Yeah, sneaking is broken in my eyes; you can do many weird things with it. But that’s off-topic.
I want to generalize the problem from falling speed to velocity to all directions. If you move extremely fast into any direction, you are likely hit collide into an unloaded chunk.
I think Minetest should not have to show much respect for very high latency clients. If your ping is over 1000, the game is pretty much unplayable already. You may even hit unloaded chunks with normal walking speed, so trying to fix a problem with high velocities for very high latency clients is simply a waste of time.
The idea is, the player should ideally, never ever collide into an unloaded chunk. Due to latency, this may not be always possible but I think there are ways to reduce the number of cases.
I have ideas to reduce these cases:
First (this is not new) apply an absolute maximum speed limit for *all* directions (velocity as a vector, maybe?). Maybe this speed limit should be disabled for debug/testing reasons because in that case you don’t really care when you collide with unloaded chunks but it should be used for normal gameplay.
Then, the game should attempt to better predict which chunks are to be loaded. If the player is in mid-air, the game can predict the player is likely to fall. So the game should as fast as possible load the chunks below the player until the spot where the player would probably fall (assuming the player does not move).
Here, up points to Y axis and right points to the X axis.
Let’s assume the player is in mid air and looking into the blue arrow direction. The chunk where the player is already inside is already loaded, so we don’t have to bother with that.
Let’s further assume there is time enough to load 3 chunks. (I simplify a lot here). Normally, the game would load the chunks (shown as the red grid here) which have a blue cross—the direction where the player looks (Maybe the game does not actually work that way, it is just an illustration.). But the player is in mid-air and therefor would go into the direction of the green arrow. So the game can predict that and would load the 3 chunks beneath the player.
Another idea for chunk prediction would be to consider the player’s current velocity. If player moves at speed X in direction Y, Minetest interpolates the player’s position and loads the chunks which are into the direction the player heads to first.
But if the player is not moving or very slow, the game may have time to load chunks to which the player simply looks to or those which are simply near the player.
Here is an illustration:
Here, the player has a velocity in the direction of the orange arrow. According to that idea, the game would load chunks based on the player’s velocity vector. The first 3 chunks which are crossed by that vector are loaded first.
For comparison, the chunks the game would normally load are blue again.
However, just looking at the raw velocity is deceptive, as it ignores the gravity. Also just looking at the gravitiy is also deceptive.
So both have to be combined:
Again, green points towards “gravity” and orange is the player’s current velocity. But over time, the player’s velocity is not a constant along that arrow (unless gravity has been disabled). Green and orange combined result in the purple arrow. The prediction would cause Minetest to load the chunks which are crossed by this predicted line first.
Assuming the player’s velocity does not change on unexprected events, I think the last sort of prediction may be already pretty accurate.
Note that the prediction of the player path should not entirely replace the current chunk loading strategy. If the player has a low velocity and stands on solid ground, the game has time to load the player’s surroundings. But for high velocities and/or deep drops, the game should prefer the chunks the player will likely hit soon first.
Lastly, if all fails and the player hits an unloaded chunk anyways, I think the solution to it would be that the player is frozen and the velocity is remembered. The player model does not move while it is frozen. As soon as the chunk loads, the player is unfrozen and continues with the stored velocity. This would fix 2 issues: First the ability to walk on unloaded chunks is gone. Second the ability to safely fall down 1000 node lengths because of luck with unloaded chunks is gone either. If you hit an unloaded chunk right before the ground, you still hit the ground at full speed when you the chunk is loaded and you are unfrozen. Hitting an unloaded chunk still sucks, but at least it is more stable. The measures to avoid hitting one must be worked out well to reduce the probability of hitting an unloaded chunk.
Maybe the client should show a loading symbol when this happens.
And I think all of this can be generalized for all kinds of entities, not just players.
Note these are all my small ideas on how to fix the issue. I think the issue of hitting unloaded chunks can never be truly fixed, but it can be made less likely. And Minetest should certainly cope better when something hits an unloaded chunk.
These are all my quick ideas I had. I honestly don’t know how realistic they are. Please feel free to comment them and to take them apart.
Posted: Wed Jun 18, 2014 01:34