-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raidboss: update arr and responses to use player objects #5891
Conversation
@valarnin A couple of things this brings up is:
|
d6adbec
to
8273168
Compare
I see two options here:
I'm fine with either one, honestly. The latter option would probably be better to reduce boilerplate in triggers though, and still be detectable if a trigger explicitly needed to check for it?
I think there are a couple of other questions that would need answered first:
const inputStrings = ['A', 'B', 'C'];
const outputString = 'something ${value}';
const option1Result = 'something A,B,C';
const option2Result = 'something A,something B,something C'; |
As far as I can tell, this is generally what gets used, e.g. A quick search for I could see an argument that this is ~ok and if it's awkward in a particular language that trigger could handle it specially.
I think |
Followup to #5861 and discussions on #5891. As the comment in the code specifies, if a trigger passes in [player1, player2, player3] as a value, and a user specifies `${players.job}`, then return: `${players[0].job}, ${players[1].job}, ${players[2].job}`. In general, this means that all array elements must either be simple strings/numbers or all share the same prop, or there will be errors below about non-existent properties. In practice, this likely will never happen. This will also handle simpler cases like: `output.safeSpots({ dirs: [output.front!(), output.back!(), output.left!()] })` This also allows for `data.party.member(undefined)` to return '???', just to reduce boilerplate.
Followup to #5861 and discussions on #5891. As the comment in the code specifies, if a trigger passes in `players: [player1, player2, player3]`, and a user specifies `${players.job}`, then return: `${players[0].job}, ${players[1].job}, ${players[2].job}`. In general, this means that all array elements must either be simple strings/numbers or all share the same prop, or there will be errors below about non-existent properties. In practice, this likely will never happen. This will also handle simpler cases like: `output.safeSpots!({ dirs: [output.front!(), output.back!(), output.left!()] })` This also allows for `data.party.member(undefined)` to return '???', just to reduce boilerplate.
#5895) Followup to #5861 and discussions on #5891. As the comment in the code specifies, if a trigger passes in `players: [player1, player2, player3]`, and a user specifies `${players.job}`, then return: `${players[0].job}, ${players[1].job}, ${players[2].job}`. In general, this means that all array elements must either be simple strings/numbers or all share the same prop, or there will be errors below about non-existent properties. In practice, this likely will never happen. This will also handle simpler cases like: `output.safeSpots!({ dirs: [output.front!(), output.back!(), output.left!()] })` This also allows for `data.party.member(undefined)` to return '???', just to reduce boilerplate. c3214ca
Followup to #5861.