Lemmings Forums

Lix => Lix Main => Topic started by: Nepster on June 25, 2016, 12:03:16 PM

Title: MaxFallHeight for tumblers inconsistent
Post by: Nepster on June 25, 2016, 12:03:16 PM
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)
Title: Re: MaxFallHeight for tumblers(?) inconsistent
Post by: Simon on June 26, 2016, 05:40:13 AM
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 (https://github.com/SimonN/LixD/issues/105)

-- Simon
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 12, 2017, 02:16:50 AM
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 12, 2017, 11:01:08 PM
From IRC:

Quote
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.

Quote
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Nepster on August 13, 2017, 11:08:28 AM
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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 13, 2017, 11:41:47 AM
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Proxima on August 13, 2017, 02:14:31 PM
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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 14, 2017, 08:13:12 AM
Thanks for the replay!

Quote
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: ccexplore on August 14, 2017, 10:39:49 AM
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?
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 14, 2017, 05:01:52 PM
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.

Quote from: IRC
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: ccexplore on August 15, 2017, 02:08:13 AM
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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 15, 2017, 02:25:22 AM
Quote from: ccx
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:
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!

Quote from: ccx
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: ccexplore on August 15, 2017, 03:10:32 AM
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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Proxima on August 15, 2017, 11:56:02 AM
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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Nepster on August 15, 2017, 05:34:48 PM
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?
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Proxima on August 15, 2017, 05:38:13 PM
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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 16, 2017, 01:23:34 AM
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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: geoo on August 19, 2017, 12:44:59 PM
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 = v2/(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 v2/(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.
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 19, 2017, 09:57:55 PM
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 v2/(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
Title: Re: MaxFallHeight for tumblers inconsistent
Post by: Simon on August 20, 2017, 09:05:32 AM
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