raidboss: Issues with unicode characters in timeline entry names and regex syncs

[wexxlee]

While working on P10N, I noticed an issue with uncode support in the raidboss timeline functionality:

1. If unicode characters (specifically, æ) are included a timeline entry name, the timeline entry will display the character as (�) in the UI.
2. Regex syncs do not appear to catch the line, and the timeline seems to run without syncing to those lines.

[quisquous]

While working on P10N, I noticed an issue with uncode support in the raidboss timeline functionality:

1. If unicode characters (specifically, æ) are included a timeline entry name, the timeline entry will display the character as (�) in the UI.

If I change a timeline entry, I see this:

Is this what you mean for this point, and isn't appearing correctly?

[quisquous]

2. Regex syncs do not appear to catch the line, and the timeline seems to run without syncing to those lines.

As a test, I added this line to t9.txt and went in unsynced.

0.0 "--sync--" sync /Pandæmonium/ window 0,1 jump 693.6

If I type /echo Pandæmonium into chat, it starts the timeline successfully.

[wexxlee]

Sorry for the long delayed reply - didn't have a chance to get back in and spend more time looking at this until now.

Is this what you mean for this point, and isn't appearing correctly?

Sorry, I should have been more accurate. I actually meant the timeline overlay itself. Here's what it looks like for me when the unicode character is included in the timeline entry name:

Wondering if perhaps this is just a font issue though, and not indicative of a broader problem with unicode support?

If I type /echo Pandæmonium into chat, it starts the timeline successfully.

I can still repro the timeline sync issue. As a test, I ran a local webpack instance and modified the p10n.txt timeline file. During my first test pull, I changed the regex to use the actual unicode character instead of the escaped one for the first half-dozen entries, e.g.:

0.0 "--sync--" sync /Engage!/ window 0,1
2.5 "--sync--" sync / 1[56]:[^:]*:Pandæmonium:827A:/
7.9 "--sync--" sync / 14:[^:]*::Pandæmonium:8259:/ window 15,15
10.9 "Silkspit (marked)" sync / 1[56]:[^:]*:Pandæmonium:8259:/
23.0 "Silkspit (resolves)" sync / 1[56]:[^:]*:Pandæmonium:825A:/
35.4 "Pandæmoniac Pillars" sync / 1[56]:[^:]*:Pandæmonium:825D:/

There was no countdown during that pull, and the timeline overlay never appeared or started running (which to me suggests the 2.5 --sync-- never matched based on the regex change.

I then ran a second test, changing the timeline entries as follows:

0.0 "--sync--" sync /Engage!/ window 0,1
2.5 "--sync--" sync / 1[56]:[^:]*:Pand\u00e6monium:827A:/
7.9 "--sync--" sync / 14:[^:]*::Pand\u00e6monium:8259:/ window 15,15
12.9 "Silkspit (marked)" sync / 1[56]:[^:]*:Pandæmonium:8259:/
27.0 "Silkspit (resolves)" sync / 1[56]:[^:]*:Pandæmonium:825A:/
41.4 "Pandæmoniac Pillars" sync / 1[56]:[^:]*:Pandæmonium:825D:/

In other words, I ensured the 2.5 --sync-- to 827A and the 7.9 --sync-- to 8259 would match, but then added +2 seconds to the next 3 abilities (still using the unicode character in their regex) to detect if it would sync to that line and jump. In theory, if the regex with the unicode character were working, I would expect to see:

• Timeline clock 10.9 - match 12.9 entry and jump +2 seconds
• Timeline clock 25.0 - match the 27.0 entry and jump another +2 seconds
• Timeline clock 39.4 - match the 41.4 entry and jump another +2 seconds

It did not match any of those entries, or jump -- instead, the entries became increasingly delayed/out of sync with actual game actions.

Interestingly, the other issue I originally saw (and even reproduced last week) -- where using the unicode character in netRegex trigger properties also would not match -- I can no longer reproduce. I added the following test trigger to p10n.ts:

   {
      id: 'P10N Pandæmonic Pillars Test',
      type: 'StartsUsing',
      netRegex: { id: '825D', source: 'Pandæmonium', capture: false },
      delaySeconds: 2,
      durationSeconds: 5,
      infoText: (_data, _matches, output) => output.test!(),
      outputStrings: {
        test: {
          en: 'Testing unicode output',
        },
      },
    },

It fired correctly each time. So I have no idea why I can no longer repro that issue, but if in fact it's been resolved, that would remove the need to do const bossNameUnicode stuff in the zone files. I think I need to do a little more testing though to see if I can repro it somehow.