User:Yosh/sandbox: Difference between revisions

← Older edit

VisualWikitext

Latest revision as of 17:35, 12 September 2025

asdhasd

@@ Line 1: / Line 1: @@
-'''Dynamic variables''', commonly shorted to '''dyn vars''' or '''dynvars''', is a system of data storage wherein one can store arbitrary, scoped data under slot hierarchies with arbitrary names, akin to that of an [https://en.wikipedia.org/wiki/Associative_array associative array]. Their usage is usually found in large systems with many moving parts, but can nonetheless be useful as easy "global" values that can be changed on an object.
+{{stub|nocat}}
-For a quick-start guide on using dynamic variables, the [[How To Use Dynamic Variables]] page serves to be a how-to.
+asdhasd
-== Overview ==
-Dynamic variables are managed with two parts: ''dynamic variable spaces'' and ''dynamic variables''. Dynamic variables live under a dynamic variable space, and can be created, modified, and destroyed dynamically.
-=== Variable Spaces ===
-By adding a [[Component:DynamicVariableSpace|DynamicVariableSpace]] to a slot, the slot and all of its children become a part of the named variable space. A slot can be part of multiple spaces at once. Spaces are <em>not</em> nested, meaning it is advised to make unique names for variable spaces.
-=== Dynamic Variables ===
-To create a dynamic variable, attach any one of the following components to a slot:
-* [[Component:DynamicValueVariable|DynamicValueVariable]], for working with [[Type:IValue`1|IValue]] types ([[Type:int|int]], [[Type:string|string]], [[Type:float3|float3]], etc.).
-* [[Component:DynamicReferenceVariable|DynamicReferenceVariable]], for working with [[Type:SyncRef`1|Reference]] types ([[Type:Slot|Slot]], [[Type:User|User]], etc.).
-* [[Component:DynamicTypeVariable|DynamicTypeVariable]], for working with the [[Type:Type|Type]] type.
-Dynamic variables have a name and a value. A variable's name is its unique identifier within the variable space, while its value is the value of the dynamic variable. This is touched on later in [[#Binding]].
-=== Dynamic Fields ===
-It is possible to "transform" an existing [[Type:IField|IField]] on a component into a dynamic variable. This is done by any one of the following components:
-* [[Component:DynamicField|DynamicField]], for working with IValue types.
-* [[Component:DynamicReference|DynamicReference]], for working with Reference types.
-Upon attaching the component and dragging the field you want to convert into <code>TargetField</code>, the pointed field can then be interfaced with like any other dynamic variable.
-=== Naming Restrictions ===
-The names of dynamic variables and dynamic variable spaces must not contain symbols, punctuation, or whitespace, <em>except</em> for period (<code>.</code>), underscore (<code>_</code>), and space (<code> </code>). To check if a character is unable to be used in a dynamic variable name, one can use the [[ProtoFlux:Is Symbol|Is Symbol]], [[ProtoFlux:Is Punctuation|Is Punctuation]], and [[ProtoFlux:Is White Space|Is White Space]] ProtoFlux nodes, taking care of the three exceptions above.
-== Binding ==
-The process of a dynamic variable being associated with a given space is called ''binding''. A dynamic variable component will traverse up the slot heirarchy, including its current slot, looking for an applicable variable space to bind to. If a dynamic variable does not find a dynamic variable space that it can bind to, it will not be accessible outside of the component itself, essentially reducing to a glorified [[Component:ValueField|ValueField]]. A dynamic variable will go through this binding process every time any part of the component changes.
-=== Direct Vs Indirect Binding ===
-When making a dynamic variable, the <code>VariableName</code> of a dynamic variable component can be one of the following two forms: <code>VariableName</code> or <code>VariableSpaceName/VariableName</code>. The former represents ''indirect binding'', while the latter represents ''direct binding''.
-If a dynamic variable is indirectly binding, it will bind to the first dynamic variable space that does not have <code>OnlyDirectBinding</code> set to <code>True</code>. If a dynamic variable is directly binding, it will bind to the first dynamic variable space that matches <code>VariableSpaceName</code>.
-For example, in the following setup:
- └─ Foo - Variable Space "test"
-    └─ Bar - Variable Space "test2"
-       └─ Baz - Dynamic Variable "test/var"
-The dynamic variable <code>test/var</code> will bind to the variable space <code>test</code>. If the variable was instead named <code>var</code>, it will bind to the variable space <code>test2</code>.
-=== Warning ===
-As of the time of writing, there exist a few instances where created variables do not instantly bind/rebind to a dynamic variable space, requiring a [[ProtoFlux:Delay Updates|Delay Updates]] of 2+ updates. These include [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1394 creating new dynamic reference variables], [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2717 deleting dynamic variables], changing the name of a dynamic variable or dynamic variable space, and any instance where there is a dynamic variable space change without a component update, such as [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1690 duplicating slots containing a dynamic variable space] or reparenting a slot containing a dynamic variable under a new dynamic variable space. If you find your dynamic variables to be behaving weirdly, try adding a delay of 2 or more updates between such operations.
-== Interfacing ==
-=== Reading Dynvars ===
-In ProtoFlux, the [[ProtoFlux:Read Dynamic Variable|Read Dynamic Variable]] node and [[ProtoFlux:Dynamic Variable Input|Dynamic Variable Input]] nodes exist to read dynamic variables from a slot. The former node is marked as [[ContinuouslyChanging]], which is a performance downgrade if <code>Source</code> and <code>Path</code> are constant. As such, if the dynamic variable and the space it is under are constant, the Dynamic Variable Input node is preferred. The slot that it pulls its space pool from is the node's current slot, and it only updates its value when needed, saving performance.
-It is also possible to read dynamic variables by sourcing the <code>Value</code> or <code>Reference</code> field of the component directly. This is not recommended, as if the dynamic variable ever gets deleted and remade, the source will break, removing half the functionality of a dynamic variable.
-=== Driving from Dynvars ===
-By using a [[Component:DynamicValueVariableDriver|DynamicValueVariableDriver]] or [[Component:DynamicReferenceVariableDriver|DynamicReferenceVariableDriver]] component, you can drive fields using a dynamic variable. This is recommended over traditional methods of driving by virtue of its flexibility and compactness.
-=== Writing to Dynvars ===
-Dynamic variables should be written to via the [[ProtoFlux:Write Dynamic Variable|Write Dynamic Variable]] or [[ProtoFlux:Write Or Create Dynamic Variable|Write Or Create Dynamic Variable]] ProtoFlux nodes.
-If dynamic variables are written to via sourcing the component field and writing, it will incur a delay of 1 frame before the value is propagated to any read nodes. As such, it is not recommended to use this approach.
-=== Driving Dynvars ===
-Driving dynamic variables must be done with caution. For one, one must drive the value field of the dynamic variable component, which incurs a delay of the value when reading it back via ProtoFlux due to drives acting as a local write every frame. Additionally, if a dynamic variable is being driven, it is <em>crucial</em> that <em>all</em> instances of the same dynamic variable are driven by the same value. Otherwise, clients will fight over which value is the "true" value of the dynamic variable and cause inconsistent behavior.
-== Best Practices ==
-Even though dynamic variables allow for a wide array of freedom, there are a few practices generally considered to be favorable when working with dynamic variables:
-* It is highly recommended to have only one instance of a dynamic variable (dynamic variable component with the same name) at any given time.
-** There aren't any huge problems with having multiple dynamic variable instances if none or all of the instances are being driven, but it allows for cleaner organization of variables.
-* Using variable names that directly bind allows for a clearer overview of what space the variables should be bound to. Indirectly binding variable names are more suited for variables that are dynamically created and/or destroyed as part of an object's function.
-** Using <code>OnlyDirectBinding</code> on a DynamicVariableSpace strictly enforces this behavior, which can prevent misbindings and catch errors earlier.
-* Dynamic variable spaces are not nested. If a system is complex enough, or if a DynamicVariableSpace is being shared by multiple objects, using periods (<code>.</code>) to pseudo-isolate objects or systems from one another is encouraged.
-== Default Spaces ==
-As of the time of writing, there are three dynamic spaces that exist by default:
-* <code>World</code>, which exists under the [[Root]] of the world. This space is <code>OnlyDirectBinding</code>.
-** Useful for things that should globally affect the world or broadcast information throughout the world. Example items that use this space include [[BeatLink]] and the [[Redprint]] manager.
-* <code>User</code>, which exists under every [[User]]'s [[ProtoFlux:Get User Root Slot|User Root Slot]]. This space is <code>OnlyDirectBinding</code>.
-** Useful for systems that affect avatars, as they can rely on a standardized space being available for each user to read and write variables on.
-* <code>Dash</code>, which exists under the slot containing the [[Component:UserspaceRadiantDash|UserspaceRadiantDash]] in userspace.
-== Example Usage ==