ProtoFlux:While: Difference between revisions

From Resonite Wiki
added examples, no longer a stub
relink
 
(6 intermediate revisions by 4 users not shown)
Line 4: Line 4:
|Inputs=
|Inputs=
[
[
{"Name": "*", "Type": "Impulse"},
{"Name": "*", "Type": "Call"},
{"Name": "Condition", "Type": "bool"}
{"Name": "Condition", "Type": "bool"}
]
]
|Outputs=
|Outputs=
[
[
{"Name": "LoopStart", "Type":"Impulse"},
{"Name": "LoopStart", "Type":"Call"},
{"Name": "LoopIteration", "Type":"Impulse"},
{"Name": "LoopIteration", "Type":"Call"},
{"Name": "LoopEnd", "Type":"Continuation"}
{"Name": "LoopEnd", "Type":"Continuation"}
]
]
|}}
|}}


A While node will start running when * is [[Impulses|impulsed]]. The code will continue running and hold a [[Impulses#Context|context]] until the provided Condition is false or the max execution iterations is hit.  
The '''While''' node is used to perform looping operations by allowing one to fire [[impulses]] continuously while a condition remains true.
{{Note|If just a [[ProtoFlux:Input|Input]] with the type boolean set to true is provided, the code will not be able to stop and will error the entire Flux chain once max iterations is it, stopping execution.|warning}}
 
Caution should be exercised when using this node. If it is easy to determine how often the loop is going to execute, a [[ProtoFlux:For|For]]-Loop should be preferred to avoid accidentally crashing the game.
{{Note|Be very careful when developing with this node. [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/774 There is no iteration limit for debugging] and [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1677 ProtoFlux does not have handling for execution taking too long]. If you accidentally create an infinite loop, you'll be unable to save progress or anything else important. Consider adding your own iteration limit, not being connected to an input impulse while developing, and save before testing!|danger}}


== Inputs ==
== Inputs ==
Line 23: Line 23:
=== * ([[Impulses|Call]]) ===
=== * ([[Impulses|Call]]) ===


Impulse to start the loop
Begin the while loop.


=== Condition ([[Type:Bool|Boolean]]) ===
=== Condition ([[Type:Bool|Boolean]]) ===


The value that the loop will check for if it should continue running or not.
Condition that the loop will check to determine if it should iterate again or not. If <code>True</code>, it will iterate again.


== Outputs ==
== Outputs ==
Line 33: Line 33:
=== LoopStart ([[Impulses|Impulse]]) ===
=== LoopStart ([[Impulses|Impulse]]) ===


Fires once at the beginning of the loop, regardless of if Condition ([[Type:Bool|Boolean]]) is true or not.
Fires after <code>*</code> is pulsed and before any iterations are performed. Will be pulsed even if <code>Condition</code> is <code>False</code> at the time of the loop beginning.


=== LoopIteration ([[Impulses|Impulse]]) ===
=== LoopIteration ([[Impulses|Impulse]]) ===


Fires infinitely all in one game tick until the game crashes, or Condition ([[Type:Bool|Boolean]]) is false. Will only fire if Condition ([[Type:Bool|Boolean]]) is true.
Will be pulsed for as long <code>Condition</code> is <code>True</code>. Only after the [[context]] of the current loop iteration is finished will the next iteration fire.


=== LoopEnd ([[Impulses|Impulse]]) ===
=== LoopEnd ([[Impulses|Impulse]]) ===


Fires once the triggered loop has ended and the node has not hit a critical error.
Fires after <code>Condition</code> turns <code>False</code>, continuing the impulse chain from before.
 
== Known Issues ==


== Examples ==
* As of the time of writing, there is [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/256 a known issue] where if the final node in the <code>LoopIteration</code> chain is a [[ProtoFlux:Write|Write]] node, said node modifies a variable used for conditional evaluation, <em>and</em> the value to write is based off said variable, the write will be using a previously cached value. This can cause an extra loop iteration to occur, which is very annoying to debug.
** The easiest way to work around this bug is to add a "dummy" node after the write, such as an [[ProtoFlux:Impulse Display|Impulse Display]] or, if debugging a ton of impulses and lag is undesirable, an empty Write node.


<gallery widths=480px heights=480px>
== See Also ==
File:Protoflux_example_while_loop.webp|Example of how to use a while loop.
File:Protoflux_example_while_loop_failed.webp|Example of how to not use a while loop, which will crash the game if fired.
</gallery>


* If it is possible to determine the amount of times you need to loop beforehand, consider [[ProtoFlux:For]] instead.
* [[ProtoFlux:Async While]] for the [[async]] variant of this node.


[[Category:ProtoFlux:Flow]]
[[Category:ProtoFlux:Flow]]

Latest revision as of 19:22, 15 December 2024

While
*
LoopStart
Condition
LoopIteration
LoopEnd
Flow

The While node is used to perform looping operations by allowing one to fire impulses continuously while a condition remains true.

Be very careful when developing with this node. There is no iteration limit for debugging and ProtoFlux does not have handling for execution taking too long. If you accidentally create an infinite loop, you'll be unable to save progress or anything else important. Consider adding your own iteration limit, not being connected to an input impulse while developing, and save before testing!

Inputs

* (Call)

Begin the while loop.

Condition (Boolean)

Condition that the loop will check to determine if it should iterate again or not. If True, it will iterate again.

Outputs

LoopStart (Impulse)

Fires after * is pulsed and before any iterations are performed. Will be pulsed even if Condition is False at the time of the loop beginning.

LoopIteration (Impulse)

Will be pulsed for as long Condition is True. Only after the context of the current loop iteration is finished will the next iteration fire.

LoopEnd (Impulse)

Fires after Condition turns False, continuing the impulse chain from before.

Known Issues

  • As of the time of writing, there is a known issue where if the final node in the LoopIteration chain is a Write node, said node modifies a variable used for conditional evaluation, and the value to write is based off said variable, the write will be using a previously cached value. This can cause an extra loop iteration to occur, which is very annoying to debug.
    • The easiest way to work around this bug is to add a "dummy" node after the write, such as an Impulse Display or, if debugging a ton of impulses and lag is undesirable, an empty Write node.

See Also