Just started learning multiplayer. Watched a lot of videos and read a lot of things, but the logic I get in game, is inconsistent with the logic I think should happen.
P.S. I am aware that C++ offers more possibilities for multiplayer, however for understanding this basic concept, I’d like to stick with blueprints for now.
So I have a listen server, and 2 clients. So 3 pawns in total.
I have set up this code inside the pawn.
Now logically, there are 3 game instances, and each of the instances has their own 3 pawns. On server there should be 3 Authorities. On each of the clients there should be 1 autonomous proxy, and 2 simulated proxies, right?
Also, the print should run for all 3 pawns in 1 game instace, so I should get 3 prints on each of the game instances (9 prints in total) each time I press G.
However, when I press G, here are the problems I don’t understand.
I get only 1 print on each of the game instances.
When I press G as the listen server, I get this printed on all 3 game instances:
Since it’s the server itself, shouldn’t it print “Authority”?
When I press G as one of the clients, I get this printed on all 3 game instances:
Why does it print Authority, if it is a client. It should print “Autonomous proxy”?
Additionally, why is it printing the same role on all 3 game instances? It should print Authority on server, Autonomous Proxy on the client that pressed G, and Simulated Proxy on the other client. No?
Would much appreciate, if you could help me wrap my head around these basic concepts.
Could this be because the calls are not going through the proper multicast routes in the wrong type of bp scope? Only the Player Controller, Game Mode & Game State exist both on server and client. Here’s a bit of info on RPC that’s gpt-4 generated for you:
In UE5’s multiplayer system, each object (such as a pawn) can exist in different states depending on whether you’re on the server or a client. These states are defined by their “Role” and can be one of the following:
Authority: The server has the final say on the state of objects and is considered the authoritative version. This role is typically held by the server for all replicated objects.
Autonomous Proxy: A client-controlled object. For a pawn, this would be the pawn that the client directly controls. This is the client’s version of their controlled character.
Simulated Proxy: These are replicated objects that exist on the client but are not directly controlled by them. They receive updates from the server about their state.
Analyzing Your Observations
Single Print per Instance: When you press “G”, you’re likely triggering the event only on the pawn that is directly controlled by that player (either the server player or one of the clients). This means the input is only recognized by the instance that has focus and control of the pawn at that moment, leading to just one print per game instance.
Unexpected Role Prints:
If pressing “G” on the server shows “1” on all instances and you expected “Authority”, it suggests that the way roles are checked or printed might be incorrect or that the server’s print statement is somehow being overridden or not executed as expected.
When pressing “G” as a client and seeing “Authority” printed, it indicates a misunderstanding of how roles are determined and displayed across different instances. Each game instance evaluates the role of the pawn in its context. However, it seems there’s confusion about how these roles are being reported or a misinterpretation of the role-checking logic in your blueprint.
Same Role Printed Across All Instances: This behavior suggests that there might be a replication issue with how the input is being handled or a misunderstanding of how the role is determined and printed in each instance. Ideally, you should see different roles printed according to the pawn’s perspective in each instance, as you’ve correctly outlined.
Steps to Debug and Understand the Behavior
Review Input Handling: Ensure your input is correctly set up to trigger the intended behavior in all instances. Inputs should be handled by the player controller and then, if necessary, passed down to the pawns.
Check Role Checking Logic: Revisit the blueprint logic that checks and prints the role of each pawn. Make sure you’re using the correct blueprint nodes to check the role of the pawn (e.g., GetLocalRole) and that this check happens correctly on each pawn in each instance.
Debug Prints: Enhance your debugging by printing not only the role but also the unique identifier (e.g., name or ID) of the pawn and the instance it’s from. This will help you better understand which pawn is printing the messages and from which context.
Blueprint Replication Settings: Ensure your pawn is set to replicate and that you’ve correctly set up the replication of events or functions that are responsible for printing the roles. For custom events, use the “Run on Server” or “Multicast” replication options as appropriate for your scenario.
Understanding and debugging multiplayer logic in UE5 requires careful attention to how inputs are handled, how replication is set up, and the context in which actions are performed. By methodically checking each part of your setup and improving your debugging outputs, you should be able to diagnose and fix the inconsistencies you’ve observed.
I know what RPCs are, the point of my question is to understand basic concepts, such as what happens when you run code without any RPC, and why it has the inconsistencies I described above.
I know that you are trying to help, and thanks for that, but I have access to chat gpt too, and what I’m looking for is a concrete answer from experienced developers, since neither the prompt you copied, nor the prompts I generated, are in the least bit helpful.
There is 3 things happening when you print a message to the screen with an Input Action.
Input is only captured by the instance that is in focus even if you play with 1 listen-server and 2 clients.
Print to screen messages are automatically being printed on all instances with a prefix of where the print got executed to aid debugging. If it happned on the server instance it is prefixed with “Server” or the 2nd Client then it is prefixed with “Client 1”
Then finally there is the function GetRemoteRole. It returns how much control the Server has over the current instance. It has authority over all the Clients and Autonomous Proxy for its own Pawn.
So the Input explains why only 1 event is executed.
The print screen behavior explains why you see 1 message on each instance.
This is why you techically only see 1 Message copied to the other instances.
