[Fixed][BUG][Editor] Creating pairs of 3+ teleporters/receivers is possible

[IchoTolot]

The results here actually make sense once you managed to set things up, but let me explain.

With the new editor you can pair teleporters and receivers in pairs of 2 and only 2. If you select 3 then only 2 get paired, if an already paired gadget gets re-paired the other gets unpaired.

But now we found out by editing the saved level's text file we can create pairs of 3+ teleporters and receivers by manually giving them the same group in the text file.

The result makes even sense: They all get the same true-physics letter. Only 1 teleporter at a time gets to teleport to a receiver while the other has to wait until it is free again.

The bug is more like: It's possible in the text file, but not in the program itself. So either the manual text file change should be recognised and forbidden by the program or the program should get the ability to create these groups as well --- at least in my opinion. A function only possible to access with text editing is a bit weird.

EDIT: I personally would forbid it for simplicity and only let pairs of 2 exist.

[Simon]

Related quirks that the game handles acceptably: Assigning N teleporters to 0 receivers in a group turns all the teleporters into decoration; they aren't shown during clear-physics. Assigning N teleporters to M receivers, I believe the later M-1 receivers are ignored by the physics and this handles like N teleporters to 1 receiver.

The critical case is N teleporters to 1 receiver. This offers real level design possibilities that you get only via text file. Either allow and offer editor UI, or forbid and specify how the game should behave when such pairings appear in levels.

-- Simon

[namida]

Multiple teleporters to single receiver is something NeoLemmix explicitly does support (note that there's at least one level in Lemmings Plus III, which was basically the prototype NeoLemmix pack, that uses this feature). Adding to this, it is also possible that one source teleporter has the "flip lemming on exit" property while another does not, which is precisely why this attribute was defined on the teleporter rather than the receiver.

[Dullstar]

Most of these cases seem reasonable. I'd suggest adding some sort of official support for wiring more than one teleporter to the same receiver to the editor itself. At the very least, doing so would make people feel more confident using it, as having to edit the text files to do it may cause some designers to avoid doing so out of either a) not knowing or b) concern it will be culled in the future. As for the case regarding teleporters assigned to no receivers, while ideally people shouldn't put fake objects in a level, clear physics handles it well, and the case is handled gracefully (i.e. without crashing the game).

As for the remaining case:

Assigning N teleporters to M receivers, I believe the later M-1 receivers are ignored by the physics and this handles like N teleporters to 1 receiver.

I don't fully understand this, but here's the best interpretation I can come up with:

For N = 1: If a single teleporter is assigned to multiple receivers, the first one on the list is used, and the others are ignored.
For N > 1: This case is just the effect of the N = 1 case combined with the fact that multiple teleporters can link to the same receiver. In other words, some arbitrary number of teleporters (which Simon called "N") can be linked to another arbitrary number of receivers ("M"), and, for each teleporter, the first receiver in the list is used ("the later M-1 receivers are ignored").

In this case, I'd say that it's at least good that the game doesn't crash when a level does this, and I'd say I don't have a problem with this as a user as long as clear physics displays things in a way that makes sense.

[IchoTolot]

I am totally fine with keeping (or removing ) this feature -- if it gets proper editor support and logical rules.

Just the rules and implementation should be discussed, agreed on and written down here so that this behavior doesn't get changed again and again in the future.

[Nepster]

Until now, I wasn't even aware that the NeoLemmix player allowed you to pair one receiver with multiple teleporters . This also explains why the editor doesn't allow this.

For the future, I am in favor of removing this "feature" completely. The reasons are:
1) It makes live much easier for me as a programmer: No need to worry about correctly displaying game hints in the clear-physics mode. No need to completely rewrite handling the pairing in the editor.
2) Assume two teleporters point to the same receiver, and one of them flips the lemmings around while the other doesn't. Then the main argument that convinced me to keep flipping teleporters, namely that we have visual clues on both the teleporter and receiver, is no longer be valid: Whatever we do, the receiver image is wrong for one of the teleporters.
3) Lemmings can only use teleporters, when no other lemming is currently using them. If we have two teleporters A and B pointing to a receiver R, then this rule becomes muddy:
  a) If a lemming in on his way from A to R, should it be possible for another lemming to enter teleporter B?
  b) What if R's animation hasn't started yet, so that both B and R seem inactive?
  c) What if R's animation would already have been finished by the time B's anmiation for the next lemming would have finished?
4) Regardless on what we decide on 3), it will be a nightmare to control the lemming flow out of such receivers, because one has to keep an eye on two or more teleporters.
5) And as far as I know, there is just this one prototype level by namida that use this feature currently, nor have there been any feature requests going in this direction. So it does seem like a feature that has mostly theoretical uses.

Regarding not pairing a teleporter/receiver with a counterpart: IIRC the editor complains about such things if you validate a level. But I would feel uncomfortable to add a hard enforcement of pairing everything.
I am certainly open for removing unpaired teleporters/receivers completely from the level, already when loading it.

Regarding pairing a teleporter with multiple receivers: This will be continued to be seen as a "not well-formed level", so it is not encouraged to edit level files in such a way. I am happy with the way NeoLemmix currently tries to create a valid level out of it. However I will take the liberty to change how the NeoLemmix player handles this situation, if this will simplify a bug-fix or implementing a new feature.

[Dullstar]

Part of the reason the feature may have only theoretical uses is because most people won't try to edit the files manually and therefore aren't aware that it can be done.

I don't personally have a problem with allowing multiple teleporters attached to the same receiver, although it's probably worth noting the behavior can be replicated simply by stacking multiple receiver sprites on top of one another. So perhaps a better question would be what the advantages are of using the same receiver vs. stacking sprites on top of each other. An important consideration would be how clear physics mode displays multiple teleporters to one receiver vs. multiple teleporters with their corresponding receivers stacked on top of each other.

[namida]

I don't personally have a problem with allowing multiple teleporters attached to the same receiver, although it's probably worth noting the behavior can be replicated simply by stacking multiple receiver sprites on top of one another. So perhaps a better question would be what the advantages are of using the same receiver vs. stacking sprites on top of each other.

A critical difference here - with your suggestion, teleporter A and B can be used at the same time. With the multiple-to-one link, only one source teleporter can be in use at a time. NeoLemmix was explicitly written to handle such a situation (on the other hand, the behaviour of one teleporter linked to multiple receivers is indeed undefined).

3) Lemmings can only use teleporters, when no other lemming is currently using them. If we have two teleporters A and B pointing to a receiver R, then this rule becomes muddy:
  a) If a lemming in on his way from A to R, should it be possible for another lemming to enter teleporter B?
  b) What if R's animation hasn't started yet, so that both B and R seem inactive?
  c) What if R's animation would already have been finished by the time B's anmiation for the next lemming would have finished?

Current, intentionally-selected, rules (assuming they haven't been changed):

a) No. All linked teleporters and the receiver must be not-in-use for any teleporter in the link to function.
b) Same as above.
c) The same rule applies for if A's animation has finished but R's hasn't, and a lemming tries to enter A. Which IIRC, is "the lemming cannot enter".

[Nepster]

a) The only level in LPIII that has two teleporters mapped to one receiver seems to be Dodgy 13, which would work just as well with two receivers.
b) In the last few months after this possibility was mentioned, there seems to be no desire to create any such levels (as far as I am aware), so having this option seems to be rather unimportant.
Together with points 1), 2) of my previous post and the good (though not perfect) alternative of replacing the one receiver with multiple ones, I don't see any reason to spend lots of time coding a consistent NeoLemmix player behavior (cf. point 2) above) and extending the editor abilities.

Unless there turns out to be a strong opposition against removing this behavior, I will go along with the following plan: Starting with the next NeoLemmix update, any level with multiple teleporters pointing to one receiver triggers "undefined behavior" of the NeoLemmix player. This means, that there is only one guarantee: NeoLemmix will not crash when loading such a level. However I reserve the right to change the actual way of handling such levels at any time. Most likely this will result in one of the teleporters still pointing to the receiver, but I will make no effort to keep this behavior stable over extended periods of time.

[namida]

What happened to the guarantee of no further culls to established mechanics? Despite usage being somewhat rare (though it is definitely NOT exclusive to that one level - at the very least there is also one LPO level that uses this feature), this is an established, completely intentional aspect of teleporters in NL.

[Nepster]

Sorry, but how can this be an "established, completely intentional" aspect of the teleporters, when you were the only one aware of that ability until IchoTolot found out about it three months ago? How is this any different than the ability to place overlapping preplaced blockers, that we agreed to remove (if you look at it from my perspective, who certainly did not design teleporters that way)? I still don't understand why they are supposed to be intended that way? Doesn't make it both the game mechanics and the code more complicated for no real gain?

Btw. both were game mechanics that I were not aware of when making the guarantee not to cull any further object types. If I had known about them before, I would certainly have brought them up before.

Anyway, as the "lemming flipping" behavior is now directly tied to both teleporter and receiver (as both signal this via having flipped graphics), we certainly have to impose the additional restriction that the teleporters for one receiver either all have to be non-flipping or all have to be flipping. In my eyes, this makes it even more unuseful to allow tying multiple teleporters to one receiver.

And can you please point out the LPO level that uses this? I would like to have a look and see whether it really needs that game mechanics.

[namida]

"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.

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.

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.

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.

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.

[IchoTolot]

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.

I am still in favor of both getting flipped: Receiver and teleporter. Which makes the turnaround more clear - even if it's an attribute of the teleporter, it emphasizes the connetion between the objects.

That would indicate that if this behavior stays, every teleporter of the group is either turning or not turning.

I do not want to see another huge fire here. We had enough over the beginning of 2018.

I am still slightly more in favor of only using teleporter/receiver pairs, but if we have to make a compromise I would propose simplifying this behavior to full turn or no turn - all objects getting flipped or not.

[Strato Incendus]

I'm pretty sure I have also used several teleporters linked to one receiver in some of my levels. I can't remember them by name right now, but I certainly wasn't surprised at all that this is possible.

Using the fact that it's apparently more difficult to pull off in New Formats as a justification for the old "it's barely getting used, so let's cull it!" reasoning is circular logic, because it basically has been removed from the New Formats editor already. If people do a manual workaround by fiddling with the text, that shows there must be a real demand for creating such teleporter mappings.

The logical consequence is to try and enable multiple teleporter to one receiver mappings inside the editor, rather than trying to ban the option altogether.

[IchoTolot]

If people do a manual workaround by fiddling with the text, that shows there must be a real demand for creating such teleporter mappings.

Here I must step in. That was not the case.

The editor removal wasn't noticed for months, until Simon, Proxima and I discovered it at our meetup while trying to create weird teleporter scenarios to find bugs - we found the blocker overlap bug as an example. We were surprised that this linking worked.