Great question actually, and pretty hard to explain in a simple manner.(of course you can just say it checks if your are on server or on client side, but it’s not that simple really.)
And if you spam authority check, it will get you no where and make it even more confusing.
I intended to write a wiki together with my working on a upgrade version of the Network_Features in ContentExamples, but maybe these following info would help you a bit.
So let’s separate into 3 sections, actor/movement component/variable replication being one, RPC call types as second, and what it means for authority as last.
And most important rule of all(as of writing) before we start, replication only happen from server to client.
-
Actor as a class has built in flag to let you tick to replicate or not, that make sure you are replicated to clients. It does nothing fancy really, but after initial replication(to create the actor on client), the rest is up to you.
Movement component can also be set to replicated, they will override your position and orientation at each update of engine that it appears to be syncing over network.
Most movement component are optimized by Epic, so use them when you can is your best option.
Now variable replication, from our “most important rule”, even if you check “replicated” and set the variable in “client side” blueprint, the change won’t propagate over, it only works from “server side” to “client side”.
Any actor that are replicated, have a copy on server, and a copy on client, who ever “owns” the pawn, ie the controller that possess the pawn, decides which copy of pawn they have direct controls over.In a sense, player controller represents you in UE4 frame work either you are on server or on client. That defines “owning” we are going to talk about later in RPC.
-
RPC calls, there are special event type we can do for RPC calls, where it be multicast, run on server, run on owning client.
These are no different than regular custom events with the exception that once it was called, base on it’s type, it will then distribute the event to the target machine you desired.
So if with no authority check, a multi cast event will be called, send info to server, and then run on every client connected(server included).
A run on server call will run from server side copy of the actor, and run on owning client call will run on who ever issues the event.
It would be more clear if Run on owning client could be called run on owning local machine, as server pawn can call this type of RPC and still run it no problem.The same deal with variable replication, “the most important rule” also applies here. Whatever RPC call type you setup doesn’t matter, the replication of call only happen from server to client.
Now Owning, in UE4 a player with input has a controller, that represents a possible “owner”, when ever gamemode lets you possess a certain pawn(there could be many in RTS) you are owner of that actor.
In Network feature level, there is a brief descript for the button press Epic logo spinning(1.5), says
This is important for respawn to happen and possess to be completed properly. Also when you plan your events, you have to keep these in mind, since if it’s not owned by a controller, server don’t know how to run these events.
-
Authority check and the role it plays. If you think carefully, and can understand whatever I said in 1 and 2, here is important part that completes the puzzle.
Any player has a controller, the source event(here using input event as they are more important) that triggers will only happen on the controlling machine.
Your button pressing only happen locally, so if you put authority check after a button pressing, it will always either pass for listen server, and fail(as remote) for all clients that connect to it.The moment you check has authority, doesn’t matter if it a tick event or anything, you filter out what can be run for all the rest of your graph that connects after it.
It’s pretty important as if you put a check right after say “InputAction FireMissile” event, a client will never be able to actually spawn a missile, no matter how hard you try.
But if you put it after the RPC “Run On Server” type of call, you ensure that whoever is calling this event(remember there are 2 copies of the same actor on server and client) is on server if you use the authority pin.
What’s the implication then?
It means RPC events aren’t as plain as they look on surface, they inherit some property of custom events, but they do something on the background so the basic 3 types are working.
But to make your game logic works fine, you have to filter it depending on situations, that’s why authority check isn’t just hide away inside nodes themselves.(you can argue that there are specific node that either only runs on server or client)
You have to actively choose what to happen and what not to happen if the event runs to this point of your graph.
Let’s have a example that I did with Network_Features, the signal poles(1.4 in first room) that use repnotify changes phase with a randomized green light period.
Original proper setup make sure server and client are seeing the same thing. If add a bool and let client run the phase, server side aren’t seeing properly signal poles.
And, if I remove the authority checks with another branch, server and client will see a off sync, as now that even with variable replication, client can still set phase changes and mess up timings.
Our “most important rule” applies, you saw a wacky signal pole that’s out of sync, replication and client event loop trying to set the vairables when it happens.
After these explanations, now try imagine this off sync happen on a much more complicated graph or interaction between blueprints.
That’s why I want to do a upgrade version of that level, I can learn from it, and everyone wish to study later on can benefit from it.
It’s definitely not a simple matter to tackle, even after read all this I bet there will be situations that are hard to resolve.
Then, here comes my 2nd important rule: Choose where you check authority wisely, avoid using remote pin when unless you know exactly what you are doing.
It might sound like a useless rule, but spamming it will cause things to stop working, while not using it make things off sync or like server pawn fire 2 projectiles at the same time on client, but are easiler to backtrack.
What about the latter part to avoid remote pin then? It is true with my test cases that with normal game logic, there are almost no situation that you want to do things on remote pin.
(ie, fair use of this would be detect if you are a server pawn or a client pawn, you only want to show something locally without everyone seeing it)
And that’s all I have to offer, hope you enjoy it.
Experiment and have your conclusion. 