raidboss: Allow overwriting triggerSet with the same ID

[Souma-Sumire]

This allows user js files to fully override build-in triggerSet behaviors by using the same ID.

It enables a streamlined way to deactivate all built-in triggers, ensuring that data variables are no longer subject to unexpected modifications.

This implementation finally makes script management completely predictable, solving a challenge I have faced for a long time.
I sincerely hope this feature can be merged.

[etnAtker]

I strongly support merging this PR.

This brings triggerSet behavior in line with what users actually expect: user customization should win over built-ins. The current "first wins" logic silently ignoring later definitions makes it impossible to cleanly patch a built-in set.

Switching to "last loaded wins" is much more intuitive. Just like with individual triggers, using the same ID is a clear signal that I intend to replace the original. Since load order is deterministic, this doesn't introduce any randomness.

I'd much rather deal with accidental ID collisions (which we can log) than the current behavior where overrides just silently fail. I write and share triggers for my group constantly when new content drops, and this has been a specific pain point for a long time. Would love to see this fixed.

[FloresWayne]

Strongly support this change.

Allowing user triggerSets to override built-in ones with the same ID finally makes raidboss behavior predictable and controllable.

For advanced users maintaining custom scripts, this is far cleaner than relying on partial disables or fragile workarounds.

This solves a long-standing pain point — hope to see it merged.

[DieMoe233]

I also agree with this PR—the current loading logic isn't as convenient as expected, and users often have to double-check their custom files.

[valarnin]

I think this is a good change and support it as well. I would like to examine the logic changes in more detail though when I get some time -- please hold for my review at the least.

[jacob-keller]

Throwing my hat in the "support merging this PR"

[valarnin]

These changes look good in general and the logic makes sense, but some thoughts/questions:

1. Was raidemulator tested with these changes? I don't think there will be any issues, but some of the popup-text overrides in raidemulator are fragile.
2. Currently these overrides will only work for user/raidboss.js or user/raidboss/*.js overrides, because there's a test rule to have unique triggerset IDs. This means that devs that want to use typescript can't leverage this functionality. Should we designate a "custom" folder for dev-specific triggersets which is excluded from some or all tests and gitigore'd, e.g. ui/raidboss/data/99-custom/*?

[Souma-Sumire]

1. Was raidemulator tested with these changes? I don't think there will be any issues, but some of the popup-text overrides in raidemulator are fragile.

Tested via raidboss config and raidemulator:

user/My Trigger.js

Options.Triggers.push({
  id: "TheMinstrelsBalladZodiarksFall",
  zoneId: ZoneId.TheMinstrelsBalladZodiarksFall,
  triggers: [
    {
      id: "ZodiarkEx Kokytos",
      type: "StartsUsing",
      netRegex: { id: "6C60", capture: false },
      infoText: "big AOE from user js",
    },
  ],
});

raidemulator

→

config

↓

raidboss

→

[Souma-Sumire]

2. Currently these overrides will only work for user/raidboss.js or user/raidboss/*.js overrides, because there's a test rule to have unique triggerset IDs. This means that devs that want to use typescript can't leverage this functionality. Should we designate a "custom" folder for dev-specific triggersets which is excluded from some or all tests and gitigore'd, e.g. ui/raidboss/data/99-custom/*?

Added.