I'm working on a very simple mod that will make Bao-Dur a Sentinel instead of a Guardian. The script portion was quite easy and took me 10 minutes.

What I'm struggling with is making this mod compatible with other mods, specifically USM since it uses baodur.dlg. What I'm trying to figure out is how to get TSLPatcher to change existing dialog entries. I'm not trying to add entries to baodur.dlg, just change a couple of entries. Any pointers on how I should go about doing this?

What I'm struggling with is making this mod compatible with other mods, specifically USM since it uses baodur.dlg. What I'm trying to figure out is how to get TSLPatcher to change existing dialog entries. I'm not trying to add entries to baodur.dlg, just change a couple of entries. Any pointers on how I should go about doing this?

If you aren't adding any new entries or replies and only modifying something for existing entries the easiest way if you aren't too familiar with the GFF layout of a DLG file would be to use the Compare button in ChangeEdit to automatically generate the needed modifiers:
Make a new folder for your mod, copy TSLPatcher.exe to this folder (rename it if you wish) and create a folder named tslpatchdata inside this folder as well.


Extract an unaltered baodur.dlg file from dialogs.bif with KotorTool and save it in the tslpatchdata folder.


Make a copy of this baodur.dlg file as well and save it elsewhere. Modify it with tk102's DLGEditor to apply the changes needed for your mod.*


Start ChangeEdit.exe, create a new config file and save it as changes.ini inside the tslpatchdata folder you created in step 1 above. Fill in the name of your mod on the Settings panel and click the Save button.


Select the GFF Files section in the treeview, rightclick on it and pick "Add GFF File" in the context menu. In the window that opens, click the folder icon to the right of the input box and select the baodur.dlg file and click the OK button.


Expand the GFF Files section and select baodur.dlg which should now appear under it to open the right panel for it. Above the modifier list in the right panel click the "GFF Compare" button (it's the one with a finger pointing at a red blob). Two standard "Open" dialog boxes will open. In the first, select the unaltered baodur.dlg file you saved in the tslpatchdata folder. In the second, select the copy of baodur.dlg you modified for your mod.

ChangeEdit should now compare the two files for differences and create modifiers for any differences it finds.


If your mod contains any new NCS files or other files that needs to be installed in a specific location for it to work but won't need to be modified, click the "Install files" section in the treeview and add them there. Copy the files that needs to be installed into the tslpatchdata folder as well.


Open WordPad and create a new RTF format document and save it as info.rtf in the tslpatchdata folder. The content of this document will be displayed in the main installer window when the installer is started, so you may put any special instructions, or the readme file of your mod here, as you like.


* = It's important you use a clean dialog file for this to apply your changes to. If you use a file already modified for another mod those changes will be found by ChangeEdit when it compares the files and modifiers will be created for them as well, which is not desired.

It may sounds really stupid...
May you release source code of your TSLpatcher, please???

It may sounds really stupid...
May you release source code of your TSLpatcher, please???

No, that's too embarrassing. When I started writing the TSLPatcher and its support tool I hadn't written a line of code in 4 years, so it's an understatement to say my programming and design skills were rusty. And I didn't do much design or make it scaleable since it originally only was meant as a small app to install my high level force powers mod. But it has grown beyond anything I originally imagined for it since, and I've been too lazy to rewrite it from scratch by the book instead. :)

The end result is that the code is one big tangled mess without much in the way of design or over-arching structure. Not pretty. Not something you'd want on display and let others have a look it if you can help it. :)

Besides, it's written in Delphi7 (as evidenced by the bloated EXE size), so the source code would be of little use to anyone who don't have that RAD environment (which is hideously expensive if you don't get a student discount).

What would you want it for?

I want to translate it to Russian, German and French. That is all.

And one bug: sometimes, especially when I use non-English languages, it gives me error (it don't want to create backup folder, so I have to do it sometimes.).

I want to translate it to Russian, German and French. That is all.


Hmm, I could try to put all the text strings in the TSLPatcher into a resource file instead, that might make translating it a bit easier, if there aren't any other changes than the language required for different locales.


And one bug: sometimes, especially when I use non-English languages, it gives me error (it don't want to create backup folder, so I have to do it sometimes.).

Hmm, if this just happened in recent versions and you haven't downloaded v1.2.8b4 that could be a bug not related to language. hen I moved the sequence things were made so the InstallList part happened earlier I forgot to move the part where the Backup folder was created as well, which would result in an error similar to what you describe.

Yeah, Resource file is great idea!

Also I'm sure YOU may release v1.2.8b5, I like this progress bar and other things, it will be great to see it released.

I have just uploaded version 1.2.8b6 of TSLPatcher. While I had originally intended to update ChangeEdit as well to handle all the new settings and keys added, a fairly serious bug was discovered that this version fixes. I thought it more important to get the bug-fix version out first, even if it doesn't quite include all I had planned.

The next version, which hopefully will be released within a few weeks, should contain an updated ChangeEdit as well, so this can be considered a bugfix-version primarily. (Unless you enjoy editing INI config file by hand. If that's the case, ask and I'll describe in more detail how the new keys are used. :))

Anyway, these things are new or changed in version 1.2.8b6:

Fixed bug where the Backup folder might not yet have been created when backing up files from the Install List, after the list was moved to earlier in the install sequence.


Added a progress bar to the main TSLPatcher window to give the user a better idea of how far along the installation progress is when installing larger mods.


Fixed word wrap bug when toggling between the Configuration Summary display and the mod information text in the main TSLPatcher window.


Added the HackList modifiers to the Configuration Summary display. Also added name of source file if different from the destination file name (configured with the !SourceFile and !SaveAs keys).


Added an optional !OverrideType key to the [filename] sections of files to be saved into ERF or RIM files. If set it can determine how TSLPatcher should react if a file with the same name already exists in the override folder (and thus would make the game not use the one in the ERF/RIM). This key can hold one of three values: ignore (default behavior, do nothing special), warn (post a warning in the progress log) or rename (add a old_ prefix to the name of the file in the override folder to deactivate it).


Added an optional !DefaultDestination key to the [CompileList] section which will determine where the NCS files should be put if no specific destination has been set. Default value if the key is left out is the override folder as before. In addition to override it can be set the the relative path (from the game folder) and name of an ERF or RIM file to insert the scripts into. This value can then be overridden with the !Destination key for individual files as before. This key is just a timesaver to avoid having to set !Destination keys for lots of files if most of them shouldn't be put in the override folder.


Optimized speed and efficiency of storing many recompiled NCS files into an ERF or RIM file. Before the ERF/RIM was saved, closed and reopened between each file that was inserted, now it's kept open until another destination is encountered. Thus if you insert scripts into multiple ERF/RIM files it's a good idea to keep them grouped by destination in the [CompileList] modifier list.


Added optional !SourceFile and !SourceFileF keys to the [TLKList] section. If present they can be used to set an alternative name of the TLK file to use to add strings into dialog.tlk from. If those keys are left out the default values are append.tlk and appendf.tlk, as before. This can be used to have different namespaces/setup lists residing in the same folder but using different append.tlk files (for example to provide different selectable language versions of a mod).


Fixed bug with TLK file handling that prevented TSLPatcher from properly handling individual TLK entries with strings longer than 4096 characters. It can now handle strings of any size properly.


Moved most text strings in the TSLPatcher application into the Resource StringTable instead of having them in the code. While this makes the application marginally larger it makes it easier to translate it to other languages, if so desired, by using a resource editor.

Is there currently, or is there a plan to add soon, a function in TSLPatcher to insert a reply or entry into a pre-existing list of others in a DLG file (such that the new entry/reply appears at a certain location causing any and all pre-existing ones to be shoved down, instead of just adding one to the bottom of the list)? If not, I'd like to request that such a function be added in, so that something like the following is possible:

starting with the entry:
E42: What do you want to know?
R69: Who?
R67: What?
R58: Where?
R63: Why?
R46: Nevermind.

a new reply (next available number being 71) is inserted between R58 & R63 like so:
E42: What do you want to know?
R69: Who?
R67: What?
R58: Where?
R71: When?
R63: Why?
R46: Nevermind.

Is there currently, or is there a plan to add soon, a function in TSLPatcher to insert a reply or entry into a pre-existing list of others in a DLG file (such that the new entry/reply appears at a certain location causing any and all pre-existing ones to be shoved down, instead of just adding one to the bottom of the list)?


It currently always puts new fields at the end of the Lists/Structs when adding new fields to a GFF file. It can perhaps currently be accomplished by some convoluted use of tokens to shuffle the list, but I'm not sure if all the required functionality for that is there since I haven't looked into it.

I suppose I could add it to the todo-list to be able to insert were in a list new structs are inserted, if I can think of a way to specify the list index in the config INI file. It'd have to fall back to inserting it last if the specified listindex is invalid though, to be safe.

I suppose I could add it to the todo-list to be able to insert were in a list new structs are inserted, if I can think of a way to specify the list index in the config INI file. It'd have to fall back to inserting it last if the specified listindex is invalid though, to be safe.

I would appreciate that. It would make sense, to me, to give a search index and flag to say whether the new one should appear either immediately before or just after the given index, and then fall back to adding at the end of the list if that index is not found (or even allowing multiple search indices [along with their before/after flags] to be given in order of preference before falling back to appending).

Please do not shoot me. I hope I am not repeating another question.

The only file I cannot alter with TSL Patcher is global.jrl. Did I happen to miss something?

Please do not shoot me. I hope I am not repeating another question.

The only file I cannot alter with TSL Patcher is global.jrl. Did I happen to miss something?

The global.jrl file is a GFF format file and you'll have to configure the patcher to modify it as such. There is no special "JRL" patcher functionality especially for that purpose.

Unless I remember incorrectly there should be a post somewhere in this thread that describes how you can use the TSLPatcher to insert new journal entries in an existing global.jrl file. It shouldn't be too much work if you use the GFF compare button in ChangeEdit to do most of the grunt work for you.

Thanks Stoffe -mkb-

I thought I overlooked something. :)

Lady Stoffe,

Thanks for developing the TSL Patcher. All I needed was to find the time to shift through it. I just downloaded your latest version, and I am very glad you kept up with it's development. This program has helped me in so many way. If I didn't have this program, I wouldn't have found the error in one of my files. Durring the installation process, I noticed I accidently created an error that was in my original version. For the life of me, I coouldn't figure out what was causing the problem. After hearing a mess of complaints, I was determined to find the error. I ran a test to see how the Patcher executes installations, and BANG there it was plain as day. Your installation log pulled out the issue right away, and I was able to fix the problem in no time.

People can rest assured that my mod is now compatible with the best of them. I was also able to cut the installation instructions down to a few lines in my readme. Since the Patcher does all of the work, I only had to add a few troubleshooting tips. :)

Thank you,
MacCorp

Hey Stoffe I haven't download the recent versions of the patcher but would you consider adding all of your various tutorials and tricks listed in this thread into a help file that comes with the patcher. Of course this is assuming you aren't doing this already.

Hey Stoffe I haven't download the recent versions of the patcher but would you consider adding all of your various tutorials and tricks listed in this thread into a help file that comes with the patcher. Of course this is assuming you aren't doing this already.

I could, provided that anyone ever reads that thing. Otherwise it would just be a dreary waste of time. People (yours truly included) do have a strange tendency of subconsciously filtering out anything with "readme" in the filename whenever browsing for new files to click on. ;)

* * *

On another note I've uploaded another minor bugfix version of the TSLPatcher, v1.2.8b8. It fixes two serious new bugs that managed to sneak into version v1.2.8b6 undetected. Those bugs would cause installation to abort if the dialog.tlk file was write protected, or when copying a 2DA line using the high() token to assign a new value to one of the columns of the new row. Thanks to DarthCyclopsRLZ for pointing out these bugs.

The new version can be downloaded via the link in the first post in this thread, as usual.

I could, provided that anyone ever reads that thing. Otherwise it would just be a dreary waste of time. People (yours truly included) do have a strange tendency of subconsciously filtering out anything with "readme" in the filename whenever browsing for new files to click on. ;)


That's why you put the tutorials in a seperate text file labeled tip's & tricks or tutorials.

Hey stoffe I encountered a problem or maybe I'm asking the patcher to do something it can't. I was trying to read files in from a subfolder within the tslpatchdata folder. If I manually set it within the install portion to read something like launcher\background.wav the installation reports an error about the game directories path. If I just browse to the folder for the file and save it in the list it continues to look in the tslpatchdata folder. So I'm wondering if it's possible to add the capability to support subfolders in the tslpatchdata folder. If it's already there then I guess this is a glitch.

Hey stoffe I encountered a problem or maybe I'm asking the patcher to do something it can't. I was trying to read files in from a subfolder within the tslpatchdata folder. If I manually set it within the install portion to read something like launcher\background.wav the installation reports an error about the game directories path.

Hmm, I'm not sure I understand what you are trying to do. All files the patcher works with (that don't already exist within the game folder) must be directly in the data folder. This is usually tslpatchdata, unless you use multiple namespaces, in which case you may optionally specify a subfolder within tslpatchdata that must then contain all files used by that namespace config (nwnnsscomp.exe and nwscript.nss excluded).

Ahh, that would explain. Would it be to much to ask to have the patcher be able to handle subfolders without the namespacing? I ask because I have discovered it is difficult to keep track of files with testing of the mod that I'm using this for. Maybe it's cause I'm trying to build a massive mod with it.

Ahh, that would explain. Would it be to much to ask to have the patcher be able to handle subfolders without the namespacing? I ask because I have discovered it is difficult to keep track of files with testing of the mod that I'm using this for. Maybe it's cause I'm trying to build a massive mod with it.

I suppose I could change it, but it would be a fair deal of work to change all the places files are accessed to make sure it can handle a more dynamic file path, and it would introduce the problem of ambiguity if there are several files named the same in different sub-folders. I'll add it to the to-do list, but since the amount of work and risk of introducing new bugs outweigh the apparent benefits (unless I'm overlooking something) it will have fairly low priority.

Not a problem. Now that I'm getting the hang of the namespace.ini feature I may not need the subfolders. Even though having it on a long term to-do list would still be nice.

Edit: ARRGGHH!!! I have found a glitch that is likely to put me on your hit list. I'm setting up the multi-installer option. On all but one of the packages I'm setting them to require a file be present in override prior to installation. However everytime I try to install the optional packages without the required file present it never prompts that I'm missing a required file. As I understand it this kind of defeats the required file part of the patcher.

On the same topic would/could you consider a option from the namespaces settings list to require a particular namespace be installed first?

Edit: ARRGGHH!!! I have found a glitch that is likely to put me on your hit list. I'm setting up the multi-installer option. On all but one of the packages I'm setting them to require a file be present in override prior to installation. However everytime I try to install the optional packages without the required file present it never prompts that I'm missing a required file. As I understand it this kind of defeats the required file part of the patcher.


Hmm, that seems to be a bug which at a quick glance seems to skip the Required file check when you use namespaces and have the patcher fetch the install location from the registry. I've done a quick fix for this and uploaded version 1.2.8b9. Hopefully that should take care of this problem. :)


On the same topic would/could you consider a option from the namespaces settings list to require a particular namespace be installed first?

Hmm, I suppose I could. Though if you have no other required files listed you can currently do this the hard way by having the namespace config in question install a blank text file in the override folder and then have the other namespace put that text file as its Required file. Though that's a bit clunky since the user would have to start the installation before noticing they can't proceed.

I could add a Required key in namespaces.ini as well which lists a file that must be present in the override folder for that Setup to be selectable in the menu, though that would only work if the installer auto-detects the install location since the user hasn't been prompted to pick where the game is at that stage.

Well it worked partially there Stoffe however it still copies files into the overide. Then it tries to patch the 2da files. When it gives it's error it also leaves the files in override. here is the installlog.


• Installation started 12/10/2006 13:21:11...
• Installing unmodified files...
• Copying file P_T3M4_0404.tga to the Override folder...
• Copying file d_armor_02.uti to the Override folder...
• Copying file d_armor_03.uti to the Override folder...
• Copying file d_armor_04.uti to the Override folder...
• Copying file d_armor_05.uti to the Override folder...
• Copying file d_armor_06.uti to the Override folder...
• Copying file d_armor_07.uti to the Override folder...
• Copying file d_armor_08.uti to the Override folder...
• Copying file d_armor_09.uti to the Override folder...
• Copying file d_armor_10.uti to the Override folder...
• Copying file d_armor_11.uti to the Override folder...
• Copying file d_armor_12.uti to the Override folder...
• Copying file d_armor_13.uti to the Override folder...
• Copying file d_armor_14.uti to the Override folder...
• Copying file d_armor_15.uti to the Override folder...
• Copying file d_hk47_02.uti to the Override folder...
• Copying file darkkendersitems.2da to the Override folder...
• Copying file dk_drdarm_01.uti to the Override folder...
• Copying file dk_drdarm_02.uti to the Override folder...
• Copying file dk_drdarm_03.uti to the Override folder...
• Copying file dk_ebo_workbench.ncs to the Override folder...
• Copying file dk_workbench.ncs to the Override folder...
• Copying file dk_workbench.utp to the Override folder...
• Copying file ii_drdhvplat_005.tga to the Override folder...
• Copying file ii_drdltplat_005.tga to the Override folder...
• Copying file ii_drdmdplat_005.tga to the Override folder...
• Copying file k_003ebo_enter.ncs to the Override folder...
• Copying file P_hk47_0201.tga to the Override folder...
• Copying file P_hk47_0202.tga to the Override folder...
• Copying file P_HK47_0203.tga to the Override folder...
• Copying file P_HK47_0204.tga to the Override folder...
• Copying file P_hk47_0205.tga to the Override folder...
• Copying file P_hk47_0301.tga to the Override folder...
• Copying file P_hk47_0302.tga to the Override folder...
• Copying file P_HK47_0303.tga to the Override folder...
• Copying file P_HK47_0304.tga to the Override folder...
• Copying file P_hk47_0305.tga to the Override folder...
• Copying file P_hk47_0401.tga to the Override folder...
• Copying file P_hk47_0402.tga to the Override folder...
• Copying file P_hk47_0403.tga to the Override folder...
• Copying file P_hk47_0404.tga to the Override folder...
• Copying file P_hk47_0405.tga to the Override folder...
• Copying file P_t3m4_0201.tga to the Override folder...
• Copying file P_t3m4_0202.tga to the Override folder...
• Copying file P_t3m4_0203.tga to the Override folder...
• Copying file P_t3m4_0204.tga to the Override folder...
• Copying file P_t3m4_0205.tga to the Override folder...
• Copying file P_T3M4_0301.tga to the Override folder...
• Copying file P_T3M4_0302.tga to the Override folder...
• Copying file P_t3m4_0303.tga to the Override folder...
• Copying file P_T3M4_0304.tga to the Override folder...
• Copying file P_t3m4_0305.tga to the Override folder...
• Copying file P_T3M4_0401.tga to the Override folder...
• Copying file P_T3M4_0402.tga to the Override folder...
• Copying file P_T3M4_0403.tga to the Override folder...
• Copying file d_armor_01.uti to the Override folder...
• Copying file P_T3M4_0405.tga to the Override folder...
• Copying file P_T3M4_0406.tga to the Override folder...
• Copying file po_pt3m4.tga to the Override folder...
• Error: You have not installed the Core files for the Holowan Plugin. Please do so then install this option. (GEN-99)

Well it worked partially there Stoffe however it still copies files into the overide. Then it tries to patch the 2da files. When it gives it's error it also leaves the files in override. here is the installlog.


Hmm, that's not right, it should check right at the beginning before proceeding to do anything else. Weird it didn't do like that with the mod I used to test the 1.2.8b9 installer with. Must have moved things around improperly. I'll have another look at it tomorrow and try to fix it more reliably that time. :)

Cool, I was hoping the installlog above would help you out.

Well it worked partially there Stoffe however it still copies files into the overide. Then it tries to patch the 2da files. When it gives it's error it also leaves the files in override.

Unless I've managed to screw up again (which in itself wouldn't be surprising) the patcher should now hopefully check for required files before doing anything no matter what. I've uploaded v1.2.8b10 which should contain this fix.

I'll give it a try and see that it works. If it doesn't I'm keeping my mouth shut though. ;)

Hey Stoffe quick question **grinning** any chance you can give lessons on this thing live over teamspeak or vent? LOL.. i want to learn and well ...sadly readme files just confuse me haha. I want to take all these old mods I have downloaded and incorporate them into a tsl patcher somehow so thatway whenever I decide to use or remove a mod its easier and I dont have to fight for days with files.

Ok, I think i followed your dialog tutorial step for step, but i get the following output when I run the setup file, what did I do wrong?


• Patch operation started...
• Copying file "upcrystals.2da" to Override folder...
• Modifying 2DA file upcrystals.2da...
• Finished updating 2DA file C:\Program Files\LucasArts\SWKotOR2\override\upcrystals.2da.
• Copying file "globalcat.2da" to Override folder...
• Modifying 2DA file globalcat.2da...
• Finished updating 2DA file C:\Program Files\LucasArts\SWKotOR2\override\globalcat.2da.
• Modifying GFF blueprints...
• Copying file "atton.dlg" to Override folder...
• Modifying GFF file atton.dlg...
• Unable to find a field label matching "AddField0" in atton.dlg, skipping...
• Unable to find a field label matching "AddField1" in atton.dlg, skipping...
• Unable to find a field label matching "AddField2" in atton.dlg, skipping...
• Unable to find a field label matching "AddField3" in atton.dlg, skipping...
• Unable to find a field label matching "AddField4" in atton.dlg, skipping...
• Unable to find a field label matching "AddField5" in atton.dlg, skipping...
• Unable to find a field label matching "AddField6" in atton.dlg, skipping...
• Unable to find a field label matching "AddField7" in atton.dlg, skipping...
• Unable to find a field label matching "AddField8" in atton.dlg, skipping...
• Unable to find a field label matching "AddField9" in atton.dlg, skipping...
• Unable to find a field label matching "AddField10" in atton.dlg, skipping...
• Unable to find a field label matching "AddField11" in atton.dlg, skipping...
• Unable to find a field label matching "AddField12" in atton.dlg, skipping...
• Unable to find a field label matching "AddField13" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY2 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY1" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY4 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY3" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY6 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY5" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY8 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY7" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY10 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY9" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY12 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY11" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY14 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY13" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY16 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY15" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY18 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY17" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY20 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY19" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY22 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY21" in atton.dlg, skipping...
• Invalid memory token 2DAMEMORY24 encountered, unable to insert a proper value in the 2da!
• Unable to find a field label matching "2DAMEMORY23" in atton.dlg, skipping...
• Finished updating GFF file atton.dlg
• Installing unmodified files...
• Copying file "pc_colo_101.uti" to the "Override" folder...
• Copying file "pc_colo_102.uti" to the "Override" folder...
• Copying file "pc_colo_103.uti" to the "Override" folder...
• Copying file "pc_colo_104.uti" to the "Override" folder...
• Copying file "pc_dblsbr100.uti" to the "Override" folder...
• Copying file "pc_dblsbr101.uti" to the "Override" folder...
• Copying file "pc_dblsbr102.uti" to the "Override" folder...
• Copying file "pc_dblsbr103.uti" to the "Override" folder...
• Copying file "pc_dblsbr104.uti" to the "Override" folder...
• Copying file "pc_lghtsbr100.uti" to the "Override" folder...
• Copying file "pc_lghtsbr101.uti" to the "Override" folder...
• Copying file "pc_lghtsbr102.uti" to the "Override" folder...
• Copying file "pc_lghtsbr103.uti" to the "Override" folder...
• Copying file "pc_lghtsbr104.uti" to the "Override" folder...
• Copying file "t7_atton01.tga" to the "Override" folder...
• Copying file "t7_atton01.txi" to the "Override" folder...
• Copying file "t7_maul01.tga" to the "Override" folder...
• Copying file "t7_maul01.txi" to the "Override" folder...
• Copying file "vis_lghtsbr01.uti" to the "Override" folder...
• Copying file "vis_lghtsbr02.uti" to the "Override" folder...
• Copying file "visas1.ncs" to the "Override" folder...
• Copying file "visas2.ncs" to the "Override" folder...
• Copying file "w_dblsbr_200.mdl" to the "Override" folder...
• Copying file "w_dblsbr_200.mdx" to the "Override" folder...
• Copying file "w_dblsbr_201.mdl" to the "Override" folder...
• Copying file "w_dblsbr_201.mdx" to the "Override" folder...
• Copying file "w_dblsbr_202.mdl" to the "Override" folder...
• Copying file "w_dblsbr_202.mdx" to the "Override" folder...
• Copying file "w_dblsbr_203.mdl" to the "Override" folder...
• Copying file "w_dblsbr_203.mdx" to the "Override" folder...
• Copying file "w_dblsbr_204.mdl" to the "Override" folder...
• Copying file "w_dblsbr_204.mdx" to the "Override" folder...
• Copying file "w_lghtsbr_101.mdl" to the "Override" folder...
• Copying file "w_lghtsbr_101.mdx" to the "Override" folder...
• Copying file "w_lghtsbr_226.mdl" to the "Override" folder...
• Copying file "w_lghtsbr_226.mdx" to the "Override" folder...
• Copying file "w_lghtsbr_228.mdl" to the "Override" folder...
• Copying file "w_lghtsbr_228.mdx" to the "Override" folder...
• Copying file "w_lghtsbr_229.mdl" to the "Override" folder...
• Copying file "w_lghtsbr_229.mdx" to the "Override" folder...
• Copying file "w_lghtsbr_230.mdl" to the "Override" folder...
• Copying file "w_lghtsbr_230.mdx" to the "Override" folder...
• Copying file "Aleek.tga" to the "Override" folder...
• Copying file "Aleek.txi" to the "Override" folder...
• Copying file "atton1.ncs" to the "Override" folder...
• Copying file "atton2.ncs" to the "Override" folder...
• Copying file "atton_lghtsbr01.uti" to the "Override" folder...
• Copying file "atton_lghtsbr02.uti" to the "Override" folder...
• Copying file "bao_dblsbr01.uti" to the "Override" folder...
• Copying file "bao_dblsbr02.uti" to the "Override" folder...
• Copying file "baodur1.ncs" to the "Override" folder...
• Copying file "baodur2.ncs" to the "Override" folder...
• Copying file "baosaber.dlg" to the "Override" folder...
• Copying file "disc_lghtsbr01.uti" to the "Override" folder...
• Copying file "disc_lghtsbr02.uti" to the "Override" folder...
• Copying file "disciple1.ncs" to the "Override" folder...
• Copying file "disciple2.ncs" to the "Override" folder...
• Copying file "iw_dblsbr_200.tga" to the "Override" folder...
• Copying file "iw_dblsbr_201.tga" to the "Override" folder...
• Copying file "iw_dblsbr_202.tga" to the "Override" folder...
• Copying file "iw_dblsbr_203.tga" to the "Override" folder...
• Copying file "iw_dblsbr_204.tga" to the "Override" folder...
• Copying file "iw_lghtsbr_101.tga" to the "Override" folder...
• Copying file "iw_lghtsbr_226.tga" to the "Override" folder...
• Copying file "iw_lghtsbr_228.tga" to the "Override" folder...
• Copying file "iw_lghtsbr_229.tga" to the "Override" folder...
• Copying file "iw_lghtsbr_230.tga" to the "Override" folder...
• Copying file "iw_SbrCrstl_100.tga" to the "Override" folder...
• Copying file "iw_SbrCrstl_101.tga" to the "Override" folder...
• Copying file "iw_SbrCrstl_102.tga" to the "Override" folder...
• Copying file "iw_SbrCrstl_103.tga" to the "Override" folder...
• Copying file "iw_SbrCrstl_104.tga" to the "Override" folder...
• Copying file "maiden1.ncs" to the "Override" folder...
• Copying file "maiden2.ncs" to the "Override" folder...
• Copying file "maiden_dblsbr01.uti" to the "Override" folder...
• Copying file "maiden_dblsbr02.uti" to the "Override" folder...
• Copying file "mira1.ncs" to the "Override" folder...
• Copying file "mira2.ncs" to the "Override" folder...
• Copying file "mira_lghtsbr01.uti" to the "Override" folder...
• Copying file "mira_lghtsbr02.uti" to the "Override" folder...
• Copying file "pc_colo_100.uti" to the "Override" folder...
• Done. All changes have been applied.


Oh what do you know, i've been working on this for 20 hours straight now.
LOL

thanks any help would be appreciated

ciao for now

Ok so I've been thinking about trying to ensure the compatibility of one of my mods with TSLRP when its released. Dashus recently explained to me that TG is apparently putting all their files (.2da's, .jrl, .dlg's, etc.) in a subfolder within the "override" folder. Now TSLPatcher could get at almost any file within that subfolder that a modder may need to edit except for .2da files. Now I was under the impression that .2da files couldn't be placed within a subfolder and still work (I thought that's why TSLPatcher didn't let you modify the location where .2da's were placed) but over here http://www.lucasforums.com/showthread.php?p=2346623#post2346623) Pavlos told me that I was wrong and, as I said, Dashus, if I read his PM right, told me that TG was doing just that. They're smart cookies so I guess I'm convinced.
What I want to know is:
If the game will read them, why can't we direct TSLPatcher to edit or place .2da files wherever we want?
Also, again if it is possible, is there some workaround? Could I manually edit the "changes.ini" to direct TSLPatcher to put my changes wherever I want?
Sorry for the long, rambling, post.

What I want to know is:
If the game will read them, why can't we direct TSLPatcher to edit or place .2da files wherever we want?


It's a sort of brute force way of resolving ambiguity as to which file to modify. If you place 2DA files (or pretty much any file) in sub-folders you allow for a condition where the ResRef (filename) of that resource is no longer unique within the override scope.

For example, if you have 20 different mods using sub-folders for their data in the override folder you could technically have 20 different appearance.2da files in your override folder, of which the game will only load one and completely ignore the rest (causing all the mods whose 2DA file was ignored to malfunction in the process). Since I don't know how the game determines which file to use if it encounters multiple copies of the same file within the override folder and its sub-folders this is a kind of forced way to resolve that ambiguity. It would be a relatively simple matter to make the TSLPatcher look inside sub-folders as well and pick the first match it finds, but handling the consequences of doing so would not be as simple.

Sub-folders within the override folder is a mixed blessing. It makes it easier to organize the files belonging to different mods, but at the same time it makes it a lot harder to detect and avoid mod conflicts where different mods modify the same standard game files (or add new files that are named the same). If you have everything in the override folder directly you'll immediately notice if a file you attempt to copy there already exists.

So in short, the TSLPatcher not looking in sub-folders is a "feature" since I couldn't think of any better ideas how to resolve such ambiguities. If anyone has a better idea of how to handle that I'm all ears. :)

Thanks for your rationale.
So what do people think is the best way for me to try and ensure compatibility with TSLRP if I'm using TSLPatcher? I guess I'll grab people's attention with the "info.rtf" file telling them if they have TSLRP installed they'll have to move the files I need to the override folder manually like Pavlos suggested on the other thread. I guess that's not a huge hassle... If someone has another idea let me know.
Thanks again stoffe

So what do people think is the best way for me to try and ensure compatibility with TSLRP if I'm using TSLPatcher?

Personally I think it would be best to wait until the Restoration Project mod has been released. It's hard to know what needs to be done from a compatibility standpoint before knowing what they have changed, what files are affected and how they are organized.

In more general terms I've always put it in the info.rtf instructions that all standard files required by the mod must be moved into the main override folder if they already exist there in sub-folders. Can't make it much more eye-catching than that, so if people still don't read the instructions it's their own fault if they mess up the game by installing the mod improperly.

Hi Stoffe :)

Is there a way to check if a field already exists in a gff file before actually adding a new one? (Like the ExclusiveColumn token for 2da's.) The point being I'd like to avoid adding the exact same field if it already exists.

Hi Stoffe :)

Is there a way to check if a field already exists in a gff file before actually adding a new one? (Like the ExclusiveColumn token for 2da's.) The point being I'd like to avoid adding the exact same field if it already exists.

I've made a quick modification to how the TSLPatcher modifies GFF files. If it now encounters a field with the same label, data type and position in the GFF tree as one it tried to add it will not add a new field, but modify the existing field instead, setting the values the new field would have been given.

The exception is structs added to a List field since they have no label, but are rather accessed by the list index they are added as, which would be dynamic if some mod has already modified the same file earlier.

I've uploaded version 1.2.9b which contains this change. See the first post (or the SWK Modding tools page) for a download link.

Same disclaimer as usual: This has only been minimally tested so use it at your own risk. It seemed to work as intended when I tried it, but there might be bugs and oversights. If you notice anything odd please let me know.

hi,

can anyone help me with this problem?
I downloaded several mods from filefront and a few of them included TSLPatcher as easy installation. those include Jedi Temple on Coruscant, HK Factory Reconstructed, and New Force Powers. the problem is that whenever i click the install mod it says "An unhandled Error Occurred!" :(

I tried to download the latest patcher and unzip it to the mod folder but it still didnt work. Right now i cant install any of the mods that include the patcher and since i dont have any moding abilities i cant do it manually. if anyone can help it would be much appreciated!!

can anyone help me with this problem?
I downloaded several mods from filefront and a few of them included TSLPatcher as easy installation. those include Jedi Temple on Coruscant, HK Factory Reconstructed, and New Force Powers. the problem is that whenever i click the install mod it says "An unhandled Error Occurred!" :(


Without knowing more exactly how you do things it's impossible to say what could be wrong. A few things:
Do you extract the downloaded mod to a folder on your harddrive or are you trying to run the installer from within a zip file?
If you extract the mod files, to where do you extract them?
If you extracted them from ZIP files did you preserve the folder structure within the archive? (WinZip has a nasty habit of flattening the folder hierarchy within an archive if you just drag and drop files out from it.)
Does your user account on the computer have write access to the KOTOR/TSL game folder?
When does that message occur? Directly when you start the installer? When you click the "Install" button in the installer? Some time during the installation process?
If you get to the start if the installation process did you select the correct destination folder if asked? It should be the KOTOR/TSL game folder, not the override folder.

1, i extracted the mod into a folder before i tried to run it
2, i extracted my files to F:Games\Star Wars KOTOR 2 stuff\HK-Factory Reconstructed (the other mods are extracted to the same place within the folder Star Wars KOTOR 2 stuff, but with a different folder name ex: F:...\...\Jedi Temple)
3, I used WinRAR and i always extract them fully, so i'm pretty sure that its not flattened or something like that
4, i have an admin account on my windows xp (as opposed to limited) so i should have full access. and i installed the star wars games from this account
5, the error occurrs right after i click the install button in the installer. it doesnt even ask for my game folder
6, i never got to that part because i think the error happens right before it asks me, but i know its the game folder and not the override that i should be inputing

Its happening to my KOTOR I mods now too. i cant use the super skip taris mod and its the same error. hope this helps

5, the error occurrs right after i click the install button in the installer. it doesnt even ask for my game folder

Hmm, weird. Does the confirmation dialog box appear after you click the Install button? Does the mod info text box get cleared and any line posted in the progress log there, or does it crash before anything else seemingly happens?

You could try opening the changes.ini file found inside the tslpatchdata folder of the mod you try to install, and under the [Settings] section change the value of the PlaintextLog key from 0 to 1, save and then try to run the installer again. Does that make any difference?

Thanks!!!!!!! :) :D

its working now! much appreciated!!

just so you know, the error occured when the installer just began installing, so there was one line of words displayed.

again, thanks so much!! :D

Err... excuse me, wanted to ask something about TSL Patcher.
Actually, it's about the .2da files.

I have difficulty in using the ChangesEdit, about adding new lines for .2da files. Here's the case. I want the TSL patcher to create new lines for the .2da files (spells, upcrystals, and baseitems), so I choose the .2da files selection on the changes.ini tree. After that I add the .2da files I wrote above. Then it shows a blank modifier. I have read the readme file, and it tell me about comparing something. So I've tried to compare by clicking the "finger button" on the TSL patcher.

After that, the "Select ORIGINAL .2da to compare against" window appear. So I choose the upcrystal.2da that places in my Override folder. Then the "Select MODIFIED .2da to compare against ORIGINAL" window appear. So I choose the upcrystal.2da from the mod I have in the TSL Patcher folder.

After that it shows a bunch of lines. From there, I don't understand what to do next. How to make the installer add a new lines for the mod each time it's installed? I'm getting confused at this...

Thank you very much for your time... and your help. :)

Hi stoffe :)

I have some questions about using TSLP for integrating dialog files. (I absolutely love this idea, btw). I used the meditation.rar file that you supplied as an example, So...

From what I gather, if the parent of the branch you want to add is an entry the Path var would be EntryList\<entry#>\RepliesList

What is the Path var syntax if the parent is a reply?
What is the Path var syntax if the branch you want to add is in the StartingList?

One last thing. I noticed you pretty much hard coded the entry and reply indexes into the changes.ini file. Suppose for arguments sake, that these indexes already existed (as in someone had already added to the dialog file). Is there a token to determine the count of the EntryList and ReplyList? Or does TSLP check for this and adjust as needed?

From what I gather, if the parent of the branch you want to add is an entry the Path var would be EntryList\<entry#>\RepliesList

What is the Path var syntax if the parent is a reply?
What is the Path var syntax if the branch you want to add is in the StartingList?


The RepliesList field under each Entry struct in the EntryList contains an index link to a struct in the ReplyList for each Reply that comes below that Entry.

The EntriesList field under each Reply struct in the ReplyList contains an index link to a struct in the EntryList for each Entry that comes below that Reply.

So, to add a new Reply node below an existing Entry in the DLG file, you find the list index of the parent Entry (#) within the EntryList and set the parent like EntryList\#\RepliesList for your new node.

To add a new Entry node below an existing Reply in the DLG file you find the list index of the parent Reply (#) within the ReplyList and set the parent like ReplyList\#\EntriesList for your new node.

Consequently, since the patcher needs to know the index of the parent node in the ReplyList or EntryList this means the patching will fail if the user has a heavily modified version of the DLG file in their install destination (override or ERF/RIM file) since those indexes may no longer exist, or they may have been renumbered if a DLG editor that doesn't preserve the indexing order of the nodes was used to modify it.

In other words this isn't as safe to do as for example TLK or 2DA patching since it assumes a certain structure of the source file but has no way of verifying if this actually is the case, but in the instances that it does work it should save the user some trouble having to merge things manually. :)



One last thing. I noticed you pretty much hard coded the entry and reply indexes into the changes.ini file.

If you mean the Value of the Index fields those aren't really hardcoded, since the values assigned when the fields are created will be overwritten further down, during the convoluted modifying of the fields that have been added before.

For example, if you look at these modifiers (relevant parts highlighted):

[gff_kreia_Index_0]
FieldType=DWORD
Label=Index
Value=738
2DAMEMORY8=!FieldPath


[gff_kreia_ReplyList_738_0]
FieldType=Struct
Path=ReplyList
Label=
TypeId=ListIndex
AddField0=gff_kreia_Listener_3
AddField1=gff_kreia_AnimList_3
AddField2=gff_kreia_Text_3
AddField3=gff_kreia_VO_ResRef_3
AddField4=gff_kreia_Script_3
AddField5=gff_kreia_Delay_3
AddField6=gff_kreia_Comment_3
AddField7=gff_kreia_Sound_3
AddField8=gff_kreia_Quest_3
AddField9=gff_kreia_PlotIndex_3
AddField10=gff_kreia_PlotXPPercentage_3
AddField11=gff_kreia_WaitFlags_3
AddField12=gff_kreia_CameraAngle_3
AddField13=gff_kreia_FadeType_3
AddField14=gff_kreia_EntriesList_0
AddField15=gff_kreia_SoundExists_3
AddField16=gff_kreia_ActionParam1_3
AddField17=gff_kreia_ActionParam1b_3
AddField18=gff_kreia_ActionParam2_3
AddField19=gff_kreia_ActionParam2b_3
AddField20=gff_kreia_ActionParam3_3
AddField21=gff_kreia_ActionParam3b_3
AddField22=gff_kreia_ActionParam4_3
AddField23=gff_kreia_ActionParam4b_3
AddField24=gff_kreia_ActionParam5_3
AddField25=gff_kreia_ActionParam5b_3
AddField26=gff_kreia_ActionParamStrA_3
AddField27=gff_kreia_ActionParamStrB_3
AddField28=gff_kreia_AlienRaceNode_3
AddField29=gff_kreia_CamVidEffect_3
AddField30=gff_kreia_Changed_3
AddField31=gff_kreia_Emotion_3
AddField32=gff_kreia_FacialAnim_3
AddField33=gff_kreia_NodeID_3
AddField34=gff_kreia_NodeUnskippable_3
AddField35=gff_kreia_PostProcNode_3
AddField36=gff_kreia_RecordNoOverri_3
AddField37=gff_kreia_RecordVO_3
AddField38=gff_kreia_Script2_3
AddField39=gff_kreia_VOTextChanged_3
AddField40=gff_kreia_CameraID_3
AddField41=gff_kreia_RecordNoVOOverri_3
2DAMEMORY7=ListIndex


[kreia.dlg]
AddField0=gff_kreia_RepliesList_3_0
AddField1=gff_kreia_EntryList_627_0
AddField2=gff_kreia_EntryList_628_0
AddField3=gff_kreia_EntryList_629_0
AddField4=gff_kreia_ReplyList_738_0
AddField5=gff_kreia_ReplyList_739_0
AddField6=gff_kreia_ReplyList_740_0
2DAMEMORY2=2DAMEMORY1
2DAMEMORY4=2DAMEMORY3
2DAMEMORY6=2DAMEMORY5
2DAMEMORY8=2DAMEMORY7
2DAMEMORY10=2DAMEMORY9
2DAMEMORY12=2DAMEMORY11


In the first one, the line 2DAMEMORY8=!FieldPath stores the full field path to the new Reply-link node that was just added in the 2DAMEMORY8 token (needed since you don't know beforehand what list index it will end up as).

In the second one, the line 2DAMEMORY7=ListIndex stores the list index the new struct that is inserted ends up as in the ReplyList in the 2DAMEMORY7 token.

In the third one, the line 2DAMEMORY8=2DAMEMORY7 links these two stored pieces of info together. It assigns the value in the 2DAMEMORY7 token (the list index) to the field at the path stored in the 2DAMEMORY8 token.

For example, say that the RepliesList link to your new Reply node that is added to entry 587 in the EntryList gets added as EntryList\587\RepliesList\4\Index. And that your new reply node struct added to the ReplyList (which the previous link should point to) gets added at list index 600 in the Reply List.

Then the third highlighted modifier above would read, when parsed by the patcher:
Assign the value 600 to the field EntryList\587\RepliesList\4\Index

Thus the initial value that was assigned when the Index field was created above (738) would be overwritten by the actual value (600) soon afterwards, and it's no longer hardcoded but dynamic. :)

Very convoluted and primitive, but at least it works (in the cases I've tested) until someone can figure out a better way of doing it. :)

(Wish I had used XML instead of INI as format for the patcher config file back when I first made it. Would have made it a lot easier to structure this sort of thing logically in the configuration. :( )

Umm...sorry about that entire line of questioning. I completely missed a post where you explained about using the gff compare function. When I asked those questions I thought I was going to have to do it by hand (wasn't questioning your coding).

Still, thanks for the reply, though :)

I've uploaded TSLPatcher v1.2.10b1 and ChangeEdit v1.0.5b1 to correct a problem I just noticed, download link is in the first post in this thread as usual.

These updates fixes a bug/oversight with ExoString fields and ExoLocString field substrings containing linefeeds or carriage return characters when patching GFF format files. Earlier the INI file would get messed up and only the text before the first LF/CR would be added to the GFF files. Now all the text should be properly added even with multiple paragraphs.

INI config files already broken by this bug (*nudge* Brotherhood of Shadow mod *nudge*) can be fixed manually with a text editor by removing the newlines so all the text in following a lang# key is on the same line in the INI file, and then insert <#LF#> where the newlines should be. (Make sure you turn off word/line wrapping in the text editor first) E.g this...

lang0=The quick brown fox

jumps over the lazy dog!

...would have to be changed to look like this:

lang0=The quick brown fox<#LF#><#LF#>jumps over the lazy dog!

...which would end up like this in the GFF substring after patching the file:

The quick brown fox

jumps over the lazy dog

If you don't do this fix, the text in the GFF substring after patching would just be:

The quick brown fox



Note: This only applies to changes.ini files that have already been broken due to this bug. ChangeEdit has been updated to handle this automatically when creating new files, or creating new GFF file modifiers in an existing one.

Hi I'm using the patcher (newest version) and trying to assing a new value thourgh a memory token for an item's BaseItem field. What I want is to copy an existent line on baseitems.2da and modify somethings inside it and I want the memory token to save the new line by its number in the index. Then an item will get modified and use that token as the value for it's BaseItem field. However everytime I do it the field ends up with the original value (that's the value of the line that's being copied) instead of the new one. Here's the relevant part of the code (since it's too large to post here):

(Tlk StrRef and other bunch of things)...

[2DAList]
(...)
Table1=baseitems.2da
(...)


[GFFList]
(...)
File13=w_melee_19.uti

(...)

[baseitems.2da]
(...)
CopyRow1=baseitems_add_ryyk_blade
(...)

[baseitems_add_ryyk_blade]
RowIndex=4
ExclusiveColumn=label
2DAMEMORY137=RowLabel
label=Ryyk_Blade
name=StrRef431
damageflags=4
numdice=3
dietoroll=4
critthreat=1
crithitmult=3
reqfeat0=2DAMEMORY27
specfeat=2DAMEMORY29
focfeat=2DAMEMORY28

That created the new line, it works, the new line appears as I wanted it on baseitems.2da, however when I read the log it says that what's being saved is the value "4" (original value), instead of the new value which should be "107", at the end of the table.

(...)
[w_melee_19.uti]
BaseItem=2DAMEMORY137
LocalizedName(strref)=StrRef431
DescIdentified(strref)=StrRef432
UpgradeLevel=3
!ReplaceFile=1

That modifies the weapon, however as the value being stored is "4" instead of the new line...Well it doesn't work.

I've taken a look to Chainz Bao Dur armor, but he adds a new line from scratch instead of copying it.

So any thoughts?

EDIT: Never mind problem solved. I had to put the 2DAMEMORY creation after I set the label for the base item. Then it stored it correctly. Thanks anyway.

trying to assing a new value thourgh a memory token for an item's BaseItem field. What I want is to copy an existent line on baseitems.2da and modify somethings inside it and I want the memory token to save the new line by its number in the index. Then an item will get modified and use that token as the value for it's BaseItem field.

The problem is with the line...

2DAMEMORY137=RowLabel

...as this will save the value in the (Row Label) column, while the baseitems.2da file is indexed by line number. So you should use...

2DAMEMORY137=RowIndex

...instead, since this will save the line number your new line gets added as in the token.



Generally there are three key values you can use to identify a particular row in most cases:

RowIndex - the line number of the row
RowLabel - The label of the row, displayed as a (Row Label) column in KotorTool.
LabelIndex - The value in the label column of the row. This obviously only works with 2DA files that have a label column, and is mostly used for editing/copying existing rows where you don't know what the row label or line number is (usually since the target lines were dynamically added by a mod earlier).

The problem is with the line...

2DAMEMORY137=RowLabel

...as this will save the value in the (Row Label) column, while the baseitems.2da file is indexed by line number. So you should use...

2DAMEMORY137=RowIndex

...instead, since this will save the line number your new line gets added as in the token.



Generally there are three key values you can use to identify a particular row in most cases:

RowIndex - the line number of the row
RowLabel - The label of the row, displayed as a (Row Label) column in KotorTool.
LabelIndex - The value in the label column of the row. This obviously only works with 2DA files that have a label column, and is mostly used for editing/copying existing rows where you don't know what the row label or line number is (usually since the target lines were dynamically added by a mod earlier).
Thanks stoffe, though as I said it worked with RowLabel I just had to put the 2DAMEMORY line after the itemtype was created.