So my kids are into D&D now and wanted me to get some of my old custom NWN stuff merged together with CEP and some other things. As I was trying to put together the tlks, it occurred to me that a Builder's life would be much easier if multiple tlks could be specified in a module.
Per the tlk documentation:
A module may specify that it uses an alternative talk table besides dialog.tlk.
If a module uses an alternate talk table, then bit 0x01000000 of a StrRef specifies whether the
StrRef should be fetched from the normal dialog.tlk or from the alternate tlk file, If the bit is 0, the
StrRef is fetched as normal from dialog.tlk. If the bit is 1, then the StrRef is fetched from the
alternative talk table.
If the alternate tlk file does not exist, could not be loaded, or does not contain the requested
StrRef, then the StrRef is fetched as normal from the standard dialog.tlk file.
Could it be expanded to add a high byte instead of using the high bits of the current value to allow using multiple custom tlk tables? The community could setup a standard as to which ones to put where, so long as the UI gives us the option to order appropriately and perhaps leave some spots empty.
So, for example:
0/no value - standard game tlk
1 - leave for module/pw world builders own content
And the various community teams decide the following,:
2 - CEP
3 - PRC
4 - <some other system>
5 - <some other system>
<cap at 8? 16?>
Each large community project can have their 2das have the correct numbers because they'll know 'slot x is used by my project, so all my strrefs must be high byte value + line number'. Builders would just have to slot the tlks in the correct spot. Obviously this doesn't remove merging 2das together for top haks, but does remove having to renumber strrefs when tlk text has to be moved to different places.
The issues I see are:
- restructuring the toolset custom content UI to facilitate 'slotting' the tlks to associate the correct high byte value to the respective file. Perhaps, per the example above, I don't want to use CEP, but I want PRC, and it has to come in as 3 to keep their 2da values correct. 2 would (and possibly 1 if a module builder doesn't use their own tlk file) need to be blank and the game engine would need to make sure the relevant file gets assigned the correct value you need.
- updating the module ifo gff to handle a list of alternate tlks structs, plus allow blank entries in the list & relevant code for this. Change in the ifo file could break community tools that edit this file.
- updating code to handle extra byte if it currently cannot handle the extra value already (i.e. code uses smaller data type)
- backwards compatibility for old modules using custom tlks. If feasible, keep the prior method of mapping values using the 01 high-bit to the first specified alternate tlk