Impulses, sometimes known as calls, are discrete actions within ProtoFlux and one of the two basic types of chains to build. In contrast to chains of inputs and outputs to a node, which are generally continuous to one another, impulses push a task execution along the impulse chain, much like conventional imperative programming.
Overview
In ProtoFlux, nodes that perform a discrete action require an impulse to execute. For example, duplicating a slot can't trigger whenever it wants--it would be impossible to control such a thing. As such, a special input * of type Call is used to trigger the action. This chain can then be continued via the Next output.
Upon an action node receiving an impulse, it evaluates all the non-impulse inputs connected to the node. This contextualizes the relationship between impulses and other node chains: Impulses push task execution, while action nodes pull their inputs, which may pull their inputs, and so on until the original input can be evaluated.
Impulses are a local construction by default within ProtoFlux. If interacting with the FrooxEngine data model in any fashion, however, the actions they perform get synced across users. Impulses being local mean that they implicitly carry the user that "owns" the impulse, which can be retrieved during an impulse chain with a Local User node.
Impulses can come from a variety of sources. Most commonly, when building ProtoFlux, a Call Input can be created by dragging out an impulse input and pressing secondary. Impulses may also come from events, or impulse chains that start once receiving some sort of signal. These include, but are not limited to, dynamic impulses, button events, fire on events, and world/item events.
Contexts
Impulses exist within a context. Contexts are picked up by the trigger of the original impulse and carried until the chain completes. Contexts carry certain values with them throughout the duration of the chain, including local values and outputs to action nodes. Outside of the specific context (and nested contexts) that they are used, it is impossible to access the underlying value of one of these context-sensitive values.
Context is kept when passing through the same node group and lost if there is a disconnect of execution to a different node group. Node groups are the nodes that are all connected in some way or another, whether through direct wire connections or by references to another node, such as referencing a variable for a write node.
For example, if a dynamic impulse is pulsed, and that dynamic impulse pulses another one, and that third dynamic impulse writes to a local, the change will not be seen by the Next path of the first dynamic impulse trigger. This is because the execution leaves the node group of the first trigger after the first dynamic impulse is pulsed, causing the second dynamic impulse to not be within the same context as the initial chain. If the second dynamic impulse wrote to the same local, then all the node groups are connected, and the change will be seen by the initial Next path.
As of the time of writing, there are two different kinds of contexts in ProtoFlux: the sync context and the async context.
Sync Context
The sync context is the "default" context that most nodes will assume when developing a chain. Chains in this context run entirely in one engine update, or frame, and are incompatible with certain nodes that expect to be ran across multiple engine updates, which expect async contexts.
Async Context
Async contexts are ProtoFlux's way of being able to use coroutines within the language. They allow execution to be delayed by the user (such as the Delay node) or paused as an action not dependent on execution needs to complete (such as the Play One Shot And Wait node).
Async contexts are able to preserve locals and action node outputs across multiple engine updates, something not possible with a sync context.
Async contexts are created using the Start Async Task node. This node actually creates a nested context relative to the input context, meaning that every value used by the surrounding context is duplicated, and the new async context can change these values without the changes being reflected in the OnStarted continuation of the previous chain.
If processing a lot of data using ProtoFlux, it may be desirable to use an async context and spread execution across multiple frames, as it will prevent a massive hitch when executing at the cost of taking slightly longer.
See Also
- ProtoFlux:Local, ProtoFlux:Store, and ProtoFlux:Data Model Store for the three types of variables one can access in ProtoFlux.
- Category:ProtoFlux:Flow:Async for async flow nodes.