I am using your WIP previous to the 1.2.5a(WIP 1) and don't have any problems but I am not quite at the stage of my mod development to actually use your new features yet but I will let you know.

As usual, feedback, comments and bug reports are welcome (and probably needed if this thing ever is to leave the "test" stage :) ).Just tested a simple UTC edit and integrated it into an existing .mod file with no errors. The GFF file and the ERF file both look correct.

Hey Stoffe

Sorry for the late response, first of all I accidentally, posted my request/feedback in the wrong forum, then I could'nt find my post and assumed it was lost. The I've been finishing my Master thesis, so naturally the modding was given a lower priority...Since it's done now I can get back to modding;-)

I'm happy to hear that you added the function to TSLpatcher, I will test it this afternoon (Danish Time) and let you know how it turns out...

Thanx man!

Is there a way, using TSLPatcher, to insert a structure between other ones inside a list in a GFF file (such as a .DLG file)? I've tried adding one with a certain index, but it seems to be tacked on at the end anyway, unless I didn't do it right (which is entirely possible). I'd like to be able to add a dialog choice (be it entry or reply) into the middle of others (shoving the rest down) in a list to keep them in a logical order. It'd also be nice to be able to copy a structure, modify certain fields in it, and then insert it.

Is there a way, using TSLPatcher, to insert a structure between other ones inside a list in a GFF file (such as a .DLG file)? I've tried adding one with a certain index, but it seems to be tacked on at the end anyway, unless I didn't do it right (which is entirely possible). I'd like to be able to add a dialog choice (be it entry or reply) into the middle of others (shoving the rest down) in a list to keep them in a logical order.

Currently no, adding a new Struct to a List will add it at the end. I figured this was the safest way of doing it since sometimes fields in a list are accessed by their index.

In DLG files this is definitely the case. Thus, if you would insert a new Field in the middle of the EntryList, you'd have to update all references to the EntryList in the ReplyList to the new subsequent index values to make them point to the correct dialog nodes.

Since the TSLPatcher currently doesn't have a DLG patcher, but just a generic GFF patcher, it isn't aware of such references/relations between fields to fix this automatically. (I don't think any of the GFF Editors allow you to insert a new Struct in the middle of a List either.)

I'm not sure I understand why you want to be able to insert a Field in a List in a DLG file though? The ordering of the List entries has no bearing on how the Structs are used to build the dialog tree. It's the index references between the StartingList <--> ReplyList <--> EntryList that builds the dialog tree. I think you should be able add a new entry at the end of the EntryList which appears first in the dialog tree in-game without problems.


It'd also be nice to be able to copy a structure, modify certain fields in it, and then insert it.
A bit like the "Copy 2DA Row" function, but for GFF Structs? I suppose that may be useful if you want to insert a large struct into a list with structs that all has the same field layout. I'll add it to the ToDo-list. :)

Currently no, adding a new Struct to a List will add it at the end. I figured this was the safest way of doing it since sometimes fields in a list are accessed by their index.

In DLG files this is definitely the case. Thus, if you would insert a new Field in the middle of the EntryList, you'd have to update all references to the EntryList in the ReplyList to the new subsequent index values to make them point to the correct dialog nodes.

Since the TSLPatcher currently doesn't have a DLG patcher, but just a generic GFF patcher, it isn't aware of such references/relations between fields to fix this automatically. (I don't think any of the GFF Editors allow you to insert a new Struct in the middle of a List either.)

I'm not sure I understand why you want to be able to insert a Field in a List in a DLG file though? The ordering of the List entries has no bearing on how the Structs are used to build the dialog tree. It's the index references between the StartingList <--> ReplyList <--> EntryList that builds the dialog tree. I think you should be able add a new entry at the end of the EntryList which appears first in the dialog tree in-game without problems.

Hmmm, maybe I wasn't being clear in what I wanted to do, or I'm just not understanding what you're saying yet :headbump:. What I want to do is this:
Let's say there's a dialog node in an NPC's dialog file that has a list of dialog options for the player in it. I want to be able to add another option but have it appear somewhere in the middle of the ones that are already there. Like so:

choices before adding (at EntryList\123\RepliesList):
0. Question A
1. Question B
2. Go back to start of converation
3. End conversation

choices after adding (at EntryList\123\RepliesList):
0. Question A
1. Question B
2. New Question C (linking to pre-determined ReplyList index)
3. Go back to start of converation
4. End conversation


A bit like the "Copy 2DA Row" function, but for GFF Structs? I suppose that may be useful if you want to insert a large struct into a list with structs that all has the same field layout. I'll add it to the ToDo-list. :)
Yeh, thanks.

Hello! Stoffe! :)

I have tried your TSL Patcher and it works like a charm. After reading the the readme, I have successfully created three new .2da files. Thanks for being specific. :)

I am intrested in some tech specifics, which were mostly my own curiosity. What does the TSL Patcher do to the 2DA files that is different from how the KotOR Tool deals with the files? They both allow you to edit the 2DAs, but does the TSL Patcher do something extra (behind the scenes)? Any type of extra preperation of the 2DA files?

You may have covered this before, so I am sorry to have a repeate question.

If anyone has the answer, please feel free to add your comments.

Mac, "bumping" of threads like you are doing will not be tolerated here, use the edit post feature to add any possible content to your previous posts. -RH

Edit: Mac, if we Mods edit your post with a warning it stays, please don't try to remove them. -RH

As was requested I have added support for modifying SSF Soundset files to the TSLPatcher, letting it insert dynamic StrRefs for sound entries in those files.

I have now also updated ChangeEdit.exe and the PDF Readme to handle the SSF section.

I have uploaded this test version as TSLPatcher v.1.2.6 (wip v1) here (http://www.algonet.se/~stoffe/TSLPatcher126wip.rar).

As before it appears to work from my limited testing, but I can't guarantee that it's bug free. If you notice any problems with it, please let me know so I can attempt to fix it.

Hey stoffe I just wanted to leave some feedback on 2 of the new(er) features of the TSLPatcher

1) zOMG the compare .2da files feature saved my poor frazzled brain.. what a lifesaver! It took me all of maybe 5 seconds to enter an 18 row appearance.2da change in the changes.ini... I am in love with this feature as it has made my changes.ini editing soooooo much easier. Thank You!

2) Your NSS processing & compiling feature works like a charm.. again, countless headaches will be solved with the feature, and without it, I don't think my Kreia mod would've been released. I can only imagine how many requests there would be to re-compile those files depending on the row changes in appearance.2da... you have my undying thanks...

Those 2 features, the newer ones I hadn't gotten to play with until now have been well worth the wait and a welcomed addition. At least now there's a(nother)? mod out using your NSS compiling feature should anyone wants to dissect it ;)

Everything tested/worked great in my game under both a clean override & a dirty 300+mb filled one hehehe... let's just hope my testing wasn't a "fluke" hehehe

I agree iwth ChAiNz.2da, your comparision oprtion saves a lot of time and headache. :) Thank you Stoffe. :)

Quick question:
I noticed that the TSL Patcher creates a Changes.ini file, which tells me what I have customly added to the files. Do I add this file into my mod set?

Quick question:
I noticed that the TSL Patcher creates a Changes.ini file, which tells me what I have customly added to the files. Do I add this file into my mod set?
Yes, when you are making your mod to use the patcher you will need to place your mod files in a 'tslpatchdata' subfolder.

When you go to start the process of making your mod use the patcher with ChangeEdit you will need to start a new changes.ini in that tslpatchdata subfolder, I believe ChangeEdit when you start a new changes.ini it has a browser window that you can place/save the new file to, you could save it wherever you want but it helps to save it to your mods tslpatchdata subfolder within your mods working directory.

You will also need a rtf text file (Wordpad) called info.rtf and that is what displays in the patcher window for the end-users to read when installing the mod, this info.rtf goes in your mods tslpatchdata subfolder as well. ;)

So when you package your mod for release, you will need a base directory that contains your readme file and the TSLPatcher.exe (Renamed to whatever you want to call it) with all your mod files plus the changes.ini and info.rtf in a tslpatchdata subfolder in that directory. Any possible script source files you can put in a Source Scripts subdirectory as well.

Like so...

Working Directory (Main Folder)
..........tslpatchdata (Subfolder)
..........Source (Subfolder)
..........TSLPatcher.exe (Renamed if you wish.)
..........Readme.txt

:D

I've done some improvements (I hope) to the ChangeEdit utility. As far as I can remember (I really should write this stuff down somewhere...):
Added a GFF Compare function to the GFF panel, as requested. It will take two GFF files (one modified an one unaltered), check which fields have been modified and added, and create Modifiers for the TSLPatcher accordingly. It's still a little rough around the edges, but as far as my limited testing has shown it appears to work. Please see the ReadMe file for more info about how it works.


Added a button to the 2DA Panel to copy an existing Modifier. This can be useful if you create many Modifiers which are very similar, allowing you to copy an existing one and only change the necessary columns rather than create it from scratch.


Added a helper to the GFF panel that will load all the Field labels from a GFF file into a dropdown box, saving its user some typing and potential typos when creating modifiers to alter the values of existing fields in a GFF format file.


Improved the box where you specify the names of new 2DA, GFF and SSF files the TSLPatcher should work with. I added a helper button that lets you pick a file with a standard Open dialog rather than having to type in the name.


Modified the helper that loads 2DA file column labels into a dropdown box in the 2DA Modifier editor. It will now find the 2DA file automatically if it's located in the same folder as the changes.ini file (e.g. in the tslpatchdata folder), and only ask for the file with an Open dialog if it can't find the 2DA file there. The box will also keep its content while you edit the same file so you won't have to reload it for every modifier.


Added Help hints for most buttons and boxes in the main ChangeEdit window. Check the Status bar at the bottom of the window while placing the mouse cursor over an interface element for some brief description of what it does.


Removed the need to manually load tokens into the Value dropdown lists in the 2DA and GFF editors. The dropdown list will automatically refresh its content when you pull down the menu.


Fixed most grids/lists to allow double-clicking on a line to edit/load the data it represents.


As usual I've only had limited opportunity to test that things work as intended. If anyone uses this and find any bugs or oddities, please let me know so I can attempt to fix them. :)

The updated ChangeEdit version can be downloaded from the link in the first post in this thread.

A GFF compare option?

Bless you, stoffe. Heck, lets go ahead and nominate yoru for sainthood! :D

Yup, I second that one! ;)

Sweet new additions there stoffe! :thumbsup:

In my ongoing effort to further complicate things, I just uploaded TSLPatcher v1.2.7b1 and ChangeEdit v1.0.4b1 (http://www.starwarsknights.com/tools.php#mctl) which seems to work now as far as I could tell from limited testing.

This version has only one new feature, that of allowing an installer with multiple install options. Simply put it allows you to make multiple sets of changes.ini/info.rtf files and optionally new sub-folders for them and their data files, and allow the prospective Mod user to choose which of them to use for their installation. Rather than re-type it all again I'll just paste what I've written about it in the ReadMe file below, for those who might be interested:

As always bug reports and feedback is welcome.

* * *

From the ReadMe:

Quick overview
A Setup List is a way of providing more than one possible way of installing a Mod from the same Installer. It may for example be used to let the user choose to update a previously installed version of the Mod, or install it completely from scratch. Technically it will allow you to create multiple changes.ini and info.rtf files and present the user with a list of options where they pick which set to use when TSLPatcher is launched. This is configured in a separate INI format file that must always be named namespaces.ini, and be located directly in the tslpatchdata folder.

If the namespaces.ini file is present within the tslpatchdata folder a dialog box is shown when TSLPatcher (1.2.7 or later) is launched, presenting the user with a dropdown list of available installation options, and a short description of each. When the user has selected which Setup to use, the associated INI and RTF file are loaded and the main TSLPatcher window is shown like before. If the namespaces.ini file does not exist within the tslpatchdata folder, TSLPatcher will not show this dialog box and just go to the main window like it usually does.

Configuration
To configure a namespaces.ini file, launch ChangeEdit.exe and choose Setup Lists from the File menu. In this submenu you can choose to either create a new namespaces.ini file, or open an existing one for editing. If you create a new one, note that it must always be named exactly namespaces.ini for the TSLPatcher to read it. A new edit window will open.

The list to the left lists all the different sets of Setup INI/RTF files present in the current namespaces.ini file. To edit an existing Setup, click it in the list, and its data will be loaded into the box on the right.

To create a new Setup, click the New... icon above the list. You will be asked to specify an identifier label for your new Setup. Like with modifier labels in changes.ini, this identifier should be unique within the namespaces.ini file and only contain alphanumerical characters or underscores and no spaces. While it will never be displayed to the user, only used internally, you should pick something that helps you remember what the setup is.

To edit the values of a selected or newly created Setup, use the input boxes in the panel to the right. The following fields are available:

Config file name - This is the name of the INI file the TSLPatcher will look in for instructions on what to do. This is usually changes.ini, but you can specify another name here if you have more than one configuration file in the tslpatchdata folder.

Info file name – This is the name of the RTF format document that will be displayed in the text area in the main TSLPatcher window, usually containing the ReadMe file or special installation instructions. This is usually info.rtf, but you can pick another name for your setup if you have several in the tslpatchdata folder.

Data folder – This field is optional. If left blank the TSLPatcher will look for the two above named files, as well as any data files that are to be installed, within the tslpatchdata folder as usual. If this field is set to the name of a sub-folder created within the tslpatchdata folder, TSLPatcher expects the above named INI and RTF file, along with all data files that should be installed, to be present within that folder instead of in the tslpatchdata folder.

Name – This is a descriptive name of this particular setup. This text will be displayed in the dropdown menu in TSLPatcher where the user can choose which Setup to use for installation.

Description – This is a short description text of this Setup, which should explain what it means. This text will be displayed in the information box in TSLPatcher when the user selects the Setup in the dropdown menu.

When you have typed in your desired values, press the Save Changes button to commit the values to the namespaces.ini file.

Important: For multiple setups that are placed in sub-folders and use nwnnsscomp.exe to recompile scripts using include files before installing them you must place the version of nwnnsscomp.exe that comes with TSLPatcher, along with an nwscript.nss file, in the tslpatchdata folder. Do not put it in the subfolder directly.

I've uploaded an updated version of TSLPatcher and ChangeEdit. This is just a mini-version with a new feature someone requested recently, nothing major.

The only new feature is that there is now an option that lets the TSLPatcher auto-detect the location of the game folder to install in, rather than ask the user to select it. The Settings panel in ChangeEdit has been modified to allow toggling this setting. It's off by default, resulting in the standard behavior of asking for the install location. If it's activated it allows you to set which game (KotOR1 or TSL) the mod is for (and which consequently will be looked up in the Windows Registry).

(I suppose it may be useful to some since a few people seems to have trouble distinguishing between the Game and Override folders. Perhaps a simple mistake to make if you aren't into modding the games.)

The download link is in the first post in this thread if anyone is interested.

Yes, when you are making your mod to use the patcher you will need to place your mod files in a 'tslpatchdata' subfolder.
(Edited for space saving)
:D
I assume that will work even if I didn't make the mod. I can use this method for KI/KII mods without the patcher.

I assume that will work even if I didn't make the mod. I can use this method for KI/KII mods without the patcher.
Yes you could, but you need to know a little bit about modding and what the mod in question changes before you could do this. If you are familiar with mods and modding these games it isn't that hard to do this with someone elses mod. stoffe set up ChangeEdit to be quite easy to work, so like I said the real hard part is knowing what the modder changed/did. :)

I have a patched up unaltered kotor 1 TLK file and I have no problem opening it in tlked

I have a question...it's possible this has been fixed with the new release, but I'd like to ask anyway since it's not a bug I can replicate, or rather, it's never happened to me.

I have a mod-in-progress that changes a custom .utc so that the Appearance_Type and PortraitId are added in from memory tokens, like so:

Appearance_Type=2DAMEMORY2
PortraitId=2DAMEMORY3

The memory tokens refer to new rows created in appearance.2da and portraits.2da. Installing it has always worked for me (I've had to uninstall and reinstall my K2 mods a few times, never had a problem with this), but for some reason, the .utc isn't being changed for some people, leaving them with the default appearance from the .utc in the tslpatchdata folder. The .utc is based on Atton's, so they end up with the new character looking like Atton. I hadn't heard that my loverly beta testers had noticed that the portrait was Atton's, but then, I suppose that's something a little less noteworthy.

I wrote my changes.ini by hand, so of course I could have written in a mistake that seems rather selective in who it bothers :)

Is there any reason why this might happen or is it just dumb bad luck?

I have a mod-in-progress that changes a custom .utc so that the Appearance_Type and PortraitId are added in from memory tokens, like so:
(snip)
The memory tokens refer to new rows created in appearance.2da and portraits.2da. Installing it has always worked for me (I've had to uninstall and reinstall my K2 mods a few times, never had a problem with this), but for some reason, the .utc isn't being changed for some people, leaving them with the default appearance from the .utc in the tslpatchdata folder.


(Seems like the "New posts" feature of the forum doesn't work properly. I've completely overlooked this post earlier, sorry about that.)

Hmm, I haven't noticed any problems with files not being updated properly, so it's hard to tell what might be causing it. Which version of TSLPatcher do you use? Does it produce any error or warning messages in the log while installing, or does the error just happen "silently"?

Did the people for whom it didn't work properly have an already modified version of the UTC file in question in their override folder, or was it a "clean" addition in all cases?

How have you set things up in the configuration file? If it's not too large you could post it here and I'll have a look at it and see if I can spot anything that looks out of the ordinary. :)

I've uploaded a new version of TSLPatcher and ChangeEdit. While it doesn't contain any new features (since no one has requested any :)) it contains some interface improvements in both TSLPatcher and ChangeEdit, some minor bugfixes and updated documentation. It's available at the link in the first post in this thread, as usual.

I've uploaded another relatively minor update to TSLPatcher and ChangeEdit.

Behold my poor skill at explaining things in an understandable way: :D

TSLPatcher:
Added a new keyword, "!FieldPath", which can be assigned to a 2DAMEMORY# token in field modifier sections when adding new fields to a GFF file. This will store the full path and labels of the field within the file inside the token.


Modified the top file section for each entry in the GFFList to allow using tokens instead of constant field paths+labels to specify which field to modify a value of. This can be used with the change mentioned above to modify the value of newly added fields after they have been created.


Added a "!SourceFile" key to all file modifier sections except for 2DA files, where you can specify the name of the file (in the tslpatchdata folder) that will be used as blueprint if the file does not already exist. This file will then be renamed to the file modifier section name when copied to its correct place. This allows using multiple template files of the same type in different Setup Lists that share the same data folder.

E.g. if you modify files that have changed in the official 1.0b patch of the game, like handmaiden.dlg. This could be used to provide one unpatched and one patched version of this file, used by different Setup Lists, both which would be renamed "handmaiden.dlg" when installed.)(Example mod using this (http://www.algonet.se/~stoffe/handmaiden4femexiles12.rar))


The statusbar of the main TSLPatcher window now always show the current install path, both when reading it from the registry and after the user has selected a folder.



ChangeEdit:
Added Open File Dialog selection buttons to the changes.ini and info.rtf selection boxes in the Setup Lists editor, so you won't have to type in the filenames manually.


Added a "Save processed scripts for debugging" checkbox to the Settings panel. This can be checked when debugging things when having the TSLPatcher process scripts for tokens and recompile them. When checked a copy of all processed scripts (used for compiling) will be saved inside the "debug" folder inside the tslpatchdata folder.


Modified the "Add GFF Field" editor with a new field for specifying the Field Path tokens mentioned above.


Modified the "Modify GFF fields" panel to display New fields to add as well, and two buttons allowing you to change the order of the GFF modifiers. (Can be useful with the first two mentioned features since you'd need to make sure modifiers with tokens as fields are below the New fields that sets the tokens in the modifier list.


So, what's the point of these changes to the GFF handling? It will allow you to use the TSLPatcher to insert conversation branches into existing DLG files. It's still a hellish amount of work to configure it to do so, but at least now it's possible. :D (Example requested mod using this (http://www.algonet.se/~stoffe/meditation.rar))

So, what's the point of these changes to the GFF handling? It will allow you to use the TSLPatcher to insert conversation branches into existing DLG files. It's still a hellish amount of work to configure it to do so, but at least now it's possible. :D
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 :)

(Seems like the "New posts" feature of the forum doesn't work properly. I've completely overlooked this post earlier, sorry about that.)

Hmm, I haven't noticed any problems with files not being updated properly, so it's hard to tell what might be causing it. Which version of TSLPatcher do you use? Does it produce any error or warning messages in the log while installing, or does the error just happen "silently"?

Sorry it took so long to see this!

It's silent from what I've heard. I used the...erm...oh geez, I don't remember which version it was, it was the first beta version that could compile .nss with a 2DAMEMORY token, IIRC.

Did the people for whom it didn't work properly have an already modified version of the UTC file in question in their override folder, or was it a "clean" addition in all cases?

It was a brand new .utc in all cases. I do know that one of the testers had her mod files put into subfolders and eventually got it straightened out by keeping some of the .2das in the main Override. The other person had far worse problems with it; the new .utc apparently lost all of the feats I added and turned into Atton in his skivvies O_o

How have you set things up in the configuration file? If it's not too large you could post it here and I'll have a look at it and see if I can spot anything that looks out of the ordinary. :)

The relevant bits are these, since the entire change.ini is about nine miles long :)

...
[2DAList]
Table1=heads.2da
Table2=appearance.2da
Table3=portraits.2da
Table4=upcrystals.2da
Table5=globalcat.2da

[GFFList]
File1=tel_dustil2.utc

[heads.2da]
AddRow1=add_head

[appearance.2da]
CopyRow1=copy_appearance

[portraits.2da]
CopyRow1=copy_portraits

...

[add_head]
ExclusiveColumn=head
head=tel_dustilh
alttexture=tel_dustilh
headtexvvve=tel_dustilh
headtexvve=tel_dustilh
headtexve=tel_dustilh
headtexve=tel_dustilh
2DAMEMORY1=RowIndex

[copy_appearance]
RowIndex=167
ExclusiveColumn=label
label=tel_dustil
NormalHead=2DAMEMORY1
BackupHead=2DAMEMORY1
equipslotslocked=306
2DAMEMORY2=RowIndex

;306 locks his hands, armor, and right forearm.

[copy_portraits]
RowIndex=23
ExclusiveColumn=baseresref
baseresref=po_tel_dustil
appearancenumber=2DAMEMORY2
appearance_s=2DAMEMORY2
appearance_l=2DAMEMORY2
baseresref=po_tel_dustil
forPC=0
baseresrefe=po_tel_dustil
baseresrefve=po_tel_dustil
baseresrefvve=po_tel_dustil
baseresrefvvve=po_tel_dustil
2DAMEMORY3=RowIndex

...

[tel_dustil2.utc]
Appearance_Type=2DAMEMORY2
PortraitId=2DAMEMORY3

It works like a charm for me, so I don't know what could be causing it.

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:
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.


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.


Extract another clean copy of the same DLG file and put it into the tslpatchdata folder.


Use the GFF Compare function in ChangeEdit to compare your modified DLG file with the unaltered version, creating AddField modifiers for the new fields.


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.


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.


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.


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...


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


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


ReplyList 738: (2DAMEMORY7 = ListIndex)
EntriesList: 627 (2DAMEMORY6 = FieldPath)


EntryList 627: (2DAMEMORY5 = ListIndex)
RepliesList: 739 (2DAMEMORY12 = FieldPath)
RepliesList: 740 (2DAMEMORY4 = FieldPath)


ReplyList 739: (2DAMEMORY11 = ListIndex)
EntriesList: 628 (2DAMEMORY10 = FieldPath)


EntryList 628: (2DAMEMORY9 = ListIndex)
(END)


ReplyList 740: (2DAMEMORY3 = ListIndex)
EntriesList: 629 (2DAMEMORY2 = FieldPath)


EntryList 629: (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. ;)

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!!!!

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)

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!!!

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:


TSLPatcher can now handle RIM format files as well. They work in exactly the same was as using ERF files as installation destination does.


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.


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.

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.

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.

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!

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?

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.

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. :)

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

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. :)

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.

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:

http://img.photobucket.com/albums/v298/Deus111/broken.jpg)

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? ^-^;

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:

http://img.photobucket.com/albums/v298/Deus111/broken.jpg)

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 (http://img142.imageshack.us/img142/2704/tslpguidn9.jpg) 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...

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.

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. :)

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.

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.

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.

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.

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.

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.

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 (http://img503.imageshack.us/img503/4871/changeeditka8.jpg)


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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).


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


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.


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.


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.


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.


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.


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.


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.