Jump to content

Home

TSLPatcher v1.2.10b1 (mod installer)


Recommended Posts

  • Replies 312
  • Created
  • Last Reply
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.
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

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.

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

  • 1 month later...

In my ongoing effort to further complicate things, I just uploaded TSLPatcher v1.2.7b1 and ChangeEdit v1.0.4b1 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.

Link to comment
Share on other sites

  • 5 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...

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?

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...