Proposed: Support for Multiple TLK files
shadguy
Member Posts: 154
A request from the community came up in Savant's Aielund Saga thread over here: https://forums.beamdog.com/discussion/67661/aielund-saga-enhanced-edition#latest , to update his TLK to provide better in-game descriptions of spells and effects. The core issue is that Aielund uses arQon's EMS system, which is a complete re-write of the spell scripts to fix a lot of issues (like dispel calculations, etc).
The problem is that Aielund also uses CEP, which comes with a TLK. I think the CEP TLK would be mostly orthogonal to one supporting EMS, in terms of 2da coverage. So, it might be reasonable integration-wise, if we were to assign two TLKs to a module and tell the mod to use CEP's TLK for everything except spells.2da, feat.2da, and iprp_spells.2da references (for example). Even if there were come conflicts, it could reduce the maintenance work for updates.
As it stands right now, there is little incentive for Savant (or anyone) to undertake an EMS+CEP tlk integration effort as one would be committing to keeping up with two sets of moving targets.
If this idea found support, it might also be helpful for some folks playing with stuff like NWNPRC, or some racial systems.
So the basic idea, to summarize:
1) Assign mutliple TLKs to a module
2) Designate one default TLK from the list
3) Designate specific 2DA <-> TLK relationships to honor
Cheers,
-Dave
The problem is that Aielund also uses CEP, which comes with a TLK. I think the CEP TLK would be mostly orthogonal to one supporting EMS, in terms of 2da coverage. So, it might be reasonable integration-wise, if we were to assign two TLKs to a module and tell the mod to use CEP's TLK for everything except spells.2da, feat.2da, and iprp_spells.2da references (for example). Even if there were come conflicts, it could reduce the maintenance work for updates.
As it stands right now, there is little incentive for Savant (or anyone) to undertake an EMS+CEP tlk integration effort as one would be committing to keeping up with two sets of moving targets.
If this idea found support, it might also be helpful for some folks playing with stuff like NWNPRC, or some racial systems.
So the basic idea, to summarize:
1) Assign mutliple TLKs to a module
2) Designate one default TLK from the list
3) Designate specific 2DA <-> TLK relationships to honor
Cheers,
-Dave
1
Comments
I mean ultimately it’s just copying some spell descriptions into the CEP tlk, updating the appropriate 2da lines, and adding Aielund.tlk to the CC.
Not sure that’s so cumbersome as to warrant Beamdog dedicating energy to allowing 2x custom tlks on top of dialog.tlk.
Per the tlk documentation:
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?>
Then each large 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 and possibly merge 2das together for their top haks.
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
- 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- map values using the 01 high-bit from the previous method to the first specified alternate tlk as before
Try this meaglyns-nwn-tlk-compiler