Any advice on the format of my mod?

[Ulic and Cay]

I've been fixing some of the issues with the Prologue, Peragus, and the early Harbinger modules. I was wondering what the best format for releasing these changes would be. Here are some of the problems I've encountered as I've been thinking about this:

Due to the fact that some of the files I have changed have the same name I can't simply tell people to drop them in their override folder. For example there are two .DLGs named coorta that fire during different modules. If I do it this way there are certain points where the game fires the wrong dialog and hangs.

If I package the changes as a .MOD I run into some other problems. During some dialogs creatures behave oddly. For example there is a dialog where some droids attack some miners, when packaged as a .MOD they won't shoot the miners but physically attack them instead and then don't leave as they are supposed to.

Packaged as .ERFs and .RIMs all my changes are made and there are no problems, however, this way people are forced to backup their original files.

Any suggestions guys?

[stoffe]

I've been fixing some of the issues with the Prologue, Peragus, and the early Harbinger modules. I was wondering what the best format for releasing these changes would be.

 

Do you care about making it compatible with other mods, or is it just a matter of what's the easiest format to distribute the mod in?

 

If you don't concern yourself with compatibility with other mods the easiest way would be to just send the modified RIM files and tell people to back up the originals before putting the new files in the Modules folder. This might break compatibility with other mods modifying the same files though, and if you've modified many modules it might make your download fairly large if you need to include many _s.rim files.

 

If compatibility is an issue you can use a mod installer that backs up the RIM files automatically and then modifies existing GFF format files (UT*, DLG, ARE, GIT etc) inside them to apply your changes, and inserts any modified scripts or other modified files that are not GFF into the RIM. This way you wouldn't need to send the whole RIM file, only the data files that are supposed to be added/modified inside them, and it would increase the chance of your mod being compatible with others. On the downside it can be a lot of work to configure the installer properly.

[Ulic and Cay]

Size and compatibility are issues I've considered. I was considering looking into your TSLPatcher, now I think I definitely will. Thanks for the response, hell thanks for writing the patcher too.

One last quick question. I don't know how the international versions of the game work. Obviously text changes would be in English but is there anything that would prevent the mod from working on an international version of the game?

[stoffe]

One last quick question. I don't know how the international versions of the game work. Obviously text changes would be in English but is there anything that would prevent the mod from working on an international version of the game?

 

Depends on the type of text. All the standard game text is kept in the dialog.tlk file, so as long as it isn't replaced the game text will remain in the language it used to be. (This also applies to new strings you add to dialog.tlk for your mod. Usually spell or feat names/descriptions, or generally any text that is loaded via a 2DA file.)

 

As for new text added in mods that is stored directly in the ExoLocString fields rather than in dialog.tlk, it depends on what locales you add substrings for. An exolocstring contains a number of substrings, two for each language (male and female variants for languages where that differs) which are identified by an ID number (female substrings are languageid + 1).

 

The game then looks in its dialog.tlk file for the language setting there, and loads the substring from the ExoLocStrings with the corresponding language ID. If this substring does not exist an empty/blank text string is used (i.e. it does not fall back to other substrings with different language IDs).

 

So, for new/changed text that is stored in ExoLocStrings within GFF format files you have to make sure you add substrings for all language versions of the game that should be supported by the mod.

[Ulic and Cay]

Well then I guess I have some more questions. What is the best way to make changes to the game dialog, changing the dialog.tlk or modifying it directly in a .dlg file? Won't changing such a major file like dialog.tlk make me incompatible with other mods that have changed the .tlk? Or is there a feature in the patcher that just makes my changes?

[stoffe]

Well then I guess I have some more questions. What is the best way to make changes to the game dialog, changing the dialog.tlk or modifying it directly in a .dlg file? Won't changing such a major file like dialog.tlk make me incompatible with other mods that have changed the .tlk? Or is there a feature in the patcher that just makes my changes?

 

It's best to put modified text in conversations directly in the DLG files, this is what the ExoLocStrings are intended for. Just make sure you add the text to substrings for all languages you want the mod to be compatible with. If you don't want to bother with creating all the substrings I think tk102's Language Converter utility can be used to handle that for you afterwards.

 

As for editing the TLK file, the TSLPatcher mod installer is capable of inserting new entries into the dialog.tlk file so you won't have to ship the whole file with your mod, and it should make it play nice with other mods that also modify this file. It cannot currently edit existing strings in the file though, so you'd have to add any text that should be changed as a new entry and update the places the entry is referred with the new StrRef index. But this should only be needed for text strings set in 2DA files. For GFF format files, like DLG, you should use the ExoLocString fields to store the text directly in the file. Makes things more self-contained and modular.

[Ulic and Cay]

As I'm finally getting around to packaging and my mod I worry that I may have run into my own little problem. There was a situation where a BarkString() command in one of my scripts calls a string that I modified in the dialog.tlk file (I used TalkEd to append a Sound Resref file to some floating text). Because the BarkString() command requires a specific string number I can't just rely on TSLPatcher and an append.tlk file can I? Am I just out of luck here or is there some way that I could get TSLPatcher to create a specific new string reference that I could reference in my script? One way at the end of the dialog.tlk that almost certainly isn't being used by another mod, like StrRef 140000 for example.

[stoffe]

There was a situation where a BarkString() command in one of my scripts calls a string that I modified in the dialog.tlk file (I used TalkEd to append a Sound Resref file to some floating text). Because the BarkString() command requires a specific string number I can't just rely on TSLPatcher and an append.tlk file can I?

 

The TSLPatcher should be able to handle this. Make the patcher add the new entry to the dialog.tlk file, and store the resulting StrRef to be accessed via a StrRef# token. Then add the NSS file for your script to the "Compile list" in the TSLPatcher config to make it recompile that script (make sure the NCS file is not in the tslpatchdata folder, only the NSS source should be there). Then, inside the source for your script, replace the hardcoded StrRef number in your BarkString() call with the token instead. The TSLPatcher will then replace the token with the StrRef value your entry was inserted as, and recompile the script and move the resulting NCS file to its destination.

 

This handles the problem that entries added to dialog.tlk might not end up at the same StrRef for everyone.

 

For example, if you assign your new dialog.tlk entry in the config to the StrRef0 token, like:

[TLKList]
StrRef0=0

 

...you would alter your NSS file to look like (relevant part bolded):

 

   BarkString(OBJECT_INVALID, [b]#StrRef0#[/b], 200); 

 

Make sure you put the copy of nwscript.nss and nwnnsscomp.exe that came with TSLPatcher inside the tslpatchdata folder for your mod. TSLPatcher will need those to be able to compile the script(s) during installation. And make sure any scripts added to the "Compile list" don't have corresponding NCS files in the tslpatchdata folder already.

 

This is the same method used to insert values stored in 2DAMEMORY tokens into scripts and have them recompiled (i.e. wrap the token name with a leading and trailing # character in the source code).