[BUG] [PLAYER] [FIX DELAYED] Pre-placed lemming causes spawning from second...

[Wafflem]

Status: Acknowledged. Fix is being intentionally delayed until the level format is replaced, to avoid any messiness around "which levels were designed accounting for this bug and which ones weren't"?

[Wafflem]

Found this in the old Player Bugs/Suggestions topic:

Discovered a bug relating to pre-placed lemmings in multiple-window levels. The preplaced lemmings are counted as having spawned, which affects which window the first lemming comes from.

For example, say we have a level with three windows (A, B and C). If you were to put one pre-placed lemming in this level, the first lemming to spawn from a window would come from window B, not A. And if there were two pre-placed lemmings, the first spawned lemming would come from window C. After this point the pattern continues as normal (so after window B, the next lemming always comes from window C. It only affects where the starting point in the release order is.)

It's a minor bug, and the behaviour is consistent, so level designers can adjust for this - they just need to be sure to take it into account. I won't release an update to fix this; but it will be fixed in V2.00n. I'll make sure V2.00n accounts for this when importing older levels.

I've tested this in the new version of NeoLemmix, and the bug is still present, as shown in the picture below (the first lemming should come out of Window A, not B).

[namida]

Yes, this bug has not been fixed yet. The biggest issue I can see still comes back to - what to do to fix this, without breaking existing levels?

One possibility is to make the editor automatically adjust the spawn order to account for is. However, this doesn't really fix anything, it just works around it in terms of what data it saves.
The other possibility is to put some kind of flag in level files to identify them as ones created after this bug was fixed; and only apply the bug fix to these. This would still potentially create problems if using an older editor version - and still require an editor update.
Another possibility is to simply fix it, and leave it up to level designers to account for it. This seems inconsistent with the goal of ensuring portability between versions as far as possible, especially for content made prior to the fix.

The last possibility is to simply leave things as is (at least until the level format is replaced - I still plan to move to a text-based format eventually), and make sure it's a well-documented behaviour. This would have no impact on compatibility, but may be slightly counter-intuitive for those who are not familiar with the behaviour.

[namida]

I think for now, the best option is to leave it as is. Once the move to a text-based format is implemented, that's the time to fix it (as existing levels can be accounted for by adjusting them during the format upgrade; and determining whether a level is from before or after the fix is a matter of "is it in binary or text-based format" rather than having to introduce a flag specifically for this purpose).