AL|EN

Yes, as the author said https://www.gibberlings3.net/forums/topic/30323-wheels-of-prophecy-updated-to-83/?tab=comments#comment-290183

Wheels of Prophecy - this mod is not yet compatible with EE You didn't provide version numbers of those mods so we can't see if any of it is outdated.

@Taylan For developing WeiDU code, use VSCode + BGforge MSL extension.

@subtledoctorYou might want to call @Magus with this https://github.com/BGforgeNet/bg2-tweaks-and-tricks/issues/5 Personally, I would love such tweak.

Yes, WeiDU 247 is required, old way still works. I strongly believe that there is a reason to update even the old mods which use old way. You need to ask wisp why providing path to out_path parameter doesn't create it automatically.

@Jazira You can update single lines of translation by simply posting it at the forum but only after the mod code and files is updated to use HANDLE_CHARSETS with from_utf8 = 1 parameter. When all source files are using UTF8 (because the mod is EE-only anyway) there is no need to use HANDLE_CHARSETS at all and you also can send translations directly via forum posts etc.

@Jazira Nope, not at all. Text copied from forums/webpages is using UTF8 generally, pasting such encoded text into ASCI files often breaks them. It depends on the editor, codepage and local settings of the modder. Too much thing to handle and too much things that can go wrong here. Murphy's Law.

@Magus But it has nothing to do with 'updating mods to latest mod release'. The thing which you describe is out of the scope of 'mod update' feature. Players can always revert to older mod version so the working state of the installation will be untouched. Also updating mods during the run is never a good idea. The thing which you want is some sort of sophisticated multi-stage backup and restore feature. I'm afraid that this is too big to handle.

EDIT: Turns out the code is incompatible with AUTO_TRA. Until future investigation, you can't use this if you are not wiling to resign from using AUTO_TRA function. EDIT: Guide was updated to reflect recent WeiDU 249 changes. AUTO_TRA is now fully supported. Introduction: Since introduction of HANDLE_CHARSETS, modders have given the ability to support translation for both classic and enhanced editions of the Infinity Engine games. The function itself was doing it's job: convert file encoding from one to another. But it also had annoyances which various modders was able to overcome via custom code. Now, with the introduction of `out_path` parameter, all of the annoyances are gone. This is an attempt to show how to get the best out of HANDLE_CHARSETS. How it was handled before: translators provide .tra files using their own preferred local encoding HANDLE_CHARSETS function convert those files into UTF8 encoding when mod was installed on enhanced game editions How it is handled now: translators provide .tra files using UTF8 encoding when the mod is installed on classic game editions, the temporary copy of translation files are converted into ASCII encoding so the source files are not touched no modification of original UTF8-files when mod is installed on enhanced game editions Using new way will save you from annoyances and allow for new features: modders no longer need to watch-out to not break custom encoding when editing foreign tra files modders can receive translations via forum posts and it can be used instantly, without hustle translators are no longer required to send files just to update one single line translation can be provided by editing files directly via GitHub online interface DOS/Shell console messages can finally have localized characters displayed properly (required Windows 10 1903 and above, for Windows 7/Windows 8.1 you have to use Cmder/ConEmu/other modern terminal with "chcp 65001" command) Requirements: required minimum version of WeiDU is 249 if you are updating old mod, you have to properly convert .tra files to UTF8 using correct codepage for specific language Full code example: https://github.com/InfinityMods/WeiDU-UTF8 Code explanation: BACKUP "weidu_external\backup\WeiDU-UTF8-Example" // move backup folder outside of the main mod data folder Move backup folder outside of the main mod data folder. The %MOD_FOLDER% is read from this value but WeiDU 249 should correct it to the main mod folder name. // do not convert Setup.tra files, those should be UTF8 already ACTION_DEFINE_ARRAY arrayNoConvert BEGIN Setup END ACTION_DEFINE_ARRAY arrayReload BEGIN Mod NPC NPCP NPC25P END Define two arrays for `noconvert_array` and `reload_array` parameters of `HANDLE_CHARSETS` function because those parameters require array. You cannot provide the filenames directly. The .tra file extension is optional. Do not convert Setup.tra files, those should be UTF8 already. LAF HANDLE_CHARSETS INT_VAR from_utf8 = 1 //the source tra files of all languages are UTF8 infer_charset = 1 //set the correct encoding for classic games based on the detected game and associated encoding verbose = 1 //display more debugging info Parameter from_utf8 = 1will tell WeiDU that the source tra files of all languages are UTF8. The infer_charset = 1 will set the correct encoding for classic games based on the detected game and associated encoding. The verbose = 1 will display more debugging info. // define variable for HANDLE_CHARSETS out_path so it can be reused later OUTER_TEXT_SPRINT "HANDLE_CHARSETS_OUT_PATH" EVAL "weidu_external\Lang\%MOD_FOLDER%" Define variable for HANDLE_CHARSETS out_path so it can be reused later and it will keep it in sync. tra_path = "%MOD_FOLDER%\lang" // path to translation files, do not add slash at the end of it Path to translation files, do not add slash at the end of it. out_path = EVAL "%HANDLE_CHARSETS_OUT_PATH%" // location of converted .tra files This is very important. WeiDU documentation says: "Note that if %tra_path and out_path are the same directory, the conversion will naturally happen only once regardless of how many times HANDLE_CHARSETS are invoked, but if the directories are different, the conversion will happen for every invocation (notably, if HANDLE_CHARSETS is invoked among the ALWAYS actions)." So when WeiDU preforming conversion operation, it overwrite original mod files and it can also change their encoding if the mod was installed on the classic editions of the games. So in order to keep original files intact, we need to provide two different path for `out_path` and `tra_path` parameters. Since WeiDU doesn't have concept of 'temporary work directory' we need to create it manually earlier. Also, if you mod uses AUTRO_TRA, you have to use the "%TRA_LOCATION%" path: // for the EE games, the variable will point to the untouched .tra files // for classic games will point to the HANDLE_CHARSETS out_path value where converted files are stored AUTO_TRA "%TRA_LOCATION%\%s" The rest of the mod that code covers changing game string and creating of default NPC with initial dialogues are only to quickly test the results and they are not related to the main goal of this guide. Please refer to WeiDU Documentation or ask here.

@Magus Well, how do you call an update that internally takes delta of the mod files and apply to local files in order to produce new file version without downloading it again? I don't get the second part, can you clariffy?

@Cynrain Which version of Ascension you use?

Well, I was mislead by strange combination of UTF-coded polish chars inside file with 1250 codepage: Sorry for confusion. @Mike1072 Can you merge this please?

I would like to get your feedback, thoughts, and experience regarding the installation routine of WeiDU mods. Assume that we have a mod called "MurphyLaw" , version "1.1.1" with the description of "Anything that can possibly go wrong, does." Most players have this mod installed with version "1.1.1". After a long time, there was an update to "v2.0.0". Players want to update the mod. For every possible case that might exist, what would be the safest and least error-prone workflow in order to have a successful mod update? Case A - Single mod or the mod that was installed as the last one A1 - What players do: Extract new 'MurphyLaw v2.0.0' version into the game directory, overwriting old 'MurphyLaw' files Re-install the same components by launching Setup-MurphyLaw and selecting "Re-install" for every component (WeiDU will then reinstall updated MurphyLaw) A2 - Proposed workflow: Keep the names of the currently installed components Uninstall the old version of the 'MurphyLaw' by launching Setup-MurphyLaw --uninstall Remove old 'MurphyLaw v1.1.1' directory from the game directory Extract 'MurphyLaw v2.0.0' version into the game directory Install the same components again by their names Case B - Updating and reinstalling mod that was installed between other mods: B1 - What players do: Extract new mod version into game directory overwriting old 'MurphyLaw' files Re-install the same components by launching Setup-MurphyLaw and selecting "Re-install" for every component (WeiDU will then reinstall updated MurphyLaw and all mods installed after) B2 - Proposed workflow: Keep the names of the currently installed components for the 'MurphyLaw v1.1.1' and for all other mods installed after Uninstall all mods after the updated mod by launching Setup-MyMod --uninstall in reverse order from WeiDU.log Uninstall the 'MurphyLaw v1.1.1' by launching Setup-MurphyLaw --uninstall Remove 'MurphyLaw v1.1.1' mod directory from the game directory Extract 'MurphyLaw v2.0.0' into the game directory Install 'MurphyLaw v2.0.0' using the same components Install all remaining mods that were installed after updated mod Explanation: Why uninstallation and removal is required instead of simply overwriting the mod files? The first reason would the way how WeiDU handles reinstalling mod components. WeiDU keeps 'uninstall information' inside sub-folder name of component index number or mod DESIGNATED number if exist. "MurphyLaw v1.1.1" comes with 3 components: "Weapons", "Armors", "Shields". WeiDU.log contains the following: ~MURPHYLAW/MURPHYLAW.TP2~ #0 #0 // Weapons: v1.1.1 ~MURPHYLAW/MURPHYLAW.TP2~ #0 #1 // Armors: v1.1.1 ~MURPHYLAW/MURPHYLAW.TP2~ #0 #2 // Shields: v1.1.1 "MurphyLaw v2.0.0" comes with 6 components components: "Armors: Mail", "Armors: Plate", "Shields: Large", "Shields: Medium", "Weapons: Sling", "Weapons: Spear". The indexes of those components are 0,1,2,3,4,5. So If you do 'Extract> Overwrite and Reinstall' you would actually install completely different components of "MurphyLaw v2.0.0": "Armors: Leather", "Armors: Plate", "Shields: Large" The next thing would be the code loops. Mods often contain code that has some sort of loops: for (every file inside MurphyLaw/ITM directory) COPY file TO override directory. If the author of "MurphyLaw v2.0.0" removes some files from the MurphyLaw/ITM directory and the user simply extract the new version into game folder, the old files won't be removed. Mod re-installation via weidu will still copy old files that should no longer exist. This also can lead to problems and false bug reports. Questions: Assuming that even if I A2 and B2 workflows are complicated and manually preforming those steps require multiple actions and is time consuming: Do you think that those are correct or there are some missing steps that I should include? Do you think such A2 and B2 workflows should be the default and forced when the players re-install mods to achieve safest and least error-prone mod updates? @Wisp Could you provide insights?

@Roberciiik Can you please revert removing of polish characters from component names? They are working fine: You could actually update component names to have all polish characters included.

@Angel Yes, you need to be in the BG installation directory.

WoW! Such attention to details. I like it!

Revisiting this topic, there is one thing I need to mention. tl;dr If you use GitHub releases to ship new versions, after creating a release do not edit it in any way. Yes, that includes manually replacing mod packages or manipulating tags. You can change the title and description. If the mod is hosted on GitHub and you do not use releases, everything below doesn't apply to you but you are encouraged to read this anyway. If the mod is hosted on GitHub and you use releases to ship new versions, there are some things you must not do because bad things will happen. In order to not break things, simply follow the usual Git + GitHub workflow: Update tp2 VERSION keyword, update readme with version, and changelog Create final local commit with all 'ready-to-go' changes Push local commits into a remote repository Optionally, create mod packages that you will later add to the release or use automated tools Create release via the GitHub web interface (or via tools) with the same tag as VERSION This is the end of the road. After publishing release, you cannot: add other tags to the same release remove or replace existing tags replace mod packages with new ones that contain changes that were created and committed later than release tag If you have done ANY modification to the local files, especially if you discover mistakes, and you want to 'update' the mod, you must repeat all of the steps above. Helpful tools that follows required workflow: There are new tools that will ensure that not only will save you time but ensure you will follow this workflow every time and save you from trivial mistakes. Mod Release - among other things, it prevents creating "2.0.0" release when your mod version is "1.8.0", prevents creating a new release if there are uncommitted file modifications and prevent creating a new release if the same release already exists. Infinity Auto Packager - among other things, it prevents creating mod packages that might contain locally uncommitted changes Clarification: PI cannot use release packages for updating the mods, it uses release tags in order to match the state of local files with the state of remote files. So especially you shouldn't replace mod packages inside release with new ones that contain changes. If you do, the mod update will not contain the latest changes and so the 'update' feature appears to be broken. Forget about PI for one moment. Know that some smart people can use GitHub clients to 'update' all mods from GitHub by simply 'pulling latest tags'. They expect that the 'release tags' represent the code for the release because everything else that is hosted on GitHub (software/projects/etc) ensure this is true. I hope this will clarify some aspects of mod updates via releases. Again, this doesn't concern you if your mod has no releases. This is now included inside the documentation of Delta updates for mods.

Hello, The Fishing for Trouble has been updated to version v3.2.6. It's minor release mainly to include Russian translation, traify files and some code improvements. I would like to thanks AGKanevchev for the updated Russian translation. Download: Zip package - https://lynxlynx.info/ie/modhub.php?InfinityMods/FishingForTrouble&pkg=zip IEMod package - https://lynxlynx.info/ie/modhub.php?InfinityMods/FishingForTrouble&pkg=iemod Visit the Forum

@JMKarlssonYou might try to use improved version of 'changelog' tool: https://github.com/InfinityMods/WeiDU-FileChangelog Just extract it into the game directory, launch and provide filename. Logs will be inside "WeiDU-FileChangelog" dir.

@Wolfdscf You need to launch "setup-DlcMerger.command" file. Directly launching executable will not correctly set it's working directory to the location where the executable exist.

Updates that I gather over the last months: use MARKDOWN file format with lists, tables for better reading added 'case-insensitive' for all rules update list of forbidden top-level files and folders update list of forbidden special files and folders added list of forbidden files and folders names starting with prefixes added examples replace 'may-exclude' with 'should-exclude' to encourage best practices added ".*" (all files starting with dot) to 'should-exclude' removed 'bgforge.ini' as it no longer exist, it was renamed to ".bgforge.yml" and it's covered by ".*" rule removed archives since modders put the source code of unmodified extra tools into mod packages removed 'ehthumbs.db' because redundant in 2021 - those files are created only when someone who develops mod has Vista (<0.8% marketshare) and open the mod directory via Media Center application Remarks: It's painful to see that package format would allow pollution of main game directory with files, let this thing go away. Replace 'must contain tp2' with 'if exist' so IEMOD package could be used for 'non-weidu' mods. I'm not entirely sure if we should disallow 'override' directory. Simple mods which contain only files could be zipped with top-level 'override' directory which contain fixed files and the install proces would be straightforward - extracting package content into main game directory and that's it.

Main motivation is that many modders like to use Capital-Letters for their files. When they provided the Windows weidu executable manually inside mod packages, they keep the case of 'Setup-' prefix. You can see this in many mods. Infinity Auto Packager provide the weidu executable but some of them want's to keep the case. Also, other modders didn't like the fact that even if they lowercase mod all files, the 'Setup-' prefix still has Uppercase letter.

# 1.1.2 the case of the letter 's' in 'setup-' prefix for Windows WeiDU executable will match the first letter of mod tp2 name example: if the mod tp2 is Abc.tp2, the 'Setup-' prefix will have uppercase 'S' macOS WeiDU executable and .command file will not be altered # 1.1.1 fixed empty package name when there was no .ini file

@lynx Thanks for correctly investigation the root cause and providing support. @jastey The bug with empty package name is fixed. Thanks for reporting.

There was a proposed repo, it was using one file with 'sorting order' syntax. Loading it from online source was not a problem but there was no point of doing that when almost noone wanted to contribute. But as you said, some players investigate install order data and wanted to contribut to the mod directly. If the rules would exist only in online list, I'm pretty sure that PR from players would not exist because they have no idea bout existence of them. I know it looks the same but apparently it's not. Some modders acts like watchmakers - alone, releasing their creation from time to time, without interacting with anything outside. Interacting with 'online list' is extra layer of work. It's easier and less time consuming for modders to put install order data inside they locally developed mods and simply do a release then repeat this step for each mod. Also less chance that somebody will forget update data after component changes. Later, the new mod maintainers can also contribute (or atleast don't break) to the install order data instead because it's already part of the mod. If such situation occurs, It's possible to provide a a feature which will 'overwrite' faulty rules. Hopefully, it won't be needed.