FRepLayout

Navigation

API > API/Runtime > API/Runtime/Engine

This class holds all replicated properties for a given type (either a UClass, UStruct, or UFunction). Helpers functions exist to read, write, and compare property state.

There is only one FRepLayout for a given type, meaning all instances of the type share the FRepState.

COMMANDS:

All Properties in a RepLayout are represented as Layout Commands. These commands dictate:

• What the underlying data type is.
• How the data is laid out in memory.
• How the data should be serialized.
• How the data should be compared (between instances of Objects, Structs, etc.).
• Whether or not the data should trigger notifications on change (RepNotifies).
• Whether or not the data is conditional (e.g. may be skipped when sending to some or all connections).

Commands are split into 2 main types: Parent Commands ( A Parent Command represents a Top Level Property of the type represented by an FRepLayout. A Child Command represents any Property (even nested properties).

E.G., Imagine an Object O, with 4 Properties, CA, DA, I, and S. CA is a fixed size C-Style array. This will generate 1 Parent Command and 1 Child Command for each element in the array. DA is a dynamic array (TArray). This will generate only 1 Parent Command and 1 Child Command, both referencing the array. Additionally, Child Commands will be added recursively for the element type of the array. S is a UStruct. All struct types generate 1 Parent Command for the Struct Property. Additionally: If the struct has a native NetSerialize method then it will generate 1 Child Command referencing the struct. If the struct has a native NetDeltaSerialize method then it will generate no Child Commands. All other structs will recursively generate Child Commands for each nested Net Property in the struct. Note, in this case there is no Child Command associated with the top level struct property. I is an integer (or other supported non-Struct type, or object reference). This will generate 1 Parent Command and 1 Child Command.

CHANGELISTS

Along with Layout Commands that describe the Properties in a type, RepLayout uses changelists to know what Properties have changed between frames. Changelists are arrays of Property Handles that describe what Properties have changed, however they don't track the actual values of the Properties.

Changelists can contain "sub-changelists" for arrays. Formally, they can be described as the following grammar: Terminator ::= 0 Handle ::= Integer between 1 ~ 65535 Number ::= Integer between 0 ~ 65535 Changelist ::= | | Array-Changelist: ::=

An important distinction is that Handles do not have a 1:1 mapping with RepLayoutCommands. Handles are 1-based (as opposed to 0-based), and track a relative command index within a single level of a changelist. Each Array Command, regardless of the number of child Commands it has, will only be count as a single handle in its owning changelist. Each time we recurse into an Array-Changelist, our handles restart at 1 for that "depth", and they correspond to the Commands associated with the Array's element type.

In order to generate Changelists, Layout Commands are sequentially applied that compare the values of an object's cached state to a object's current state. Any properties that are found to be different will have their handle written into the changelist. This means handles within a changelists are inherently ordered (with arrays inserted whose Handles are also ordered).

When we want to replicate properties for an object, merge together any outstanding changelists and then iterate over it using Layout Commands that serialize the necessary property data.

Receiving is very similar, except the Handles are baked into the serialized data so no explicit changelist is required. As each Handle is read, a Layout Command is applied that serializes the data from the network bunch and applies it to an object.

RETRIES AND RELIABLES

@FSendingRepState maintains a circular buffer that tracks recently sent Changelists (@FRepChangedHistory). These history items track the Changelist alongside the Packet ID that the bunches were sent in.

Once we receive ACKs for all associated packets, the history will be removed from the buffer. If NAKs are received for any of the packets, we will merge the changelist into the next set of properties we replicate.

If we receive no NAKs or ACKs for an extended period, to prevent overflows in the history buffer, we will merge the entire buffer into a single monolithic changelist which will be sent alongside the next set of properties.

In both cases of NAKs or no response, the merged changelists will be tracked in the latest history item alongside with other sent properties.

When "net.PartialBunchReliableThreshold" is non-zero and property data bunches are split into partial bunches above the threshold, we will not generate a history item. Instead, we will rely on the reliable bunch framework for resends and replication of the Object will be completely paused until the property bunches are acknowledged. However, this will not affect other history items since they are still unreliable.

Syntax

class FRepLayout :  
    public FGCObject ,  
    public TSharedFromThis< FRepLayout >  
Copy full snippet

class FRepLayout :     public FGCObject ,     public TSharedFromThis< FRepLayout >

Inheritance Hierarchy

• FGCObject → FRepLayout
• FSharedFromThisBase → TSharedFromThis → FRepLayout

Constructors

Destructors

Variables

Protected

Functions

Public

Overridden from FGCObject

Static

See Also

• FRepParentCmd) and Child Commands (

• FRepLayoutCmd).

• FRepChangedHistory.