[+][BUG][PL] Error when hovering over teleporters/receivers in Physics View

[IchoTolot]

I received a level for the LDC34 that has a lot of teleporter/receiver pairs. I attached it to this post.

When hovering over teleporter/receiver pais in true-physics-mode you get an error that throws you back to the menu.

It happens in the regular version, but I bet it also effects CE.

I received additional information from the author:

I also should mention that when i was designing this i ran into a problem that this many teleporters wouldn't work unless I made sure that all the teleporter objects were listed before any other of the interactive objects. since that interactive object list system only has 256 slots which allows for a max of 128 teleporter pairs and I include 126. So getting it to run took a little text editor work.

I bet here is the core of the problem. 

So the object list should probably be made more robust and either allow these instances or be much stricter so that users can't game the system and create edge cases like this.

What's the best move, I am not sure. 

EDIT:
Additonal information from Armani:

In cpm each teleporter/receiver pair(also portals, in the same way) gets a helper icon showing a letter A, B, C, ... The renderer use the pair number directly as an index into the helper icon enum but that enum has only 26 letter icons A~Z.  this is where the problem arises

So..

1) From the 27th pair onward, the index points to unrelated icons so the label shows a wrong one.
This doesn't break the NL but ideally should be fixed anyway.

2) From the 55th(could be slightly wrong) pair on, the index goes past the end of the helper image array, which triggers an error message.
The game is still playable as long as you don't turn on the cpm and hover your mouse over the broken objects.

The cleanest fix I can think of: instead of the direct enum cast, add a local procedure and pair 26 and up are drawn as two alphabets (AA, AB, ..., AZ, BA ... and so on)

[IchoTolot]

Armani gave some additional insight that I added to the main post.

[JRT]

I also should mention that when i was designing this i ran into a problem that this many teleporters wouldn't work unless I made sure that all the teleporter objects were listed before any other of the interactive objects. since that interactive object list system only has 256 slots which allows for a max of 128 teleporter pairs and I include 126. So getting it to run took a little text editor work.

Yes and to add a bit more specificity. The game would run otherwise just fine but when lemmings entered the IN teleporters they would vanish and then never materialise on the other end. and if memory serves you see a flash as if a lemming is teleporting in but never does and that's always on the last placed teleporter (I think). This weird behaviour can be easily reproduced.

[WillLem]

Unless namida reopens NeoLemmix development, this will not be fixed for vanilla NeoLemmix 12.14. However, we may be able to find some solution for NeoLemmix CE.

Reading over this, my instinct is to simply disallow more than 26 teleporter/receiver pairs. More than this probably shouldn't be supported in NeoLemmix anyway, particularly if we have to start resorting to indexing hacks to get it to work.

I'll certainly be applying this cap in SuperLemmix (where the problem likely also exists). Happy to discuss implementing the cap (or not) in NeoLemmix CE, so please reply if you believe we should be supporting 27 or more pairs.

Your silence = teleporter/receiver pairs will be capped at 26 as of the next version of CE.

[Simon]

instinct is to simply disallow more than 26 teleporter/receiver pairs

Then CE won't be a drop-in replacement for NL anymore.

To reject >= 27 pairs, you'd need to get wide consensus that putting more than 26 pais is a level design error even in namida's NL. The exact rule for the future (explicitly limit to 26, or allow >= 27) doesn't matter much to me, but I recommend against a split of the ecosystem.

-- Simon