Impulses

This article or section is a Stub. You can help the Resonite Wiki by expanding it.

Impulses

Impulses are a way for ProtoFlux to do actions that happen during a specific time, rather than a continuous per-game-tick basis. They can be considered as a sort of action. When an impulse is triggered it's like an event in a game. When the user hits a button that sends an impulse, when your feet visibly hit the ground, that can send an impulse. When you fill a glass entirely, an impulse can be sent.

Impulses have data associated with them. This data includes

• The user who sent the impulse, which can be read via a Local User Node.
• The index of the impulse of the total number of impulses sent down the line.
• the start time the impulse was sent.

Think of Impulses as an instant action, that doesn't have a duration, but rather an instant moment in time which all code must run before the next smallest unit of time can happen.

When a protoflux value socket is connected solely into nodes that recieve Impulses, the value is no longer calculated every game tick but only when the node is impulsed. This is useful if you want to search the entire root for a slot, but then Write it to a variable to keep it for later. In this scenario, the search only has to be done for one frame, and then the cached value can be used instead. Searching the entire root is extremely costly, but if the value is written and then cached, the performance impact is negligible.

Non Async Impulse Code will freeze the game engine loop until the code is finished. This can cause huge performance issues, and is why it is highly recommended to make large computations Async

Async

Async or Async Impulses are a way to take your code and run it over more than one engine update cycle. Async Impulses are required to run nodes that are in the ProtoFlux Async category as these nodes require a Async Operation to start executing and will often take some time to complete what they do. Nodes like this include but are not limited to Delays, Cloud variable nodes, and ASync Whiles.

Async is a way in some cases to reduce lag in some code as instead of halting the engine while you do a bunch of work in one update, you can spread the work over time and over multiple updates instead.

Async however will not completely remove lag from actions done in world. So if you create a massive amount of data that has to be networked all at once, then making the code Async will not always prevent the lag from occurring.

Async is currently not multi-threaded which is said in this video (at 40:00): https://www.youtube.com/watch?v=1losWav_AZQ

Contexts

Contexts are a way for the game to store a frozen state of the game in which to keep values the way they are during execution. This means if you use a Fire On True, Fire On False, or a Fire On Change the data in the entire world during the impulse generated by the nodes will not change except when acted upon by the code. This is why functions like creating dynamic variables, moving them, or checking protoflux indirectly will not work instantly and will require a new context from a few game ticks later.

For example, if you change the Position of a Slot, and then check a value that should change via a write node based on the slot's position, it will not update. This is because the other impulse chain is waiting for that context to be released, and will not fire till the next game tick. New contexts can be generated through a delay, or by a new impulse in later game ticks.

On the contrary if a value that is being driven by other protoflux or components is checked during our impulse, the code driving it will update the value first (Also known as Evaluating) before our code uses the final value for the execution.

The StartAsyncTask node will create a new context from which all previous values read from ProtoFlux nodes will be frozen and still be able to be read from any downstream nodes even if Delays are used.

Local Nodes will be the default value for it's data type till it is written to during a context. During that context, the local node will keep the value from every write and change to it. Once the context is released, the value instantly returns to the default value, discarding the data, preventing it from being seen or networked. However, if it's value is written to a Data Model Store it will persist across all contexts, allowing it to be seen by everyone in the session through the network.

A Data Model Store on the other hand will allow writes to it that will persist across contexts, allowing for another impulse or script to read the variable later and act on it. This is good for storing your final value after a massive calculation as a value for a smaller drive script. If a Data Model Store is written to multiple times in a context, the last value the data model store has after the context is the value that gets networked.