No announcement yet.

Strange behaviour of server side calculated and applied forces on the clients side

  • Filter
  • Time
  • Show
Clear All
new posts

    Strange behaviour of server side calculated and applied forces on the clients side

    Hi, since I couldnt find any matching existing post, I need to make one on my own.

    To my blueprint setup: I have a simple cube which hovers in air due to forces working together and simulating sth like a suspension. Movement input from clients is handled via RPCs. (client says i want to move forward, server executes it via multicast). So far in testing this on the same machine, it was running fine with up to 3 clients. More than 3 and my old PC just gives up. So far so good, as I just wanted to play with a friend via Internet.
    Problem now when playing via internet (steam with advanced session) is, that the forces which are applied to the hovering cube such as simulated friction and so on are now behaving strange up to a point, where i cant even move around a corner without bumping into the wall several times.

    I understand that my input calls of 100 times per second is a bit high for such intent - even so the input doesnt feel laggy. But what I dont understand is, why even the simple forces which are calculated on the server behave strange now. I mean, when i provide clientside input to move the cube around a corner, my serverside calculated friction shouldnt behave strange since the cube is only being moved on the server?

    I cant wrap my head around this, so any help is most welcome.
    Last edited by Brandungsfels; 06-30-2020, 02:08 PM.

    If your forces are of the kind that "cast a ray, figure out how far to the ground, apply a proportional force" then that's a simple P controller, which will not be stable.
    Even if you add things like compensating for current angular momentum and current world-velocity of the corner the ray was cast from, you end up with a PID controller, that needs careful tuning to work stably.
    The biggest problem here is that the time step used by Unreal varies, based on frame rate, and may be different on the server compared to the client. And when you suddenly get a bigger time step, because of some hiccup on the computer, "simple" physics based on blueprints may suddenly explode, depending on how the simulation works.
    This is why things like the Character Controller doesn't use a lot of physics, but instead is more based around things like "sweep this capsue, and put it where I say!"

    I don't know if this is the problem for you, but if "behaves strangely" can be explained by varying physics time steps, then that's a possibility.


      Thank you for the fast answer jwatte.

      Morning, I shouldnt post late at evening - even I can't make much sense of my text

      Here is another try:

      Since I put all the calculations into functions set by timers (0,01s) I thought I would sidestep the problem with the fps.
      The biggest problem while playing over the internet is the calculation of friction and my 'drift force' since those are calculated on the base of the current velocity.
      I understand, that those calculations depend on a stable server to run properly. But what I do not understand is, why those hickups occur even while Server runs on 120 fps
      and doesnt show any signs of slowing down.
      When I let all my calculations be run on the server side, shouldnt i just get a laggy experience on the client side instead of physics going insane?
      I am planning to rewrite all my movement and replication system to do the now serverside calculation on the client side, put the replication aside and let the clients just
      tell the server their position and let server handle passing that information down to other clients.
      But since iam an absolute beginner in everything related to the topic of gamedesigning I have no idea if the path iam trying to take doesnt end in a dead end.

      Any suggestions on how to work on this issue would be most appreciated

      greetings, fels

      Further searching for information on that topic brought me back to substep the physics thus altering the "wrong" delta time for lower fps rates. I did use it already, but must see now, that I misunderstood the concept behind it
      Last edited by Brandungsfels; 07-01-2020, 09:24 AM.


        I put all the calculations into functions set by timers (0,01s) I thought I would sidestep the problem with the fps.
        I don't think that will work -- I haven't seen any guarantee that timers are more accurate than the per-frame timing.
        You could get a similar result by accumulating DeltaTime in the Tick function, and then simulating N times such that your accumulator goes below 0 (or between 0 and your quantum, whichever you prefer.)
        But that's still not good enough, because if the physics itself hasn't updated between two ticks, it won't have moved the objects between the ticks, so you'll just repeat the same step twice sometimes, accumulating twice as much force and such.
        If you actually do the movement yourself as well, incudling velocity/acceleration/angular momentum/inertia tensor, then perhaps that could become stable, though, as long as you're not interacting with anything else that moves. Is that what you're doing?

        One mechanism that I end up using at times, is to cast my rays and calculate my response, not from the "current position," but from the "position extrapolated forward X milliseconds."
        This means that I pre-apply the current velocity and angular momentum by some amount of time, and then do my world sensing from those positions. What this ends up doing is making the response stronger when the movement is faster, in effect turning up the "D" and "P" terms of the "PID" controller, making it more stable but a little bit squishier. (Which isn't bad, if you want a sense of inertia in the movement.)


          Thx again for taking the time to answer this thoroughly.
          I spent most of the last days reading on various topics (client prediction, server authority, substepping, PID controller, interpolating) and I think I just delved into an too ambitious project as a total newbie in everything related to creating games.
          I think the pre-applying of some variables would be a nice solution indeed. But trying some things in that direction made my head spin. I actually implemented Bored Engineer's MMT plugin and it seems to do just exactly the things I need. Now I can apply forces and torque without worrying about different outcomes. Tried to implement substep on my own - but no way without cpp knowledge

          Thanks again for taking your time - though I hope I did understand the concept behind it - implementing those is another story
          Last edited by Brandungsfels; 07-06-2020, 04:58 AM.