PDA

View Full Version : TSLPatcher v1.2.10b1 (mod installer)


Pages : [1] 2

stoffe
05-25-2005, 07:13 AM
Latest version: TSLPatcher 1.2.10b1, ChangeEdit 1.0.5b1 (http://www.starwarsknights.com/tools.php#mctl)


(You can check which version you currently have by opening the Properties window of the EXE file in Windows Explorer and check on the Version tab.)

* * *

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

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

It can, in general terms:
Add new entries to the dialog.tlk file, so you won't have to distribute the whole 10 MB file with a mod, and make it compatible with other mods adding new entries.


Modify and add new lines and columns to 2DA files that might already exist in the user's override folder, allowing different mods to modify the same 2DA file with less risk of causing incompatibility.


Modify values in fields and add new fields to GFF format files (UT*, DLG, JRL, GIT, ARE, IFO etc...) that might already exist in the user's override folder or inside ERF/RIM archives. Again to reduce incompatibility when different mods need to do things to the same file.


Dynamically assign StrRefs from your new dialog.tlk entries to 2DA, GFF, NSS and SSF format files, allowing you to use your new TLK entries regardless of which StrRef indexes they were added as, through the use of token references. (E.g. add the correct StrRef values to the "name" and "desc" column in spells.2da if you add a new force power.)


Dynamically assign values from 2DA and GFF files to cells and fields in other 2DA, GFF and NSS files, such as the line numbers from newly added rows in a 2DA file or the field path label of a newly added field. This can be used to link together files that reference eachother dynamically, regardless of where in the files your additions end up. E.g. linking new heads.2da --> appearance.2da --> portrait.2da lines together to add a new player appearance. Or linking a new appearance.2da line for an NPC to the "Appearance_Type" field in their UTC template, just to mention a couple of potential uses.


Insert StrRef or 2DA/GFF token values into scripts and recompile those scripts automatically with the correct values. (E.g. adding new Force Powers with an impact script that needs to know which lines in spells.2da the new powers are defined at.)


Dynamically modify SSF (Soundset) files to point to new entries you have added to dialog.tlk.


Automatically put other files that does not need to be modified into the correct folder within your game folder (e.g. "Override", "Modules", "StreamMusic" etc...), or inside ERF or RIM format archive files existing in any of those folders.


Insert modified GFF files into a RIM or ERF format file (ERF, MOD, SAV etc), found in the game folder or any of its sub-folders, or modify existing files already found in that destination file. Recompiled NCS script files can also be inserted into RIM and ERF format files (but only overwrite, not modify existing scripts with the same name).


Make unaltered backup copies of any files it modifies or overwrites, making it a little easier to uninstall a mod again.


Provide the user with different installation alternatives which may be chosen at installation time.


Display a ReadMe, instruction text or agreement with basic font and text formatting support (using the Rich Text Format) to the user prior to installation.



It cannot, in no uncertain terms: :D
Make standard game scripts that are modified by serveral mods compatible. The structure of a script file is too dynamic to lend itself well to automatic merging (at least for someone of my skill level in programming).


Resolve naming/priority conflicts resulting from placing several variants of files with the same name in different sub-folders inside the override folder. It will always assume that all files it is supposed to modify are located directly in the override folder and not in any subfolders to avoid ambiguous situations.


Modify files held inside BIF files in the game, since KEY/BIF files work pretty much the same as the override folder in most cases, and editing the KEY/BIF data can lead to problems. This does of course not prevent you from extracting whatever files you need from the BIF data in advance and put them in the TSLPatcher's data folder.



A few quick "how to" examples:
Insert new branches into DLG files. (http://www.lucasforums.com/showpost.php?p=2135535&postcount=177)
Install a New Player Appearance mod. (http://www.lucasforums.com/showpost.php?p=2168405&postcount=201)


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

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

Alternatively, if you don't want to mess with your DLL files, you could force TSLPatcher to use a plain text box for status messages rather than the colored/formatted one. To do this, use Notepad to open the changes.ini file found inside the tslpatchdata folder that came with the mod you wish to install. Under the [Settings] section, change the value of the key PlaintextLog from 0 to 1.



Q: I'm not seeing any Install Mod button, and the text field in the TSLPatcher window seems to extend behind the window boundraries.

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



Q: When trying to install a mod it complains that it's not a valid installation location. What's wrong?

A: Make sure you are selecting the folder the game is installed in, not the override folder, when the TSLPatcher asks you where to install the mod.



Q: When trying to install a mod it complains that access was denied to the dialog.tlk file.

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


* * *

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


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


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


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


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


EDIT(2006-10-03) Uploaded TSLPatcher v1.2.8b6, which contains a whole bunch of bug fixes and some new features. Please see this post for details (http://www.lucasforums.com/showpost.php?p=2186813&postcount=210).

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


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


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


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

EDIT(2006-08-06) TSLPatcher v1.2.8b0 and ChangeEdit v1.0.4b7 uploaded. This version changes how the ERF handling functionality works to make it more useful. See this post (http://www.lucasforums.com/showpost.php?p=2144898&postcount=181) for more info.

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

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

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

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

EDIT(2006-04-29) Uploaded TSLPatcher v1.2.7b1 and ChangeEdit v1.0.4b1. Too much more information can be found in this post (http://64.20.36.211/showpost.php?p=2076883&postcount=166).

EDIT(2006-03-25) Updated ChangeEdit to v1.0.3a with GFF Compare function, 2DA Modifier copy button and a whole bunch of interface improvements. See this post (http://64.20.36.211/showpost.php?p=2055110&postcount=163).

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

EDIT(2006-03-09) Uploaded new test version, TSLPatcher v1.2.6a (WIP v1) with added support for modifying SSF Soundset files with dynamic StrRefs for added TLK entries. See this post (http://64.20.36.211/showpost.php?p=2041981&postcount=159) for a little more detail.

EDIT(2006-02-03) I've uploaded a new test version, TSLPatcher v.1.2.5a, which has some limited ERF (e.g. module file) packing functionality added. See this post (http://64.20.36.211/showpost.php?p=2010175&postcount=150) for more details.

EDIT(2006-01-16): I've uploaded a test version of TSLPatcher v1.2 and ChangeEdit v1.0 which has some new features added. See this post (http://64.20.36.211/showpost.php?p=1988487&postcount=132) for details.

T7nowhere
05-25-2005, 08:46 AM
Great work man.

Thanks

General Kenobi
05-25-2005, 12:43 PM
Excellent work my friend :thumbsup: My lil' achin' 2da brain thanks you :D

5/5 Elephant Rating

:elephant: :elephant: :elephant: :elephant: :elephant:

I have been having issues with 2da editing and this will be a killer tool to use to merge existing ones.

Again thanks man :D

DM

Darkkender
05-25-2005, 01:32 PM
Good to see this in final release now.

Jeff
05-25-2005, 07:41 PM
Great job stoffe. This is great :)

Jackel
05-25-2005, 07:43 PM
Nice work stoffe! I will be experimenting with this in the next few days for sure.

Keiko
05-25-2005, 07:49 PM
Nice Job!:)

Mav
05-25-2005, 11:10 PM
This sounds like an exceptional tool, I'll be looking into this more in depth in the next few days.

ChAiNz.2da
05-26-2005, 11:54 AM
Great stuff man!

I'm persnally glad to see the GUI was in the public release :D

When I first started testing, It took me a few read throughs of the readme to get going... after that.. (to quote Atton) "Pure Pazaak" ;)

:thumbsup:

stoffe
06-03-2005, 03:22 PM
I have uploaded a new version of the Patcher and its support applications. If anyone is interested you can download it on this page. (http://www.starwarsknights.com/tools.php)

As before, comments, suggestions and bug reports are welcomed.

This is what has changed since the first release, snipped from the Readme:


TSLPatcher v1.1.1b
------------------------
* Added a new Setting that when set will make the Patcher run in Installer mode instead. When doing this, the Patcher will not ask for each individual file. It will only ask the user for the folder where the game is installed, and then automatically use the dialog.tlk file found in that folder, and the override folder located there. If no Override folder exists within the selected folder, one will be created. The patcher will then check the Override folder for the presence of any of the files (except dialog.tlk of course) it should modify. If present, it will modify those existing files. If the files are not present, the Patcher will look in the "tslpatchdata" folder for the file, which will then be copied to Override and modified there. Thus, when using the Patcher in Installer mode, all data files that make up your mod should be put in the "tslpatchdata" folder (except dialog.tlk). In the case of 2DA files, don't put the modified version here, put an unaltered copy of the 2DA files in "tslpatchdata". They will only be used if the user doesn't already have a custom version of that file in their Override folder.

* Added a bare bones file "installer" feature to allow the Patcher to also install files it shouldn't modify. All files must be located within the "tslpatchdata" folder, and will be copied to the specified folder within the main Game folder the user has selected (override in most cases). This will only work when the patcher runs in Installer mode. Intended to allow the patcher to fully install a mod into the game, not just the files that it should modify. Useful for things like textures, icons, unmodified scripts etc.

* Added support for the Orientation and Position type of fields (that I missed earlier) when modifying GFF fields. If you wish to use it for whatever reason, Orientation is set as four decimal values separated by a | character. Position works the same, but is three numbers instead of four. For example:

Field: CameraList\0\Orientation
Value: 12.4|6.5121|1.25|-9.6

* Added a primitive way for the Patcher to modify things like NCS scripts with correct 2DA index values and StrRefs. It is currently VERY primitive, and WILL mess up your files if you don't know what you are doing when you configure it. As such it is not added to the ChangeEdit application, and I won't describe how it works here. If you really need to use it, ask me and I'll describe how it works.


TalkEd v0.9.9b
------------------
* Added new option in the Search dialog to search for each word individually. Checking this box and typing "vogga dance" as criteria would match the string "Do you wish to dance for vogga?" for example.
* Fixed some annoying behavior in the list when adding new entries. The list should now display all new entries that have been added since the current file was loaded (or created in case it is a new file) when a new entry has been added.
* Added support for associating TalkEd with TLK files in the Windows Explorer. If a TLK files is drag-n-dropped on the TalkEd icon, that file will be opened. If TalkEd is associated with TLK files, doubleclicking a TLK file will open it in TalkEd.

ChangeEdit v0.9.3b
-------------------------
* Fixed annoying list behavior, when adding a new entry to a list, the new line will be selected.
* Added CTRL-SHIFT+Arrowkey keyboard shortcuts to press the arrow buttons that store/retrieve data in lists.
* Two new entries in the Settings section. You may now set if the patcher should do backups of existing files before modifying them, and you may set which run mode (Patcher or Installer) it should run in.
* Added new section for specifying files that should be installed by the patcher when running in Installer mode.
* A whole bunch of minor bug fixes.



(Check the Force Powers mod I recently uploaded to PCGameMods if you wish to see a working example of this version of the Patcher in action.)

Darth333
06-03-2005, 03:49 PM
Good work as always stoffe :) It's getting better and better!

As discussed, I uploaded the file at swk.com: http://www.starwarsknights.com/tools.php and added a link to this thread so it can be found easily. If there is anything you want to be changed, just let me know.

RevanA4
06-03-2005, 06:00 PM
Originally posted by Jackel
Nice work stoffe! I will be experimenting with this in the next few days for sure.

me to now that LA is back up

stoffe
07-09-2005, 05:04 AM
Since this thread has lost most of its posts I suppose I should re-post what is new in the latest released full version (1.1.2), which includes a rudimentary readme, examples and the TalkEd and ChangeEdit utilities.

It can be downloaded from here (http://www.starwarsknights.com/tools.php).



TSLPatcher v1.1.2b
------------------
* Added an optional special key named "ExclusiveColumn" to the AddRow and CopyRow 2DA modifiers. If used this must be at the top of the modifier list for AddRow or just below the Index of the line to copy in CopyRow. When present this must be set to the label (ie name) of a column in the 2DA file. The patcher will then check what value is assigned to that column in the modifier for the new row, and compare it to the values of all rows in that column in the 2DA file. If no other row has the same value in the column as the one you are about to add, the Patcher will continue as usual and add the new line to the 2DA file.

If, however, another line already had that value set for the specified "exclusive" column, then that line will be modified instead and no new row will be added to the file. This can be used to update existing lines, for example when a new version of a mod is released, avoiding adding duplicate line while still allowing the mod to be installed fresh if the lines don't already exist.

IMPORTANT! Only the first matching row will be used and modified, thus it is very important that you use a column which allows you to identify the row in a fairly unquie way. The "label" column in the 2DA files which has it is good for this, since the game rarely if ever actually use the values here for anything.

* Added a "LabelIndex" special key to the ChangeRow 2DA modifier. This will only work for 2DA files which have a "label" column. In those files you can use the "label" column to index/identify a row to modify instead of the normal line number or row label identifiers. This is useful for modifying existing lines which have had their line number and row label assigned dynamically earlier, and as such you can't know them when you are writing your Patcher instructions. IMPORTANT! If more than one row has the specified value in its "label" column, the row with the highest line number (ie closest to the end of the file) will be used.

* Added support for the "high()" special value token to the AddRow 2da modifiers as well. Previously this special token only worked for CopyRow modifiers. (It inserts the highest value of all rows in that column + 1 for the new row, provided that the column contains numbers.)

* Added a summary of patcher progress log at the conclusion of an Install/Patch operation, reporting if any warnings or errors occured during installation. This should hopefully make it clearer to users who understandably won't read the whole log if something went wrong.

* Changed the "start" message in the progress log to reflect if the program is running in Installer of Patcher mode. Also added the date and time when the operation was started, to help people remember in what order they have installed different mods (which if useful to know if you want to uninstall a mod.) See the next point below.

* At the conclusion of an operation, the progress log will now automatically be saved to a file named "installlog.rtf" created in the same folder as the Patcher app is running from.

* Cosmetics: The ".\" folder (ie the game root folder), if used in the InstallList of folders, will now be reported as the "Game" folder in the progress log.

* Added support for overwriting existing InstallList files. If using ChangeEdit.exe, tick the checkbox below the filename input box. If editing things with a text editor, Change the key in the file-list from "File#" to "Replace#". This will make existing files with the same name to be overwritten. The original file will first be placed in the "backup" folder (if backup is enabled) before it is overwritten. The Patcher will also refuse to overwrite EXE and TLK files. This is useful for updating an earlier version of a mod while still allowing it to be installed fresh with the same Installer.

* Added a new special key to the HACKList modifiers. If the first key in the list for each file is set to "ReplaceFile=1", this will make any existing files in the Override folder with the same name be overwritten. Note that the existing files will be overwritten by fresh copies from the "tslpatchdata" folder before HACK assigns new values. This is useful for allowing updates to earlier versions installed while still allowing fresh install with the same Installer app.

* If running in Installer mode and a needed file is missing in the "tslpatchdata" folder (which it in most cases really shouldn't be) and the patcher asks the user for the file instead, the selected file will now be copied to Override and modified there, rather than that file being modified directly as it incorrectly worked before.


ChangeEdit v0.9.4b
------------------
* Added a preview box to the TLK panel to let you view the whole entry when you select a long TLK entry in the append.tlk list. Should make it easier to pick the correct entry when assigning StrRef tokens if you have several which starts in pretty much the same way (for example Force Power descriptions).

* Added a "Replace" checkbox to the Install Files panel. When checked the file in the edit box will replace files with the same name that already exists in the folder. If not checked, the Installer will skip the file and issue a warning in the progress log that the file already existed.

* Added "LabelIndex" to the line identifier dropdown menu in the ChangeRow editor window for 2da files. If selected, the value box should be set to a value in the "label" column in the 2da. See above in the patcher change notes for more info about this.

* Added "high()" to the Value field dropdown list in the AddRow 2da editor window.

* Added "ExclusiveColumn" to the Column label dropdown list in the AddRow and CopyRow 2da editor windows when loading column labels from a 2da file. See above for more info about what this optional key does.


TalkEd v0.9.9b
--------------
* Added new option in the Search dialog to search for each word individually. Checking this box and typing "vogga dance" as criteria would match the string "Do you wish to dance for vogga?" for example.
* Fixed some annoying behavior in the list when adding new entries. The list should now display all new entries that have been added since the current file was loaded (or created in case it is a new file) when a new entry has been added.
* Added support for associating TalkEd with TLK files in the Windows Explorer. If a TLK files is drag-n-dropped on the TalkEd icon, that file will be opened. If TalkEd is associated with TLK files, doubleclicking a TLK file will open it in TalkEd.

stoffe
07-09-2005, 05:19 AM
Some other things from the top of my head that has vanished from this thread.


@ermo(?) -
I put together a mini-release containing the patcher application only that has added commandline support as you asked. It accepts two optional parameters, the first is the name of an INI file containing work instructions, the second is a name of a custom RTF file to display in the info text box when the app starts. Like:


TSLPatcher.exe another.ini someinfo.rtf


You can download it here (http://www.algonet.se/~stoffe/TSLPatcher113.rar). That file contains the patcher EXE only since I assume you already have the other files and nothing else has changed. Hopefully this is what you meant...

* * *

@commas -
I am working on a new "full" version of the patcher that can handle adding new nodes to existing dialog files, as you requested. Progress has been slow recently though since I've been busy with other real-life things the last few weeks. Hopefully I should be able to get to it during the vacation soon.

* * *

@Everyone -
Since I've gotten a few questions about odd behavior resulting from this, and it is far from obvious I should point this out. Should've been in the ReadMe file to begin with to avoid trouble, but it's easy to become blind to your own designs... Sorry about that. :(

When modifying 2DA files with AddRow-modifiers, you must assign a value to at least one column before you can assign a value from the new row (like the RowLabel or RowIndex) to a 2DAMEMORY token.

This is due to the fact that the patcher executes things in the order they are listed in the modifier lists, and the new row isn't added until at least one value has been set for a column.

Thus this is invalid, as RowIndex hasn't been determined yet:

[heads.2da]
AddRow0=heads_bastila

[heads_bastila]
2DAMEMORY1=RowIndex
head=P_BastilaH
alttexture=kinrathpup
headtexe=evilpup


While this is valid, as the new row has been added:

[heads.2da]
AddRow0=heads_bastila

[heads_bastila]
head=P_BastilaH
alttexture=kinrathpup
headtexe=evilpup
2DAMEMORY1=RowIndex

General Kenobi
07-09-2005, 07:20 AM
Originally posted by Stu BodyBanger
Download now Our exclusive offer 0.00 $ :)


Your not supposed to post spam stuff :mad:

Maxstate
07-09-2005, 08:37 AM
Great addition to the community, good work!

TheOssusKeeper
07-14-2005, 09:50 PM
Quick question for someone who might know:
Is there a comprehensive step-by-step guide for dummies like me who don’t know much about using the TSLpatcher and the other utils that comes with it?
If so, where can I find it?

sorry if this has already been asked, i've been gone for a while and instead of wading through post after post, i thought i'd straight up ask... :D

T7nowhere
07-14-2005, 10:05 PM
The only tutorial I know of are the examples that stoffe -mkb- has provided with tslpatcher.

this should have been posted in the tslpatcher thread in order to keep as much info about the tool in one place, so I'm merging this with the tools thread.

ChAiNz.2da
07-15-2005, 05:05 AM
Originally posted by TheOssusKeeper
Quick question for someone who might know:
Is there a comprehensive step-by-step guide for dummies like me who don’t know much about using the TSLpatcher and the other utils that comes with it?
Like T7 mentioned, stoffe's examples included worked wonders for me :D

Though I was "lost" at first, I made my first Patcher while having the examples (and the readme) open along with my project.

It was probably one of the first times where a 'mod' of mine worked the first time.. miracles do happen huh? ;)

Try following them as you go along, but if there's any other questions, feel free to post. Now that there's a few of us here who've used it... maybe stoffe won't wind up having to answer all of them this go around :D

TheOssusKeeper
07-16-2005, 12:18 AM
Originally posted by T7nowhere
The only tutorial I know of are the examples that stoffe -mkb- has provided with tslpatcher.

this should have been posted in the tslpatcher thread in order to keep as much info about the tool in one place, so I'm merging this with the tools thread.


Sorry 'bout the second post T7, i got lost when i didn't see my post anywhere :D

TheOssusKeeper
07-16-2005, 12:21 AM
Originally posted by ChAiNz.2da
Like T7 mentioned, stoffe's examples included worked wonders for me :D

Though I was "lost" at first, I made my first Patcher while having the examples (and the readme) open along with my project.

It was probably one of the first times where a 'mod' of mine worked the first time.. miracles do happen huh? ;)

Try following them as you go along, but if there's any other questions, feel free to post. Now that there's a few of us here who've used it... maybe stoffe won't wind up having to answer all of them this go around :D


hey chainz, maybe you could tell me how you got yours to work step-by-step? :D please, if you don't mind to terribly much :D maybe simplify it for a simpleton like me :p


PS. I love your laughing man avatar, i was going to do the same thing, but wasn't sure if this web site would allow me to use custom avatars or not... :D

stoffe
07-16-2005, 07:29 AM
Originally posted by TheOssusKeeper
Quick question for someone who might know:
Is there a comprehensive step-by-step guide for dummies like me who don’t know much about using the TSLpatcher and the other utils that comes with it?
If so, where can I find it?


Don't think there is, and as evident by the readme file I'm terrible at writing guides, so the chance that I would write one that is usable is rather minimal. :)

Besides, it depends on what type of mod you'd use it for how you'd need to do things, so it's a bit hard to make a "one size fits all" type of guide...

You could have a look at some of the existing mods that use the patcher and see how things are done there. The changes.ini file present with these mods contain the instructions for the patcher and can be opened with both a texteditor (like notepad) or with the ChangeEdit utility included with the patcher.

A few mods off the top of my head that I remember uses it that may be useful to look at as an example:

ChAiNz.2da's Bao-Dur armor - adds a new baseitem to baseitems.2da and updates the GFF/UTI template for the armor to point to it.

My Force Powers mod - Adds new lines to a bunch of 2da files, adds new text to dialog.tlk, hacks script files with proper 2da index values. Also enables updating of existing lines from a previous install of the mod.

My Twilek exile appearance posted a few days ago - Adds a new player appearance editing heads, appearance and portraits.2da, adds workbench-creating for a robe, modifies existing animations.2da line.

There may be other mods using it as well that I can't think of right now. Inspect the changes.ini of other mods and see how things are put together, that be of some help in figuring it out.

And if you have any questions about anything, please ask.

One important piece of advice that makes understanding those files a bit easier though: Everything is done in the order it is listed in the patcher instructions. Thus the ordering of instructions is very important in cases where files reference eachother, like the heads.2da ---> appearance.2da --> portraits.2da sequence when adding a new appearance. This is important to keep in mind when storing values in the 2DAMEMORY tokens for later use.

ChAiNz.2da
07-16-2005, 08:06 AM
Originally posted by TheOssusKeeper
hey chainz, maybe you could tell me how you got yours to work step-by-step? :D please, if you don't mind to terribly much :D maybe simplify it for a simpleton like me :p
well, like stoffe mentioned, it's really a different case for each type of mod, depending on what you need it to do. But, I'll be more than happy to help you along as you go...

Can you give us a jist of what you're mod will be needing to change? Such as which .2da files will need to be appended?

2DAMEMORY tokens are going to be your friend ;) but unlike what the 'techy jargon' makes it sound like, the Patcher is very straightforward and easy to get used to...

I'd suggest using the changeedit.exe for starters, until you can get the hang of manually editing the .ini yourself. Of course, if you're more comfortable with scriptng (unlike me.. hehe) perhaps .ini editing might be easier...

Just give us a little more 'meat' to your project and we'll try to help as best we can :)

TheOssusKeeper
07-16-2005, 05:48 PM
Originally posted by ChAiNz.2da
well, like stoffe mentioned, it's really a different case for each type of mod, depending on what you need it to do. But, I'll be more than happy to help you along as you go...

Can you give us a jist of what you're mod will be needing to change? Such as which .2da files will need to be appended?

2DAMEMORY tokens are going to be your friend ;) but unlike what the 'techy jargon' makes it sound like, the Patcher is very straightforward and easy to get used to...

I'd suggest using the changeedit.exe for starters, until you can get the hang of manually editing the .ini yourself. Of course, if you're more comfortable with scriptng (unlike me.. hehe) perhaps .ini editing might be easier...

Just give us a little more 'meat' to your project and we'll try to help as best we can :)


Well I made that 4 new detonators mod (with Stoffe's help (scripts))... and i thought i'd make it much easier for the gamers to install by using the tslpatcher... basically it has the uti files and the script files and it modifies the spells.2da... after getting this little (big ?) project done, i was going to re-up it to pcgamemods.com for everyones convenience, plus i wasn't very happy with having to try and explain how to merge the mod with the spells.2da, it was all too confusing, even for me...

plus, i think it is a small enough mod to practice on, to try and learn how to use the tools, because i don't want to screw up someones game with a faulty mod, if i can keep from it ;)

I will probably stick with the changeedit util. 'cause i don't know anything about scripting...

I would really appreciate any and all help I could get, thanks in advance :D

ermo
07-16-2005, 07:30 PM
Originally posted by stoffe -mkb-

@ermo(?) -
I put together a mini-release containing the patcher application only that has added commandline support as you asked. It accepts two optional parameters, the first is the name of an INI file containing work instructions, the second is a name of a custom RTF file to display in the info text box when the app starts. Like:


TSLPatcher.exe another.ini someinfo.rtf


You can download it here (http://www.algonet.se/~stoffe/TSLPatcher113.rar). That file contains the patcher EXE only since I assume you already have the other files and nothing else has changed. Hopefully this is what you meant...


It certainly is - great job!

- ermo

PS. Sorry that I didn't post before now- had issues reactivating my account :(

TheOssusKeeper
07-17-2005, 03:35 PM
Stoffe and or Chainz,
Here is a link to some screen shots that I took of my progress with the TSLpatcher.
I was wondering if one of you two or both could take a look and see if I’ve got it right so far, and tell me what I need to do next to get this thing up and running (working) like it should… Basically I have no clue as to what the 2damemory thing is or how to use it or how to get the gff files working like they should be or how to get them to reference the proper lines [Row Label] of the spells.2da in the properties subtype correctly of the uti files…


Screenshots:

http://img348.imageshack.us/img348/4600/step1thru55hw.jpg


You can see I’m try’n :D but there’s a few things I still ain’t got yet ( < ain’t proper English :D )…
Hope you can help, please… :)


Please and Thanks in advance... ;)

stoffe
07-17-2005, 05:38 PM
Originally posted by TheOssusKeeper

I was wondering if one of you two or both could take a look and see if I’ve got it right so far


For your spells.2da CopyRow modifiers, you don't need to set the NewRowLabel column if you just want it to get the next free number in line. If you leave it out the application will do that automatically. At the end of the modifier list for each grenade, add one line that stores the row index of your new line for later use.

For Napalm, add:
Column: 2DAMEMORY1
Value: RowIndex

For Flash, add:
Column: 2DAMEMORY2
Value: RowIndex

For Shock, add:
Column: 2DAMEMORY3
Value: RowIndex

And finally for Combo, add:
Column: 2DAMEMORY4
Value: RowIndex

See below for more in-depth description of what this does.

Looking at the titlebar, do you have the patcher inside your Override folder? I wouldn't recommend this, since the game would attempt to load any (still unpatched) data files it encounters within the tslpatchdata folder as well.

Originally posted by TheOssusKeeper
Basically I have no clue as to what the 2damemory thing is or how to use it


2DAMEMORY tokens are a way to temporarily retrieve a value from a 2DA-file and store it for later use. Think of them as memory-slots which can keep track of a value that can then be inserted into other places, like other 2DA files or GFF files. To use the above as the example...

2DAMEMORY1=RowIndex

...would look up the row index (ie line number) of your newly added line, and store it in the first memory slot. Aside from RowIndex, you can assign the label of any column in the 2da file to a 2DAMEMORY token, which will then store the value found in that column for the line you are currently adding or modifying.

You can then assign this token to any column (in 2da files) or field (in GFF files), which will make the patcher insert the stored value where the token is encountered.

If, for example, your new line ended up on line number 282 in Spells.2da, whenever 2DAMEMORY1 is assigned to anything, the patcher would insert the value 282 at that place.

This mechanism is used for linking together 2DA files that reference each other, or to insert 2da line references into other files, such as GFF format files.

Remember that instructions are processed in the order they are listed, so you must make sure that you have assigned a value to a 2DAMEMORY token before you try to access that value elsewhere.

When adding new lines, don't assign a value to a 2DAMEMORY-token at the very top of the modifier list since the line isn't added until you've assigned a value to at least one column. Thus the line does not exist yet at that point, and no value can be retrieved.


Originally posted by TheOssusKeeper

or how to get the gff files working like they should be or how to get them to reference the proper lines [Row Label] of the spells.2da in the properties subtype correctly of the uti files…


You use the 2DAMEMORY tokens for this. The four extra modifier lines I described adding above would store the line number in spells.2da for the napalm grenade in 2DAMEMORY1, the line number for the Flash grenade in 2DAMEMORY2, the Shock grenade in 2DAMEMORY3 and finally the Combo grenade line number in 2DAMEMORY4.

Now that you have those values memorized, you need to insert them into your item templates (UTI files) for your grenades.

To do this, you'll need to assign the memorized value to the field within the GFF format UTI file that stores which line in spells.2da is used by the grenade explosion.

Open your grenade template in a GFF editor to find what field this is. Find the PropertiesList field and expand it. If you haven't done anything odd, it should only contain one struct, labeled 0, in a grenade template. Expand this struct and find the Subtype field within it. This is what contains your 2da reference.

To describe how to find this field for the patcher we need to provide the full path in the tree to where it is. This is done by separating the different fields in the hierarchy with a backslash character.

So, back in ChangeEdit, select your napalm grenade under the GFF files heading. Fill in the input fields as follows:

GFF Field: PropertiesList\0\Subtype
Value: 2DAMEMORY1

Press the button with the red arrow pointing up to add your change to the list. Then select the Flash grenade and fill in...

GFF Field: PropertiesList\0\Subtype
Value: 2DAMEMORY2

Further, select the shock grenade and fill in...

GFF Field: PropertiesList\0\Subtype
Value: 2DAMEMORY3

And finally select the Combo grenade and fill in...

GFF Field: PropertiesList\0\Subtype
Value: 2DAMEMORY4


This will take the stored values and assign them in the GFF file to the field referring to the spells.2da file.


I'm terrible at explaining things but hopefully this make it at least a little clearer... :)

TheOssusKeeper
07-17-2005, 05:47 PM
Stoffe, thanks, i'll give it a shot and see what happens...

also if you or someone else desides to make a guide or something, perhaps a visual guide, you can use my screen shots as part of the guide, for what to and not to do, if you like...

thanks again, i'll give it a whirl, :D

TheOssusKeeper
07-17-2005, 08:25 PM
Ok Stoffe, here is a link to the screenshots of the fixed version, minus the install part... :D

http://img346.imageshack.us/img346/6108/fixed1thru105bx.jpg

So far so good, i tried it using a clean spells.2da file and it seems to be working perfectly, i also tried it with a dirty spells.2da :D and it seems that it updated and or replaced all the necassary files and the ones i already had copies of i.e. .ncs and the .nss files it skipped... but all still seems to be working good...
again if you or someone else plans to make a guide (visual) you can use my screenshots if you like (unresticted)...

Once again thanks a million, i wouldn't have gotten this thing to work without your help... :thumbsup: Kudos on the TSLpatcher it is a miracle, hehe

stoffe
07-18-2005, 05:32 AM
Originally posted by TheOssusKeeper
it seems that it updated and or replaced all the necassary files and the ones i already had copies of i.e. .ncs and the .nss files it skipped... but all still seems to be working good...

Hmm, perhaps I should have mentioned this more specifically since you aren't the only one who has done that mistake, so it isn't obvious how it works... :)

Files modified by the patcher are copied to the override folder while they are modified (only if they didn't already exist there in the case of 2da files).

Thus, 2da files or GFF files that the patcher has changed something in should not be added to the InstallList of files as well, since they have already been installed when they were modified. If done and you set them to just be copied the most you will get is a warning that the files already exists.

However if you set them to replace existing files in the InstallList you will overwrite the GFF files the patcher has just modified with new unmodified copies from the tslpatchdata folder, which you usually don't want. :)


You should also replace the content of the info.rtf file in the tslpatchdata folder with either the readme or some kind of installation instructions. This is the text that is displayed in the main window when the installer is started.

TheOssusKeeper
07-18-2005, 06:09 PM
Originally posted by stoffe -mkb-
Files modified by the patcher are copied to the override folder while they are modified (only if they didn't already exist there in the case of 2da files).

However if you set them to replace existing files in the InstallList you will overwrite the GFF files the patcher has just modified with new unmodified copies from the tslpatchdata folder, which you usually don't want. :)

So basically, they (the gamers) needs to have a clean override folder (free from the files in the InstallList), correct?

So in order for someone to use this mod (if they already have a previous version) they would need to delete all the old files first, correct?


See I thought that the patcher copied all files to the override, then modified the necessary files... the copied files would overwrite the current ones and then the patcher would modify them and the ones that didn't get copied, like the 2da file would just simply be modified... :confused: maybe in the next beta release, it could work this way, that way you wouldn't have to worry about what gets overwriten as far as the uti files and the script files go anyway, and then everything gets modified after everything is copied to the override... (don't know if this will work or not, just an idea though :D)

ok, but i think i get the read me file thing, though :D

PS. if you could download my mod at pcgamemods.com (if you hadn't already) and take a look at it for me? please...

Thanks in advance :thumbsup:

stoffe
07-18-2005, 06:56 PM
Originally posted by TheOssusKeeper
So basically, they (the gamers) needs to have a clean override folder (free from the files in the InstallList), correct?

So in order for someone to use this mod (if they already have a previous version) they would need to delete all the old files first, correct?


Files that are just copied over and not modified in any way should preferably not be present in the override folder already. This is just like any other mod, if two mods uses files that are named the same they are incompatible. If the patcher encounters an already existing file it shouldn't modify (ie on the InstallList), it will skip that file and print a warning in the progress log that the file already existed, to alert the user to a possible mod conflict.

If, however, you are making an updater for a previous version of your mod and you can be reasonable sure (by unique file naming) that the existing file is in fact from a previous version of your mod, you should set the InstallList to replace rather than copy that file. Then the patcher will copy the file from tslpatchdata and overwrite the file with the same name that already existed in Override. This will allow you to install a new version on top of an old one without the user having to delete anything manually first.

Only set the replace flag for files in the InstallList you can be reasonably sure are from your own mod(s), since it might mess up already installed mods otherwise.


Originally posted by TheOssusKeeper

See I thought that the patcher copied all files to the override, then modified the necessary files... the copied files would overwrite the current ones and then the patcher would modify them and the ones that didn't get copied, like the 2da file would just simply be modified... :confused:


Things are done in this order, provided that the instructions are present to do it.

1) The contents of append.tlk (if present) is added to the user's dialog.tlk file.

2) 2DA files in the 2DAList are updated.
a) If the 2da file does not exist in the user's override folder, the patcher looks in the tslpatchdata folder for it. The file is then copied to the override folder.
b) If the 2da file exists in the override folder, either from a previous mod, or from just having been copied there from the step above, the 2da file (in override) is modified according to instructions.

3) GFF format files in the GFFList are modified. If a file with the specified named already exists in override, that GFF file is modified. If the file does not exist, the file is copied from tslpatchdata to Override, and the copy in override is then modified.

4) File hacks are performed. This will never modify files that already exist in override. If no file with matching name exists, it is copied from tslpatchdata to override, and the copy is then modified. If the file already existed, the patcher will issue a warning and skip the file, unless you've instructed it to overwrite that file if it existed.

5) The installlist is processed. This should only contain files that the patcher hasn't done anything with in any of the above steps (since those steps have already copied the relevant files to override if necessary). The listed files are copied from tslpatchdata into the folders which are specified.

TheOssusKeeper
07-18-2005, 07:07 PM
i am sorry stoffe, but it must really be frustrating for you, trying to explain all this stuff, but on a lighter note, i think that last part helped me a lot, thanks ;)

Well, now i know, i think i need to go fix my mod again :rolleyes: i'll get it right this time :thmbup1: (i hope, hehe)

stoffe
07-20-2005, 03:04 PM
{snip} - reference to "unecessary comment" in previous post deleted- d333

I've tried to explain things as best I can, but I know I'm terrible at explaining things. It's probably better to leave the explaining to someone else who's good at it (and is more proficient with English than I am). I've done the best I can to clarify things, if that's not enough there's nothing more I can do about it I'm afraid. :(

The TSLPatcher is a mod installer of a sorts, that is capable of adding information to certain types of files rather than just overwrite them if it already exists. It is by no means the final answer to making mods compatible, and it's only really useful for a limited type of mods. But for that type of mods it's at least better than nothing, IMHO, and can make installation a bit less of a headache for the non-modding end user. :)


Originally posted by MacLeodCorp

What does it do to the .2da file specifically, and why does it do it? I don't want to hear, it modifies the files so it is compatible.



That depends on what it has been instructed to do. It is capable of adding new lines to a 2da file (either from scratch or by copying an existing line and modifying its values), modify values on existing lines and add new columns to 2DA files. This is done from a set of instructions created by the maker of the mod that it is supposed to install.

I originally made the application in order to make it easier to install and distribute a Force Powers mod I created. Since spells.2da is modified by a lot of other mods, the TSLPatcher was made to add the necessary lines at the end of the existing file in override, saving people the trouble to manually merge the 2da files and link things together. Thus it should be compatible with any other force power mods that people may already have installed.

Also, since distributing dialog.tlk in its entirety is a bad idea, I needed some way to include the necessary text without including the full 10 Meg file, and (hopefully) avoid changing the language of the player's game if they have non-english versions.

Originally posted by MacLeodCorp

Why would you want to change anything in this file? (dialog.tlk)


Personally I needed it for my force powers mod. The force power names and description text needs to be added to dialog.tlk in order for the game to display it. Shipping the whole file with the mod would have made it incompatible with any other mods that modify dialog.tlk, would have added about 2 Meg to the download size, and would have caused trouble for non-english games. So I made the TSLPatcher add the necessary text entries to the already existing dialog.tlk file of the user who installs the mod. The patcher then modifies the spells.2da file to point to the correct StrRefs for these text entries.

The Source
07-20-2005, 03:07 PM
Oky, maybe this could help you!?

1. If I remember right, your program has defaults to open. However, those defaults are not the items that I the modder modified. To prevent confussion, I would delete those defaults, and just make a label that says: "Choose your .utis, .2da, etc...". Depening on what you need to alter.

2. I would also make it possible to choose, one .2da file with multiple .uti/,utc files. I think that would make some ease.

3. Now, I don't need to choose certain items, but your programs asks for them. That creates confusion. I would have the program open only files that need to be opened, and not files that have nothing to do with your edits. Example: dialouge.tlk may need to be open for all edits, but .uti does not need to be open.

4. Create a comprehensive readme, which states: If you altered these types of files, then the patcher needs to patch these files, so your mod can work.

5. Create a comprehensice readme, which explains how to install the patcher.

6. Delete your example files from the data folder, for it creates confussion. Exlpain certina important details in a readme, and use some screens.

I know you worked really hard on this program, and I thank you for everything you have done. Please don't take my posts as harshness. I really do enjoy and utilize your programs.

stoffe
07-20-2005, 03:30 PM
Originally posted by MacLeodCorp


1. If I remember right, your program has defaults to open. However, those defaults are not the items that I the modder modified. To prevent confussion, I would delete those defaults, and just make a label that says: "Choose your .utis, .2da, etc...". Depening on what you need to alter.

2. I would also make it possible to choose, one .2da file with multiple .uti/,utc files. I think that would make some ease.

3. Now, I don't need to choose certain items, but your programs asks for them. That creates confusion. I would have the program open only files that need to be opened, and not files that have nothing to do with your edits. Example: dialouge.tlk may need to be open for all edits, but .uti does not need to be open.


Sorry, I'm not sure I understand what you mean? If you set the TSLPatcher to installer mode, the only thing the user should have to select is the folder where the game is installed, not any individual files. Then it's up to the mod-maker creating the INI file with instructions to determine which files should be modified and link them together as necessary, and put the necessary files the patcher needs in the tslpatchdata folder.

Originally posted by MacLeodCorp

4. Create a comprehensive readme, which states: If you altered these types of files, then the patcher needs to patch these files, so your mod can work.
5. Create a comprehensice readme, which explains how to install the patcher.


Doubtful this is going to happen. I can think of few more boring things to spend my free time with than sitting for days writing comprehensive documentation for something only a handful of people use anyway. :) Especially with my english skills being what they are, and I doubt instructions written in my native language would be all that helpful to most people. :)

I try to answer specific questions to the best of my ability though if people wonder how to do something or if there is something unclear about how a specific feature works.

Originally posted by MacLeodCorp

6. Delete your example files from the data folder, for it creates confussion. Exlpain certina important details in a readme, and use some screens.


I left a few files in there as an example of how things are laid out. I usually find it easier to learn new things if I have examples to look at. But if it is more confusing than helpful I suppose I could remove all example files from the next version when I upload it.

TheOssusKeeper
07-20-2005, 06:23 PM
i think maybe Chainz knows a little about it, maybe T7 (not sure), i myself have only started using it, but i do know you can use it to edit any existing line in a 2da or add new lines or copy a line from a 2da and replace some if not all of the column values as you see fit... thats why i was saying the other day there shouldn't be any compat issues with your heads.2da and your appearence.2da if you edit them with the tslpatcher in the proper order... And correct me Stoffe if i'm wrong but don't you need to set the values for the head.2da first before the appearence.2da? :)

TheOssusKeeper
07-20-2005, 06:37 PM
this may help some... i hope :)

What if you (Mac) or anyone for that matter that had questions about the TSLpatcher set down and posted a list of questions, all questions that you may have and then everyone that has used the patcher or has experience with the patcher set down and answered these questions, wouldn't that be a step in the right direction to making a comprehensive guide, then someone could take all the answers and make an understandable guide from it and even place all of the questions and answers in the guide, kinda' like an appendix, would that help?

i'll also post this in the TSLpatcher thread as well...

stoffe
07-21-2005, 10:34 AM
I have uploaded version 1.1.4 here, it's a quick bugfix version for a bug that I just ran into.

Due to a bug in the code saving GFF files, a few files laid out in a particular way would become corrupted when they were saved (about 2 out of 20 of the files I tested with were affected). This is now fixed in v.1.1.4, and it seems to save all GFF files I've tested with properly.

This file contains only the fixed TSLPatcher.exe, since TalkEd.exe or ChangeEdit.exe haven't been modified since v.1.1.2.

Sorry about not spotting this error earlier, but since I haven't heard from anyone else about it I guess no one else has run into it yet anyway. :)

If you have made an installer with the patcher for a mod, and that mod works fine when installed, your files aren't affected by the bug and there's no need to repackage your mod with this version. But if you make a new mod that uses the patcher I'd suggest using this version instead.

* * *

As for the next full version with the new features that were requested, I've got a bit more free time to spare now and will get to work on it shortly.

Jeff
07-21-2005, 11:06 AM
Great! Glad you are still updating it. I never ran into the problem, but I was bound to eventually had you not. I have found this useful for I think 3 mods already, and plan on using it again in an upcoming mod.

T7nowhere
07-21-2005, 12:28 PM
Originally posted by stoffe -mkb-
I have uploaded version 1.1.4 here (http://www.algonet.se/~stoffe/TSLPatcher114.rar), it's a quick bugfix version for a bug that I just ran into.

Sorry about not spotting this error earlier, but since I haven't heard from anyone else about it I guess no one else has run into it yet anyway. :)

I suppose its better that the programmer finds the bugs rather than the user. ;)

Thanks for the update, personally I purpously use 2da's in my mods now :D. This is the kind of tool I have wanted since the beginning.

ChAiNz.2da
07-21-2005, 12:46 PM
Originally posted by T7nowhere
Thanks for the update, personally I purpously use 2da's in my mods now :D. This is the kind of tool I have wanted since the beginning. You Too!?!? :lol:

I thought I was the only one.. hehehe ;)

I have several ideas for mods now incorporating baseitems and spells 2da... but was always hesitant cuz' many of my older mods tended to include those quite often (along with hate mail afterwards :p )...

Thanks for the update stoffe! :D

ChAiNz.2da
07-22-2005, 07:05 PM
FYI, version 1.1.4 has been added (updated) on the StarWarsKnights.com Tools Section (http://www.starwarsknights.com/tools.php) :D

as a side note, does the 1.1.4 update contain the command line ability that 1.1.3 had?
If not, let me know and I'll re-add the 1.1.3 version as well, (noted with the command line ability) ;)

and as always, if you would prefer the tool (and updates) be removed, just let us know :)

Pardon the double-post, but I thought a site update would warrant it rather than an 'overlooked' edit ;).. hehehe

ermo
07-25-2005, 04:16 PM
@TheOssusKeeper

wouldn't that be a step in the right direction to making a comprehensive guide, then someone could take all the answers and make an understandable guide from it and even place all of the questions and answers in the guide, kinda' like an appendix

Maybe a wiki (http://phpwiki.sourceforge.net/) would be better suited to this kind of thing than the forums?

(Not that I know where that wiki would be hosted or anything...)

ermo
07-25-2005, 05:36 PM
stoffe,

Let's say I'd like to change a few existing stringrefs in dialog.tlk (20-50).
Instead of distributing the entire modfied dialog.tlk file, I'd rather just distribute
the changed strrefs and have TSLPatcher patch them up.

Is that possible right now?

Or is the ''correct'' approach to create an append.tlk file, append it to dialog.tlk
and point the affected game ressources to the new strrefs?

stoffe
07-25-2005, 07:07 PM
Originally posted by ermo
stoffe,

Let's say I'd like to change a few existing stringrefs in dialog.tlk (20-50).
Instead of distributing the entire modfied dialog.tlk file, I'd rather just distribute
the changed strrefs and have TSLPatcher patch them up.

Is that possible right now?

Or is the ''correct'' approach to create an append.tlk file, append it to dialog.tlk
and point the affected game ressources to the new strrefs?

The TSLPatcher is currently unable to edit existing entries in a dialog.tlk file, since I assumed there was minimal use for such a feature.

If it's text for something new it's probably better to add a new entry anway and just point whatever you intend to use it for to that StrRef instead. There are plenty of duplicate strings in dialog.tlk already so this seems to be how Bioware or Obsidian did it as well.

If you really need to be able to edit an existing dialog.tlk entry I suppose I could add that feature, but I just don't see what kind of mod that would be useful for. :)

mrdefender
07-25-2005, 08:22 PM
I've sucessfully made a tslpatch thingy but found something odd...

The files are supposed to be replaced, but I got 38 errors saying "file exists, skipping it" :confused:

I made a patch thing for a future release, if it ever comes. I have the old files ready and all I would need is update the files and give it a go.

The files in the patcher thing are the exact same as the ones it's supposed to replace. Is this why It gives me a skipping error thing? Once the files have been updated, will tsl patcher replace them? :confused:

I'd like to thank Chainz.2da for letting me use his tslpatcher thing as a template :)

stoffe
07-25-2005, 09:14 PM
Originally posted by mrdefender
I've sucessfully made a tslpatch thingy but found something odd...

The files are supposed to be replaced, but I got 38 errors saying "file exists, skipping it" :confused:


Hard to say for sure without knowing more about how you've configured the installer. Here are a few things I can think of:

Are these unmodified files that are just installed, or are they files that have been modified by the installer?

You shouldn't put any files on the Install list that has already been modified by the application. Only unmodified files should be put there.

If the files are on the Install list, have you checked the Replace box (if you are using ChangeEdit) or named the key "Replace#" (if you are using a text editor) for the files you wish to overwrite existing copies of? The file installer should only complain about existing files when they aren't set to be replaced.

Which version of the TSLPatcher application are you using? The replace feature was added in v1.1.2 if I remember correctly, and will not be recognized if you use an earlier version.

If none of these things help, post your changes.ini file and I'll have a look at it and see if I can spot anything.

mrdefender
07-26-2005, 03:01 AM
I've downloaded 1.1.2 and the 1.1.4 patch thing...

Was abit confused with your reply. Not sure if that has anything to do with the fact it's 3am here and I've been up all night testing other stuff lol.

here's my changes.ini... I'm guessing your browser will open it as a webpage instead of a download :confused:

http://jediarchives.ca/changes.ini


I like the patcher alot, easy to use too :)

*falls asleep on the keyboard*
http://forums.jediarchives.ca/html/emoticons/sleep3.gif
http://forums.jediarchives.ca/html/emoticons/sleep3.gif

TheOssusKeeper
07-26-2005, 04:10 AM
Originally posted by mrdefender
I've downloaded 1.1.2 and the 1.1.4 patch thing...

Was abit confused with your reply. Not sure if that has anything to do with the fact it's 3am here and I've been up all night testing other stuff lol.

here's my changes.ini... I'm guessing your browser will open it as a webpage instead of a download :confused:

http://jediarchives.ca/changes.ini


I like the patcher alot, easy to use too :)

*falls asleep on the keyboard*
http://forums.jediarchives.ca/html/emoticons/sleep3.gif
http://forums.jediarchives.ca/html/emoticons/sleep3.gif


if the files already exist in your override folder, my guess would be to update the tslpatcher by checking the replace box at the bottom of the install files window, you will have to select each file and check the box for each file, this will replace any existing files in your override folder with the ones in the tslpatchdata folder, if i'm not mistaken, Stoffe correct me if i'm wrong, but i think thats how it works :D

stoffe
07-26-2005, 06:19 AM
Originally posted by mrdefender
I've downloaded 1.1.2 and the 1.1.4 patch thing...

Was abit confused with your reply. Not sure if that has anything to do with the fact it's 3am here and I've been up all night testing other stuff lol.


Probably has more to do with the fact that I have trouble explaining things in an understandable way. :) I'll make another attempt.

Originally posted by mrdefender

here's my changes.ini... I'm guessing your browser will open it as a webpage instead of a download :confused:


Strange, at a quick glance I can't spot anything that would be obviously wrong with that instructions file. The problem probably lies elsewhere.

1) Where are you running the patcher from? If you have it inside your override folder you should move it elsewhere.

2) Do you have all the files that should be installed inside the tslpatchdata folder? Is the changes.ini you posted inside the tslpatchdata folder. Is the tslpatchdata folder located in the same folder as the installer application?

3) Are the files you are trying to replace already located within the override folder?

4) Could you post the progress log the installer makes when it runs? Check for a file named installlog.rtf that should have been created in the same folder as the installer EXE.

If the problem remains elusive, could you send me the whole thing with the installer, tslpatchdata folder and all files that should be installed, like you currently have them when it causes the problem? I'll have a look at it and see if I can spot the problem.

* * *

A few things I did notice when checking out your changes.ini file though:

1) If you intend the installer to replace a previously installed version with a new one, you should add a key named ExclusiveColumn to the top of your AddRow modifier list, and set its value to the name of the label column. That will ensure that you won't get duplicate rows added to spells.2da if you run the installer multiple times. Like (in your changes.ini):

[101]
ExclusiveColumn=label
label=WristConsole
name=****
spelldesc=****
(etc...)

It makes the installer check if there is already a line in the 2da file with a value matching that you are trying to add, in the column you specify. If a match is found, the existing line is modified instead of adding a new one. If no match was found, the new line is added as intended. In this case, it would check if there already is a line in spells.2da with the value WristConsole set in the label column.

2) You don't have to set all the column values to **** when you add a new line. If you leave out a column in the modifier list for your new line, the installer will automatically set the value of that column to ****. Makes your modifier list a bit shorter and means less work for you. (Well, at least it would have meant it if you hadn't already added all those columns. :) )

ChAiNz.2da
07-26-2005, 06:25 AM
Originally posted by stoffe -mkb-
2) You don't have to set all the column values to **** when you add a new line. If you leave out a column in the modifier list for your new line, the installer will automatically set the value of that column to ****. Makes your modifier list a bit shorter and means less work for you. (Well, at least it would have meant it if you hadn't already added all those columns. :) )
Sorry, that's my bad! :o

That's how I usually tend to do it in my installers... and mrdefender was probably following it (mine) as an example.

I'm paranoid so I usually put everything in the line info just to make sure... though now I'm tempted to try it (being the lazy person I am.. ;) heheh)...

Commas
07-26-2005, 02:59 PM
Originally posted by stoffe -mkb-

2) You don't have to set all the column values to **** when you add a new line. If you leave out a column in the modifier list for your new line, the installer will automatically set the value of that column to ****. Makes your modifier list a bit shorter and means less work for you. (Well, at least it would have meant it if you hadn't already added all those columns. :) )

ok, i have two questions about this:

1) if i am modifying an existing line in a 2da and there is a value already in a column that i need to change to **** do i need to make an entry for that column, for example in appearance.2da in the column RaceTex for blue mandalorians the value is N_Mandalorian, but i need to change this value to ****, do i just not do anyting for that column and it will automatically change it to **** or do i actually need to say racetex=****

2)if i am modifying an existing 2da and there is a value that does not need to be changed, and i want to leave them as is do i need to include an entry stating the orignal value? basically, if i need it to stay the same as it was, do i need to tell it to stay the same or if i leave it with no entry will it replace the value with ****?

stoffe
07-26-2005, 03:20 PM
Originally posted by Commas
ok, i have two questions about this:

1) if i am modifying an existing line in a 2da and there is a value already in a column that i need to change to **** do i need to make an entry for that column


No, left out columns will only get the default value **** set if you don't assign any value to them when you are adding a new line from scratch to the file, since there are no existing values it could use. :)

When modifying a line, the only changes that will be made are those in the modifier list. All other column values will remain untouched on the modified line.

The same is true when copying a line. The new line will then get all the values from the line you copy, and only the changes in your modifier list will be applied. All columns left out will get the value the line that was copied had.


Originally posted by Commas

2)if i am modifying an existing 2da and there is a value that does not need to be changed, and i want to leave them as is do i need to include an entry stating the orignal value? basically, if i need it to stay the same as it was, do i need to tell it to stay the same or if i leave it with no entry will it replace the value with ****?

Just don't add the columns to the modifier list which you don't want to change. Only the listed columns will be modified by the application, everything else will be left alone. If you want to change an existing value to ****, you'll need to assign that value though, just like any other.

Commas
07-26-2005, 05:03 PM
awesome, thanks! thats a huge relief, i thought i was going to have to go back and change a bunch of entries. thanks again!

RedHawke
07-26-2005, 11:26 PM
Stoffe,

I just wanted to say thanks for the patcher and the work you have put into it.

I used it for the first time last night and it was really easy to use (For me anyway! :p).

Thanks again stoffe! :D

EDIT: (From post below...) Thanks for the test inatall tip stoffe!

stoffe
07-27-2005, 02:36 PM
I got this question recently, and thought everyone who uses this application might want to know about it (if you haven't figured it out yourself already). :)

If you have made a mod using the TSLPatcher and want to make a test install to ensure that everything installs and is modified properly, but don't want to run the risk of ruining your game install if something goes wrong, you can easily fake a valid install location.

Just make a new folder and copy your dialog.tlk file to this folder. This is all that is necessary, since the patcher only checks for the presence of dialog.tlk in the selected folder to determine if it's a valid game folder.

If you want to see if already modified files are updated correctly, make an override folder inside this folder as well, and dump your test files inside it.

ChAiNz.2da
07-27-2005, 03:16 PM
:thumbsup: thanks for the tip stoffe!

I usually just crossed my fingers, gritted my teeth.... and hoped i was right.. hehehe :laugh6:

I think I'll try your way next time ;)

TheOssusKeeper
07-29-2005, 12:36 AM
Stoffe, that is a cool idea... :D thanks

stoffe
07-29-2005, 08:07 AM
I've discovered another problem with the TSLPatcher that mrdefender made me aware of. It seems like when I compiled v1.1.3 and v1.1.4 I accidentally used an outdated version of the TSLPatcher class, which caused some newly added features to "disappear". :o

You can download a fixed version here (http://www.algonet.se/~stoffe/TSLPatcher115.rar), which should have the full functionality again.

Like before, the archive contains only the fixed TSLPatcher.exe and not the support applications TalkEd.exe and ChangeEdit.exe (which can be found in the v1.1.2 archive).

If your mod using the TSLPatcher doesn't make use of the "update existing install of mod" features, it shouldn't be affected by this oversight.

Sorry everyone for the goof-up. :o

ChAiNz.2da
07-29-2005, 08:29 AM
Originally posted by stoffe -mkb-
You should probably use RowIndex instead of RowLabel when dealing with spells.2da to be safe, since it is indexed by line number. As long as the row label is identical to the line number it doesn't really matter, but just in case. :)

RowLabel = The column to the far left in KotorTool's 2DA-editor, whose values you can edit. It usually mirrors the line number of the row, but must not necessarily do so in all files.

RowIndex = Perhaps confusingly named, this is the line number in the 2DA file. This starts at 0 and counts up one for each line in the file. This obviously can't be edited (unless indirectly by deleting lines).
aahh! Thanks stoffe! :D

I was using RowLabel because in KotOR Tool the column name for the numbers are "(Row Label)" and I could never find the mysterious "Row Index" :p

Would it be safe to leave out the "RowLabel" entirely (using RowIndex instead), or does it need to be included as well as a precaution?

I'll be sure to do that from now on :thumbsup:

stoffe
07-29-2005, 08:38 AM
Originally posted by ChAiNz.2da



I was using RowLabel because in KotOR Tool the column name for the numbers are "(Row Label)" and I could never find the mysterious "Row Index" :p

Would it be safe to leave out the "RowLabel" entirely (using RowIndex instead), or does it need to be included as well as a precaution?


For 2DA's indexed by line number it's probably best to use RowIndex to refer to a line. Many of the "big" 2DA's, like spells.2da, feat.2da and placeables.2da use line number indexing (ie the value in the RowLabel column isn't used to access a row).

This is not valid for all 2DA's though. Some, like visualeffects.2da, use to RowLabel column to access an individual line. For those 2DA's, you should use the RowLabel since the line number of an entry may change, as such 2DA's safely can be sorted, reshuffled or have lines deleted without messing things up.


This is probably getting a bit off-topic in this thread though, but since you're a moderator and have the final say in such matters I figured it was okay to answer. :)

Yah... we'll keep pertinent posts in your tools thread from here on out. But at least it will help mrdefender :) It's my fault, so you're in the clear...hehehe - ChAiNz.2da

hkoldrat
07-31-2005, 12:53 PM
hi i'm new here please forgive me should i act noobish or for my english as i'm not native.....

back on topic, i can't seem to run the files of the patcher, it only shows an error message like "RichEdit line insertation error" or something of that manner
since i got a few mods with same modded files, it seems i must merge them, and unfrotunately this patcher is the only tool i can find on the net....
any ideas would be welcome
thanks for the attention

stoffe
07-31-2005, 09:26 PM
i can't seem to run the files of the patcher, it only shows an error message like "RichEdit line insertation error"

This is an external error caused by the RichEdit DLL files in your system. RichEdit is a component that comes with Windows, though it seems some other applications install (and unfortunately overwrite) those DLL files as well.

From what I have been able to figure out, that error occurs when the version of the RichEd DLL files you have installed in your system is either some peculiar version, outdated or whatever it might be. I haven't been able to recreate the error myself so I don't know for sure.

It works just fine on my computer, if you want the RichEd DLLs from my computer you can download them here (http://www.algonet.se/~stoffe/richedlibraries.rar). Unzip and put those in the System32 folder inside your Windows folder. Back up the original files that exist there first before replacing them.

If you don't want to do this or can't get it to work anyway, download the latest version of the TSLPatcher.exe and use instead of the one you have now. Then open the changes.ini file you are working with in Notepad and, under the [Settings] section, add this line:
PlaintextLog=1

This will disable the formated, color-coded progress log and show the install progress as rather ugly plain text instead. That should hopefully bypass the RichEdit error. (Hopefully since I can't reproduce the error myself, so I don't know for sure what's causing it. :) )

ChAiNz.2da
07-31-2005, 09:35 PM
(Hopefully since I can't reproduce the error myself, so I don't know for sure what's causing it. :) )
Hey stoffe, I got to thinking on this.

Could it perchance be caused by depending on what program the modder used to create their .rtf file? I had noticed that during my most recent mod, when I created the .rtf through MS Word, the file size was substantially larger than when I re-did it with Windows Wordpad.

That, or even if you create it in Wordpad, but either intentionally or accidentally opened it up in MS Word (spell checking, file association, etc.)...

Just a thought.... more like a shot in the dark, but who knows... hehehe

stoffe
07-31-2005, 09:42 PM
Could it perchance be caused by depending on what program the modder used to create their .rtf file?

Hmm... I doubt it, since the error apparently occurs when the installation process starts (after clicking the button) rather than when the application starts. Thus the info text has already been displayed and the box cleared to make room for the progress log instead. At least that's how I understand it.

It appears those who had the problem before got it working when they replaced the RichEdit DLL files too. And a quick google search for "RichEdit line insertion error" seems to indicate that other applications that use the RichEdit control has similar problems with a handful of users.

I suspect that those effected have installed some other application or OS component that replaces the RichEdit DLLs that come with Windows as standard. But that's just a wild guess. :)

Whatever the problem is, it sure is annoying. Seems like the installer is creating more problems than it solves for some people, and that was hardly what I had in mind when I made it...

ChAiNz.2da
07-31-2005, 09:56 PM
Whatever the problem is, it sure is annoying. Seems like the installer is creating more problems than it solves for some people, and that was hardly what I had in mind when I made it...
meh.... It's mostly contributed to "player too lazy to read the damn readme" error ... hehehe

You'd be surprised on how many 'problems' spring up with simple drag-n-drop installs :rolleyes:

Just too nip this little problem in the 'bud', I'm probably going to start putting a "Troubleshooting" note pointing out this particular nuisance (that only seems to be happening recently)... at least then I can tell them "it's in the readme!" :devsmoke:

hkoldrat
08-01-2005, 12:02 PM
thanks.....now the patcher works.....thanks for the assistance

stoffe
08-02-2005, 06:51 PM
I've put together a new version of ChangeEdit, the utility you can use to make TSLPatcher instructions in a somewhat more userfriendly manner than plaintext editing.

You can get the new version here (http://www.algonet.se/~stoffe/ChangeEdit098.rar). Be advised that it's still a beta-version so there may be bugs I haven't run into yet.

This new version contains two changes, one small and one a bit bigger:

1) Added a toggle to the Settings screen that allows for changing of the log window style from Normal to Plaintext, that was added in TSLPatcher 1.1.6 (http://www.algonet.se/~stoffe/TSLPatcher116.rar). This can be used for those who have problems with their RichEdit DLLs to (hopefully) still run the TSLPatcher correctly, though in a somewhat less eye-friendly way.

2) Added a 2DA Compare button on the 2DA Files screen next to the trashcan button. When you click this button, it will ask for two 2DA files. Select an unmodified copy first, and then a modified copy as the second file.

ChangeEdit will then compare the two 2DA files and fabricate AddColumn, AddRow and ChangeRow modifiers matching the differences between the two files.

This can hopefully be useful to reduce the amount of data entry necessary for use with mods with lots of 2DA editing, though it should be noted that some manual hand-tweaking may be necessary to the modifiers it creates.

For example 2DA values that should use some form of tokens (StrRef, 2DAMEMORY, high() etc...) will need to insert the tokens by hand, since the comparison function will only grab the value that differs from the second 2DA file and insert it into the modifiers.

Since this is a fairly new feature it's a little rough around the edges and it may be that there still exist some bugs, but from what testing I have made it appears to work.

Also note that since my programming skills are abyssmal the comparison may take a few seconds if you compare two large 2DA files (appearance.2da, spells.2da), depending on how fast your computer is. There is no progress bar and the application appears to freeze while it works, this just means that it's working, not that it has crashed (hopefully). :) I'll add a progress bar or something in a future version.

If you want to try it, remember: Pick the unmodified 2DA first, and the one with modification second, when the Open dialog boxes pop up. Needless to say, bad things will happen if you pick two 2DA files who aren't of the same kind. (Ie comparing spells.2da to appearance.2da probably won't work too well.)


Bugs, questions or suggestions? Please let me know.


(Uh, why do the posts in this thread become extremely wide? Annoying to have to scroll horizontally to read things...)

tk102
08-02-2005, 07:17 PM
2) Added a 2DA Compare button on the 2DA Files screen. When you click this button, it will ask for two 2DA files. Select an unmodified copy first, and then a modified copy as the second file.

ChangeEdit will then compare the two 2DA files and fabricate AddColumn, AddRow and ChangeRow modifiers matching the differences between the two files.

Excellent. I'm glad I didn't have time to delve into that. Low hanging fruit tastes good, eh? :thumbsup:


Also note that since my programming skills are abyssmal the comparison may take a few seconds if you compare two large 2DA files (appearance.2da, spells.2da), depending on how fast your computer is.There's just no way around it that I've found. The progress feedback is a pacifier, but even then we're still talking about seconds, not minutes. If you want to talk about slow -- talk about DLGEditor vs. kreia.dlg. :rolleyes:

Commas
08-03-2005, 01:29 PM
awesome! thank you so much stoffe! this new feature is going to save a lot of people a lot of time (and hopefully it will get a few more people into using the the patcher now :D)! this is truly one of the best apps available for kotor modding. Brilliant! keep up the excellent work!

now if you'll excuse me i have got to go try this out!

ChAiNz.2da
08-06-2005, 11:15 PM
1) Added a toggle to the Settings screen that allows for changing of the log window style from Normal to Plaintext, that was added in TSLPatcher 1.1.6 (http://www.algonet.se/~stoffe/TSLPatcher116.rar). This can be used for those who have problems with their RichEdit DLLs to (hopefully) still run the TSLPatcher correctly, though in a somewhat less eye-friendly way.
ACK! I completely missed this version! :eek:
Is this just recent?? (I noticed it was posted on SWK) :confused: ahh well... I've got it now... hehehe

(Uh, why do the posts in this thread become extremely wide? Annoying to have to scroll horizontally to read things...)
Fixed it ;) There was a run-on img tag placed side-by-side, and if you're like me... you have sig images turned off?...

Plus the run-on was quoted so it made it doubly bad ;)

Lord Hydronium
08-09-2005, 08:37 AM
How compatible is the patcher with KOTOR? I tested it on 2das and GFFs and everything worked fine, memory tokens and all, but it doesn't seem to work with dialog.tlk. I first tried running it with an append.tlk and 2da modification with StrRefs in the 2das, and it simply didn't finish the installation (no backup, install log, or anything). Then later I ran it with just an append.tlk, and it claimed to have finished the installation, but nothing was changed. Running an append.tlk and several other changes to the 2das and GFFs without any references to the .tlk works fine, except for the fact that it skips over the append.tlk step entirely (it's not even in the log). I'm assuming the problem is that the program is designed for TSL, and the dialog.tlk is somehow fundamentally different from that of KOTOR. If that is the case, is there any chance of a version that can patch KOTOR's dialog.tlk? If that's not the case, and it's some other problem, what could it be?

stoffe
08-09-2005, 09:16 AM
How compatible is the patcher with KOTOR? I tested it on 2das and GFFs and everything worked fine, memory tokens and all, but it doesn't seem to work with dialog.tlk.

I first tried running it with an append.tlk and 2da modification with StrRefs in the 2das, and it simply didn't finish the installation (no backup, install log, or anything).

I'm assuming the problem is that the program is designed for TSL, and the dialog.tlk is somehow fundamentally different from that of KOTOR. If that is the case, is there any chance of a version that can patch KOTOR's dialog.tlk? If that's not the case, and it's some other problem, what could it be?

I have no idea if it's compatible with the first KotOR since I haven't tested it. I haven't done much modding for KotOR1 so I don't know if the file format differs in some way. If you can open KotOR1's dialog.tlk file with TalkEd the TSLPatcher shouldn't have any trouble with it since they use the same class for TLK manipulation.

However, if the TSLPatcher program is configured to use StrRef tokens you should potentially get a few progress log entries before it even tries to open the dialog.tlk file:

If you are running the patcher with detailed progress logging enabled (loglevel 4), doesn't it mention anything about the TLK at all? It should at least say "Loading StrRef token table..." before beginning to load the StrRef token list from the INI file. If it does not, something very strange is going on. :)

If there is at least one valid StrRef token in the ini file under the [TLKList] section, append.tlk exists in the tslpatchdata folder and a dialog.tlk file exists at the install location, you should get a "Appending strings to TLK file..." message in the progress log as well.

A valid StrRef token has to start with StrRef followed by a unique number.

Open your changes.ini file with notepad and find the [TLKList] section. Please post that section here and I'll see if it looks like it should.

Lord Hydronium
08-09-2005, 05:05 PM
I have no idea if it's compatible with the first KotOR since I haven't tested it. I haven't done much modding for KotOR1 so I don't know if the file format differs in some way. If you can open KotOR1's dialog.tlk file with TalkEd the TSLPatcher shouldn't have any trouble with it since they use the same class for TLK manipulation.
Actually, I can't. TalkEd simply closes when I try to open dialog.tlk.

However, if the TSLPatcher program is configured to use StrRef tokens you should potentially get a few progress log entries before it even tries to open the dialog.tlk file:

If you are running the patcher with detailed progress logging enabled (loglevel 4), doesn't it mention anything about the TLK at all? It should at least say "Loading StrRef token table..." before beginning to load the StrRef token list from the INI file. If it does not, something very strange is going on. :)

If there is at least one valid StrRef token in the ini file under the [TLKList] section, append.tlk exists in the tslpatchdata folder and a dialog.tlk file exists at the install location, you should get a "Appending strings to TLK file..." message in the progress log as well.
I stand corrected. It does get to that step, in fact. Those two messages display on the logging screen; however, after that is where it goes wrong. The patcher simply closes, the log is never saved, and no backups or changes are made. This only happens if it tries to build the StrRef token table. If it's simply appending, it just skips that step entirely (and from your comments, it sounds like at least that part's intentional, since there's no need to add entries that are never referenced). All other memory tokens work fine. Between that and the behavior of TalkEd, I'm assuming it is just a compatibility issue.

Open your changes.ini file with notepad and find the [TLKList] section. Please post that section here and I'll see if it looks like it should.
It's straight out of ChangeEdit:

[TLKList]
StrRef0=0

stoffe
08-09-2005, 05:26 PM
Actually, I can't. TalkEd simply closes when I try to open dialog.tlk.
(snip)
Between that and the behavior of TalkEd, I'm assuming it is just a compatibility issue.


Hmm, that's very strange. I just tested to open my KotOR1 dialog.tlk file with TalkEd and it opened without any problems. Though my K1 file has a few custom entries added and is not the original untouched file.

Unfortunately I don't seem to have an unaltered copy of that file, and I'm not too keen on reinstalling KotOR1 now just to get that one file.

Could someone else confirm if TalkEd.exe (http://www.algonet.se/~stoffe/TalkEd.rar) is unable to load an unaltered KotOR1 dialog.tlk file, please?

Both the TSL and KotOR1 dialog.tlk file appears to be using the TLK V3.0 format. Unless they've changed the format without changing the version number they should be the same.

TheOssusKeeper
08-23-2005, 03:50 AM
ok i am sure i am doing something wrong :giveup:... i need to add a line to the upcrystals.2da file... but i can't get it to work right... here is what i have so far for the .2da part...

First column _________________ Second column

ExclusiveColumn ______________ high()
Label _______________________ Light
template ____________________ g1_w_sbrcrstl22
shortmdlvar __________________g1_w_short03
longmdlvar ___________________g1_w_lghtsbr03
doublemdlvar _________________g1_w_dblsbr003
2DAMEMORY1 ________________RowLabel

what am I missing, please help... this i driving me bonkers :headbump not that i didn't have very far to go in the first place, hehehe :D

RedHawke
08-23-2005, 05:02 AM
First column _________________ Second column

ExclusiveColumn ______________ high()
The only thing I can see wrong is this one...

There is no ExclusiveColum in upcrystals.2da! ;)

Delete this entry and it should run fine. Also why assign a 2DAMemory token to an upcrystals.2da row number? They aren't refrenced anywhere or used in any .uti files. :confused:

TheOssusKeeper
08-23-2005, 05:06 AM
well thats what i was wondering, how does the patcher know to add a new line or what number to assign?

RedHawke
08-23-2005, 05:09 AM
well thats what i was wondering, how does the patcher know to add a new line or what number to assign?
You are doing like I did... you are reading a little too much complexity into the process... ;)

If you use the function to add a new row or copy a row it assigns a new row number automatically... and you only need 2DAMemory tokens if you are needing to refrence that new 2da row number later on for things like uti files and such. :D

TheOssusKeeper
08-23-2005, 05:12 AM
the last line in my 2da fils is 262... and when i run the patcher it adds the new line, but it adds it as 262, so now i have 2 262's in my 2da file...


edit: i added rowlabel high() to the head of the list and now it adds the line, but in place of the number (263) it has high() instead... weird...

RedHawke
08-23-2005, 05:23 AM
What you might want to do is in ChangeEdit delete your original add new row part and recreate a brand new addrow call. Being you had that erronious ExclusiveColumn call in there it might have messed something up...

TheOssusKeeper
08-23-2005, 05:25 AM
ok, i'll try that and see what happens, but should i go ahead and add the rowlabel high() as well?

RedHawke
08-23-2005, 05:28 AM
but should i go ahead and add the rowlabel high() as well?
No! I never had to mention the row numbers in the mod I made and it edited itemcreate.2da and itemcreatemira.2da just fine.

TheOssusKeeper
08-23-2005, 05:32 AM
it's still not working, i totally redid the change.ini file and left out the rowlabel option and like before it add the new line except the rowlabel was the same as the one before it, so now i have 2 rows with the number 262... :giveup:

TheOssusKeeper
08-23-2005, 05:36 AM
from what i understood of the readme file about the exclusivecolumn option is it supposed to work with add new line and copy line, and you were supposed to be able to use the high() option to seek out the last line in the 2da file and add 1 to that for the new line... maybe i miss read it...

RedHawke
08-23-2005, 05:40 AM
Question: Do you have a stock upcrystals.2da in your tslpatchdata folder?

If you don't... then put one in there and try the install again.

Also, when you went to edit the colums in ChangeEdit, did you manually type in the rowlabels to edit or did you load the labels from upcrystals.2da?

TheOssusKeeper
08-23-2005, 05:43 AM
yes, a clean one extracted strat from the kotor tool...

loaded from the 2da, from the 2da in the tslpatchdata folder...

TheOssusKeeper
08-23-2005, 05:45 AM
question: what is the max number of rows allowed in the upcrystals.2da file?

i've got 262, trying to add 263, maybe it's maxed out at 262?

RedHawke
08-23-2005, 05:46 AM
Even more simply, check to see if your upcrystals.2da's row numbers are ordered correctly. (Look for a skipped row number somewhere below 262, if this is so then you could get 2 of the same row numbers by using the installer, then the error is with your override's 2da file.)

TheOssusKeeper
08-23-2005, 05:49 AM
nope, no skipped no.'s...

RedHawke
08-23-2005, 05:54 AM
What number did you assign to your 2da line editing task?

You know when it asks for a number did you assign a high one like 999 or one under 262?

TheOssusKeeper
08-23-2005, 05:57 AM
it didn't ask...

RedHawke
08-23-2005, 06:08 AM
it didn't ask...
Yes it does, it is the Add Modifier Label box... scratch this thought! I think I found something! Bear with me! :D

This is the USM's upcrystals.2da right? Even the stock upcrystals.2da does this...

262 would be the proper row label addition for upcrystals.2da, in the eyes of the installer, as upcrystals.2da has no row 0, and most all of the other 2da files do... since the row 0 is missing the editor thinks there is one less row that there is supposed to be... hence it uses row 262.

You could test this by adding a false row 263 into your override's upcrystals.2da file and running the installer once again you should end up with 2 row 263's if this is so then I am correct.

Thankfully upcrystals.2da does not have it's row numbers refrenced by anything so 2 row 262's should not harm much of anything... our games should run fine with 2 of the same row numbers. If not then we could always bribe stoffe to fix the lack of an upcrystals.2da row 0 in the installer? :D

If this is so, this would be neither your fault, or the installers fault, but the games fault, because Bioware and OE did not follow their own 2da file formats and put a row 0 in upcrystals.2da! LOL! :lol:

EDIT: I hope I'm right, but I have to log off for tonight good luck TheOssusKeeper! :D

TheOssusKeeper
08-23-2005, 06:15 AM
okey dokey, i'll give 'er a whirl... hehehe :D

TheOssusKeeper
08-23-2005, 06:54 AM
i added the rowlabel 0 at the beginning of the file and it worked like a charm... :D
also now i have a problem with the install files not wanting to copy into the override folder... i've got the install files set, but the patcher will not place them in the override folder, so how do i fix that?

PS. sorry it took so long to get back to you, it's raining here and i get water in my phone lines and i get kicked offline and it takes forever to log back on... :(


edit: is there a way to add the dumby rowlabel 0 at the beginning of the file via the patcher, so that it will number the new row properly?

stoffe
08-23-2005, 07:49 AM
ok i am sure i am doing something wrong :giveup:... i need to add a line to the upcrystals.2da file... but i can't get it to work right... here is what i have so far for the .2da part...


ExclusiveColumn high()
Label Light
template g1_w_sbrcrstl22
shortmdlvar g1_w_short03
longmdlvar g1_w_lghtsbr03
doublemdlvar g1_w_dblsbr003
2DAMEMORY1 RowLabel



ExclusiveColumn is not a column you can assign a value to. The high() token assigns the highest value of all numbers in a column in the 2DA file, but ExclusiveColumn is no column. It's a keyword to which you assign the column label of a column in the 2DA file. The value you then assign to this column in the modifier must be unique among all lines in the 2DA file. If it is not, the patcher will modify the existing line that already had a matching value, rather than add the new line.

To use your example, if you had set ExclusiveColumn=Label, it would mean that if any line in the 2DA file already had the value Light in its Label column, that line would be modified and no new line would be added.

This function is meant to eliminate adding duplicate lines if the patcher is run on a game which already has the mod installed. Such as when doing an update to an existing mod, where you want to add lines if the player don't have the old version of the mod installed, but update what's already there (bugfixes etc) if they have the old version.



262 would be the proper row label addition for upcrystals.2da, in the eyes of the installer, as upcrystals.2da has no row 0, and most all of the other 2da files do... since the row 0 is missing the editor thinks there is one less row that there is supposed to be... hence it uses row 262.

If this is so, this would be neither your fault, or the installers fault, but the games fault, because Bioware and OE did not follow their own 2da file formats and put a row 0 in upcrystals.2da! LOL! :lol:


In all fairness I wouldn't blame Bioware or Obsidian, since, as far as I can see, the standard upcrystals.2da in 2da.bif does begin with a rowlabel of 0. :) I would guess that one of the USM people have used KotorTool's Renumber Row Labels function, which will replace all row labels and begin at 1 rather than 0, no matter what the file previously started at.



Thankfully upcrystals.2da does not have it's row numbers refrenced by anything so 2 row 262's should not harm much of anything... our games should run fine with 2 of the same row numbers. If not then we could always bribe stoffe to fix the lack of an upcrystals.2da row 0 in the installer? :D


If you don't assign a row label directly in a modifier, the patcher will make the row label the same as the line number of the new line. In files which start at rowlabel 0 (most of the standard files with numeric rowlabels as far as I know), this would be identical to the next row label in line.

I guess I didn't think of the fact that incremental row labels don't have to match the line number and didn't add support for the high(), since I incorrectly assumed that it would be the same as assigning no RowLabel. I'll have to fix that in the next version to make high() work for Row Labels too, and add a filter preventing it from adding a row with a Row Label that already exists in the 2DA.

Though in this case, as said, if the upcrystals.2da isn't indexed by the row label (which seems to be the case since the USM file works just fine despite its new row label numbering), it doesn't matter what the value in that column is, since the game won't use it.

ChAiNz.2da
08-23-2005, 08:53 AM
In all fairness I wouldn't blame Bioware or Obsidian, since, as far as I can see, the standard upcrystals.2da in 2da.bif does begin with a rowlabel of 0. I would guess that one of the USM people have used KotorTool's Renumber Row Labels function, which will replace all row labels and begin at 1 rather than 0, no matter what the file previously started at.
Guilty :o

But I did notice this blunder right-offhand. Since it didn't affect anything during our test runs I left it in it's current state rather than re-number the whole .2da file again. I can however make a new 'true' index if everyone would feel more comfortable having the line 0 in it.

Just let me know :D

stoffe
08-23-2005, 09:16 AM
@TheOssusKeeper:
Try this version (http://www.algonet.se/~stoffe/TSLPatcher117.rar) of the patcher. It should allow you to assign the high() token to the RowLabel when adding new lines, allowing you to get the highest row label regardless of the line numbers. Like:

RowLabel high()
Label Light
template g1_w_sbrcrstl22
shortmdlvar g1_w_short03
longmdlvar g1_w_lghtsbr03
doublemdlvar g1_w_dblsbr003


@ChAiNz.2da:
I personally wouldn't bother with it. It works anyway and the Row Label isn't actually used for anything in upcrystals.2da, so it doesn't really matter. :)

There's nothing in the 2DA format in general that demands that a Row Label starts at 0. It doesn't even have to be a numeric value after all, like in plot.2da where they use tags as row label. Some files expect numeric row labels, some does not, and in some it's unused. :)

TheOssusKeeper
08-25-2005, 01:49 AM
Guilty :o

:tsk: jk... :D


Actually, I do think it affects something though, after updating the upcrystals.2da... I add the crystal to the workbench, it didn't show up... so i think the workbench reads what’s in the upcrystals.2da because it didn't find the new crystal...

here's my meaning:
in the upcrystals.2da file:
row label 262
row label 262 (the patcher just dup'ed the previous rowlabel)

in the itemcreate.2da:
row label 416
( in this config. the itemcreate wouldn't recognize the new crystal at rowlabel 262 or the one at rowlabel 416, in their respective 2da files.)

same goes for this config. as well:
in the upcrystals.2da file:
row Label 262
rowlabel 0 (add for proper row label indexing)
row label 263

in the itemcreate.2da:
row label 416
(when this config didn't work either I went back and deleted the rowlabel 0 that was placed between the 262 and 263 rowlabels, then the crystal showed up and worked fine in the iteamcreate.2da...)

i got every thing working now 100%... thanx for all the help... ;)

edit: I got to think’n that maybe it didn’t recognize the new crystal because there was a break in the rowlabel numbers, i.e. rowlabel 262, rowlabel 0 and rowlabel 263? But why didn’t it recognize the dup’ed rowlabel, unless it was because it was duplicated?

TheOssusKeeper
08-25-2005, 02:06 AM
hey Stoffe, version 1.1.7 works like a dream, thanks... :D keep up the good work... :thumbsup:

zulu9812
08-30-2005, 01:32 PM
When I use ChangeEdit.exe to compare to 2da files for differences, anf I get the following error:

"Invalid row index specified, unable to look up cell value"

This happens with every single 2da file (and yes, I'm comparing 2das of the same type. e.g. apearance.2da and appearance.2da). I'll confess to now really knowing what I'm doing with this program, though.

stoffe
08-30-2005, 01:52 PM
When I use ChangeEdit.exe to compare to 2da files for differences, anf I get the following error:

"Invalid row index specified, unable to look up cell value"

This happens with every single 2da file (and yes, I'm comparing 2das of the same type. e.g. apearance.2da and appearance.2da). I'll confess to now really knowing what I'm doing with this program, though.

Are you loading the unmodified 2DA file first, and the modified one second, when you compare? I think that error would occur if the first 2DA file has more lines or columns than the 2nd 2DA file in the current version.

Since the TSLPatcher is unable to delete lines from a file I didn't put too much thought into it this case before. I'll change it so it will just skip the extra lines and compare the rest, rather than display cryptic messages, in the next version. :)

zulu9812
08-30-2005, 02:46 PM
I was actually comparing two modified files, but thanks - that makes a lot more sense now :)

stoffe
08-30-2005, 05:01 PM
When I use ChangeEdit.exe to compare to 2da files for differences, anf I get the following error:

"Invalid row index specified, unable to look up cell value"


I think I have fixed that behavior in this new version (http://www.algonet.se/~stoffe/ChangeEdit099.rar) now. If it encounters rows or columns in the first 2DA file that aren't present in the second 2DA file, it will just pop up a warning about the extra rows/columns but continue comparing the lines/columns present in both files.

However, for addrow and addcolumn modifiers to be created, the 2DA file containing the new rows/cols must be the second one loaded.

I also did some cleaning up and optimizing of the compare function, and made it use the label column text (for 2DAs that have that column) in the created modifier labels instead of line number to make it a bit clearer which lines have been found when viewing the list.

TheOssusKeeper
09-30-2005, 10:18 PM
Hey Stoffe, can I give an idea for the next version of the ChangeEdit.exe?
I was thinking if it is possible, to select multi files (mass select) and input them into the 'install files' windows with them using the preset destination folder and settings? instead of having to select one file at a time... just a thought if it could be done, that would be awesome and a time saver as well...

stoffe
10-01-2005, 03:14 PM
I was thinking if it is possible to select multiple files (mass select) and input them into the 'install files' windows with them using the preset destination folder and settings? Instead of having to select one file at a time...

That hopefully shouldn't be too hard to implement. I'll add it to the ToDo list and have a look at it next time I feel like working on ChangeEdit. Thanks for the suggestion. :)

stoffe
10-04-2005, 05:11 PM
Hey Stoffe, can I give an idea for the next version of the ChangeEdit.exe?
I was thinking if it is possible, to select multi files (mass select) and input them into the 'install files' windows with them using the preset destination folder and settings? instead of having to select one file at a time...

Since I had some free time this evening I added an extra button next to the arrow buttons which you can use to mass-add files to the install list. It will pop up a box asking you for the destination folder name and the Replace/copy setting for the file, and then open a standard Open dialog box for you to select the files to add. Use CTRL/SHIFT when clicking to select multiple files.

I also took the opportunity to add the two new settings fields that were added in TSLPatcher 1.1.7 to the Settings screen in ChangeEdit to make them a little more accessible.

The first (required file) can contain the name of a file that must be present in the user's override folder in order for the installation to proceed. The second (error message) can contain a message that will be displayed to the user if that specified file is missing and installation aborts. Just leave both boxes blank to not use this feature.

That feature is mostly intended when making updates to existing mods to ensure the user has the mod that will be updated installed.

You can get this tiny update to ChangeEdit.exe here (http://www.algonet.se/~stoffe/ChangeEdit0992.rar). As far as I have seen from some quick testing things seem to work.

TheOssusKeeper
10-04-2005, 09:45 PM
Since I had some free time this evening I added an extra button next to the arrow buttons which you can use to mass-add files to the install list. It will pop up a box asking you for the destination folder name and the Replace/copy setting for the file, and then open a standard Open dialog box for you to select the files to add. Use CTRL/SHIFT when clicking to select multiple files.

You can get this tiny update to ChangeEdit.exe here (http://www.algonet.se/~stoffe/ChangeEdit0992.rar). As far as I have seen from some quick testing things seem to work.

Wow Stoffe, thank you very much… you're an absolute :ang3:
This will help immensely, and save a whole lot of time… :thumbsup:
Three cheers for Stoffe… :cheers: :cheers: :cheers:


Edit: I just tried it out, it seems to work perfectly... as always ;)

ermo
11-28-2005, 07:58 PM
* Added a primitive way for the Patcher to modify things like NCS scripts with correct 2DA index values and StrRefs. It is currently VERY primitive, and WILL mess up your files if you don't know what you are doing when you configure it. As such it is not added to the ChangeEdit application, and I won't describe how it works here. If you really need to use it, ask me and I'll describe how it works.

All right, I'll bite ;)

515=2DAMEMORY1

Is the key '515' some sort of index that counts the number of bytes nb since the beginning of the compiled script file? It would make sense, I suppose.

But really, it'd be rather nice if there was some way of instructing TSLPatcher to replace real text in .nss files. Although it would probably be a 'corner case' as it were.

On a side note: I have to agree with your comment on Bioware/OE being allergical to their own constants in the scripts. It's just plain poor programming practice.

stoffe
11-29-2005, 08:36 AM
All right, I'll bite ;)
515=2DAMEMORY1
Is the key '515' some sort of index that counts the number of bytes nb since the beginning of the compiled script file? It would make sense, I suppose.


The number is a byte offset into the file (in decimal, not hexadecimal) where it will overwrite the following 4 bytes with the value you are assigning to it. The value must be an integer (32 bit signed interval in the case of NCS files).

If you put ReplaceFile=1 at the top of the hackfile section the patcher will overwrite any existing copies of the file in Override with the copy from the tslpatchdata folder before it modifies the file. If this line is left out the patcher will skip the file if it's already present in override (since it has no way of knowing if the byte offset would still be valid in a custom-modified file). For example:
[myscript.ncs]
ReplaceFile=1
4752=StrRef0
... would write the resulting StrRef stored in the StrRef0 token of an entry added to dialog.tlk at byte offset 4752 in myscript.ncs, overwriting any myscript.ncs found in the override folder.

This will work for any file and not just NCS files, though I made it primarily with hacking NCS script with proper StrRef and 2DA indexes in mind.

Note that if the target file has a NCS extension it will write the assigned value as big-endian, since this is the way NWScript-integers are stored in NCS files. All other file types will have the value written little-endian. This is important to remember if you use a hex editor to search for a dummy value in an NCS file to get the offset for the value. (I.e. to find the location of the value 999 in a compiled script you'd search for 0x000003E7.)


But really, it'd be rather nice if there was some way of instructing TSLPatcher to replace real text in .nss files. Although it would probably be a 'corner case' as it were.


Yes, I agree that the current solution is an ugly hack, hence the name "HACKList". :)

But I doubt my programming skills are sufficient to implement my own NSS->NCS compiler in the TSLPatcher, so I haven't looked into a more elegant solution much. It was the best solution I could think of at the time for this problem. Juggling with byte offsets is hardly user friendly, but it worked for what I needed it for at the time. :)

ermo
11-29-2005, 06:59 PM
The number is a byte offset into the file (in decimal, not hexadecimal) where it will overwrite the following 4 bytes with the value you are assigning to it. The value must be an integer (32 bit signed interval in the case of NCS files).


Hehe, I suspected as much :) (and thanks for the instructions)

(...)
Note that if the target file has a NCS extension it will write the assigned value as big-endian, since this is the way NWScript-integers are stored in NCS files. All other file types will have the value written little-endian. This is important to remember if you use a hex editor to search for a dummy value in an NCS file to get the offset for the value. (I.e. to find the location of the value 999 in a compiled script you'd search for 0x000003E7.)


... as opposed to little-endian E7 03 00 00. Ok.

Yes, I agree that the current solution is an ugly hack, hence the name "HACKList". :)
But I doubt my programming skills are sufficient to implement my own NSS->NCS compiler in the TSLPatcher, so I haven't looked into a more elegant solution much. It was the best solution I could think of at the time for this problem. Juggling with byte offsets is hardly user friendly, but it worked for what I needed it for at the time. :)

Well, who said anything about implementing a compiler? ;) All I had in mind was that you could re-format .nss files with the help of some simple markup and call nwnnsscomp.exe --game 2 --compile <current nss file>

(script before TSLPatcher is run)

//my_mod.nss
// reformat with 2DAMEMORY# values from TSLPatcher

int SpellId1, SpellId2, SpellId3, SpellId4, SpellId5;

// this block is here for convenience. I'd like to avoid having to create
// these lines one by one each time tslpatcher has replaced the tokens.
// SpellId1 = 2DAMEMORY1;
// SpellId2 = 2DAMEMORY2;
// SpellId3 = 2DAMEMORY3;
// SpellId4 = 2DAMEMORY4;
// SpellId5 = 2DAMEMORY5;

//<tslpatcher> SpellId1 = 2DAMEMORY1;
//<tslpatcher> SpellId2 = 2DAMEMORY2;
//<tslpatcher> SpellId3 = 2DAMEMORY3;
//<tslpatcher> SpellId4 = 2DAMEMORY4;
//<tslpatcher> SpellId5 = 2DAMEMORY5;

if (GetHasSpellEffect(SpellId1))
{
// foo
}
(...)

(script after TSLPatcher is run)

//TSLPatcher reformatted my_mod.nss on 2005-11-29 at <current time>
//my_mod.nss
// reformat with 2DAMEMORY# values from TSLPatcher

int SpellId1, SpellIdd2, SpellId3, SpellId4, SpellId5;

// this block is here for convenience. I'd like to avoid having to create
// these lines one by one each time tslpatcher has replaced the tokens.
// SpellId1 = 2DAMEMORY1;
// SpellId2 = 2DAMEMORY2;
// SpellId3 = 2DAMEMORY3;
// SpellId4 = 2DAMEMORY4;
// SpellId5 = 2DAMEMORY5;

SpellId1 = 301;//2DAMEMORY1
SpellId2 = 302;//2DAMEMORY2
SpellId3 = 303;//2DAMEMORY3
SpellId4 = 304;//2DAMEMORY4
SpellId5 = 305;//2DAMEMORY5

if (GetHasSpellEffect(SpellId1))
{
// foo
}
(...)


I hope you get the idea. But since I'm the only one who's asked, it's probably not worth the effort.

Btw. don't be so hard on yourself. If your programming skils are 'insufficient' as you put it, you've certainly managed to hide it well. ;) Give yourself some credit. From my point of view, it's well deserved.

Rock on! :cool:

stoffe
12-01-2005, 08:05 AM
Well, who said anything about implementing a compiler? ;) All I had in mind was that you could re-format .nss files with the help of some simple markup and call nwnnsscomp.exe --game 2 --compile <current nss file>


Well, I've tried to make the installer app fairly stand alone with little reliance on external things to decrease the risk of things going wrong (which admittedly has already failed miserably with the whole RTF thing), but I guess an external EXE is less likely to cause trouble than a DLL.

Still, it would require you to ship nwnnsscomp.exe with the mod. File size issues aside, I'm not exactly sure how legal it would be to distribute someone elses application like this with your own work.

A text substitution function that looks through NSS files for tokens and replace them with values, and calls to nwnnsscomp.exe if located within the tslpatchdata folder probably wouldn't be too hard to do, but it'll take some time to implement. I'll look into it, but since I am pretty busy with other things right now and have little time to spare for modding I'm afraid it will have to wait a few weeks until I have more free time.


If your programming skils are 'insufficient' as you put it, you've certainly managed to hide it well. ;)
Heh, that's half the reason why I haven't posted the source code for my tools yet (it's not pretty). :D

Darkkender
12-01-2005, 01:27 PM
Hey Stoffe, you could always distribute a batch file that calls nwnnsscomp that way somebody could adjust it for there own folders. As for distributing the source I think it would take a simple permission PM to Fred. The Original sourcecode by Torlack is made available at his site. I suppose if you wanted to do what I'm doing which is to download it and integrate the critical components into a program you could as long as you abide by Torlacks terms. Which are by the way pretty mild basic GNU type of terms.

timsong
12-17-2005, 06:24 AM
Whenever I click the install mod button, I got a "RichEdit Line Insertion Error" message. Anyone know why?

Tupac Amaru
12-17-2005, 07:50 AM
Whenever I click the install mod button, I got a "RichEdit Line Insertion Error" message. Anyone know why?
This post should solve your problem :) :
http://www.lucasforums.com/showpost.php?p=1837055&postcount=65

Herbatic
12-20-2005, 12:11 PM
I've just started modding KotOR, and I was using KMM, which is fantastic, but as soon as I had my first mod conflict I thought a program like yours would be the ideal solution - I was very happy when I found you had already made it!

Could someone else confirm if TalkEd.exe (http://www.algonet.se/~stoffe/TalkEd.rar) is unable to load an unaltered KotOR1 dialog.tlk file, please?


I opened an original dialog.tlk and the one from All-in-one Force Powers 3.01, and it appears to work fine with both :D

So I guess this means it should be fully compatible with KotOR, despite the name?

This program is just amazing Stoffe, I know enough about programming to appreciate the effort and skill to make this program.

Makes me want to start modding...

Joris1
12-22-2005, 10:02 AM
Hi, I have a question:

I saw in a mod by AVOl that he used your TSL Patcher. But in there was only a zip file and no folder names "tslpatchdata".

How can I make it that is it so??

ChAiNz.2da
12-22-2005, 10:18 AM
Hi, I have a question:

I saw in a mod by AVOl that he used your TSL Patcher. But in there was only a zip file and no folder names "tslpatchdata".

How can I make it that is it so??
You'll need to extract the contents of the .zip file...

It should contain all the necessary files afterwards :)

Joris1
12-22-2005, 10:32 AM
I already try that! It contains only the exe file

Tupac Amaru
12-22-2005, 11:58 AM
I saw in a mod by AVOl that he used your TSL Patcher. But in there was only a zip file and no folder names "tslpatchdata".
It doesn't have a separate 'tslpatchdata' folder. Everything is packed into the .exe. Just run it, choose your game path and the mod should install just fine. That was how it worked for AVOL's Bastila mod I am using at least.

Joris1
12-22-2005, 01:24 PM
Yes, but how can I pack everything in the .exe??

Darth333
12-22-2005, 01:35 PM
I think he used NSIS: http://nsis.sourceforge.net/Main_Page

but NSIS wont make your mods compatible with other mods right away. You'll have to use the patcher too. Personally unless the mod is really big, I don't see the point in using NSIS: too much hassle for nothing and I like to see what I install.

Joris1
12-23-2005, 07:16 AM
Thank you! But I think I will use the old TSL Patcher. The mod should cames out tomorrow and I haven't the time to change all things. ;)


P.s. I have just a grammar question: Names it "the underwear from Bastilla" or "the underwear of Bastilla"???

Darth333
01-07-2006, 08:11 PM
I have a question concerning 2DAMEMORY# tokens. I'm working on force powers and I'd like to cumulate more than one value in the prerequisites column. Is it possible?

something like this:
prerequisites=2DAMEMORY2 [AND] 2DAMEMORY3

to get, per example, 282_283 in the spells.2da file

stoffe
01-07-2006, 08:59 PM
I have a question concerning 2DAMEMORY# tokens. I'm working on force powers and I'd like to cumulate more than one value in the prerequisites column. Is it possible?

something like this:
prerequisites=2DAMEMORY2 [AND] 2DAMEMORY3

to get, per example, 282_283 in the spells.2da file

Currently it's not possible, the tokens just insert the value they correspond to without accepting any operators. If it's needed I'll add it to the ToDo list and see if I can come up with a solution for it as soon as I get the inspiration to do some more work on the patcher application.


However if I remember correctly, if you only need it for "standard" prerequisites, it should be enough that you set the prerequisite of each power to the one before it in the family and not all the weaker powers.

E.g. Wound --> Choke --> Kill, Where Kill would have Choke as prerequisite and Choke would have Wound as prerequisite. Since you'd need to get Wound in order to get Choke, Kill would indirectly have Wound as a prerequisite through Choke's prerequisite.

Darth333
01-07-2006, 10:05 PM
E.g. Wound --> Choke --> Kill, Where Kill would have Choke as prerequisite and Choke would have Wound as prerequisite. Since you'd need to get Wound in order to get Choke, Kill would indirectly have Wound as a prerequisite through Choke's prerequisite.

Hehe yes I did that and I initially thought that was the reason why my 2nd and 3rd levels force powers did not appear in the level up screen but....[insert bad word here]I just figured out it's because I granted the first level of my force power with a script using the Grantspell function (with the -1 value for the 1st level)...the game doesn't seem to let you level up your force powers normally afterwards...and all this after making new sound files, cutscenes and all :(

Thanks anyways :)

rgdelta
01-09-2006, 04:22 PM
Stoffe I had a question/suggestion in one heh not sure if this will be too hard or if you are already working on it but could it be possible to have TSL patcher do a gff compare similar to your 2da compare???

stoffe
01-10-2006, 07:08 PM
Stoffe I had a question/suggestion in one heh not sure if this will be too hard or if you are already working on it but could it be possible to have TSL patcher do a gff compare similar to your 2da compare???

You mean the utility that builds the settings file and not the Patcher application, right? Something that adds the differences found to to the Patcher's settings file?

If so, I'll add it on the ToDo-list, though I don't know when I get to have a look it it since it seems like a fair amount of work (for one of my skill level anyway :) ).

rgdelta
01-10-2006, 07:14 PM
yeah that is what I am talking about in Changedit for the changes.ini. It was a thought I came up with when working on my mod.

stoffe
01-10-2006, 07:55 PM
EDIT: I've made some further fixes, and updated ChangeEdit to support these new features. See this post (http://64.20.36.211/showpost.php?p=1991879&postcount=135)

I've had time to work a bit on a new version of the TSLPatcher, trying to implement some of the feature requests I've received.

I currently have an apparently functional 1.2 version done, but since I am awful at detecting my own mistakes I would appreciate it a lot if some daring individual who is fairly familiar with how the patcher works would like to give it a spin and see if any problems arise.

Do note that I haven't yet made an update to the ChangeEdit application to incorporate these changes. I'd prefer to see that everything works fine before starting on that, in case something is messed up and I need to make fundamental changes. Thus you'll have to edit changes.ini by hand if you want to help test it.

I do plan to update ChangeEdit to support these additions and include it when I release this version though, which should make configuring it a bit less complicated than is described below. :)

This version has the following two things added:

1. Improved GFF Handling:
The Patcher is now able to add new fields to GFF files. I'd assume this was primarily meant to dynamically add entries to global.jrl and such. I guess it can be used to add entries to DLG files as well, though that would be a lot of work involved.

This is done by adding a KEY named "AddField#" (# is an incremented number as usual to make each key unique) under the section for the file in question. The VALUE is this key is the name of another section in changes.ini which holds the specifics of the new field to add. This section then contains some of the following keys:

General keys:

FieldType - REQUIRED field, this determines the type of field, see below.
Path - OPTIONAL field, determines where in the GFF field tree the new field should be added. Leave blank to add the field at the root/top level.
IMPORTANT: This *must* be unspecified for sub-fields added within the sections of newly added LIST or STRUCT fields, or the field might be added at the wrong position!
Label - REQUIRED field, this sets what the field label (name) of the new field will be. This must be specified for all new fields, EXCEPT for new STRUCTS added to a LIST.
Value - OPTIONAL field, this sets what value the new field will have. Take care to only enter data in a format that will fit within the type of field set in FieldType (i.e. only numbers in INT fields etc). STRUCT and LIST fields are containers and have no value, and should not specify this key.
NOTE: Values specified for Position and Orientation fields must have each value separated by a pipe character, like 0.0|1.0|5.0.


Field specific keys:

StrRef - OPTIONAL field. This is only used in sections that create a new ExoLocString field. It will set the value of the dialog.tlk StrRef for this field.
lang# - OPTIONAL field. This is only used in sections that create a new ExoLocString field. # is the language id to add a new localized substring to the ExoLocString under. Multiple "lang"-lines with different language id's may be specified to add strings for multiple languages and genders.
TypeId - OPTIONAL field. This is only used in sections that create a new STRUCT field. This sets the type ID of the struct to the number assigned to it. (Decimal value, NOT hexadecimal please...)


Valid FieldType Values (see above):
Byte, Char, Word, Short, DWORD, Int, Float, Int64, Double
ExoString, ResRef, ExoLocString
Orientation, Position
Struct, List

New LIST and STRUCT fields:
To add new sub-fields to a LIST or STRUCT field you have just added, you can add "AddField#" keys to its specifier section. These will work just like such keys added directly under the file's section, with one important difference. DO NOT add a "Path" key to ANY of the sub-sections that define those sub-fields. Their position paths will be derived automatically from their parent field.

A Nonsense Example:
[GFFList]
File0=testfile.gff


[testfile.gff]
AddField0=st_new_lindex_struct
AddField1=st_new_byte_field


[st_new_lindex_struct]
FieldType=Struct
Path=SomeStruct\MyList
TypeId=12
AddField0=st_struct_field_name
AddField1=st_struct_field_desc
2DAMEMORY1=ListIndex


[st_struct_field_name]
FieldType=ExoString
Label=AddedName
Value=A field in a patched-in struct!


[st_struct_field_desc]
FieldType=ExoLocString
Label=AnAddedDesc
StrRef=1212
lang0=This is a localized string in a new struct added in by the Patcher!


[st_new_byte_field]
FieldType=Byte
Label=TestByte
Value=2DAMEMORY1




2. Primitive NSS Processing and Compiling:
As requested, the Patcher now has a new configuration section called [CompileList]. If present, it should list the names of NSS script files that should be processed and then recompiled before being installed. The list is made up of a key which is either File# if the file must not already exist in the user's override, or Replace# if it should overwrite any existing copies of the resulting NCS that sits in the user's overide folder.

What this does is to look for #2DAMEMORY*# and #StrRef*# tokens within the script source and replace them with the actual value the Patcher has stored in memory corresponding those tokens. The modified file will then be compiled with NWNNSSCOMP.EXE and the resulting NCS file put in the user's Override folder.

NOTE: nwnnsscomp.exe, nwscript.nss and any necessary include files required for compiling the script must be located in the tslpatchdata folder for this to work.

Another Nonsense Example:
---> changes.ini
[2DAList]
Table0=appearance.2da

[CompileList]
Replace0=changelook.nss

[appearance.2da]
CopyRow0=appearance_sister

[appearance_sister]
RowIndex=454
ExclusiveColumn=label
label=ST_HANDMAIDEN_SISTER
2DAMEMORY1=RowIndex


---> changelook.nss
void main() {
ChangeObjectAppearance(OBJECT_SELF, #2DAMEMORY1#);
}


If you want to help test this, you can find this WIP version of the TSLPatcher application here. (I've included the version of nwnnsscomp.exe I use in this test archive since I haven't figured out a way yet to detect which version is present, since they all require different commandline parameters. I hope this isn't illegal or against the rules.)

ChAiNz.2da
01-12-2006, 08:31 AM
I may just have a great opportunity for testing this stoffe with the Kreia Robe Mod I'm working on (especially the custom script additions you've added).

Though I'm not up to that point yet, I'll be sure to give you some feedback once I do some experimenting :)

This looks great! :thumbsup:

The Source
01-12-2006, 04:24 PM
Hey Stoffe!
I noticed you have a 2DA Converter/Merger listed in your signature. How does this differ from the TSL Patcher?

Edit:: Add::
Never mind! I found the thread... :)

stoffe
01-14-2006, 10:50 PM
EDIT(2006-01-16): I uploaded a fixed version of ChangeEdit where i've added an input-box and Help-button I forgot about in the earlier version in the "Add GFF Field" editor window. Oops.


EDIT(2006-01-18): Uploaded small fix to ChangeEdit (wip v4) to fix problem with data validation not accepting 2DAMEMORY/StrRef tokens in the new GFF Field editor. Duh...


EDIT(2006-01-25): Uploaded test version (wip v5) with requested ability to overwrite existing GFF files rather than modify them in place. Added an attempt at documentation.


EDIT(2006-01-27): Uploaded a new test version (wip v6) with some minor bugfixes and a few mistakes corrected in the ReadMe. TSLPatcher will now also show the output from nwnnsscomp.exe in the progress log if the LogLevel is set to 4, to make debugging easier.




Do note that I haven't yet made an update to the ChangeEdit application to incorporate these changes.
(snip)
I've included the version of nwnnsscomp.exe I use in this test archive since I haven't figured out a way yet to detect which version is present, since they all require different commandline parameters. I hope this isn't illegal or against the rules.

I've uploaded a new test-version of TSLPatcher v1.2, which, aside from some minor bug fixes, hopefully should work with any version of nwnnsscomp.exe. I added a new field in the Settings section where you can set extra commandline flags that are necessary (such as "-g 2" etc). The text entered in this field is appended to the parameter list sent to nwnnsscomp.exe before the file names and the "-c" and "-o" flags that the TSLPatcher uses on its own.

For reference, the commandline used by the Patcher to compile script source looks something like:

"C:\Path\to\tslpatchdata\nwnnsscomp.exe" customParameters -c "C:\path\to\tslpatchdata\tmp_scriptname.nss" -o "C:\path\to\tslpatchdata\scriptname.ncs"


Further, I've now modified the ChangeEdit application to support the two new features mentioned in the previous post (adding fields to GFF files and processing scripts for tokens). This should make it a little less complicated to configure the patcher to use these functions, I hope.

As far as I can tell from some quick testing it appears to work, but I've no doubt made some mistakes so it's possible there are some bugs in it still. Some polish and a bit more help text in ChangeEdit is probably also necessary.

I have uploaded the new test version of ChangeEdit as well along with the TSLPatcher EXE. You can find them both here if you are brave enough to want to help me test it and see if everything works.

Joris1
01-15-2006, 07:58 AM
Hi, I have a few questions:

1.) How can I add a new Row to an 2da file. I mean How can I do it that the TSL Patcher adds a new row. But the TSL Patcher must add the highest row, if you understand what I mean.

2.) In in the appearance.2da is a column normalhead. How can I make it, that the number is equal to the number in heads.2da??

3.) In portraits.2da is a column appearancenumber. How can I do it, that the number is equal to the appearancenumber?

stoffe
01-15-2006, 03:53 PM
Hi, I have a few questions:

1.) How can I add a new Row to an 2da file. I mean How can I do it that the TSL Patcher adds a new row. But the TSL Patcher must add the highest row, if you understand what I mean.

2.) In in the appearance.2da is a column normalhead. How can I make it, that the number is equal to the number in heads.2da??

3.) In portraits.2da is a column appearancenumber. How can I do it, that the number is equal to the appearancenumber?

This can be done by having the Patcher modify the 2DA files in the proper order and temporarily store the line number of the resulting rows in 2DAMEMORY tokens, which can then be assigned to a column in another 2DA file. These steps should work:

1) Add the files to the 2DA list in the Patcher in the order heads.2da, appearance.2da and last portraits.2da.

2) For heads.2da, add a new row and set its columns to their desired values. Then last, assign RowIndex to 2DAMEMORY1.

3) For appearance.2da, add a new row, sets its other columns as you wish, then assign 2DAMEMORY1 to the normalhead column. At the end, assign RowIndex to 2DAMEMORY2.

4) For portraits.2da, add a new row and assign 2DAMEMORY2 to the appearancenumber, appearance_s and appearance_l columns.

This would take the line number that your new row in heads.2da was added as and store it in the 2DAMEMORY1 token. It would then assign that value to the normalhead column for your new row in appearance.2da. Further, you would store the line number of your new row in the 2DAMEMORY2-token, which you will then assign to the appropriate columns in portraits.2da.

If you want to see an example of how this is set up, you can take a look at the changes.ini file of the "Twilek Exile" mod linked to in my signature.

Joris1
01-16-2006, 08:40 AM
Thank you! I took a look on the changes.ini file of your mod. But it confused me that there was only one new row. Normally there are three rows. For each class one! How do you do that?

I wrote a changes.ini like in your mod but with three new rows. But after I have installed my mod to test it, there were 5 new rows!

Here is the code:

[Settings]
FileExists=1
WindowCaption=Install Mission Vao19 Appearance
ConfirmMessage=Make sure you have read the instructions before continuing. Do you wish to install this mod now?
LogLevel=3
InstallerMode=1
BackupFiles=1


[TLKList]


[2DAList]
Table0=heads.2da
Table1=appearance.2da
Table2=portraits.2da


[GFFList]


[InstallList]
install_folder0=override


; ================================================== =================

[heads.2da]
AddRow0=N_TwiAssH01


[appearance.2da]
AddRow0=appearance.2da
AddRow1=b
AddRow2=c

[portraits.2da]
AddRow0=portraits_Mission


; ================================================== =================

[N_TwiAssH01]
ExclusiveColumn=head
head=N_TwiAssH01
alttexture=P_Mission19H01
headtexvvve=P_Mission19H01D2
headtexvve=P_Mission19H01D1
headtexve=P_Mission19H01D1
headtexe=P_Mission19H01D1
2DAMEMORY1=RowIndex


[appearance.2da]
RowIndex=664
ExclusiveColumn=label
label=Unique_Mission_Vao19_SML_01
race=****
driveanimwalk=2.6
normalhead=2DAMEMORY1
backuphead=****
modela=PFBAM
texa=P_Mission19BA
texaevil=PFBAMD
modelb=N_TwiAssasin
texb=PMVB
texbevil=PMVBD
modelc=PFBCM
texc=PFBC
modeld=PFBDM
texd=PFBD
modele=PMBEM
texe=PFBE
modelf=PFBFM
texf=PMBF
modelg=PFBGM
texg=PFBG
modelh=PFBHM
texh=PFBH
modeli=PFBIM
texi=PFBI
modeli=PFBVM
texi=PFBI
modell=PFBL
texl=PFBLMV
texlevil=PFBLMVD
envmap=CM_Baremetal
2DAMEMORY2=RowIndex

[b]
RowIndex=664
ExclusiveColumn=label
label=Unique_Mission_Vao19_MED_01
race=****
driveanimwalk=2.6
normalhead=2DAMEMORY1
backuphead=****
modela=PFBAM
texa=P_Mission19BA
texaevil=PFBAMD
modelb=N_TwiAssasin
texb=PMVB
texbevil=PMVBD
modelc=PFBCM
texc=PFBC
modeld=PFBDM
texd=PFBD
modele=PMBEM
texe=PFBE
modelf=PFBFM
texf=PMBF
modelg=PFBGM
texg=PFBG
modelh=PFBHM
texh=PFBH
modeli=PFBIM
texi=PFBI
modeli=PFBVM
texi=PFBI
modell=PFBL
texl=PFBLMV
texlevil=PFBLMVD
envmap=CM_Baremetal
2DAMEMORY2=RowIndex

[c]
RowIndex=664
ExclusiveColumn=label
label=Unique_Mission_Vao19_LRG_01
race=****
driveanimwalk=2.6
normalhead=2DAMEMORY1
backuphead=****
modela=PFBAM
texa=P_Mission19BA
texaevil=PFBAMD
modelb=N_TwiAssasin
texb=PMVB
texbevil=PMVBD
modelc=PFBCM
texc=PFBC
modeld=PFBDM
texd=PFBD
modele=PMBEM
texe=PFBE
modelf=PFBFM
texf=PMBF
modelg=PFBGM
texg=PFBG
modelh=PFBHM
texh=PFBH
modeli=PFBIM
texi=PFBI
modeli=PFBVM
texi=PFBI
modell=PFBL
texl=PFBLMV
texlevil=PFBLMVD
envmap=CM_Baremetal
2DAMEMORY2=RowIndex

[portraits_twilekjedi]
ExclusiveColumn=baseresref
baseresref=po_pmission19
sex=1
appearancenumber=2DAMEMORY2
race=6
plot=0
appearance_s=2DAMEMORY2
appearance_l=2DAMEMORY2
forpc=1
baseresrefe=po_pmission19d1
baseresrefve=po_pmission19d1
baseresrefvve=po_pmission19d1
baseresrefvvve=po_pmission19d2


; ================================================== =================

[install_folder0]
File0=appearance.2da
File1=heads.2da
File2=P_Mission19BA01.tga
File3=P_Mission19H01.tga
File4=P_Mission19H01D1.tga
File5=P_Mission19H01D2.tga
File6=PFBLMV01.tga
File7=PFBLMVD01.tga
File8=PMVB01.tga
File9=PMVBD01.tga
File10=po_pmission19.tga
File11=po_pmission19d1
File12=po_pmission19d2
File13=portraits.2da


Oh, the files are not from me! I wrote this only for, because I want to play with it!

stoffe
01-16-2006, 02:15 PM
Thank you! I took a look on the changes.ini file of your mod. But it confused me that there was only one new row. Normally there are three rows. For each class one! How do you do that?


If the appearance is identical for all three body sizes I fail to see the point in adding 3 identical rows. :) I just added one row and then made all three columns (appearancenumber, appearance_s, appearance_l) in portraits.2da point to the same line in appearance.2da. Seems to work.



I wrote a changes.ini like in your mod but with three new rows. But after I have installed my mod to test it, there were 5 new rows!


From a quick look I spotted a number of problems with these settings: (Did you modify them by hand or by using ChangeEdit?)

1) You have two sections which are both called [appearance.2da]. Section name must be unique, or the Patcher won't know where to look for info. Change the Modifier Label for the "AddRow0" key under the "real" [appearance.2da] to something else that's unique.

2) Since you are adding and not copying a row in the to-be-renamed [appearance.2da] section the RowIndex key has no purpose. (When you copy a row, it tells the Patcher which row to make a copy of.)

3) Since you are adding a new row (instead of copying an existing one to use as a template) as mentioned above, any column which you haven't assigned a value to directly will get "****" set as value. Since the appearance.2da file contains a lot of columns, your character appearance will be quite broken since a lot of columns won't get a meaningful value set. Thus, you should probably copy one of the player appearance lines and change the relevant columns instead of adding a new one. Use CopyRow# instead of AddRow# as modifiers in the (real) [appearance.2da] section.

4) You are using the same 2DAMEMORY token (2DAMEMORY2) to store all the resulting line numbers of the 3 lines you add to the appearance.2da file. Thus they will overwrite the previously stored values and only the line number of the last line added will be kept.

5) In the [portraits.2da] section, you use a Modifier Label called portraits_Mission where you instruct it to add a new line. However, no such section exists in the changes.ini file you posted. (The section is called portraits_twilekjedi).

6) in the portraits_twilekjedi section, you only assign the line number of the last appearance.2da to the portrait (in all 3 columns, like I did). This means that two of the appearance lines you added are never used when picking a portrait at the character creation screen.

7) Finally, you have added the 2DA files you just modified to the InstallList as well. This is unnessecary since they have already been put in override (if they didn't already exist there, or the existing one was modified), and I assume it would result in "File skipped" warnings when the Patcher runs. (And, if you had used Replace# instead of File# keys all the changes you made to those files, as well as any changes other mods had made, would have been overwritten by a the clean copy of the 2DA file from the tslpatchdata folder. Which would have been bad.)

As a general rule, files that have been touched by any of the other sections should never be added to the InstallList.

If you didn't use ChangeEdit.exe to modify the changes.ini file you might want to give it a try. While it'll hardly win any awards for user-friendliness it should hopefully make it a bit easier to understand and harder to make mistakes. I hope. :)

Joris1
01-16-2006, 02:30 PM
Hui! This is a long difficult text for a German in the 10th class! But thank you!

From a quick look I spotted a number of problems with these settings: (Did you modify them by hand or by using ChangeEdit?)


I modify them by hand! It takes less time as the ChangeEdit!

Thank you, I think it will help me at first!

rgdelta
01-18-2006, 06:33 PM
Stoffe for the development of TSL Enhanced I am going to use your WIP version because things like the compile with tokens I need.

Kristy Kistic
01-22-2006, 02:27 AM
Hi Stoffe :)

I haven't been able to figure this part out so, can you use the patcher to add inventory items to an existing utm file (Let's say larrim.utm - which is pretty common in mods) without having to replace the existing utm? Or perhaps for dan13_nemobody.utp - who, if this does work must have dropped from over encumbrance? And if so, what exactly is the needed syntax?

Thanks :)

Kristy

stoffe
01-22-2006, 08:39 AM
I haven't been able to figure this part out so, can you use the patcher to add inventory items to an existing utm file (Let's say larrim.utm - which is pretty common in mods) without having to replace the existing utm? Or perhaps for dan13_nemobody.utp - who, if this does work must have dropped from over encumbrance?
And if so, what exactly is the needed syntax?

While I haven't directly tested it, I think it should work when using the new "Add GFF Field" feature in TSLPatcher 1.2. I don't remember if the x/y position field for an inventory/store list of items still have a meaning in KotOR or if they are just remnants from NWN. If it doesn't matter that several entries might have the same x/y position values, it should work as it is now.

(If the x/y values must be unique, please let me know and I will see if I can add a "High" token that will pick the next highest value of a field in the structs in a list.)

Anyway, I think something like this might work, if pasted in as the GFF section of a changes.ini file (I snipped the non-relevant parts to save space). I'd recommend using ChangeEdit to set things like this up. It's easy to make mistakes if you add things like this by hand (even though Notepad is quicker if you need to copy&paste existing sections with minimal changes).

larrim.utm:
(add an infinite supply of "st_grenade01" and a single item of "st_myrobe01" to the store)

[GFFList]
File0=larrim.utm


[larrim.utm]
AddField0=itemlist_entry_1
AddField1=itemlist_entry_2


; First new item ----------------------------------------------------
[itemlist_entry_1]
FieldType=Struct
Path=ItemList
Label=
TypeId=ListIndex
AddField0=itemlist_entry_1_infinite
AddField1=itemlist_entry_1_res
AddField2=itemlist_entry_1_posx
AddField3=itemlist_entry_1_posy


[itemlist_entry_1_infinite]
FieldType=Byte
Label=Infinite
Value=1


[itemlist_entry_1_res]
FieldType=ResRef
Label=InventoryRes
Value=st_grenade01


[itemlist_entry_1_posx]
FieldType=Word
Label=Repos_PosX
Value=0


[itemlist_entry_1_posy]
FieldType=Word
Label=Repos_Posy
Value=1


; Second new item ---------------------------------------------------
[itemlist_entry_2]
FieldType=Struct
Path=ItemList
Label=
TypeId=ListIndex
AddField0=itemlist_entry_2_res
AddField1=itemlist_entry_2_posx
AddField2=itemlist_entry_2_posy


[itemlist_entry_2_res]
FieldType=ResRef
Label=InventoryRes
Value=st_myrobe01


[itemlist_entry_2_posx]
FieldType=Word
Label=Repos_PosX
Value=0


[itemlist_entry_2_posy]
FieldType=Word
Label=Repos_Posy
Value=2



dan13_nemobody.utp:
(add one "st_myrobe01" and one "st_mysaber01" to the container)

[GFFList]
File0=dan13_nemobody.utp



[dan13_nemobody.utp]
AddField0=itemlist_entry_1
AddField1=itemlist_entry_2


; First new item ----------------------------------------------------
[itemlist_entry_1]
FieldType=Struct
Path=ItemList
Label=
TypeId=ListIndex
AddField0=itemlist_entry_1_res
AddField1=itemlist_entry_1_posx
AddField2=itemlist_entry_1_posy


[itemlist_entry_1_res]
FieldType=ResRef
Label=InventoryRes
Value=st_myrobe01


[itemlist_entry_1_posx]
FieldType=Word
Label=Repos_PosX
Value=0


[itemlist_entry_1_posy]
FieldType=Word
Label=Repos_Posy
Value=2


; Second new item ---------------------------------------------------
[itemlist_entry_2]
FieldType=Struct
Path=ItemList
Label=
TypeId=ListIndex
AddField0=itemlist_entry_2_res
AddField1=itemlist_entry_2_posx
AddField2=itemlist_entry_2_posy


[itemlist_entry_2_res]
FieldType=ResRef
Label=InventoryRes
Value=st_mysaber01


[itemlist_entry_2_posx]
FieldType=Word
Label=Repos_PosX
Value=1


[itemlist_entry_2_posy]
FieldType=Word
Label=Repos_Posy
Value=2


Like with editing GFF files before, if those files are present in the override folder already they would be modified in-place. If they are not, however, an unmodified copy must be present in the tslpatchdata folder so it can be copied to the user's override folder and then modified.

(Note that if you set the TypeId of a new STRUCT (added to a LIST field) to "ListIndex", it will be set to the same value as the index the STRUCT will be added as in the LIST field. I think I've forgotten to mention that in the help text. Oops.)

Patriarch
01-23-2006, 06:55 PM
Heya

Stoffe I've testet your Gff "add entries" additions to TSL patcher, and I am pleased to say if works flawlessly(I've teste it with complex entry additions including strref and memory tokens to both append.tlk and global.jrl )Thank you this is essentially what we need and I urge you to keep up the good work. We are very close to have an idiot proof installation system.....Well not entirely :ears1:

In a topic earlier I adressed the possibility for the TSLpatcher to use subfolders. I am able to make it work when the subfolders are present in the original game root...What i want to do is to create a folder in the streamvoice\gbl called tae and put some files there. Tslpatcher does'nt seem to create this folder... It provides me with and error that says "invalid folder"...
My question is does TSL patcher only create the folder "override" if not present, or is it supposed to also create other custom folders?(I suppose that it will actually only create the one folder called override and discard references to other folders if not present at intallation). Below is a recap of my installlist section

[InstallList]
install_folder0=override
install_folder1=modules
install_folder2=StreamVoice\Gbl\tae < is the problem

T7edit: I merged the thread created in Holowan with this one, since this is where the post belongs.

stoffe
01-23-2006, 09:31 PM
My question is does TSL patcher only create the folder "override" if not present, or is it supposed to also create other custom folders?

Currently, the only folder it will create is the override folder if it is missing.

It does not currently create the missing folders if a path specified in the InstallList does not exist. If you need it I'll change it right away to create missing folders, it's a pretty quick fix.

I've uploaded TSLPatcher 1.2a (WIP v4) now that changes this behavior (it's the only change in that version).

(Just make double sure you spell all the names of existing folders correct now, since it'll just create any folders with typos in their names and move the files there without any warnings. :) )

SunBlade
01-24-2006, 03:11 PM
first of all:
stoffe, thanks for this great tool!

i think i found a 'flaw' in your TSLPatcher.
the current order of execution is:
1. 2DA files patching
2. GFF files patching
3. file hacking (i think)
4. file copy/replace
5. NSS compiling

at first sight there is no problem, when i execute the patcher whith my mod(which isn't finished yet)
it copys the baseitems.2da(if not already present) and adds a new line(on first run) / modifies the existing(on second run) and remembers the line number, then
it copys a_BaoDur_01.uti(if not already present) and changes the BaseItem field to the remembered number, and then
it copys and overwrites the texture of Bao Dur's Armor.

the problem is a_BaoDur_01.uti won't be overwritten if the file exists.
this isn't a problem for me now, but it would become a problem when i decide to make a lot of changes to Bao Dur's Armor.
then i would have to do all changes in changes.ini, because a_BaoDur_01.uti would never be replaced with the one from the tslpatchdata folder.

i suggest you change the order of execution, so that the file copy/replace would happen before any file is patched.


btw: each time you install a mod which adds strings to dialogs.tlk the strings would be added, resulting in duplicated strings. i wonder if you could do something about it, maybe check if the string which should be added already exists and taking that StrRef#. but correcting a spelling error from a previous version would still result in adding a string. i think keeping a changelog of the append.tlk would do the trick.
anyways, i don't think this .tlk veryfication is easy to implement, additionaly it would slow down the mod installation several minutes.
this isn't a real problem to me, because dlgconv exists :) .

stoffe
01-24-2006, 06:35 PM
i think i found a 'flaw' in your TSLPatcher.
(snip)
the problem is a_BaoDur_01.uti won't be overwritten if the file exists.


Thanks for the feedback.

This is by design, the TSLPatcher never overwrites any existing 2DA or GFF files present in override, it modifies the files in place instead. This is to allow them to modify files that other mods also use, such as DLG files, the global.jrl file, Store/merchant files, placeables with inventory (and of course append things to already modded 2DA files).

This would allow mods that use the same files to coexist, so long as they don't modify exactly the same fields in GFF files or the same cells in 2DA files.

If you for some reason need an existing file to be overwritten rather than modified and compatibility with other mods is not an issue, I could add a setting on a per-GFF file basis (like the ReplaceFile=1 key in the HACK List) that would always use the GFF file in tslpatchdata as template and discard any already installed file.

As for changing the sequence things are done: The InstallList is fairly stand-alone in how it works, but I'll have to check through the code to see if it causes any problems to move it up first before I dare to move it around. :)

(The reasoning for putting it at the bottom was to avoid copying a lot of files into the user's game folders in case something goes wrong during the processing of the TLK/2DA/GFF files and the Patcher aborts the installation.)


btw: each time you install a mod which adds strings to dialogs.tlk the strings would be added, resulting in duplicated strings. i wonder if you could do something about it, maybe check if the string which should be added already exists and taking that StrRef#.


The TSLPatcher already checks if an identical string already exists in dialog.tlk, and if so uses that string instead of adding a new one. Though if you correct spelling mistakes or such the string is no longer identical, and it would be added as a new entry.

The problem with checking beyond this is that there is nothing to use to identify whether the entry already exists if the text/sound resref doesn't match. The StrRef is dynamic and different for each user, depending on if they have other mods installed that modify the dialog.tlk file.

The only immediate way around this I can see would be if the TSLPatcher kept a central database with the checksum of the dialog.tlk file (to ensure it's not been modified by other applications) and a table linking append.tlk StrRef to <--> dialog.tlk StrRef for each mod.

I'll add it to the To Do list if you think it's necessary, but I'm not too convinced if the importance of this is sufficient to warrant the amount of work involved to do it.

The only time a user would encounter this is if they use a released updater for a mod they already have installed which corrects spelling mistakes or does text adjustments from the earlier version. And since the dialog.tlk file already is littered with duplicate strings straight off the game discs I don't think a handful more "orphaned" entries would cause any noticable ill effects. :)

If I'm overlooking some factor in this, please enlighten me. :)


* * *

@Everyone: I've added an early attempt at a somewhat descriptive documentation ReadMe for the TSLPatcher to the WIP-archive (linked to in the above posts). Should anyone read it and notice any glaring mistakes (English is not my native language), please let me know.

(And if no one reads the documentation it won't matter either way :) )

SunBlade
01-25-2006, 01:50 PM
... I could add a setting on a per-GFF file basis (like the ReplaceFile=1 key in the HACK List) ...yea, that would help a lot.


The TSLPatcher already checks if an identical string already exists in dialog.tlk ...:D you're way ahead of me :)
maybe i should reconsider storing the strings in append.tlk


The problem with checking beyond this ...i thought of something like:[TLKList]
StrRef0=0
StrRef1=5
StrRef1Old0=2
StrRef1Old1=1
StrRef2=4
StrRef2Old0=3implied i only add strings to append.tlk, this would mean:
StrRef0 is processed normaly
StrRef1 is then an updated version of StrRef1Old0 and StrRef1Old1 (pretty much spelling errors ;P )
StrRef2 is then an updated version of StrRef2Old0 (so if StrRef2Old0 is already present in dialogs.tlk it would be overwritten with StrRef2, else normal processing)

hope you got my idea. if that's to complex or simply impossible just discard it.
i think there are more important items on your todo list :D


EDIT: oh and i have an additional feature request.
could you implement a way to sort .2da tables, that i can do something like:[itemcreate.2da]
AddRow0=a_BaoDur_01
SortRow0=a_new_order

[a_BaoDur_01]
ExclusiveColumn=label
label=a_BaoDur_01
skill=35
group=4
level=15
align=0
base_skill=5

[a_new_order]
Sort0=group
Sort1=base_skill
Sort2=skill
Sort3=labelSortRow only makes sense on .2da tables which aren't referenced by line number like itemcreate.2da.
this would be a good way to sort the workbench :)


p.s.: your new readme looks good

stoffe
01-26-2006, 10:15 AM
yea, that [option to overwrite existing GFF files rather than modify them] would help a lot.


I've updated TSLPatcher 1.2a (WIP v5) with this option now. As far as my limited testing shows it appears to work. There's a new checkbox in the GFF panel in ChangeEdit where you can set the file to be overwritten.



:D you're way ahead of me :)
maybe i should reconsider storing the strings in append.tlk
(elaboration snipped)


Right, I'll add it to the Todo-list, but it feels more like polish than something essential so it'll have rather low priority. Thus I don't know when/if I will have time to implement it.


EDIT: oh and i have an additional feature request.
could you implement a way to sort .2da tables, that i can do something like:
(snip)


Hmm, I don't see what the point of this would be, since it in no way affects the operation of the installed mod (other than breaking it utterly if you sort a line number indexed 2DA). This sounds more like something useful for the mod maker (rather than a mod installer), which KotORTool already handles perfectly fine. Or am I overlooking something?


p.s.: your new readme looks good

Thanks. :)

Though I found some mistakes and minor omissions on my own which have been corrected and included in the WIP archive. But I think I'll leave it as it is now unless someone has any suggestions or other feedback. No point in putting a lot of time into doing something dreary if no one has any use for it anyway. :)

stoffe
02-02-2006, 05:26 PM
I got in a productive mood yesterday and decided to implement a feature that was requested some time ago (I don't remember by whom, sorry).

The test version, TSLPatcher v1.2.5a (WIP v1) (http://www.algonet.se/~stoffe/TSLPatcher125wip.rar), now has some functionality for adding GFF files it has modified, or scripts it has recompiled, to ERF format files (i.e. ERF, MOD, SAV, HAK files) instead of putting them in the Override folder. This should allow you to pack TSLPatcher-modified files into Module files.

There is a new field, "Destination", added to the GFF panel in ChangeEdit where this can be set. If the field is left blank or set to "override", it will work like it always has, and the TSLPatcher will look for the file to modify in the override folder (or copy it there first if it doesn't already exist).

If the field is set to the name of an ERF format file, the modified GFF format file will be added to that ERF archive instead, and not be put in override. Note that files inserted into ERFs will totally ignore the user's override folder, and such the file will be taken from the tslpatchdata folder, modified according to instruction and then inserted into the ERF. If a resource with that name already exists in the ERF file it will be overwritten by the new file that's added.

To make things even more confusing, the destination ERF file must be located within the tslpatchdata folder, where it will have the modified files added. You'll then have to add the ERF file to the Install... list of files to place it in whatever game folder it should be located in. This is the only exception to the rule to never add files modified by the TLK/2DA/GFF sections to the Install... list.

The Script panel in ChangeEdit has a corresponding Destination box as well, allowing any resulting NCS files from recompiled scripts to be added to ERF archive files.

* * *

As far as my limited testing has shown this new feature appears to work, but as usual it's entirely possible, and quite likely, that there are bugs and problems I have overlooked. If anyone is brave enough to help me test this and find any problems, please let me know. :)

stoffe
02-05-2006, 03:40 PM
I just uploaded a new test version, TSLPatcher v1.2.5a (WIP v2) (http://www.algonet.se/~stoffe/TSLPatcher125wip.rar), which contains two fixes for problems I discovered with the previous versions:


One is a fix for a bug that prevented scripts using include files from being compiled properly after being processed.
The other is a modification of the Script process/compile functionality that enables it to process include files for tokens as well, and not just the compilable scripts themselves (which I had forgotten about before) :)


As usual, feedback, comments and bug reports are welcome (and probably needed if this thing ever is to leave the "test" stage :) ).

rgdelta
02-06-2006, 12:36 AM
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.

tk102
02-06-2006, 03:01 AM
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.

Patriarch
02-08-2006, 06:22 AM
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!

CaptainWhyNot
02-17-2006, 06:36 AM
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.

stoffe
02-17-2006, 07:32 AM
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. :)

CaptainWhyNot
02-17-2006, 08:13 PM
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.

The Source
03-06-2006, 07:03 PM
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

stoffe
03-09-2006, 05:16 PM
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.

ChAiNz.2da
03-12-2006, 06:56 AM
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

The Source
03-12-2006, 03:30 PM
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?

RedHawke
03-12-2006, 10:59 PM
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

stoffe
03-25-2006, 07:36 PM
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.

DarkSpiral
03-26-2006, 12:22 AM
A GFF compare option?

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

RedHawke
03-26-2006, 01:39 AM
Yup, I second that one! ;)

Sweet new additions there stoffe! :thumbsup:

stoffe
04-29-2006, 05:38 PM
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.

stoffe
05-28-2006, 06:25 PM
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.

Arαtoeldar
05-31-2006, 12:10 PM
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.

RedHawke
05-31-2006, 11:18 PM
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. :)

rgdelta
06-15-2006, 10:01 PM
I have a patched up unaltered kotor 1 TLK file and I have no problem opening it in tlked

Princess Artemis
06-22-2006, 05:10 PM
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?

stoffe
07-06-2006, 06:38 PM
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. :)

stoffe
07-08-2006, 11:50 AM
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.

stoffe
07-25-2006, 11:37 AM
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))

ChAiNz.2da
07-25-2006, 01:11 PM
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 :)

Princess Artemis
07-25-2006, 02:27 PM
(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.

stoffe
07-25-2006, 02:41 PM
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. ;)

Lit Ridl
07-30-2006, 03:18 AM
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
07-30-2006, 07:10 AM
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
07-31-2006, 12:00 PM
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
08-06-2006, 05:36 PM
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.

stoffe
08-09-2006, 05:59 PM
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
08-11-2006, 04:41 PM
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
08-11-2006, 06:26 PM
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
08-11-2006, 07:00 PM
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
08-11-2006, 08:11 PM
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
08-11-2006, 11:02 PM
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
08-12-2006, 03:52 AM
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
08-23-2006, 05:13 PM
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
08-24-2006, 02:57 AM
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
08-27-2006, 07:41 PM
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? ^-^;

stoffe
08-27-2006, 08:36 PM
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...

Master Kavar
08-27-2006, 09:28 PM
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
08-27-2006, 09:36 PM
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
08-27-2006, 09:49 PM
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
08-28-2006, 03:21 AM
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
08-28-2006, 07:05 AM
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
08-28-2006, 05:40 PM
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
08-29-2006, 02:39 AM
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
08-29-2006, 05:21 AM
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
09-05-2006, 02:02 PM
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.

Char Ell
09-22-2006, 02:40 AM
I'm working on a very simple mod that will make Bao-Dur a Sentinel instead of a Guardian. The script portion was quite easy and took me 10 minutes.

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

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

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


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


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


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


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


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

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


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


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


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

Lit Ridl
09-30-2006, 06:49 AM
It may sounds really stupid...
May you release source code of your TSLpatcher, please???

stoffe
09-30-2006, 10:23 AM
It may sounds really stupid...
May you release source code of your TSLpatcher, please???

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

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

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

What would you want it for?

Lit Ridl
09-30-2006, 11:27 AM
I want to translate it to Russian, German and French. That is all.

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

stoffe
09-30-2006, 02:55 PM
I want to translate it to Russian, German and French. That is all.


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


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

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

Lit Ridl
10-01-2006, 05:44 AM
Yeah, Resource file is great idea!

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

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

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

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

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


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


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


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


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


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


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


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


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


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

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

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

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

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


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

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

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

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

Darth Reign
11-26-2006, 11:37 AM
Please do not shoot me. I hope I am not repeating another question.

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

stoffe
11-26-2006, 11:43 AM
Please do not shoot me. I hope I am not repeating another question.

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

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

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

Darth Reign
11-26-2006, 11:46 AM
Thanks Stoffe -mkb-

I thought I overlooked something. :)

The Source
11-29-2006, 11:09 AM
Lady Stoffe,

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

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

Thank you,
MacCorp

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

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

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

* * *

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

Darkkender
12-10-2006, 05:38 PM
Well it worked partially there Stoffe however it still copies files into the overide. Then it tries to patch the 2da files. When it gives it's error it also leaves the files in override. here is the installlog.


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

stoffe
12-10-2006, 06:23 PM
Well it worked partially there Stoffe however it still copies files into the overide. Then it tries to patch the 2da files. When it gives it's error it also leaves the files in override. here is the installlog.


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

Darkkender
12-11-2006, 01:10 AM
Cool, I was hoping the installlog above would help you out.

stoffe
12-12-2006, 11:40 AM
Well it worked partially there Stoffe however it still copies files into the overide. Then it tries to patch the 2da files. When it gives it's error it also leaves the files in override.

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

Darkkender
12-12-2006, 12:37 PM
I'll give it a try and see that it works. If it doesn't I'm keeping my mouth shut though. ;)

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

rocky348
05-28-2007, 07:42 PM
Ok, I think i followed your dialog tutorial step for step, but i get the following output when I run the setup file, what did I do wrong?


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


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

thanks any help would be appreciated

ciao for now

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

stoffe
07-20-2007, 08:53 AM
What I want to know is:
If the game will read them, why can't we direct TSLPatcher to edit or place .2da files wherever we want?


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

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

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

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

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

stoffe
07-26-2007, 04:07 PM
So what do people think is the best way for me to try and ensure compatibility with TSLRP if I'm using TSLPatcher?

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

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

Kristy Kistic
08-11-2007, 11:06 PM
Hi Stoffe :)

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

stoffe
08-13-2007, 02:28 PM
Hi Stoffe :)

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

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

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

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

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

Undying_Jedi
08-14-2007, 10:05 PM
hi,

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

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

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


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

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

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

stoffe
08-15-2007, 10:39 AM
5, the error occurrs right after i click the install button in the installer. it doesnt even ask for my game folder

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

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

Undying_Jedi
08-15-2007, 03:42 PM
Thanks!!!!!!! :) :D

its working now! much appreciated!!

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

again, thanks so much!! :D

Darth Vanisher
08-20-2007, 08:24 AM
Err... excuse me, wanted to ask something about TSL Patcher.
Actually, it's about the .2da files.

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

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

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

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

Kristy Kistic
08-29-2007, 01:01 AM
Hi stoffe :)

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

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

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

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

stoffe
08-29-2007, 07:03 PM
From what I gather, if the parent of the branch you want to add is an entry the Path var would be EntryList\<entry#>\RepliesList

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


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

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

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

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

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

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



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

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

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

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


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


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


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

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

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

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

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

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

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

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

Kristy Kistic
08-29-2007, 10:21 PM
Umm...sorry about that entire line of questioning. I completely missed a post where you explained about using the gff compare function. When I asked those questions I thought I was going to have to do it by hand (wasn't questioning your coding).

Still, thanks for the reply, though :)

stoffe
09-19-2007, 08:28 AM
I've uploaded TSLPatcher v1.2.10b1 and ChangeEdit v1.0.5b1 to correct a problem I just noticed, download link is in the first post in this thread as usual.

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

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

lang0=The quick brown fox

jumps over the lazy dog!

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

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

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

The quick brown fox

jumps over the lazy dog

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

The quick brown fox



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

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

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

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


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

(...)

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

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

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

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

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

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

So any thoughts?

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

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

The problem is with the line...

2DAMEMORY137=RowLabel

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

2DAMEMORY137=RowIndex

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



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

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

Soulforged
11-10-2007, 06:04 PM
The problem is with the line...

2DAMEMORY137=RowLabel

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

2DAMEMORY137=RowIndex

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



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

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