I am making a multiplayer game where the main unit is an ACharacter extending class where the mesh is set to simulate physics for the entire game.
I just did the following repro
same source code and content in 4.5, go in game in multiplayer game, for the server, the client exists, but for the client, the server proxy is destroyed as soon as set simulate physics is called
I went back to 4.3, same source and content, and everything works just fine, on the client, when the server proxy has set simulate called, the proxy does not get destroyed and I can actually play my game
#Different Project Case
In a completely different project, an FPS game, I encountered the same issue, on the client, when the server proxy has set simulate physics called on the character mesh, the server proxy disappears
For the server, when client proxy is set to simulate physics, the client simulates physics normally
#Repro Project For You
I have composed a repro project for you that involves a tiny amount of C++ for network replication of Set Simulate Physics
When you test it you will see that one of the following happens on the client machine when the server proxy is set to simulate physics
either the proxy instantly disappears
or the physics asset goes completely bonkers for a few moments and then disappears
This is totally unacceptable situation for my game and so I am back on 4.3 once again.
Please examine my repro project and find a solution for this easily reproduceable issue
#Using my Test Project
You can download it :
Then you can go into the editor and run a listen server with one client, or run dedicated with 2 clients
#B Key
Press the B key to run my C++ replicated Set Simulate function which uses rep notify var to set the character mesh to simulate physics
#This is a Severe Bug
I had to revert to 4.3 because of this, I cannot continue with new UE4 updates until this matter is properly addressed.
Again in my game the main characters are always simulating physics, in a multiplayer game.
I tried turning of replication of the mesh to see if that would protect it from getting destroyed by whatever is destroying it on the Client in 4.5 (everything works fine in 4.3).
/*
In my Base Character Class Constructor
*/
bReplicateMovement = false;
//MESH NOT REPLICATE
Mesh->SetIsReplicated(false);
This did not result in any change in behavior, the server proxy on the client machine is still getting instantly destroyed as soon as it is set to simulate physics.
I did check to make sure the mesh is indeed not being replicated.
How is it possible that the server proxy on the client machine is getting destroyed when I set it to simulate physics for the client reality, if it is not being replicated?
what part of UE4 code base knows or cares what server proxy is doing on client reality even if the mesh is not being replicated?
I just had major breakthru in understanding the bug that 4.5 introduced for the client’s perception of the physics movement of the server’s proxy!
#Video Link
#Context
In my game when the client is destroyed in combat the client’s camera focuses on the server.
By accident I destroyed the client in combat, and its camera went to where it thinks the server is located.
Which happens to be at the World Origin (which is not where the server’s proxy should be really)
Again please recall that both server and client Character meshes are always simulating physics
Notice in the video how each time the server’s physics simulating mesh moves, the server proxy disappears even from the origin, but when the server becomes immoble again it reappears on the client
#Understanding the Video
Left screen = Server
Right screen = client
client is taken out of play and is left to only observe where it thinks the server’s physics simulating proxy is, which is at the origin of my level.
#What this Means
Somehow the network replication for Character meshes that are simulating physics is really messed up in 4.5
I am a rather confused because I found this behavior happening even when I set Mesh->bReplicates to false in the constructor of ACharacter!
#Solution
#Epic, please determine why
I cannot turn replication of the mesh off so that this replication bug involving physics simulating Character meshes does not occur
why the bug is happening at all, sending the server’s physics simulating proxy to the world origin and then having it disappear entirely while server is moving.
As per our talk and testing, the below code seems to be an adequate workaround to the issue at hand. Replace Mesh->SetSimulatePhysics( true ); with the following:
if( !Mesh->bEnablePhysicsOnDedicatedServer && IsRunningDedicatedServer( ) )
return;
Mesh->BodyInstance.bSimulatePhysics = true;
Mesh->bBlendPhysics = true;
for( int32 i = 0; i < Mesh->Bodies.Num( ); i++ )
{
Mesh->Bodies[ i ]->bSimulatePhysics = true;
Mesh->Bodies[ i ]->UpdateInstanceSimulatePhysics( );
}
Seems that using SetInstanceSimulatePhysics on the Bodies as per 4.5 does not work for replication, where as the 4.3 method of UpdateInstanceSimulatePhysics does.
I can confirm that switching out the 4.5 SetSimulate code for the 4.3 SetSimulte code does fix the errors I see in my sample project which I am sharing in this post!
If you diff 4.5 to 4.3 SetSimulatePhysics in SkeletalMeshComponentPhysics.cpp you can see that the code substantially changed in 4.5 and is vastly inferior to the performance of 4.3, because the 4.5 is bugged as I am reporting in this thread.
Please investigate why this is so!
Many thanks to Ehamloptiran for figuring this out!
#Workaround Still Does Not Help My Main Project
Epic please still aaddress this issue, because th workaround does not work for my main project, only the test project I’ve included in this post (very small test project)
@ and @Ehamloptiran, thanks for looking into this. I’ve been working with replicated vehicles ( AWheeledVehicle’s RootComponent is a USkeletalMeshComponent) and can confirm the same issue since 4.5 on a PIE dedicated server (I haven’t tested a standalone dedicated server yet).
The workaround works for me but I haven’t done extensive testing yet.
I wanted to report on something I noticed. While testing in a standalone dedicated server environment, I noticed that my vehicle meshes weren’t actually disappearing, their simulated proxy roles were just way out of position. I disabled the workaround and I see identical behavior – sometimes everything is fine, sometimes transforms are way out of sync (as if replication has quit).
This might be a completely separate issue. I’m going to do some more testing today. It’s arduous because it doesn’t seem to happen in PIE.
I’ll just keep dumping stuff until you guys ask me to stop :D. My issue may be completely distinct. If so, I’ll create a separate question.
Initially I thought this issue was purely disappearing proxies. I would spawn in a dedicated server, attempt to drive over to another player, and appear to be invisible. After some repetition and exploring I noticed that the proxy was visible, it was just in a very different location, as if the simulated proxy pawn had spawned in a different location from the autonomous and authoritative. It would move when and how I moved, but its initial orientation was wrong and its transform was not being corrected through replication, so the resulting position was very different.
If I destroy the authoritative pawn (which is invisible to the other client) then the respawned pawn and its proxies appear and move correctly to all parties.
I have to test this with a fresh, sample project, but I suspect that either a) the GameMode’s default pawn spawn mechanism is incorrectly setting the transform for simulated proxies or b) there is something peculiar about my pawn. Once my pawns are destroyed, their respawn is handled by a different implementation in a subclassed GameMode. I’m about to test a hack I hope will isolate the issue a bit more, where I force newly connected player controller pawns to be destroyed and respawned instantly in an effort to let my spawn implementation take over immediately.
Update: my initial spawn was a blueprint derived from my pawn class, whereas subsequent pawns were from the purely C++ base class. I didn’t notice this because the derived blueprint class doesn’t have any functionality. I’ve changed the GameMode respawn functionality to the SpawnDefaultPawnFor() function. Testing with a blueprint pawn causes the disappearing/diverging pawns, whereas a pure C++ pawn behaves as expected.
So i can confirm this problem as well, and also for Static Mesh`s.
Reverting back to 4.3 is not a option for us so am realy hoping Epic solves this.
Full info on my problem can be found but its the same as described above.
Something to note:
For a skeletal mesh that has bEnablePhysicsOnDedicatedServer
The mesh will disaper on the client, but will actualy be simulating on the dedicated server.
A static mesh disapears completly it seems.
If you ask me this is a critical bug as this totoly break games relient on physics replication. Am afraid don`t have any new information regarding a solution tough.
Again, fully aware that the issue I’m seeing may be entirely unrelated, and I’m planning to report it separately, but I wanted to leave my findings in case someone with a similar issue ends up as the symptoms can appear to be identical.
I noticed that my respawn functionality, which is handled in C++ by a derived game mode, spawns my C++ pawn and not my default blueprint pawn class as set in the editor. If I change my C++ game mode respawn functionality to use the DefaultPawnClass (set in the editor) then I consistently see the diverging pawns issue in a dedicated server environment. Certain materials also fail to render. Reverting respawn to spawn instances of the pure C++ class resolves the issues in a dedicated server environment.
I just wanted to let you all know that we have created JIRA UE-6128 and our developers are looking into this issue. We will post back as soon as we have something.
I’v solved it !!! All you need to do is to destroy the movement component and disable replication before starting the physics simulation. all the clients will see the ragdoll and you too and it will works great !
I’m so proud of myself :")
Take a look at this post below. came up with a blueprint workaround that may correct the issue for you. I just gave it a try and it corrects the issue. In the meantime, our dev’s will continue to look into the issue and we will post back when we have something.
