Setup: Client Widget Button clicked to change player status → If has authority, multicast event to other clients telling them to update the status of that player, if not authority, call event on server to multicast.
I cannot figure out / understand why when the server changes status i does not multicast, and when a client does, i looks like only the server and one client receives multicast?
If your Server ist a dedicated, He can’t Spawn Widgets. OK I saw you don’t have a dedi. Set your Status variable to be replicated and Change it in a Server rpc, don’t use These multicasts rpc.
You don’t need to check for authority before making a RunOnServer event call. Also don’t use Macros when a function can do the job. Macros are only useful for making latent function calls or branching flow like the SwitchHasAuthority Macro. Macros are more expensive to use than functions and they can’t be called outside the class.
Now onto the real problem. All PlayerControllers exist on the server but each client only have their own PlayerController so when you call a Multicast event on a PlayerController only the Owner will get the RPC. Use GameState or PlayerState to replicate variables to every client.
No widgets are attempting to be spawned, all widgets are spawned by owning controller. I am avoiding replicated variables, these are no changed every tick so replicating seems like a waste and bad programming to me, and 'I am trying to master what I can with network replication early on, so was trying to accomplish this using only events. Why do you say to not use these multicasts?
hmmm, thank you so much for pointing out a macro is more expensive, I did not realize this. Great to know! Also great to know I do not need to check for authority when calling a run on server! Thank you for the added bonus
I was aware Player Controllers cannot see each other, but I was under the impression that only mattered if you were trying to have one player controller access variables from another player controller. I was not thinking there was a problem here since I was calling an event to run on server client, and then server client was multi-casting to other clients. And since at least one client was getting the multicast it seemed like it should work, as 'I would have expected nothing to go through if it wasnt, but instead one client would respond, and I did not think that client would since itself is no calling the event, but the server is. Been having a hard time grasping RPC’s and proper communication. I have watched Epic’s tutorial thing on network optimization (a good watch) and I remember him sayin that multicast rpc’s are bad, but I understood it as being bad if it is something that is being called often, as it is then better to have a replicated variable.
I am trying to stay away from replicating variables, as mentioned in comment above, as these variables would not change every tick, and also to help myself learn networking better.
Sending reliable RPC’s on tick will quickly turn into a pit of despair that is impossible to recover from. Unreliable RPC’s are not as unreliable as you might think unless if you have already filled up the buffer with Reliable RPC’s.
RPC’s are necessary for sending input from the clients to the server and if the input is sent rapidly it is pointless to make it reliable since if a packet is lost a new more recent package will be ready anyway. Some events should be reliable if intermediate values are important but this should never happen on tick.
Network states (replicated variable)
A network state is a persistent change that makes long term changes to the world. This could be a door is opened or an item is activated etc. When a client joins the game late or is reconnecting these replicated variables begins to update.
Network events unreliable
A network event is short term changes to the world that could be dropped without effecting the overall state. This could be creating sound or particle effects that disappear shortly after. Input events is also network events.
Network events reliable
These are slow events that rely on every bit of information being sent and add extra overhead on each RPC and should only be used when absolutely necessary. This could be important announcement messages from the server to the clients.
a replicated var is not replicated every tick if it is not changed - so it is not a waste. multicasts are not reliable by default and even if you tick the “reliable” box I had not so good experiences with it. but go the way GamerP57 wrote, he is right, this is your error with setting it in the PC which is not replicated to clients (except of owning). go with player state- it’s supposed for that. eg set a repl. var in playerState “state” and intereate through the states serverside eg in gamemmode to controll your lobby logic.
Network States (Replicated Variables) - System checks every replicated variable every tick if it has changed, and if has changed, send clients updated variable. On the optimization side, they have talked about making these initially dormant, if you know they will not need updated when initialized, and can do a force net update later to update them when needed and bring them out of dormancy; or changing update frequency or another form of dormancy (i forget). The force net update would be kind of like sending a reliable event? Such as the door would be best sent as a force net update to make sure the packet is not lost since it may not be changed for a period of time?
Reliable Events - As far as being slow and extra overhead, this is because the packets need to be sent, client needs to send confirmation back to server, and if not confirmed process is repeated until successful yes?
Network Events Unreliable - You mentioned input here? I am confused by this, (Unless it is input that is updated on tick, such as an axis input or something on a joystick such as for FPS character movement), what about types of input like my clicking the button to show ready status, or in an RTS game (which I would like to do later on) a client selects units, and gives those units a move command? Would not that move command need to be reliable (or a force net update, updating a movement vector variable in selected units) since it happens once? Then, the clients would update that variable and simulate the movement of the units until it receives another update? And is it better to send an event or to have a force net update on some sort of dormant replicated variable?
Also, I have noticed on replicated variables, there is another drop down for replicated condition an have not come across discussion on that in any of the tutorials or videos. Would you know some good sources on explanation of the options in that menu, and how/what they do?
Thank you so much!
Network relevancy combined with the relatively new Replication Graph helps to prevent unimportant properties from consuming a lot of resources.
Reliable Events have to be confirmed yes similar to TCP
User input is unpredictable. A simple button click made reliable could be abused by a user and suddenly what you thought was an infrequent event is now a very frequent event and because you made it reliable other unreliable events have to be sacrificed. It has to be a very important user input before I would make it reliable. Remember that unreliable is not that unreliable unless if you already messed up with reliable RPC’s somewhere.
Replication conditions is simply a filter that when used only updates specific clients. Very useful for saving bandwidth and CPU cycles.
They are not replicated every tick, but they are evaluated for change every tick (not really relevant for this scenario, but if you have 5,000 replicated variables…) Good to know you have not had reliable experience even with reliable multi-casts! Thanks for the tidbit!
Ahhh, yes, forgot to bring up that point, my friend is a key example hahaha, playing an RTS, he seems to think clicking 1k times a second giving his units move commands helps, and that was gonna be yet another question of mine is how does one handle controlling (limiting) user input like this? I would have no idea how to setup logic to detect multiple clicks like this, ignore all but last click and use that as input.
HA, thanks for reminder, I downloaded this a while ago, forgot I had it. Didn’t read it at the time cause I was learnign some other stuff. I was looking at his diagram of the overlapping circles, I redid my code and had the Button Widget call an event on the Gamestate (the ebvent on gamestate is set as run on server) and the gamestate calls a multicast where that multicast event gets the player controller, from player controller gets the player info widget, and then calls an update status event on the widget telling it to change it’s display state. I could not get this to work - is this because a widget would have to first go through its player controller to get access to gamestate? - ok, I know this seems stupid, but I am really just playing around tryin to get a master understanding of rpc’s and network replication. once i gt it working using rpc’s I will work on setting up properly using replicated variable
So, using RPC’s (which, is not really the recommended way of accomplishing this) I got it to work with this setup:
Client Widget Clicked → Calls Event (Run on Server) from it’s owning Player Controller (Passes Player Index (int) and Status (Enum) → Player Controller calls Event (Multicast) from GameState (Passes Player Index (int) and Status (Enum) → GameState calls Event (Run Owning Client) from Player Controller (Passes Player Index (int) and Status (Enum) → Player Controller calls Event (Run Owning Client) from Widget which the widget then updates the visual look of itself.
The less confusing way to explain for others: Widget comunicates with controller, controller communicates with gamestate, gamestate communicates with all controllers, those controllers tell their own widgets (which correspond to the correct player) to update.
Thanks to everyone for the info, advice etc. Greatly appreciated, and I now feel like I have a pretty solid understanding of this all. Will be doing a setup using PlayerState and replicated variables now
