I have built a multiplayer setup based off the Network Multiplayer in Blueprints tutorial put out by Epic, available on the docs and YouTube. I am currently using a listen server setup and the Steam Online Subsystem. I have been testing it with another member of my team, who is on a different internet network. We can both successfully host a lobby, as well as find and join each other’s lobbies from the menu. Once the lobby is launched we are both brought from the lobby level to the game level using Server Travel. Here is where the problem comes in: Once both players have loaded in, the host can move around freely and interact as intended. However, the Client player cannot move around using WASD, look around, or fire using mouse input. The host can see the client move and fire, but cannot interact with the host in any way, nor can the host interact with the client, but the collision works, so the host cannot walk through the client. The only part of the Client that works is pressing T to chat, and sending chat messages. All character blueprints are set to replicate, as well as character movement components. I have attached an image of my game mode setup for spawning in the players. Currently for testing purposes and simplicity I have the spawn system set to pick randomly between 2 spawn points.
Eh, I’ve run into this issue several times before and it’s definitely a replication issue with PIE. The trouble is the Listen Server is both a Client and a Server so not all of the “Standard replication” rules apply as they should especially with PIE. PIE and networking does a lot of strange voodoo and I’ve given up using a Listen server and opted for using a Dedicated server with a non-Single Process to ensure each Client is in fact isolated as its own Client. With a Listen Server you’ll need to write some overhead to ensure things like RPCs, replicated variables, etc. from other Clients actually get replicated properly with methods such as Role checks or implement RPCs that may seem like it shouldn’t be necessary or “doubling up” but remember: one of those Clients is also a Listen Server.
Just out of curiosity, in the FirstPersonGameMode Blueprint, at the Possess node, is the Target (Player Controller) valid on both client PCs? I assume since you’ve got a colleague to work with you can stagger your connections so try and have the other person join late and see what happens. Try printing server-side stuff all along the way to the screen/log on the Listen server to see where it breaks. If not able to stagger connections, I suggest trying to see if you can just host a Dedicated server on one PC (also have that start 1 Client for yourself) and have your colleague launch a game in PIE and see if they can connect to your instance that way.
We have been testing using a standalone window, I don’t know if that makes a difference. After running a few tests with my colleague, I can confirm the player controller is valid. It is also properly loading the player’s selected character from the lobby character select menu. Still no movement unfortunately. On a side note, I noticed the client isn’t properly capturing the mouse to the window, it moves off the window as a client when I try to look around, but stays captured as the host. So in your experience, using the dedicated server route, you haven’t had as much trouble as with a listen server? I am more than willing to try the dedicated server route, but I was planning to use listen servers as we begin handing it out to our prototype testers, so that way we don’t need a dedicated server in place for them yet.
I have the same issue but slightly different. Followed the same tutorial.
Client can log in and look around but can’t move on any Axis - it just stutters/shakes in the direction you want to move, it feels like the game recognizes the input but can’t act upon it. Packaging made no difference.
this might not be the problem at all but i would let the GameMode completely handle the spawning and possessing. The event OnPostLogin gets called when a new player connects to the server and always returns a valid player controller. from here you can spawn and posses. in your approach you call your custom spawn function on event begin play within the player controller which might generate some problems
I know that I am late, but I found a solution. In my case, the problem was that my Game Mode was parented by “GameModeBase” and my Game State was parented by just the normal "GameState. The solution is to set your Game State parent to “GameStateBase” and your Game Mode parent to “GameModeBase”.
This answer might help someone in the future.
If you are joining your dedicated instance via the console with the open command (e.g. open 127.0.0.1), make sure you don’t have anything disabling your player’s input.
My case was a result of utilising SetInputModeUIOnly to locked when opening the main menu at launch which I had configured within my GameInstance blueprint.
I realise this may not be directly related to the original post, but it is the first result on google for the issue.
I just resolved this myself and thought I’d throw this out there in case anyone else stumbles across the same silly issue. Good luck.
Stuttering sounds like its moving client side, but not server side. So when you try to move, the server snaps you back to where you are on the server. Able to send a photo?
