This is a breakdown of the fields and their purposes of the *.ToEEPC file. It is a work in progress. As I figure more out, I will add to this. Please feel free to post, share, and improve upon it. If modifications are made to the TCE engine it could make character editing easier for some. This is from my study of the ToEEPC files. Some of these blocks can be found in the *.tfaf files (save game files) also. I haven’t checked them out yet to compare. Please ignore any grammatical or spelling errors. << Beginning of Character File >> 0900 0000 == Character sheet beginning block -- followed by 1 double-word Purpose Signifies this is the Player-Generated character – The pre-generated characters have a 0100 0000 here instead Purpose of value is unknown 0200 0000 == variable length double-word bit data block. It uses a 0000 0000 “end-field†double-word to indicate the end of the field – in this case it is immediately followed by the end-field double-word, which I will refer to as the EFDW. End-field words will be EFW and end-field bytes will be EFB. There are no end-field bits, thankfully. Note: This field is, always, a group of double-words with a 0000 0000 double-word used to indicate the end of the field. Values are placed in between these two double-words and are double-word in length and are byte fields. It is used to indicate # and sequence of the data from previous block’s data. Bytes are always read from right to left. Example: abcd efgh ijkl mnop shows 2 double-words of data. It will be read as opmn klij ghef cdab. Do not convert this to decimal. Just read the byte values from right to left. If no sequence is required, it will just show the # of data with 1’s filling right to left. So 1 data field means a bit value of 0001 for the “b†byte, and 2 would be 0011 with 3 being 0111 and 4 as 1111. At 5 move to the “a†byte and so on. xxxx yyyy == 4 double-word length field – has a 01 end-field byte (EFB) (byte after the last double-word to indicate the end of the block. Purpose unknown xxxx 0000 == Character name beginning block -- xxxx is the # of characters in the name -- each character is one byte in size ( the word Rogue would appear as 526F 6775 65) xxxx 0000 == First of 2 instances of character portrait -- refer to portrait.mes for portrait -- value points to the big picture xx00 0000 == sex -- 00 = Female 01 = Male xx00 0000 == First of 2 instances of class – values begin 07 for Barb up to 11 for Wiz in alphabetical order xx00 0000 == race – Values – 00 to 07 – Human, Dwarf, Elf, Gnome, Half-elf, Half-orc, Halfling, Monster in that order xx00 0000 == First of 2 instances of alignment – Values – 00 – N ; 01 – LN ; 02 – CN ; 04 – NG ; 05 – LG ; 06 – CG ; 08 – NE ; 09 – LE ; 0A – CE xx00 0000 == only instances of unknown value 01 == The end-field byte (EFB) that I mentioned above. 7700 0000 == Unknown block beginning signifier – Followed by 3 double-words that appear to be in byte or word values Purpose of unknown 0200 0000 == Unknown double-word bit block – followed by the 0000 0000 EFDW Purpose unknown xxxx yyyy == unknown double-word of data that appears to be in byte or word form Purpose unknown 0200 0000 == Unknown double-word bit block – followed by the 0000 0000 EFDW Purpose unknown xxxx yyyy == Unknown double-word block set -- 4 double-words long, that appears to be in byte or word form Purpose unknown 0D00 0000 == Unknown byte block header -- followed 11 bytes. The last 4 bytes seem to always be 0000 and is probably the EFW Purpose unknown 0200 0000 == Unknown double-word bit block – followed by the 0000 0000 EFDW. Purpose unknown xxxx yyyy == Unknown variable-length double-word block – It seems to have some preset values; but, not all characters will have same ones. They appear to be sequenced. Purpose and values unknown mostly – Near the end of the field you will find the HP double-word. It is usually within 3 double-words from the EFB. 01 == EFB 0400 0000 xxxx 0000 yyyy 0000 == Variable length double-word block begins -- xxxx is value for # of double-words of the block -- yyyy is on offset indicator – (Note: 0400 0000 always signals a variable length double-word block. Values will be in double-word data form) (Warning: if you add feats after initial generation of character, do not change this section. It is best to leave it alone until it is better understood. They game seems to place these in initially in the sequence you see them in when you View the character and look at the feats sub-window. Except for special class skills that don't get listed like the Rogue's sneak attack or the Clerics Turning and Positive/Negative Energy) Purpose -- This block indicates preset feats or effects based on choices made at startup like race, class and deity/domain Suspected values: 5EA1 4D00 -- Human simple weapon proficiency 064A 0000 -- Elf simple weapon proficiency 6EF9 BC04 -- 2 weapon fighting proficiency 85B6 6704 -- 2 weapon defense 8242 8804 and 2CC6 FE02 related to Negotiator and Scribe Scroll A538 100F related to Improved Initiative 0200 0000 == Double-word bit block – values for this field are not sequential, so it only indicates the # of fields above – has the EFDW xxxx yyyy == Unknown double-word block – values seen are 0000 0000 and FFFF FFFF only so far. If you have the FFFF FFFF, then you will have an extra double-word as the last double-word at the end of the file. 01 == EFB 0400 0000 xxxx 0000 yyyy 0000 == Variable length double-word block begins -- Purpose of this field seems to be related to feats selected during generation of character; but, only those that affect things -- Combat reflexes will never appear here. It has 2 or more subsections indicated by starting with 0100 0000 -- first set seems to be for physical affecting feats like Improved Init or 2 weapon fighting -- second set seems to be for magical affecting sections -- 0200 0000 == Double-word bit block – Purpose – indicate # of above fields and sequence if necessary -- values appear to indicate the above field is not sequential. 01 == EFB 0400 0000 0600 0000 yyyy 0000 == Variable length double-word block begins – yyyy is offset Purpose -- this one is for stats -- sequence is Str, Dex, Con, Int, Wis, Chr -- values will be in xxxx 0000 form 0200 0000 == Double-word bit block – Purpose – indicate # of above fields and sequence if necessary -- has a 3F00 0000 bit field double-word to indicate the # of Values above and the EFDW 01 == EFB 0400 0000 0100 0000 yyyy 0000 == Variable length double-word block begins – of only 1 length Purpose – Second and final instance of class 0200 0000 == Double-word bit block – has 0100 0000 and the EFDW xxxx yyyy == Block of double-word values for specific purposes. Purpose -- char description fields -- 1st double-word -- height 2nd double-word -- wt 3rd double-word -- alignment 4th double-word – deity Clerics will have 3 more double-word fields of which the first 2 indicate Domains and the 3rd indicates positive or negative energy (It may be possible to give yourself more Domains here. Not sure.) 01 == EFB <<Spell section for spellcasters begins -- only there if character has spells>> 2000 0000 xxxx 0000 yyyy 0000 == variable length field for spells -- xxxx indicates the # of spells known -- yyyy is the offset -- each spell field is broken down into 8 double word lengths -- may have the 0100 0000 fields to indicate subsections of single words and specific purposes -- non-spellcasters will not have this field or those without spells yet Breakdown of fields First field is the spell -- refer to SpellList.mes for values of spells (Note: spells are listed based on how they are listed in your spell book -- new spells are added at the end (spells may be separated into level groups) 2nd field -- aaaa 0000 -- indicates type of caster -- values run from 8700 for barbarian through 9000 indicates sorcerer 3rd field is spell level -- 4th field – unknown 5th field – unknown 6th field – unknown 7th field – unknown 8th field – unknown 0200 0000 == Double-word bit block – It has the EFDW Purpose – bit count showing the # of spells available 4 spells is 0F00 0000 – it is not sequence oriented. 01 == EFB <<Spell section for spellcasters ends -- only there if has spells>> 0400 0000 xxxx 0000 yyyy 0000 == Variable length double-word block begins -- feats taken -- refer to feats.mes for values Purpose -- feats taken -- This is the ONLY field you need to modify when adding feats -- the game will show them in the character screen the next time you look it on New Game -- View – Feats -- any effects will take place the next time you start the game with that character. 0200 0000 == Double-word bit block – It has the EFDW Purpose – first double-word indicates the# and placement of feats. As they do not need to be in order the value should match the # of feats from xxxx above. However, the values are in bit form so one feat equals 0100 and 2 feats are 0300 and 3 feats are 0700 – this indicates a possible max of 32 feats in the game xxxx 0000 == second and final instance of character portrait 01 == EFB 0400 0000 xxxx 0000 yyyy 0000 == Variable length double-word block begins -- skills -- refer to skills.mes for values (Note: for a CC skill to be listed here it must have a value of at least 2 -- class skills will always be an even # by a factor of 2 for each point you want in it. Level 1 characters can have a max of 4 points in any field -- Class skill which is a value of 8 -- CC skills will have a max of 4.) Skills are listed in this order and must be given values in this order -- Appraise, Bluff, Concentration, Diplomacy, Disable Device, Gather Information, Heal, Hide, Intimidate, Listen, Move Silently, Open Locks, Sleight of Hand, Search, Sense Motive, Spellcraft, Spot, Tumble, Use Magic, Survival, Perform 0200 0000 == Double-word bit block – It has the EFDW Purpose unknown –. The right-most one is for Appraise, the second one from the right for Bluff and so on. abcd 0000 == Hair style and color and head/body form. Here is the breakdown in “nibble†form ab cd. Reversing gets cd ba . c is 0, d is the nibble for hair color (refer to hair.mes for color listing), b is the hair style (16 potential styles based on 8 styles for each sex – may be able to use a hair style for an opposite sex here if you like that one, like if you wanted a bald headed woman), a is head/body form (Sequence follows racial listing from above with the Females first and then followed by the Males – so HUF – human female – is 0000 in bit form and HUM – human male – is 1000 in bit form) 01 == EFB xxxx 0000 == Character name beginning block (second and final time) -- xxxx is the # of characters in the name -- each character is one byte in size ( the word Rogue would appear as 526F 6775 65) -- exactly the same as above 00 -- EFB xxxx 0000 == pc voice -- refer to pcvoice.mes for values xxxx 0000 == occasional extra field – Purpose unknown << End of Character File >> Basic Tutorial on Hex Editing The values you see on the left side of the Hex Editor are in Hexadecimal or “Hex†values. There are 4 types you need to worry about on the left side of the screen and that is the ONLY place you should be making changes. The right side of the screen is for visual purposes only. Mostly helpful in identifying character strings like your character’s name, or other text. These types are the “nibble’, “byteâ€, “word†and “double-wordâ€. A “nibble†is half a byte, or one character. A “byte†is the basic unit. It is a pair of the characters you see. When you click in the left side, it will always set the cursor at the beginning a byte, never a nibble. The basic structure is shown in pairs of bytes also knows as a “wordâ€. These are the groups of 4 characters you always see with spaces in between and usually alternating colors for easy identification. It is recommended that you adjust the width of your editor’s window so that you have an even number of columns. It makes it easier to count the double-words. However, the editor shows “visual words†not “actual wordsâ€. Some values in the file are only a byte in size, like the 01 used to denote the ending of the 0200 0000 block. So, often, the actual word is split on the screen as 00xx xx00. The xxxx is the actual word value. The “double-word†is 2 words and is usually denoted like this: 0000 0000 The left-most column is called the offset. It is in hex values and shows the numerical value of the starting byte in that row. It is mainly there to show you where in the file you are and to find the same place in another file so you can compare values. Note: Remember, on word and double-word values, you must always reverse each of the word byte values. 4F01 on the left side of the Hex Editor will be reversed to 014F for its actual Hex value to produce a value of 335 in decimal value. You can then compare this value to the one in your *.mes or *.tab file. It is usually the numerical value on the leftmost column. Here is an example: You don’t like your PC’s voice. Say you want to go from the Gruff Warrior voice to the Happy Trickster. Open the PCVoice.mes file with Phalzyr’s ProtoEd or WordPad. Find the voice file you want to change it to. In this case the Gruff Warrior voice is 9 and the Happy Trickster is 17. The second to last double-word in the file is your PC’s voice file. 9 Decimal becomes 09 Hex byte and 0009 in a Hex word. Now reverse the values to get 0900. You should see that the second to last double-word has a value of 0900 0000. That shows you have the right spot. 17 Decimal becomes 11 Hex byte and 0011 Hex word. Reversing the values becomes 1100. I hope this helps a lot of you out there.
First correction: Concerning Hair Color, style and body form. abcd 0000 == Hair style and color and head/body form. Here is the breakdown in “nibble†form ab cd. Reversing gets cd ba . c is 0, d is the nibble for hair color (refer to hair.mes for color listing), b is the hair style (16 potential styles based on 8 styles for each sex – may be able to use a hair style for an opposite sex here if you like that one, like if you wanted a bald headed woman), a is head/body form (Sequence follows racial listing from above with the Females first and then followed by the Males – so HUF – human female – is 0000 in bit form and HUM – human male – is 1000 in bit form) Should now read: abcd 0000 == Hair style and color and head/body form. Here is the breakdown in “nibble†form ab cd. Reversing gets cd ba . c is 0, put d and a together to get ba -- now break it into 3 parts by bits 00 xxx yyy- xxx is for hair and yyy is for style (each has only 8 options possible), a is head/body form (Sequence follows racial listing from above with the Females first and then followed by the Males – so HUF – human female – is 0000 in bit form and HUM – human male – is 1000 in bit form).
D'oh! This is what I get on 4-5 hours sleep for the last few days. Ignore my last post. I made a mistake in it. So let's try this again. Correction: abcd 0000 == Hair style and color and head/body form. Here is the breakdown in “nibble†form ab cd. Reversing gets cd ba . c is 0, d is the nibble for hair color (refer to hair.mes for color listing), b is the hair style (16 potential styles based on 8 styles for each sex – may be able to use a hair style for an opposite sex here if you like that one, like if you wanted a bald headed woman), a is head/body form (Sequence follows racial listing from above with the Females first and then followed by the Males – so HUF – human female – is 0000 in bit form and HUM – human male – is 1000 in bit form) Should now read: abcd 0000 == Hair style and color and head/body form. Here is the breakdown in “nibble†form ab cd. Reversing gets cd ba . c is 0, put d and b together to get db -- now break it into 3 parts by bits 00 xxx yyy- xxx is for hair color and yyy is for hair style (each has only 8 options possible), a is head/body form (Sequence follows racial listing from above with the Females first and then followed by the Males – so HUF – human female – is 0000 in bit form and HUM – human male – is 1000 in bit form). Note: In my previous post, I said to put the d and the a together when I meant to say put the d and the b together. a is still the body type indicator. Update: I suspect that extra field that occasionally pops up at the end of the file may be related to an extra starting weapon based on if you took any of the Exotic Weapon, Weapon Focus, Weapon Finesse, or Weapon Specialization Feats. However, I have not tested this yet to prove it. I remember seeing a file that only listed those feats and not the rest, but now I don't remember its name or location and can't seem to find it again. (Of course!) :> I will be posting this in its latest corrected version on Sorceror's Place today, also.
Alrighty, let me add something to the post. Unfortunately, I don't have time personally to break down ToEEPCs right now, but I can give you some hints to direct you to the right path. Here are some facts for your consideration: 1) .ToEEPC is an instance of a modified object file format that is used by the game for MOB files as well. Therefore, ToEEPCs and MOBs are very similar. IN FACT, all ToEEPC files contain an embedded MOB file. 2) In fact, ToEEPC consists of two parts: 1) the player object header (that contains the unique identifier of the player AS a player object, player's name, and some extra stuff), 2) the player mobile object, in fact - the embedded mobile object (MOB) file of type 0x0D (obj_t_pc, for player characters) that contains the player's properties (skills, feats, strength, dexterity, spell list, and whatnot). 3) The mobile object (MOB) part always start with 77 00 00 00 01 00. The first part (uint 0x77) is the version ID of the object file format. The second part (ushort 0x01) is the flag that specifies that the following data is a data for the mobile object. Other values are not possible in ToEE, but in Arcanum there could have been another value as well - ushort 0xFFFF - which used to mean an object prototype (as opposed to object instances). Anyway, nevermind. 4) Those long things that start with ulong 0x02 and end with a 16-byte data block are globally unique identifiers. They are very important and they ensure the unique position of an object in the memory. They are also unique names that the game uses to address mobile objects. 5) I can't give you a full MOB file format breakdown at the moment, but I'd like to point one thing out for you: it's a variable-size format, and therefore, it has a lot of means to control its elements (what is where). The basic idea of a MOB file is to provide a stream of properties in such a way that it corresponds to an internal structure of a game object in memory. Basically, it's a stream of properties, the total size of which can easily be calculated by the engine since there is an explicit declaration of existence/absence and size of every property that is ever possible to have occured in the data stream. 6) I'd say that those 0x01 bytes that you count as EFBs (or whatever you call them - end of the field, or something), are treated incorrectly. It's more of a beginning of a field. It usually begins a complicated structure field (such as a sizeable array (SAR), an array of GUIDs, or something like that). Experimentally it turns out that it's always 0x01 in the original files but it has a certain purpose (I'll list it below). BUT -- it IS in the beginning of a field, not in the end of it. FOR EXAMPLE: When describing a sizeable array of character attributes (strength, dexterity, etc.), you used the following form: 0400 0000 0600 0000 yyyy .... Note that it's for the most part not correct to write it in that way. On the other hand, it should be like this (SAR = sizeable array): Code: 01 // number of SAR structures to follow, here = 1 04000000 // size of an individual SAR element, here = 0x04 (32-bit int) 06000000 // number of individual elements in a SAR, here = 6, one for // each property (str, dex, con, int, wis, cha) yyyy0000 // SARC index. Don't ask me to disclose what this is, I won't // since there are people who don't want me to disclose it. // But it's NOT any offset. Let me just say it's a memory saver // type of thing. You can leave it as 00000000, too, by the way, // and you shouldn't experience much of a difference. ToEEWB // has saved this as 00000000 for a long time until the way to // write reliable SARC indices was found. <DATA FOLLOWS, exactly six blocks, 4 bytes each (int32's).> xx000000 // The size of the post-structure element count, // in 32-bit blocks <POST-STRUCTURE ELEMENT COUNT FOLLOWS, in the form 2^N-1, where N is the number of elements, in our case - 2^6-1 = 63 (or 0x3F). Note that the post- structure must be aligned according to the 'xx' value above. So, for example, if xx=02000000 (so that there should be two values for the post-struct), the element count should have the following structure: 3F000000 00000000 (two 32-bit blocks) I'm done with SARs (sizeable arrays). Sorry if everything above sounded complicated. I could have made a complete MOB file format breakdown for everyone's use, of course, and that could have made things a lot easier, but right now I absolutely have no time for it (and it would have taken a few days of pure work to complete it), so... The only thing I feel bad about is that if you're going to break down ToEEPCs you'll have to break down MOBs again, which means you'll have to re-invent an already known thing... Dunno, man. I'll see what I can do to help you out in the future. Also, I'd like to point out why breaking down ToEEPCs could be important to everyone here: the MOB file contained in the ToEEPC files has a lot of interesting properties that appear to be attributable to the MOB files in general, such as: feat list, spell list, etc. In fact, if we broke down that *MOB* file entirely, and I have added the support for in into ToEEWB, we'll *no longer* need PROTOS.TAB at all (!!!) Every single property will be MOBbable (even feats, spells, and skills, and whatever else). And believe me, this is an even more important conclusion (in the long run) than just breaking down ToEEPCs for the heck of it. Once again - DARN! I wish I had time to do it!!! - Agetian
Wow! That makes some things so much clearer. Thanks! Some of the things you mentioned like unique identifiers I suspected, but didn't know positively. I suspected that 01 was either some kind of header or block ender. It just seemed to me as I was working it out that it as a field or block ender fromwhat I saw. Now I know which. Some other things make a lot more sense now. I assume this is an object file in is an object-oriented program? (You can see how much of a novice I am here.) I have had some programming courses like Assembler and COBOL and other older languages but no Object Oriented programming. I begin to see the potential you mentioned but not as fully as you do. Basically, I begin to get the idea of how little I really know and have figured out . Cool! And, yeah, I would be reinventing the wheel here. Or just reverse engineering, or whatever. And considering the 4 days I spent getting this far, I can appreciate the work you would have to throw into it. I've taken this about as far as I care to for the moment; but, I'll rewrite this with what you have given me for corrections. I still plan to work on the tfaf files. I just don't know what signifies the beginning of a character in the tfaf yet. It would help if I knew that. I don't plan to break the whole thing down. I just want to understand the file better and some of its parts. Right now, however, I just want to play the game through at least once to enjoy it. Anyhues, thanks again for the information. It is very much appreciated.
D'oh! You just told me how to tell where the character begins in the tfaf didn't you. 7700 0000 0100 followed by its unique identifier? I saw that in the tfaf as I was looking at it. I double-check before I assume that though. I just thought there might be some special identifier that indicates player specific information.
.tfaf/.tfai is a saved game "archive" (sort of, it's not compressed but it stores a lot of files - that's why I call it an archive). They can be decompressed into individual files using a simple Python script (available for download somewhere on Co8, but I'm not sure where exactly -- probably in the released mods & tools thread). Hope this helps. 7700 0000 0100 works for all .MOB files. Yeah, btw, MOB file represents a single object (an instance of an abstract object class in ToEE engine) with all its properties. - Agetian
I'm just bumping this as someone was looking for it and it took me 20 minutes to find to help them out. It also gets referenced periodically in other threads I noticed ("yeah, there was a thread about that a while back..."). Anyone got any new info to add?
There *can* be a model reference, it's simply optional. If the ToEEPC file does not modify the model and uses the default one, it doesn't even store it. Instead, it reads the data from protos.tab. However, it's theoretically (and practically) possible to add a model field into a ToEEPC file that will override the protos information. - Agetian
Cool, so we can give monks Elmo's Drunken swagger? Drunken boxing is my favourite martial art style (to watch).
It would be better IMO if this info were able to be used for stopping elmo from doing that all-the-friggin'-time. He ought to only do it if wandering around Hommlett alone, i.e. not in a party.
