Use Case Question (possible enchantment) : Pioroty Order from source file locations

Start by reading the DoomTools documentation or entry points for doommake's source discovery and WAD-building behavior; the issue does not name specific files or tests. Trace how patch lumps and texture definitions are selected from loose sources, resource WADs, and the IWAD. Done means the precedence is documented or implemented so converted loose patches can be used while definitions still come from the resource WAD.

I'm having a small usability issue in my new project and thought I would ask if you know of a procedure with doomtools to get around it, or if not, maybe this is actually and enhancement request.

In Short

When doomtools finds source files... how are multiple copies of the same lump handled. Like say I have a patch with the same name in the src\textures\patches, in \src\convert\patches in _\src\wads\textures\aResource.wad_ and inside the doom.wad. How dose doomtools determine which version of the patch file is used? if it just adds it from all the sources and the last one written is the final one found the wad, then what is the write order?

Practical Example

• I have a custom pal0, placed in \src\convert\palettes
• I'm using a resource wad called aResource.wad placed in \src\wads\textures
  • Images extracted from a \src\wads\textures\aResource.wad are copied directly, without palatalization.
  • crucially, texture definitions for the patches are also copied from aResource.wad into the release.wad.
• I use doommake explode to extract all the patches from aResource.wad as pngs and then place them in \src\convert\patches
  • doommake will now convert all those patches to the /build/convert folder, as in re-palatalize them to the new custom pal0.
  • crucially, the texture definitions are not defined for these extracted patches in src\textures. The texture definitions are still only in the aResource.wad. So the texture.wad in the build dir, while containing the new converted patches, dose not contain any of the definitions, so can not be used in udb, without adding the texture definitions and switch and animation definitions
• When running UDB I add the aResource.wad as normal, and map away. On build, doomtools will create the release.wad only using the patches from aResource.wad that I have applied to the map, as well as merging the texture definition from aResource.wad, for that texture into the release.wad texture definitions
  • crucially, the actual patches added to release.wad are coming from aResource.wad, not the build/convert dir.

Here is the rub : As I am using a custom playpal, so I need the aResource.wad image data to be converted... BUT I need the texture definition imported from the wad file.

So, now that I have the original resource wad in \src\wads\textures\ containing the texture definitions and patches lumps that are NOT converted, and the loose patch pngs for that wad in src\textures\patches that convert to the new palette and are stored in build/convert.

BUT... the resulting release.wad is using the patch files from the aResource.wad and ignoring the converted patch files in build/convert.

Work Around

The way I am working around this is sorta cumbersome. Basically I have to rebuild the entire resource wad so the file in src/wads/textures actually has the converted patches inside it.

The problem is that, currently, all the tools I use to do this are listed as work in progress. So I am not sure if the resulting wads are actually fully functional.

• doommake explode has a "experimental" warning
• WTExport help says "doesn't read ANIMDEFS", while this is not an issue as I work in vanillia or boom/mbf21 it is a problem for some other formats

So I take the resulting texture.wad (the one with all the patches but no texture or animation definitions created from the patch source dirs the extract the lumps from the original resource.wad

wadtex source.wad -x texture1.txt -n TEXTURE1
wadtex target.wad -i texture1.txt -n TEXTURE1

wadtex source.wad -x texture2.txt -n TEXTURE2
wadtex target.wad -i texture2.txt -n TEXTURE2

wswantbl source.wad -x DEFSWANI.txt
wswantbl target.wad -i DEFSWANI.txt

• Then delete the patches from src/convert/patches
• rename the textures.wad file (now with the texture and swanim lump) into aResource-rePalatalized.wad
• delete /src/textures/wads/aResource.wad
• move aResource-rePalatalized.wad into /src/textures/wads/

Basically I have rebuilt the entire resource wad, but now it contains the converted patches

The Actual Question

Is all THAT the correct way to do this? If you want to use a resource.wad but need the patched rePalatalized, you have to somehow rebuild the entire wad, ensuring that during the process you have not broken anything.

Possible Enchantment Suggestion

It seems that maybe a priority system on the source directories could automate this entire process, but taking the texture definitions from the resource.wad as normal, but if patches are in the build/convert folder of the same name, then those files are always used as priority over anything from src/textures/wads or the iwad itself.

So the final procedure for all that above would be..

• add aResource.wad to src/textures/wad
• explode aResource.wad and copy all patches into src/comvert/patches

Now when in UDB you use it as normal, and on build it is taking the texture and animation definitions from aResource.wad, but when adding the actual graphic data, it is seeing that there are lumps are inside build/convert of the same name, so it uses them. No rebulding of the wad is needed and all the patch files are loose in the src/convert dir for use with the patch editor and to be tweaked by a gfx app... it seems a much more streamlined way of doing things, more in tune with the open directory idea of doomtools.

Am I making sense?

I hope that is all making sense and it should be noted that manually rebuiding the resource wad, as I listed absolutely dose solve this issue. Just not in a automated way.