TSLPatcher v1.2.10b1 (mod installer)

[stoffe]

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

 

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]
[b]ExclusiveColumn=label[/b]
label=WristConsole
name=****
spelldesc=****
(etc...)

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

 

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

[ChAiNz.2da]

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!

 

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

 

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

[Commas]

Originally posted by stoffe -mkb-

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

 

ok, i have two questions about this:

 

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

 

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

[stoffe]

Originally posted by Commas

ok, i have two questions about this:

 

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

 

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

 

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

 

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

 

 

Originally posted by Commas

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

 

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

[Commas]

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

[RedHawke]

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

 

Thanks again stoffe!

 

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

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

[ChAiNz.2da]

thanks for the tip stoffe!

 

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

 

I think I'll try your way next time

[TheOssusKeeper]

Stoffe, that is a cool idea... thanks

[stoffe]

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

 

You can download a fixed version here, 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.

[ChAiNz.2da]

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!

 

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"

 

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

[stoffe]

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"

 

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

 

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

 

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

 

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

 

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

[hkoldrat]

hi i'm new here please forgive me should i act noobish or for my english as i'm not native.....

 

back on topic, i can't seem to run the files of the patcher, it only shows an error message like "RichEdit line insertation error" or something of that manner

since i got a few mods with same modded files, it seems i must merge them, and unfrotunately this patcher is the only tool i can find on the net....

any ideas would be welcome

thanks for the attention

[stoffe]

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. Unzip and put those in the System32 folder inside your Windows folder. Back up the original files that exist there first before replacing them.

 

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

PlaintextLog=1

 

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

[ChAiNz.2da]

(Hopefully since I can't reproduce the error myself, so I don't know for sure what's causing it. )

Hey stoffe, I got to thinking on this.

 

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

 

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

 

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

[stoffe]

Could it perchance be caused by depending on what program the modder used to create their .rtf file?

 

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

 

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

 

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

 

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

[ChAiNz.2da]

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

 

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

[hkoldrat]

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

[stoffe]

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. 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. This can be used for those who have problems with their RichEdit DLLs to (hopefully) still run the TSLPatcher correctly, though in a somewhat less eye-friendly way.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

Bugs, questions or suggestions? Please let me know.

 

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

[tk102]

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?

 

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.

[Commas]

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 )! this is truly one of the best apps available for kotor modding. Brilliant! keep up the excellent work!

 

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

[ChAiNz.2da]

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

Is this just recent?? (I noticed it was posted on SWK) ahh well... I've got it now... hehehe

 

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

Fixed it There was a run-on img tag placed side-by-side, and if you're like me... you have sig images turned off?...

 

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

[Lord Hydronium]

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

[stoffe]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[Lord Hydronium]

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