Fair Strides

TSL Patcher, TLKEd, and Accessories

13 posts in this topic

File Name: TSL Patcher, TLKEd, and Accessories

File Submitter: Fair Strides

File Submitted: 06 Mar 2017

File Category: Modding Tools

 



Inside this download, you will find several VERY useful tools. Almost all of these were made by stoffe originally and the only alteration I made was to make sure TSL Patcher did NOT check for the presence of the dialog.tlk file to verify the path you're installing the mod to. This was done to allow installing mods to the Workshop folders.

Of note in this package are three files:
1. ReadMe, really.pdf - A read-me file that really should be read if you want to understand how to do something with the TSL Patcher.
2. nwnnsscomp.exe - A modified script compiler that TSL Patcher uses to substitute tokens (such as .2da row pieces) in source scripts (.nss files) and then compile the scripts.
3. nwscript.nss - As far as I'm aware, the nwscript.nss file from KotOR 2, required by nwnnsscomp.exe to compile scripts.

Below are the original release thread descriptions for stoffe's work and I honestly don't think I could put it better than she already did years ago. :D

TLK Ed:

TalkEd is a dialog.tlk (or any TLK v3.0 file for that matter) editor that works with both KotOR1 and TSL. It can add new entries to a TLK file and edit or delete existing ones. It can create new TLK files from scratch or edit existing ones, and is capable of merging two TLK files together.

In addition it can be used to search among the entries in a TLK file for matches to a number of criteria.

(Dialog.tlk is the file that contains all the standard text strings in the game. It also links sound files to certain text strings.)

* * *

In a sudden burst of inspiration I finished a whole bunch of things I had planned for TalkEd but never gotten around to. I have uploaded the resulting TalkEd v1.0.4b version here.

What has changed in this version? Some things off the top of my head:

  • It now keeps track of the file it has loaded and can save it without every time popping up a Save dialog asking you to name the file.
  • You can doubleclick an entry in the grid to edit it without having to use the Menu or keyboard shortcut.
  • It will only warn about closing a file or the application if you've actually made changes to that file.
  • Added a "drag thing" (what are they called?) between the grid and the text display box, making them independently resizable.
  • Added displaying sound Resrefs for an entry in a separate column in the main listing.
  • Added new search filter to only list entries which has a sound file referenced.
  • Added new command in the Tools menu to delete TLK entries.
  • Added new command in the Tools menu to mass-add blank padding entries.
  • Fixed some minor bugs I discovered.
  • Lots of minor interface annoyances making it a little easier to work with.


Since my programming skills leaves a lot to be desired I'm sure there are still a bug or two which I haven't spotted during my testing. As such this is still considered a beta version. If anyone uses this and spots any problems, please let me know.




TSL Patcher (along with ChangeEdit):

The TSLPatcher is a small application intended to be used as a mod installer for KotOR and K2:TSL. Despite the name it works with both games in the series. Its purpose is to move some of the burden of making different mods compatible from the end mod user to the mod developer.

ChangeEdit is a support utility, used to create TSLPatcher configuration files with a somewhat user-friendly graphical user interface. (Well, more user-friendly than creating the config files by hand in notepad, anyway.)

It can, in general terms:

  • Add new entries to the dialog.tlk file, so you won't have to distribute the whole 10 MB file with a mod, and make it compatible with other mods adding new entries.
  • Modify and add new lines and columns to 2DA files that might already exist in the user's override folder, allowing different mods to modify the same 2DA file with less risk of causing incompatibility.
  • Modify values in fields and add new fields to GFF format files (UT*, DLG, JRL, GIT, ARE, IFO etc...) that might already exist in the user's override folder or inside ERF/RIM archives. Again to reduce incompatibility when different mods need to do things to the same file.
  • Dynamically assign StrRefs from your new dialog.tlk entries to 2DA, GFF, NSS and SSF format files, allowing you to use your new TLK entries regardless of which StrRef indexes they were added as, through the use of token references. (E.g. add the correct StrRef values to the "name" and "desc" column in spells.2da if you add a new force power.)
  • Dynamically assign values from 2DA and GFF files to cells and fields in other 2DA, GFF and NSS files, such as the line numbers from newly added rows in a 2DA file or the field path label of a newly added field. This can be used to link together files that reference eachother dynamically, regardless of where in the files your additions end up. E.g. linking new heads.2da --> appearance.2da --> portrait.2da lines together to add a new player appearance. Or linking a new appearance.2da line for an NPC to the "Appearance_Type" field in their UTC template, just to mention a couple of potential uses.
  • Insert StrRef or 2DA/GFF token values into scripts and recompile those scripts automatically with the correct values. (E.g. adding new Force Powers with an impact script that needs to know which lines in spells.2da the new powers are defined at.)
  • Dynamically modify SSF (Soundset) files to point to new entries you have added to dialog.tlk.
  • Automatically put other files that does not need to be modified into the correct folder within your game folder (e.g. "Override", "Modules", "StreamMusic" etc...), or inside ERF or RIM format archive files existing in any of those folders.
  • Insert modified GFF files into a RIM or ERF format file (ERF, MOD, SAV etc), found in the game folder or any of its sub-folders, or modify existing files already found in that destination file. Recompiled NCS script files can also be inserted into RIM and ERF format files (but only overwrite, not modify existing scripts with the same name).
  • Make unaltered backup copies of any files it modifies or overwrites, making it a little easier to uninstall a mod again.
  • Provide the user with different installation alternatives which may be chosen at installation time.
  • Display a ReadMe, instruction text or agreement with basic font and text formatting support (using the Rich Text Format) to the user prior to installation.


It cannot, in no uncertain terms: big_grin.gif

  • Make standard game scripts that are modified by serveral mods compatible. The structure of a script file is too dynamic to lend itself well to automatic merging (at least for someone of my skill level in programming).
  • Resolve naming/priority conflicts resulting from placing several variants of files with the same name in different sub-folders inside the override folder. It will always assume that all files it is supposed to modify are located directly in the override folder and not in any subfolders to avoid ambiguous situations.
  • Modify files held inside BIF files in the game, since KEY/BIF files work pretty much the same as the override folder in most cases, and editing the KEY/BIF data can lead to problems. This does of course not prevent you from extracting whatever files you need from the BIF data in advance and put them in the TSLPatcher's data folder.





A few quick "how to" examples:
Insert new branches into DLG files.
( http://web.archive.org/web/20150911133933/http://www.lucasforums.com/showpost.php?p=2135535&postcount=177 )

 

Install a New Player Appearance mod.
( http://web.archive.org/web/20150929073207/http://www.lucasforums.com/showpost.php?p=2168405&postcount=201 )

Troubleshooting:

  1. Q: I get a RichEdit line insertion error when trying to install mods. What's wrong?


    A: It seems a few people have odd versions of the RichEdit DLL files installed in their system that doesn't play nice with the colored text box component TSLPatcher uses. To work around this you could try to replace the RichEd DLL files with versions that should work. Extract the two DLL files from this archive and put them in your Windows\Windows32 folder. Move existing files with those names to a safe location first so you can restore them if this causes other problems! Do not overwrite them!

    Alternatively, if you don't want to mess with your DLL files, you could force TSLPatcher to use a plain text box for status messages rather than the colored/formatted one. To do this, use Notepad to open the changes.ini file found inside the tslpatchdata folder that came with the mod you wish to install. Under the [settings] section, change the value of the key PlaintextLog from 0 to 1.
  2. Q: I'm not seeing any Install Mod button, and the text field in the TSLPatcher window seems to extend behind the window boundraries.


    A: This odd problem some people experience seems to be tied to what screen resolution and pixel density is being used in your monitor settings, but I have been unable to replicate it or figure out exactly what's going on. As a workaround you can "click" on the Install button by using it's quick keyboard command. Pressing the [ALT] keys on your keyboard should start the installation process.
  3. Q: When trying to install a mod it complains that it's not a valid installation location. What's wrong?


    A: Make sure you are selecting the folder the game is installed in, not the override folder, when the TSLPatcher asks you where to install the mod.
  4. Q: When trying to install a mod it complains that access was denied to the dialog.tlk file.


    A: Make sure that your dialog.tlk file is not write protected. This file is found in the same folder as the swkotor.exe binary. To check if it's write protected and undo it, right-click on the file, pick Properties in the context menu and uncheck the write protected checkbox.


Original update history (ordered newest change first):

EDIT(2007-09-19) Uploaded TSLPatcher v1.2.10b1 and ChangeEdit 1.0.5b1, which fixes a bug/oversight breaking the changes.ini format when adding or updating ExoString fields or ExoLocString substring fields with text contining newline (LR/CR) characters. In those cases only the text before the first newline would get added earlier. This should now be fixed to handle text with multiple paragraphs properly. See this post for more details.

EDIT(2007-08-13) Uploaded TSLPatcher v1.2.9b which will handle already existing GFF fields a bit better when adding new fields to a GFF file. It will now update the value of the existing field to match what the new field would have had set, rather than just skip it entirely.

EDIT(2006-12-12) Uploaded TSLPatcher v1.2.8b10 hopefully making the Require file checks work reliably all the time, this time. Thanks to Darkkender for pointing this out.

EDIT(2006-12-10) Uploaded TSLPatcher v1.2.8b9 fixing a bug with the patcher not checking for required file if using multiple setups and auto-detecting the game install location. Thanks to Darkkender for pointing this out.

EDIT(2006-12-02) Uploaded TSLPatcher v1.2.8b8, which contains fixes for two bugs that sneaked their way into version 1.2.8b6. The bugs would cause installation to abort if the dialog.tlk file was write protected, or if copying a 2DA line and using a high() token to assign a new value to a column of the new line. Thanks to DarthCyclopsRLZ for pointing out these bugs.

EDIT(2006-10-03) Uploaded TSLPatcher v1.2.8b6, which contains a whole bunch of bug fixes and some new features. Please see this post for details.

EDIT(2006-09-07) Sneaky mini-update to TSLPatcher v1.2.8b4, fixes a bug with backing up files before replacing them from the InstallList, which was introduced when the install list sequence was changed to happen before 2DA edits. Also fixed mistake where word wrap was permanently left off when toggling from the Config Summary back to the info.rtf display on the main TSLPatcher window.

EDIT(2006-08-28) TSLPatcher v1.2.8b3 uploaded, this hopefully fixes the occasional crashes when recompiling scripts with include files, and works around the weird GUI glitch in the main TSLPatcher window that resulted in the buttons and scrollbars ending up outside the window area. Huge thanks to tk102 for taking time to iron out the nwnnsscomp bug.

EDIT(2006-08-09) TSLPatcher v1.2.8b2 uploaded. This version fixes a bug with the RIM handling class which caused the game to have trouble loading RIMs modified by the Patcher, caused by an error in the RIM specifications I had at my disposal. The game should now properly load modified RIM files without problems.

EDIT(2006-08-09) TSLPatcher v1.2.8b1 and ChangeEdit v1.0.4b8 uploaded. This version allows the "Install" function to place files into ERF/RIM archives, allows options for renaming files during installation, and adds a "config summary" button to the main TSLPatcher window.

EDIT(2006-08-06) TSLPatcher v1.2.8b0 and ChangeEdit v1.0.4b7 uploaded. This version changes how the ERF handling functionality works to make it more useful. See this post for more info.

EDIT(2006-07-25) TSLPatcher v1.2.7b9 and ChangeEdit v1.0.4b6 uploaded. This version has some changed made to the Add/Modify GFF Field functionality, allowing to to be used to insert new conversation branched into DLG files. Various minor user interface changes have also been made.

EDIT(2006-07-08) TSLPatcher v1.2.7b7 and ChangeEdit v1.0.4b4 uploaded, containing some bugfixes, interface improvements (I hope) and minor changes to make it a little less sensitive to errors.

EDIT(2006-05-28) Uploaded TSLPatcher v1.2.7b5 and ChangeEdit v1.0.4b3, with a Mini-update that allows it to optionally auto-detect the game folder location rather than ask the user where it is, as requested.

EDIT(2006-05-11) Uploaded TSLPatcher v1.2.7b4 and ChangeEdit v1.0.4b2. No new features, just some fixes to bugs I discovered, and slight change to how the script compiler is called to allow it to work with the custom version of nwnnsscomp that tk102 has been kind enough to provide. This custom version is also included in the download now.

EDIT(2006-04-29) Uploaded TSLPatcher v1.2.7b1 and ChangeEdit v1.0.4b1. Too much more information can be found in this post.

EDIT(2006-03-25) Updated ChangeEdit to v1.0.3a with GFF Compare function, 2DA Modifier copy button and a whole bunch of interface improvements. See this post.

EDIT(2006-03-19) Updated TSLPatcher to v1.2.6a (wip v2), which fixes a bug that would prevent the script compilation function to work properly on Windows 98 and Windows 2000 computers.

EDIT(2006-03-09) Uploaded new test version, TSLPatcher v1.2.6a (WIP v1) with added support for modifying SSF Soundset files with dynamic StrRefs for added TLK entries. See this post for a little more detail.

EDIT(2006-02-03) I've uploaded a new test version, TSLPatcher v.1.2.5a, which has some limited ERF (e.g. module file) packing functionality added. See this post for more details.

EDIT(2006-01-16): I've uploaded a test version of TSLPatcher v1.2 and ChangeEdit v1.0 which has some new features added. See this post for details.

 

 



Click here to download this file

  • Like 4

Share this post


Link to post
Share on other sites

I think I just might end up using this in the next day or so... thanks for posting this FS! (and thanks Stoffe ^^)

  • Like 1

Share this post


Link to post
Share on other sites

@Hashishin: What are you trying to write? You can enter it in the Fast Reply box at the bottom of the page without quoting the entire first post.

Share this post


Link to post
Share on other sites

I've run into an issue when using TSLPatcher to edit .dlg files that I hope you guys might help me out with.

The dialog I want to edit has this form:

 

Entry 1

  > Reply 1

     > Entry 2 (conditional script)

     > Entry 3 (conditional script)

 

I want to change it to this:

 

Entry 1

   > Reply 1

      > NEW Entry (NO conditional)

         > Entry 2 (conditional)

         > Entry 3 (conditional)

 

The problem here is that this requires a modification of "Reply 1"'s entry list which originally consisted of "Entry 2" and "Entry 3". For one I can't remove the second entry from the list, but I don't actually mind it staying there since my "NEW Entry" has no conditional anyway so any entry listed afterwards won't show up ingame. But the other problem is to actually remove those conditionals. Since they're stored in the entry list as well (which I didn't actually know until today), I'd have to change the "Active" field to be empty. And it seems that TSLPatcher can't do that. So my question is this: Is there are way in which TSLPatcher can do it but I just haven't found it yet? And if not, is there a better way around that than to simply add a script that always returns true?

 

Thanks for any help :)

Share this post


Link to post
Share on other sites

Where can I get the source code to TSLPatcher?

 

I'm in the midst of installing a bunch of mods, and it's... mind-deadening tedium to keep selecting the Kotor2 folder under steam...

 

So, I want to patch the tool to be able to read a "config file" telling where the Kotor2 folder is.

 

And, if I have the time to do it, probably modify the tool enough to be able to tell it which mods to install (all, or a subset), so it can iterate over the list of mods to install rather than having the user running the TSLPatcher tool TENS of times (Example: The "TSL NPC Overhaul" mod which contains 60+ mods inside of it -- mind-numbingly tedious :ouch: ).

 

I might even expand the tool to be a full-fledged "Patch Manager" ... but that's more the long-term personal wish of mine :blush:

Share this post


Link to post
Share on other sites

@Pepoluan: As it turns out, I'm rebuilding the TSLPatcher in a different language (from Delphi Pascal to Perl) due to some annoying issues with it.

 

Most of your list I've already been implementing.

 

I can probably allow a "modinstall.ini" in the same folder as the .exe, with a sub-folder called "moss". The "modlist.ini" would then have a list of installs to run back-to-back, with paths to the .ini files to run and the name of the Info file. The paths would be relative to the mods folder.

  • Like 1

Share this post


Link to post
Share on other sites

@Pepoluan: As it turns out, I'm rebuilding the TSLPatcher in a different language (from Delphi Pascal to Perl) due to some annoying issues with it.

 

Most of your list I've already been implementing.

 

I can probably allow a "modinstall.ini" in the same folder as the .exe, with a sub-folder called "moss". The "modlist.ini" would then have a list of installs to run back-to-back, with paths to the .ini files to run and the name of the Info file. The paths would be relative to the mods folder.

That's awesome!

 

I'm not a Perl programmer, though, so if you release the source code, I might not be able to assist much (not well versed in Perl :blush: )

 

Just some thoughts, hopefully can inspire you:

  • My plan was to make the installer config optional, so if the installer config is not found in the same directory as the TSLPatcher.exe file, it will revert to the 'normal' behavior
  • For the "modlist", I originally plan on simply creating a filter prior to the loop; the "modlist" would specify exactly the name of the sub-mod to install (the name comes from the "namespaces.ini" file?)
  • The filter syntax I envisioned is 'glob-based' (instead of regex-based) with one prefix character indicating install or not, processed in order, e.g.:
    • +*  = install all sub-mods
    • -*NAR  = remove all sub-mods that end with the letters "NAR" (case-insensitive)
    • +101NAR  = install sub-mod with the exact name "101NAR"
    • These three lines will result in installation of all sub-mods, except mods ending with "NAR", but will install "101NAR"
  • I want to patch it also to unconditionally append to the installation log, recording the time of installation and which sub-mod got installed
    • If it installs multiple sub-mods in one go, it will first record the time of start and the list of mods after being filtered (see above), then for each submod installation record the time of installation and which sub-mod got installed

Anyways, glad to hear that the TSLPatcher is not abandoned, yay!

 

Feel free to hit me up if you need my help; I'll try to assist the best I can.

Share this post


Link to post
Share on other sites

I think I might have identified a bug in TSLPatcher. The problem seems related to files within .mod files (probably any ERF archive) that end with minus '-' or plus '+' before the extension (maybe anywhere in the filename?). Basically, the trailing minus and plus are getting removed. It doesn't depend on modifying the +/- files directly, just unpackaging and repackaging of the .mod file in order to add files or alter GFF files does it.

 

The place this seems to come up is with danm14ac.mod in K1. It has two scripts called k_pdan_state1-.ncs and k_pdan_state1+.ncs which are part of the 'Murdered Settler' quest you get from Bolook on Dantooine. After you run a TSLPatcher based installation that modifies danm14ac.mod ... the resulting .mod file only contains k_pdan_state1.ncs. The file sizes of state1- and state1+ are the same so I'm not sure which one is winning out, but either way, the script name no longer matches the DLG file, and the quest becomes impassable.

 

Not sure if this is fixable in existing code (with available time), but it's something to check in a newly written codebase. In the short term maybe it makes sense for mod-makers to manually include any affected files in their mods so that they are installed directly to Override/.

Share this post


Link to post
Share on other sites

Ndix_UR: I had completely forgotten about this. I fixed this bug in ERFEdit, but forgot that TSLPatcher uses a copy of this library. In either case, I'm mostly done translating TSLPatcher to Perl, where I don't even bother with the check on the filename's contents.

  • Like 1

Share this post


Link to post
Share on other sites

I've noticed, at least with the kotor version, that TSL patcher has issues when it comes to mods using the same module files thus creating massive compatibility issues. Is there a work around so that mods that edit the same module files may be used?

Share this post


Link to post
Share on other sites
9 hours ago, Doctor Evil said:

I've noticed, at least with the kotor version, that TSL patcher has issues when it comes to mods using the same module files thus creating massive compatibility issues. Is there a work around so that mods that edit the same module files may be used?

That's exactly what TSLPatcher is for. There are just some mods where the creator decided to not use TSLPatchers full features and instead of modifying a module file just drops it into the modules folder and that's what's creating the compability issues.

Share this post


Link to post
Share on other sites
15 hours ago, Kexikus said:

That's exactly what TSLPatcher is for. There are just some mods where the creator decided to not use TSLPatchers full features and instead of modifying a module file just drops it into the modules folder and that's what's creating the compability issues.

hmm, well i'm noticing modules being skipped or overwritten in every instance which leads me to believe it's not working properly for me, however if this is the case then that makes sense. Thank you

Share this post


Link to post
Share on other sites
6 hours ago, Doctor Evil said:

hmm, well i'm noticing modules being skipped or overwritten in every instance which leads me to believe it's not working properly for me, however if this is the case then that makes sense. Thank you

The skipping is actually a good thing. Modules being overwritten not so much. 

If a mod edites files in a module and is properly set up it will do the following: It checks whether the module already exists in the module folder. If it doesn't it takes an unmodified module file and copies it there. Otherwise it will skip this step. This is where those warning messages come from. 

In either case the installer will then proceed and modify the content of either the unmodified or the already existing and modified module. 

This feature of editing the already existing module files is what makes TSLPatcher so useful as that allows for much better compability. 

Unless the mod author decided to just straight up replace the module files in which case you want to install that mod as early as possible. 

And all of the above is also the case for files in the override folder. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now