AL|EN

mother of god ... Simple mod to print those variables: INITest/INITest.tp2 BACKUP ~INITest/backup~ SUPPORT ~~ AUTO_EVAL_STRINGS BEGIN ~Component 1~ DESIGNATED 1 NO_LOG_RECORD DEFINE_ACTION_FUNCTION read_in_ini STR_VAR filename="INITest/configuration-default" RET_ARRAY ini_content BEGIN COPY - "%filename%.ini" "%override%" // "COPY -" means no actual changes to the file REPLACE_TEXTUALLY ";.*" "" REPLACE_TEXTUALLY "#.*" "" REPLACE_TEXTUALLY "=" " " READ_2DA_ENTRIES_NOW ini_entries 2 FOR (i=0;i<ini_entries;i+=1) BEGIN READ_2DA_ENTRY_FORMER ini_entries i 0 key READ_2DA_ENTRY_FORMER ini_entries i 1 value SPRINT $ini_content("%key%") "%value%" END END LAF read_in_ini END PRINT "%timer11%" PRINT "%timer12%" PRINT "%timer13%" configuration-default.ini ;timer11 timer11=0 ;timer12 timer12=0 ;timer13 timer13=0 It doesn't print values probably because I miss something weidu-related, but we are getting close. One more look?

Can someone help me to create a code which: - read all content of the file, skip all lines with ; or # as first characters - put each line to array - for each line from array, split line via '=', assign first element to the 'variable name' assign second element to the 'variable value' - set 'variable name' = 'variable value' So far, I can't find any weidu function to read whole file into memory and assign this data to variable without modify the file itself.

This is what I cooked copied from cdtweaks BACKUP ~IMPsurprice/backup~ AUTHOR ~Jarno Mikkola aka The Imp~ AUTO_EVAL_STRINGS ALWAYS INCLUDE ~IMPsurprice/configuration-default.ini~ // config file ACTION_IF !VARIABLE_IS_SET timer11 THEN BEGIN OUTER_SET timer11 = 0 END ACTION_IF !VARIABLE_IS_SET timer12 THEN BEGIN OUTER_SET timer12 = 0 END ACTION_IF !VARIABLE_IS_SET timer13 THEN BEGIN OUTER_SET timer13 = 0 END ACTION_IF FILE_EXISTS ~IMPsurprice/configuration.ini~ THEN BEGIN INCLUDE ~IMPsurprice/configuration.ini~ // config file END END BEGIN ~Component 1~ DESIGNATED 1 PRINT "%timer11%" PRINT "%timer12%" PRINT "%timer13%" configuration-default.ini //timer11 OUTER_SET timer11 = 0 //timer12 OUTER_SET timer12 = 0 //timer13 OUTER_SET timer13 = 0 configuration.ini //timer11 OUTER_SET timer11 = 1 //timer12 OUTER_SET timer12 = 1 //timer13 OUTER_SET timer13 = 1 If user won't create configuration.ini, values will be read from configuration-default.ini But this solution is using 2DA format :/ Could someone help me with this request: http://gibberlings3.net/forums/index.php?showtopic=29657 ? Setup-IMPsurprice.zip

@Imp You code doesn't execute, please just post it as attachment/pastebin.

Could you can read baldur.ini file and check if 3D Acceleration equals 1? If not, use ABORT weidu function to skip this component without need to use READLN. Could you detect SPPR142/1342 somehow? I see only two choices so 'subcomponent' can also be used. I'm confident that other modders could offer solutions to get rid of READLN. Any kind of READLN options will pause installation and require user to provide input during every new installation. It's not unnecessary but it's major pain to deal for install tool: it's impossible to present such choices at the mod component list to the user before installation without providing custom made data. Life show us that nobody will do this anymore. Remarks: you are added spaces before and after, so it's "key(space)=(space)value" and it's not how INI file format is defined. You have to remove those spaces. I can't offer to read a custom made "INI version of the file format made by x" because every modder has his own ideas how to write config file. Some uses spaces, tabs, comas, some use weidu formats etc. It would be a nightmare to support. Also you name you file as 1pp.ini so next update will overwrite user choices. Please rename it to configuration-default.ini and add a comment: ";To use this file, rename it as configuration.ini and leave it in current folder."

Numbers and string values are not a problem for INI. You can even put "valueA,ValueB" and split it by comma via regexp to simulate array of multiple values. But for 'true' Arrays or more complex data values, HJSON must be used. One remark: you already posted an example of you own custom 'Gwendolyne unicorn' file format. It's not an ini file. Can you find out why? And you use custom "configuration filename". There is no way for the tool to detect and use it, if you don't use any of Point 3, solution a) b) or c) from previous page. Currently, only possible way is b) and c). Not a problem. The amount of choices/keys are infinite inside ini/json file. Or I misunderstand you.

First of all, it's really motivating to see modders who want to make players life easier. When I take look at READLN, it's the worst, most evil thing I could image. If my work would help you to get rid of it, I'm all ears. The most important thing is that an user-defined/modified config file should not be overwrite by new mod version because mod updates would destroy user configuration and cause infinite amount of frustration for them. This is one of the solution which I've posted. The logic to read both files and prioritize user values has to be coded inside mod itself but the file format of such file must be 'industry standard', more about this below... Forget about the past, new install tool could present 'mod configuration' dialog with editable values, but there are few key points: 0. File encoding It can be ANSI if it won't offer to write Unicode strings. UTF8 no BOM, it it does. ANSI: ;use only english color names Colors=Red UTF-8: ;Put anything here, including Unicode characters ComanionName=Pszczółka does weidu can read UTF8 files? 1. File format of such file must be 'industry standard', one for all mods. And please forget about xml I can't write a custom parser for each mod only because it's author like to put spaces before and after '=' character. Or use TAB to separate key and values. Or include weidu commands which the tool can't understand. It would be too much work and errors. So let's choose one, modern 'industry standard' file format. I vote would be for INI as a first choice and HJSON (JSON doesn't' allow comments) for more advanced modders who understand benefits of such modern format. More about this at point 4. 2. File extension of 'default configuration file': It would be the best for the tool to use correct file extension. My test shows that .ini files are opened via notepad on default, clean windows installation. Nothing to worry CamDawg 3. The filename of such 'default configuration file' and 'user configuration file', I propose 3 solutions: a) first detection/priority: will be defined by modders via mod tp2 file and "CONFIGURATION" keyword. It doesn't exist today, I can support it if it will be introduced. But I would rather avoid to depend on weidu. b) second detection/priority: will be defined by modders via "mod metadate file" - filename is the same as tp2: modname.tp2 > modname.ini/json - file is placed at the same directory as tp2 file - it has simple configuration = configuration.txt/ini/json key=value pair. This would allow more flexibility. c) third detection/priority: it will be defined via install tool itself because otherwise every mod will have different configuration file names and my only option would be then to scan mod folder for 'ini' or 'txt' or 'cfg' or something else and detect if it's a true mod configuration file. This is terrible way to do things. So this is my take: configuration-default.ini/json - for default mod values configuration.ini/json - for user-defined values, install tool will create copy of it when user will click "Configure Mod Options" 4. File content It should follow the format definition. So if it's ini, it has only key=value pair or comments (comments for ini are ; or #) : INI: ;This variable will remove the racial requirement if set to 1 ;e.g. a value of 1 will allow Viconia to romance gnomes, or Aerie half-orcs romance_racial_requirements=0 ;This variable will remove the gender-based requirements for romances if set to 1 ;e.g. a value of 1 will allow Anomen to romance males or Jaheira to romance females romance_gender_requirements=0 ... HJSON: { #This variable will remove the racial requirement if set to 1 #e.g. a value of 1 will allow Viconia to romance gnomes, or Aerie half-orcs romance_racial_requirements: 0 #This variable will remove the gender-based requirements for romances if set to 1 #e.g. a value of 1 will allow Anomen to romance males or Jaheira to romance females romance_gender_requirements: 0 } 5. Presentation to user When tool will detect 'configuration' file, using any of the method from Point 3, it will show "Configure Mod Options" button which will: If 'configuration.ini' file doesn't exist: - create 'configuration' file by coping 'configuration-default.ini' - open 'configuration.ini' file using default system editor If 'configuration.ini' file exist: - open 'configuration-default.ini' file using default system editor (there is also possible to scan and add missing values from 'configuration-default.ini' but I would have to test it and see how it works, not promises for now) That's very simple yet effective approach. More advanced approach would be to add "key=value" pairs as a editable nodes in TreeView below all mod components More work but it can be done. I will post example later. 6. Input constraints How about declare input constraints like "between 1 and 5" or choose only from 'green' 'red' values? Does it's something which you would like to have or it's out of scope and should be handled via mod tp2 internal logic ? It would require extra data to be included inside file but it can be done. That's everything which comes to my mind, let's do this

It was a typo, I mean "change 'read setting logic' to always read from configuration.ini if it is present" similar as example below. Good catch. First solution for this problem which comes to my mind: step 1: read configuration-default.ini file step 2: if file exist, read configuration.ini file and use user customized values for previous keys This way, you can add new config variables with default values while keeping user customized values. Thoughts?

Ha! Amazing creativity when you need to "get things done" I'm aware that the purpose of this file is to be read only by SCS. It would be very helpful to change the format of this file to "Key=Value" pairs because I can parse it via industry standard algorithm. I notice one problem with the way how you designed the "reading SCS custom option from configuration file": Steps to reproduce: 0. Download and extract SCS 1. Edit stratagems.ini and set desired options 2. Install SCS 31 4. New version is released, download and extract SCS 32 > stratagems\stratagems.ini will be introverted to default one, it will happen every time when new version will be released > reinstall SCS Possible way to fix: - rename stratagems.ini to configuration-default.ini (reason for renaming - I try to be one-step-ahead of what I will ask/provide by myself next) - change 'read setting logic' to always read from configuration.ini it it is present If you could fix this before releasing 32, you will save yourself the trouble of receiving bug reports about 'my settings don't work anymore'

Hi @DavidW There is no industry standard way way to read stratagems.ini as it isn't 'ini' file by it's technical definition. It doesn't even contain "Key=Value" pair. It's a text file with characters and numbers divided by spaces. Because of that, there is no standard way to read this configuration and present to player. May I suggest to use industry standard format like ini/json/xml etc ?

Hello fellow adventurers, if you ever wanted to provide feedback about New Install Tool, this is you chance. this time there won't be any poll. Instead, I need you to tell me about everything related to installing mods via Install Tool. Players: please tell me what you don't like about BWS (yep, GUI sucks) what should be improved and what is missing. Don't write something like "same as BWS, only better", focus on most annoying or important things. Modders: which features related to mod presentation/configuration/maintaining new Install Tool should have? Every feedback will be read and take into consideration but not everything is possible You can also come to Discord Channel https://discord.gg/NfhByE and have discussion

@Miloch I forgot about those tweaks, thanks for bringing it up! I might take look at other mods and see if there is something worth including.

Thanks for this! In addition to my previous suggestions, in my opinion it would be nice to transfer these SCS components: - Reduced reputation increase - Increase the price of a licence to practice magic in Athkatla - Increase the price asked by Gaelan Baele It's because those components are very useful (even without SCS) for medium-large installation when you are dealing with lot of gold and quests. Thoughts?

It's not discrimination lol, 32-bits are past, just like Windows XP. There is nothing which prevents you from having 64-bit OS. There are two problems, one that you can't execute weidu 64-bit, second is that weidu 32-bit can't auto-update 64-bit versions and it hangs. The solution is simple: install 64-bit OS to avoid such problems in the future for other mods or: - delete setup-bg1ub.exe - download http://weidu.org/~thebigg/weidu.exe - rename to setup-bg1ub.exe Hope that this will help you.

Nothing is wrong with the mod itself. Does you Windows 7 is 32-bit or 64-bit ?

Maybe the baldur.exe process was running during mod installation or maybe AV blocked modifying .tlk files. Disable AV and reinstall.

Take look at WeiDu.conf file inside main BG2EE directory and check which language is set for all mods. In case it's not en_US, you have to change it and reinstall all mods.

Those are Ascension know issues with BG2EE 2.5, please post errors from mods to proper topics

@Uhtredsson Which OS do you use?

No it doesn't. I don't know much about iwdification influence at later SCS install. You should make new thread with such general question.

Forum engine bug, updated to: https://github.com/Gibberlings3/SwordCoastStratagems/archive/RevisedSCS.zip

False alarm. After restoring the game, installation went fine.

In my opinion, spell changes are needed for AI, item changes makes game harder so it's fine. Only few SCS components (NPC ones) are candidates for adoption by Tweaks Anthology.

I'm glad to hear that. This time I won't speak for anyone except myself: just tell when.

Good to know, I can deprecate Fixpack method for RevisedSCS. I support lots of things that aren't my optimal design choices. SCS has supported SR pretty extensively for years and I'm not planning to change that. I suspect I know SR better than anyone else knows the innards of SCS! The intention of my reply was in context of this custom, community-made RevisedSCS "package" and you support for it, not the "general SCS support for SR". Also regarding the SR, I'm fully aware that you are capable of dealing with SR. How can anyone doubt that? I was referring to the fact that constantly track SR changes might be overwhelming and the support from the person who "knows/created recent SR changes" should be expected. Too many mental shortcuts are bad. If I stepped at you toe, I'm sorry, didn't mean to.