Server Tick Rate Affects Character Mesh Physics [BUG]

Increasing the tick rate on the server causes simple character physics interactions to increase in force. This is a confirmed bug in the server.

To recreate:

  1. Create a game from the Third Person Template
  2. Add simple physics actors (with replication) to the level (I used cubes)
  3. Alter collision settings for character mesh/pawn and cubes to allow the character mesh to kick the cubes
  4. Set the game up for and build a dedicated server and client
  5. Edit the DefaultEngine.ini to increase the tick rate (200 is a good value to see the issue)
  6. Run the server, connect a client, and run into the physics actors

*Getting the template to work as client/server involves more work than one would expect, but you’re Epic so I figure you know what to do.

*You probably want to also disable that new adaptive network thing – it’s HORRIBLE.

Hey Jin_VE,

I’m not sure that I understand what the issue is. I would expect a different tick rate to produce different physics behavior since physics simulation is typically entirely framerate dependent. Could you elaborate a bit or perhaps provide a video that I could take a look at to better understand the issue?

Also, were you seeing this behavior in previous engine versions as well, or did it begin in 4.17?

Hi ! To my understanding, physics should run at the speed of reality where 1s = 1s. The tick rate should divide that time up evenly. A higher tick rate means a smaller delta-seconds, which should always balance out to add up to 1s/s. Everything else I could see in the physics system remains unaffected. For example, two normal physics actors do not gain mass, velocity, or momentum when the tick rate is increased. It only happens when the mesh, a non-physics object is interacting with the physics actors.

I have an external system that is time-critical but I can’t get a response from the server any faster than its tick rate, so I got better results when I increased it. All except for this one strange situation.

I noticed that you can’t enable physics collision for a mesh that is driven by the ProjectileMovement component (the bullet hits everything in a large radius and unreliably so). So it made me think that maybe my issue is because I have physics collisions enabled on the skeletal mesh? As I mentioned above, I tried socketing collision component ‘shoes’ to the mesh and turning mesh collision off entirely but still got the problem.

Seems to me that whatever is driving the velocities of that mesh (the animation?) isn’t considering the tick rate. I’d be happy to make a video if you still need it, but all it will show is the character kicking cubes normally (default tick rate) and then kicking them like Superman (200 tick rate).

Yes, I first found this in 4.16. It may go back further. And thanks for looking into this! :slight_smile:

I just went back to the sample I made. It’s not happening. I have no idea what I was seeing. I’m looking at the tick rate setting in the INI and it’s in the IpNetDriver section, so I’m not sure that’s the actual base tick rate at all. Sorry to waste your time. Working with the engine source can get kind of confusing and lonely.

Not a problem, I’m glad it is resolved. Feel free to let me know if you run into the issue again and we can continue to investigate.

Well, it still happens in my implementation but not with the example I made. Let me explain a bit deeper.

I have a scalable technology that clusters game servers. I implemented a UE4 plugin to interface with it, so anyone will be able to make UE4 dedicated clusters. It makes one big game space, allows you to spread AI across many machines, and more. I’m inches from being ready to formally present.

I think I’m seeing this problem because I’m running a remote character actor on the server where the cubes are being hosted. For some reason (maybe not having a controller?), it’s not behaving the same way it would if the cubes and character were hosted on the same machine. I’m hoping you or someone else had any thoughts. I have enabled “bRunPhysicsWithNoController” in the controller component, by the way.