Myogestic.Remote.SetControlRequest
VHI_godot¶
Myogestic.Remote¶
SetControlRequest Class¶
public sealed class SetControlRequest : Google.Protobuf.IMessage<Myogestic.Remote.SetControlRequest>, Google.Protobuf.IMessage, System.IEquatable<Myogestic.Remote.SetControlRequest>, Google.Protobuf.IDeepCloneable<Myogestic.Remote.SetControlRequest>, Google.Protobuf.IBufferMessage
Inheritance System.Object → SetControlRequest
Implements Google.Protobuf.IMessage<SetControlRequest>, Google.Protobuf.IMessage, System.IEquatable<SetControlRequest>, Google.Protobuf.IDeepCloneable<SetControlRequest>, Google.Protobuf.IBufferMessage
Properties¶
SetControlRequest.Continuous Property¶
Continuous DOF values by control address. Each must be finite and inside the range declared for it.
Property Value¶
Google.Protobuf.Collections.MapField<System.String,System.Single>
SetControlRequest.Discrete Property¶
Discrete DOF states by control address. Each must be one of that DOF's declared states. Kept separate from continuous on purpose: a held state and a number are not the same kind of command.
The key is the address the manifest published, exactly as for continuous — not the client's own alias for the control, which the target has never seen and could not interpret. So a target resolves the *control* from the key and the *state* from the value: in the Virtual Hand, for instance, the states are the movement names it currently offers, matched case-insensitively. Resolving on the state alone cannot tell two discrete controls apart that happen to share a state name.
An address this target does not export, and a state that control does not declare, are both refused by address in ControlAck.rejected — so a client never has to guess whether "fist" means anything here, or which control it meant.
Property Value¶
Google.Protobuf.Collections.MapField<System.String,System.String>