[2.50.0, 2.50.1] Lanmolas Cause a 'Kill All Enemies' Effect

[ZoriaRPG]

In both 2.50.0, and 2.50.1, if you place a lanmola on a screen, with any other enemies, including other lanmolas; then kill any enemy on that screen, leave, and return; all the other enemies will be dead. The enemy that you kill does not need to be the lanmola, either. No combination of enemy editor properties, or screen flags, seems to matter.

[Gleeok]

I think that has something to do with the temporary no return effect, and was actually made like that on purpose, because that's what the NES does. I'm not very familiar with how that works though.

[Anarchy_Balsac]

Check the "Enemies Always Return" rule or flag to bypass this problem.

[CJC]

Just curious... what enemy slot is the Lanmola in? The first? Somewhere in the middle of the list?


I think that the cause might be that Lanmolas--while loaded as a single enemy--are actually treated as multiple enemies. It might be that the Lanmola is logging each of its segments as separate beatable enemies, throwing off the screen count.

By which I mean this: Lanmola has X segments, there are 6 other enemies on screen.
The enemy screen count expects 7 enemies, but there are actually 6 + X enemies on screen. You kill one enemy.
The no return count now expects 6 enemies, but there are 5 + X enemies on screen. It kills the last enemy in the list to reduce the count, but it's still too high. It keeps removing enemies until it gets to the Lanmola, which has more segments than there are enemies on the screen. So it kills the Lanmola too, leaving the screen empty.



I'm just brainstorming here. Try switching the Lanmola to the end of the list to see if the behavior is different.

[ZoriaRPG]

Just curious... what enemy slot is the Lanmola in? The first? Somewhere in the middle of the list?


I think that the cause might be that Lanmolas--while loaded as a single enemy--are actually treated as multiple enemies. It might be that the Lanmola is logging each of its segments as separate beatable enemies, throwing off the screen count.

By which I mean this: Lanmola has X segments, there are 6 other enemies on screen.
The enemy screen count expects 7 enemies, but there are actually 6 + X enemies on screen. You kill one enemy.
The no return count now expects 6 enemies, but there are 5 + X enemies on screen. It kills the last enemy in the list to reduce the count, but it's still too high. It keeps removing enemies until it gets to the Lanmola, which has more segments than there are enemies on the screen. So it kills the Lanmola too, leaving the screen empty.



I'm just brainstorming here. Try switching the Lanmola to the end of the list to see if the behavior is different.

I had considered that, but a base lanmola is treated as six NPCs, not ten. It's clearly a problem with some state that it sets on the screen though; and it happens in any slot.

It's actually a different quest rule, that is disabled by default (Temporary no-return disabled). You need to turn this on, in order to prevent lanmolas from killing everything in a room.
@Saffith Was that the desired result of adding that quest rule? I know that Lanmolas stay dead in the NES Z1, but they shouldn't take every other enemy on the screen down with them...

--

Regarding other comments/questions, f you are curious, the number of NPCs created by each lanmola, is equal to the number of segments set as its Attribute[0] + 1. Knowing that, you can set up lanmola revival/generation, with basic maths, even determining the number of lanmolas by reading the n->Attributes[0] index, for the enemy ID.

That doesn't revive other enemies from the list; and because ZC doesn't support 2D arrays, it's not possible to copy an enemy list into an array, and store that array in a Screen->D register, then later restore them in order, stopping at a count stored in a separate register.

You could store every enemy on each screen per dmap in one huge array, but the amount of work to do that, just isn't worth it for one enemy type. It's easier to Autoghost a custom lanmola.

@ Anarchy_Balsac That's not a fix. In fact, that doesn't work at all:

Ticking 'Enemies Always Return' has no effect on screens with lanmolas, without 'Temporary no-return disabled.'. This, is its own bug, so treat it as a second-tier bug for this report. .

Even if it did work, that is just as much of a problem, as the lanmolas killing everything; but with scripting, there are ways to resurrect things. It's just a bloody pain; and setting 'enemies always return' had several downsides too. Eve with workarounds, it's a serious bug. At least it isn't as bad as 2.50.0, where Remove(n) on a lanmola crashed ZC (completely).

It's still a bug that needs to be addressed, as I do not believe this happened in 2.10; nor do I recall any point in Z1 where killing a lanmola, leaving a room, and re-entering it caused it to be clear of enemies. If that did exist, then this behaviour would need to be a NES compatibility quest rule, and should be disabled by default.

Lanmolas do whatever they wish, though: That's a constant across ZC versions.Try forcing n->X on one, or n->OriginalTile, or n->Step. They just ignore everything.

@Saffith In addition to the report above, as I recall, both 'enemies never return', and 'enemies always return' flags both have troubles with lanmolas. I know that ticking 'Enemies always return, does not revive them; nor does it revive the other enemies on that screen. I'm not certain on 'never returns after death' though, because lanmolas pretty much act that way inherently, and take everything else down with them.

What does fix this, is enabling the following quest rule: Temporary no return disabled. Thus, it is clearly something to do with how lanmolas are treated (as bosses). I thought that was enabled by default, and most people don;t know what it does; so, there's already a rule for it, and this may have been an unnecessary bug report; but I think that this specific rule should be enabled as a default, because it sure is confusing.

It's still a conflict between that quest rule, and the 'enemies always return' screen flag though. I'm not sure if there is a good compromise for those two.

I'd also suggest renaming that quest rule to 'Disable Lanmola/Trap Room Enemy Respawns', or something like that. Adding 'disabled' at the end of the wording, seems like turning it on, would enforce the NES behaviour, rather than the opposite.

Shouldn't that rule be under 'NES Fixes', and not 'Enemies' too?

[XMuppetSB]

I think that has something to do with the temporary no return effect, and was actually made like that on purpose, because that's what the NES does. I'm not very familiar with how that works though.

In the NES game, Lanmolas never appeared in the same room as other types of enemies. Every single room that had Lanmolas only had either 2 Red Lanmolas, or 2 Blue Lanmolas. Not to mention, the Lanmolas would stay dead until you leave the dungeon. (Level 9 to be exact, as they only appeared in level 9)

[Anarchy_Balsac]

Interesting facts, though it should be noted I only posted that as a joke.

[Chris Miller]

In the NES game, they had to do it that way, because the lanmolas used up a lot of sprites. Any other enemies in the room would overload the sprite limit. I would guess that the no-return flag on the lanmolas is screwing with the return flags on other enemies.

EDIT: Ah, Zoria got it. I kind of skimmed over his post a little too quickly the first time around.

[ZoriaRPG]

In the NES game, they had to do it that way, because the lanmolas used up a lot of sprites. Any other enemies in the room would overload the sprite limit. I would guess that the no-return flag on the lanmolas is screwing with the return flags on other enemies.

EDIT: Ah, Zoria got it. I kind of skimmed over his post a little too quickly the first time around.

Actually, I'm willing to bet it's how the no-return prevention for those specific enemies via the quest rule works, mechanically. It probably clears the Guy list, and sets a permanent no-return state on the screen, rather than trying to clear specific enemies.