Level WADs that contain maps that don't match the filename

[selliott4]

I noticed that some of the WAD files in the "levels" directory contain maps that do not match the filename. For example, "map08.wad" contains MAP01. Here's a one liner to get a list of all WAD files that contain unexpected maps:

cd levels; for w in c*.wad dm*.wad map*.wad; do l=${w%.wad}; l=${l^^}; l=${l/DM/MAP}; l=${l/C/E}; bad=$(yadex $w < /dev/null | grep "  Levels:" | grep -v $l | awk '{print $2}'); if [[ -n $bad ]]; then echo -e "$w\t$bad"; fi; done

And the output it produced:

dm31.wad   MAP01
dm32.wad   MAP01
map06.wad  MAP04
map08.wad  MAP01
map13.wad  MAP09
map14.wad  MAP03
map18.wad  MAP06
map19.wad  MAP08
map24.wad  MAP06
map32.wad  MAP01

I realize that the build handles this correctly, that the filename drives what maps ends up as in the final "freedoom*.wad" files, but it's still a bit confusing. For example, wad2image, which I'm in the process of trying to get integrated into the build, generates images based on the map name, not the filename.

 

Fortunately based on a quick experiment I did it's possible to change the map name within the WAD file with a hex editor without otherwise changing a map. In other words it's possible to edit the map names listed above by only changing one or two bytes in the containing WAD file. The build seems to still work correctly after the edit.

 

Should I submit a pull request with the map names edited to match the WAD files?

 

 

[Voros]

if it helps, yes.

[selliott4]

I've submitted pull request 481 for this.

[Voros]

This may take care of the problem atm, but maps will be changed in the future. Consider adding a filename recognition function alongside the marker name recognition, to avoid future problems.

[selliott4]

It's a bit surprising to me that levels are still going to be replaced, not just edited, which I'm guessing is how this happens. In any case I could take that one liner and make it into a script, something like "scripts/test-map-names.sh". There would then be a build target like "test-map-names" that ran it. There could be a new "test" target that then depends on "test-map-name" so additional tests could be added easily in the future. Does that sound about right?

 

I think fixing this problem in an automated manner is a harder problem than detecting it. I can just check again in a while and submit another CR if need be.