illwieckz
commented
6 years ago Note: I discovered a strange bug around the pk3dir support, but I don't know if it's related to the code introduced or just triggered by some new path that was never taken before.
My textures/radiant/notex shader is stored in a tex-common_src.pk3dir or tex-common_src.pk3 set. This textures/radiant/notex shader is not a physical path but a shader path, the real picture path is different (textures/common_src/notex.png, and this shader path is only provided to workaround the GtkRadiant inability to provide this required texture itself.
- When I open a blank map, GtkRadiant is able to find the
textures/radiant/notexpath even if it's only provided by a pk3dir. - When I open an existing map, GtkRadiant complains because failing to load the
textures/radiant/notexpath when this path is only provided by a pk3dir. - When I open an existing map, GtkRadiant is able to find the
textures/radiant/notexpath if it's provided by a pk3.
ensiform
This PR adds pk3dir support, in a simple way: each pk3dir is loaded as a VFS.
This PR also extends the pk3 VFS to support dpk/dpkdir for Dæmon engine/Unvanquished game, and I also added pk4/pk4dir because it was cheap.
I haven't yet found a way to not load found pk4 and dpk if VFS is pk3 only (or other combination), so the current code loads all pk3/pk4/dpk found if game profile uses pk3 VFS. It's probably not an issue though.
DPK vfs is the versionned and dependency based VFS used by the Dæmon engine (used by Unvanquished for example, see DPK Format), this dpk support introduced by this PR does not handle versionning (it just loads all dpk/dpkdir available as if it was pk3), it does not prevent mapping and compiling, people just have to take care of concurrent paths like pk3 needs, and people are used to, so there is no urge to implement this versionning and dependency mechanism and it's considered out of topic regarding this PR.
The same mechanism was added to q3map2: pk3dir, dpk and dpkdir support added. I did not added pk4/pk4dir support since there is not pk4 based games known with map compilation needs. The pk3dir/dpk/dpkdir code is copypasted straight from NetRadiant tree, and also lacks versionning/dependency mechanism for dpk use case (it's true on NetRadiant side for q3map2 too).
I initially derivated my code from a code by @neumond, but I was not happy with this first implementation, or its latest state: this first implementation was just loading the pk3dir for the current map, and needed everything else (like texture set) being there as pk3. So I removed the per map pk3dir loading mechanism and added the “load every pk3dir found” mechanism instead. At the end, I discovered that all the code by @neumond was entirely removed, without any trace from it.