Modules in ZQuest

Something I've been working on the past few weeks is cleaning up the code related to the .qst file data structures; as part of that I've taken steps to fix one annoying aspect of quest development, which is the inability to export only some enemies, items, etc: you currently have to export everything or nothing, whereas ideally, you could download from the QDB a self-contained module containing one new type of enemy, a different module containing new items, etc. and easily integrate them all into your quest.

Attachment 211
Attachment 212
Attachment 213

This will be possible in the next (post 2.50) version of ZC. Each quest can contain multiple modules, each of which is a collection of independent assets like enemies and items (currently enemies, items, and sprites are implemented; I will do combos next.) You can import one set of enemies, for instance, and it won't touch any of the existing enemies in your quest. Likewise you can create a module of a small handful of custom enemies and export them for others to use.

The CORE module is the one that comes with a default blank quest; the other module is one I created and populated with a few quick enemies. You can add new enemies etc to any module, and copy/paste between modules, etc as expected. Oh and incidentally the hard-coded limits on the number of enemies, items, and sprites is gone, which I know was hindering some people.

Any place in the GUI where you need to specify an enemy, item, or sprite, you now specify the module and the item (e.g.) within that module (see screenshots).

There are however a few issues still needing to be worked out:
- there are several hard-coded sprites, items, and enemies still used by ZC (the fires that appear in guy rooms, the selector icon in the active subscreen, etc). Hopefully this number dwindles over time, but for now if you want to change these you have to modify the appropriate entries in the CORE module.
- scripts currently can only access stuff in the CORE module, but eventually there will be a ZScript command for choosing the module when loading itemdata etc.
- although all of the above sounds like a simple change, implementing it required cleaning up a lot of cruft in the ZC and ZQ codebase. There will be bugs at first until all of the kinks are ironed out, but this cleanup is a necessary evil to make adding more new features to the ZC code manageable (including, eventually, scriptable enemies and weapons).

Great stuff!!! :D

+1

So, this is about the same concept that I discussed for the .dat files; right?

Some things that should be forwarded:

Quest Numbering, and Name Entry Skips; such as ZELDA skipping to quest ID 2. These should be a module setting. The quest filename name for each quest in series, and any special rules (Quest Nmber 1 -> 2 unless 29 deaths ->4) and so forth.

Most defdata should be in the module.

Fonts, obviously, need to be in there. I still want to add alfont.h though, so we can discuss that later.

I will try to come up with a list of assets that should be in each. I'm not certain why a 'CORE' module is needed though. Having one module per assets pack that can be treated as a core, and tack-on bits as modules seems logical, too; and would ease change-outs.

Not quite. The modules I'm talking about are things that make sense to have several sets of within a quest: enemies, items, combos, tiles. Things like quest rules, name of the quest, and font are exactly what does not go in a module since it never makes sense to load more than one of these things per quest.

Nice! It's not exactly something I would've asked for but this would be great to have. Might be good for exporting enemies from the Enemy of the Month contest? If they're enemy editor enemies.

Sure. My eventual goal is that you would be able to export a custom enemy or boss complete with its tiles and scripts and any quest author would be able to easily import and use it.