Is the replication order guaranteed? (Rep_Notify) C++

Ivan3z · March 17, 2025, 9:04am

I just realized something

If I have two replicated variables (for example)

	UPROPERTY(ReplicatedUsing=OnVar1Change)
	uint8 Var1 = 0;

	UPROPERTY(ReplicatedUsing=OnVar2Change)
	uint8 Var2 = 0;

The variables are replicated in the same order as established in the function “GetLifetimeReplicatedProps” if they take new values in the same tick.

void UMyClass::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const
{
	Super::GetLifetimeReplicatedProps(OutLifetimeProps);	
	DOREPLIFETIME_CONDITION_NOTIFY( UMyClass, Var1,  ELifetimeCondition::COND_None,  ELifetimeRepNotifyCondition::REPNOTIFY_OnChanged);
	DOREPLIFETIME_CONDITION_NOTIFY( UMyClass, Var2,  ELifetimeCondition::COND_None,  ELifetimeRepNotifyCondition::REPNOTIFY_OnChanged);	
}

That is, even if the value of Var2 changes first and then Var1 (in the same tick):

Var2=1;
Var1=2;

The OnVar1Change() function is executed first on the client and then OnVar2Change() is executed.

I would like to know if I can trust this. Is the replication order guaranteed?
Or should I look for a logic that does not depend on the order of replication?

Because I could replicate one structure instead of the two separate variables, like this:

USTRUCT()
struct FVars
{
	GENERATED_BODY()
	
	UPROPERTY()
	uint8 Var1 = 0;

	UPROPERTY()
	uint8 Var2 = 0;
};

And

UPROPERTY(ReplicatedUsing=OnVarsChange)
FVars Var1 = 0;

But in this case I am replicating 16 bits even when I only need to replicate 8 bits.

So it’s a dilemma…

Thank you so much!!

Auran131 · March 17, 2025, 9:30am

i think this is the best course, i believe it only replicates whats changed anyway, like an array?

Ivan3z · March 17, 2025, 9:43am

I’m not sure how replication actually works… until now I thought that in the case of the structure all members (16 bits) would be replicated… And I thought the same in the case of an array…

But if it works like you say it really is a paradigm change for me. I was very concerned about inefficient use of the network.

Thank you very much for your help!!

Auran131 · March 17, 2025, 10:01am

im no expert either so another hero may jump in

but i can say i wouldnt worry about the efficiency of one small struct, especially when its OnRep as it’ll replicate when it can, not forced like a RPC

Ivan3z · March 17, 2025, 10:16am

In that case I am doubly worried.

Not only do I need it to send as few bits as possible (so as not to saturate the network), but I also need it to be as fast as possible.

One variable is the type of weapon.
The other variable is the amount of ammunition.

Sometimes I just need to check the ammo value.
Sometimes I just need to check the type of weapon.
And sometimes I need to check both things at the same time.

Maybe I need a more efficient replication method than Rep_Notify to do that.

Auran131 · March 17, 2025, 1:05pm

not really, checks should be done on server, the rep is just to display HUD info so its not urgent.

even if you’re doing some client side prediction or FX it wont break the game if they are wrong as long as the server is authoritative.

Ivan3z · March 17, 2025, 1:32pm

Yes, it’s for the “HUD”
It was important that the functions were executed in the correct order.
Suddenly it started malfunctioning when switching weapons (it used to work fine before).
The ammo from the previous weapon was displayed on the current weapon.
Then I realized that the values changed on the same tick and that the notifications were not being executed in the correct order.

You seem to be right. Only the members of the structure are replicated.

https://www.reddit.com/r/unrealengine/comments/3d1wfh/replication_of_structs_cant_get_a_confirmed_answer/?rdt=53346

However, I still have doubts about the bits that are sent over the network.

The socket is going to send a block of bytes (The size of the structure).
If you send fewer bytes the other members of the structure will end up with random values (garbage) or Zero value. And that’s in the best case because it could cause an exception and crash the program.

At least in my experience with sockets, when you send a structure over the network you must send a block of bytes the same size as the structure…

I can think of a way that if you send the structure in pieces, it then has to be recombined on the client side. But if they do it like this I would like to be sure. Everything that does not add up subtracts.

Auran131 · March 17, 2025, 1:38pm

that’s out of my league, BUT i really, really don’t think you need to worry about this. micromanaging performance at this level without a problem is gonna slow your production to a crawl.

Ivan3z · March 17, 2025, 1:50pm

I don’t really know… it’s a shooter game… There are eight players shooting very frequently.

The only thing I know is that it’s not good idea to overload the network.
That’s why I want to send as little data as possible.

I hope someone can solve this doubt.

If I really didn’t have to worry about that, that would be great… I would use the structure and not worry about the order of execution of the functions.

Auran131 · March 17, 2025, 1:58pm

you dont have to worry. remember RepNotify will only fire when its ready (network safe) yes this means the player gets a delayed HUD but thats what lag is, we’re all used to it.

that said if you fire 35 shots, it doesnt update 35 times. it updates once when its ready with a value between (x and 35) if that make sense.

or if it makes you feel better, lets say thats exactly how Lyra or even Fortnite would do it

Reliable RPCs are what could overload the network which is why you should use them sparingly

Ivan3z · March 17, 2025, 2:14pm

Well… in this case I feel calmer.

Now I have a new worry… the RPCs

I’ll check them to see how often they are executed.

I would like to find information about how replication works internally (I’ll look in the documentation)
I was lucky because you explained some things to me…
But I think I need to know everything about it.
So I will know exactly what to do in every situation.

Thank you very much for your help. @Auran131

Auran131 · March 17, 2025, 2:19pm

they are all unreliable so its fine, but that means they could be dropped/lost so unreliable is good for fast but non essential things like FX. (lets say a muzzle flash if you multicast that)

also things on tick since if you drop 1 tick no big deal, you’ll get the next. ie say movement input.

Only use reliable for absolutely essential things that would break the game if missed.

Ivan3z · March 17, 2025, 2:40pm

That’s the kind of thing I need to know.

I’ve been searching the documentation for a while and I still haven’t found it.
Looks like this is going to take longer than I thought.

Thank you so much @Auran131

Rev0verDrive · March 17, 2025, 9:41pm

The order of Variables/RPC’s in a packet has no bearing on the processing order of them. No order is guaranteed in any processing outside of Actor Tick Grouping.

There are no guarantees of receival on any data marked unreliable (no resends). Yet, Reliable just means you’ll get it at some point (resend)… even if that means it’s irrelevant by the time you do get it.

e.g. Resend (value: B), Next update server tick (value: D)

The first replication of a struct is the entire struct and current values. Subsequent replications are only the values that have changed (Network/Bandwidth && Processing Optimization). These sends will not include a zero/nulled structure. That would defeat the purpose of only sending the changed values. Struct designation and value.

Grouping “Like && Action Specific” replicated variables together in a struct is always a good approach.

Replicated variables should not require ordered sequential processing. Look at combining them into a single variable representing 2 or more sub states. Enumeration is a good option here.

4 States in a single Enum

If you need the individual values…

HUD based variables, Health, Score, Ammo etc, should be RepNotify.

Client-side prediction approaches to data can be helpful. For example you fire a shot and deduct ammo locally to maintain your UI and current states of things. The servers update will “clean up” any mishaps.

Keep in mind there’s no guarantee the server will receive your Shot RPC. Regardless, the next shot it does execute will correct the owning client.

Packets are processed and sent on tick start.

A packet received on Tick 100 will be processed at Tick 101 start, and any outbound response (RPC, replicated var) will be sent on Tick 102.

e.g. You fire a shot and RPC the server to shoot.

Tick 100 RPC is received.
Tick 101 it’s processed, Shot Fired and Multicast Called. Server executes the MC logic.
Tick 102 The multicast is sent to clients.

Ivan3z · March 18, 2025, 2:24am

HI @Rev0verDrive
Thank you so much for explaining this to me.