Falling deep is awkward

[Wuzzy]

Falling deep is poorly implemented. When you fall a long hole or just very high in general, your speed exponentially (I guess) increases. The problem is, at one point you are falling so fast that Minetest is not able to load the chunks fast enough. The result of this is that you may stop falling in mid-air (your speed gets reset to 0) because you hit the top border of an unloaded chunk. Then you start falling again when the chunk is loaded. For very big heigths, this can repeat a couple of times. You can even walk on the unloaded chunk!
If you are lucky, you hit an unloaded chunk which is just slightly above the ground you are going to hit. Since your speed is 0 again, the last few node lengths you are dropping after the chunk loads won’t damage you. So you could possibly get away inunjured with a 1000 node length fall.



This all shows me that something is deeply wrong and needs to be thought over.

[paramat]

A player cannot be allowed to fall into ungenerated chunks, because the chunk may be solid, then you end up buried. Minetest mapgen can't keep up with human terminal velocity. I'm not sure it's possible to keep track of how far a player has fallen, or if it is, it may not be worth the extra processing load.

[Kilarin]

but it shouldn't be too much extra processing load to just set a maximum falling speed. Should it?

[HeroOfTheWinds]

but it shouldn't be too much extra processing load to just set a maximum falling speed. Should it?

That may work to stop the problem for some people, but those who have slow internet connections will still not be able to load the chunks fast enough to stop themselves from landing on an ungenerated chunk. I'd say just don't fall into 1000 node deep pits, and there's no problem.

[rubenwardy]

Maybe make it so the player pauses when hitting an unloaded block, but keeps velocity?

[Kilarin]

I'd say just don't fall into 1000 node deep pits, and there's no problem.

That DOES seem like good general advice. :)

[Krock]

Also using shift can prevent from damage.

[Wuzzy]

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.

[proller]

solved in freeminer.

[Krock]

solved in freeminer.

How?

[Wuzzy]

I can’t reproduce what proller claims, and I cloned the Freeminer repository 10 minutes ago.

I hit unloaded chunks several times when falling, I can walk on unloaded chunks and my speed periodically resets to 0 when an unloaded chunk is hit.

It seems to me that this is not at all solved in Freeminer.

[proller]

But hits must be rarer than in mt.
Generating map speed still slow, but if area already generated your fall speed without stuck can be 100+

[Calinou]

Quoting what I said on #1442 for information:

Note that old versions of the game had two ways of handling this thing: 0.2_20110731 dealt fall damage when landing on unloaded blocks; 0.2_20110922 made the player stuck on the unloaded block, dealing no fall damage but keeping their velocity.

I think what 0.2_20110922 did was good, but it was problematic when touching the side of unloaded blocks: you were stuck there too.