Rewrite a bit more |
Add links |
||
Line 6: | Line 6: | ||
Impulses have some data associated with them. This data includes: | Impulses have some data associated with them. This data includes: | ||
* The user who sent the impulse, which can be read via a [[ProtoFlux:Local User|Local User]] node during the impulse. | * The user who sent the impulse, which can be read via a [[ProtoFlux:Local User|Local User]] node during the impulse. | ||
* The time of the impulse, read by the T (WorldTime) nodes or UTC Now (and similar) nodes. | * The time of the impulse, read by the T ([[ProtoFlux:World_Time_Float|WorldTime]]) nodes or ([[ProtoFlux:UTC_Now|UTC Now]]) (and similar) nodes. | ||
When a ProtoFlux value is connected solely into nodes that receive Impulses, the value is no longer evaluated every game update but only when the node is impulsed. This is useful to optimize performance as instead of doing a constant evaluation, you wait until a Impulse is received to evaluate. A heavy computations which benefits from this approach is FindChildByName which searches an entire hierarchy when it is evaluated. In this scenario, the search only has to be done once during the Impulse, and then optionally it can be cached using a Write node. | When a ProtoFlux value is connected solely into nodes that receive Impulses, the value is no longer evaluated every game update but only when the node is impulsed. This is useful to optimize performance as instead of doing a constant evaluation, you wait until a Impulse is received to evaluate. A heavy computations which benefits from this approach is ([[ProtoFlux:Find_Child_By_Name|FindChildByName]]) which searches an entire hierarchy when it is evaluated. In this scenario, the search only has to be done once during the Impulse, and then optionally it can be cached using a Write node. | ||
{{Note|Non-Asynchronous Impulse Code will freeze the game engine loop until the code is finished. This can cause performance issues, and is why it is highly recommended to make lengthy computations Asynchronous and to not evaluate them constantly.|warning}} | {{Note|Non-Asynchronous Impulse Code will freeze the game engine loop until the code is finished. This can cause performance issues, and is why it is highly recommended to make lengthy computations Asynchronous and to not evaluate them constantly.|warning}} | ||
== 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 [[ProtoFlux:Delay|Delays]], [[ | 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 [[ProtoFlux:Delay|Delays]], [[Category:ProtoFlux:Variables:Cloud|Cloud variable nodes]], and [[ProtoFlux:ASync While|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 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. | ||
Line 23: | Line 23: | ||
== Contexts == | == Contexts == | ||
Contexts are a way for ProtoFlux to store a state of local variables in the scope of the executing code. A new context can be created using the StartAsyncTask node. Variables in the context will still be able to be accessed and read with the same values even if Delays are used. A context can be thought of as what data is available during a certain Impulse. | Contexts are a way for ProtoFlux to store a state of local variables in the scope of the executing code. A new context can be created using the [[ProtoFlux:Start_ASync_Task|StartAsyncTask]] node. Variables in the context will still be able to be accessed and read with the same values even if Delays are used. A context can be thought of as what data is available during a certain Impulse. | ||
Revision as of 01:08, 18 February 2024
This article or section is a Stub. You can help the Resonite Wiki by expanding it.
Impulses
Impulses (or Calls) are triggered actions. They normally do not have a duration (unless using Async calls) and happen in a singular instantaneous moment. Some examples of Impulses could be when a user clicks a button, when a user collides with something such as the ground, or when a object gets duplicated.
Impulses have some data associated with them. This data includes:
- The user who sent the impulse, which can be read via a Local User node during the impulse.
- The time of the impulse, read by the T (WorldTime) nodes or (UTC Now) (and similar) nodes.
When a ProtoFlux value is connected solely into nodes that receive Impulses, the value is no longer evaluated every game update but only when the node is impulsed. This is useful to optimize performance as instead of doing a constant evaluation, you wait until a Impulse is received to evaluate. A heavy computations which benefits from this approach is (FindChildByName) which searches an entire hierarchy when it is evaluated. In this scenario, the search only has to be done once during the Impulse, and then optionally it can be cached using a Write node.
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,, 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. Likewise if running Async code constantly it can also cause performance issues.
Async is currently not multi-threaded which is talked about in this video (at 40:00): link to the video at the specified time
Contexts
Contexts are a way for ProtoFlux to store a state of local variables in the scope of the executing code. A new context can be created using the StartAsyncTask node. Variables in the context will still be able to be accessed and read with the same values even if Delays are used. A context can be thought of as what data is available during a certain Impulse.
Local Nodes will have the default value for their data type until 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 its value is written to a Data Model Store it will persist, 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 Impulse, the last value is the value that gets networked to other users.