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

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

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

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.

awesome, thanks! thats a huge relief, i thought i was going to have to go back and change a bunch of entries. thanks again!

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!

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.

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

Stoffe, that is a cool idea... :D thanks

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

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:

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

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

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

(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

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

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:

thanks.....now the patcher works.....thanks for the assistance

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

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:

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!

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

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?

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.

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

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.

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

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:

well thats what i was wondering, how does the patcher know to add a new line or what number to assign?

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

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

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

ok, i'll try that and see what happens, but should i go ahead and add the rowlabel high() as well?

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.

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:

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

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?

yes, a clean one extracted strat from the kotor tool...

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

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?

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

nope, no skipped no.'s...

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?

it didn't ask...

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

okey dokey, i'll give 'er a whirl... hehehe :D

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?

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.

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

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

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?