I mentioned before in my patch thread that I was encountering some funky stuff regarding Hero Party scripts, and that I'd make a thread about it once I confirm my theory as to what is going on within the game. Seeing as I've managed to fix all the issues I was encountering, I can safely say that my theory is confirmed true, and so here is a thread on what I've discovered.

There are three quirks that I encountered for Hero Parties relating to scripting: triggers specifically.

When Created...
This first quirk is fairly easy to understand.

When spawning multiple copies of the same Hero Party under the exact same trigger simultaneously, and if that party has a 'When Created' trigger attached to it, the trigger will only set off once instead of setting off for as many parties being spawned. As stated, however, it is a very specific instance as it has to all be precisely the same.

This only applies to triggers directly under the Hero Parties themselves. If a 'When Created' trigger is placed under an individual member within the Hero Party, then it will set off for as many times as that member is spawned, regardless of conditions like the above.

When Incapacitated / Killed...
This next quirk is easily the most complicated of the three.

This quirk relates to tying a 'When Incapacitated' or 'When Killed' trigger directly to the Hero Party itself (I haven't tried the 'Imprisoned' trigger yet). If there are multiple copies of the same party that are active on the map with one of the above mentioned triggers attached to it, then the trigger will only set off if the condition has been met for all of them. It will also only set off once, regardless of how many active parties there are. The point of which they're spawned doesn't matter. All that matters is if there are multiple copies of that same party existing at the same time. Spawning more of the same party will also add to the condition.

Example: There's a script loop that spawns the same party every 3 minutes. When that party is killed, Flag 1 will be increased by 1. A party spawns and is immediately killed, then Flag 1 will be increased by 1 as intended.

However, if a party spawns and then a second copy spawns before the first one is killed, then killing either party will not increase Flag 1. Instead, both parties must be killed and Flag 1 will still only increase by 1, instead of 2.

If a third copy of the same party spawns before both parties are killed, then that third copy must also be killed in order for Flag 1 to be increased by 1 and only by 1.

If all those parties are killed, and another party spawns only after the prior parties are killed, then only that lone, last party needs to be killed to increase 1, just like in the first line of the example. And so on if more parties spawn.

As seen in the example, there is a lot of variance and inconsistency in the way Flag 1 increases due to this script quirk. That's what makes this quirk also the most dangerous out of all three as it's the one most likely to completely break a script if a scripter isn't cautious enough.

* * *

Lastly, there is a significant difference as to when this trigger is applied directly to a party and when it is applied to a specific member within that party. The quirk for when applying it to a specific member applies to both the 'When Dying' and 'When Killed' trigger.

Like when applying this trigger to a party, the conditions 'group up' for all active copies of that same member. Meaning, if there are, say, three active copy parties that each contain the same member with a 'When Killed' trigger, the trigger on that member will only set off once for all active members.

However, unlike with the above mentioned party scenario, the trigger doesn't set off when all of the active copy members are killed. Rather, it sets off when only one of the copy members dies. It doesn't matter if it's the first, second, or third spawned. All that matters is that one of them has to die and the trigger will set off immediately.

What makes this a quirk, however, is the fact that the trigger still only sets off once. For all following copy members who die, the trigger will not set off.

Like with the party scenario, however, this only applies to all currently existing / active copy members. If they're all killed before more spawn, then the first copy to die in the newly spawned parties will set off the trigger once again.

The example for this is pretty much exactly the same as with the party variation of this quirk.

In short, the difference between the party and individual member variation of this quirk is the timing as to when the trigger sets off. With the party variation, it sets off once when all active copies of that party die. For the member variation, it sets off once when the first of all active copies of that member die. Similarly, the party variation of this quirk is equally dangerous to scripts.

Repeat Commands
The last quirk is very straightforward.

Simply put, repeat commands don't work. The game completely ignores any repeat conditions attached to a Hero Party or any member within a Hero Party. Every trigger will hit off only once, but it is also a 'once per party'.

I found this out when attempting to create a script to change patrol routes on a respawnable Hero Patrol party.

* * * * * * * * * *

I hope this information provides useful and can allow for level designers to create more advanced maps without running into the same kind of scripting issues / hells that I encountered when I first discovered these quirks.