[4.5.1, Video and Repro Project] I had to revert to 4.3 Again, Set Simulate Skel Mesh Bug On Client

Dear Friends at Epic,

#I had to revert to 4.3 Again

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

  1. either the proxy instantly disappears
  2. 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.

#Download Link, 20 MB

again is my repro project for you!


#My Attempt 1

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; 


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?

#Major BreakThrough Video

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


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!


#Epic, please determine why

  1. I cannot turn replication of the mesh off so that this replication bug involving physics simulating Character meshes does not occur
  2. 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.

#Video Link

again is the video link, enjoy!

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( ) )

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.

#Workaround Confirmed For Test Project

Awesome work Ehamloptiran!

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!

#Epic Devs Please Investigate SkeletalMeshComponentPhysics.cpp

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)


Digging a little deeper, the issue seems to be caused by the following:

if (OwnerComponent->AttachParent)

Located in BodyInstance.cpp in the SetInstanceSimulatePhysics function, if I comment it out, then it works exactly the same as my workaround above.

#Epic Please Help

I am still awaiting any kind of resolution on this matter.

Ehamloptiran’s awesome helpful research and workaround doesn’t really work for me in several projects, resulting in odd behavior.

The mesh no longer goes to the origin but it still behaves very strangely for several of my paid projects as well as my own personal 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.

Keep going Piinecone!

I want this issue addressed!

Thanks for sharing your research!


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.

This bug is also still persistent in my project. Epic, please help resolve this as it’s making an online FPS very hard to troubleshoot. Thanks!

Thanks :smiley:

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.

This issue does not appear in PIE.

Thank you, everyone, for taking the time to report this. I have been investigating this issue and will update once I have more information.

Great to hear from you !


Hi everyone,

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.



Thanks TJ and Epic!


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 :")


Hi ,

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.