When I play the game single player, everything works fine. But as soon as I switch over to multiplayer, certain Event Constructs stop running on the listen server, such as those for UI Blueprints. Clients on the other hand work the exact same as when I ran the game in single player. Is there a reason why or a fix for it? Also, if I have everything working for a single player, when I play in multiplayer, events that aren’t being replicated (such as executions from Event Constructs) should still work the exact same way right? Thanks for any insight in advance 
Hi, you might wanna work through some tutorials on UE and networking.
Constructs stop running on the listen
server, such as those for UI
Blueprints
The HUD and the UMG widgets only exist on the local client. The server won’t know about their widgets.
Also, if I have everything working for
a single player, when I play in
multiplayer, events that aren’t being
replicated (such as executions from
Event Constructs) should still work
the exact same way right?
That’s an it depends answer and I can’t put it in few enough words, if you understand page 8 to 10 of this here Multiplayer Network Compendium | An Unreal Engine Blog by Cedric Neukirchen you would at least have a partial answer.
Hey, thanks for your reply! But how would I have my listen server have his UI’s event construct run then? Would I have to instead make a custom event which is called instead?
Also, could you help me clarify where I should store certain variables and events? I’ve done some reading up about the game modes, game states, player states, player controllers and all (probably should have done this way earlier but… yeah) and I realised that all that I’ve done that works in my single player probably isn’t the best way for multiplayer. I basically have most of my player related things in my player character instead of it being spread between player controller and player state (which I’m still unsure of how it’s used).
I’m trying to make a game with a few game modes such as capture the flag and a battle royal. In which the characters have a few specialisations to choose from during the game that will alter their skills (such as mage, warrior, archer, basically like Fat Princess). So my understanding of the hierarchy of things is:
Game Instance: Has custom events for spawning widgets before the game (that aren’t part of the actual gameplay) such as menus and joining matches or creating matches.
Game Mode: The rules for the specific game mode, so capture the flag could have something like once objective has been held for 30seconds, the team wins. Respawning the players that have died back at their team base.
Game State: What is going on within the game, such as how long the objective has been held for already if it is being held at all, number of kills per team, who is winning or losing.
Player Controller: The HUD should be spawned from here. Selecting and spawning the skill the player has depending on what class he is (again, the mage, warrior, archer). His movements such has running and jumping.
Player Character: Variables such as hp, mp
Player State: Stores the max number of kills which the game state can refer to for most kills?
Thanks for any help in advance!
But how would I have my listen server
have his UI’s event construct run
then?
You can have UI on your listen server but it will be only local. If you want to replicate stuff from the UI you would need to do it from a blueprint that exists on both server and client (so maybe send an event to such a blueprint from the UI and do the replication there).
As for player controller, pawn, game mode,… what you want to do/save there depends. Some of those objects do not exist everywhere that would be one limitation and the other one would be better overview, so convenience.
Game Instance: Persists through level change. So everything you want to be remembered throughout changing levels would be here.
Game Mode: Only exists on the server. So this does not replicate. Makes cheating for the client harder.
Game State: Just something you can directly access from everywhere and exists on all clients, so does replicate. You can use it for better overview, or you can just use any other blueprint.
Player State: Same as Game State, so exists on all clients so does replicate. You can use it for better overview (so if you know that all player related stuff that all other players should know about is in here, that might be easier to maintain/expand).
Player Controller: Exists on the server and the owning client. So the server knows about all player controller, but each client only knows about one player controller (his own). Keep that in mind if you want to replicate things, so you cannot use things like multicast and replication only goes from server to owning client.
Player Pawn: Exists on all clients.
If you change your pawns, then the player controller persists. So you would do everything you want to be saved throughout pawn changes in the player controller.
And of course if you set an actor to replicate than it will exist on all clients.
Then there are some general things to consider:
Ownership: Clients can only call Run On Server events if they own that actor. So if several clients should be able to interact with an actor, then you would need to do that through the server. If only one client needs to interact with an actor (for example his weapon) then you can also set that client as owner.
Reliable: If you use up too much network bandwidth, then RPCs might get dropped. For RPCs that must come through (the game will break otherwise) mark them “reliable”. But keep in mind that they only get dropped once you have bandwidth problems, so don’t make everything reliable, only what absolutely needs to be.
Also you can call an RPC only twice per frame, so don’t do something like calling them during a for loop.
And try to replicate as less as possible and be careful when using RPCs, so try to save network bandwidth. So for example if you would have a bot that fires with a high frequency (rifle), it might be better to just send one event to the clients that the bot starts shooting and one event when he ends his shooting and do the logic on server and client instead of replicating each shot from the bot.
Thank you so much for your help! It is much appreciated
I’ve managed to run the executions in the UI via an event as you mentioned!
I have on more query regarding the bandwidth problems. I heard from a video (can’t remember which one) and it mentioned that instead of using RPC’s, a repnotify could be used instead which would not consume as much bandwidth? Is this true? Should I then try to convert things to repnotifies whenever possible? (Although I am aware they work differently in terms of how “current” the information is)
a repnotify could be used instead
which would not consume as much
bandwidth? Is this true?
I don’t know.
You might wanna read the last post from TheJamsh here
Most of the times you will be limited by design. If you do things that alter the game state you can’t use Multicast/Run On Owning Client. Cause
(1) In progress join
(2) Net Cull Distance. If you call a multicast on an object that is further away from the client than the Net Cull Distance, then the multicast won’t be executed there and the client will never know about this. If you would have used Replicated/RepNotify Variables, then as soon as the client gets closer than the Net Cull Distance the changes will be send to this client.
Then if you want to do one shots that must come through at this exact moment, you will need to use Multicast/Run On Owning Client.