I don't understand Switch Has Authority

I’m new to replication. I watch some replication tutorials, and some people use Switch Has Authority and other’s just use events. I’m confused. What’s the point of it? I used to think the authority was the server and remote was the clients. Yet now I’m hearing the clients can have authority too. If this is the case it seems pointless.

So my main concern is when should I use Switch has Authority and when should I not use it when dealing with replication? Thanks!

Tutorials aren’t worth a sht dude, not in this area (HasAuthority often ends up being overused / misused).
In practice, you will often have to use it in conjunction with **IsServer **or IsLocallyControlled plus others.:wink:

This is my understanding of how it works. But as I warned you in the other thread, Multiplayer is a mindf**k!
Example: If Client2 spawns an object it will exist on Client2 only and Client2 will have sole network authority.
On a Listen-Server setup Client2/Client3 etc will have no authority over Server Client1’s actors whatsoever.
But the Server Client1 will have authority over Client2 / Client3 objects as they were spawned on the server!

So unlike a Dedicated-Server, Listen-Server HasAuthority is not always a safe indicator of Server vs. Client!
Its often more useful as an indicator of ownership or who created an actor than anything else, so its misused.

Tutorials and Docs should not be teaching stuff this way as its misleading, yet that’s Epic’s own docs for you!
The best thing is just experiment and try things in small practical projects as that really helps. Forget tutorials!

So, if I’m understanding you correctly. Switch Has Authority isn’t very useful for a listen server set up, which is what I’m using. The server will ultimately have control and that’s why it doesn’t matter if I route clients through the authority branch. The system will still treat them as clients and override them using the server’s standards. For a beginner, Switch appears misleading. Unless I’m dealing with determining ownership, or more advanced stuff, I should just stick with events.

You mentioned Is Locally Controlled, this is another term I see tossed around. Some times in tutorials I’ll see conditionals of them on Begin Play. In my situation of using a Listen Server set up, when should I use or avoid these? Up till now, I would just add them or take them out on whim hoping I’d get a lucky configuration which would work. Yet if they are not necessary for my purposes, I don’t want to waste my time with them.

I agree. I’m starting to get frustrated on the replication tutorials. After a while, they all start saying the same thing. Many are a bunch of intro tutorials which go over the same general knowledge. Instead of hearing for the 1,000th time that the server is in control, it would be nice knowing which replication methods are effective in different situations. For example, understanding why they use a multicast event and server event vs just using a server event. Maybe its just me, but I’d rather not have the general knowledge. I just want the method. I’ve found its easier to learn the general concepts after I’ve experimented with lots of different methods.

I rarely consult Unreal documentation. Its too terse and technical. If I had access to a ton of replication code examples, that would be very beneficial. That’s basically what I do now for replication vids. I just skip to their code and see if there is anything new I could apply to my own situation. Do you have any recommendations of any good sources for info on Unreal replication?

I appreciate your patience. I’ve always struggled with puzzles. They give me headaches lol. Replication is a lot like puzzles. Its not easy. I’m just gonna keep banging away at it until I get it.

When I get a chance, I’ll respond to your other comment on my other post. I definitely appreciate the guidance!

Not quite… What I’m saying is, you have to be careful using HasAuthority on a ListenServer and remember to use a combo of IsServer / IsLocallyControlled along with HasAuthority. If you combine NOT-IsServer into your logic you can rule out the Listen-Server branch executing something you need the owning Client to be doing. Same goes for IsLocallyControlled. You’ll just have to play around with these in different scenarios using on-screen Print-String tests to discover all the subtleties, as there’s many different use cases depending on your game setup and type. But overall this will become more obvious as you try to figure out why different replication scenarios aren’t working as expected. There’s no simple rule-set I can offer here. I have to keep making my own continuous notes and referring back to them, and often I forget to do that, and lose half a day on stupid mistakes…:mad:

Again ^ see above ^. But overall, you will see these nodes getting routinely used in tandem with manual replication of Vehicles / Aircraft for example. You only get movement replication and client-side prediction done for free with Characters. For every other kind of movement or physics you must account for this yourself! To avoid lag its often necessary for Clients to move their own Vehicles and then send Vectors to the Server for A. Anti-Cheat Validation and B. Replication for Server and other Clients (to witness). And this is when things become a real mind**k… You have to code not only for the Client (Client2) but also for the Server’s copy of Client2 (not to be confused with the Listen-Server’s own Client Vehicle (Client1)), as that will also need its own special handling (although its easier as replication is partially already handled). But you also have to handle the case for remote Clients that are witnessing the movement of Client2. That all has to be smooth too, or Clients will see jumpy jerky movement which kills the effect. So how do you distinguish the movement of Client2 versus remote Clients’ view of Client2 versus the Server’s copy of Client2? You can use IsLocallyControlled… Using HasAuthority alone wouldn’t be safe in this case, as you could be interfering with the code for the Server’s copy of Client2. Clear?

As regards Multicast versus Server-only. Again this will come with experience and trying out test projects. But its crucial to understand that Multicast may be needed when you see a change that is working on the Client that initiated it, but nothing is getting to the other Clients. I’m trying to think of a simple example such as changing the color of a multiplayer car. If you do that Server-side only, the owning Client may be correct and the Server will be correct, but subsequent Clients will not be. Using a Multicast RPC here is a good example of Function Replication (RPC). However, if this was a continuous stream of changes then that’s not best practice, and the ‘big book’ says you should use RepNotify on each of the Clients instead to change the color of the remote Client’s car… Clear?

I’ve never found any sources that were worth the time tbh (eXi’s PDF is popular and the Mathew Wadstein WTF series is highly rated too). But to be honest, tutorial makers live in a huge bubble. They pretend knowledge can be encapsulated into a fixed time frame. But the fact is, to get the topic done they have to leave out all the edge cases! So tutorials only get you so far before they utterly fail you. That’s why, I only recommend learning from working projects. See link below…The best advice I have is to learn from pre-existing projects: dissect things / take things apart / experiment and try to have fun (sounds obvious but its really important)… There are several multiplayer templates by creators here… Alternatively consider buying templates from the Marketplace, as its a popular route people take to make up for useless docs / bad tutorials… Epic live in complete denial about this. Its always been this way even before UDK. But long term, it will hurt them! This is why video tutorials and wall-of-text docs (especially those without anim-gifs) are so useless, they can never cover all the nuances!!!:wink:

All of game dev is a puzzle really. It starts with trying to understand Comms or getting game elements to communicate with each other.

Another way to look at this is to take a simple third-person / first person Shooter. You often have 3 Players in multiplayer PIE / LAN testing. Server-Client1 / Client2 / Client3. In practice though, this is actually 9 actors that you have to be concerned with or 9 different POVs (points of view / perspectives). IsLocallyControlled is a helpful test or branch to get the local Player playing on a particular screen (the main character that you’re controlling on that particular screen). The remote branch of HasAuthority on that same screen should give you the remote client(s) playing on that screen in the background. This test or branch is often useful for adding local sound or visual FX for remote players for example (while not handling or dealing with their core control code).

Using IsServer on its own or in conjunction with IsLocallyControlled should get you the actual Server’s Client, which is key, especially for spawning actors that require or need replication, or for setting / updating variables that need to be replicated. Summing up, in a lot of multiplayer scenarios such as manual replication of movement, you’re actually having to deal with at least 3 different code branches all of the time. So there are always 3 different branches to consider. The docs rarely make this clear though. That’s about the limit to my understanding. In practice at a C++ level, its more complicated again, as there are more ‘roles’ to deal with. But this should get you started. BTW: It can help to follow devs with ‘Engine Contributor’ badges. Good luck dude! :cool: