As you can see i am spawning a replicated actor called “SymbolPassword” from another replicated actor with switch has authority. But in SymbolPassword the MS multicast event doesnt run in the clients. Eventhough the MS is multicast and reliable. How can i solve this ?
Client has to exist in order to receive RPC’s.
Loading order is server loads level. Level creates Game mode and Game State. Game mode then spawns and possess pawn for each connection. Pawns are replicated over along with what level to load to each connected client.
Client receives packet, starts loading level and spawns pawn.
Note !!! In most cases (99%), the Pawn will be spawned on clients before the level is sufficiently loaded.
Thank you. I’ve realized that multicast events doesn’t work on EventBeginPlay most of the time since they dont exist at that time. Is there a way to trigger those events after the clients entered the game and they all exist instead of calling them in EventBeginPlay ?
You will need to create a “ready” state that reports back to either game mode or game state. When all have reported back call a multicast event.
depending on your goal you can always use repnotifey too which is also more efficient than multicasts
You’d have to loop through the player array to set a rep_notify on each. If you have 10 players that’s 10 values in the replication packet. Multicast would be 1 RPC call on each owning client.
huh? you just set it on server and it’ll only replicate when it can, RPC especially reliable ones can cause client desync
There’s always desync in multiplayer. Even on LAN there’s ping variance, then game and render thread variance. Rep_notify variable won’t mitigate desync.
Op is trying to execute logic when the player has loaded. Special event. In order for the server to know when a client has loaded you need the client to tell the server it’s ready.
Ops other constraint is one and done. One RPC call to handle all clients. Thus multicast.
Rep_notify requires the creation of a variable and a function that will persist. Thus is bloat. A dispatcher call to the server is a one and done per client. You can even unbind it when done. Once all are ready the server can fire a single event that executes logic on every client. No loops, no passing variables etc. The packet will have a simple event call in it.
Replicated variables should always be used when changing a state in the game rather than using a Multicast RPC since RPC can and will desync while OnRep variables are reliably replicated.
The only downside to replicated variables is that intermediate changes might be dropped but this is also what makes variables that change often much more lightweight than RPC’s.
Multicast RPC’s should only be used if you are doing an instant action like playing a sound or animation or notification that only matters right when it happened.
Say I wanted to load a special UI on all clients. Yet, only when all clients are ready. This is a one time event and will never happen again. Initialized from the server.
Would you still use Rep_Notify or would you instead look at Event Dispatcher or Multicast (Reliable)?
If I’m doing character cosmetics, door states, health, ammo, score etc… Rep notify all day, every day without a second thought.
RPC’s that are called when a client is having connection issues and reconnecting will be dropped even if reliable and since a client can have issues at any moment I would probably use a variable unless if the UI is not important later on.
I’m fully aware of network issues will result in a chance the multicast is not received on lossy clients.
I’m looking at an approach to have all clients load specialized functionality etc in a one off call from the server (passing specialized info). Info is the same for all clients.
Doing it with Rep_notify adds a variable and a function to the character class. Variable will also be added to replication graph and checked every pass.
For giggles lets say the specialized info is a row name from a data table. The OnRep function would look up the row and add an Actor Component to the character class, then set a reference. That’s it. From there onward the row name has zero value. The variable will never be updated again, nor the function run again.
Using rep_notify here would require the server to loop all players and set the rep_notify for each. 100 players = 100 iterations of the loop, 100 vars replicated out to every client (gotta keep them sims updated). Then role checks etc added to the onrep function to ensure only the client-side autonomous executes the logic.
At that point wouldn’t it be better bandwidth and net saturation wise to build a polling function using component reference validation as control for row request?
You can always use net dormancy or the push model to prevent the constant checks when you want to optimize.
dont get me wrong either would work in this situation but like Garner said i only use RPC for effects like sounds etc which also dont need to be reliable and you can drop them safely without effecting the game.
in this particular case i dont see why you couldnt just use the beginplay since this will only run on client when the client is loaded anyway. in my experience variables are replicated before client begin play is called so everything should be set to go, although i havent tested that extensively.
i think the real question is what are you trying to multicast and why?
Because the server is firing an event before the pawn exists on the client. That’s the whole point of the client notifying the server that it is ready. Not all load in fast. Varying hardware/software, background services, apps etc.
Look at Battlefield for example. Pre-round all clients have to ready up before the game start countdown starts ticking. Thus each client has to call the server to notify it. When all have readied up, the server fires back an event to start the countdown.
i was referring to the client begin play not the server begin play which will obviously fire when loaded on the client.
but again this depends on what the OP is trying to achieve
In Ops post he’s firing a multicast on the server, but some clients aren’t receiving it because the pawn doesn’t exist yet.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
