I would like to support combined local and remote multiplayer. If I call “CreatePlayer” on the client side (HasAuthority remote) this leaves a mess. It does create a new character, and yes, this character can be controlled using a gamepad on the client. But on the server side, suddenly the second gamepad also works and I can control a second character on the server (which is actually a client character).
It seems like an additional “local” controller is also created on the server, which is a bug, because there is still only one local player on the server.
How to reproduce: Connect two gamepads. Use third person blueprint template, create some spawn points, map the character jump action to “has authority - remote” and then “CreatePlayer”. Run the game in client/server mode with 2 players (in two windows).
Then select the client window and press the jump button (for the client). This creates an additional player.
Afterwards, you will be able to control 2 players both in the client window and in the server window, which is wrong. It should only be possible in the client window.
In order to phrase a proper question: How do I create an additional local player for correct use with remote multiplayer?
Actually, the same issue occurs if I call CreatePlayer on the server. It seems that CreatePlayer currently does not work in a “remote” multiplayer environment. It leads to the client being able to control a server character.
I’ve spent some time working on this, but I’m not seeing the same results. It could be that there is a slight difference in our setups. As a result, I have a couple of questions.
Could you provide a screenshot of the blueprint that you are using for Create Player?
Also, how are you handling your character input in your game? Is this issue only occurring when using a controller for input?
sorry, my bad, the “steps to reproduce” did not work because I made other changes which I did not write down.
After retrying I have narrowed the issue to the following problem: If I run “CreatePlayer” on the client and then run “GetControlledPawn” on the return value, it contains nothing. This actually caused the issues I had because of the way I posessed the characters after spawning. Afterwards I just got desparate trying different things, which is why my bug description is so bad. Sorry for not providing proper steps to reproduce.
Here is an example blueprint to show that GetControlledPawn returns nothing (use third person template):
Here are the settings I am using to start the game in the editor:
The issue is: I don’t know which character I just locally spawned on the client. If I react to some event, this may be some other remote character joining.
I need to know “this” character which the client just spawned because I need different implementation for local and remote characters.
Please let me know if you can reproduce this issue.
Honestly, this is something that I’m not sure works the way that you’re looking to set it up. I’m going to spend some time looking into the issues and discuss it with our developers to see if I can determine if there is, in fact, a bug here or if there is an alternative solution.
thanks for looking into this, as I still have not found a proper alternative way to deal with this.
I have the option to store the returned controllers in an array and perform the character changes later, but that adds a lot of complexity for something that should be very simple. Also, I cannot even tell CreatePlayer which pawn class to use for spawning, so I cannot use some placeholder for local players and replace it later.
I would still say that after creating a player on the client the character should exist on the client, but well, I’m new to Unreal Engine…
After spending some time testing this, I haven’t been able to see the same results.
I think that it would be worth the time to look into this tutorial:
The tutorial goes through how to set up local multiplayer. Although I know you’re looking to modify the setup slightly by adding networked multiplayer to it as well, if you can get the initial setup down I think that it will resolve your issue in your multiplayer project.
Let me know if after running through the tutorial you’re still having the same issue, and I’ll be glad to continue investigating.
There are no hints about combined local/remote multiplayer in any of these tutorials, except in the one you pointed to, but this is only an answer at the end which says “yes this is possible”.
I also wrote a request for help in the forum and got no response. It seems that this is something very uncommon in Unreal Engine.
The problem I have is that CreatePlayer, if run on a client, returns a new controller but does not yet associate a pawn with it. Instead, it seems that it tells the server to spawn a pawn which then replicates and later appears on the client. This makes CreatePlayer behave very differently on client and server, so it feels like a bug. If pawn creation is delayed, CreatePlayer should e.g. have a delayed pin which returns after player creation is complete, so that the pawn can be accessed.
Sorry for the delay. At this time we believe that the issue you are describing is not actually a bug with the Unreal Engine, and so we are not able to take any further action on this. If you still believe this may be a bug, please provide steps for us to reproduce the issue, and we will continue our investigation.
At the current time, we do not have the resources to allocate to investigating the issue without a clear way to reproduce it, as the current steps were not getting the same issue on my end. If you’d like to provide a project that showcases the issue, I’ll be glad to try to look into it. You can PM me a link to Drive or Dropbox through the forums: https://forums.unrealengine.com/member.php?160394-Sean-Flint
I’ve spent a lot of time to find a workaround for this issue. Basically, one could state that this is “working as designed” but the design is very bad imho.
The solution is, basically, the following:
If you need to run CreatePlayer on a Client (which is connected to a server), simply do not use the return value. Instead, use some kind of player activation based on the local player id in BeginPlay of the Controller.
