Okay, so I looked at the save files. Yeah, for real ;-P
Once again, a foreword: I may sound like "Mr. Obvious" - sure. But I haven't noticed any notes on these topics, and it also helps to know what things
aren't, if for no other reason that simple elimination.
The first thing I noticed is a seemingly obvious thing -- it's
one save file. One. If you recall in Fo2 or Half-Life and such, a save file consisted of data files for several locations, besides the obvious .sav file for the character stats. These location data entries, if for nothing else, could be used to store object states like
doors, safes, computer terminals and such. This possibility opens up new ideas for research: try comparing a savegame before and after cracking a safe? In the console, take note of the safe's ID tag, and see if it exists in the savegame? In the game it is also possible to relate to obejcts by their IDs (by putting "ID." before the action, player.showinventory works as well as 14.showinventory as far as I know) - so perhaps a quick reference or two to INTs suspected of being object codes? If this would prove true, a potential elimination of all alike entries (discarding of world information) could somewhat limit the search area.
Now, all that data could be saved as a really big matrix of items in the game, sure... it wouldn't make much sense, but it's possible. But no, I'm not so sure.
One way to determine if this is even remotely possible is to check the
size of the file before and after discovering a new location. If it suddenly got a whopping increase - yup, it's storing locations.
Another (related? maybe) thing that got me interested is this repeating pattern of HEX, that looks like a marker. I'm talking about the combination of 7C's, 7F's and FF's.
Sample: 7C FF FF 7F 7F FF FF 7F 7F FF FF 7F 7F 7C
Another thing that intrigues me, is the existence of the following keywords at the later stages of the savegame: Open, Close, SpecialIdle.
The "visual" structure of the savegame changes in a pre-determined order.
Also, a note on the bytes. It would appear that the save-game data is stored in little-endian (low-order byte first). Multiple values are separated by the | character (7C in hex). A quick shot would be seen with the character name - Ahleena being 7 characters long, and directly before it having 07 00 (that is 00 07 in little-endian). My characters work the same - Shodan has 06 00 7C NAME-HERE, and Miyu has 04 00 7C NAME-HERE. Better keep the little fact in mind, heheh
Somewhere in the 2/4th part of the savegame we come across "FFields", as I call them - vast fields of irradiated FF FFs. These are most likely placeholders. What they're supposed to hold is to be determined, but
placeholders have this knack of keeping space for things of pre-determined size, and sometimes order. This is a 'hot-zone' for me - keep an eye out for changes in this area, between savegames.
--------[ like, 20 mins later ]--------
Okay. So I loaded it up, and it is certain that things get dumped in a very weird way. For example, during the game, the quick-save isn't "truly saved" - it's dumped into quicksave.fos.tmp, a file which is somewhat more messy.
After that it gets put to order in the final savegame.
As I suspected, strings are saved as 7C uint_16 strlen (little-endian) 7C string 7C. So, for example "Close" would be saved as
7C 05 00 7C 43 6C 6F 73 65 7C
(which would correspond to "|..|Close|" on char display ;P)
This reinforces my theory that the | "posts" (heck, they look like posts) are in fact "posts" separating data -- that is, markers. After checking up on location names and karma stats, I have also confirmed the little-endiannes of integers in the save files - now I am SURE. There is only ONE way 0C 00 would translate into 12 (the length of "Vault Guardian").
Here's my take on decoding the b**ch: separate the whole file by 7C - anything 2B is a 16bit int, anything 4B is a 32bit int, 2B followed by some form of readable character is a string with length. Anything else is unknown data.
Also, separate the whole file by the marker provided above, and further split by 7C. Maybe that way we could make some sense out of this seemingly random data we have.
And oh, one last note -- something tells me that we're dealing with a "pack" of sorts - a structured entry list, sort of like a database file, or a resource file. What I mean by that is that we're looking at smaller "file-like" entities packed together. It may be worthwile to try and determine if the file could possibly be "de-indexed" into smaller chunks by some sort of key-like structure (directory?). If it's anywhere, it's in the file; and if so, it's in a prominent location (beginning? end - more like it?).
I also noted that the file's structure changes in a pre-determined basis - I was wrong, obviously. But I've also noticed that I was still dealing with the same "parts" of the file, only in a slightly different order. So, the idea of the file being somehow indexed could really lead to something (how otherwise would the game keep track of the contents if they're shuffled up like that?)...
I hope this helps somewhat.
--------[ like, 15 more mins after that ]--------
I took a second glance at the savegames - the two that were both close and far apart (61 seconds, 1 perk and 25? skill points apart, to be semi-exact ;P). I have noticed that some parts of the savegame did NOT change - I repeat, they did NOT. They only appear different because they have been MOVED. Where there was, say AAABBBBCCCCC, now is AAADBBBEECCCCC, and it looks different. I have noticed several new data entries (whose meaning of course eludes me ;P) that I think are (or could be) related to the perk addition. The point is, changes were made in three consecutive places - so I'm guessing ID entry, STATUS entry and CONTEXT entry. Or something. An interesting fact: I used the retinal scan algorythm to compare the two files, and the seemingly added entries, when summed up, seem to be roughly of the size that has been added to the savegame overall... we don't know WHAT it is, but we certainly can track its movement - so to speak...
(writing of an app that would track additions seems inevitable now)
Still... It would seem that my little scary thought of having layers upon layers of accurate complexity in the savefile just got some meat on its bones... :/
--------[ The end for now ;P ]--------
Oh, and some random head-up-my-ass-ness. Skip for health.
[spoiler:e6a32a0f70]Moving on (r. I had a look at that Wiki page. Word of advice: strings... are meaningless. As far as I can tell, these are just what they appear to be - written text. Instead of "Moriarty's Saloon" I could write "My very own ass" (with appropriate corrections) and it would still load the same, and I don't think it would take me to the sacred place...
Now don't get me wrong, it's a great idea to collaborate using a Wiki like that, but You're approaching this matter from the very same sacred end of things. You don't go hunting for random INTs and try to assign meaning to them...
You go hunting for patterns.
Although I am absolutely with You on this one - if it helps to hunt around like that, I'll officially take my own head out of my sacred place.
And before You kill me, chop me up and hang me to dry in one of those raider locations we all oh so very much love and adore
, ... uhh, okay. Do Your worst. I guess I didn't know what to say here anyway.
[/spoiler:e6a32a0f70]