High ping causes player to fall under the map [voxels]

Help and Feedback Scripting Support
#1

Hi guys,
Im making a game where players have to use bombs to dig in terrain. When player throws the bomb, parts are voxelized and it looks cool BUT if I throw the bomb to the ground, there is a split second when there is nothing under my legs. So my voxelization code works like that:

  1. bomb explodes, I get all parts in range of explosion
  2. I split parts into two parts (using only data and saving new parts data in table) until they are smaller than vec3(1,1,1).
  3. I place all small parts where they should be
  4. I remove parts that have to be removed

so I shouldnt fall under the map but it happens. do you know how can I handle it? also, everything works on server, would you suggest to do some changes here? how can I improve my system to reduce lags/stuttering and make players not fall under the map? btw, bombs in the video are huge, I just wanted to show the effect

#2

try putting an anchored part below the player until the explosion finishes making the crater

#3

how would you detect on client when explosion ends?

#4

you could just have whatever’s generating your explosions have it place the part under everyone and then delete it when the explosion finishes (serversided)

#5

On the server it may end but there is a client delay… I already have a part under players until explosion ends

#6

There’s no great way to do this that will look instant on all clients. You ultimately don’t have total control over how quickly part updates get processed on any particular client, or the order. When a large number of parts changes on the server, the client processes the changes in batches, and does not respect the order you did things on the server, because there are a lot of rules at work. Player character parts have priority over other bits of the world, and things closer to your character will probably update before things farther away. But size of parts matters too.

Really the only way you can guarantee that players don’t fall through the void is to not remove anything on the client until all of the newly-created blocks have been placed. Clients would need to know what to wait for, so it would require remote events. Because clients would all be out of sync with each other, there would be a period of time where client and server physics would be out of sync too, as the server has to wait a reasonable amount of time before deleting blocks also, otherwise replication could delete them on a client before the client script does. This would be a real pain to implement and test, and would never be perfect.

One thing you can do that would help speed things up for everyone is make sure the server and all clients always have an already-created pool of parts ready to add. You don’t want to be doing any Instance.new(“Part”) or part:Clone() to make new parts when you’re building the voxel craters, that will be much slower than CFraming in already-existing Parts.