Allow reading Dynamic Variables without a valid space with a reference to the exact slot they're on

[5H4D0W-X]

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

Dynamic variables are immensely useful to access and change data on objects with various different slot structures. Sometimes though, the exact slot that the variable is on is known, making the DynamicVariableSpace useless and sometimes even introducing issues, particularly when duplicating slots with DynamicVariableSpaces underneath slots with spaces of the same name (such as in a tree of slots with data on them). The ability to read unbound dynamic variables would also make it easier to attach them to arbitrary objects that may not already have variable spaces, such as flux nodes, due to the current inability to dynamically attach a variable space component.

Describe the solution you'd like

Make it so Dynamic Variables can be read directly from the slot they're on even when not bound to a variable space for easy dynamic access when value propagation isn't needed, or if that's architecturally not possible add new variable components that act like dynamic variables without hierarchy propagation.

Describe alternatives you've considered

Adding a variable space to every slot that needs its own context for variables and dealing with issues arising from reparenting and duplication, where variables don't bind immediately and take on the values from their parent's space.

Additional Context

This would be super helpful in creating (more lightweight) custom data structures (lists or trees of slots with arbitrary data) and in interacting with objects and tools (adding variables to flux nodes to allow different tools to work more seamlessly).

Requesters

ShadowX

[Frooxius]

This is tricky, because it goes against the design of the dynamic variable system - it's whole point is the dynamic nature and access by a path in the variable space.

Simply put, the variables don't actually exist without the space.

The components are a definition of them and proxies, but they are not the variable itself.

To give you an example, there are components which do not hold any value themselves directly, they just proxy it to another field. You can't read those without the variable existing in the space.

The space is also what provides most of the actual read/write functionality.

I don't see a way to add this feature without making the system messy and inconsistent.

This is usually an indicator that your problem would be solved by a different type of system, designed for this purpose.

I don't fully understand though what the underlying issue is - if you already have exact references to a slot, why not have an exact reference to a field? What is the access pattern like?

[5H4D0W-X]

If slots with variables are dynamically created/duplicated or the system interacting with them is not directly connected (e.g. world system connecting to avatar or vice versa), fields can't just be directly referenced. My idea is to have a system that has many of the benefits of using dyn vars, which is to say access without direct references to fields, but without the overhead of linking variables to spaces. Let's say I make something where tons of slots are dynamically duplicated from templates to visualize something, and I want to tween them to different positions and rotations dynamically. I could put DynamicReferenceVariables to the transform fields on the slots, together with a DynamicVariableSpace each, but it would be more efficient to have variables that are specific to that slot.

TLDR Basically what I'm asking for is Value/ReferenceFields that can be read from and written to from a slot ref with flux or components. Sorta like writing to the transforms, name and tag of a slot, but with arbitrary types and an arbitrary amount of values or references.

[JackTheFoxOtter]

[...] sometimes even introducing issues, particularly when duplicating slots with DynamicVariableSpaces underneath slots with spaces of the same name (such as in a tree of slots with data on them). [...]

Are you referring to the same issue that I reported yesterday? (https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/3148) If so, would fixing that (partially) fulfill your demand for this request?

Generally, if we assume bugs like that will be fixed, I don't think the overhead of dynamic variables is a problem. I think it would be less desirable to create a completely separate system mostly redundant to dynamic variables, or make dynamic variables more complex. In your use-case, you could just put a dynamic variable space onto the slot itself to reference the fields dynamically. That's what I do in situations like those. There's also #3149, which would make dynvar linking faster and remove even more overhead, to the point of there pretty much not being any to worry about in practice. (Also the new runtime will probably also improve dynvar binding performance).

I do think the ability to access fields on components on slots dynamically would probably be better solved by component-level access (#57), that would provide a much more general and direct way to interact with any kind of data on a per-slot basis.

[5H4D0W-X]

Are you referring to the same issue that I reported yesterday? (https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/3148) If so, would fixing that (partially) fulfill your demand for this request?

I guess so, if the performance improvements from #3149 were also implemented. Since the first issue I presented was a bug that should be fixed anyway, my main focus was on performance. I wasn't aware that there is actually a simple way to improve linking performance by that much (O(n²) to O(n) would be huge), and if that is implemented, that kinda does make my request unnecessary

[LimeProgramming]

I want this.

Plug slot into a read and read the variables off of it. Similar to how it works with a tag but reading a variable by name with an isFound bool for filtering or whatever.