Dynamic Variable Store

[Hayden-Fluff]

While working on a project, I encountered a case I seem to encounter a lot, that case being that I often see value stores to drive the state of a Dynamic Variable. An example of this can be seen below

WriteLatch writing to a Data Model Store, which is then driving a DynamicValueVariable

This led me to the idea of having a generic variable store that is, in itself, a Dynamic Variable, allowing that store to be used where ever you would need within a given dyn var space without an additional component or slot and driver node.

The reason I haven't made this a feature request is because I was also thinking "well what if you want it to be a Local or Store, and not only implicitly synced with the data model"

My proposal is to have an extension to the existing Local, Store, and Data Model Store to make those readable by dynamic variables, and the way you'd interface with this is that the variable name would be whatever you put into the string input in the Store itself

This is my own concept, though I would like to hear what other people think, would this be a useful tool to have?

This would also mean that you would be able to directly interface with Dyn Vars with things like a write latch, or anything that can write to these variables.

An issue this also brings up is, if this does have dynamic variants for Local and Store, that would add a lot more options to the context menu used to create these variables, at least three additional options, which might make this menu too cluttered. This is also something I would like opinions on.

[Zyro1331]

I'd very much vouch for something like this, as I heavily utilize driven Dynamic Variables in many complex and interactive projects of mine.
A feature like this alone would greatly improve the simplicity of interfacing with Variables outside of ProtoFlux scripts, as well as more easily allow dynamic reading and writing variables from other ProtoFlux groups.

In my scenario, if I wanted to make something like a "DynamicVariableValueStore" to store some client-side value that could be read and written to by multiple ProtoFlux groups, I'd have to create a DynamicValueVariable component somewhere on my item and drive it with a ValueCopy pointing to itself with WriteBack enabled.

[Hayden-Fluff]

Upon talking with a few, I noticed that my wording might be a little confusing, so some clarification

The original idea was to just have a variable that is just a dynamic variable, which would function identically to the Dynamic Value/Object Variable components, and the variable would technically be on the node itself.

The reason I thought of this is that I commonly see variables that exist purely to drive a Dynamic Variable, and in the example above, I specifically wanted to use a WriteLatch to interface with a Dynamic Variable.

As for things beyond this, well that's why I made this discussion, I don't necessarily know what the implementation of something like this would look like (This could kind of be implemented with a mod that just hooks the value into a Dynamic Field, and the variable name is value copied from the slot name, but that's a mod idea for separate talk)

Here's my mock concept of this idea using what's available in the engine at the moment.

[Zyzyl]

This request seems to be asking for essentially the same functionality as #4113 would provide. Do you see any major differences that I'm missing?

[Hayden-Fluff]

This might actually be specifically what I'm looking for, but in thinking of how this would be interfaced with, I also found the idea of stores and locals that are dynamic interesting, though after talking with others, that may not fit in what dynamic variables are supposed to be (though I can list quite a few cases where dynamic variables are localized, even in official content, but that's a separate topic)

The discussion here would also allow for dynamic variables to be declared in the code directly instead of needing a separate dynamic variable component elsewhere, which might be weird, but in some cases I don't think it would be unwelcome.