1. The Big Picture

Everything in Resonite is a synchronized data model. There is no "game logic" separate from data — the world is the data, and changes propagate automatically across all users.

Key insight: A Resonite world is a tree of Slots. Each Slot holds a list of Components. Each Component has typed Members (fields). That's the entire architecture.
ConceptAnalogyWhat it holds
WorldScene fileOne root slot tree + users + settings
SlotGameObject / TransformPosition, rotation, scale, active flag, child slots, components
ComponentMonoBehaviourTyped members (fields) specific to its purpose
Member / FieldSerialized fieldA single typed value: float, string, reference, etc.

2. Workers & Sync Elements

Under the hood, Resonite's data model is built on Workers — objects that participate in the synchronization system.

Worker

Base class for anything that lives in the data model. Has a unique persistent ID. Slots, Components, and Users are all Workers.

Sync Element

The atomic unit of synchronization. Every field on a component (like Position on a Slot, or Size on a BoxMesh) is a Sync Element. When it changes, the change is replicated to all users.

Users are Workers too. Every user in a session is a full Worker with their own slot hierarchy under the world root, marked by a UserRoot component. That hierarchy contains the user's avatar, head, hands, controllers, locomotion modules, audio streams, and a User dynamic variable space. User components work like any other — they have Sync Elements, can be driven, and are inspectable. Per-user state (like IK, dynamic bones, or user-specific UI) is typically achieved through driven fields, which are computed locally on each client rather than synced over the network.

Change Propagation

When you modify a Sync Element:

  1. The local value updates immediately
  2. A change event fires locally (drivers, ProtoFlux nodes react)
  3. The change is queued for network replication
  4. Remote clients receive and apply the change
  5. Remote change events fire on those clients

3. Value Types vs Reference Types

This is the most important distinction in Resonite's type system. It determines which components and ProtoFlux nodes you use.

The dual-nature gotcha: string and Uri are value types in FrooxEngine's data model — they use ValueField<T>, DynamicValueVariable<T>, etc. However, in ProtoFlux they are object types — use ObjectWrite<string> and ObjectValueSource<string>, not ValueWrite<string>. See wiki: Value Types.
Value Types (structs)Reference Types (classes)
bool, int, long, float, double
float2, float3, float4, floatQ
colorX, enums, string, Uri 		Slot, User, Grabber
IButton, IGrabbable
IAssetProvider<T> (materials, textures, etc.)
Stored inline in memory Stored as a pointer/reference
ValueField<T> ReferenceField<T>
ValueWrite<T> ObjectWrite<T>
ValueSource<T> ObjectValueSource<T>
DynamicValueVariable<T> DynamicReferenceVariable<T>

4. Data Container Components

Resonite has many components that "store data," each serving a different purpose and scope.

Pure Storage

The simplest containers. A single typed value or reference, no naming, no hierarchy.

ValueField<T>

Stores a single value type. The most basic container. Used by drivers, ProtoFlux, and internal component wiring.

[FrooxEngine]FrooxEngine.ValueField<bool>
ReferenceField<T>

Stores a reference to another object (slot, component, asset). The reference-type equivalent of ValueField.

[FrooxEngine]FrooxEngine.ReferenceField<Slot>
Not purely passive: ValueField and ReferenceField have a built-in proxy mechanism — dropping a slot with one of these components onto an inspector input field will source its value into that field. If you need truly inert storage with no inspector side-effects, use ValueTag<T> / ReferenceTag<T> instead.

Named Variables (Dynamic Variables)

Named, scoped data accessible anywhere within a DynamicVariableSpace. Resonite's primary inter-component communication system.

DynamicVariableSpace

Defines a namespace scope. All DVVs under this slot (in the hierarchy) with matching space name share a namespace.

[FrooxEngine]FrooxEngine.DynamicVariableSpace
DynamicValueVariable<T>

A named value variable within a space. Has VariableName (string) and Value fields. The workhorse of Resonite data binding.

[FrooxEngine]FrooxEngine.DynamicValueVariable<string>
DynamicReferenceVariable<T>

Same as DVV but for reference types. Stores a reference to a slot, component, or asset by name.

[FrooxEngine]FrooxEngine.DynamicReferenceVariable<Slot>

Drivers

Components that continuously drive (overwrite) a target field's value. The target shows a purple indicator when driven.

ValueDriver<T>

Drives a single target field from a source value. One-to-one.

[FrooxEngine]FrooxEngine.ValueDriver<float>
ValueMultiDriver<T>

Drives multiple target fields from one source. One-to-many.

[FrooxEngine]FrooxEngine.ValueMultiDriver<float>
ValueCopy<T>

Copies a source field's value to a target field each frame. Like a driver but from an existing field rather than a constant.

[FrooxEngine]FrooxEngine.ValueCopy<float3>

ProtoFlux Bridge Components

These live on ProtoFlux node slots and bridge between the component data model and ProtoFlux's execution graph.

GlobalReference<T>

A reference from ProtoFlux to a component field. Points to a specific IValue/IField (see Interface Types). Must be manually created when using the API.

[FrooxEngine]FrooxEngine.ProtoFlux.GlobalReference<...>
GlobalValue<T>

A constant value exposed to ProtoFlux. Unlike GlobalReference, it stores the value directly rather than pointing to another field.

[FrooxEngine]FrooxEngine.ProtoFlux.GlobalValue<string>
ValueSource<T> / ObjectValueSource<T>

ProtoFlux node that reads a value/reference from the data model. Outputs to other PF nodes.

[ProtoFluxBindings]...CoreNodes.ValueSource<float3>
ValueWrite<T> / ObjectWrite<T>

ProtoFlux node that writes a value back into the data model. Triggered by an impulse.

[ProtoFluxBindings]...Nodes.ValueWrite<...>
StoredValue<T> / StoredObject<T>

ProtoFlux-local storage. Persists a value within the PF graph without writing to the data model. Useful for state machines.

[ProtoFluxBindings]...Nodes.StoredValue<float2>

Cloud Variables

Persistent variables stored on Resonite's cloud servers. Survive world restarts and can be shared across worlds.

CloudValueVariable<T>

Reads/writes a cloud variable defined in user or group settings. Value persists across sessions.

[FrooxEngine]FrooxEngine.CloudValueVariable<string>
ActiveUserCloudValueVariable<T>

Like CloudValueVariable but automatically scoped to the active user (the user interacting with it).

[FrooxEngine]FrooxEngine.ActiveUserCloudValueVariable<bool>
ValueDriver.ValueSource vs ValueSource<T> node. ValueDriver.ValueSource is a member field on the ValueDriver component — you point it at a field ID (e.g. DVV.Value). ValueSource<T> is a separate ProtoFlux node that reads values into a graph via a GlobalReference bridge. Same name, completely different things.

5. Interface Types

Interfaces are abstract contracts describing capabilities of fields and components. They're the type constraints that determine what you can wire to what. You never create an IValue<T> directly — you create a DynamicValueVariable<T> whose .Value field happens to implement IValue<T>.

Interface Hierarchy

flowchart TD IF["IField<T>
Most general — any typed field"] IV["IValue<T>
Readable typed value (subset of IField)"] IGVP["IGlobalValueProxy<T>
ProtoFlux bridge proxy"] DVV_V["DVV<T>.Value"] VF_V["ValueField<T>.Value"] GR["GlobalReference<T>"] IF -->|"subset"| IV IV -->|"wrapped by"| IGVP DVV_V -.->|"implements"| IV VF_V -.->|"implements"| IV GR -.->|"implements"| IGVP style IF fill:#2a2a1a,stroke:#FFEB3B,color:#fff style IV fill:#1a472a,stroke:#4CAF50,color:#fff style IGVP fill:#472a1a,stroke:#FF9800,color:#fff style DVV_V fill:#1a472a,stroke:#4CAF50,color:#fff style VF_V fill:#1a472a,stroke:#4CAF50,color:#fff style GR fill:#471a2a,stroke:#E91E63,color:#fff

Core Field Interfaces

InterfaceWhat It MeansImplemented ByExpected By
IField<T> Any typed field on any component. Most general. Every member field ValueDriver.DriveTarget, ValueCopy.Source/Target
IValue<T> A readable typed value. Subset of IField. DVV.Value, ValueField.Value, most typed members ValueDriver.ValueSource, GlobalReference.Reference
IGlobalValueProxy<T> ProtoFlux bridge proxy — wraps IValue for PF nodes. GlobalReference<T> ValueSource.Source, ObjectValueSource.Source, event node inputs
Practical rule: When a field says "expects IValue<T>", drop any .Value field from a DVV or ValueField of matching type T. When it says "expects IField<T>", any typed field from any component works.

Reference-Type Interfaces

These interfaces constrain reference-type fields — you'll see them on ProtoFlux event nodes and interaction components.

InterfaceWhat It ConstrainsCommon Concrete Type
IButtonClickable buttonTouchButton, UIX Button
IGrabbableGrabbable objectGrabbable component
IAssetProvider<T>Asset provider of type TPBS_Metallic (Material), StaticTexture2D (Texture), StaticAudioClip (AudioClip)

What Goes in GlobalReference<T>?

The generic parameter of GlobalReference determines what it can point at and which ProtoFlux nodes use it.

GlobalReference<...>Points AtUsed By PF Node
GlobalReference<IValue<float>>DVV<float>.Value, ValueField<float>.ValueValueSource<float>.Source
GlobalReference<IValue<string>>DVV<string>.ValueObjectValueSource<string>.Source
GlobalReference<IButton>TouchButton, Button componentButtonEvents.Button
GlobalReference<IGrabbable>Grabbable componentOnGrabbableGrabbed.Grabbable
GlobalReference<IAssetProvider<AudioClip>>StaticAudioClip componentPlayOneShot.Clip
GlobalReference<Slot>Any Slot referenceElementSource<Slot>.Source
API type string gotcha: GlobalReference generic parameters use full assembly-qualified names: GlobalReference<[FrooxEngine]FrooxEngine.IValue<float>>, not shorthand. See §13 API Reference.

6. Proxies

"Proxy" is an overloaded term in Resonite. Several component families use the name, each serving a different role. They all share the idea of indirection — standing in for something else — but they operate in different contexts.

Proxy Families

FamilyComponentsPurpose
ProtoFlux Data Proxies GlobalReference<T>, GlobalValue<T> Bridge between ProtoFlux nodes and the component data model. The most important proxies for data flow.
Inspector / Grab Proxies ValueProxy<T>, ReferenceProxy, AssetProxy<T>, DelegateProxy<T> Make grabbable objects act as values, references, or assets for the in-game inspector's drag-and-drop system.
Lifecycle Proxies DestroyProxy, SaveProxy Redirect destroy or save operations to a different target slot.
ProtoFlux Internal Proxies MethodProxy, FunctionProxy, AsyncMethodProxy, ProtoFluxRefProxy, ProtoFluxGlobalRefProxy, ProtoFluxReferenceProxy, FieldDriveBase+Proxy, ReferenceDrive+Proxy, … Internal ProtoFlux node machinery (thousands of variants). Not user-facing. Includes nested +Proxy classes that drive nodes create on target slots.
What does +Proxy mean? In .NET, the + symbol denotes a nested class. FieldDriveBase<T>+Proxy is a Proxy class nested inside FieldDriveBase<T>. ProtoFlux drive nodes (like FieldDrive, ReferenceDrive, PlaybackDrive) use these nested proxy components internally — they get placed on the target slot to perform the actual drive operation.

The rest of this section focuses on ProtoFlux Data Proxies, since they are central to understanding how data flows through the system.

ProtoFlux Data Proxies

Why they exist: ProtoFlux runs in its own execution context, separate from the component data model. It needs a standardized interface to read and write fields. Data proxy components provide that bridge — a stable, typed connection point that ProtoFlux nodes can reference.
graph LR CF["Component Field
(e.g. DVV.Value)"] -->|"reference"| PC["Data Proxy
(GlobalReference / GlobalValue)"] PC -->|"read / write"| CF PC -->|"source / variable"| PF["ProtoFlux Node
(ValueSource / ValueWrite)"] PF -->|"write back"| PC style CF fill:#2a5a3a,stroke:#4ec9b0,color:#fff style PC fill:#4a3a6a,stroke:#c586c0,color:#fff style PF fill:#3a4a6a,stroke:#569cd6,color:#fff

GlobalReference<T> vs GlobalValue<T>

GlobalReference<T>

Points to an existing field. A "window" into the data model. This is the most common data proxy — it doesn't store data itself, it references data that lives elsewhere.

Example: A GlobalReference<IValue<float>> pointing at a DVV<float>'s Value field lets a ValueSource<float> node read that DVV.

GlobalValue<T>

Stores its own constant value. A "constant" exposed to ProtoFlux. No external reference needed — the value lives directly on this component.

Example: A GlobalValue<float> set to 9.81 provides a gravity constant that any ProtoFlux node can read.

IGlobalValueProxy<T> interface: Both GlobalReference<T> and GlobalValue<T> implement IGlobalValueProxy<T>. ProtoFlux node inputs (like ValueSource.Source) expect this interface, which is why either data proxy type can satisfy them.
GlobalReference<T>GlobalValue<T>
StoresA pointer to another fieldIts own value
Use whenReading/writing dynamic data (DVVs, ValueFields, Grabbables, Buttons)Providing a constant to ProtoFlux
Common withValueSource, ObjectValueSource, ValueWrite, ObjectWrite, ButtonEvents, OnGrabbableGrabbedAny PF node needing a fixed input

8. ProtoFlux & the Data Model

ProtoFlux is Resonite's visual programming system. It operates in its own execution context but reads from and writes to the component data model via bridge components.

sequenceDiagram participant F as Component Field participant GR as GlobalReference participant VS as ValueSource Node participant PF as ProtoFlux Graph Note over F,PF: Reading a value INTO ProtoFlux F->>GR: Reference points to field GR->>VS: Source reads from GlobalRef VS->>PF: Output feeds PF graph Note over F,PF: Writing a value FROM ProtoFlux PF->>PF: ValueWrite node receives impulse PF->>GR: Variable points to GlobalRef GR->>F: Writes value to component field
API Gotcha: When you add a ProtoFlux node via the API (addComponent), Resonite does NOT auto-create the companion GlobalReference component. You must manually add it and wire the reference. The in-game node browser does this automatically, but the API doesn't.

The Bridge Pattern

Every ProtoFlux node that reads/writes the data model follows the same pattern:

  1. A GlobalReference<T> component on the node's slot points to a target field
  2. The PF node has a member (e.g. Source, Variable) that references the GlobalReference
  3. At runtime, the node reads/writes through the GlobalReference to the actual field

9. Data Flow Patterns

Common wiring patterns you'll encounter and create in Resonite.

Pattern 1: DVV → Driver → UI

A DynamicValueVariable drives a UI text element. Change the DVV value, and the text updates automatically.

flowchart LR DVV["DynamicValueVariable<string>
VariableName: 'score'
Value: '42'"] VD["ValueDriver<string>
Source: DVV.Value"] TXT["Text Component
Content (driven)"] DVV -->|"Value field"| VD VD -->|"drives"| TXT style DVV fill:#1a472a,stroke:#4CAF50 style VD fill:#2a1a47,stroke:#9C27B0 style TXT fill:#1a2a47,stroke:#42A5F5

Pattern 2: DVV → GlobalRef → ProtoFlux Read

ProtoFlux reads a DynamicValueVariable through a GlobalReference bridge.

flowchart LR DVV["DynamicValueVariable<string>
Value field"] GR["GlobalReference<IValue<string>>
Reference → DVV.Value"] OVS["ObjectValueSource<string>
Source → GlobalRef"] PF["Rest of
ProtoFlux Graph"] DVV -.->|"field ID"| GR GR -->|"provides"| OVS OVS -->|"output"| PF style DVV fill:#1a472a,stroke:#4CAF50 style GR fill:#472a1a,stroke:#FF9800 style OVS fill:#471a2a,stroke:#E91E63 style PF fill:#1a2a47,stroke:#42A5F5

Pattern 3: ProtoFlux → Write → DVV

ProtoFlux writes a computed value back to a DynamicValueVariable.

flowchart LR PF["ProtoFlux
Computation"] OW["ObjectWrite<string>
Variable → GlobalRef"] GR["GlobalReference<IValue<string>>
Reference → DVV.Value"] DVV["DynamicValueVariable<string>
Value updated"] PF -->|"impulse + value"| OW OW -->|"writes via"| GR GR -.->|"targets"| DVV style PF fill:#1a2a47,stroke:#42A5F5 style OW fill:#471a2a,stroke:#E91E63 style GR fill:#472a1a,stroke:#FF9800 style DVV fill:#1a472a,stroke:#4CAF50
Remember: string is a value type in FrooxEngine but an object type in ProtoFlux — use ObjectWrite<string> (not ValueWrite<string>) in ProtoFlux. Use ValueWrite for float, bool, int, etc.

10. Wiring Guide

The previous sections describe what each component is. This section explains how to wire them in the Resonite inspector — what goes in those null fields and what to drag where.

Fields Are the Unit of Reference

The #1 conceptual hurdle: References point to fields (members), not components or slots. You're wiring field-to-field, not component-to-component.

Every field on every component has a unique internal ID used by the data model. When you wire a ValueDriver's ValueSource to a DVV's Value, you're pointing at that specific field — not at the DVV component as a whole.

This means you can wire any field of the correct type to any compatible target, regardless of which component it lives on.

Inspector Color Coding

Field highlight colors tell you what's controlling a field:

ColorMeaningEditable?
White (none)Normal, locally set valueYes
Cyan / TealLinked (ValueCopy, network-synced)No
PurpleDriven (ValueDriver, local compute)No

The small circles (○) next to each field in the inspector are reference handles — grab-and-drop targets. Drag from one ○ and drop onto another to create a reference.

ValueDriver<T> — Step by Step

flowchart LR SRC["Source Field
e.g. DVV.Value"] VD_SRC["ValueDriver.ValueSource
expects IValue<T>"] VD_TGT["ValueDriver.DriveTarget
expects IField<T>"] TGT["Target Field
e.g. Text.Content"] SRC -->|"drag ○ → drop"| VD_SRC VD_TGT -->|"drag ○ → drop"| TGT style SRC fill:#1a472a,stroke:#4CAF50,color:#fff style VD_SRC fill:#2a1a47,stroke:#9C27B0,color:#fff style VD_TGT fill:#2a1a47,stroke:#9C27B0,color:#fff style TGT fill:#1a2a47,stroke:#42A5F5,color:#fff
  1. Attach ValueDriver<T> to any slot
  2. ValueSource field: grab the ○ next to the source field (e.g. DVV's Value) and drop it here — expects IValue<T> (see §5)
  3. DriveTarget field: grab the ○ next to the target field (e.g. Text's Content) and drop it here — expects IField<T> (see §5)
  4. The target field turns purple = it's now driven

Common sources for ValueSource: DynamicValueVariable.Value, ValueField.Value, any typed member on any component.

ValueMultiDriver<T> — One to Many

Same as ValueDriver, but DriveTarget is a list. Each entry drives a different target field. Useful for broadcasting one value (e.g. a color) to many receivers.

  1. Set ValueSource to the single source field
  2. Add entries to the DriveTarget list — each entry takes a ○ reference to a target field
  3. All targets turn purple

ValueCopy<T> vs ValueDriver<T>

ValueCopyValueDriver
Source field typeAnother existing field (IField<T>)IValue<T> interface
Result colorCyan link (synced, saved)Purple drive (local, not saved)
Network syncYes — value replicated to all usersNo — each client computes independently
Use whenYou want the value synced to all usersYou want local computation
Key insight: ValueCopy produces a link, ValueDriver produces a drive. Choose based on whether you need network sync.

ProtoFlux Wiring — The GlobalReference Bridge

ProtoFlux nodes don't reference data fields directly. They go through a GlobalReference on the same slot.

Reading a Value into ProtoFlux

flowchart LR DVV_VAL["DVV.Value
(the actual data)"] GR_REF["GlobalReference.Reference
drag DVV.Value ○ here"] VS_SRC["ValueSource.Source
→ points to GlobalRef comp"] PF["ProtoFlux Graph
receives value"] DVV_VAL -->|"drag ○ → drop"| GR_REF GR_REF -.->|"provides"| VS_SRC VS_SRC -->|"output"| PF style DVV_VAL fill:#1a472a,stroke:#4CAF50,color:#fff style GR_REF fill:#472a1a,stroke:#FF9800,color:#fff style VS_SRC fill:#471a2a,stroke:#E91E63,color:#fff style PF fill:#1a2a47,stroke:#42A5F5,color:#fff
  1. The ProtoFlux node (e.g. ValueSource) has a Source field
  2. That field expects a GlobalReference on the same slot
  3. The GlobalReference's Reference field points to the actual data field (e.g. DVV.Value)
  4. In the inspector: drag DVV.Value's ○ → drop onto GlobalReference.Reference

Writing from ProtoFlux

flowchart RL PF["ProtoFlux Graph
impulse + value"] OW_VAR["ObjectWrite.Variable
→ points to GlobalRef comp"] GR_REF2["GlobalReference.Reference
drag DVV.Value ○ here"] DVV_VAL2["DVV.Value
(receives written data)"] PF -->|"impulse"| OW_VAR OW_VAR -.->|"writes via"| GR_REF2 GR_REF2 -->|"drag ○ → drop"| DVV_VAL2 style PF fill:#1a2a47,stroke:#42A5F5,color:#fff style OW_VAR fill:#471a2a,stroke:#E91E63,color:#fff style GR_REF2 fill:#472a1a,stroke:#FF9800,color:#fff style DVV_VAL2 fill:#1a472a,stroke:#4CAF50,color:#fff
  1. The ProtoFlux node (e.g. ObjectWrite) has a Variable field (not "Target"!)
  2. Wire Variable → GlobalReference on same slot
  3. Wire GlobalReference.Reference → target field (e.g. DVV.Value)

Quick Reference: What to Drop in Each "null" Field

ComponentFieldWhat to Drop HereTarget Turns…
ValueDriver<T>ValueSourceAny field of type T (○ handle)—
ValueDriver<T>DriveTargetThe field you want drivenPurple
ValueMultiDriver<T>DriveTarget [n]Each field you want drivenPurple
ValueCopy<T>SourceAny field of type T—
ValueCopy<T>TargetThe field you want linkedCyan
GlobalReference<T>ReferenceThe data model field to bridge—
ValueSource<T> (PF)SourceGlobalReference on same slot—
ObjectWrite<T> (PF)VariableGlobalReference on same slot—

11. Which Component Do I Need?

Use this flowchart to find the right data component for your use case.

flowchart TD START["I need to store/access data"] --> Q1{"Does it need a
name for lookup?"} Q1 -->|"Yes"| Q2{"Scope?"} Q1 -->|"No"| Q3{"Purpose?"} Q2 -->|"Within a slot subtree"| DVV["DynamicValueVariable
or DynamicReferenceVariable
+ DynamicVariableSpace"] Q2 -->|"Across worlds/sessions"| CLOUD["CloudValueVariable
Persistent, cloud-stored"] Q3 -->|"Simple field storage"| Q4{"Value or Reference type?"} Q3 -->|"Drive another field"| Q5{"One target or many?"} Q3 -->|"Bridge to ProtoFlux"| Q6{"Read or Write?"} Q3 -->|"PF-local state"| STORED["StoredValue / StoredObject
Lives in PF graph only"] Q4 -->|"Value (bool, float, string, etc.)"| VF["ValueField<T>"] Q4 -->|"Reference (Slot, User, etc.)"| RF["ReferenceField<T>"] Q5 -->|"One"| VDRIVER["ValueDriver<T>"] Q5 -->|"Many"| VMDRIVER["ValueMultiDriver<T>"] Q6 -->|"Read from data model"| Q7{"Value or Reference type?"} Q6 -->|"Write to data model"| Q8{"Value or Reference type?"} Q7 -->|"Value"| VSRC["ValueSource<T>
+ GlobalReference"] Q7 -->|"Reference"| OVSRC["ObjectValueSource<T>
+ GlobalReference"] Q8 -->|"Value"| VW["ValueWrite<T>
+ GlobalReference"] Q8 -->|"Reference"| OW["ObjectWrite<T>
+ GlobalReference"] style START fill:#1a2a47,stroke:#42A5F5,color:#fff style DVV fill:#1a472a,stroke:#4CAF50,color:#fff style CLOUD fill:#1a3a4a,stroke:#00BCD4,color:#fff style VF fill:#2a2a1a,stroke:#FFEB3B,color:#fff style RF fill:#2a2a1a,stroke:#FFEB3B,color:#fff style VDRIVER fill:#2a1a47,stroke:#9C27B0,color:#fff style VMDRIVER fill:#2a1a47,stroke:#9C27B0,color:#fff style VSRC fill:#471a2a,stroke:#E91E63,color:#fff style OVSRC fill:#471a2a,stroke:#E91E63,color:#fff style VW fill:#47331a,stroke:#FF9800,color:#fff style OW fill:#47331a,stroke:#FF9800,color:#fff style STORED fill:#333,stroke:#999,color:#fff

12. .NET Naming Conventions

Resonite is built on .NET (C#). Component type strings follow .NET assembly-qualified naming, but with a Resonite-specific format.

Anatomy of a Type String

[FrooxEngine]
FrooxEngine.
DynamicValueVariable
<string>
Assembly Namespace Class Name Generic Argument

Assembly Prefixes

PrefixContainsExamples
[FrooxEngine] Core engine components, UIX, materials, data types BoxMesh, Canvas, PBS_Metallic, DynamicValueVariable
[ProtoFluxBindings] ProtoFlux execution nodes ButtonEvents, ValueWrite, SetLocalPosition

Generic Syntax Rules

Important: Use the Resonite angle-bracket syntax, NOT CLR backtick notation.
Correct (Resonite)Wrong (CLR)
DynamicValueVariable<string>DynamicValueVariable`1[System.String]
ValueField<float3>ValueField`1[BaseX.float3]
ValueField<bool>ValueField`1[System.Boolean]

Common Generic Type Arguments

bool int long float double float2 float3 float4 floatQ colorX string Uri Slot User

value = value type   ref = reference type

Note: string and Uri are value types in FrooxEngine but object types in ProtoFlux (use ObjectWrite, not ValueWrite).

13. API Quick Reference

Member $type Formats

When updating component members via the API, values must include a $type discriminator.

$typeShapeExample
bool{ $type, value }{ "$type": "bool", "value": true }
int{ $type, value }{ "$type": "int", "value": 42 }
float{ $type, value }{ "$type": "float", "value": 0.5 }
string{ $type, value }{ "$type": "string", "value": "hello" }
float2{ $type, value: {x,y} }{ "$type": "float2", "value": { "x": 1, "y": 2 } }
float3{ $type, value: {x,y,z} }{ "$type": "float3", "value": { "x": 1, "y": 2, "z": 3 } }
floatQ{ $type, value: {x,y,z,w} }{ "$type": "floatQ", "value": { "x": 0, "y": 0, "z": 0, "w": 1 } }
colorX{ $type, value: {r,g,b,a,profile?} }{ "$type": "colorX", "value": { "r": 1, "g": 0, "b": 0, "a": 1 } }
enum{ $type, value, enumType }{ "$type": "enum", "value": "Alpha", "enumType": "BlendMode" }
reference{ $type, targetId }{ "$type": "reference", "targetId": "Reso_12345" }

Component Type Strings by Category

UIX Components
Materials
Meshes
Rendering
Interaction
Data & Variables
ProtoFlux Nodes

Common Gotchas

List members (e.g. MeshRenderer.Materials) do NOT support dot-notation access. Materials.0 fails. Use the list assignment pattern instead.
string and Uri are value types in FrooxEngine (ValueField, DynamicValueVariable) but object types in ProtoFlux (ObjectWrite, ObjectValueSource). Don't look for ValueWrite<string> in ProtoFlux — it doesn't exist.
GlobalReference not auto-created. When adding ProtoFlux nodes via API, you must manually add the GlobalReference<T> companion component and wire it.
ObjectWrite.Variable — the member is called Variable, not Target.

External Resources

Official and community references covering topics discussed in this guide:

Official Resonite Wiki