Normally if a pk3/zip file, or presumably a folder (I haven't checked) is loaded, it will recursively go at least one folder level deeper, such as in the case of, say, a cloned git release of a mod, which works as intended.
If a PK7/7z is loaded this same way, it will parse the file and lumps, but does not actually seem to load any of the decorate, mapinfo, and so on, unless they're located in the root directory of the compressed file.
Actually not sure if this is a bug or a feature request, or if it only affects the Windows binaries, but either way it would be nice if it could be fixed.
Tested as of automated drdteam build gzdoom-x64-g3.3pre-408-g80a0d15.
ZDoom doesn't read 7z/pk7 the same way as zips/pk3s/folders
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZDoom doesn't read 7z/pk7 the same way as zips/pk3s/fold
This behavior is not 'say', like a cloned git repo, but to handle actual git repo downloads - and those are always in Zip format. The code do do the checks is inside the directory loader loop so it'd have to be copied in its entirety with the added complication that 7z directories are not available as plain data but have to be read entry by entry from the file.
I do not consider this necessary to implement.
I do not consider this necessary to implement.
Re: ZDoom doesn't read 7z/pk7 the same way as zips/pk3s/fold
I see. Thanks for the quick response and clarification.