Month: January 2021

Implement heat pump mechanics for inside and outside temperature modifiers

Resolves #67

Hi! This commit adds the last big building block of the temperature milestone (in GitLab parlance). While at first heat pumps are a fairly technical concept, in the concept of temperature in OLives they also make a lot of sense, if you put an aircon unit somewhere, that exhaust heat has to go somewhere:

What made this tricky is that so far, the temperature modifiers operated under the assumption that there is an absolute target temperature. The exhaust temperature modifiers however need to work with a relative value.
With every object that is marked as heat pump, not only one, but two temperature modifiers are being created.
The first (primary) is created for every temperature modifying object (like the radiator), the second (exhaust) is marked as inactive as long as the first is not responsible for any actual temperature changes and its value gets updated as soon as the primary modifier is causing a different effect on its own tile.
This fit rather neatly into the existing concept, so even cases like the one below look weirdly nice:

I’m pretty happy to have this task behind me and I’m fairly happy with the result, next on the agenda is, probably, fleshing out the height map concept, which kind of exists in OLives, but hasn’t been touched in two years and is not exposed to the user at all right now. Stay tuned for more, bye. 🙂

Do not accidentally move the object to position (0,0) when aborting a walking job at just the wrong time

Resolves #68

Hello! This is the second of two quick fixes that really annoyed me while testing. Due to a unfortunate chain of circumstances the object navigation was sometimes reset in a way that caused a code branch to run that was trying to pop off an element from the upcoming navigation candidates when it was already empty, implicitly creating a new node with X and Y values of 0 respectively. What happened next is that this was assigned as the next position and magically the object was teleported to (0, 0).
Not anymore.
Time to get to the last ticket regarding the temperatures, which might be a bit more complicated than the previous ones, but let’s see. Bye 🙂

Update which walls should be auto-hidden by applying the changes from the tile information staging buffer after adding new walls

Resolves #71

Hi! This is just one of two (hopefully) quick commits to fix some issues which got a little annoying while developing. This fix in particular addressed a regression which was recently introduced as I added a new stating buffer for room tile information.
The buffer itself worked just fine, it just so happened not to get applied once the new room information was determined after adding new walls, which in the visually resulted in fully-drawn walls, even though they should have been lowered, as they were covering up a newly created room.
Anyway, that’s fixed now, bye. 🙂

Add proper animations for changing settings of both regular and slim object types

Resolves #56, #69

Hello! This commit wraps up the enabling/disabling and “changing settings” mechanics, mostly by adding actual animations for that. Also, some code in Python that will select the correct animation depending on the object type that is interacted with was added. You can see what it looks like now below:

Please take special note of the excellent editing at the end of the video

This almost brings the whole temperature saga to an end, the only still missing are the heat pump mechanics. After that it will be time for some bug fixes and then it will be time for the next bigger topic. Which one that will be I am still deciding, I have thought of same rather exciting (at least for me) candidates already, so stay tuned. Byeee. 🙂

– Make the same changes to the enabling/disabling logic for temperature modifiers as for light sources
– When determining the logical tile from model vertex data, make sure to apply the animation to the vertex

Relates to #56
Resolves #70

Hi! This commit was mainly about applying the same more generic approach to disabling/enabling as was already implemented for light sources in the previous commit.
While doing so I had a bit of a minor epiphany about a lighting issue which can be observed in this screenshot:

What happened here is that when trying to determine the light situation in a vertex’s environment, the animation(s) was/weren’t applied to the current position yet. Since the “neutral” position for the vertices which are way too bright here is actual further away from the model’s torso, they are actually on a different tile, at least as far as the lighting logic is concerned.
Luckily, fixing this was as simply as applying the animation. 🙂

Speaking of animations, next up on the never ending todo list is fixing the still-looping animation when enabling, disabling and changing settings on an object. Bye. 🙂

– Extend the AbstractObject and AbstractLight python classes to support enable/disable events.
– Extend the LightInfo class (+ Python counterpart) and the LightInfo struct in GLSL with an active/inactive flag
– Based on that, implement enabling/disabling light sources for togglable object types    

Relates to #56

Hello! This commit is basically self-explanatory, it is now possible to turn light sources off and on. To be more precise, that means objects which are both marked as togglable and have a script that implements the AbstractLight class.
While implementing that, I realised that this generic approach makes a lot more sense, so I will also move the “setting the temperature” action to something very similar before moving on with the actual animation for both.
Once that is all done, it might even make sense to post a quick video again. Who knows. Byee 🙂

Support multiple objects that have temperature modifiers on the same tile

Relates to #64

Hi! This rather innocent looking commit changes the way the internal mapping of objects to their respective temperature modifiers works. As has been previously mentioned, so far that was only supporting a single object that has a temperature modifier per tile, which would probably lead to complications and made calling some functions a bit awkward.
This has been rectified now, the real star of this commit though is changing the text on enable/disable buttons to “Turn on” and “Turn off” respectively, as that rather sounds like what an actual person might say. Byeee 🙂

– Add togglable object mechanics (WiP, mostly done)
– Add temperature selection for temperature modifying objects
– Extend the Python API to support modifying temperature modifiers properly
– Add a configuration option to enforce debug logging in release builds

Relates to #69, #56

Hello, while this is a rather substantial change I will refrain from creating a video for now, enjoy this screenshot instead:

The reason for this is that the topic is not quite done yet, and I would rather present it when it is working without any (known) quirks. The basic mechanic is fine, but due to some regressions when updating room data it may lead to crashes if things are being done in a certain order.
Getting this off the ground required the usual extensions of the Python API, as well as implementing some new functions on the C++ side to make it happen.
While doing so I also realised I definitely need to properly support multiple temperature modifiers on the same tile. A fact that I, for some reason, convinced myself at first is not necessary. Oh well.

The other headliner here is that it is now possible to override the standard setting of not having debug style output in release builds, it can be enabled by setting force_debug_logging to true in the config.json.
Byee 🙂

– Only slowly change an agent’s temperature depending on its surrounding temperature
– Boost the temperature by 5+C when the agent is lying down (presumably covered up)
– Slowly decrease HP if the agent is above or below its allowed temperature range

Resolves #61

Hi! I initially wanted to take a video for this commit, but as it turns out, looking at bars go up and down isn’t exactly riveting to watch 🙂
That being said, you better get those agents into a warm, cosy house at night (or into a bed), as otherwise they might suffer from hypothermia. Ouch.
Next up will either be a quick bugfix or two or build the temperature selector for temperature modifiers, the next few days will tell. Byee! 🙂

– Extend Python API to support object specific temperature functions
– Add some glue code to the GameState to allow passing of the current tile temperature to the Python side
– Add a very simple WiP implementation on the Python side that just uses the current tile temperature as the object one
– Make the linter happier
– Play around with some constants in regards to temperature propagation through walls (feels more realistic now)

Relates to #61

Hello! While not exactly atomic in nature, this commit is mainly about getting the temperature calculation going. The actual “calculation” as such is simply done assigning the temperature value of an agent’s underlying tile to the object itself, but bulk of the work here was setting up all the right values without getting too much of a performance hit.

The latter can happen since this code is being executed on every tick and calls from C++ land to Python (and vice versa) can end up in more overhead that one may initially anticipate.

To somewhat mitigate this effect the pre-fetched value is being passed when calling to the tick handler from the C++ side, even though the Python API could simply fetch it on its own, in order not to make yet another call on every tick.

You can check out below what that currently looks like:

Next up will be writing some actual logic to make it feel a bit nicer, but I probably won’t get hung up on too many details here, as there is another ticket or two (or three) to be done overall before the temperature topic can be considered more or less done. Bye. 🙂