raidboss trigger development rule question
Souma-Sumire opened this issue · 4 comments
English is not my native language; please excuse typing errors.
I've created a trigger for GolbezEx's Gale Sphere mechanic, and I receive all four upcoming texts when the first sphere appears. Subsequently, I delay their output by 6.5, 10, and 13.5 seconds, respectively. However, to achieve this, I must create four separate triggers.
The issue that arises is that I don't need to receive the required text in the output for the next three outputs; instead, it is obtained in the output of the first trigger and then saved in data for use in the subsequent three triggers. However, this violates the 'no outputStrings in trigger' rule.
If I adhere to this rule, users would have to repetitively modify their output text four times.
What should I do in this situation? Thank you!
Code Details Image
I've created a trigger for GolbezEx's Gale Sphere mechanic, and I receive all four upcoming texts when the first sphere appears. Subsequently, I delay their output by 6.5, 10, and 13.5 seconds, respectively. However, to achieve this, I must create four separate triggers.
Before creating a new trigger, I might suggest looking at the Gale Spheres trigger that's already in place for the Golbez Normal raid, as it already handles that mechanic.
https://github.com/quisquous/cactbot/blob/main/ui/raidboss/data/06-ew/trial/golbez.ts
It's been a minute, but iirc, I think I shamelessly copied the logic for that trigger from valarnin's original (still WIP) PR #5425 for Golbez Ex. Regardless, I would suggest keeping the same trigger logic that's used for Golbez normal for GolbezEx unless there's a reason to deviate (and iirc, I don't think there is).
But as to the code in your PR: it's hard to tell without seeing the full code, but I'm not sure I see a need to do four separate triggers, since I think your regex for each trigger looks(?) identical. It should just be a matter of capturing each cast and sticking the directional info sequentially in data.[whatever] (if that's even necessary).
The issue that arises is that I don't need to receive the required text in the output for the next three outputs; instead, it is obtained in the output of the first trigger and then saved in data for use in the subsequent three triggers. However, this violates the 'no outputStrings in trigger' rule.
EDIT: Sorry, I was speed-reading and missed the issue. If you're writing your own triggers, you can return a string directly from infoText, but if you are planning to PR the trigger, lint will alert if you try to return a string; I believe the requirement is to use outputStrings indirection so that the content of the string can be changed for each trigger in the UI. (It's mentioned in https://github.com/quisquous/cactbot/blob/main/docs/RaidbossGuide.md)
Hope that helps!
First of all, thank you for your response.
I did indeed forget to check the trigger for the normal difficulty or the existing PR, and I appreciate the reminder.
However, I'm currently not planning to submit it to the main branch. I'm using TypeScript to help me develop my custom triggers temporarily. There's still a lot for me to learn, so for now, I'm just asking about this particular rule.
If needed, my complete code is here
The reason I divided it into four parts is that it would be very confusing if the text was read all at once. So, I designed it to display all safe zone texts first, and the TTS (Text-to-Speech) announces the next safe zone after each judgment. Personally, I believe this is more "disability-friendly," so I did it this way. I think I need to use infoText, and I don't need outputString.
So, maybe I can "ignore" this issue since I'm only creating it for personal triggers? Or is there a way to manually bypass it, like //@ts-ignore?
Once again, thank you for your response!
I find // eslint-disable-next-line to disable error, Maybe this is what I need.
// eslint-disable-next-line rulesdir/cactbot-output-strings will do it more narrowly as well and not disable other errors.
And yeah, the underlying reason for this rule is that it makes it more clear to users where the output is coming from if every trigger has its own output strings. There's no way to know in the cactbot config ui that to modify the output of trigger B that you should find trigger A and modify it instead.
It's not a perfect solution and it makes things awkward in situations like this where you have one trigger with all the logic and several other triggers to call things out. Even if you do things like endsinger-ex's const orbOutputStrings and just outputStrings: orbOutputStrings for each trigger, it still does mean that users have to fill in each of them redundantly.
I think there is probably a use case for "trigger set output strings", where the triggerset itself has some shared set of output strings that users can fill in once and that apply everywhere. I think I'd still maybe want cactbot developers to fill in which outputstrings are used so we could display that in the UI though? Alternatively, maybe some way of grouping triggers together that say "hey all of these four triggers use this set of outputstrings", but the ui for that is less clear.