Feature request - Allow for multiple alternate tlk files

SyrusGreycloak

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

TarotRedhand

As I see it the main problem here is that tlk files are there to enable translation into various languages. Therefore it is not just the issues you raise but also doing it across a number of different languages as well.

TR

SyrusGreycloak

I don't see the number of different languages as a current issue on the technical side for this request. That has already been handled by the tlk file format itself. The expansion I'm suggesting would work for all supported languages as it's not changing the format of the individual tlk files themselves, just as when Bioware gave us the option for a user tlk. All it does is allow for multiple files to be attached and how to determine the addressing into those files to get the correct string. The content/language of the stored string would be handled as it currently is.

Or am I missing something else you are trying to point out?

Arvirago

I agree. It would be great to have a CEP_es.tlk or ProjectQ_es.tlk files with spanish translations, to add to my custom mod tlk, without having to merge, translate and all that hard work.

TarotRedhand

@Arvirago While nice in theory I would point out that the two that you mention were made by users and not BD. That being the case BD can't alter them due to copywrite issues. As they are user made that does open the door to you doing the translation yourself...

TR