Bugs/rants from 2015-09-27 session

[Simon]

Hi,

I've played some more of IchoTolot's nice pack. Here's the daily digest about NL.

This write-up has become slightly more ranty than I wanted, again. >_> Let's call it a side effect of thorough issue reporting. I don't believe anything here is critical, and NL2 with mappable hotkeys is more important.

Arrows moving backwards: The L1 hell set and the NL space tileset both have one-way arrows moving backwards. The arrows point in the correct direction, but move in the wrong direction.

"It has always been this way": Not an argument during a comparison with L1, even if it's like this in the L1 data files. The arrows that point to the right, but move to the left, are never used in L1. Rotten Egg, and One Way Digging To Freedom, both have only left-facing arrows. Maybe the L1 devs have never noticed this error, because the gadget was never used. They have cared about detail for proper arrow animation in the other sets.

Athlete unspecified: I believe this is already on the menu for NL2. Athlete is a useless description of a lemming, because unlike in L1, there is more than one possible combination of >= 2 permanent abilities.

Climber passes through low horizontal bars: See image below.



Assign climber while a lem is walking up to the terrain setup. It will pass right through the horizontal bar, and continue climbing.

This bug was already in L1 and vanilla Lemmix. The NL builder checks for terrain with all of its body, but the climber is still allowed to pass thorugh terrain entirely.

Expected instead: Climber cannot pass though the horizontal bar. They fall/turn immediately, or don't even start climbing in the first place.

Ignore climbers when assigning climber: Have lem #1 and lem #2 both under the cursor. Assign climber to #1. Try to assign climber to #2. The game doesn't assign anything to #2.

Expected instead: Clicking on the bunch several times should assign this many climbers, and ignore already-climbable lems when finding out whom to assign.

Select only walkers: Assign climber to lem #1, assign climber to lem #2. Assign digger to lem #1. Have #2 in this digger pit as a walker. Hold Shift (= the NL key to perform what is mapped to RMB in L1: select only walkers) while trying to assign builder to #2.

The game doesn't highlight any lemming, and doesn't assign builder.

Expected instead: Assignment to #2, because it's a walker, and the Shift feature is described explicitly as "select only walkers", not "priority invert".

Preferring to implement select-only-walkers" over priority inversion is a different problem. There are times when select-walkers is better, but almost every time, priority invert is better. Priority invert would solve the case at hand.

No-overwrite default for gadgets in editor: Strikingly often, level authors forget to set no-overwrite for exits, traps, etc. This obscures builder bridges behind the gadget. In 95 % of the cases, no-overwrite is the wanted flag. For gadgets sitting on perfectly flat terrain, there is no visual hint in either editor or game that this problem will occur with the overwriting gadget.

So, on adding a gadget in NL editor, check no-overwrite as a default.

Error on missing music: Missing music should not prevent playing a level, and not generate a message box. Only use message boxes for critical events -- i.e., data is about to be lost. Missing music is not critical. If you absolutely need to report the error, display it without resorting to a modal box, or log it.

Replay overwritten without warning: Pressing [U] to save a replay overwrites any existing file with the same name. Here, data is lost, but no message box is generated! Replay saving might use a save browser widget anyway.

-- Simon

[namida]

The L1 hell set and the NL space tileset both have one-way arrows moving backwards. The arrows point in the correct direction, but move in the wrong direction.

"It has always been this way": Not an argument during a comparison with L1, even if it's like this in the L1 data files.

In the case of the Space (and Horror) tilesets, this is an intentional design decision. The argument perhaps holds more water (or, fire?) for the Fire set, and this is something that could be considered for changing.

Athlete unspecified: I believe this is already on the menu for NL2. Athlete is a useless description of a lemming, because unlike in L1, there is more than one possible combination of >= 2 permanent abilities.

Currently, Alt + mouse-over will reveal the exact combination of abilities; and yes, an improvement over that is planned for NL2.

The text that appears with Alt+Mouseover takes the form of five characters, which are replaced with a dash in the case that no letter of that slot applies:
1. "C" for a climber
2. "S" for a swimmer
3. "F" for a floater, or "G" for a glider
4. "D" for a disarmer
5. "Z" for a zombie, or "G" for a ghost

<climber stuff>

Yes, I've always had some difficulty deciding (and implementing) exactly where the balance should be in terms of what climbers can or can't get past, and indeed, that seems like a situation where they shouldn't. A less-obvious case might be if there's one pixel sticking out from the terrain, but it's at a very low height, such that a Jumper could also get past it.

Ignore climbers when assigning climber: Have lem #1 and lem #2 both under the cursor. Assign climber to #1. Try to assign climber to #2. The game doesn't assign anything.

This is something that should be addressed, indeed.

Select only walkers: Assign climber to lem #1, assign climber to lem #2. Assign digger to lem #1. Have #2 in this digger pit as a walker. Hold Shift (= the NL key to perform what is mapped to RMB in L1: select only walkers) while trying to assign builder to #2.

That'd be because you're pushing Shift, while expecting the functionality of Ctrl. Shift = assign to a lemming that has previously not received any skills (exists primarily for the one-skill-per-lemming challenges).

In regards to a proper priority invert, this is something that could be added in NX2 for sure. What's your thoughts on how exactly it should function - choose from the least-prioritized lemmign then work backwards? Or L1-like, where only the two highest priority lemmings are considered, but the second-highest has priority over the highest? Etc?

No-overwrite default for gadgets in editor: Strikingly often, level authors forget to set no-overwrite for exits, traps, etc. This obscures builder bridges behind the gadget. In 95 % of the cases, no-overwrite is the wanted flag. For gadgets sitting on perfectly flat terrain, there is no visual hint in either editor or game that this problem will occur with the overwriting gadget.

This makes sense, and could be easily done in an update to the current editor. I'll add it to the suggestions list.

Error on missing music: Missing music should not prevent playing a level, and not generate a message box. Only use message boxes for critical events -- i.e., data is about to be lost. Missing music is not critical. If you absolutely need to report the error, display it without resorting to a modal box, or log it.

That's fair enough; I'll make the change in the upcoming V1.35n-D update so that missing music simply results in silence, not an error. Though most likely, the message box will remain (at least for NX1), because in the primary usage of NeoLemmix - that is, large custom packs - this is something that should be strongly brought to the creator's attention while creating their pack.

Replay overwritten without warning: Pressing to save a replay overwrites any existing file with the same name. Here, data is lost, but no message box is generated! Replay saving might use a save browser widget anyway.

The default beahviour is to auto-name the replay files; there is an option in the config screen to open a save file dialog instead.

[Simon]

Whoa, fast response -- thanks.

Shift/Ctrl: I didn't know this. I was happy when Icho told me Shift did something related to what I want, and have used it ever since. I'll have to experiment with Ctrl the next time I'm over at his place.

Best priority invert: I'm rather biased and believe my own version is the best, but I want to thoroughly review my own version when it comes around in the D port. The priority code is a huge mess in C++ Lix, despite me liking what it does. I believe it inverts everything except distance from the center of the mouse cursor. I feel this warrants a separate topic later.

Backwards arrows: I'd be interested in the design decision to make backwards-scrolling arrows. I was pretty confused from these arrows coming up in Icho's adaption of the Castle tileset. Icho said he'd always look for the arrow tips; apparently, I glance at the motion instead.

-- Simon

[namida]

Now is perhaps a good time to discuss one-way arrows for NX2; as I'm already planning to strongly modify how they work from a graphic set / technical point of view (in particular, making them much more like steel areas than like objects, albeit with a visual component), and am currently working on graphic set code. I'll start a topic about it.

[ccexplore]

Backwards arrows: I'd be interested in the design decision to make backwards-scrolling arrows. I was pretty confused from these arrows coming up in Icho's adaption of the Castle tileset. Icho said he'd always look for the arrow tips; apparently, I glance at the motion instead.

I'm pretty sure at least one (actually, most?) of the sets in L1 has OWW whose motion is back-and-forth rather than a single constant direction.  And then there are cases like Cheapo where IIRC the arrows don't move at all.  So in terms of precedence, Icho's correct to recommend looking for the arrow tips.

I'll grant you that having the arrows moving in a constant backward direction do seem like an unnecessary point of confusion, even if it probably won't confused anyone used to looking for the arrow tips.

[Simon]

I'm pretty sure at least one (actually, most?) of the sets in L1 has OWW whose motion is back-and-forth rather than a single constant direction.

The back-and-forth moving arrows in L1 have a special bouncing movement. Assume right-pointing arrows. These move quickly to the right, slow down, start moving slowly to the left, accelerate, and then bounce sharply at their leftmost point, moving quickly to the right again.

This bounce is noticeable without concentrating on it, and the bouncing animations in L1 are consistent with directions all the time.
 

cases like Cheapo where IIRC the arrows don't move at all. So in terms of precedence, Icho's correct to recommend looking for the arrow tips.

I'd rank the fixed arrows as clearer than the backwards-moving arrows. They offer nothing to look at but the arrow tips.

-- Simon

[namida]

So - it seems full animation is preferred, but that in the case where the animation is perceived as problematic, fixed is considered at least an improvement. As such - perhaps continue to allow full animation, but allow an option to disable the animation (and just display one constant frame)?

[Simon]

I'd place the burden on the animation designer. The proper direction of movement should be a guideline, as is drawing arrows in the first place instead of other shapes.

The option will only be necessary if convention-violating animations continue to exist.

Icho didn't feel this was important enough to fix immediately, whereas I would have jumped at the chance to edit the single animation file. I didn't want to dive into the tools that bind graphics into a blob.

-- Simon

[Simon]

Replay overwritten without warning: Pressing [U] to save a replay overwrites any existing file with the same name. Here, data is lost, but no message box is generated! Replay saving might use a save browser widget anyway.

The default beahviour is to auto-name the replay files; there is an option in the config screen to open a save file dialog instead.

A popular solution for automatic naming is: If the desired file already exists, do not overwrite, but add -1 or -001 near the end of the filename, before the extension. If that exists too, increment to 2, etc.

Basically, I believe default options should never step on people's toes. Dangerous behavior must be desired first.

-- Simon

[ccexplore]

The back-and-forth moving arrows in L1 have a special bouncing movement. Assume right-pointing arrows. These move quickly to the right, slow down, start moving slowly to the left, accelerate, and then bounce sharply at their leftmost point, moving quickly to the right again.

I believe you, but to be quite honest, before you pointed it out up there, I personally simply had not remember off top of my head that level of details of the motion as you described above.  It would appear that for whatever reasons I had always focused primarily on the arrow tips and much less on the motion.

That of course doesn't invalidate the point that there do exist people including you who find the motion to be a much stronger cue, so perhaps an option for no animation is best, though certainly the existing animations for the included sets (specifically the Hell one that caused trouble for Simon) can be updated as well to correct the unexpected motions.  Restricting the set of movements in the general case (as namida mentioned as one proposal) may prove undesirable as there may be all sorts of interesting, non-confusing animations one may wish to do that for their OWW graphic outside of motion of the individual arrows (eg. changing colors over motionless arrows; motion depicted by movements of colors/shading/brightness rather than full motion of the arrows; etc.)

[namida]

Fair enough. Let's strike the "fixed motions" off the table, and consider other options - such as whether or not to have a "disable one-way arrow animation option" (which as well as for people who find animation of them confusing, could also be useful for those on weaker PCs).

[namida]

Regarding the climber issue mentioned here - any suggestions on what should be checked / should happen? I'm thinking of going with a solution where, if he'll climb one "step" then hoist immediately, allow it (similar to walkers (or jumpers) moving up through a very small amount of terrain, which is a long-accepted behaviour), but if he would start a second "step" when there's an obstacle in the way, he falls. (For that matter - is this really that different from such a case? Does it actually need to be fixed, or is it more consistent for similar behaviour to occur here?)

As per the suggestion here, I have modified NeoLemmix (for the V1.35n-D release) to simply give a warning on missing music, instead of crashing. If you hit OK on the warning, the level continues as normal (except without music). The warning will not show up if you have music disabled.

[Nepster]

1) Climber ignoring the lowest 6 pixels of terrain
Just to give an example of the current behaviour, I made a little level TestClimber.lvl (just watch it and do nothing; if you want some fun, try to predict the path the lemming takes ).
namida's suggestion (to allow climbing through terrain when hoisting immediatly afterwards) would make the conversion of L1/Lemmix/Lemmini levels easier, but adds another rule (i.e. makes gameplay more complicated). And I don't yet understand what would happen in my test level? Would the lemming try to climb and behave (at least for the very first part) as in the current version, or does he simply turn around? I feel that simply turning around would be more appropriate.

2) Climber and very small overhangs
See the attached picture: When digging down a miner shaft, one or two pixels remain at the top. Thus currently there is precisely one side of the digger hole that a lemming may use to climb out. In L1/Lemmix/Lemmini the opposite happens and lemmings can always climb both sides (due to slightly different digger mechanics).
So the question is: Should the climber be able to ignore such very small overhangs (consisting of only one or perhaps two pixels)?
Arguments for NO (current NeoLemmix mechanics):
- Simpler rules, i.e. no exceptions.
- New trick to turn around climbers (without having to use builders) that can be exploited in levels.
Arguments for YES:
- The current behaviour may break old levels without having an easy fix or introduce new backroutes.
- IMO letting lemmings climb out on both sides creates more interesting design options.
I can live with any of the options, but feel that we should be aware of the consequences of our choices.

[Proxima]

No, because the overhang is visible and the player would expect it to block a climber. When it fails to do so, the player won't be clear about what the specific rule is.

Surely the best solution is to tweak the digger mask so it no longer leaves that single pixel?

[ccexplore]

I think one of the closest analog here may be how builders currently react to ceilings.  As you know, builders have a "floor check" and a "ceiling check".  And if things start off with the ceiling thin and already below top of head of the lemming, the ceiling check is effectively bypassed (because the top of the lemming's head has "poked through" the thin ceiling into air), allowing the lemming to "build through" a thin platform until the floor check is triggered.

That's not to say the climber should have that sort of behavior, but using that analogy, currently the climber has a similar sort of "ceiling check" but no corresponding "floor check".  One can either add a floor check, or modify the ceiling check to check for very low ceilings that are below top of head of the lemming.

A side question related to this is whether a lemming that is already hoisting should have the same checks (since terrain can be dynamically added while hoisting) as a climbing lemming.  Given that I believe NL already has skills like stoners that can add a relatively thick chunk of terrain overhead instantaneously, the answer here is probably "yes" if it isn't already so.

Surely the best solution is to tweak the digger mask so it no longer leaves that single pixel?

Maybe.  Unless that has been changed, under original game mechanics, the first dig stroke (immediately upon assignment) already takes out something like 2 additional rows of pixels above ground level, I'm guessing making it take out one more row can prevent the overhang creation--for the miner slope anyway.  Obviously if you start considering steeper slopes, the amount of such additional rows for the digger to take out initially may become a little questionably too much.

Doing it for just the miner slope may still have merit especially if it is currently pixel-precise (depending on where exactly you started digging) whether you end up with the overhang or not.  Having the outcome differ in that way is probably undesirable regardless of whether you want to consistently get the overhang versus never.  That said, again once you start considering other slope angles (or more irregular terrain), it may become more difficult to enforce even such consistency.

[Nepster]

Surely the best solution is to tweak the digger mask so it no longer leaves that single pixel?

As far as I know, the digger mask for the first stroke was changed from 2 addictional pixels to only 1 pixel. As this change was deliberately made, I expect that namida has very good reasons for this and therefore refrained from suggesting to undo this change.
And the current mechanics always leave this overhang, independantly of the starting position.

One can either add a floor check...

Adding general floor checks (or low ceiling checks) might create problems with terrain additions, e.g. via building stairs/platforms against the wall. I would add such checks only for the very beginning.

[ccexplore]

Adding general floor checks (or low ceiling checks) might create problems with terrain additions, e.g. via building stairs/platforms against the wall. I would add such checks only for the very beginning.

Can you provide a more specific example of what problems you have in mind?  My suggestion for adding floor/low-ceiling checks is still specifically about climbers and hoisters, not every possible action.  If we want consistency, it's not clear to me why it should matter that the terrain is pre-existing versus added via a skill.  Having checks happen only at the start seems like the same kind of "adds another rule (i.e. makes gameplay more complicated)" situation that you were objecting to earlier when discussing namida's proposal.

[IchoTolot]

For me it is simply logical and easy to understand even for beginners that the digger and climber behaves this way (taking out terrain starting from the diggers height level and stopping if there's a pixel above him). I think this is perfectly fine as it is currently.

[Nepster]

Adding general floor checks (or low ceiling checks) might create problems with terrain additions, e.g. via building stairs/platforms against the wall. I would add such checks only for the very beginning.

Can you provide a more specific example of what problems you have in mind?  My suggestion for adding floor/low-ceiling checks is still specifically about climbers and hoisters, not every possible action.  If we want consistency, it's not clear to me why it should matter that the terrain is pre-existing versus added via a skill.  Having checks happen only at the start seems like the same kind of "adds another rule (i.e. makes gameplay more complicated)" situation that you were objecting to earlier when discussing namida's proposal.

The word "general" in my previous post was intended only for climbers (ans possibly hoisters), i.e. in situations like the one in the attached picture, I think the climber should continue. The reason is the following:
Let's consider the opposite action: removing terrain. If you remove terrain at the lower half of a climbing lemming, he will continue climbing. This indicates that only the upper half of a climbing lemming counts for determining its position and whether he should continue climbing. So after adding terrain in the bottom half, the lemming should be above the added terrain. As stopping to climb and start walking on the added terrain is kind of weird, I am in favour of letting him continue on his climb.
As for a possible implementation: At the beginning failing the floor check should immediately turn the lemming around, because there is simply no wall to hang on to. On a successful floor check, he will be at least one frame in the climbing position. Once there one can apply ceiling checks to determine whether to continue climbing.

True, this suggestion has the disadvantage of "adds another rule", but I am not yet convinced that one can drop this rule. Furthermore while floor checks may replace namida's suggestion, the converse is not true. Even with namida's suggestion, one might need floor checks and has to decide when to apply them.

[ccexplore]

Let's consider the opposite action: removing terrain. If you remove terrain at the lower half of a climbing lemming, he will continue climbing. This indicates that only the upper half of a climbing lemming counts for determining its position and whether he should continue climbing. So after adding terrain in the bottom half, the lemming should be above the added terrain. As stopping to climb and start walking on the added terrain is kind of weird, I am in favour of letting him continue on his climb.

I actually had in mind that the interrupt from such a case of added terrain be same as the overhang case, so that the lemming would fall rather than ended up walking on the added terrain (unless there is terrain added underneath the lemming's foot to prevent it from falling).  Nevertheless, the point with the terrain-removal situation is a reasonable argument, and would at least suggest that the ceiling/overhang check should not be lowered all the way down.  But then by that reasoning, one can argue that maybe a sufficiently low overhang should be ignored too (ie. "by design, not a bug") when the lemming is just starting to climb.  The "removal terrain" analog doesn't quite apply in this case since the lemming still goes by walker rules until it actually reaches a wall to transition to climbing, unless we want to special case the first few initial frames of climbing to react differently with regards to terrain removed post-transition.

That's not to say we can't have a different rule during the transition moment that prevents the climbing from starting if there is already a very low overhang, but it's worth pointing out that it is actually an inconsistency (even if not necessarily a bad one) if we consider how the game does ceiling checks elsewhere.

As for a possible implementation: At the beginning failing the floor check should immediately turn the lemming around, because there is simply no wall to hang on to.

Are we still talking about terrain being added (or a pre-existing low overhang), or terrain being removed?  Again, one can argue that if the overhang starts off very low, the lemming's head and arms are already above the overhang while it is still walking, and therefore doesn't have to be affected by the overhang.  It would be a conscious choice to add an additional rule if we want such low overhangs to have an effect on whether the lemming can start climbing.  I can go with it either way.

[Nepster]

That's not to say we can't have a different rule during the transition moment that prevents the climbing from starting if there is already a very low overhang, but it's worth pointing out that it is actually an inconsistency (even if not necessarily a bad one) if we consider how the game does ceiling checks elsewhere.

True.

Are we still talking about terrain being added (or a pre-existing low overhang), or terrain being removed?

Mainly about a general guideline when to apply which terrain check against currently existing terrain, i.e. mainly concerning the first question in my first post here.

Again, one can argue that if the overhang starts off very low, the lemming's head and arms are already above the overhang while it is still walking, and therefore doesn't have to be affected by the overhang.

Again, one can argue in the same way for missing terrain pixels. But obviously we need floor checks that no terrain is missing before starting to climb and not just worry about terrain in arms and head height.

It would be a conscious choice to add an additional rule if we want such low overhangs to have an effect on whether the lemming can start climbing.  I can go with it either way.

Completely agree with you there. I think one can find good reasons either way and the main question is whether to go for a more versatile climber (current mechanics) or a more intuitive one (see Simon's first post). The longer I think about it, the more I am in favour of changing the climber mechanics even if that means that some old levels need to be fixed.
PS: Does anyone know an old level that cannot be fixed by slight terrain changes, once climbers are restricted by low terrain?

[ccexplore]

Again, one can argue that if the overhang starts off very low, the lemming's head and arms are already above the overhang while it is still walking, and therefore doesn't have to be affected by the overhang.

Again, one can argue in the same way for missing terrain pixels. But obviously we need floor checks that no terrain is missing before starting to climb and not just worry about terrain in arms and head height.

Hmm, I think the difference in how I see the "missing terrain" analog in this case is that even non-climber walkers will be able to walk into the narrowest of gaps.  So I see it not so much that "the lemming considered climbing, but did not do so because terrain is missing" as "the lemming never considered climbing yet at that point, because by normal walker rules, it can still continue walking forward just fine rather than having to turn around".

I wouldn't say it's even "obvious" when it comes to floor check.  Basically, your statement about a climber that can "ignore the floor" to start climbing is essentially an opportunistic/greedy climber, one that always check for opportunities to climb, rather than only when the default walking behavior does not give the "continue walking at same direction" option leaving only the options to turn vs climb.  For example, given the below configuration of terrain (L = where the lemming's at), a "greedy" climber that ignores the floor would start climbing up the wall rather than continue walking through the narrow gap.  It's definitely quite different from how climbers currently work, but if climbers had been implemented that way all along I don't think it would be considered as all that strange, it would just be what makes a climber a climber.

Code: [Select]


 XXXXXXXXXXXXXX
 XXXXXXXXXXXXXX
 XXXXXXXXXXXXXX
 XXXXXXXXXXXXXX
 XXXXXXXXXXXXXX
 XXXXXXXXXXXXXX
L
XXXXXXXXXXXXXXX
If normal walking behavior has cases that can turn non-climber lemmings around with "missing terrain" (ie. like Clones basically), then you do have a case where a non-greedy climber would make a decision whether it's okay to start climbing up with the missing terrain.

[namida]

Alright well, it seems there's a lot of disagreement on how exactly we should proceed on this - so I shall leave it as-is for the upcoming bugfix update. It's something that can be reconsidered in the long-term (ie: the 2.00 update).

[ccexplore]

Yet another way to look at this is to consider a very low overhang, and consider lowering the top of the wall until it is short enough to become a walkable step (where the lemming can just hoist itself up the step as a walker--more accurately a "jump").  An observation can then be made that the overhang did not affect the ability of the lemming to jump up a short step, but then once the wall is just high enough to require climbing, the same low overhang suddenly impacts the ability to start climbing.  It's not exactly wrong or strange, since we are after all looking at two different actions even if they are similar in nature (allowing the lemming to move vertically up), but it does open up the ability to reasonably argue that the same low overhang can be a non-factor when starting to climb.  Especially if we further add in the rule you suggested, that such a low overhang should be ignored later when the lemming is already climbing and the terrain changed to create the overhang at a low position relative to the lemming.

And if we apply "what if it's missing terrain" like Nepster is apt to, then we see that in both cases (step versus wall), the lemming continues walking rather than trying to jump/climb up past a gap into higher terrain.

Alright well, it seems there's a lot of disagreement on how exactly we should proceed on this - so I shall leave it as-is for the upcoming bugfix update. It's something that can be reconsidered in the long-term (ie: the 2.00 update).

To be somewhat fair, I think I'm the only one who's been pointing out that the low overhang having an effect on the climber isn't necessarily that obvious.  Even I am okay with the various proposals including the Lix-like behavior of preventing transition to climber on any overhang however low.  Maybe a better gauge is to determine how many levels would be affected (both positively as well as negatively) by the change, especially if we are talking about a v1.x update that are supposed to be more minor in nature.

[namida]

I'd consider it a final decision at this point that there'll be no change for V1.35n-D; but I fully encourage further discussion in regards to what to do in V2.00.

[Nepster]

Yet another way to look at this is to consider a very low overhang, and consider lowering the top of the wall until it is short enough to become a walkable step (where the lemming can just hoist itself up the step as a walker--more accurately a "jump")...

Good argument.

To be somewhat fair, I think I'm the only one who's been pointing out that the low overhang having an effect on the climber isn't necessarily that obvious.

And I agree that it is not obvious. And I seem to be the only one pointing out that low overhangs being ignored isn't obvious either (from a mechanical point of view).

Maybe a better gauge is to determine how many levels would be affected (both positively as well as negatively) by the change...

There will be quite a few negatively affected levels (e.g. regarding the brown stairs in the pillar style). Many of them don't require this climber mechanic, but it opens up more possibilities and alternative solutions.

...especially if we are talking about a v1.x update that are supposed to be more minor in nature.

Never realized that we were arguing about a V1.x update.

[Simon]

I was with Icho yesterday, and we agreed how any overhang should cancel climbers. The rule should be as simple as possible, which makes the path tracable by eye much more easily.

The rule to become climber is separate from the rule to remain climber. I have been happy with the Lix rule for 9 years now:

Code: [Select]

walk walk walk
if (cannot walk forward)
    if (ridge is ascendable)
        become ascender
    else if (lem can climb && no low overhangs)
        become climber
    else
        turn walker

And there are no other (walker -> climber) transitions anywhere in the walker code. In particular, the climber is not greedy.

Icho believes the digger should not, under any circumstances, perform an overstroke (= remove terrain higher than his normal 1 row of 9 pixels). If no-digger-overstrokes creates a non-climbable overhang in a miner tunnel, that's perfectly fine.

Digger overstroke might appear to be reasonable to get overhang-free holes on bumpy terrain. But overhangs can be desired on bumpy terrain. To prevent overhangs as a designer, use flat terrain. To prevent overhangs as a player, dig on top of a bump, not in between the bumps.

-- Simon

[ccexplore]

The rule should be as simple as possible, which makes the path tracable by eye much more easily.

I think it may be overstating the difficulty of gauging overhang height, but it is fair point that never having to pay any attention at all to overhang height (even cases where it is so obviously low even at a glance) is by definition a little easier for path-tracing.  It is basically Proxima's argument but shifting from "ease of learning/understanding the physics" to "ease of tracing paths by eye".

[geoo]

Re: Climber passing through low horizontal bars:
Honestly, I'd just leave it as is. The climber has the ability to climb, and with it comes the ability to hoist up slightly higher ledges than normal guys. If you really want to rot this behaviour out, have a check for terrain not only at the top pixel, but also the three pixels below, but as I said, I don't think it's necessary. (I think one of my better Lemmix levels would break if this were changed, but I don't care all that much about them at this point.)

Re: little edge left by digger in miner tunnel:
A climber should certainly not be able to get past such ledges. The fix should either be in the digger, or the issue be left as it is. (I don't see why the digger mask has been changed to remove less terrain above the digger. If there's a good reason I'd like to hear it.)