Brief summary of issue:
Named matches can be created by (?<example>) and will be accessible in matches or multimatches by their name. For some reason line spacers, lua functions, prompt checks, and possibly others are ignored when counting which multimatches table to include them in. The result is that if you use a three line trigger with one of the affected types as the second line, a named capture in the third will appear in multimatches[2], while its numbered capture appears in multimatches[3].
Steps to reproduce the issue:
- Create a trigger with three inputs, the second being a line spacer of 1, and a delta of 1
- Display multimatches on successful execution
- Trigger whatever two-line text you made the trigger for
Error output
N/A
Extra information, such as the Mudlet version, operating system and ideas for how to solve:
Unfortunately, fixing this will be a breaking change for anyone who relied on this behavior. On the plus side, it's unlikely anyone but me relies on this behavior right now, as named captures are not a well-known feature.
Garuda Linux 64-bit (current), AUR build of 4.19.1
Brief summary of issue:
Named matches can be created by
(?<example>)and will be accessible in matches or multimatches by their name. For some reason line spacers, lua functions, prompt checks, and possibly others are ignored when counting which multimatches table to include them in. The result is that if you use a three line trigger with one of the affected types as the second line, a named capture in the third will appear in multimatches[2], while its numbered capture appears in multimatches[3].Steps to reproduce the issue:
Error output
N/A
Extra information, such as the Mudlet version, operating system and ideas for how to solve:
Unfortunately, fixing this will be a breaking change for anyone who relied on this behavior. On the plus side, it's unlikely anyone but me relies on this behavior right now, as named captures are not a well-known feature.
Garuda Linux 64-bit (current), AUR build of 4.19.1