Hash-based resource replacement

[Nash]

Inspired by Graf Zahl's initial thoughts on the matter.

The jist of this suggestion is a way to do lump replacement based on the hash of the "to-be-replaced" lump.

What's different from Graf's idea and what's being proposed here is that it would work for any lump, not just /graphics/ lumps. I'm not sure how it would work from a technical standpoint - would it work similar to the filter folders (so now we'd have "hash folders")?

Besides the use case Graf presented in that other post (mod-specific TITLEPIC replacements), one mod that could immediately benefit from this is NightFright's Brightmaps Plus pack - currently, there are separate downloads depending on whether the user uses vanilla sprites or the sprite fix sprites. With hash-based replacement, the entirety of Brightmaps Plus can be a single file.

[Graf Zahl]

The main problem here is performance. To replace any lump based on its hash you have to read it. This can take quite a bit of time when loading lots of things.

[Rachael]

Maybe what might help with performance issues is if the replacement requires a title - i.e. TITLEMAP.replacement.2EC59756DA<whatever>.png

[Graf Zahl]

That was pretty much my original suggestion about this.

[_mental_]

I would add a special lump that does files remapping. It will specify source name+size+MD5 and target's full path.

[Graf Zahl]

Now that's precisely what I'd like to avoid.

[Tormentor667]

The main problem here is performance. To replace any lump based on its hash you have to read it. This can take quite a bit of time when loading lots of things.

Would this happen at startup?

[Rachael]

Yeah, that's when resources are loaded so that's when it would make the most sense to do the replacements.

[Tormentor667]

I wonder if the filename is something like “orIginallumpname.replacementname.md5hash”, wouldn’t it be enough if the engine just checks the original name hash?

[JPL]

Not exactly the same use case that's being discussed here, but if the ability to get hashes / checksums for non-map assets, eg textures, were exposed to ZScript it would let me do some compatibility fixes for WadSmoosh. (specifically, fixing custom skies that are defined via the TEXTUREx lump and can't be otherwise detected)