logic actions of type AND, OR, etc. each take one or multiple input logic actions and alter their internal state.
Optionally, they can have a target, just like any other action.
The main difference is that that target isn’t an object but a trigger or another action that gets triggered when the logic operation’s internal state either hits true or false (configurable).
some management in the event handlers to make sure gui items being processed don’t get removed/moved around in the item queue.
serialization of items has been expanded to allow for local copies of items including their full hierarchy. Child objects that reference other objects within the hierarchy should now be guaranteed to point to the same (relative) item within the copy, while references pointing at items outside the hierarchy should remain the same on a copied item.
I’ve found a neat little code profiler that allows me to find bottlenecks in my program flow:
the tree view class is working, albeit with a few glitches still.
In order to get the scene graph tree working, there were a whole lot of problems with the grid class to be solved. That took its sweet time, but it’s (mostly) behaving the way it’s intended now.
What remains to be done is icon support in list views / labels, as well as the implementation of the eventhandler in the scene graph tree view.
After all, we want to be able to interact with the tree, not just look at all those pretty names.
a Tree view, derived from the list view, displays all the existing terrain patches.
Tree structure:
logic actions:
base action CLogicAction that has a status (true or false)
each derived action can combine a set of other actions and evaluate their status to generate an own status, then optionally trigger a follow-up action if the status is either true or false.
fcts:
and, or, nand, nor, xor, etc..
set (true / false), toggle
Journal
New Posts & Thoughts