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.