MaxFallHeight for tumblers inconsistent

[Nepster]

Attached a level with a runner, who jumps, tumbles against a wall and then hits the floor. Jumping in frame 88 allows the lix to survive the fall, while she dies for frames 87 and 89. The y-coordinates of the starting position are the same in all cases.

(replays made using D-Lix V0.6.2)

[Simon]

Explanation: The tumbler has a speed vector, this determines how far the tumbler travels per frame. The vector's y component increases each frame, to simulate gravity. When a tumbler flies into a wall, she aborts movement in that frame prematurely, turns, but doesn't continue to fly yet. In replay-87 and replay-89, the lix is airborne for one frame longer than in replay-88, because she wastes lots of potential travelling distance turning at the wall.

Instead of from distance fallen, tumblers die from impacts at a certain y-speed. In replay-87 and replay-89, she builds y-speed for one frame longer than in replay-88. This extra speed pushes her over deadly y-speed.

I should probably continue flying in the same frame after turning.

Issue #105

-- Simon

[Simon]

Finally, I've found a reasonable fix for this tumbler inconsistency from June 2016.

0.6: When non-floatable tumblers hit the ground, they splat if their y-speed exceeds a constant.

0.7.18: Tumblers remember how many pixels they have moved downwards since (they got flung for the last time, or since they moved upwards, whatever of these happened later). When non-floatable tumblers hit the ground, they splat if the fallen hi-res pixels exceed 126.

Reasoning: I remember how I chose C++ Lix's safe-speed-constant by trial and error: I wanted it as large as possible, but not allowing longer falls than the faller. Now, for 0.7.18 and beyond, I've set the tumbler-safe-distance-constant to 126, equal to the faller's safe-fall constant. This is perfectly in spirit with the original design in C++ Lix.

Compared with C++ Lix and D Lix 0.6, tumblers become minimally sturdier in 0.7.17: Without rebounding from a wall, they survive 4 more hi-res pixels than before. With rebounding from a wall, 0.6 tumblers were inconsistent anyway, they died slightly earlier than meaningful. But fixing this inconsistency was the point of the change.

All singleplayer levels remain solvable.

-- Simon

[Simon]

From IRC:

22:20 <geooo> Simon: what about downward steam? Now means surviving at very high downward speed.

I consider downwards steam a problem of its own. The lix fall downwards on their own, they don't need steam for that. If you want to kill lixes, use fire instead of downwards steam.

I'd even remove the downwards steam tile altogether? Only 3 singleplayer levels have downwards steam: Goblin City, Goblin City's repeat with the Japanese name, and 100 Ways to Die. In all 3 cases, it's pure decoration. No multiplayer maps use it. Ramond's geoo's Playground used the downwards steam to shoot lixes onto trampolines, which aren't supported in D Lix.

Alternatively, I'll re-introduce max-speed as a second killing check (either distance or speed can kill on their own), but set max-speed faster than in 0.6.

22:21 <geooo> And your implementation is consistent between upwards tumblers bumping or not bumping into a wall (I.e. they reach the same max height?)

Yes, tested that. Whatever I chose for the max-fallen constant, either all of Nepster's 3 maps killed the jumpers, or all 3 let them live.

-- Simon

[Nepster]

In 0.6 one could save fallers by assigning a fling-bomber directly above them, when they were only a few pixels above the ground. This is no longer possible after your change, correct? If so, then I approve of your change even more, because this behavior didn't make sense to me in the past.

[Simon]

No. 0.7.18 tumbers' number of pixels fallen resets whenever they're flung anew.

I could carry over tumblers' and fallers' pixels fallen to the new tumbling after flinging them anew, and only reset pixels fallen when tumbling upwards. Hmm.

Still leaning to cut the downwards steam even with that physics. That wouldn't solve downwards steam, merely exploding from above. The exploder's center of flinging is slightly below the exploder's foot because that's funnier, therefore you could still save lixes when the exploder is only slightly above the faller.

-- Simon

[Proxima]

I used the "fling-bomber directly above" behaviour to solve D12 Alternative Route Required. However, I've now found a solution that doesn't depend on that behaviour. Now I think this is a cleaner solution, and my original may be a backroute that should be prevented, so I'd be happy for the physics to be changed. Also, my new solution is conceptually simpler, but it took me longer to find, so I'm happy for the level to stay at its current position.

There is one downside to changing the behaviour: you could still save all the lix by fling-bombing with the bottom faller if they were close enough, so the player may spend a long time attempting this before realising it's impossible.

[Simon]

Thanks for the replay!

In 0.6 one could save fallers by assigning a fling-bomber directly above them, when they were only a few pixels above the ground. This is no longer possible after your change, correct?
---
carry over tumblers' and fallers' pixels fallen to the new tumbling after flinging them anew, and only reset pixels fallen when tumbling upwards

I've test-implemented (tumblers retain pixels fallen when flung anew, reset only when flinging upwards), no release yet. Problem: The horizontal transportation beams in Downpour (in lemforum Quirky). Lixes travel slowly down-right in the beams before the exit. They look safe, but they have fallen many pixels already before the beams caught them, therefore they will splat.

Will ponder this for 1-2 days. We could adapt Downpour with up-right beams instead of down-right, but the problem is more fundamental. Down/left/right beams should catch lix safely.

-- Simon

[ccexplore]

Hmm, so maybe always reset pixels fallen whenever a beam caught a lix?  Or are you worry about that being inconsistent with re-flinging now requiring an upward tumble to reset pixels fallen?

[Simon]

Yeah, special-casing between exploder-flinging and steam/beam-flinging is one way out. Ideally, I'd love to find a simple rule that governs all cases. Maybe there is no such rule.

SimonN: tumbler's death decision is fascinating and surprisingly hard. Few ideas cut the mustard
Proxima: :(
SimonN: maybe steam/beams should reset pixelsFallen and flingploders don't
SimonN: but ideally, all flings are the same
Proxima: or cull Downpour :P
SimonN: Downpour is perfect to test our assumptions
SimonN: I like Downpour. I'd still discuss cutting Downpour if you feel like that, but we must solve the general fling issue nonetheless

(Proxima probably not serious about culling Downpour. The level was misleading in the past, it has been more straightforward since.)

-- Simon

[ccexplore]

Is it at least the case that all the steam/beam-flinging cases that should be "safe" would've all at least reduced the downward vertical velocity of the lix (if a case doesn't outright change it to upward)?  Pondering whether then perhaps it would work to change the reset for explosion re-flinging, to be based on merely an upward difference between the old and new vertical velocity vectors, rather than strictly requiring the new vertical velocity to be upward?

In stating this, I'm assuming the behavior Nepster was objecting to (explosion directly above the lix getting re-flinged near ground level, resulting in unexpected safe landing) would've increased the downward vertical velocity of the lix.

edit: I should add that I'm not very well-versed in the specific mechanics of beams and steam.  Perhaps it would be helpful to compare how their interactions with a lix differs from the explosion re-flinging, particularly in terms of resulting trajectories.  Ideally we want to avoid situations where a steam/beam flinging looks and affects the lix very similarly to, or even identical to, a setup with explosion flinging, yet differs in survivability.  In other words, difference in survivability should ideally be explained purely in terms of differences in the trajectories, rather than types of flinging.  That being said, if this ideal proves too difficult to achieve, I'd still consider special-casing.

[Simon]

I'm assuming the behavior Nepster was objecting to (explosion directly above the lix getting re-flinged near ground level, resulting in unexpected safe landing) would've increased the downward vertical velocity of the lix.

I believe your assumption is incorrect, and that Nepster criticizes the following behavior 0.6 and 0.7.18:

• Have a lix fall from far above, or tumble from far above with large downwards velocity.
• Shortly before the lix hits the ground, explode a second lix nearby.
• Explosion overwrites the first lix's fling velocity entirely. Even when the exploder-effected fling velocity is downwards, it's never deadly according to 0.6 rules.
• The first lix lands safely.

The test-implemented behavior is (tumblers retain pixels fallen when flung anew, reset only when flinging upwards). This sounds like it will feel weird anyway: Even when your exploder effects an almost-zero velocity, it's important whether the velocity had an upwards component.

I like the downwards beams (2 hi-res-pixels down per frame), but I don't like the downwards steam (a deadly 24 hi-res-pixels down per frame). I would like to remove the downwards steam.

I'm now leaning to the 0.7.18 behavior (reset pixels fallen whenever flung anew), and discard the test-implemented behavior. But that accepts a mechanic considered weird by Nepster. I'll give Nepster a couple days to evaluate this discussion!

difference in survivability should ideally be explained purely in terms of differences in the trajectories, rather than types of flinging

The downwards beams produce straight downwards trajectories. When the lixes leave the beam, they continue tumbling from there, usually straight down, with minimal-then-increasing velocity. This looks perfectly survivable near a floor.

Nearby exploders in suitable positions overwrite the fling entirely, possibly to zero velocity. The resulting flinger looks perfectly surviving near a floor.

Maybe exploders should not overwrite velocity, but add to it? Overwriting seems more fun. I'm a sucker for cartoon physics. >_>;;

-- Simon

[ccexplore]

I see.  To be honest, to some extent this feels a little like the same kind of weirdness some people might have with, say, late-assigned floaters (unless this is different now in Lix compared to Lemmings).  Certain things, be it a beam, explosion flinging, or assigning a floater, can abruptly affect fall survivability, and there are bound to be a few cases where things look a little strange as a result.

Perhaps the problem is that the beam case resets the downward velocity to a value strictly slower than normal falling/tumbling, while the explosion flinging doesn't (or does it)?  Just wondering if there's still any sensible case to be made to tie the reset of fall distance based on the new velocity being "safe", for some definition of "safe" that can still include some small amount of downward velocity.

It does seem like unless we completely get rid of the ability for explosion flinging to reset pixels fallen, there will always be edge cases for it that can feel like late-assigned floaters.  Like Simon said, it seems difficult to sensibly argue the difference between a 0.0001 new upward velocity versus 0 versus -0.0001 downward, when the trajectories would all probably look near identical when close enough to ground level.

Anyway, looking forward to see what Nepster thinks.

[Proxima]

Another point is that you can make lix survive a fall by batting them near the bottom, and this is used in some intended solutions in the pack.

[Nepster]

Anyway, looking forward to see what Nepster thinks.

I basically agree with everything said so far, but have no good solutions either.

Yes, surviving the fall if battered around, flung aside or being caught in the downpour makes sense and should be kept.
Yes, if fling-bombers would add to the velocity and the original speed criterion would be kept, this would be the most natural fix for the "downward-fling to survive" issue. But then the original but resurfaces.
Yes, if we count fallen pixels, then we probably need special-casing if we want to remove "downward-fling to survive".

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