MaxFallHeight for tumblers inconsistent

[Proxima]

So perhaps the best way is to continue allow "downward-fling to survive", and just discourage creating levels that require this?

I agree, and I would add that "Alternative Route Required" could, if we wanted, be fixed to allow my "clean" solution and prevent the "downward-fling to survive" solution by requiring save 29/30 instead of the current 28/30.

[Simon]

Thanks everybody!

0.7.19 keeps the 0.7.18 behavior: Kill by pixels fallen, keep pixels fallen at 0 when flying upwards, and reset pixels fallen when flung anew. Maybe we'll get more insights in the next months.

I don't know any level that requires flinging downwards to break falls. We'll keep Alternative Route Required at 28/30 to allow variation, which seems to align with Insane Steve's spirit. Added Proxima's replay to the proof database.

-- Simon

[geoo]

This seems like a somewhat dirty quickfix that overall works with surprisingly little collateral damage. It doesn't even fix the original cause of the issue, which I would thought would have been the obvious choice for fixing it, i.e. when a tumbler hits the vertical wall, still add the whole y-velocity to the y-position, and invert whatever distance remains from the x-velocity after subtracting the distance to the wall, and add it to the x-position. The trajectory stopping at the wall during a frame in itself is a flaw, though it is barely noticeable. One could probably design some pathological examples where it's annoying or strange nevertheless.

Either way, it seems like the main issue in the bigger picture is that fallers work with distance, while tumblers and flingers work with velocity.
Flingers must use velocities, and I guess because of faller physics being holy, they must use distances. (If they weren't holy, there would be an obvious unification of physics: Just use realistic physics by having fallers affected by gravity, and death is determined by impact velocity for everyone. In that sense moving to distances for the tumbler check is a step backwards to me, if anything.)
So at some point a conversion between distances and velocity must happen.
In 0.6 it happened by estimating the velocity of a flinger after having fallen 126 pixels, and everything was fine except the issue from the beginning of the topic which arises from some unrelated issue, namely some sloppiness in tumbler movement code.
In 0.7.18, you swept the necessity for converting between distances and velocities under the rug and "fixed" the issue by removing downward flinging objects. It works with surprisingly little collateral damage, as everything overwrites rather than adds to velocities (comic physics rather than real physics), and thus everything that sets an upward velocity is not affected. Either way, if you ever wanted to add rather than overwrite velocities (which would cleanly solve Nepster's concern that explosions from above can actually save fallers, but also disallow certain other things that work under current physics), or have downward flingers, here's how the conversion between velocities and distances should be done:
Given the desired y-velocity v (of the flinger object; or in case we use addition rather than overwriting, the sum of the two y-velocities), we need to estimate the distance traveled s to achieve the velocity v under acceleration a (=gravity), starting with 0 velocity. This is computed via s = v²/(2a).

So if you want to stick with the 0.7.18 fix instead of fixing the underlying cause, I propose to make the following addition:
If a lix encounters a downward flinger that flings down with vertical velocity v, instead of initializing the pixels-fallen-counter with 0, initialize it with v²/(2a), where a is the gravity constant in the game.
That way we can have downward flingers of any speed with consistent physics, rather than some arbitrary velocity cutoff (currently somewhere undetermined between 2 and 24 pixels per frame) from which on we consider the physics to be weird and thus disallow faster downward flingers by convention.

[Simon]

Thanks for the thorough post. Agree that 0.7.18 splat rules take another step away from real-life physics, and that the tumbler is mediocre.

Initialize pixelsFallen with v²/(2a) is sensible. Under 0.7.18 acceleration and wall rebound, I can't set a max survivable speed, because in a tight vertical shaft, you could accelerate really fast without travelling down many pixels.

I feel too close to release to touch tumbler physics again. I'll keep rebound-and-continue and add-don't-overwrite in the back of my mind for the future.

-- Simon

[Simon]

Implemented in 0.7.22: Initialize pixelsFallen on downfling with the typical value. Since the physics are discrete and the speed increases by 1 or 2, I compute the pixels with a loop, not a formula. This is heavily unittested because it's fickle.

I've re-included the downsteam, but I'm still reluctant. I'd rather leave it out. Downsteam just kills everybody because it flings so fast.

Exploder fling is almost unaffected because of the desired Eat-My-Shrapnel effect: Even when you explode above a target lix, she is flung horizontally or even upwards. Typical-value-pixelsFallen-initializtion has mainly an effect on downflinging gadgets.

-- Simon