stoffe Posted January 8, 2006 Author Share Posted January 8, 2006 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. Link to comment Share on other sites More sharing options...
Darth333 Posted January 8, 2006 Share Posted January 8, 2006 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 Link to comment Share on other sites More sharing options...
rgdelta Posted January 9, 2006 Share Posted January 9, 2006 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??? Link to comment Share on other sites More sharing options...
stoffe Posted January 10, 2006 Author Share Posted January 10, 2006 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 ). Link to comment Share on other sites More sharing options...
rgdelta Posted January 10, 2006 Share Posted January 10, 2006 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. Link to comment Share on other sites More sharing options...
stoffe Posted January 10, 2006 Author Share Posted January 10, 2006 EDIT: I've made some further fixes, and updated ChangeEdit to support these new features. See this post 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.) Link to comment Share on other sites More sharing options...
ChAiNz.2da Posted January 12, 2006 Share Posted January 12, 2006 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! Link to comment Share on other sites More sharing options...
The Source Posted January 12, 2006 Share Posted January 12, 2006 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... Link to comment Share on other sites More sharing options...
stoffe Posted January 15, 2006 Author Share Posted January 15, 2006 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. Link to comment Share on other sites More sharing options...
Joris1 Posted January 15, 2006 Share Posted January 15, 2006 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? Link to comment Share on other sites More sharing options...
stoffe Posted January 15, 2006 Author Share Posted January 15, 2006 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. Link to comment Share on other sites More sharing options...
Joris1 Posted January 16, 2006 Share Posted January 16, 2006 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! Link to comment Share on other sites More sharing options...
stoffe Posted January 16, 2006 Author Share Posted January 16, 2006 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. Link to comment Share on other sites More sharing options...
Joris1 Posted January 16, 2006 Share Posted January 16, 2006 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! Link to comment Share on other sites More sharing options...
rgdelta Posted January 18, 2006 Share Posted January 18, 2006 Stoffe for the development of TSL Enhanced I am going to use your WIP version because things like the compile with tokens I need. Link to comment Share on other sites More sharing options...
Kristy Kistic Posted January 22, 2006 Share Posted January 22, 2006 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 Link to comment Share on other sites More sharing options...
stoffe Posted January 22, 2006 Author Share Posted January 22, 2006 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.) Link to comment Share on other sites More sharing options...
Patriarch Posted January 23, 2006 Share Posted January 23, 2006 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 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. Link to comment Share on other sites More sharing options...
stoffe Posted January 24, 2006 Author Share Posted January 24, 2006 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. ) Link to comment Share on other sites More sharing options...
SunBlade Posted January 24, 2006 Share Posted January 24, 2006 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 . Link to comment Share on other sites More sharing options...
stoffe Posted January 24, 2006 Author Share Posted January 24, 2006 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 ) Link to comment Share on other sites More sharing options...
SunBlade Posted January 25, 2006 Share Posted January 25, 2006 ... 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 ... 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=3 implied 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 ) 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 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=label SortRow 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 Link to comment Share on other sites More sharing options...
stoffe Posted January 26, 2006 Author Share Posted January 26, 2006 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. 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. Link to comment Share on other sites More sharing options...
stoffe Posted February 2, 2006 Author Share Posted February 2, 2006 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), 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. Link to comment Share on other sites More sharing options...
stoffe Posted February 5, 2006 Author Share Posted February 5, 2006 I just uploaded a new test version, TSLPatcher v1.2.5a (WIP v2), 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 ). Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.