[feature] separate binary for misc lump handling, generation, transformation

[elf-alchemist]

This is issue is a long-term proposition, that will likely only be truly tackled (that is, if it will be tackled at all) after most of the ID24 implementation is nearing completion.

In the KEX release of Doom, I happened to come across the console command maketrackhashfile, it automatically generates a fully fledged TRAKINFO lump for the music lumps used in a given WAD, specifically, it seems to parse lumps such as UMAPINFO and interlevel scripts to find the default "Off" tracks.

It reminded me of the automatic generation of the TRANMAP and SKYTRAN lumps built-into the engine, and I thought to myself of making an issue to add this in Woof!, however I noticed it may very well be too much to put inside just the woof binary.

So I'm now thinking that it would be really nice to have such a hypothetical woof-utils binary to handle generating such assorted lumps and templates, as a modder I've found myself interested in using these kinds of lumps, but felt limited by both SLADE not supporting working with most of them, or felt the cumbersomeness of having to use either the Boom utils in DOSBox or the Windows version via Wine, such as the DAT to LMP converter for the generated TRANMAPs.

Such a util binary would help enable a lot more of the simpler tweaking and modification of WADs by consolidating this misc tooling in one place for modders to work with.

The main idea from this issue is to have an easier time using the useful Boom Editing Utils and other hard-to-manually-use utility lumps in a more modern, more streamlined and consolidate fashion.

To get a general idea, support for this would include a feature set similar (but not strictly identical) to the following:

• Generating TRANMAP/SKYTARN lump to user-defined levels of translucency percentage and algorithm (additive, subtractive, etc), via preferably command-line parameters.
  • For example woof-utils -tran 50 -algo additive.
• SWANTBLS <-> ANIMATED/SWITCHES compilation and decompilation.
• Algorithmic generation of PLAYPAL, COLORMAP and CR*, including use of "translation strings" to map one set of colors to another.
• MUS to MIDI conversion, optionally including playback for testing Woof's handling of MIDI playback, for a quick and dirty way to test without needing to launch it.
• UMAPINFO template generation
• Generating JSON lump templates
  • TRAKINFO based on the currently used music tracks, falling back to vanilla defaults when needed, etc
  • COMPDB template from a supplied WAD's maps
  • DEMOLOOP vanilla defaults temaplate or simplified minimal definition
  • interlevel and endfinale scripts based on vanilla defaults or simplified minimal definition
  • GAMECONF template, optionally including the player translation defaults.
• Etc, etc...

[rfomin]

I think it will be much more convenient for users if we add this functionality to SLADE. It already supports editing most of the Boom features, right?

Generating TRANMAP/SKYTARN lump to user-defined levels of translucency percentage and algorithm (additive, subtractive, etc), via preferably command-line parameters.

• For example woof-utils -tran 50 -algo additive.

We don't have any alternative algorithms yet. There is woof -dumptranmap <name> command line parameter.

SWANTBLS <-> ANIMATED/SWITCHES compilation and decompilation.

I think it works in SLADE?

MUS to MIDI conversion, optionally including playback for testing Woof's handling of MIDI playback, for a quick and dirty way to test without needing to launch it.

No reason to use MUS these days.

UMAPINFO template generation

There are many examples of how to use UMAPINFO, and the format itself is simple enough.

Generating JSON lump templates

There should be an editor for ID24 lumps, but no one has made one yet. Ideally it should also be integrated into SLADE. We can add TRAKINFO generation as it's simple enough, everything else is not for editing by hand.

[fabiangreffrath]

I agree that this is mostly stuff that should get proper support directly in a resource editor like SLADE. The fact that most of this isn't already in SLADE doesn't mean that it should get added elsewhere instead. Although we already support some of these ideas to a certain degree (e.g. export of the generated color translation tables), I also agree that we shouldn't turn (or extend) this port into a utility collection with features that strictly belong into SLADE (or whatelse WAD editor).

[elf-alchemist]

After giving some time to think about this a little better, I concur with the decision to not support all of these features.

Certainly, TRAKINFO auto-generation will be the one with the most mileage and significance.

It's behavior on KEX is to parse all relevant music defining lumps, I believe it seems to be UMAPINFO, interlevel, endfinale and demoloop, and generate only the minimal JSON needed for the maps / screens needed.

For example, I had tested it on a two-map PWAD of a friend and it had generated an entry for D_DM2TTL, D_DM2INT, D_READ_M, D_MAP01 and D_MAP02 (both defined in UMAP). Maybe Woof won't need to check every single possible thing (such as if a intertext screen even appears in the map flow) but it's just something to consider.