[#6923] Add system-specific adventure importer dialog with actions

[arbron]

Adds a new Adventure Importer sheet that follows the dnd5e design style. Following the example of core with its V2 importer, this sheet is not made default and instead must be opted into on a per-adventure basis.

The new sheet includes support for pre- and post-import actions which are presented as checkboxes on the importer sheet to give control to users. There are three actions initially provided by the system: "Activate Scene", "Display Journal", and "Customize World", but modules can add their own actions.

Each adventure can use flags to define which of the actions is run when that adventure is imported and customize their behavior. There is also a new AdventureRegistry that allows defining actions for a single adventure or for all adventures in a module. Actions added through the registry can support custom handlers without having to add to the global configuraiton.

// These actions will be run across all adventures in the module
dnd5e.registry.adventures.setModule("dnd-adventures-faerun", {
  importActions: ["activateScene", "displayJournal"]
});

// This specific adventure has a different set of actions
dnd5e.registry.adventures.setAdventure("Compendium.dnd-adventures-faerun.adventures.Adventure.OJuc9WnDJDAETIFr", {
  importActions: [{ id: "displayJournal", journalId: "x0TaNijLJkanmufc" }]
});

The system also contains a dialog that presents actions available after using quickstart to load the adventure. By adding a separate quickstart handler actions can opt in to support on quickstarted adventures. These actions are passed all of the adventures that have that action and their configs so they can optimize if more than one adventure is quickstarted.

[Fyorl]

Good consolidation. Some parts of the design I am not convinced of yet.

So far our use of registries in the system are passive, they collect information at load. We don't have modules actively writing into them. For that pattern we use CONFIG.DND5E. I would prefer we continue with that, so I would propose either namespacing CONFIG.DND5E.adventures.importActions, e.g. CONFIG.DND5E.adventures.importActions.dnd-tomb-annihilation = { myHandler: ... }, with shared actions going under the dnd5e namespace; or keeping the shared actions at the top-level and requiring custom actions be prefixed, e.g. CONFIG.DND5E.adventures.importActions["dnd-tomb-annihilation.myHandler"] = ...

I am also not a fan of the flags and having multiple ways to define handler payloads. I would prefer we just had one way, also via CONFIG.DND5E, e.g.

CONFIG.DND5E.adventure.imports["Compendium.dnd-tomb-annihilation.adventures.Adventure..."] = [
  { id: "activateScene", initialScene: "..." },
  { id: "displayJournal", initialJournal: "..." }
];

[arbron]

Good consolidation. Some parts of the design I am not convinced of yet.

So far our use of registries in the system are passive, they collect information at load. We don't have modules actively writing into them. For that pattern we use CONFIG.DND5E. I would prefer we continue with that, so I would propose either namespacing CONFIG.DND5E.adventures.importActions, e.g. CONFIG.DND5E.adventures.importActions.dnd-tomb-annihilation = { myHandler: ... }, with shared actions going under the dnd5e namespace; or keeping the shared actions at the top-level and requiring custom actions be prefixed, e.g. CONFIG.DND5E.adventures.importActions["dnd-tomb-annihilation.myHandler"] = ...

I am also not a fan of the flags and having multiple ways to define handler payloads. I would prefer we just had one way, also via CONFIG.DND5E, e.g.

CONFIG.DND5E.adventure.imports["Compendium.dnd-tomb-annihilation.adventures.Adventure..."] = [
  { id: "activateScene", initialScene: "..." },
  { id: "displayJournal", initialJournal: "..." }
];

Switching over to config sounds good.

My main motivation to also having flags as an option is it allows simple setups to be done without requiring adventure modules to dig into code. A creator can just set a few flags on the adventure itself and not have to add a javascript file and handle extra configuration. I'll put up my updated version to see what you think, but I can still pull out the flag stuff.

[Fyorl]

My main motivation to also having flags as an option is it allows simple setups to be done without requiring adventure modules to dig into code. A creator can just set a few flags on the adventure itself and not have to add a javascript file and handle extra configuration.

Is the idea that they would add these flags directly to their unpacked adventure YAML? Because adding flags in-app also requires some macro/coding, right? Or were you thinking of adding another app like with the journal flags?

[arbron]

My main motivation to also having flags as an option is it allows simple setups to be done without requiring adventure modules to dig into code. A creator can just set a few flags on the adventure itself and not have to add a javascript file and handle extra configuration.

Is the idea that they would add these flags directly to their unpacked adventure YAML? Because adding flags in-app also requires some macro/coding, right? Or were you thinking of adding another app like with the journal flags?

Wasn't thinking of another config app, but a macro that just does adventure.setFlag("dnd5e", "importActions", ["openScene"]); is pretty simple.

[Fyorl]

Wasn't thinking of another config app, but a macro that just does adventure.setFlag("dnd5e", "importActions", ["openScene"]); is pretty simple.

Well a macro is code, but I suppose it's less code. Seems like it's basically free to support flags though so I don't really have any objection. This all looks good to me.