We are no longer limited to every detail of any user dialog being statically defined for a ?{...} statement in the code, since we can now execute such code dynamically. We can store input controls in attributes, e.g. if MacroSheet.myUniqueInput is set as ?{Input|a,0|b,1|c,2}, this script...
!mmm script
!mmm set choice = "@{MacroSheet|myUniqueInput}"
!mmm chat: ${choice}
!mmm end script
... launches the input control and writes the chosen value to the chat (0, 1 or 2).
A separate script, executed before the one above is even sent to MMM and thus parsed/expanded by the Roll20 chat engine, could dynamically set the myUniqueInput attribute and thus change the options given to the player or even replace the entire control by a preset value or nothing at all (""). They cannot be part of the same script / execution chain, since then the Roll20 attribute reference would be expanded before it got changed by MMM.
How would the second script get called from the first without adding a chat button that would complicate UX?
What does not work:
Dynamically generating code that includes ?{...} Roll20 user controls via !mmm chat: !mmm set var = ${"?"}{...}
Same if we use @{...}: this gets expanded once, so we'll get the ?{...} code from the attribute but that code is not executed.
Outside chat buttons, we cannot use customize blocks to reinject input to a script, since code dynamically executed through the chat does not expand %{char|ability} references and sending the entire script to the chat using !mmm chat: statements with the necessary escaping would be very inconvenient and prone to bugs.
We are no longer limited to every detail of any user dialog being statically defined for a
?{...}
statement in the code, since we can now execute such code dynamically. We can store input controls in attributes, e.g. ifMacroSheet.myUniqueInput
is set as?{Input|a,0|b,1|c,2}
, this script...... launches the input control and writes the chosen value to the chat (0, 1 or 2).
A separate script, executed before the one above is even sent to MMM and thus parsed/expanded by the Roll20 chat engine, could dynamically set the
myUniqueInput
attribute and thus change the options given to the player or even replace the entire control by a preset value or nothing at all (""
). They cannot be part of the same script / execution chain, since then the Roll20 attribute reference would be expanded before it got changed by MMM.What does not work:
?{...}
Roll20 user controls via!mmm chat: !mmm set var = ${"?"}{...}
@{...}
: this gets expanded once, so we'll get the?{...}
code from the attribute but that code is not executed.customize
blocks to reinject input to a script, since code dynamically executed through the chat does not expand%{char|ability}
references and sending the entire script to the chat using!mmm chat:
statements with the necessary escaping would be very inconvenient and prone to bugs.