Ground Control 2: Operation Exodus SDF files
Ground Control 2: Operation Exodus SDF files
Help extract SDF files in game Ground Control 2: Operation Exodus
You do not have the required permissions to view the files attached to this post.
-
friendsofwatto
- VVIP member
- Posts: 535
- Joined: Wed Jun 30, 2004 3:01 pm
- Location: Australia
- Been thanked: 13 times
- Contact:
OK I have attached a Game Extractor (Full Version) plugin for these archives. Because there is some odd formatting in the archives, I cannot add support for this archive to Game Extractor (Basic Version).
If you have the full version, unzip into your plugins/ directory (make the directory if it doesn't already exist).
WATTO
watto@watto.org
http://www.watto.org
If you have the full version, unzip into your plugins/ directory (make the directory if it doesn't already exist).
WATTO
watto@watto.org
http://www.watto.org
You do not have the required permissions to view the files attached to this post.
Game Extractor - Read and write thousands of game archives!
-
Mr.Mouse
- Site Admin
- Posts: 4051
- Joined: Wed Jan 15, 2003 6:45 pm
- Location: Dungeons of Doom
- Has thanked: 421 times
- Been thanked: 575 times
- Contact:
Watto, I think it is impossible to get a correct format from the one file.
Could we have more examples?
It seems that it start with RYS+version number(byte).
Then the files. That's where to strange things happen.
Each file is preceded by a uint32{4}, in case of the first file possibly representing an pointer (relative to the offset of this variable) to the start of the next file when the 8th bit of the 4th byte of the uint32 is NOT set (size would then be this pointer - 4).
The second file starts with a (relative) pointer, but now that same 8th bit IS set. Consequently, the pointer now represents the exact size of the file (calculate only the first three bytes of the pointer).
That would also mean the files each start at the
That's something different than what your plugin is doing, but may still prove the actual format.
Could we have more examples?
It seems that it start with RYS+version number(byte).
Then the files. That's where to strange things happen.
Each file is preceded by a uint32{4}, in case of the first file possibly representing an pointer (relative to the offset of this variable) to the start of the next file when the 8th bit of the 4th byte of the uint32 is NOT set (size would then be this pointer - 4).
The second file starts with a (relative) pointer, but now that same 8th bit IS set. Consequently, the pointer now represents the exact size of the file (calculate only the first three bytes of the pointer).
That would also mean the files each start at the
Code: Select all
5D00 0080 -
friendsofwatto
- VVIP member
- Posts: 535
- Joined: Wed Jun 30, 2004 3:01 pm
- Location: Australia
- Been thanked: 13 times
- Contact:
OK I understand that Mr Mouse - sometimes when I do have more files to work with I need to change the specs alittle. So if we could get some more files for comparison, we will hopefully be able to come up with something more solid.
WATTO
watto@watto.org
http://www.watto.org
WATTO
watto@watto.org
http://www.watto.org
Game Extractor - Read and write thousands of game archives!
-
Mr.Mouse
- Site Admin
- Posts: 4051
- Joined: Wed Jan 15, 2003 6:45 pm
- Location: Dungeons of Doom
- Has thanked: 421 times
- Been thanked: 575 times
- Contact:
Well, technically, if you need to change the specs, you are not supporting the archive. So, that can be misleading.friendsofwatto wrote:OK I understand that Mr Mouse - sometimes when I do have more files to work with I need to change the specs alittle. So if we could get some more files for comparison, we will hopefully be able to come up with something more solid.
WATTO
watto@watto.org
http://www.watto.org
Anyway, I have been able to look at larger files and it appears to be a different story. A 250 MB file also had only two "files". One huge, and the second much smaller and at the back. This leads me to suspect that the second is actually a compressed/encrypted tail of some kind, with the first chunk the actual compressed/encrypted file data.