BAD FPS ON THOSE WHO REMAIN ROBLOX UPDATE

By default, we replicate physics updates with the assumption that the observer is at the player’s character location, but developers can override this location by setting Player.ReplicationFocus from a server script. One of the factors is distance to the observer. There are multiple factors that control how often we send updates.

BAD FPS ON THOSE WHO REMAIN ROBLOX UPDATE

The artifacts you are seeing are not a consequence of the lowest level protocol, they are an artifact of the throttling we have in place that limits physics update rate: when the client doesn’t receive a position update for an object for a long enough period of time, the object will appear remain in place until another update arrives. Physics/UDP/Unreliable: roblox replication already is based on UDP, and physics data is already sent unreliably. Once it is released you will likely need to do additional work to propagate ping information to clients for localscript use. Ping: there is work underway to expose ping information on the server.

** I do not work for, nor associate with ION Racing, however their live streams show the issues with ordered packets down to a T, making them a perfect example case for UDP Protocols based on my albeit limited knowledge of the subject. * I am by no means an expert on how exactly UDP versus TCP protocols work, and I do understand that UDP is harder to work with than TCP due to it having no error checking (destroying packets that are considered in error), but I do believe that UDP would make this more feasible. The latter is done by iRacing, the former is done by ION.) (To counteract car hitboxes going inside one another, either turning off collisions completely or not allowing cars to collide when a car is blinked back in, already inside another car. A similar system could be put in place by Developers if UDP was available to them to use, where frames where the packet is lost, the car simply would not be displayed. In iRacing, when packets get dis-organized or lost, the car will be “blinked” out. What you get is a bunch of garbage as far as positioning data, as seen in races by ION** with lots of cars on track: Once it arrive, all the packets fire off at once, which shoots the car forward to it’s current destination. That certainly adds up.) In a perfect world, a player’s ping would be an attribute of the player in Game.Players.Ĭurrently with Roblox’s ordered packets (apart of TCP protocol), when packets get backed up, a car will just dead stop and wait for the missing packet to arrive. (As well I have worries about firing the remove events too often, as I’d be looking to fire one per frame, per player. An officially system provided by Roblox would be less hacky, and likely more reliable with calculating the ping as there are more resources to Roblox in the background to run these calcs quicker. Currently the only way to do this is to Fire a Remote event, take down the time you fired it, wait for the response on the server, and then take down the time you received it.

When making calculations to place cars in front of where the server currently dictates them to be, you need a reliable source of a player’s ping. GTA V has this same issue when playing “Chicken” at high speed, but when racing in the same direction, the impulse is low.

The car goes through the wall at the end due to the high impulse of the stopping force. gif-maker (36) 800×450 5.45 MB The player floating behind the opponent car would be where the car would normally be placed.

Bad fps on those who remain roblox