Drive: Difference between revisions

Latest revision as of 19:30, 17 February 2025

A drive continuously controls a property.

At a glance

A driven property will appear purple in the inspector window. The value of a driven property cannot be directly changed unless write back is enabled. Trying to write to a driven field without write back will have no effect, and even throw a warning to the resonite logs. A property can only have one drive on it at a time. See Field Linkage for more info about write back and hooking.

Locality

Driving a property is very different from writing to a property.

When you write to a property, you are telling everyone else in the session about the new value. This means that the write has to go across the network first. This can be especially problematic if you are writing a value very rapidly; this can result in significant jitter for other users. It can get even worse if multiple people are writing at the same time.

When you drive a property, you are telling the game to use another value to control it. This involves no network traffic, and thus doesn't depend on latency.

However, this can cause disagreement: each user is in control of their view of the property. If you plug Local User into User Username and drive a text field's content with the output, each user will see their own username.

This is often quite useful. However, this can also cause unwanted divergence: some ProtoFlux nodes, like Constant Lerp, are handled locally by each user. This can cause two people to disagree on the state of the world.

This is usually not a problem if the system you're using is inherently convergent. Constant Lerp trends steadily towards its target value; if everyone has the same target value, then everyone will eventually agree on the output.

Creating Drives

A very common way to create a drive is to use the ProtoFlux Tool to create a drive node. For more details, see the ProtoFlux page.

Many components can take a property to drive. ValueCopy reads from one property and drives another one with that value. Simply grab the name of the property you want to control and drop it in.

Write Backs

Write backs are a special property found on some components with varying names in the form of a Bool These booleans are just field hooks with a different name. See Field Hooks

(editor's note: not ready for translation yet; still making lots of changes!)

@@ Line 38: / Line 38: @@
 == Write Backs ==
-Write back is on components like [[Component:LinearMapper1D]], Linear mappers in general, [[Component:ValueCopy]], and [[Component:ReferenceCopy]] to name a few. Write backs are a special property that allows driven fields to respect attempted changes to it via protoflux writes, text editors, or inspectors. These write backs will write to the original value being used to drive the target field.
+Write backs are a special property found on some components with varying names in the form of a [[Type:Bool|Bool]] These booleans are just field hooks with a different name. See [[Field Linkage#Hooks|Field Hooks]]
-Write back for Components (like LinearMappers) which mutate their value as they copy from value A to B, will actually reverse the equation from B to A. This means if you write 10 to a value on a component (A) with writeback and the field it targets (B) becomes 20, writing the value 20 to B will make A automatically set to 10.
-This is useful for when you want to make 2 containers synchronize their capacity in terms of volume, or to synchronize sliders or visuals in a cross link fashion.
 <!--T:15-->
 (editor's note: not ready for translation yet; still making lots of changes!)