Player V1.36n Pre-Release

[Simon]

Re: private test version sent via PM at 02:32 UTC:

I don't have a German keyboard. :-] And the system language is English. But I have most keys mapped around, maybe that's still useful for feedback.

Hardware-Capslock is mapped to Backspace. NL's hotkey dialog, click Find key, press hardware-capslock, the dialog highlights Backspace. Hardware-S is R, I press hardware-S, Find key finds R. This seems good; I expect similar good results on a German layout, as long as the bound function exists in the dialog.

Therefore, no idea what it does for keys that are bound to umlauts; hardware-semicolon is bound to ö on the German layout. Nepster/Icho might test this.

However, click Find key, press Hardware-arrow-left, which is mapped to arrow-left, it doesn't highlight anything and keeps the previously highlit list entry highlit.

The dialog presents , and . instead of < and >, both for hardcoded and non-hardcoded key names. This is good. I assume the non-hardcoded keys come from a Windows/Wine library, and they depend on the system language, which is English, not German.

With non-hardcoded keys, KP_Left is what you call Left Arrow. I can map stuff to that, and it's still triggered by the inverted-T arrows. So, find-key doesn't find the key, but the binding works during the game nonetheless.

The bindings that worked with find-key also work in the game: Find-key, press hardware-D, highlighting S which is correct under my layout, map builder to this. Start game, press hardware-D, it selects builder.

Icho has a German system and a German keyboard, maybe send him the version, too.

-- Simon

[Nepster]

The new version works very well with German keyboards, and symbols like "ö" and "ß" are displayed and correspond to the correct keys. I have only two small remarks:
1) The key description of the NumPad keys is now "1 (ZEHNERTASTATUR)" (with the longest being "KOMMA (ZEHNERTASTAT"), which do neither fit within the space in the list nor after the "Editing key: ...".
2) With the "Find key" option, the correct key is highlighted in the list. However one does not directly jump to this key, but has to scroll through the list and find the highlighted key manually. Not sure, what the behaviour was in the previous V1.36 and whether this behaviour is intended or not.

PS: Perhaps wait for another day or two before releasing the final version of the Toolkit, because I am currently testing it by creating a new beta version of NepsterLems. So far things look good, but you never know...

[namida]

The new version works very well with German keyboards, and symbols like "ö" and "ß" are displayed and correspond to the correct keys. I have only two small remarks:
1) The key description of the NumPad keys is now "1 (ZEHNERTASTATUR)" (with the longest being "KOMMA (ZEHNERTASTAT"), which do neither fit within the space in the list nor after the "Editing key: ...".
2) With the "Find key" option, the correct key is highlighted in the list. However one does not directly jump to this key, but has to scroll through the list and find the highlighted key manually. Not sure, what the behaviour was in the previous V1.36 and whether this behaviour is intended or not.

1. Does it at least show enough to distinguish all keys from each other? If it does, I would say that's good enough.
2. If you use Find Key, and it highlights the key, and you assign something to it (without scrolling to find it in the list), does it nonetheless apply the intended function to the key? I remember not being able to find a way to make it actually scroll to the desired option, but it should still select it and any changes should affect it...

And yep, that sounds like a good idea. I'll update these pre-release test versions to the latest, so you're building this updated test version with the latest code.

EDIT: Done. Just for the record - for now, worry about player bugs. Any bugs with the Flexi Toolkit itself (ie: the actual editing tool; not with the output created by it), unless very major, should of course still be reported but I'll fix in a seperate update.

[Nepster]

1. Does it at least show enough to distinguish all keys from each other? If it does, I would say that's good enough.

Yes, it shows enough. While checking, I realized that there is another slightly different (but again low priority) problem: In the list the key "STRG" (english "CTRL") appears three times, but both my "STRG"-keys point to one and the same element in the list. The same happens for a few more keys. As I have not yet found a key that points to the other "STRG"-entries in the list, this is probably not a big problem though.
Playing around a bit more, I noticed that the key "ALT GR" also points to the same "STRG"-entry in the list as the "STRG"-keys, likely because it evaluates as "STRG"+"ALT". Not sure at the moment, whether this causes any problems. 

2. If you use Find Key, and it highlights the key, and you assign something to it (without scrolling to find it in the list), does it nonetheless apply the intended function to the key?

That works fine.

[Nepster]

Just a brief feedback regarding the toolkit: Everything works very well now .
Nevertheless I discovered another little bug with the toolkit: In the scroller texts, one can type in almost every character. But the game itself can only display a very restricted character set, ignoring all other characters. So it would be good to have an automatic warning message, or at least the Issue Checker should return such a warning.
For the V1.36 one can probably live with this little bug, but it would be good to have this fixed in the big V2 update.

PS: The "ALT GR" key seems to work in all instances just as the "STRG" key, so no problem here.

[namida]

Bug reported via PM: Ghosts will not splat if they fall into water, even if it's a fall they wouldn't survive if there wasn't water there.

[Nepster]

While playing Doomsday Lemmings II, I found some more issues. Not all of them are bugs in the strictest sense and some of them may wait for NeoLemmix V2. (And I am a bit sorry for the slightly ranty style of this post).

1) The lemming count constantly confused me - THIS NEEDS TO BE CHANGED! Who cares how many zombies and ghost are walking around? If I see on the preview screen 45 lemmings required out of 50, then I expect to be allowed to lose 5 lemmings. I do not want to count all zombies and ghosts first and adjust this number. Even worse in levels like Demonic 5, where one has to wait until all lemming appeared, before knowing how many lemmings one may lose, because it is simply impossible to count all the zombies!
I know this has come up before, but this really is annoying!

2) One never knows, when zombies and ghosts have special abilities like being swimmers, climbers, ... This must be directly visible once one moves the cursor on the zombie/ghost.

3) Ghost can be disarmers, but they will still ignore traps completely. So giving ghosts the disarmer skill is totally useless. Either let ghosts disarm traps or disable giving them the disarmer skill.

4) The interaction of ghosts and blockers is a bit weird. Ghosts just ignore any blocker, be it a usual lemming blocker or a ghost blocker. I would have expected either
4.1) Ghosts turn around at any blocker, or
4.2) Ghosts walking to a lemming blocker release the blocker, because the lemming fears the ghost and thus decides to move again.

[ccexplore]

4) The interaction of ghosts and blockers is a bit weird. Ghosts just ignore any blocker, be it a usual lemming blocker or a ghost blocker. I would have expected either
4.1) Ghosts turn around at any blocker, or
4.2) Ghosts walking to a lemming blocker release the blocker, because the lemming fears the ghost and thus decides to move again.

4.2's cute.

I actually have no idea at all how ghosts work in NL, but without knowing anything else about its behavior, if someone told me "ghost isn't interacting with so-and-so", the obvious first reaction for me would be "duh, it's a ghost!".  So while it may well be inconsistent behavior compared to rest of ghost's current behaviors, I don't necessarily expect a ghost-blocker interaction as a given.

Along that line of thinking, the first thing that came to my mind is that ghosts only interacts with ghost blockers, and regular lemmings only interacts with regular blockers.  But really this is more a game mechanics design question that probably deserves its own topic and poll.  We need to weigh the pros and cons of various gameplay possibilities each variation allows and disallows.  I'm sure namida has his own ideas as well when he first added ghosts to the game.

[Nepster]

Lemmings fearing ghosts is otherwise the standard behaviour: Walking lemmings turn around when encountering ghosts and builders, bashers, miners, ... stop their current work to flee.

EDIT: Removed incorrect information.

[ccexplore]

Ah okay, in that case I would intuitively expect 4.2 to happen as well, unless there are good gameplay reasons to do otherwise.

Do ghosts fear other ghosts as well, or are ghost-ghost interactions same as their non-ghost counterparts?

[namida]

1. Yes, this is on the cards for V2.
2. Alt + Hover over (also allow distinguishing between say, a Climber+Floater Athlete and a Climber+Swimmer Athlete, for example; it's not just for ghosts/zombies)
3. Preventing the assignment makes sense, I guess. The same can also be said for swimmers.

4. I don't think anyone else has found this strange so far. I've generally described it as "ghosts aren't affected by anything except terrain (including steel / one-way)" - this would imply they aren't affected by blockers either. Lemmings performing these other tasks absolutely should not stop them to flee the ghost - from a technical point of view, at least in terms of interaction with other lemmings, a ghost is just a moving blocker with a larger blocker field. So, for example, if a ghost causes a miner to turn, it should continue mining but in the other direction (assuming it still has something to stand on; ghosts won't magically allow it to mine in mid-air). Indeed - as you could tell if you were to release the blocker somehow, a ghost can indeed change which direction a blocker is facing.


@ccx: Ghosts do not interact with other ghosts at all. Zombies, however, are affected by them just like normal lemmings would be.

[ccexplore]

Thanks for the explanation on 4.  Nepster's description talks about "fear" and "fleeing" so mentally I had the incorrect impression that the lemmings would actually stop what they were doing, as opposed to merely being forcibly turned (but otherwise continuing on with the actions of their current skill) like with a blocker field.

I'd like to add that #3 makes a lot of sense, although that's also assuming there are no plans in future to allow the ability to change the ghost status of a lemming.  Granted, even if the future does allow that, the skill assignment behaviors can always be readjusted then.

[Nepster]

2. Alt + Hover over (also allow distinguishing between say, a Climber+Floater Athlete and a Climber+Swimmer Athlete, for example; it's not just for ghosts/zombies)

Didn't know that this works as well for zombies. However there is one difference to normal lemmings: With usual lemmings (except the few preplaced ones), one has already an idea what abilities one has given them, and Alt+Hover is only there to confirm this. With zombies one has a priori no such information at all, making this check much more important. Plus, hovering over zombies ist useless at the moment (one cannot do anything with zombies), so giving this additional info directly by hovering over the zombies would be convenient for me.

4. [...] Lemmings performing these other tasks absolutely should not stop them to flee the ghost - from a technical point of view, at least in terms of interaction with other lemmings, a ghost is just a moving blocker with a larger blocker field. So, for example, if a ghost causes a miner to turn, it should continue mining but in the other direction (assuming it still has something to stand on; ghosts won't magically allow it to mine in mid-air). Indeed - as you could tell if you were to release the blocker somehow, a ghost can indeed change which direction a blocker is facing.

Sorry, my mistake, but I could have sworn to have seen a builder stopping his work. In the light of the actual mechanics, the current behaviour is at least consistent.

[Wafflem]

Not sure if this has been reported before, but it seems that a swimming climber is unable to properly climb up terrain at a certain height. If the terrain the lemming encounters is of a short height, the lemming climbs up but then turns around and swims. If the terrain the swimmer encounters is a tall height, they can climb up. See attached level.

[namida]

Huh, that's weird. No, I don't think it's been reported before. It also happens with a wall that has a top exactly one pixel higher than your one there.

I have a guess at what might be happening - I'm guessing that an exception to interacting with water has been applied to Climbers to avoid them going back to a swimmer, but the same exception hasn't been applied to *Hoisters*, thus meaning they detect water and go back to swimming. (EDIT: It wasn't exactly this, but it was pretty close.)

So - things that need to be done for the V1.36n release:
> This Swimmer+Climber bug
> The ghosts not splatting in water bug
> For ghosts / zombies, automatically show full information on permanent skills

Anything else?