I have a PhysicsBallBP project, somewhat loosely based on the Blueprint Multiplayer project. Up until now I’ve only been testing with two players, so I don’t know when this bug was introduced.
The server’s player works fine, as does the first client to connect to the game. Every client after that seems not to connect properly. These clients:
Cannot leave the server (the Destroy Session node fails). If I force the issue by making them load the main menu anyway, they do disappear from the game to everyone else, but they can’t reconnect.
Cannot zoom in. This one is really baffling. Players’ cameras are attached via a SpringArm - Moving the mouse sets the rotation and scrolling sets the Target Arm Length. If I print the Target Arm Length, it seems correct on the broken clients, but the camera never actually zooms in - and yet all the other input (including turning the camera) works fine!
Do not get a PhysicsBallBP (Pawn) spawned for them when I launch the gameplay map from the lobby. They do travel to the gameplay map, but their camera is stuck at (0, 0, 0) with no Pawn. I haven’t investigated this issue much as I’m mostly working on finishing the lobby.
CAN move and have their skin/color changed correctly. Everything seems to be replicated properly - they can knock other balls around and everything.
If I connect to the server, then leave and reconnect, I get a broken client that can’t leave again or zoom in.
This is my code to launch the lobby from the GameInstance. It’s the same as in the tutorial except you can’t “use LAN” (since it doesn’t seem to do anything, and the tutorial project works fine with “use LAN” unchecked).
This is the code to join the lobby, also in the GameInstance. It’s also the same as the tutorial’s.
This is the code to leave the lobby, in the LobbyMenu widget. It’s also the same except for the print string indicating failure.
I have the source for the tutorial here too, and I’m testing them both in PIE with Use Single Process - the tutorial works in this configuration (doesn’t have the bug where the third client can’t disconnect), so the configuration is not the problem.
If this isn’t a known problem with a known solution, I’ll copy my project and remove stuff until it’s a simple demonstration of the bug (and if I don’t find the problem while doing that I’ll post it).
I’ve stripped the project down to the very bare bones, basic connect/disconnect logic and I’m still having the problem. 1.6MB zip file with the project is here. If a networking guru could take a look at this and tell me what I’m missing, I’d really appreciate it. I have no clue what it could be at this point.
Start a game in one of the windows. Just make sure you allow more than 2 players, the other settings don’t do anything.
Find the game and connect. The server name should be your PC name and some numbers (Blueprint can’t set the server name properly… been meaning to get that advanced sessions plugin). Click on the name to connect.
Connect with at least two clients. On the last ones to connect, click “leave”, or press TAB to hide the menu and try to scroll in/out.
My project is for 4.14.3 but I just checked, and this happens with version 4.15.1 as well.
I can’t look at your project as in at work this might be in your gameinstance for error handling make sure server is not destroying its session on error remote should only be destroying its session.
I wasn’t doing that but I think I’ve found the issue. I’m having my physicsballBP apply damping every tick, and replicate its position/velocity to the server and back to all the clients every tick (since the BP doesn’t do this automatically like Character does). Disconnecting all this from “Event tick” fixes the problem. Not sure what the specific problem was yet.
Could be difficult because I actually, yknow, do need to replicate the position all the time… will look into how to do this.
Lucky for you I got it working anyway! The problem was specifically the multicast event sending each ball’s position, rotation and velocity to each client, every tick. I wired that up to a 0.2s timer instead, and it looks like I’ll be able to get decently smooth visuals that way. Still need to test on a network with higher ping though.
The Destroy Session node seemed to just be a symptom of some underlying problem though, since the broken clients couldn’t zoom in either. Not sure what the exact issue was/is.
