Complex items and optionality
Closed this issue · 6 comments
Many things in 5e contain options, whereby the AE to activate depends on a choice made. This leads to two options for data:
- Split each option out into a different Foundry item (and therefore a different button on the sheet)
- Use a macro to create a pop-up querying which option the player would like to trigger
The latter is neater and more intuitive imo, but it might be slow if a player never uses a certain option. We need to agree how to handle this—and whether we are happy to accept 'half-complete' items until a general solution is found—because there's probably a fucctonne of items that it applies to
Only one item please imo. You're only importing one thing from plutonium, you only expect one thing. So needs to be a macro. But also how would you implement that macro, is there a template you'd need to use for every item like that, or can you structure the data such that the module/plutonium generates a standard macro from an array of options?
is there a template you'd need to use for every item like that
Midi QoL has a (non-AE) option to trigger a macro when an item is activated (i.e. clicked). Using Item Macro, we can bundle this macro with the item itself rather than import it into the normal macros directory.
I agree it would be nice to have all the popups be 'consistent' with each other in styling, but the issue is that the macro will invariably have more programming than just the popup. That is, once the popup appears, you need to write code to handle what each button does, and that has to be included in the same macro! I suppose in principle the popup could be triggered by a core Plutonium function with reliable behaviour, so the PAD-only, item-specific macro only needs to call the initial 'create modal' function and provide instructions for each result.
await plutonium.optionsPopup.create(
"Body text <b>with HTML</b> and whatnot like.",
"Button 1", "function1",
"Button 2", "function2"
);
function function1 {
executeCommands();
}
function function2 {
executeCommands();
}
function closePopup {
executeCommands();
}
I agree, one item/feature in the game equals one item on the character sheet, so please use macros. I personally do not see a reason to dictate code structure, format, or styling.
The reason to at least have a style guide is so other people can review the code easily, if it ever needs updates! This could be fixing a bug, an API change, Midi overhauling itself, etc.
The only requirements I'd like to 'enforce', to be clear, are:
- Write comments (obvious)
- No minified code unless the human-readable one is available somewhere else (see #22 )
- Use the same pop-up formatting as everything else (which we can draft whether or not Giddy makes some Plutonium magic to make it easier; this is to provide a 'consistent' experience so users don't have to constantly reread every single pop-up because they're all phrased differently)
Whatever solution I end up cobbling together for jamming macros into proceedings, I'll make it eslint
-able, so a minimum bar for code styling will be in place
Writing good code is a whole different kettle of fish, and (un)fortunately not machine-enforceable (yet 😓)
kinda made irrelevant by CPR/etc. managing it better than anything any of us clearly have the effort to maintain 😏