I couldn't reply to the Editor Tricks post because its thread has been archived:
I have experience with hex-editing of EXE and saved game files in various games. Long before game designers started putting model data into easily accessible TXT files, the numbers existed as binary data tables near the ends of their EXE files. A few strings and fixed-length record clues were usually all one had to start with, but then the familiar numbers from the game would become apparent. I've even learned to recognize some floating-point numbers.
Binary data files should be consistent between different versions of the game (though there might be differences between Zeus and Poseidon). However, EXE files are extremely sensitive to version. When giving the address for the start of a binary data table in an EXE file, it's vital to note what version one is referencing.
I look forward to seeing Duck's notes on hex-editing Poseidon and its data files.
[This message has been edited by JRFisher (edited 02-03-2012 @ 03:19 AM).]
Author
Replies:
DerangedDuck Pleb
posted 03-23-12 01:19
ET (US)
1 / 1
Ah, at least 1 interested party then, good to know. Have been distracted, not paying attention to this forum. Sorry for the slow reply.
I hadn't actually thought along the lines of sharing .exe file info, though I have reverse engineered/decompiled enough of the program that I could in theory produce fixes for the 80+ bugs/issues I've identified. I might even someday produce a patch. Or not.
As far as hex editing of .map/.set/.pak/.sav files, I'm actually not sure what to share and a lot of my notes are a mess, but I'll try to post some stuff out when I have more time in a day or 2.
ADDED 03-24:
The .set file is entirely uncompressed data and has a rigid format: Header (20 bytes) Basic Episode Data (fake) (20 blocks of 356 bytes each) Real Episode Data (14 blocks of 2032 bytes each) Stuff (148 bytes) Episode Mythology Data (14 blocks of 300 bytes each) Event Data (offset 0x9c00) (14 blocks of 18600 bytes) Stuff (225 bytes?) (offset 0x49549) Apparently unused .map data ( 500000 bytes ) might be revert data for editor or something. Or might just be left over from when map was in the .set file. (offset 0xc3669) # events for each episode (offset 0xc3694 to 0xcb263) 10 different blocks of data, all apparently never used (offset 0xcb264) (Parent city favor for episode) 10 x 4 bytes (offset 0xcc38e) colony goals (offset 0xccabe) parent city goals
.sav and .map files are not of fixed length. However, the 1st 8(save) or 12(map) bytes are version information, and the next 6000 bytes are a manifest of sorts. Each element in the manifest is 20 bytes: 4 bytes 01=compressed 00=not compressed 4 bytes memory address data came from 4 bytes sizeMult1 4 bytes sizeMult2 4 bytes ?(not important)
Modifying the manifest does nothing, the game just checks the file's version number and then assumes that it is in the correct format for that version. If the file turns out to not be in the correct format because some numbskull was playing around with a hex editor, the game will helpfully crash and burn.
If all the blocks were uncompressed, the .sav and .map files would have a fixed length--A very large fixed length, about 4MB for each save, rather than the 300-500K it usually is.
For uncompressed data, the actual size of the data in the file would be (sizeMult1 x sizeMult2)
Compressed data blocks consist of: 4 bytes for the of the block 2 bytes with the values: 00 06 (size - 2) bytes of data
does not include itself, but does include the "00 06", So total number of bytes used would be +4.
99 30 00 00 00 06 would indicate a compressed block of = 0x3099 (12441) bytes.
One exception to this is that a value of "00 00 00 80" means that the compressed data block is in fact uncompressed, because no useful compression could be applied. If I recall correctly, this means that the next 51984 bytes will be considered the data for that block. If the block is supposed to be smaller, the rest of the data in the file will be unused. I'm not sure what happens if the block is supposed to be larger, but I recall having trouble inserting an uncompressed terrain block (which is 200K) into a map file.
An example of the use of this is to locate the Real Episode data in a sav file. We know it is 2032 bytes, so we search for or "f0 07 00 00", which is hexidecimal for 2032(7f0), written in little-endian order(used by programs written for intel chips). We come up with:
00000000 98189000 f0070000 01000000 00000000
This shows that it is the 10th entry in the manifest. Adding up the values of the sizes of things, we'd find that we need to wander down 6009 bytes, then a compressed block, 8 bytes, another compressed block, then 144 bytes, which would bring us to the data for the current episode.
Basic Episode data (fake): note that this is a copy of part of Real Episode Data This appears to be unused. Changing it will do nothing.
4 byte : 01: episode exists 4 bytes 00's 4 bytes FF's for player created adventures. Has value for included adventures, possibly sound/text lookup index? 4 bytes episode # 4 bytes FF's 4 bytes possibly another sound/text lookup index? 60 bytes 00's 4 bytes = next episode 03=victory, 02=parent, 01=colony, 00=nothing 4 bytes = type of this episode 00=start 02=parent 01=colony 264 bytes = 00, then Ascii name of scenario
Real Episode data : Notes: - a single such block exists in .sav, and .map files - a .set file has 10 for parent episodes and 4 for colonies - not all bytes will be used in a particular file type for example, game points would be ignored if not in a .map file - some bytes would only have meaning for the 1st episode, whose value would apply to all episodes
Monster invasion: 00=monster in city 01=monster unleashed 02=monter invades
Request: 00 general request 01 under threat of invasion 02 attacking rival 03 festival 04 construction 05 famine 06 financial woes 07 city menaced by monster 08 ? 09 player attack rival <yes, this is a "request" type event...>
City status change: 00 trade suspended (they're provoked) 01 trade resumes 02 trade shuts down (no given reason) 03 trade opens up 04 tribute suspended 05 tribute resumed 06 rebellion 07 rebellion over? 08 colony becomes rebellious 09 rival becomes ally 0a ally becomes rival 0b city becomes vassal 0c ally becomes rival 0d god disaster 0e military buildup 0f military decline 10 econ increase 11 economic decline 12 city becomes active 13 city becomes inactive 14 city appears 15 city disappear 16 god disaster over 17 rebellion over 18 city conquered
* Appears to be unused A Event normally created automatically by computer
HEADER: (00)(01) event ID# 00-?? (02) event type (03) month of event occurance
ITEM (04)(05) actual item chosen from the 3 items (item is god, commodity,...) (06)(07) first possible item (08)(09) second possible item (0A)(0B) third possible item
QUANTITY (0C)(0D)(0E)(0F)(10)(11)(12)(13) RANGE/VC QUANTITY of goods, invaders, etc.
(14)(15)(16)(17)(18)(19)(1A)(1B) RANGE/VC TIME till begin. Years from episode start for scheduled events, months from trigger for triggered events.
(1C)(1D)(1E)(1F)(20)(21)(22)(23) RANGE/VC: CITY (request) or marker(invasion)
TRIGGER (24)(25) FF FF normal or XX 00 : trigger this eventID on SUCCESS (26)(27) FF FF normal : trigger this eventID on REFUSAL
OCCURANCE (28)(29) (2A)(2B)
XX .. .. .. 0x000000XX 1:you weak 2:CPU created? 4:oracle 8:oracle did | 1:triggered only 2:recurring 4:recur event complete, mil event complete 8:is triggered .. XX .. .. 0x0000XX00 4:raiding party returning 2:involves hero(?) 1:ares came along(?)| 1:finish up at end of scenario .. .. XX .. 0x00XX0000 | 1:visible on map? 2:do at end of episode 4:set when close to arrival for invasion? 8:won? .. .. .. XX 0xXX000000
(2C)(2D) # months warning before event (2E)(2F) months used/left/whatever
(30)(31) Event status from 00 to 0a
(32) flag:waiting for dialog response? (33) flag:request placed on request list?
(34)(35) Triggering event ID#? FF FF (36) godID, or monsterSlot, or HeroSlot # warships for naval invasion (37) (37 gets 36 from trigger event)
This can be set for regular invaders too, but as far as I can tell, they ignore it, although the unit data has a field that receives the value, so they ought to do something :P.
(52)(53) FF FF Triggered event on LATE (54)(55) FF FF Triggered on responded but LOST
(56) 01=monster/attacker will destroy city 02=will conquer city (57) 01=1st warning given. 11=final warning before arrival given? 04 = can't invade (announce invasion?) till this flag is set...
(58)(59)(5A)(5B)(5C)(5D)(5E)(5F) RANGE/VC: city that launched invasion.
(60) SUBTYPE of event (which city status change, which kind of request, etc., which god sent us on quest, see above for options) (61)