Author: s20

Fix operator< for the Position2Raw type as well as an off-by-one error when writing the mapping of light position to unique light id

Relates to #43, #48

Hi! The mighty light chair is returning for another appearance. This time, it seems after some quick testing, it seems tearing down and adding new walls works properly in regards to light sources being associated with the right positions. Turns out having a std::map that cannot work properly due to a faulty condition in operator<() in a containing type is not a good thing that may lead to overlapping mappings. While debugging that I had a minor epiphany about a potential off-by-one problem, but the code broke before that even mattered. Now both should be fixed though. 🙂

Still wrong is the calculation that should take the size of the containing room into consideration when calculating the ambient light intensity, same goes for light colour, which is not used at all yet. One step at a time. Bye!

Add the new configuration options for light information, move the data all the way to the python script, make it possible to use job messages even after an object was destroyed, implement add/move/remove light in the abstract light class

Relates to #43, #47, #48

Hello! Once again a rather heavy commit touching many different files and places. After a lot of preparation the point to actually have a visual difference has come, still very much WiP and slightly buggy, but..behold

As you can see there is no model for light sources yet, so the chair model will have to do for now. When adding and removing rooms it will easily glitch out right now and not reset it tiles to their proper values. There is a problem with the light intensity calculation and the colour of light sources is still simply completely ignored. But it’s still quite nice to finally see a visual difference when adding a new light source. 🙂 Hopefully these bugs won’t take too long to resolve so that the system can be fleshed out more. Bye!

Change the function signature of the lifecycle object callbacks and move more responsibility to the abstract object class

Resolves #55

Hi! Finally being able to check a ticket off again, that’s nice! The life cycle callbacks work as intended, it looks something like this:

That’s all for today! Next up, exposing (some of) the object configuration to object scripts and then wiring up the light creation code to Python as well, let’s see if we can finally bring some (rudimentary) light to the nights. 🙂

Add callbacks to object scripts. Refactor object scripts to improve non-controllable script objects. Expose Pos3 class to Python (and refactor it on the C++ end to make it explicit). Add new object categories.

Relates to #55, #56, #47, #48

Hello! I’m pleased to announce that no scope creep whatsoever occurred in this commit. None. Anyway, here’s Wonde in this commit some things were prepared/started, while others almost finished.
The big ticket item this time is probably the almost complete support for callbacks into an object’s Python script. The part I am not yet happy with are the passed arguments, but besides that the basic principle seems more or less sane.
Also a lot of refactoring happened on the Python end, not as much in terms of code, but the actual class hierarchies and what exactly gets passed to object script constructors. Good stuff.
Some more code is also being exposed to the Python API, that too is nice.
New object categories (LightSource, FewTicksRequired, Togglable) were introduced, some only in name, others (half)implemeneted.. so.. no scope creep. Nothing to see here. Move along. Bye.

Make sure to update subsequent light id to light vector mappings. Swap the position from idx -> lightId to lightId ->idx in the mapping to make it easier to work with

Relates to #48

Hi! Once more nothing too exciting happening here, just the sudden realisation it’s probably a good idea to keep proper track of mappings when removing elements. One of these days this code will actually get to run. Stay tuned. 🙂

Add function to the room manager to update a specific light source

Relates to #48

Hello! This one comes as advertised, just a function to actually update the existing light data, which might come in handy. Bye! 🙂

Update the light room assignments when adding/removing walls

Relates to #48

Hi! Not much to add to this, another missing piece done. Hopefully working, the first full integration will show. 🙂

Add support for adding/removing light sources to the room manager (WiP, untested and does not react to wall changes yet)

Relates to #48

Hello! After struggling quite a bit with some unintended changes in my local build environment as well as a slightly demotivating type of tasks to conquer that next milestone this one took a while. However, while it does not look like much (in fact, there is no visual change whatsoever) there is now logic in place to add and remove dynamic light sources. The bad news is, that data isn’t used anywhere yet, let’s see if we can make that happen sometime soon. 🙂

Remove the global ambient light information as this is handled per tile and rename/refactor some structs/members to more acurately reflect their purpose

Relates to #44, #45, #46

Hello! Just some more preparation work for more in-depth changes to the ongoing lighting work. In order to keep things at least in the spirit of being atomic this work was done in its own separate commit.

Add version header and a mechanism to add the current git commit hash when building from gitlab

Hi! Unlike the original plan another small feature was added today: commit hashes in the builds (which will dutifully report this as part of the version number now).
That being said, the version number is now also advertised, which is currently at 0.0.2, which in itself does not have any actual meaning yet. The plan is to jump to 0.0.3 as soon as the light topic comes to a close, as that will make OLives look significantly better, but let’s see about that.
Anyway, the reported version number in all its glory:

Riveting!