Talk:GXT

Separate page for SA/IV?

Given the length of this page, would it make sense to move the format for GTA: SA and IV to a different page as has been done with SFX and SFX_(SA)? Those SFX pages make sense because even though the formats there share a (vaguely) common base, there's still enough difference for them to be separate. I think the same could be done here to keep the article a bit shorter. – Squ1dd13 (talk) 15:15, 1 September 2020 (UTC)

TABL sections

Has someone yet tried to add more "TABL"-Sections to an GXT? (In standart-game's this is never used, I don't know if this will work...)

Sanny Builder

"An entire list of all entries is available with Sanny Builder." ... Where? o.O --Aschratt 14:33, 26 Nov 2007 (UTC)

Here: "SB\help\GXT Strings\*.text" Seemann 15:25, 26 Nov 2007 (UTC)

Great! Thanks! :) --Aschratt 16:13, 26 Nov 2007 (UTC)

Thoughts about header format

Is it possible that the headerformat truely looks like this?

INT16   - 2b   - File version (0x04 used since San Andreas - previously no version information has been stored - see below)
INT16   - 2b   - UTF encryption format (0x08 for UTF-8, 0x10 for UTF-16 - other formats are not used or not implemented)
CHAR[4] - 4b   - FourCC: "TABL"

GTA III uses some different format. It does not know tables. Everything it know is 1 general table. So the version history is like this:

Version 1 - GTA_2
Version 2 - GTA_3
Version 3 - GTA_VC
Version 4 - GTA_SA, GTA_IV

Still I don't know if San Andreas also supports UTF-16 encryption. Need to test this. --Aschratt - oO 16:29, 25 April 2010 (UTC)

GTA III format

CHAR[4] - 4b   - FourCC: "TKEY"
UINT32  - 4b   - Offset to data (TDAT section)

To get the number of entries inside this table divide the offset to the data section by 12 (8 byte for each entry name and 4 byte for each entry offset - see below). Now each entry got the following header information:

UINT32  - 4b   - Offset to content (relative to data offset + 8 representing "TDAT" fourCC and the size of the TDAT section - see below)
CHAR[8] - 8b   - ASCII encodet name of the entry

Now after the collection of entry header information the TDAT section follows as we know it from the other formats:

CHAR[4] - 4b   - FourCC: "TDAT"
UINT32  - 4b   - Offset to end of file (or size of data section)

Each content string is stored in multi-byte encryption (guess UTF-16). Content strings are null-terminated. --Aschratt - oO 16:29, 25 April 2010 (UTC)

String encryption

-8 and UTF-

Any suggestions about how the encryption really works? --Aschratt - oO 16:29, 25 April 2010 (UTC)

It seems special characters values are derived from their position in the font texture(s). May be a 4 year late answer but it's still useful information. --Ethanh59 (talk) 04:28, 1 October 2014 (UTC)