Tag: c++

– add another temperature related configuration option
– change internal implementation of the configuration getter functions to a generic template for all data types
– flesh out format for temperature modifier JSON configurations
– properly validate object type configurations upon start-up
– extend the python API to allow adding and removing of temperature modifiers
– change code formatting style in relation to functions with long parameters whenever coming across it
– change some defines into const expressions
– add logic for temperature modifier similar to the light source logic to the room manager
– further extend the actual temperature modifier definition to handle all use cases (i can currently think of)
– refactor some light source utility code in the room manager so that it can reused for temperature modifiers
– add logic for mapping temperature modifying objects to actual temperature modifiers (and create/move/delete the modifiers as needed)
– add additional code in the object manager that triggers the mapping creation/update/deletion when objects marked as temperture modifiers get changed (WiP, it is currently still inlined in places it does not belong and needs to be moved elsewhere)

Relates to #64

Hello! It’s been a pretty long time, but unfortunately some good old scope creep made this commit grow bigger and bigger. Be that as it may, most of these items should be more or less self-descriptive and it would be frankly a bit tedious to take this apart item by item.
To sum things up, it got the entire temperature modifier concept a bit closer to a practical application. Unfortunately I cannot show a screenshot here, as all the changes (even though there were plenty) have no visual effect yet whatsoever, but that should change soon.
I already made up my mind concerning the scope for the next ticket, which will be a very small fraction of the above, so stay tuned. Byeee.

Add an aircon unit as an object (as an object type + assets)

Resolves #65

Hi! This commit basically only adds a new model and the basic configuration necessary to make it show up in OLives. Enjoy the, no doubt, breathtaking beauty of said unit below:

That being done that means we are going back to actual coding to actually give these two new objects actual functions. Stay tuned, the great temperature saga continues. Bye!

– Add new temperature modifier object category
– Add new object category “WallMountedSlim” to have wall mounted objects that allow tiles to remain navigable
– Add new object “radiator” which has no function yet

Resolves #64, #65

Hello! Once again another temperature related commit, this time once again more preparation is being done as well as another model is added. Behold, the radiator:

It has no function as such yet, but it is already the first object of the new “WallMountedSlim” object category, which is almost the same as “WallMounted” (like the sink), however tiles they are placed on remain navigable and they can be placed below windows.
Before continuing with the temperature modifier implementation I will probably add another object/model to get this out of the way, but let’s see. Byeeee.

Visualise the current temperature of a tile (if the temperature draw mode is selected)

Resolves #63

Hi! This implements the rest of ticket 63, visualising the current temperature of a tile. It does so by interpolating a colour that is somewhere between two colours (a shade of red and blue respectively). As a result of this we can finally see the dummy calculation for “inside temperature” in action.

A small caveat that comes with this approach is that the visualisation only has an effect on the tiles, so it may look a bit weird in darker environments, as can be seen on the right. Be that as it may, I’m happy with the quick progress (most of the leg work was already done in prior tickets) so next up will be the arguably a lot more complicated tasks of finding a sensible way to calculate the per-room temperature and implementing a concept of “temperature modifiers”. As always, one step at a time!

Adds UI elements, state in multiple classes and texture assets to choose and store the current tile view mode (temperature or “normal”)

Resolves #63

Hello! This is the first, and arguably the easiest, step in introducing temperature as a concept. It really only meant adding a new state variable in the appropriate places and wiring up a way to control (and show) the current state in the UI. And of course, similar to the wall draw state, make it togglable via a hotkey. Bask in its glory below:

Add outside temperature view to UI

Resolves #59

Hi! As first part of implementing the concept of temperature meant there is now a visualisation of the current “world” temperature on the UI. It is calculated very similarly to the way the outside light information is, based around weighted averages of reference values for certain times.
Nevertheless, check it out below:

Add feature to select multiple wall tiles by pressing shift.
The tiles get added in the following order:
1. Follow 90° angles on both ends of a wall tile (as in corners inside a room)
2. For each side, if nothing was found, try to follow wall adjacent wall tiles on the same plane
3. For each side, if nothing was found, try to follow 270° angles (as in corners outside a house) 

Resolves #39

Hello! As mentioned in the last post, now it’s also possible to quickly change the wall types for entire rooms or the exterior of an entire building easily by holding shift while selecting.
It works very similar to the way the floor tile handling does, but was obviously a bit more tricky to implement. Nevertheless, check out the result below 🙂

Be more sensitive about when to lock and unlock mutexes in order to fix crahes/vulkan memory warnings in a variety of situations

Resolves #66

Hello, not particularly exciting, but that should take away the most occurring problems resulting in crashes. There may be some visible flicking sometimes when placing a window now, but I definitely prefer that over potential crashes. 🙂
On to the next usability topics, doing bulk wallpaper changes. Byeee!

Add the ability to change the floor for an entire room at once

Resolves #38

After much under the bonnet work I’ve decided to put in two long-standing tickets, bulk editing for wall tiles and floor tiles, this commit implements the tile part:

Implementing this got a lot easier by finally introducing the concept of “rooms” a while back. On more good news, doing this will also make implementing the wall counter-part of this ticket a bit easier. However, not happening in release builds, but debug builds is a weird race condition that I will have a look into first. Hopefully that is not going to take too long, but be that as it may, I’m happy to see this happening finally. 🙂

– Fix race conditions when drawing placement markers that regularly caused validation errors (or even crashes)
– Replace marker state hash and wall state hash calculation with a simple increment as it is only called after actually changes    

Resolves #50, #49
Relates to #52

Hi! Yet another low-key change that has a big impact: no more random crashes (or warnings) when placing walls due to the build marker code doing some funny things when synchronising the draw commands.
There are some other issues which may be due to similar race conditions, but I’ll get to that at some other point, this was definitely the worst example for this problem, making building walls for testing purposes a bit of a gamble.
While doing that I also finally got around to replace two over-complicated and not necessarily reliably working (build markers and walls) hash functions with a simple increment.
Since either recalculation only ever gets triggered after actual state changes there is no harm done here, in fact it greatly simplifies the code, so, yay!
Next up are more visible changes again, which is also good for my motivation. Byeee.