SRB2 Message Board  

Go Back   SRB2 Message Board > Archived > SRB2 Forum Archives > Bug Reports (2.1.X)

Thread Tools Search this Thread
Old 01-06-2019   #1
Jimita's Avatar
Default PK3 read errors

Exhibit A: lua_files.pk3
This file was generated by a tool made in C#. This archive has two files inside the Lua directory, named test1.lua and test2.lua.

Expected Behavior
The game should load the test1.lua file, and then the test2.lua file. The test1.lua file should continuously print the string "first file" into the console, and the test2.lua file should continuously print the string "second file" into the console.

Actual Behavior
Only the test2.lua file loads. The only string that is printed into the console is "second file".

The test1.lua file is simultaneously a file and the start of a folder.

Exhibit B: lua_files_winrar.pk3
This file was created by WinRAR. This archive has the same files as lua_files.pk3.

Expected Behavior
Same as lua_files.pk3.

Actual Behavior
The game refuses to start-up, and prints this message into the the log file.
ERROR: Central directory is corrupt
Exhibit C: lua_files_slade.pk3
This file is lua_files.pk3, saved by SLADE.

Expected Behavior
Same as lua_files.pk3.

Actual Behavior
The game properly loads the test1.lua file and the test2.lua file. The console will continuously print the string "first file", and then the string "second file".
Attached Files
File Type: pk3 lua_files.pk3 (329 Bytes, 108 views)
File Type: pk3 lua_files_slade.pk3 (409 Bytes, 88 views)
File Type: pk3 lua_files_winrar.pk3 (521 Bytes, 91 views)

Last edited by Jimita; 01-06-2019 at 11:59 PM.
Jimita is offline  
Old 01-13-2019   #2
Nev3r's Avatar

I'm pretty sure this is because the game expects hierarchically organized files in the central directory based on folders. It'd require some extra work regarding sprites to load files arbitrarily regardless of the central directory ordering, and It'd be slower (to what extent I don't know) than the current method.
Regarding winrar, it might be because the central dir it generates is different from what the game is expecting.
I'll post again when I get the time, however, stick to SLADE for now since it is really the only editor supported, and restrain yourself from manipulating the PK3s with other tools because the central directories get shuffled.

EDIT: if you're scripting something to generate PK3s, then make it follow SLADE'S hierarchy for now:


Last edited by Nev3r; 01-13-2019 at 08:40 AM.
Nev3r is offline  
Old 01-13-2019   #3
SteelT's Avatar

It was fixed here though... I didn't realize it could also affect sprites though. I never really tested for that scenario.
SteelT is offline  
Old 01-13-2019   #4
Nev3r's Avatar

I wasn't aware of that fix; seems to fix an ugly bug (oops, sorry about that one) related to comments and extra fields; that may have been what was causing problems for WinRAR-generated archives.

Regardless, the sorted central directory still seems to be a requirement, so you'll still get odd behaviors when not using SLADE.

I apologize for not explaining this properly before: SRB2 currently loads PK3s in a slightly similar way as WADs: instead of looking for FF_START, FF_END, it looks for the first entry called, for example, "Sprites/*", and assumes it is the folder entry, and treats it as the start marker. If found, then it looks for the next entry which DOESN'T have "Sprites/*" in its name, and treats it as the end marker. The rest of entries in between are loaded almost (if not exactly, I forget) identically to WADs.
What SLADE does is to organize those entries in a tree-like structure, just as I posted earlier. This is not a necessity in PKZip's specs, but it's required in SRB2 because of the way lumps are loaded as data. What WinRAR does, for example, is to place the latest added entry to the end of the list, instead of sorting them. This isn't a problem for SLADE, WinRAR, nor any other file explorers, but since it is unsorted, SRB2's "find start/end" method fails, and leads to entries not being loaded.

It could be possible to, instead of using markers, check every single entry individually and compare their names, without assuming folder limits. This would fix the problem for most resources, however I'm unsure about sprites; as I recall, either the markers or lump/entry ordering is a necessity of some sort due to the way they're loaded (I may be wrong, it's been a long time), and if that's the case, that bit of code would be required to be rewritten too.

EDIT2: Just in case, folders are ASSUMED to exist as entries in the PKZip central directories in SRB2; I have no clue if they're a requirement, but as far as I know, they're always generated by all of the programs I've tested.

Last edited by Nev3r; 01-13-2019 at 01:40 PM. Reason: typo
Nev3r is offline  
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT. The time now is 05:55 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.