DarkMultiPlayer Client

DarkMultiPlayer Client

38.8k Downloads

[Discussion] What would it take to allow for better physical interactions?

JohannesMP opened this issue ยท 3 comments

commented

One big limitation of DMP/KMP right now is that physics interactions are volatile at best.

For example, let's say that Rover_A and Rover_B are each controlled by separate players. If Rover_A attempts to slowly push Rover_B, it's very likely that an explosion will occur, because while A pushes B in its simulation, B hasn't yet felt the impact of A and thus syncs its position back to A which results in an intersection of the two rovers and tears from the respective pilots.

This is doubly problematic because chances are Client_A will simulate its own Rover_A, but Also Rover_B breaking and will try to sync the resulting parts to the server, and Client_B will simulate its own Rover_B breaking but will also attempt to simulate Rover_A, and sync resulting debris.

For the sake of discussion, what are some possible ways that this problem could be mitigated? Resolving collisions in a multiplayer environment typically requires either server-side resolution or at least far simpler physics models than what is going with KMP, but could an alternate solution be found that would allow the simple scenario explained above, Rover_A pushing Rover_B, and both clients reacting better?

  • To address the double syncing, is it possible for a client to treat vessels controlled by other clients as vessels that are unbreakable? That way each client is responsible for resolving the breaking of their own vessel.
  • Regarding performance, a client could treat other uncontrolled vessels as no-clipped and use the server's position/velocity values to place them in the world. Only when within a certain range could the client then chose to simulate the object's physics.
  • At slow relative speeds, is it possible to make collisions between two objects more forgiving? like by somehow fudging or predicting the other vessel's position?

Note: I was hoping to go into more detail but for now I'm too tired to manage that; I'll probably expand on the topic, however I would like to hear other opinions on the matter.

commented

There are some cases that you can duplicate the collided vessel.
Me and MrFreake were testing the other day, with the gatling gun mod. When I shot him, his rover exploded, but shortly after, a duplicate rover showed up and was intact.

commented

It's worth mentioning that only one client can update a vessel now, so pushing KSP's ball around is a little tricky: https://www.youtube.com/watch?v=7oBxOkd5cbk

If vessels slightly collide, they don't always explode though.

commented

I don't know how often updates are being synced between clients but I think for good servers with large bandwidth it would make sense to be able to increase resolution in physical updates (eg. instead of 5 pfps (physical frames per second) it could be 30 pfps that are being transmitted). It's up to the server owner to figure out the best resolution for cpu/network usage versus physical precision. This wouldn't be an actual solution as it doesn't solve the main issues, but it may be a nice workaround while better solutions are being investigated.
On my server I'd set the updates to 40 or 50 pfps so the maximum overlapping parts at 5m/s (which I think is reasonably fast relative speed) would be 0.1m which should be fine for KSP to not completely mess up collisions. It's still 10 frames less than optimal client side speed which I feel is a large enough buffer for slower clients to keep up to the task.
Form what I feel while playing, the physical update speed is at around 3-6 pfps which is imho very slow and would cause as much as 1.6m overlapping of objects between syncs which is definitely problematic.