TSLPatcher v1.2.10b1 (mod installer)

[stoffe]

You've won me over with just these few lines. Hellish work or no, given the possibilities with this function.. oh yeah.. I'm feeling the urge to "tinker"

 

Thanks so much stoffe... If I run into any bugs I'll let ya' know

 

If you want to play with it these are rougly the steps you go through to make it work:

1. Start with a clean copy of the DLG file, and add your new dialog entries to it like usual with the DLGEditor. Store this somewhere else, since it will not be part of the install.
    
    
   
2. Write down somewhere the Entry node and Reply node indexes (displayed at the top of the edit area in tk102s DLGEditor) for your new nodes and how they connect to eachother.
    
    
   
3. Extract another clean copy of the same DLG file and put it into the tslpatchdata folder.
    
    
   
4. Use the GFF Compare function in ChangeEdit to compare your modified DLG file with the unaltered version, creating AddField modifiers for the new fields.
    
    
   
5. Edit the generated modifiers to replace the necessary static values with dynamic, token-based ones to make it work with already modified DLG files. For each struct added to the EntryList or ReplyList and their corresponding EntriesList and RepliesList, set the TypeId field to "ListIndex". This sets the Struct field's type id to the same value as the list index it will be added as, which seems to be how DLG files work.
    
    
   
6. Also for each struct added to the EntryList or ReplyList (but not EntriesList or RepliesList), put a 2DAMEMORY token into the "Index token" input box. This will store the resulting list index the struct i added as in a token which will be used later to link the nodes together. Write down (preferably in the same place as step 2 above) which token is used for which entry/reply.
    
    
   
7. For each "Index" field inside the structs added to the EntriesList and RepliesList of an Entry/Reply struct, put the name of a 2DAMEMORY token into the Path token input box. Write down which replies/entries which token is used.
    
    
   
8. The data stored in the two above steps will be needed in order to link the new entry and reply nodes together. The "Index" field tokens assigned in the EntriesList and RepliesList structs now holds the GFF field paths to the fields which needs to have their values updated, while the tokens assigned in the EntryList and ReplyList structs hold the values that need to be assigned to those fields. Which brings us to the next step...
    
    
   
9. Go back out to the main "Modify GFF Field" panel in the ChangeEdit main window, and add new modifiers here. Set the "GFF Field" input box to the name of a 2DAMEMORY token which holds the path to one of the Index fields, and the "Value" input box to the name of the 2DAMEMORY token which holds the Entry/Reply List Index it should link to.
   

 

Using the requested mod linked to as example, the info I wrote down to keep track of how things were connected looked like:

(Remember: The index numbers below match the numbers in the auto-generated modifier labels, but not necessarily those in the DLG file after it has been modified, since it's inserted dynamically. (Except E587))

Entry 587 (standard, static)
   --> Reply 738 (first new, dynamic)
       --> Entry 627 (dynamic)
           --> Reply 739
               --> Entry 628
           --> Reply 740
               --> Entry 629


[u]EntryList 587:[/u] (exists in standard DLG, insertion point)
RepliesList: 738 (2DAMEMORY8 = FieldPath) (new added to RepliesList)


[u]ReplyList 738:[/u]	 (2DAMEMORY7 = ListIndex)
EntriesList: 627 (2DAMEMORY6 = FieldPath)


[u]EntryList 627:[/u] (2DAMEMORY5 = ListIndex)
RepliesList: 739 (2DAMEMORY12 = FieldPath)
RepliesList: 740 (2DAMEMORY4 = FieldPath)


[u]ReplyList 739[/u]: (2DAMEMORY11 = ListIndex)
EntriesList: 628 (2DAMEMORY10 = FieldPath)


[u]EntryList 628:[/u] (2DAMEMORY9 = ListIndex)
(END)


[u]ReplyList 740:[/u] (2DAMEMORY3 = ListIndex)
EntriesList: 629 (2DAMEMORY2 = FieldPath)


[u]EntryList 629:[/u] (2DAMEMORY1 = ListIndex)
(END)

...from which you can see that things need to be connected like:

 

(path+label)=(listindex)

2DAMEMORY2=2DAMEMORY1

2DAMEMORY4=2DAMEMORY3

2DAMEMORY6=2DAMEMORY5

2DAMEMORY8=2DAMEMORY7

2DAMEMORY10=2DAMEMORY9

2DAMEMORY12=2DAMEMORY11

 

This is since dialog nodes are connected like:

(? = a listindex, irrelevant to keep track of here since it isn't referenced from anywhere else.)

EntryList\587\RepliesList\?\Index=738 --> ReplyList\738\EntriesList\?\Index=627 --> EntryList\627\RepliesList\?\Index=739 --> ReplyList\739\EntriesList\?\Index=628 --> EntryList\628

 

...which when written with the token values from above to make it dynamic would be like:

2DAMEMORY8=2DAMEMORY7 --> 2DAMEMORY6=2DAMEMORY5 --> 2DAMEMORY12=2DAMEMORY11 --> 2DAMEMORY10=2DAMEMORY9 -->

 

As said, quite load of manual work involved to make it work at this stage.

[Lit Ridl]

STOFFE!!! STOFFE!!! STOFFE!!!

Help me, please!

I have to make installer for live planets (02,03,04) but I have problem with dialog.tlk.

Here is my situation:

I have to modify row in dialog.tlk with number 42502 (503, 504), they are clear now, I want to insert text in them, not to create new but how???

Help, please!!!!

[stoffe]

I have to make installer for live planets (02,03,04) but I have problem with dialog.tlk.

I have to modify row in dialog.tlk with number 42502 (503, 504), they are clear now, I want to insert text in them, not to create new but how???

 

The TSLPatcher currently won't update existing lines in dialog.tlk in order to reduce chances of incompatibility (if several mods change the same entry) and make it easier to find and undo changes. It will just add new entries at the end of the file (unless an identical entry already exists in the file, in which case the existing one will be used instead of adding a new duplicate).

 

This usually isn't a problem though, you just add new entries with your text, store their resulting StrRef values in a StrRef# token and then insert that token into the 2DA file, GFF file or script that needs to reference those dialog.tlk entries.

 

For example, if you want to add a new planet to the Live_Planet_02, Live_Planet_03 and Live_Planet_04 rows in planetary.2da with a new name and description, you'd set things up like (irrelevant parts skipped):

 

[TLKList]
StrRef0=0
StrRef1=1
StrRef2=2
StrRef3=3
StrRef4=4
StrRef5=5


[2DAList]
Table0=planetary.2da


[planetary.2da]
ChangeRow0=2da_mod_PlanetOfTheMonkeys
ChangeRow1=2da_mod_AnimalPlanet
ChangeRow2=2da_mod_ForbiddenPlanet


[2da_mod_PlanetOfTheMonkeys]
LabelIndex=Live_Planet_02
name=StrRef0
description=StrRef1
model=planet_02


[2da_mod_AnimalPlanet]
LabelIndex=Live_Planet_03
name=StrRef2
description=StrRef3
model=planet_03


[2da_mod_ForbiddenPlanet]
LabelIndex=Live_Planet_04
name=StrRef4
description=StrRef5
model=planet_04

 

...in the changes.ini file, while the append.tlk file contains two entries for each planet, the name of the planet and the description. This would add the six new entries to the dialog.tlk file of the user if they don't already exist, and set the proper StrRef values referring to then in the name and description columns of the Live_Planet_02, Live_Planet_03 and Live_Planet_04 rows in planetary.2da. (I assume this is for KotOR1, since there is no liveplanet 2 in TSL)

[Lit Ridl]

So, I have no time to wait and I've made chnges in planetary.2da:)

It is interesting that my head supports this.. I guessed it myself (but though I 'm stupid when I found no way to edit rows), so that 2da way was only one thing I may do... Thanks for notifing about impossibilities!!!

[stoffe]

TSLPatcher v1.2.8 has now been uploaded (link in the first page of this thread as usual). This version changes a few things about how the handling of ERF files work to make it more useful. The usual warnings apply, I've tested it for a few horus and it seems to work, but I cannot guarantee that it works without problems in all situations and circumstances. If you notice anything behaving incorrectly please let me know so I can attempt to fix it.

 

 

These are the noteworthy changes:

 

1. TSLPatcher can now handle RIM format files as well. They work in exactly the same was as using ERF files as installation destination does.
    
    
   
2. TSLPatcher is now able to directly modify any ERF (ERF, MOD etc) and RIM format file located within the game folder or any of its subfolders. GFF files can either be modified in place if they exist within such an archive file, or inserted if they don't already exist or if the Replace setting is checked.
    
    
   
3. The order of processing for the InstallList has been moved to earlier during the installation process. The phases of installation now occur as: TLK appending, Install List, 2DA editing, GFF editing, Compile List, SSF editing. This allows placing new ERF/MOD/RIM files into their proper folder before any GFF needs to be modified in or saved into them, or NCS files need to be saved into them.
   

 

Modify/save GFF files inside ERF/RIM archives you specify the relative path (from the game folder) of where the file is, followed by the name of the file, as install destination. If, for example, you want to modify a GFF file inside the myarea.rim file located in the Modules folder, you set the Destination field to Modules\myarea.rim. (To install files into the override folder as usual just leave the Destination field blank, like before.)

 

Note that you still need a copy of the GFF file you want to modify in the tslpatchdata even if you are 100% sure it already exists within the destination ERF/RIM (like in one of your own custom modules), since it needs that redundancy in case the file is missing (since it can't know how sure you are ).

 

Recompiled NCS files can be inserted into existing ERF/RIM files in a similar manner, but will never modify existing NCS files with the same name at the destination. Existing files within the ERF/RIM will either be overwritten or skipped, depending on if you've check the Replace checkbox.

 

ERF/RIM files having their content modified in such a way will have unaltered backup copied of them saved in the backup folder, if Backup is enabled in the settings.

[stoffe]

In case someone is interested I've uploaded TSLPatcher v1.2.8b1, a quick update since further testing and poking around the code revealed some bugs in the new functionality introduced in 1.2.8b0 that I had overlooked earlier. Aside from bugfixes, this version also changes/adds the following:

• Changed the InstallList functionality to allow installing files into existing ERF/RIM archives as well, and not just into subfolders within the game folder. This destination is set the same as you set the folder, only specify a filename at the end of the relative path (from the game folder) as well. (E.g. Modules\904mal.rim)
   
   
  
• Changed the InstallList, GFFList, SSFList and CompileList to allow renaming files from the source to install using the keys !SaveAs (to change the name the file is installed as) and !SourceFile (to specify another name than is listed for the file to copy.) These keys are added to the sections for the file they should affect. This can be used to work with multiple copies of files that are named the same but with different content (like module.ifo) in the same patcher config.
   
  This is not yet added to ChangeEdit but must be added by hand in the INI file for now. As such it's an "advanced" feature until I figure out how to squeeze it into the increasingly bloated user interface of ChangeEdit.
   
   
  
• Added a configuration summary button to the main TSLPatcher window, allowing the prospective mod user to view a brief overview of which files the TSLPatcher is set up to modify, and other relevant info, before deciding whether to proceed with installation.
  

 

(These changes along with those in the previous version aim to make it possible to modify modules more directly without having to put mod-specific files into the override folder or re-package the whole thing if just some minor things have changed.

 

It should hopefully also help make mod edits a bit easier to make compatible between multiple mods since it will edit the files already present in the module RIM/MOD files (unless you tell it to overwrite), and help bypass some of the naming conflicts that can be caused by putting module data in the override folder.)

 

Same warning as always: It seems to work from my own limited testing, but I can't guarantee that it does under all circumstances. If you use this and notice something out of the ordinary please let me know so I can attempt to fix it. Download link is at the first page of this thread.

[stoffe]

It seems like there is some problem with the tk102 modified version of nwnnsscomp.exe that comes with TSLPatcher currently that may cause it to crash under some circumstances while compiling a script that uses multiple include files. We are currently looking into this problem and will hopefully find out what's causing it and fix it.

 

In the meanwhile I'd suggest avoiding to use TSLPatcher in situations where it needs to recompile a script that uses include files, since compilation during install may not work for all users depending on where their game is installed and where they run the patcher-installer from.

 

Hopefully a fix shouldn't take too long.

[Karstedt]

I have a question/request. I haven't been able to figure out how to insert a line at the top (or anywhere other than the bottom for that matter) of a .2da file with TSL patcher. Is it possible? Is it a feature that could be added?

 

Great tool!

[stoffe]

I have a question/request. I haven't been able to figure out how to insert a line at the top (or anywhere other than the bottom for that matter) of a .2da file with TSL patcher. Is it possible? Is it a feature that could be added?

 

It is currently not possible since I have not been able to imagine a use for it.

 

It currently always inserts new lines at the end of the file. Inserting lines anywhere else in line number indexed 2DAs (which most of the big core 2DAs, except visualeffects.2da, appear to be) will mess the file up since the indexes for all the following lines will be ruined. And for files not indexed by line number it doesn't matter where in the file a line is, so it might as well add it at the end there too.

 

Why do you need to insert lines in any other position than at the end?

[Karstedt]

I figured out that the first entry in upgrade.2da wll dissapear on area/load/save transitions (that appears to be the cause of the dissapearing Rubat crystal I've been posting about). So my solution is to insert a blank entry at line 0.

 

I've been fooling around with TSL patcher to post a patch to do this, but can't insert a line. I've resorted to having it simply change line 0 to a useless entry and make line 203 (the old Rubat line that had a Z added to make it do nothing) the entry for the Rubat crystal. However, being a stickler about changing as little as possible, it bugs that I might be messing up the sort order on the upgrade selection screen (I know, nobody but me probably cares). I don't know if simply changing the "Row Label" will alter the sort order (so I can maintain the original order in wich the crystals are displayed).

 

Anyway, there you go; a use for inserting rows at places other than the bottom. I'll probably just say screw the sort order and set it up the way I described, though I thought I might mention it as a potentially usefull feature to add.

[stoffe]

I figured out that the first entry in upgrade.2da wll dissapear on area/load/save transitions (that appears to be the cause of the dissapearing Rubat crystal I've been posting about). So my solution is to insert a blank entry at line 0.

(...snip...)

Anyway, there you go; a use for inserting rows at places other than the bottom.

 

Hmm, while I doubt it's a feature that will see much use I suppose it wouldn't hurt to put in a "insert line" modifier for 2DAs. It will have to wait until tomorrow though since it requires expanding a bit upon the 2DA-handling class I'm currently using for the patcher. It can only can do essentially what TSLPatcher is currently capable of since it was written for that purpose.

 

Don't think it will be that much trouble fixing, but it might take a bit of time to do.

[Karstedt]

Eeep...

 

I wouldn't spend too much time working on that feature

 

After further testing I've decided (like all others before me I'm guessing) that inserting lines is not the best way to create a distributable patch. Although in theory I still like the idea...

 

Hope I didn't cause too much of a fuss.

 

Edit: Hmmm I keep coming back to this. Now I'm making a grenade mod and I've got it mostly ready to go, but I want a good way to get the sort order right for the lab station. I want each grenade to appear under the regular one of its type (IE frag grenade, frag grenade mark II etc), instead of just having all the grenades listed at the bottom.

 

When I manually edit the .2da, I'd just insert lines at the appropriate spots and hit renumber all rows when I'm done. I'm trying to figure out a way to achive the same effect with TSL Patcher.

 

Anyway, if you have any thoughts on how to make such a thing happen... I think the sort order goes off the row index and not the "RowLabel". So if you can re-index the rows you could still auto assign the next highest number availible for the "RowLabel" (IE Index 34,Label 306) and get the item to appear in the order you want.

 

If that makes any sense

[stoffe]

I have uploaded TSLPatcher v1.2.8b2, which fixes a sneaky bug in the RIM handling class. Apparently the RIM specification I used contained incorrect information about where certain things were stored, causing the game to have trouble loading RIM files modified by the TSLPatcher (though KotorTool had no such problems loading the modified files).

 

This version fixes this problem, and the game can now load modified RIMs without problems as far as my testing shows. (Lesson learned: Don't rely on other tools rather than the game to verify that things load properly).

 

No other changes (that I can remember) in this version, the above bug was serious enough to get a version of its own. Still looking into the odd problems with recompiling scripts using multiple include files under some circumstances. Hopefully a fix for that will be made soon as well.

[Darkkender]

Karstedt I think I know why you are having problems with 2da files. Never ever use the renumber feature in Kotor Tool. Many of the 2da files start at line "0" since 2DA stands for Two Dimensional Array and entry "0" is where arrays start in programming. Now what throws things off is there are some 2da's that do begin at line number "1". Fred had been meaning to remove the Renumber line's entries as people would read through the 2da files and enter the wrong line number to reference in there mods. So if your problem with upgrade.2da stems from renumbering the lines in a 2da file then I guess this post has a use.

[Master Kavar]

I seem to be having a problem with the installer, as far as I know the problem is with my computer because I haven't seen it affect anyone else. But it only happens with newly (re-)released mods, like RedHawke's Ord Mandell, or the recruit Dustil mod, as you can see:

 

 

When this problem occurs, the screen has no scroll bars, and the Install button is gone. I checked but all older mods that use the installer still work fine.

 

So...little help please? ^-^;

[stoffe]

I seem to be having a problem with the installer, as far as I know the problem is with my computer because I haven't seen it affect anyone else. But it only happens with newly (re-)released mods, like RedHawke's Ord Mandell, or the recruit Dustil mod, as you can see:

 

 

When this problem occurs, the screen has no scroll bars, and the Install button is gone. I checked but all older mods that use the installer still work fine.

 

This problem has been reported by a handful of other people before, but since I can't recreate the problem on my computer it's very difficult to figure out what is causing it, and I can't test to see if changes I've made have done anything to get rid of the problem. It looks like this on my computer.

 

It's some odd glitch with the user interface that for some unknown reason causes the panel with the buttons and text area to resize and become larger than the window they are contained in. The buttons and scrollbars are still there, but they have ended up outside the window area and thus can't be seen. Thus you can "click" the install button by using its hotkey instead as a workaround. (ALT-S if I remember correctly).

 

However, since you can make this problem happen I'd appreciate if you'd be willing to take some time to test a potential fix version and see if it resolves the problem. It won't retroactively fix existing mods unless you replace the installer EXE coming with those mods with the latest version (which can be done without any problem since no configuration is stored in the EXE directly). So if you could download the test version, put it in the install folder of a mod with this problem, run it instead of the normal installer and see if the problem remains...

[Master Kavar]

Sure thing, just direct me to the test version and I'll give it a go, it's the least I can do for enjoying my multitude of patachable mods ^_^. Thanks for responding to me so quickly.

[stoffe]

Sure thing, just direct me to the test version and I'll give it a go, it's the least I can do for enjoying my multitude of patachable mods ^_^. Thanks for responding to me so quickly.

 

Thanks. Download this file, unpack it into the folder of a mod you had problems with (the folder that contains the tslpatchdata folder) and run TSLPatcher.exe and see if the window still appears messed up, and let me know how it works.

[Master Kavar]

It worked just like a charm for the mod I wanted. I'm still going to test it on a couple others though a bit later.

[Darkkender]

Hey Stoffe, since I don't know how you have actually programmed the workspace area that is displayed I'm not 100% positive on a solution. However it appears you are using win 2000, and at least the most recent posted user problem is posted by a user with win XP. I know XP has had some minor GUI interface changes from 2000 that involve the autodetection that really get fouled up if you are programming from 2000 or earlier for XP. What I might recomend as a fix is to set a fixed viewing area that can be handled by a 800x600 windowed area. Within that viewing area for the text set it to auto wordwrap instead of being side scrollable. This will force the system to accept certain GUI aspects rather than allowing autodetects to set the area. Also while being only a 1% chance there might be issues between European versions of windows and US versions enough so that it is causing the conflict. I do highly doubt this last tidbit however it is squishysoft. Also since I'm unsure what language or compiler TSLPatcher is built on but it could just be that you have not updated the OS Platform SDK or the libraries to support Win XP.

[stoffe]

since I don't know how you have actually programmed the workspace area that is displayed I'm not 100% positive on a solution. However it appears you are using win 2000, and at least the most recent posted user problem is posted by a user with win XP.

 

I'm using Windows XP Home Edition on my current machine, and running Windows XP Professional on my old machine (I just don't like the gaudy Win XP GUI style so I run classic style anyway ). I've tested TSLPatcher on both and the GUI glitch appears on neither with any of the versions it's been reported for. The peculiar thing with it is that only a handful (6 people so far) have reported experiencing this glitch, and I haven't been able to make any connection between the cases as to why it occurs.

 

I'm using Delphi 7 to make TSLPatcher, and I suspect it's some peculiar bug in the VCL GUI libraries that is causing this glitch. It certainly wouldn't be the first oddity in the VCL forms classes. The way things are set up this shouldn't be able to happen. The buttons and RichEdit controls are placed on a panel, which in turn is set to automatically scale with the client area (active window space). In most cases it does, but in these handful of cases the panel becomes much larger than the window area for some unknown reason.

 

Anyway, in the attempted fix I posted yesterday I manually resize the panel to match the window area whenever the main window is opened or resized, hopefully that will do the trick. An ugly workaround that shouldn't be necessary, but I've exhausted all other options I could think of previously and apparently the problem didn't go away since Master Kavar had it with a fairly recent version.

[stoffe]

I've uploaded TSLPatcher version 1.2.8b3, which only contains a couple of bug fixes and no new functions.

 

This will hopefully fix the problem with nwnnsscomp crashes when recompiling scripts using include files. As far as my testing has shown scripts previously known to cause trouble now compiled fine. Huge thanks goes to tk102 for taking time to locate and fix this bug with nwnnsscomp.

 

This version also includes a workaround which will hopefully counteract the weird user interface glitch that a handful of people experienced, which would push the buttons and text area scrollsbars in the main TSLPatcher window outside the window area.

[Darkkender]

Well I guess that information shoots my theory in the foot or at least wings the toes. Of course I'm not familiar with VCL so I would be unsure as to glitches in the libraries. I keep thinking I should refresh my Pascal skills with the new OOP version called Delphi.

 

I am curious what is the default screen ratio you have set for the window? I know almost all of the Game Programming books recomend building tools with 640x480 as the default screen size even if next to nobody uses it anymore. I wonder if this technique would be any help at all.

[oldflash]

Could be possible to blame video card's drivers (or utilities)? For me the patcher works perfect but I saw in Master Kavar's pic a little icon in titlebar (right side) and from what I know some video drivers/utilities use to change screen settings.

[stoffe]

Here is another "quick how-to" guide for how the TSLPatcher could be used to accomplish certain modding tasks. Hopefully these examples will make it a bit clearer how things fit together.

 

* * *

 

New Player Appearance Mod:

To use TSLPatcher to install a mod adding a new player appearance to the game you'd roughly follow these steps. This assumes that you have already added the new lines required to appearance.2da, heads.2da and portraits.2da and created your textures and models. This is not a guide for how you create a new player appearance mod, only for how you could make an installer for such a mod.

 

ChangeEdit main window

 

1. Create a folder to contain your mod and copy TSLPatcher.exe to this folder. You may rename the EXE file to something more intuitive if you wish, like "Install Mod.exe" or whatever you like.
    
    
   
2. Create a new folder inside this folder alongside the TSLPatcher.exe, name it exactly tslpatchdata. Copy the models, textures and any other files belonging to your mod into this folder, except any 2DA files used.
    
    
   
3. Use KotorTool to extract unaltered copies of the files appearance.2da, heads.2da and portraits.2da. Put these 2DA files inside the tslpatchdata folder as well.
    
    
   
4. Start ChangeEdit.exe and chose New... from the File menu to create a new config file. Save the file as changes.ini inside your tslpatchdata folder.
    
    
   
5. The Settings panel will open. In the Window caption input box, type in the name of your mod. If you want a confirmation dialog box to pop up before the installation begins when the user presses the Install mod button, type in the warning text in the Confirm message input box, or set it to N/A to prevent the box from showing.
    
   Make sure Run mode is set to Installer. If you want TSLPatcher to automatically locate the folder where the game is installed, set the Ask for game folder dropdown menu to Look up folder path in the Windows registry, and select which game your mod is for. If you use automatic game lookup you should probably use a confirm message as mentioned previously. If you pick Ask the user to select folder location an Open dialog box will show when installation starts to let the user select where to install.
    
   For debugging purposes you should leave it at Ask the user... for now, and set the Log level dropdown menu to 4. Press the Save changes button to save your settings to the config file.
    
    
   
6. Next, select the 2DA Files section in the treeview to the left, right-click on it and pick Add 2da file... in the context menu. In the box that opens, either type in heads.2da, or press the icon to the right of the input field to browse to the file if you are afraid of typos. Press OK, and the file should be added to the treeview. Select it to view its 2DA Modifications panel.
    
    
   
7. Since you have already made the necessary 2DA modifications with KotorTool or another 2DA editor, let's make use of those. Click the Compare button above the modifier list. It's the one with a finger pointing at a red blob. This will allow ChangeEdit to compare two 2DA files and automatically create modifiers for the found differences for you.
    
   In the first Open dialog box that opens, select the unaltered heads.2da file you saved in the tslpatchdata folder. This is what your changes will be compared against to figure out what has been modified.
    
   In the next Open dialog box, select the heads.2da file that has been modified for your mod. Please wait while ChangeEdit works, depending on the size of your 2DA files and how much you have changed it may take a while for it to finish working. A confirmation box will pop up once it is done.
    
    
   
8. If your mod adds just one new player appearance, ChangeEdit should now have found your new line and created an "AddRow" modifier for it. Doubleclick this modifier in the list to open its editing window.
    
   In the Label of Exclusive column dropdown menu, select head. (If there is no content in the dropdown menu you can click the icon to the right of the input box to load the column labels from a 2da file manually.) This will instruct the TSLPatcher to only add this new line if there isn't already another line in heads.2da that has the same value as this new line in the head column. If there is, no new line will be added, and the existing line will be updated instead to match the values of this AddRow modifier. This is used to prevent duplicate lines from being added to the 2DAs if the installer is run more than once.
    
   Next you will need to store the line number of this new line, so it can be properly referred to from appearance.2da's normalhead column.
    
   Temporarily storing values in TSLPatcher is done using the (poorly named) 2DAMEMORY tokens. Think of the 2DAMEMORY tokens as a series of storage containers with numeric labels stuck to them to tell them apart. 2DAMEMORY token labels are defined as 2DAMEMORY1, 2DAMEMORY2, 2DAMEMORY3 etc up to as many as you need.
    
   Working with 2DA files a 2DAMEMORY token can keep track of the line number (RowIndex) of the current line, the Row Label (RowLabel) of the current line, or the value of any column on the current line (by assigning the column label to the token).
    
   Anyway, in this case we want to keep track of the line number. Still in the Add 2DA Line editor window, select the Column input box under the Set column value section. 2DAMEMORY tokens don't show up in the dropdown menu, so you'll have to type them in by hand. Type in 2DAMEMORY1 in the Column input box. Next, select the Value input box below it and type in RowIndex.
    
   Click on the button with the right-pointing red arrow to add the token to the Column values list to the right, then close the editor window. This will save the line number of your new line in the 2DAMEMORY1 token. You will need this soon when setting up appearance.2da.
    
    
   
9. Select the 2DA Files section in the treeview again, right-click and pick Add 2da file... in the context menu. Type in or select appearance.2da. Just like you did for heads.2da, select the file in the treeview and click the Compare button above the modifier list. First select the unaltered appearance.2da file from your tslpatchdata folder, then select the appearance.2da file modified for your mod. Let ChangeEdit do the work the create the necessary modifiers.
    
    
   
10. If you've followed the standard procedure of adding a separate appearance for the Guardian, Sentinel and Consular starting classes (or Soldier/Scout/Scoundrel if it's for Kotor 1) three new modifiers should have been created to instruct TSLPatcher how to add your three new lines to the 2DA file. Doubleclick on the first one to open its editing window.
     
     
    
11. Set the Label of exclusive column dropdown menu to label, to use the label column to prevent duplicates. Make sure your new lines have unique labels if you have copy&pasted existing lines when you added them.
     
    Next locate the normalhead column in the New column values list to the right and double-click it to load it into the Set column value fields to the left. Drop down the menu of the Value field and you should find 2DAMEMORY1, the token you just assigned in the heads.2da section, in the menu. Select it and press the right-pointing red arrow button to save the changes to the normalhead value. This will ensure that the correct line number from heads.2da is used, no matter what other custom lines may already exist in that file.
     
    Further we need to save the line number of this new appearance.2da line as well, so it can be properly assigned in the portraits.2da file. In the Add column value Column field, type in 2DAMEMORY2 and in the Value box type in RowIndex and press the red right-arrow button to save. Close the editor window. Note the new numerical label used, we want to save the line number in a separate token (number 2) and not overwrite the heads.2da line number in token number 1.
     
     
    
12. Repeat the previous stage for the two other appearance.2da modifiers. Take care to assign 2DAMEMORY1 to the normalhead column for each, and to save their line numbers in a new 2DAMEMORY token (2DAMEMORY2, 2DAMEMORY3 and 2DAMEMORY4 respectively).
     
     
    
13. Memory refresher: TSLPatcher is now keeping track of 4 values for us, stored something like:
    2DAMEMORY1 - line number of new row added to heads.2da
    2DAMEMORY2 - line number of new row for Consular/Scoundrel in appearance.2da
    2DAMEMORY3 - line number for new row for Sentinel/Scout in appearance.2da
    2DAMEMORY4 - line number for new row for Guardian/Soldier in appearance.2da
     
     
    
14. Add portraits.2da to the 2DA Files section like before, and compare the unaltered version against your modded one to create modifiers. If you added one new player appearance, one new modifier should have been generated. Doubleclick it to open the editor.
     
     
    
15. Set the Exclusive column to baseresref to prevent duplicates, then find the columns appearancenumber, appearance_s and appearance_l in the column value list to the right. These columns refer to your new appearance.2da lines. Assign the values kept in the 2DAMEMORY tokens to them, assuming the above order it would be like:
    appearancenumber = 2DAMEMORY3
    appearance_s = 2DAMEMORY2
    appearance_l= 2DAMEMORY4
    Save and close the window.
     
     
    
16. That should take care of the mod compatibility parts, letting your mod play nice with most other mods that modify those same three 2DA files. Next we'll get the other files that don't need any editing to where they should be. Click on the Install Files section in the treeview. From here you can instruct TSLPatcher to copy files from the tslpatchdata into any folder, ERF or RIM file within the game folder. In this case we simply want to move the texture and model files into the override folder.
     
     
    
17. Click the Add multiple files button below the file list. It's the one that looks like a stack of documents next to the arrow buttons. This opens a window where you can either type in the name of a folder, or select a folder to get the name of with a standard Open dialog box (to reduce the risk of typos). Type in override in this box and check the Replace existing files in folder to instruct the TSLPatcher to overwrite any files in override that are named the same as your files. (They will be copied to the backup folder before being overwritten.)
     
    Click the Select button and a standard Open dialog box will open. Hold down the SHIFT/CTRL keys on your keyboard as needed to select multiple files, select your textures and models in the tslpatchdata folder and press Open to add the to the file list.
     
    Important: Do not add any files added to the 2DA Files, GFF Files, Soundset Files or Script source sections to the install list! Those files will be put in their proper place already when the TSLPatcher modifies them.
     
    Exit ChangeEdit, your config file should now be functional.
     
     
    
18. Open up WordPad (comes with Windows) and create a new RTF (Rich Text Format) document. Name this file info.rtf and save it in the tslpatchdata folder. The content of this file is the text that will be shown in the main TSLPatcher window when the installer is started, before the user presses the Install Mod button. Put whatever you like in this file, for example a readme file, or special installation instructions.
     
     
    
19. Create a new folder somewhere and copy the dialog.tlk file from your game into it. Also create an override folder inside this folder. This folder can now be used as a fake game folder, allowing you to test that your installer has been properly configured without having to risk messing with your game.
     
    Run your installer and keep an eye on the progress log for any warnings or errors being logged, indicating that something is improperly configured or some files are missing.
     
     
    
20. When everything installs without any errors, start ChangeEdit again, open your changes.ini config file, go to the Settings section and change the Log Level back to 3 to hide the debug output in the progress log. If you wish you can also set it to automatically look up the game folder in the windows registry now.
    

 

 

Summary:

The purpose of doing things like this is to improve chances of making your mod compatible with other mods that also have modified 2DA files that the prospective mod user might have installed in their game. When set up like this TSLPatcher will not overwrite any existing 2DA files found in the game. It will rather make changes to those 2DA files, preserving any changes and additions made by other mods.

 

The reason you include unaltered copies of the 2DA files in the tslpatchdata folder is for when the mod user do not already have any of those 2DA files in their override folder. In those cases TSLPatcher will first copy the missing 2DA file to the override folder, and then apply the instructed changes as usual.

 

Remember that the order you add the 2DA files is important, since you must have your heads.2da line before you can refer to it in appearance.2da, and you must have your appearance.2da lines already before you can refer to them in portraits.2da. Modifiers must be added in the order they are to be carried out when the TSLPatcher installs the mod.