Difference between revisions of "TreFile Template"
From SWGANH Wiki
(→TSF - '''Tre Sub File (Purpose)''') |
|||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 28: | Line 28: | ||
|identifier used for later reference | |identifier used for later reference | ||
|} | |} | ||
| − | Here is a list of the different templates at your disposal | + | Here is a list of the different templates at your disposal: |
| − | { | + | {{field types}} |
| − | + | ||
| − | + | =Note= | |
| − | + | *Snow> Exca, look at the existing templates for the colour scheme, it's already been defined for all the values you're looking at... | |
| − | + | *exca> if you're talking about this: [[Packet_Template]] my opinion is: it contains mistakes, not all the types are defined, and an uint is not an int. | |
| − | + | *snow> We can fix the mistakes, but I dont want to be changing templates to a new colour scheme 6 months into the project. | |
| − | + | *exca> also, i'd like to point out that if you edit the [[Packet_Template]] upper left table (the one with types), as stated in the PM I sent you, you'll see that the types are not templated at the moment, hence why i started mines in the first place. So if you're ok with that i'll modify the list keeping the current colors and adding the new types while modifying a bit some names that makes no direct sense: for example, the byte type does not exist in C++, uint64 does not either and long are probably 32bits (unless running a 64bits OS which i sprobably not the case for SWG). In an other way i defined my types templates using the C# types (not appropritate for C++ code as same types does not share the same values). Maybe we should statuate about the values in a more pragmatic way when describing files and protocols. Here's the info we need about each field to describe them correctly cross language: | |
| − | + | **number of bytes:1, 2, 4, 8, n or 2n (1/2/4/8/n/N ?) | |
| − | + | **little or big endianess (L/B ?) | |
| − | + | **signed or unsigned (U ?) | |
| − | + | **integer, real or string (I/R/S ?) | |
| − | + | I have yet no precise idea of a clear way to write it. Just ideas. What do you all think? | |
| − | + | *exca> I updated this page [[Binary_%26_Hex#The_data_types]], only last column needs to be filled now. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 05:57, 21 March 2007
Each file type can be described as follows:
TSF - Tre Sub File (Purpose)
| Understood at |
|
|
|
|
|
| File Type: TSF format |
|
Description here. |
Header:
| INT
|
TSF file type header id (sequence: 0x04 0x03 0x02 0x01, value: 0x01020304 = 16909060) |
| SHORT
|
items count |
Then items list, for each:
| BOOL | test flag |
| INT
|
identifier used for later reference |
Here is a list of the different templates at your disposal:
| Render | Keyword | Type Details |
|---|---|---|
| BOOL | bool | bool (1byte, 0:false, other value:true) |
| SBYTE | sbyte | sbyte (1byte, signed) |
| BYTE | byte | byte (1byte, unsigned) |
| SHORT | short | short (2bytes, signed) |
| USHORT | ushort | ushort (2bytes, unsigned) |
| INT | int | int (4bytes, signed) |
| UINT | uint | uint (4bytes, unsigned) |
| FLOAT | float | float (4bytes, signed) |
| LONG | long | long (8bytes, signed, mostly used for object ids) |
| ULONG | ulong | ulong (8bytes, unsigned, mostly used for object ids) |
| DOUBLE | double | double (8bytes, signed) |
| A_STRING | a_string | ANSI/ASCII String (2 -packets- or 4 -files- bytes size + 1byte chars, ASCII:leading0+7bits, ANSI:8bits) |
| U_STRING | u_string | Unicode String (4bytes size + 2bytes chars) |
| C_STRING | c_string | Customization String (look here for details) |
| B_STRING | b_string | Byte String (4bytes size + 1byte chars, used for session key only) |
| { } | list | LIST Component (this is a sub section repeated as a list of data. Indent Variable types with 1 space.) |
| ? | uncertain | Uncertain Values (use a single question mark ? in the name to display uncertainty in the variables understanding.) |
| ?? | unknown | Unknown Variable Name (use ?? or Unknown for the name to display that there is no clue as to what the data does.) |
XML style list tags sample: (use as many ":" as needed to multi-indent)
{{beginlist|myitems|mycount}}
:{| class="wikitable"
|}
{{endlist|myitems}}
<myitems count=mycount>
<myitems/>
Note
- Snow> Exca, look at the existing templates for the colour scheme, it's already been defined for all the values you're looking at...
- exca> if you're talking about this: Packet_Template my opinion is: it contains mistakes, not all the types are defined, and an uint is not an int.
- snow> We can fix the mistakes, but I dont want to be changing templates to a new colour scheme 6 months into the project.
- exca> also, i'd like to point out that if you edit the Packet_Template upper left table (the one with types), as stated in the PM I sent you, you'll see that the types are not templated at the moment, hence why i started mines in the first place. So if you're ok with that i'll modify the list keeping the current colors and adding the new types while modifying a bit some names that makes no direct sense: for example, the byte type does not exist in C++, uint64 does not either and long are probably 32bits (unless running a 64bits OS which i sprobably not the case for SWG). In an other way i defined my types templates using the C# types (not appropritate for C++ code as same types does not share the same values). Maybe we should statuate about the values in a more pragmatic way when describing files and protocols. Here's the info we need about each field to describe them correctly cross language:
- number of bytes:1, 2, 4, 8, n or 2n (1/2/4/8/n/N ?)
- little or big endianess (L/B ?)
- signed or unsigned (U ?)
- integer, real or string (I/R/S ?)
I have yet no precise idea of a clear way to write it. Just ideas. What do you all think?
- exca> I updated this page Binary_&_Hex#The_data_types, only last column needs to be filled now.
