[DISCUSSION] Priority order of trigger area types?

[Nepster]

Soon the experimental version will be able to handle multiple overlapping trigger areas, e.g.
- Within one frame, a lemming can pick up a skill, press a button and then get smashed by a trap
- While a triggered trap is active killing one lemming, another may hop into the exit (even though the exit trigger area was previously totally covered by the trigger area of the trap)

However the details are less clear:
- How do we order exits, triggered traps, continuous traps, water and teleporters? It doesn't make sense for a lemming to hop into the exit while being fried by a fire blower at the same time.
- How do we decide between Radiation and Slowfreeze or between Splat-pad and Anti-Splat-pad?
- Do we even want to pick up a skill while dying in a trap as described in the first example above?

Are there any combinations resp. rules for prioritizing that you feel particularly strongly about?

[namida]

The most common cases are going to be the kind that are already supported - generally, water overlapping something else (with the intention that a swimmer is used to get to the other object, or must avoid the object, depending what kind it is).

Perhaps one idea that could be argued for is a rule of "negative overrides positive"; this could be seen by analogy with the existing case of splatting from a long fall overriding exiting. So, something that kills the lemming would have the highest priority (perhaps with one that does so inherently, like fire, having priority over those which can be made safe, like water, having priority over something that must be triggered, like a standard trap, which in turn has priority over the only-deadly-once single-use trap). There would be some matter of subjectivity involved - which is more negative, radiation or slowfreeze?

One thing this doesn't account for: We probably don't want to encourage such confusing designs in the first place. Excluding those (such as OWWs) that are of a completely different nature and have no reason to interact with standard objects, cases where we actually want this are probably going to be limited to stuff overlapping water (already supported in stable version), or possibly one-way fields overlapping certain other types (eg. the unlock button is in the middle of a one-way field). But for example, even if there was a clearly defined behaviour, a level with splat pads and antisplat pads overlapping each other's trigger areas would be somewhat of a bad design in the first place.

At any rate, I would say that almost any defined result is better than the current system of "whichever object was placed last has priority", though.

On this note - are you working on anything related to the trigger area overlapping (or at least fixing the cancelling bug)? If not, I'd like to work on that next, but I'd also prefer to avoid duplicating effort or conflicting with your changes. (If you are working on this, there are a few other areas I can work on in the meantime.)

[Nepster]

Perhaps one idea that could be argued for is a rule of "negative overrides positive"; this could be seen by analogy with the existing case of splatting from a long fall overriding exiting.

This has positive and negative consequences: On the one hand, it would allow for nice puzzles ideas (e.g. placing triggered traps above exits), but on the other hand, this might lead to a lot of frustration, if it is not obvious whether a trap trigger reaches over all of the exit or not. Similarly one can mislead players by placing pickup-skills behind continuous traps...
Sure, such designs are certainly to be discouraged, but I worry about the guideline: "Players will certainly not complain if the game is too player-friendly (regarding edge cases), while they will get annoyed if the rules are too unfriendly to users."

Your idea might nevertheless be a good one. I am just saying that I am not yet convinced, that it is the best solution...

-------------------------------------------------------------

Here another related question: How to prioritize blockers versus force fields?
a) Always prioritize blockers over force fields: Then one might pass through force fields by placing blockers on top of them, which would lead to very weird tricks.
b) Always prioritize force fields over blockers: Then blockers within force fields would have no effect at all and lemmings can just walk through them, which again would lead to very weird tricks.
c) Disallow overlapping blocker fields and force fields: This changes the current behavior, where such overlaps are possible. I am not sure how often one wants to place blockers next to force fields and how big the impact is on existing content.

-------------------------------------------------------------

On this note - are you working on anything related to the trigger area overlapping (or at least fixing the cancelling bug)?

If the one-way-wall cancelling bug was caused by removing the line

Code Select Expand

if V in [DOM_STEEL, DOM_ONEWAYLEFT, DOM_ONEWAYRIGHT, DOM_ONEWAYDOWN] then
in TLemmingGame.InitializeObjectMap, then my changes will automatically fix this bug. If TLemmingGame.InitializeObjectMap isn't the cause of the bug, then I have no idea where to find the bug and might only accidentally fix it.

[namida]

Here another related question: How to prioritize blockers versus force fields?

IIRC, current behaviour is that blocker has priority (but in many cases, as soon as the lemming turns around and moves one pixel, he'll be inside the one-way field, now on a pixel that doesn't have a blocker, and turn around again). Although I don't remember the logic behind it, I do remember this being an intentional decision. Nonetheless, it's not commonplace enough that there needs to be much resistance to changing it, if there are good arguments for doing so.

[Nepster]

For now I implemented the following order of prority for trigger types:
1) Buttons, pick-up skills, updrafts and pure animations
2) Continuous traps (fire and water)
3) Triggered traps
4) Radiation
5) Slowfreeze
6) Teleporter
7) Exit
8) Flipper
9) Blockers and force fields

Blockers cannot be assigned if their trigger area would overlap the trigger area of force fields.
For preplaced blocker, their trigger area has priority over the trigger area of force fields. Moreover blockers with higher index have proprity over blockers with lower index.^*

There are currently no good reasons, why any of the above should be precisely like this. A decision was made, just because some decision had to be made. So if you have anything you prefer to be changed, please tell me.

^* Pretty, pretty please do NOT make levels relying on this behavior for preplaced blockers. Future bug-fixes will be made without considering their impact on this behavior, so it might change every once in a while.