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; trying to do so will have no effect. A property can only have one drive on it at a time.
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.
(editor's note: not ready for translation yet; still making lots of changes!)