DOREPLIFETIME for all replicated variables?

Hey all,

I’m trying to put together a replicated UObject (to represent an item slot in an object-based inventory system) that is primarily manipulated on the Server, but the clients need to be aware of most of the UObject’s properties.

What I’m having a hard time with is finding the best way to replicate variables. I do the following:

Declare the variables and mark them as replicated in the .h file:

public:
	UPROPERTY(Replicated, BlueprintReadWrite, Category = "Item Info")
	FText Name;
	UPROPERTY(Replicated, BlueprintReadWrite, Category = "Item Info")
	UTexture2D* Icon;
	UPROPERTY(Replicated, BlueprintReadWrite, Category = "Item Info")
	int MaxCount;
	UPROPERTY(Replicated, BlueprintReadWrite, Category = "Item Info")

On the .cpp file, I write the following in GetLifetimeReplicatedProps

void UItemObj::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
	DOREPLIFETIME_CONDITION(UItemObj, ComponentOwnerPrivate, COND_InitialOnly);
	DOREPLIFETIME(UItemObj, ItemID);
	DOREPLIFETIME(UItemObj, Count);

	DOREPLIFETIME(UItemObj, Name);
	DOREPLIFETIME(UItemObj, Icon);
}

Of course, any variable not registered for replication in this function are given a warning:

LogClass: Warning: Property ItemObj::MaxCount (SourceClass: ItemObj) was not registered in GetLifetimeReplicatedProps. This property will not be replicated. Use DISABLE_REPLICATED_PROPERTY if not replicating was intentional.

There two issues I see with placing every variable in GetLifetimeReplicatedProps.

  1. What happens to variables in child classes, especially in BP ones (since I intend to open this up to BP)? I feel like I would be loosing flexibility here if I had to manually code that in.
  2. If I have to write a separate DOREPLIFETIME() line for every variable I mark as replicated, I’m worried the code might be too heavy

Is there a better way to register all replication-mark variables?

I appreciate any help. I’m mostly new to trying to wrap my head around networking on C++

1 Like

In answer to your first point - Child classes, including blueprints, are responsible for their own variables. I don’t believe you lose any flexibility as I can’t really think of a situation in which you’d have a replicated variable in a parent which you’d want to change the replication behaviour of.

Second point - No need to worry about the code being too heavy, you’re doing the right thing. The macros are simply the way of choosing (as you have done in your example), the method by which the variable will replicate.

2 Likes

Got it.

Thank you for clarifying!