What is the actual meaning of "Authority"?

[Chumble]

Lately I’ve been having some issues with the networking aspects of the unreal engine and I think quite a bit of it boils down to a faulty understanding as to what “Authority” means. My background is in Java programming and my networking experience has been with programming a client and server separately. When I was dealing with networking then, the setup was as follows

1. Client presses a movement key. Checks locally to see if they would collide. If not…
2. Move client locally, then…
3. Send a message to the Server to say the Client is moving.
4. Server gets message, checks collision, and responds with “Ok to move” (or “Move invalid, go back to x,y”)
5. Client gets message from server, either “OK” or “Go back”, processes it.

Ok, so there’s a very obvious distinction between client and server. They don’t even run the same code, so it’s really hard to confuse them.

In the Unreal Engine 4, if I go and set the number of players to “2” and don’t check off “Dedicated”, one of the clients that gets loaded is a listen server client. So… it’s a client that is basically acting as the server, the authority for the game being run. If “Dedicated” was checked, both clients would simply be clients. This is all well and good.

Now my questions begin. When is the appropriate time to use the “Authority” switch? I’ve been told, “Whenever anything imperative to the gameplay is being calculated or processed”. Makes sense that the server should approve all game changes. Character movement is a pretty important aspect of gameplay. The server should be the one to say “Yes, the player can move here”. However, if you throw that switch between a movement input event and a “Add movement input” to a character, making sure that it has authority, your client will not move (even with replication enabled in the Defaults tab). In this case, it sounds more like “Only the server can move”.

So really, what does it mean to have authority? If I don’t use the authority switch, it all seems to work fine. But I’m not really sure why. What is happening under the hood when I press “W” and my character moves forward, looking correct from both a client and server standpoint? If I have “Replication” checked, I would think that means that the movement result propagates to all clients. Does only the server look at the replication flag? Because it seems to me that without the authority switch, both the server and client are running that movement input, both will see the replication flag.

I would really appreciate some insight on this.
Thanks

[PenguinTD]

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.

1. 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.

2. 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

Server and Client replication functions can only be used on actors that have a “Net Owner”. Actor have net owners if they are a player controller or owned by a player controller.

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.

3. 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.

[Wolfsblut]

Great post by Penquin so far.

I would recommend that you go for a dedicated server first so you never get these one-client-works-the-other-not issues - In my opinion today you do not need an authority check at all with a dedicated server, well, at least if you build a rts like game.

The second most important thing for me was to understand what-is-allowed-to-do-what-and-where regarding replication calls and that is written in the documentation very clear in 1-4 or 5 paragraphs. These boil down to one important information that I overlooked for quite a view days: only the pawn the Player POSSES and the Player can only posses one pawn at a time!

That is your Player-Representation normally, the default player pawn. So every rpc-call has to be made from here. Otherwise you have to posses-before-call and that is in my point of view not a good way to go. I’m still trying to make a rts style game, well kind of, but I guess you will run into the same issues if you build a first or third person game too.

For every networking game you build you need one pawn a client posses. Even if you don’t actually use it within the game at all.

[PenguinTD]

Controller

It’s possible to possess multiple pawn, but would probably require a new class of controller implement in C++. I think the community RTS implemented with a proxy control.(ie. player possess a camera/status pawn, and this pawn have an array of selected objects).

You can also call RPC directly from playercontroller, my respawn wiki uses exactly this approach.

[Chumble]

Wow, thank you guys so much for the detailed information… it’s a lot to absorb and I may need to read through this a few more times to understand it better,

Can we go over a simple example using your “InputAction FireMissile”? What is the actual flow of events?

Client presses a button and the character’s FireMissile event is executed. At this time, it is done only on the client, server doesn’t even know about it, right? So if FireMissile is a custom event, you can enable Multicast on it so that it runs on both the initiating client and server. The event itself could just spawn a projectile with an initial velocity.

Ok, so now both the client and server have run the same event, spawning this projectile. If I ensure that the spawned actor is replicated, Epic’s built-in movement replication will handle this correctly across all clients?

At this point, this is how I see it -
Initiating client and Server both run their own version of the code, they each spawn their own projectile. But since the projectile is set to replicate, will the initiating client spawn two projectiles?

If the above is correct, would it make more sense to have the “FireMissile” event only “Run on server”? The server will execute the event then spawn the projectile that replicates to everyone.

If I can simply tell an event to only run on the server, do I need to worry about authority at all? If the client is told to run “FireMissile” which is set to “Run on server”, wont it just stop there?

I realize I’m asking a lot of questions, hopefully not too many. I will continue to play with this to get a better understanding.

Thanks

[Wolfsblut]

@PenguinTD;143761

You can also call RPC directly from playercontroller, my respawn wiki uses exactly this approach.

Cheers, I never even tried. The playercontroller is an actor and the client possesses this actor by default, that makes sense and perfect fits to the “Requirements” in the documentation: https://docs.unrealengine.com/latest/INT/Gameplay/Networking/Replication/RPCs/index.html

I’ll would love to see the controller being extended to possess more than one actor at a time.

I actually mark all actors with a certain player id (I use the onClicked Event a lot), the array-solution is also fine, another solution is to simply derive all actors into different actors for each player.

[PenguinTD]

@Wolfsblut, Thanks for the link, I’ll put it into my signature links. It helps to confirm observations and to continue work on the network features upgrade.

@Chumble, The input events(any event actually started with InputAction/InputAxis or say InputTouch) can’t be set to RPC, just like EventTick won’t be RPC. If you think about it, all the events are generated from source of either input or periodical events like tick. You may already understand this, but I want to just clear this out of way first. Now come to my example.

“InputAction FireMissile” could be a binding to LMB, that has a place in your pawn blueprint. A RPC called “FireMissileOnServer” is set to RunOnServer. Every instance of this blueprint pawn will have those event available.

1. So when “InputAction FireMissile” triggered on client, yes, Server don’t know about it.(I won’t make it too confusing to bring in more details for now.)

2. When you run a Multicast event from client, from my test cases, you can call it successfully, but it does not sent to server.(Read the link Wolfsblut posted)

3. If you run multicast on spawn a projectile(assume that it’s replicated) from a server pawn, your client will see 2 projectiles from that server pawn.
   The reason being that on server, the server pawn spawn a missile and gets replicated to client. But on client, the server pawn’s replication gets that multicast RPC so on it spawn a missile again on client.

4. yes, server spawned actors that have proper movement components and are setup to replicate properly will be replicated to clients.

5. no, client will spawn projectile but multicast can’t go from client to server, so server saw nothing and client have a missile running on it’s own. See 3. for server calling multicast.

6. Yes, that’s actually the only sensible way to do it properly. RunOnServer and let the projectile to replicated itself over all clients.

7. I did the test, authority check or not after the RPC event RunOnServer doesn’t seems to affect result, plus the doc link Wolfsblut provided, it is running only on server.
   So no authority check after that RunOnServer event node is okay. When client call a RunOnServer RPC, if you own the actor, your call will make it to the server.

Edit:

I think this is a good example for consideration.
Multicast situation from client, the example from Network features aren’t exactly good to demonstrate multicast from client as when you step on the trigger button, it’s the replicated server pawn that also triggered the server side button. And it’s a level object, so it doesn’t even count. Bad example actually.

Now a real world situation would be like, say I want to spawn a particle effects, I don’t want it to be a replicated actor like missiles to increase network traffic, just some thing that position and timing won’t be gaming important.(like post victory celebration fireworks by pawns.) What you would have to do is to still have a RunOnServer RPC, that calls a Multicast event on Server, so every client including server will spawn that particle effects.