This is the main portion of a Darklands saved game file. Every saved game consists of a pair of files: ".sav" and ".bsv". The ".sav" file contains world and character data. The ".bsv" file contains battle and dungeon data (only for the last dungeon entered and not finished). TODO: check for party strength (0-10): is it in here? Current party location. This is a copy of a string in the array at offset . Saved game label. The words at 0x43, word at 0x47 are almost constant, but seem to change just before dream. City contents seed. This appears to be a seed for a pseudo-RND used to calculate what saints/formulas/items are available in each location. Current date. Cash on hand. Global reputation. Current location. Index into the array. Wilderness locations get 0xffff. Current map coordinates. Current menu (or screen). This can be thought of as "current in-city location" for most intents and purposes. It defines which menu of options you get. See also . First word is always 0, 1, or 2. Previous menu (or screen). This is the last menu/screen before the current one; only important in "shared" locations. For example, the "listen to rumors" board is accessible from both the inn and the town square. When you leave it, you return to the correct place, but is identical in both cases. Sometimes this value is incorrect; perhaps it's only reliable in shared locations?. See also . Bank notes (in Florins). Quality of philosopher's stone. Although a word, this rarely gets higher than 30(?) in real game play. Party member walking order indices. This is the order party members walk in when walking single-file. 0-based. TODO: For some reason, changing this number while in the mines doesn't change walking order. Probably another copy of this is stored in the corresponding .bsv file, and is used for large battlefields? When do changes take effect? Party leader index. 0-based. Number of characters currently in the party. Because this includes NPCs, it can change over the course of the game. Number of characters defined. This is the number of characters which are available when "swapping characters" (in the inn), plus any NPC (like Hanse or the town leader) currently in the party. Because this includes NPCs, it can change over the course of the game. Party member character indices. Indexes into the arrays of character data for each of the five party slots. 0-based; an empty slot gets 0xffff. Party member image file. If defined, it will be one of the four 'player' images. The string also corresponds to one of the "pics\???small.pic" files. TODO: where is that image used? The byte pattern {0x00,0x30,0x00,0x30} is used for an empty slot. Party member colors. The colormap used for the player's image (in battles) for each of the five character slots. Character data. Number of events. The file offset for this depends on number of characters defined: for 4 characters, it's 0xa31; 5=0xc5b; 8=0x12d9; 9=0x1503. Event data. Events include: all quests (Raubritter and "find the X") and the expiration of saint effects. Events probably also include: endgame quests; the dream; maybe also wilderness encounters. A new game starts with 4-9 events already defined. Number of map locations. Map location data. Map location data includes cities, villages, castles, dungeons, etc; anything that can be found on the map. Most -- but not all -- of this data is a straight copy from . Some data (local reputation, cache index, destroyed sites) changes over the course of the game. The coordinates of Marienburg differ just slightly between here and ; it seems like the city was located off the edge of the map, and some executable patch moves it back on when creating a new game. This seems to be a "warning value"; there are actually 0x62 entries in . Number of current item caches. Local offset to cache data. The offsets are relative to . 0x62 offsets should suffice, as there are only 0x5c cities with inns -- but these slots are never reused (see the notes below). Inserting a 0x63rd entry would clearly be extremely bad! Only of these are actually used; remaining slots are all zero. Item caches. These are items that you "stored with the innkeeper" in cities. This structure is often corrupted. If you cache items at an inn, then remove the items, the offset remains (and stays the same). Returning to recache items sometimes causes an overflow, causing this "array" to become 64k larger, full of random memory contents! Needless to say, you probably lose your items then. A color value (RGB triplet). Color byte values range from 0x00 to 0x3f. Presumably these values are then multiplied by four to get "standard" RGB triplets. A set of colors for a person (battle mode). Color byte values range from 0x00 to 0x3f. The set of these that can be chosen from when creating characters is defined somewhere (the executable??), however the game seems to handle any values correctly. Color 1: bright shade. Color 1: dark shade. Color 2: bright shade. Color 2: medium shade. Color 2: dark shade. Color 3: bright shade. Color 3: medium shade. Color 3: dark shade. A character (and all their belongings). Age. A character's birthday is dependent on their party order (not marching order). The first character is January 1st, the second February, etc. Note that the birthday effects can be exploited (by swapping characters at inns) so that some characters never age -- although since age after initial training has no deleterious effects, there's no reason to do so. It would also cost 40-50% of your on-hand gold for each swap. Heraldic shield. Ranges from 'A' to 'O'. This corresponds to one of the "pics\shield?.pic" files. TODO: is this a null-delimited string or just a char? Item type of the currently equipped missile device. This is the first of ten bytes (scattered through this structure) which indicate what a character currently has equipped. Instead of offsets into the items array, the item type and quality are stored. The game does not seem to enforce that you must own the item. Full name. Nickname. Possibly longer or shorter, but seems to be 10 characters and a null. Item type of the currently equipped vital armor. Item type of the currently equipped leg armor. Quality of the currently equipped vital armor. Quality of the currently equipped leg armor. Item type of the currently equipped weapon. Quality of the currently equipped weapon. Quality of the currently equipped missile device. Quality of the currently equipped shield. Item type of the currently equipped shield. Current attributes. If a saint is invoked or a potion is quaffed, any resulting changes to attributes are directly reflected here; are added (for the near future) which then alter the attribute back to normal. Maximum attributes (aside from temporary increases). Skills. As with attributes, if a saint is invoked or a potion is quaffed, any resulting changes to skills are directly reflected here; are added (for the near future) which then alter the skill back to normal. Number of items carried. Knowledge of saints. The array spans 20 bytes, 160 bits. The bit offset into this array corresponds to the the offset of the saint in the array . Fewer than 160 saints are actually defined; it is unknown what happens if bits past the actual number of saints are turned on. Bit is on if saint is known Knowledge of alchemical formulae. Byte offset into the array corresponds to the offset of the type of formula (fleadust, essence'o'grace, etc) in the array . It is unknown what happens if any of the first five bits are turned on; probably nothing, though. Knowledge of q45 formula. Knowledge of q35 formula. Knowledge of q25 formula. Only of the 64 items are populated; the rest are all 0x00. An event, effect, or quest. TODO: flesh this out!!!!!!!!! TODO: describe the dynamics of this structure For RB quests, when first given this value is sort of the name of the person who gave it to you. After killing the RB the value moves to offset 0x1e, and this gets a copy of the value from 0x1a. Date the event was created. Always identical in value to . Date the event will expire. TODO: for effects, is this the date it happens instead?? For quests, this is the location where the quest was given, until the reward is taken; then it becomes -2. For other things this is usually -2, although occasionally it is 0. TODO: make this an enum. For newly given RB quests, this is the location of the RB. Once the RB is slain it becomes the location of the city to return to. For newly given RB quests, this is the location of the city that gave the quest. Once the RB quest reward is taken, this becomes 0. Common values are 0x63, 0x5f, 0x32, and 0, although others appear sporadically. Maybe this is a sort of state variable? For RB quests the sequence is: 0x8 (got quest), 0x24 (killed RB), 0x7 (got reward). This and the next five are usually, but not always, zero. For RB quests this is often 0x03; it becomes 0 after the reward is taken, and no reward can be gotten if it is not 3. Possibly (for quests, at least) this is the index of the option to 'enable' within the card? The 'ask X for your reward' option is the 3rd option on the screen... TODO: this could maybe be tested by (carefully) altering the card and the index...? Unless the logic is in the executable. This is usually the item code for an item required by a quest. Codes are a reference to offsets into the item_definitions array. However, I've seen an event appear where this is non-zero and an item quest has not just been taken. Number of items in the cache. This is probably limited to the range 0-64 (just as characters can only carry 64 items). Cached items. Code of the item(s). Codes are a reference to offsets into the item_definitions array. Quality of the item(s). Number of items.