Fire On X fires continuously with the Standard Controller Node

[ErrorJan]

Describe the bug?

The "Fire On True" node should only pulse once the input is true and shouldn't pulse again unless the input was false and then true again. If you have another person join and connect the "Primary" output (or any boolean output) of the "Standard Controller" node and connect it with the input of the "Fire On True" Node and then press Primary (or the action required for that boolean to be toggled) it will pulse continuously, but not every frame. The same happens with the "Fire On False" and "Fire On Change" Node The "Fire On Local X" Nodes are fine.

To Reproduce

Have a user join you, then. Connect a "Primary" output of the "Standard Controller" node and connect it with the input of the "Fire On True" Node and then press Primary.

Expected behavior

For the node to only output a pulse once.

Screenshots

Resonite Version Number

Beta 2024.5.4.678

What Platforms does this occur on?

Windows, Linux

What headset if any do you use?

Quest 2

Log Files

JAN-WINARCHPC - 2024.5.4.678 - 2024-05-04 21_45_11.log

Additional Context

No response

Reporters

ErrorJan

[shadowpanther]

Using a Local User with Controller nodes is not advised and could lead to this behaviour. Try specifying a fixed user input or using the Active User Self if this goes onto an avatar or an object.

What is happening here is the Controller node starts switching between different users and showing you their respective controller inputs. This is what triggers the Fire On nodes in turn.

[mpmxyz]

I have written a warning against feeding this node local values recently: https://wiki.resonite.com/ProtoFlux:Fire_On_Change Fire On X uses a Sync internally to replicate the last measured value to every user. This means that it is not valid to feed it local values. If I were to guess the design goal here is to make it watch values that are consistent across all users and are only changed by a single user at a time. The change-events can then be triggered immediately on the user who caused it.

Use Fire On Local X instead! (-> I think this issue will end in a "by design".)

[Frooxius]

This is not a bug given this setup.

Fire On X are global nodes - they assume the state is same for every user and they have heuristics to figure out on which user the state changed first.

However since you're plugging "Local User" into Standard Controller, you're feeding local state into node that tries to detect global state. This means that each user is looking at the global state of that node, trying to figure out if the value changed.

If one user is holding the button and other is not, you essentially end up with the users fighting each other. One user sees "Oh this was last false, but it's true for me, so it fires", then the other users sees "Oh this was last true, but it's false for me, so it fires" and back and forth.

If you want to detect when the state changes for the local user (who is currently evaluating), use the Local Fire on X variants on the nodes instead.

[ErrorJan]

I see, it appeared like a bug, since the Display node wasnt switching between true and false.

[mpmxyz]

Using a Local User with Controller nodes is not advised and could lead to this behaviour. Try specifying a fixed user input or using the Active User Self if this goes onto an avatar or an object.

What is happening here is the Controller node starts switching between different users and showing you their respective controller inputs. This is what triggers the Fire On nodes in turn.

I can't find any reason that Standard Controller couldn't be fed with Local User. It just seems to read from a StandardControllerProxy of the given user when evaluated. The only side-effects I could find is creation of a proxy component on the given user if it doesn't exist yet. That could maybe create multiple components when multiple users use the same user input value at the same time for a user without that component. But it looks like a definite non-issue for the input Local User.

Is this some myth that should be clarified on the Wiki?

[shadowpanther]

Is this some myth that should be clarified on the Wiki?

I think Froox clarified this better as the expected behaviour of Fire On nodes with localised values. My explanation was not correct, then.