Extrainfo and file comments were not skipped for each file while parsing the central directory, meaning the game would report it as corrupt if any of those were non-zero. This can be the case for files made using the 7Zip CLI on Windows, which store an NTFS header per entry.
The length of extrainfo was being added to the file contents offset for some reason, so after fixing the above issue, none of the lump data decompressed properly.
I haven't tested this fully, but this does allow PK3s generated using the 7Zip CLI to load into the game, although they may not function 100%. I doubt this will negatively impact SLADE-generated PK3s, since they presumably write nothing for any of those fields. There's still the issue with assumed entry order to deal with for full functionality, I think?
