thanks Lance
to be clear, the output shown above is output by NwN2 when saving a game.
I came across it while searching around my Nwn2 files to make a list of what filetypes are GFFs. This is what i have so far, btw
/// <summary>
/// The types of gff-files available.
/// </summary>
enum GffType : byte
{
generic, // 0
ARE, // 1
BIC, // 2
FAC, // 3
GIC, // 4
GIT, // 5
IFO, // 6
JRL, // 7
ROS, // 8
ULT, // 9
UPE, // 10
UTC, // 11
UTD, // 12
UTE, // 13
UTI, // 14
UTM, // 15
UTP, // 16
UTS, // 17
UTT, // 18
UTW // 19
}
So … while arbitrarily testing my in/out routines, I opened a savedgame’s playerlist.IFO file and it threw an exception. I was mildly surprised but started debugging … CExoLocString, which is a GFF field-type, can store strings in various localized languages:
/// <summary>
/// The types of languages available.
/// @note The values will be used as integers as well.
/// </summary>
enum Languages : uint
{
English = 0,
French = 1,
German = 2,
Italian = 3,
Spanish = 4,
Polish = 5,
Russian = 6, // <- nwn2 add (not in the nwn1 doc)
Korean = 128,
ChineseTraditional = 129,
ChineseSimplified = 130,
Japanese = 131,
// TlkEdit2 defines another Locale: "GffToken".
// It can appear as either the
// "LocalizedName" (eg. "Battleaxe +2")
// or
// "LastName" (eg. "DoneOnce7=1")
// within an item's Struct under either
// "Equip_ItemList"
// or
// "ItemList"
// .
GffToken = 4294967294 // 0xFFFFFFFE
}
And with the help of TlkEdit2, noticed that a ‘valid’ language-type can be the so-called “GffToken” – it’s not described in the docs, however. I fixed that and took a closer look at savedgames’ IFO and BIC files … the player.BIC data is also stored in playerlist.IFO (the latter holds data about all current player characters, and seems to be the file/data that’s reloaded instead of player.BIC). And started noticing funnythings in the BIC/IFO gffs. Things like that field getting truncated above.
And things like this:
but uh, integers shouldn’t be getting stored as Chars (i mean, that’s just silly). Chars are essentially letters that make up a string … (and just to be funner, they’re defined as 1-byte in C++ but as 2-bytes in C# – the designers of the GFF spec seem to have used the C++ 1-byte type, but that’s ASCII, rather ANSI, since ASCII is only 7-bits and it was ANSI that extended it to all 8-bits of a byte … but that’s not necessarily big enough to hold a character in UTF8 … and some strings in NwN2 are UTF8 …). So i have to sort that out.
Because here’s an example of what a “char” usually looks like:
And when I continued perusing BIC/IFO files in both TlkEdit2 and my GeneralGFF app for comparison, I began to notice how a bunch of stuff wasn’t really making strict sense in our character data. Eventually i saw the truncated labels and chose to watch random Utube videos for the rest of the day.
The other good part is, TlkEdit2’s output and my output appear to be the same (apart from the interpretation of Chars)
edit for clarity (sic)
Or of course … a script needs recompiling since a change. 
