SnakeBite icon indicating copy to clipboard operation
SnakeBite copied to clipboard

fpkd (and possibly other archives) file order

Open TinManTex opened this issue 3 years ago • 1 comments

Would need exe spelunking.

Comment from SortFpksFiles (the current workaround): //tex fpkds seem to require a specific order to their files. //Don't know whether this is also an issue for fpks, or other archives (are there any other archives with multiple filetypes?)

//Reproduction: Extract an unmodified fpkd (such as chunk0_dat\Assets\tpp\pack\mission2\init\init.fpkd, as it's loaded automatically and early) DEBUGNOW redo this test to confirm issue again //change the order of the file entries in the .fpkd.xml so that they're not grouped by extension //repack and the load the game //game will fail to load //as the issue doesn't seem to happen when there are no fox2s in fpkd VERIFY //it might simply be that the first entries must be fox2s?

//Furthermore, entries are also sorted alphanumeric ordinal - ascending for fpk, descending for fpkd for some reason, but (lua at the very least) loaded in alpha ascending

//Reproduction: have two lua files, one referencing the other (or rather a field of the other ie somescript.somevar) directly in its load time script (ie not hidden in a function) - (this also suggests that lua files are just loaded to fpkd order rather than having a load order specified anywhere) DEBUGNOW actually test lol //Or just hook luaL_loadbuffer and see the load order for a vanilla file.

//GOTCHA: This mean there's a currently unresolved (unresolvable?) problem of mixing in hashed entries as you can't know their position. Though that's only an issue for GZ fpks? (and s/makebite isn't for gz) //GOTCHA: while archiveExtensions is a good effort at reconstructing order by examining exising files, it doesn't have full coverage //as some extensions can only be reconsructed in unconnected groups, so the placement of those in the overall order are just at the whim of whatever the topo algo put them at

//Some lua scripts reference some extensions: RegisterExtensionInfo, RegisterPackageExtensionInfo //however only some of the extensions match observed fpk file order.

//The only real solution here is if the fox engine fpk loader has an apparent reversable load order.

//As it currently stands (2021-02-20) it (via BuildFpk) repacks all vanilla tpp,mgo,sdd fpk files (provided that fpk.References are coppied) to binary identical files. (except for fpkds with lua since gzslib doesnt reencrypt).

So currently at a 'it's working ok for now', but would be good to get some definitive answers at some point.

TinManTex avatar Mar 10 '23 22:03 TinManTex

another note: fox2 goes first, deps from fox2 go after

this is just an observation without conclusion

unknown321 avatar Apr 26 '25 02:04 unknown321