As you already know, the Massiv divides all nodes into three groups: client nodes, simulation servers and data service nodes. Because data service nodes do not participate in the simulation, they can never be destination of replications or migrations, and will not be mentioned in the following sections.

Default replication flag constants distinguish two client node types: standard client and privileged client. The Core will support this distinction in the future, but currently it treats all client nodes as equal. When using recommended settings (see Section 7.5.4, “Recommended Node Replication Masks”), all client nodes are treated as privileged for replication purposes.

	Note
	This distinction is used only for replication purposes when choosing which properties should be replicated and which objects belong to a replication group, it does not add any special privileges to client nodes. You can still easily implement per-account privileges as can be seen in the Massiv Demo - only players with root accounts may directly edit the terrain and entities.

Property attribute repflags allows you to choose which properties of a managed object should be serialized when replicating the object to a node of given type. It can be assigned one of the values defined in Table 7.1, “Property replication flags”. The default value of the repflags attribute is REPLICATE - all properties are replicated to all node types by default.

Replication flags are specified for each property which is member of a managed object. If the property is a container property, its replication flags apply to both the container and the properties it holds.

	Note
	When replication protocol decides if a property should be replicated, it checks only the value of its repflags attribute, even if the property is a managed object or a container. For example, an array property with SERVER repflags would not be replicated to client nodes at all, even if it contained an object with properties with REPLICATE repflags.

The ptr_repflags property attribute of pointer properties is used to define replication and migration groups. Possible values are described in Table 7.2, “Pointer replication flags”. The default value of the ptr_repflags attribute is NONE for weak pointers and MIGRATE for strong pointers - weak pointers do not define a group by default, and strong pointers define a migration group by default.

Migration and replication groups in general are documented in Section 5.3.7, “Migration And Replication Groups”.

Warning

Strong pointers must always define at least a migration group. The IDL processor will automatically change default value (NONE) of ptr_repflags of simple strong pointer properties to REPLICATE (actually, value of another property attribute, strongptr_repflags, is used, but you should never override its default). However, if a strong pointer is stored inside a structural property (such as a pair or a container), ptr_repflags of the property must be set manually in the IDL.

Pointers contained within member objects and container properties of an object define migration/replication groups too. If a pointer is member property of a managed object, ptr_repflags specified in IDL of the corresponding class are used. If a pointer is a member of a non-object container property, ptr_repflags of the container are used. This means that it's impossible to mix pointers with different ptr_repflags in container properties (such as the pair, for example).

	Note
	It's possible for pointers to define a replication group even if their value is not replicated, if repflags is more restrictive than ptr_repflags. This feature is probably not very useful.

	Warning
	Be careful when mixing objects of different kind (described in Section 4.3.7, “Class Kinds”) in a group. Migration of object of unsupported kind will crash destination node, replication of object of unsupported kind and all objects replicated along the object will be ignored by destination node.

When interpreting values of repflags and ptr_repflags attributes, the Core compares them with replication masks for given node type.

The Core does not define any replication flags except the MIGRATE bit, other bits are defined in the IDL. Values described in previous sections document recommended flag values defined in src/core/object/object.idl and the Core does not know their values. Therefore default replication masks are pretty useless: when they are used, all properties are always replicated, and all pointers with the MIGRATE ptr_repflags bit set define both migration and replication group, no matter what the destination node type is.

To use flags defined in src/core/object/object.idl with meaning described in previous sections, override mask settings on each node to these values:

[ Settings/ObjectManagement/Replication ]
server_repflags_no : integer = 0
server_repflags_yes : integer = 3  

client_repflags_no : integer = 0
client_repflags_yes : integer = 5  

	These masks match iff MIGRATE and SERVER_BIT are set.
	These masks match iff MIGRATE and PRIVILEGED_CLIENT_BIT are set, i.e. all clients are privileged.

In the Massiv Demo, these settings are stored in a separate file, src/demo/config/common/massiv.replication.conf.

As already mentioned, the Core does not force you to use replication flag values defined in object.idl. To define custom flags, you must first understand how the Core interprets the flags.

Let's begin with few simple definitions:

It is said that replication flags match a replication mask, if all bits set in the yes-mask are set in the flags too, and no bits set in the no-mask are set in the flags. In other words, the yes-mask specifies which bits of the flags must be set in, and the no-mask specifies which bits of the flags must not be set.

Different replication masks are used for migration and replication, as described in Table 7.3, “Replication masks”. The Core uses the mask to enumerate migration or replication group - pointers with ptr_repflags attribute matching the mask define a group. When the Core migrates or replicates an object, only properties with repflags attribute that matches the mask are serialized.

To define custom replication flags, you must:

It's not recommended to override default replication flag values. It's even not very useful, because current version of Massiv uses only type of destination node to choose replication masks. This may change in the future.