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.