These are the primitive types supported in a coherence schema:
Uses a default range of -2147483648 to 2147483647 (32 bits).
Uses the default range of 0 to 4294967295 (32 bits).
Uses the default range of -9223372036854775808 to 9223372036854775807 (64 bits).
Uses the default range of 0 to 18446744073709551615 (64 bits).
Encoded using one of the following compression types:
Higher precision floating point using 64 bits. It does not support compression.
Encoded using a single bit.
Encoded using two floats with a specified compression (defaults to
Encoded using three floats with a specified compression (defaults to
Encoded using three components and a sign bit.
Encoded using four components (RGBA).
A string with up to 63 bytes encoded using 6 bits for length.
An array of bytes with an upper limit of 511 bytes encoded using 9 bits for length.
Packet fragmentation is not supported yet in this version, so packets bigger than the internal MTU (~1200 bytes) may be never sent.
Entitytype is used to keep references to other Entities. Technically the reference is stored as a local index that has to be resolved to an actual Entity before usage. Also, since a Client might not know about the referenced Entity (due to it being outside of its LiveQuery) an Entity reference might be impossible to resolve in some circumstances. Your Client code will have to take this into account and be programmed in a defensive way that handles missing Entities gracefully.
Several of the primitive types can be configured to take up less space when sent over the network, see Field settings.
The most common definition in schemas is components, which correspond to replicated fields for baked MonoBehaviours.
The definition takes a name of the component, and on the following lines an indented list of member variables, each one followed by their primitive type (see above.) The indentation has to be exactly 2 spaces. Here's how it might look:
After code generation, this will give access to a component with the name
Portalthat has the members
Optionally, each member/type pair can have additional meta data listed on the same line, using the following syntax:
[key1 "value1", key2 "value", etc...]
This is how it might look in an actual example:
connectedTo Entity [prio "high"]
size Float [prio "low", bits "16"]
There are some components that are built into the Protocol Code Generator and that you will always have access to.
Archetypes are used to optimize the sending of data from the Server to each Client, lowering the precision or even turning off whole components based on the distance from the LiveQuery to a particular Entity. Read more about how to define them in the schema on the page Archetypes and LOD-ing.
Commands are defined very similarly to components, but they use the
Here's a simple example of a command:
command Damage [routing "AuthorityOnly"]
Routing defines to whom the command can be sent. Currently, two values are supported:
AuthorityOnly- command will be received only by the owner of the target Entity
All- command will be received by every Client that has a copy of this Entity
When using reflection, there are limitations to what types are supported in commands. See the Supported types in commands section for more information.
Inputs represent a group of values that are snapshotted every frame (or fixed frame). This snapshot is then sent to other clients or a session host, so it can be processed by the same code on both ends, resulting in the same outcome.
Example of an input:
XMov Vector2 [compression "None"]
YMov Vector2 [compression "None"]
Throttle Float [compression "None"]
Schemas have limits to protect the Replication Server. Ensure you stay within these limits:
- A single schema cannot have more than 10 million characters
- A component/command name cannot be more than 512 characters
- A field/archetype/input/enum name cannot be longer than 128 characters
- A component cannot have more than 128 fields