notes about nodes

a new node system will make scripting easier.

 

Nodes can be of type action, trigger or object and have different in- and output connectors.

  • object nodes show their connections to their triggers
  • triggers and actions show connections to their actions
  • property window shows up upon double clicking a node (same window as before)

 

a connecting line between two connectors only visualizes that action A has a link to action B. How that link works is up to the actions in question. One action might modify another action’s properties directly (‘push-mode’) while another action reads a property of a connected action (‘pull-mode’). Both cases would simply display a line or curve between the two connectors.

a first attempt at rendering nodes inside a clipped area:

along with this change, the base action might be expanded:

each action might get the ability to trigger a remote action, just like the ‘execute’-action did before.

This works exactly like a follow-up action, except that the executed action can be a remote action and doesn’t have to be an immediate child.

Continue reading

why weak pointers don’t work

Recently, I’ve implemented a weak pointer class that manages its resource pointer by setting it to NULL in every instance that uses that same resource.

 

That way, weak pointers allow for notifying anyone who has a pointer to that resource once the resource gets deleted.

 

Good idea, especially since p407 uses a dynamic editor environment with objects that reference others that might get deleted at any point.

Continue reading

logic operations

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).

Continue reading

spring cleaning

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:

Very Sleepy

Continue reading