Add local / non-synced Variants of Logix Variables and other Nodes

[Banane9]

Is your feature request related to a problem? Please describe.

In many cases, temporary data written to registers during impulses is only necessary for the local user executing the impulse. It is possible to prevent synchronisation of these temporary values by using a Value or Reference Copy component on them, but this is a relatively annoying process and not discoverable without someone showing it off.

Therefore it'd be nice to have local variants of any Logix nodes that act as value storage.

Relevant issues

• 2590 where Sync-behavior was clarified

• 2324 where a combined "writing a temporary value" node is requested, which would likely also benefit from this request

Describe the solution you'd like

Under Variables, add what amounts to a copy of Storage called Local Storage. All variable nodes in this would be "Local " and not sync the value being written to them.
Additionally, add local variants of Boolean Latch, Stopwatch (or w/e the node counting time since an impulse is called) and other nodes that act as storage for a value.

This would make it easier for new users to discover local values as a network-performance saving measure and save "veteran" users the hassle to open an inspector for every node they want to localize. Additionally, localized nodes would be clearly indicated, rather than looking like any other synced value when editing.

Ideally, all nodes that already use the copy component on the same slot to localize the value would be updated to the local variants, to improve readability for those existing ones too.

Describe alternatives you've considered

Continuing to manually add Copy components manually to nodes to localize their values. This is a hassle, not discoverable for new users, and hurts understanding of behavior when reading the produced logix at a later date or by another person.

In theory, the local variants could simply be a short hand that automatically sets up the copy component when spawning the node, rather than having to do it through an inspector. However I assume this wouldn't help with the problem of making the alterred behavior clearly visible.

Additional context

It is often said that users on platforms with majority user generated content have a responsibility to keep their content performant too. Therefore I think it's prudent to improve optimization options, by allowing value storage without causing network traffic to be easily discovered just through looking at the available nodes. The earlier this is added, the fewer systems will be built where unnecessary network traffic is a side effect, lowering the work to upgrade things in the future and improving performance for users with lower bandwidth connections.

[Zyzyl]

It would appear there is a relevant item on the LogiX roadmap https://github.com/Neos-Metaverse/NeosPublic/projects/15#card-61393175

[Banane9]

Well, then I suppose there's an issue for tracking any progress, prioritization and discussion, now 👍

[H3BO3]

Yeah, this is already a planned feature. A prerequisite is propagating the "local" status to things that use or reference that data, so people don't get confused when they code something that doesn't get replicated to others. Closing this issue

[ProbablePrime]

I dont' think we should close issues that are mapped to a card. LEaving them open allows for discussion. I will reference this issue from the card though.

Discussion is important especially for newer features.

[H3BO3]

The feature hasn't even been implemented yet but okay

[ProbablePrime]

We can discuss its design before its implemented.

[Frooxius]

Yes, as per roadmap this is planned and already overall designed, though some details still need to be designed before full implementation.

The trickiest part on this is doing it in a clean way. We want to prevent scenarios where local-only and synced values get accidentally mixed and result in confusing behavior, where a part of the data model is driven from something (partially) local only by accident, causing desync. Those bugs are often hard to diagnose, as they don't happen when the user tests alone and sometimes are not even immediately apparent when testing with multiplayer as they diverge over time.

Neos' data model is designed to prevent those kinds of bugs altogether as much as possible and the planned redesign of LogiX validation system will ensure that's kept - the "local only" value source will propagate when validating and warn the user whenever they want to plug it back into the data model.

This is also one of the major per-requisites for collections, as those will benefit from local only data greatly - e.g. constructing array or dictionary for JSON serialization, without having to sync it to other users, causing a lot of network traffic.

[JackTheFoxOtter]

My two cents on this issue - this is a great idea that I'd very much approve, I'm just not sure if implementation wise it would be a good idea to create dedicated nodes for all localized variants (for example "Value Register" and "Local Value Register", "Boolean Latch" and "Local Boolean Latch" etc.) since this applies to all nodes that have an internal state, perhaps this could be a more generalized setting you can toggle per-node if that node has an internal state, perhaps visually highlighting the localized nodes in some way. That way it would automatically apply to any current and future Nodes with internal state, while also not adding even more clutter to the node browser. A visual hint, for example a different color, would also be easier to spot at a glance when taking a look at someone elses (or your past self's) code. I think the differentiation between something being local or synchronized is fundamental and versatile enough that it would warrant an extra language feature.