2.00 Physics inconsistencies

[namida]

With a major rewrite, which even if designed to be identical is probably a good time to re-test packs before releasing them on the new engine, I'm wondering if some inconsistent physics details should be tidied up?

In recent times, I've tried to shy away from major changes where possible. A few have been unavoidable to fix otherwise-exploitable situations, as well as others that relate to very recently introduced behaviour so aren't likely to break a lot of levels (eg. the fix to ghost digger + normal walker interaction), but for the most part, these have become rarer and rarer recently.

Some of the still-existing ones are, at least as far as NX1 is concerned, remaining unfixed for now not so much because they shouldn't be fixed, but because the impact on existing levels - either in terms of invalidating existing solutions, or opening up new backroutes - is disproportionate to the severity of the bug itself. One example would be the bug that carried over from Lemmix and went unnoticed all this time, of that traps (and by extensions, teleporters, which function very similarly to traps apart from relocating the lemming instead of removing it) skip the first frame of their animations when triggered - while this is probably not how they should behave, it is how they always have behaved in NeoLemmix so far, and thus levels have at least been designed (even if not conciously so) with this in mind. Another recently-noticed one which I'm opting not to fix for now, is closely related to the trick (whether or not it counts as a glitch is debatable; NeoLemmix has never considered it to be one) of how in some cases - either via dropping in from overhead, or coming up from underneath on a very steep slope - a lemming can slip by a blocker unaffected. While this is acceptable and even generally considered to make sense in the case of a blocker, a similar situation occurs with zombies, where a non-zombie lemming is placed on a slope as a blocker, and a zombie comes down towards it from above - the zombie will turn around, but will not infect the blocker.

As mentioned before, these all fall into the category of "bugs that are better left unfixed due to the potential impact on existing NeoLemmix levels being more severe than the exploitability or illogical-ness of the bug". But, should these kind of things be tidied up for NX2's initial release - which is probably a very good time to re-test any content anyway? Or should it be left until a later revision (if touched at all), which means further checking of the content - something that cannot be relied on as much with a "one program loading data files" setup, compared to in NX1 where (at least in the case of larger packs made with Flexi, which has been the dominant method of content distribution so far) a pack is tied to a specific EXE version (and thus a specific set of physics) until / unless the creator updates it to a new version, at which point they have presumably tested it with the new version?

(On the other hand, do keep in mind that NX2 will likely have more powerful tools than NX1 for checking packs' working with newer versions, such as mass replay testing.)

[Simon]

If you're going to fix these at any point, fix them as early as possible.

Backroute proneness: Trap frameskip won't affect solutions much. There was a Lemmix level about clustering fallers/floaters past 2 chameleons; that would get easier. But this fix doesn't reek like backroute fertilizer.

Gimmicks aren't used much in legacy levels. They're seeing use in contemporary levels, where the author is still around and can do testing on their pack.

The alternative is to treat them as features and never fix the bugs.

-- Simon

[IchoTolot]

I can't think of a level which would break if the trap+blocker behavior is changed.
The blocker one was just annoying sometimes (you can't place a blocker here; put it elsewhere!) and the trap one will make a few levels a LITTLE bit easier.

So personally I would approve these two fixes, but would not encourage further physics changes due to possibly broken levels. But if there are any more of these little ones which are just a bit annoying and won't break sth, go ahead!

[mobius]

the blocker not effecting zombie on slope sounds like something I would tidy up for NX2's initial release. Honestly I have yet to run into any real current game breaking bugs. But I have been designing levels to less rely on precise


I apologize if you've already fixed this or weren't refering to this sort of thing in this discussion; But I really hope you plan to fix the zombie count issue as soon as possible. I don't see this breaking anything, other than people having to fix their lemmings counts in their levels, but not all that many zombie levels exist yet, apart from yours. I'm assuming...

I'm sorry I keep bringing this up but it's just so confusing [and a little annoying] and seems totally wrong, imo. I wouldn't mind if this is fixed before my pack comes out. I'd have to edit all my levels with zombies in them but I wouldn't mind doing that, it would seem better then.

The other things seem minor to me and I wouldn't care too much if they aren't taken care of soon.

Since a lot of the new features are still "new" they still have not gotten real extensive testing. So I would expect glitches trickle in later rather than sooner.

[namida]

But I really hope you plan to fix the zombie count issue as soon as possible. I don't see this breaking anything, other than people having to fix their lemmings counts in their levels, but not all that many zombie levels exist yet, apart from yours. I'm assuming...

I'll revise that for NX2. It'd need changes to how levels are handled; however since I have outright stated that I won't be ensuring NX2 levels are compatible with NX1, this won't matter too much at that point. (The reverse isn't true - NX1 levels will be compatible with NX2.)

[namida]

A case that has come up - is blockers being immune to traps (and other objects). Should this be changed?

(See #lix chatlogs for 13/09/15, from 12:49:43 onwards)

I can't think of many cases where this would make a difference. The only case I can think of of a level (other than those explicitly invoking the trigger-area-cancelling glitches in L1) that exploits this is Psycho 24 of LPI; however this level is still very solvable without using this mechanic, it just requires slightly more precise placement of the blocker.

That aside, potential backrouting could maybe occur in levels that use locked exits - a blocker placed in front of them currently would be stuck there (unless freed via any of the usual blocker-freeing methods), but with this change, would exit as soon as the exit unlocks. This may not nessecerially be seen as a bad thing in terms of new level designs; while existing levels (if there even are any which would be affected by this) could perhaps use stackers or stoners instead of blockers.

[namida]

Another thing - if the physics are going to get a bit of revision, then it makes sense to do as much of the revision as possible in the first NX2 release. So as such - is there anything else that should be addressed?

I recall reading that Lix recently implemented a priority order during each frame, of what order the lixes would be processed in. I'm wondering if NeoLemmix should do the same; currently, action is completely processed for the first lemming (in order of spawning) before the second, who in turn is done before the 3rd, etc; regardless of what they'd do. And their action is carried out in full; including any terrain or trigger area addition or removal. This could lead to a situation like this:

1. You have three lemmings. Lemming 1 and Lemming 3 are in exactly the same position, Lemming 2 is slightly ahead of them.
2. Lemming 2 becomes a platformer exactly at the edge of a fall. When he gets to the frame where he actually places the brick, Lemmings 1 & 3 are also exactly at the edge by this point.
3. Because of the update order, Lemming 1 would fall (as the brick hasn't been placed yet when he's processed), while Lemming 3 would step onto the brick (because it *has* been placed).

Exactly how things should be divided, and what order they should be processed in, to resolve this, is a complicated question. But the first question is - should this be resolved at all? I'm leaning towards yes at this point; my first thought would be to avoid physics changes, but since the general consensus seems that there are several that should be made, then it makes sense that as many as possible are done at the same time (and in particular, with the new major version, which is a point at which levels should be tested anyway), rather than each update making another major change and breaking levels several times over. The only thing that follows on from that is, how far should this be taken? One could even argue that, since high-res graphic support is planned, that NX2 should implement a new set of high-res physics in place of the old ones (when I say "new", of course, I do mean strongly based on the old low-res ones) - which would also remove the need to support low-res at all. (At this point though, it'd also become questionable whether it should even keep the name "NeoLemmix", as it'd no longer have anything in common with Lemmix except maybe some very small snippets of specialised code (eg. DAT decompression, maybe); under the current plans it'd be carrying over NeoLemmix's mechanics which is a good reason to keep the name.)

[ccexplore]

A case that has come up - is blockers being immune to traps (and other objects). Should this be changed?

I can't think of many cases where this would make a difference.

I think you can create setups that rely on the immunity by, for example, having the terrain led lemmings to a trap via falling from above.  With the immunity, a blocker can be assigned to a lemming that just landed (while the trap is already triggered by a previous lemming), and the blocker is guaranteed to stay undisturbed by the trap forever.

To argue that immunity makes sense would seem to imply that trap triggers are some sort of motion sensor rather than just a simple proximity sensor.  If we take that interpretation, then it's not just blocker that have immunity; lemmings doing other actions can also have temporary immunity whenever they aren't changing position during the frame update.  I seem to recall that's actually exactly how the original game's physics was coded (that it typically doesn't bother to check for triggers, and not just trap triggers, unless the lemming has moved), so at least the current physics are likely quite consistent with the "motion sensor" interpretation, whether or not people feel the interpretation makes sense.

This can become more significant if (or maybe it's already the case?) the game expands its repertoire of object types so that there are more of them whose trigger can be dynamically disabled and enabled (eg. think switches that can affect linked objects).  The "motion sensor" interpretation also tends to make less sense for object types like water and "constant" hazards (but is currently a non-issue since you can't turn them off and on), so if the game ends up evolving in that direction where many types of objects can have their effects be turned off and on, you may find yourself ending up wanting to remove the immunity or at least do some tweaks in that area.

[namida]

I think, based on various things that have come up - as well as some recently-noted but fairly obscure bugs in NX1 - keeping consistent physics with the current NX1 ones is not an ideal goal, especially since if I were to do so, it'd just mean a need for physics changes later on to fix these bugs.

So since we're already probably going to be breaking at least some stuff - feel free to put out there anything else you feel should be changed.