"Splittin Like Crazy" in Mental is the level in question. In particular, the "only one teleporter can use the receiver at a time" aspect is important here; using two receivers instead would greatly reduce the difficulty of the level. And again, this is just off the top of my head - there may be others.
Yes, I can see how adding another receiver there would simplify the level, though I don't think "greatly" fits. On the other hand adding another receiver would at least make the level more predictable for the player, which might (or might not) turn the level into an even better one.
It is "established" on the grounds that it has been the case for as long as teleporters have existed, and that it was shown in very early packs that used them. It is "completely intentional" because they work that way by design, not as the result of a bug / unintended side effect. And the difference from the blocker-teleporter issue, is that one was unintended and lead to a situation contradictory to a very well-established game rule, and has never been used in any level aside from for the explicit purpose of demonstrating the behaviour itself; the other was an intentionally-implemented feature, with a level that uses it having existed almost as long as teleporters themself have existed in NL.
Yes, the blocker-comparison was not a good one. Still I would question your argumentation for "established": Your Dodgy level might use it, but it doesn't call attention to it. As it works just as well with two stacked receivers, players will just never learn about these game mechanics there. And I would say the same for "Splitting like crazy", especially as it is so extremely chaotic that the player has no time to really see what is happening. IchoTolot, Simon, Proxima and myself being surprised by this game mechanics should be an indication that "established" and "intended" behavior was not communicated properly, either through forum posts or actual levels.
And to be clear - the possibility that one source teleporter is flipped and the other is not is also a completely intended aspect. This can be resolved by flipping only the teleporter graphic, which also makes it more clear (to designers, too) that the flipping is an aspect of the teleporter, not the receiver.
But from the next version on, you might just flip the teleporter but not the receiver in the level file (if you modify it by hand), however the NeoLemmix player will
enforce that either both or none of them are flipped. We agreed on this change, because the old behavior (although originally intended) was in no way easy to understand for level designers or players. I myself had to make a test level with all four options of flipped teleporters/receivers to understand the behavior.
Upshot is:
1) Going back to decoupling the flip-lemming behavior and flip-sprite behavior on the receiver's end is not the way to go forward.
2) Even if some behavior works as originally intended and there have been good options to create it in that way, it might still turn out to be unpractible. I am against keeing stuff that surprises people, when basically the only reason for keeping it is "it was always that way".
We have already had people call into question the suitability of using anything in NL that isn't a base L1 feature due to culls; who were then reassured that there wouldn't be further culls. Now, you are proposing yet another one.
That is simply not true: Noone ever questioned the existance of teleporters themselves (same as for the new skills and lots of other new objects). What we are discussing now is an edge-case of the game mechanics. This is something else than completely culling a game feature, like we did when removing radiation and slowfreeze objects. What you are basically demanding is a complete freeze in the game mechanics, so that they can never even be touched again - because
any game mechanics change does cull some possibilities in game-play!
I'd even be happy to put some effort towards maintaining some of these features myself if NL was still open-source - if nothing else, just so that creators can actually have that guarantee that features they choose to use are not going to be removed later - but as far as I can tell, you aren't providing the source code anymore - I certianly cannot find a link to the repo anywhere.
NeoLemmix is still open source. You can find the source code
here.
And thanks for the offer to come back to coding in NeoLemmix - I truly appreciate that. However the main coding effort will be with the editor, because its object data structure is absolutely build around having only
pairings of teleporters, not a many-to-one relationship.
To be totally honest: I really don't have any desire to spend lots of time coding stuff for a feature that was basically never used (even when we had the old editor, which apparently supported this). There are so many other parts where I can improve the editor for a much bigger gain. Compared to that, disallowing the many-to-one relationship are just two lines of code in the NeoLemmix player.
Finally I do notice, that you haven't answered my question,
why this many-to-one possibility is intended?
