rmitton / goaldis Goto Github PK

Thanks for making this tool public. I've been trying to make it work for Jak 2 and potentially Jak 3 files but it seems like the headers are different than they are in Jak 1 and I haven't been able to make sense of it yet. Figured I would make an issue in case anyone else was also trying, or had any advice.

Instead of it being a simple 4-byte number for either the number of files in the .CGO or the length of the individual files there are many numbers before the .CGO's name none of which seem to correspond to either (the first 4-bytes seems to be common across all files though). Likewise the file names do not have reserved size but seem to just be whitespace delimited.

I've tried several of these numbers as 4-bytes and 2-bytes but nothing seems to pass through the file properly as it does in the Jak 1 files. Some output comparing the Jak 1 and 2 files.

I can't seem to figure this one out. When running dumpall.bat, I get a repeated message that MSVCR120D.dll was not found. I've tried reinstalling the MS C++ 2013 redistributable for both x86 and x64, and tried this on 2 different systems. I can't figure out what else to try to get it working. Any help would be appreciated. Thanks!

Not even with the pre-compiled .exe file or even the dumpall.bat file works on Windows XP at all. Any ideas to work around this?

I noticed the same thing you did - the game's linker seems to write out misaligned addresses sometimes!
(

I believe this misalignment actually intended: all the misaligned addresses I've seen so far have 2 in the bottom 3 bits. In GOAL, a pair is different from other objects. Instead of having a type pointer in front of the object, a pair is stored as the pointer to the pair + 2. There's a similar trick done on some integers.

If you check load-boundary-h.go, load-boundary.go, and load-boundary-data.go, it looks like there's a lot of data stored in a linked list/tree made of pairs. Linking the part that has this data structure causes lots of misaligned addresses when linking.