hey Stoffe, version 1.1.7 works like a dream, thanks... :D keep up the good work... :thumbsup:

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.

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

I was actually comparing two modified files, but thanks - that makes a lot more sense now :)

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.

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

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

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.

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

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

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

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:

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

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.

Whenever I click the install mod button, I got a "RichEdit Line Insertion Error" message. Anyone know why?

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)

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

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

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

I already try that! It contains only the exe file

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.

Yes, but how can I pack everything in the .exe??

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.

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"???

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

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.

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

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

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.

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

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:

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

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.

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?

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.

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!

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

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!

Stoffe for the development of TSL Enhanced I am going to use your WIP version because things like the compile with tokens I need.

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

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

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.

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

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

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

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

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

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

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