AL|EN

The description was updated to reflect that the zip package always contains the latest official WeiDU version from https://github.com/WeiDUorg/weidu/releases, at the time when it has been created.

@Salk The size difference comes from WeiDU 247 being distributed without UPX compression. One of the benefits is that exe won't be flagged as falsely positive virus. @jastey It's normal WeiDU, taken directly from https://github.com/WeiDUorg/weidu/releases

FWIW, the immutability of HANDLE_CHARSETS function that is described here, can now be done with out-of-the-box features by using newly added "out_path" parameter. The instruction and examples can be found here.

Guide was updated to reflect proper and supported usage along with AUTO_TRA. This part of the code was changed: AUTO_TRA "weidu_external\lang\%MOD_FOLDER%\%s" //use out_path + \%s You can now use it freely, without limitation.

Congratulations!

At the risk of biased questions, I added an anonymous poll. Please don't be terrified by this, it's not like we are setting-up Devil's pledge. BTW: The discussion regarding "LABEL's vs marker files" was moved to this topic at my request and with subtledoctor consents.

Because I was the most complain person regarding this, I felt obligated to do everything regarding this matter. This includes updates to weidu documentation so new modders would be encouraged not to use ACTION_READLN. I'm happy to announce that a well-crafted description has been added to the docs. Thanks wisp!

Did you mean " to 23600 version or above" ?

@jastey FfT should now have face.ids from BST as of v3.2.8

@subtledoctor I think you misunderstood me. All examples except the "Refinements" are not falling into above: every component or combination of them has different outcome. For "Refinements", the HLA components can have only two outcomes: install all HLA's or only some HLA's: The 'all HLA's outcome" is achievable by selecting 8 HLA's components The 'some HLA's outcome" is achievable by the same HLA's components but not all of them Yet, there is a third choice to have 'all HLA's outcome" by selecting an extra component <- this will give the player the same outcome as 1 so it's redundant But ye, while mod manager will present those choices at once, weidu is offering components selection as one-by-one so I guess it's yet another area for it's improvement. I'm nitpicking, let's leave it for now. I'm grateful that you find LABEL's being useful. This one is interesting, please explain: Do you use the "file is detected" as "REQUIRE/FORBID" component or rather to "skip some part of the code" during the actual installation when all 'requirement/forbid conditions' were previously evaluated? So the hypothetically selected component will still be present inside weidu.log but because of 'FILE_IS' condition, the actual code was skipped entirely and it's like dummy component? To put it another way, if there will be ever a situation when the player chooses a particular component combination, then one or more components will be completely skipped because of 'file check" and it won't be added to weidu.log?

@subtledoctor After reviewing your use-case again and comparing it to some former cases (where the main mod component was spitted into several) and other examples of the 'component reorganization', I conclude that there is a little bit more to the story. Later, I will cover this in a separate topic with more examples but for now, I hope that we can continue this discussion in good faith. I understand that the mod is in the early stage of development so the work and focus is putted elsewhere than component system. The weidu installation routine itself encounters modders to start with one big component at the beginning. Later, comes the 'let's offer more choices" thought. But it is really a meaningfull choice? The point I would like to make is that if you are spiting the main component into several smaller ones, so all content of the big one main component is covered by them, there is no point in keeping the main component anymore. It offers nothing new for the player, no new content etc. When the player will use your mod, he will be presented with 6 choices, choose what he wants, mod manager will save his choices (hopefully!) and he could then even use the same selection for other games. Why keeping it only to introduce more complexity into the mod itself, which then you have to deal with later? The less complex the component system would be the less work you will spend on it. Anyway, this is something which I thought.

@subtledoctor I don't mind mentioning 'marker files' or any other thing which sparks discussion. Having hundreds of extra files inside override is not something that I would rise against using marker files. If you are focusing on this use-case, it seems valid. That being said, you emphasize over marker files because you limit the usage context only to the simplest possible feature, that is, a detection if some component was installed into the game and the code should account for that. Marker files have no semantic meaning unless you explicitly define them via code and arbitrary textual description. It's like checking if the game is BG2EE by detecting the existence of hexxat.cre. Sure, weidu allows you for doing that and you won't be the first modder who is doing it. Weidu also has a standard function which you can use for the same purpose. And when you take look at recently updated mods, for eg: at BG1NPC changelog, you will quickly notice that there was a shift from FILE_EXIT into GAME_IS in order to standardize code. I don't understand how you can claim that the only advantage of LABEL is being more reliable and that marker files can accomplish everything LABEL does. I have literally written the advantages in the first post. LABEL is so much more, you need to think outside of the weidu box to see it: Can marker files be used to create a curated mod list aka mod compilations? - No. Can marker files be used to create curated install order lists? - No. Can marker files be used to provide a reliable way to save user component selections for mod managers? - No. Does the logic behind marker files could be somehow 'extracted', logically interpret, and present to the user as 'mod dependencies or conflicts' before installation begins? - No. (it can definitely be done with upcoming tp3, it won't be possible with marker files logic) So let me give you an example of what globally unique LABEL can do. The mod compilations are transformed from this: Ascension:0:Rewritten Final Chapter of Throne of Bhaal` transitions:0:Main component: Allow continued play after Sarevok and/or Irenicus is defeated ... to this: (there are no more tp2 filenames and designated numbers!) Ascension-RewrittenFinalChapterOfToB ; Ascension - Rewritten Final Chapter of Throne of Bhaal #L-TRANSITIONS-MAIN ; Transitions - Allow continued play after Sarevok and/or Irenicus is defeated ... The users can finally reliably save mod choices like this: Ascension-RewrittenFinalChapterOfToB #L-TRANSITIONS-MAIN ... There is indeed some extra work and brainpower associated with adding LABEL and using it for internal and external mod dependencies. But let's assume for the moment that someone has to take look at your mod to see "how things are done" and coded several logic conditions by using marker files. Then he needs to create dependencies for mods which doesn't have marker files. So he learns how to use REQUIRE_COMPONENT, FORBBIT_COMPONENT with DESIGNATED numbers. The DESIGNATED numbers were changed, things break. Then he discovers usage of LABEL so he re-code external dependencies. Later, he wants to provide the above extra features for his mod. He needs to create and add LABEL to every component. But he could be done this in the first place and use LABELS for internal dependences. It would also teach him how to create dependencies for all external mods since they either use DESIGNATED or already have LABEL. This appears to me as more extra work than starting with LABEL's in the first place. Did I do my homework and invented something which doesn't use LABEL? Yep. It requires using external website/command-line tool to generate semi-random numbers like 01EY951MQSCCJB4RXSBE6MDE7D for every mod component. The only advantage of this version of global ID is that it's a no-brainier solution: you generate ID's, paste into tp2 and you are done. One problem, as you mentioned was the 'require to use extra website/tool'. The second problem was: it could only be used for the mod manager, without any kind of benefits for WeiDU. Having to choose between PI-only solution and LABEL, I chose something which can be used by both worlds. So I DO account for 'extra work'. I agree that the syntax of REQUIRE_PREDICATE MOD_IS_INSTALLED ID_OF_LABEL is awful. I wish that REQUIRE_COMPONENT, FORBBIT_COMPONENT could use LABEL or at least a variable. If you want to have simplified syntax, requests for WeiDU were created, add your vote to them.

@jastey Missed you reply, sorry. I'm always in favor of up-to-date documentation but I have to find a way to have a centralized PI guide without fear that it will be read once and forgotten. Editing posts won't work. What's the best way of notifying modders about updates with new features? There is a point in time when there won't be any new PI modders feature but until it happens, there will always be an 'extra rounds' with PI because I'm still adding features to it.

Introduction: The current way of handling mod dependences is relying on DESIGNATED numbers. Due to how DESIGNATED numbers are inseparably connected to the mod components structure and order, it's inevitable that sooner or later those numbers will be changed and all dependencies will have to be updated. And when they do, everything breaks. Instead of using REQUIRE_COMPONENT, FORBBIT_COMPONENT with DESIGNATED numbers, we will use mod LABEL with combination of MOD_IS_INSTALLED and ID_OF_LABEL as an improved way that won't rely on DESIGNATED numbers and it won't prevent modders from changing them. Please remember that it's not only about improving your mods, it's also about giving a good example for new modders. The common practice of new people is reading other mod's code to figure out how to do things instead of reading WeiDU documentation. Q: What is LABEL and why I should add LABEL's to my mods? A: LABEL is a better DESIGNATED. It allows assigning a unique textual identifier for a given mod component. And use this identifier to handle internal dependencies between the components of the same mod and external dependencies of the mods from different authors. By using globally unique LABEL's locally, you are saving yourself the trouble of fixing dependences after DESIGNATED changes. By using external mods LABEL's for defining dependencies, you avoid 'locking' DESIGNATED numbers changes of those mods so the author can freely change them when he needs to. Q: I would like to add LABEL's for all my mods so other modders can use it. How to create proper LABEL? A: Read this guide: What is LABEL, why you should create it and how to do it properly How it was handled before: mod provide DESIGNATED numbers assigned to it's components other mods and tools create dependences based on those numbers after a mod update, the DESIGNATED numbers had to be changed and with it, all mod dependencies need to be updated How it is handled now: mod provide globally unique LABEL's assigned to it's components other mods and tools create dependences based on those LABEL's even if DESIGNATED numbers will be changed due to the evolution of the mod, their LABEL's won't so all mod dependencies will still be correct Advantages: using the new way will allow for the dependences to no longer rely on DESIGNATED numbers and survive when they change avoid 'locking' of external mods DESIGNATED numbers changes, author will be able to freely change them when they need Prerequisites: the mod that we want to add dependencies must have LABEL's added to it's components Example: Let's consider a NPC mod that has 3 components: the component that add NPC with all it's content into the game the component that allows to change NPC portrait, this component requires main component to be installed the component that allow assigning a special kit from an external mod, this component requires an external mod main component to be installed NPC.tp2: BACKUP "weidu_external\backup\NPC" // move backup folder outside of the main mod data folder SUPPORT "forum.com/thread-1" VERSION "0.1.0" AUTO_EVAL_STRINGS BEGIN "NPC Main Component" LABEL "NPC-Main" DESIGNATED 1000 OUTER_SET ID-NPC-Main = ID_OF_LABEL "NPC.tp2" "NPC-Main" PRINT "ID of the NPC-Main LABEL: %ID-NPC-Main%" // Example of local dependency BEGIN "NPC Portrait Component" LABEL "NPC-Portrait" DESIGNATED 2000 REQUIRE_PREDICATE MOD_IS_INSTALLED "NPC.tp2" ( ID_OF_LABEL "NPC.tp2" "NPC-Main" ) "This component requires main component." OUTER_SET ID-NPC-Main = ID_OF_LABEL "NPC.tp2" "NPC-Main" PRINT "ID of the internal NPC-Main LABEL: %ID-NPC-Main%" OUTER_SET ID-NPC-Portrait = ID_OF_LABEL "NPC.tp2" "NPC-Portrait" PRINT "ID of the internal NPC-Main Portrait: %ID-NPC-Portrait%" // Example of external dependency BEGIN "NPC Kit Component" LABEL "NPC-Kit" DESIGNATED 3000 REQUIRE_PREDICATE MOD_IS_INSTALLED "Kit.tp2" ( ID_OF_LABEL "Kit.tp2" "Kit-Main" ) "This component requires the main component from the external Kit mod." OUTER_SET ID-Kit-Main = ID_OF_LABEL "Kit.tp2" "Kit-Main" PRINT "ID of the external Kit-Main LABEL from Kit mod: %ID-Kit-Main%" Kit.tp2 (for reference, must be installed before NPC.tp2): BACKUP "weidu_external\backup\Kit" // move backup folder outside of the main mod data folder, change only your mod data folder name SUPPORT "forum.com/thread-1" VERSION "0.1.0" AUTO_EVAL_STRINGS BEGIN "Kit Main Component" LABEL "Kit-Main" DESIGNATED 9999 OUTER_SET ID-Kit-Main = ID_OF_LABEL "Kit.tp2" "Kit-Main" PRINT "ID of the internal Kit-Main LABEL: %ID-Kit-Main%" Possible WeiDU improvements: remove the requirement of having '.tp2' for the ID_OF_LABEL tp2 name parameter (for now, you can use a local variable with full tp2 name) add a possibility to use ID_OF_LABEL for REQUIRE_COMPONENT and FORBBIT_COMPONENT so the syntax can be simplified

@Bartimaeus Thanks, I've added nice explanation what is LABEL and why someone should add it to his mods. And another explanation how to use it. Also clarification about how important this decision is from the mod ecosystem perspective.

tl;dr: Add "LabelType = GloballyUnique" line into mod metadata file thus indicating that the "label usage context is for Project Infinity". Then for each mod component add WeiDU LABEL keyword by combining modder prefix or author name, the mod display name (read warring!) and the component name. Then never even change it. You will help other modders, people who create so-called 'mod compilations' and players who do use mod managers. Introduction: Project Infinity feature status: Implemented You might wonder, what is LABEL? Why I should add LABEL's to my mods? LABEL is a better DESIGNATED. It allows assigning a unique textual identifier for a given mod component. And use this identifier to handle internal dependencies between the components of the same mod and external dependencies of the mods from different authors. By using globally unique LABEL's locally, you are saving yourself the trouble of fixing dependences after DESIGNATED changes. By using external mods LABEL's for defining dependencies, you avoid 'locking' DESIGNATED numbers changes of those mods so the author can freely change them when he needs to. Finally, those are extra advantages that mod ecosystem will get when LABEL's treated as globally unique instead of being bound to tp2 name: label can help you to properly handle mod component dependencies of the other mods, other modders could use labels from your mods the same way so-called mod compilations will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods installation order guides will not become obsolete after changing DESIGNATED numbers or even donating components to other mods mod conflicts list will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods players can safely keep the list of selected mod components and use it without this kind of nightmare The goal is to create LABEL that is globally unique across ALL existing and future mods. It's easy and straight forward when you keep a simple general rule: Modder'sPrefixOrAuthorName-ModDisplayName-ComponentName WARNING: It seems natural to use the so-called tp2 basename as part of the LABEL. Of course, you can do it, but you should be aware that the whole LABEL is locked and remains the same forever even if the component (its code) is moved to another tp2 file/different mod, no matter if it's your mod or someone else. You should absolutely leave it unchanged. This is a very important distinction that is not obvious at first glance. If a mod MyTweaks.tp2 contains a component with the label 'xx-MyTweaks-RemoveDragons' and later is donated to cdtweaks.tp2 mod/file, the LABEL STAYS THE SAME with modder prefix and tp2 name! How to enable: Step 1: Add the Add "LabelType = GloballyUnique" line into the mod metadata file, thus indicating that the "label usage context is for Project Infinity". Step 2: For each component of your mods, create labels according to the below requirements and best practices. Label requirements: no spaces no special characters, except the modder prefix no Unicode characters minimum 4 characters cannot be the digits-only, using digits-only (LABEL '100', '1000' etc) for LABELS in fact removes its advantages cannot be a combination of 'ID:DESIGNATED' as actual LABEL (LABEL 'MyMod:0' etc) cannot be ONLY tp2 basename, the main component of your mod could be easily constructed by adding '-Main' suffix Label best practices: kebab-case, snake_case, PascalCase it's best to start with the modder prefix: xx-MyMod-Main try to avoid using well-known shortcuts of the mods from the most significant to the least significant: "xx-MyMod-Portrait-Brath" / xx-MyMod-Portrait-Wallo" instead of "xx-MyMod-Wallo-Portrait" / "xx-MyMod-Brath-Portrait" avoid using the component category in the label name The component category (equivalent to the WeiDU GROUP feature) is a virtual concept and depends on individual preferences. After transferring components to a different mod or category, the label will have a mismatched and confusing name so it may mistakenly prompt people to change this part of the LABEL, but it should never be done. Example: BEGIN "MyMod" LABEL "MyMod-Main" Wrong label names: "a" - not enough characters "Spells" - too general name "Main" - too general name, add mod display name "MyMod" when tp2 is MyMod.tp2/Setup-MyMod.tp2, please add '-Main' suffix Proper label names: Labels of the main component of Ascension mod by DavidW: ////////////////////////////////////////////////////////////////////// // Ascension main component: rewritten Chapter 10 // ////////////////////////////////////////////////////////////////////// BEGIN @104001 DESIGNATED 0 GROUP @101000 LABEL Ascension-RewrittenFinalChapterOfToB Labels of the main component of Transitions by Lauriel: //////////////////////////////////////////////////////////////////////////////////// // MAIN COMPONENT FOR ALL GAMES: ALLOW CONTINUED PLAY AFTER DEFEAT OF BOSS ENEMY // // OPEN THE PALACE AND MODIFY DUKE BELT TO ALLOW FOR BG1 CONTINUATION // // OPEN SULDANESSELLAR AND MODIFY QUEEN ESSEMINE TO ALLOW FOR BG2 CONTINUATION // // HANDLES PC'S ROOM IN THE PALACE AND IMOEN'S TRAINING IN MAGIC IN EET // //////////////////////////////////////////////////////////////////////////////////// BEGIN @2 // MOD 0 LABEL "#L-TRANSITIONS-MAIN"

When I was writing a guide about "How to properly handle mod components dependencies" and "Best practices for LABEL's" one important thing got my attention: Do labels from all of my mods are 'reserved' just as filename prefixes? So already defined labels can't be used for other mods, even if they are inside different tp2? So they can be utilized as globally unique ID of the component? Q: What is LABEL and why I should add LABEL's to my mods? A: LABEL is a better DESIGNATED. It allows assigning a unique textual identifier for a given mod component. And use this identifier to handle internal dependencies between the components of the same mod and external dependencies of the mods from different authors. By using globally unique LABEL's locally, you are saving yourself the trouble of fixing dependences after DESIGNATED changes. By using external mods LABEL's for defining dependencies, you avoid 'locking' DESIGNATED numbers changes of those mods so the author can freely change them when he needs to. You can read about how to create LABEL here: What is LABEL, why you should create it and how to do it properly You can read about how to use it here: How to properly handle mod component dependencies Before I can move forward with the guides and with the next PI features, I would like to know the modders opinion about this matter. So let me demonstrate examples of already existing LABEL which are globally unique across all existing and future mods: Ascension-RewrittenFinalChapterOfToB Ascension-BalthazarCanBeRedeemed #L-TRANSITIONS-MAIN #L-TRANSITIONS-BG1_DREAM isra_npc_for_bg isra_valerie_crossmod_content Some thoughts: Ensuring that the labels LABEL's are globally unique across ALL existing mods can be achieved without searching across all tp2's. The longer the LABEL is, the higher chance to be globally unique. Best practices can influence and make sure that all LABEL's created by any modder will be globally unique across all existing mods. I have a list of best practices but let's leave it for another topic. LABEL's which were unknowingly created by modders are indeed globally unique across all existing mods. This was achieved without any form of community contract or a best practice guide. If the LABEL's of certain mod contains the unique tp2 name, the label is globally unique. It is hard to imagine a mod that would have "Ascension-*" as a part of its LABEL and not be a component of the Ascension mod. That doesn't mean that a mod can't have for eg: a#-MyMod-Double-Ascension-Creature-Level as LABEL. LABEL's which contain modder prefixes are automatically reserved only for modders who reserved a given prefix. I think that we can agree that modders prefixes could be used as the first part of the LABEL thus making all labels globally unique. It appears to me that, similar to modder prefixes, LABEL's should be utilized as globally unique and not as a combination of tp2 name and label itself. And they became globall ID of the component. This is it! It's the most important missing functionality in the mod ecosystem. To underline the enormous importance of this, let me mention that if the concept of globally unique ID had been present since the beginning of WeiDU component system, the BWS project would still be bustling with life and would not require 24/7, never-ending Sisyphus work. All the work could be spared to improve mods. All problems related to changing DESIGNATED numbers are solved by adding a LABEL to the components. Additionally, LABEL's utilized as globally unique (and not only within tp2 files) allow for additional features outside of what WeiDU can do. Right now, it doesn't matter that WeiDU currently cannot use it without providing tp2 name. It can be improved later at least to some degree. Mod managers can use full advantages of LABEL's being utilized as globally unique. Those are extra advantages that mod ecosystem will get when LABEL's will be utilized as globally unique instead of being bound to tp2 name: so-called mod compilations will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods installation order guides will not become obsolete after changing DESIGNATED numbers or even donating components to other mods mod conflicts list will not become obsolete after changing the DESIGNATED numbers or even donating components to other mods players can safely keep the list of selected components and use it without this kind of nightmare Everyone, please share your thoughts and opinions. @CamDawg @argent77 @subtledoctor @DavidW @jastey @Gwendolyne @Bartimaeus @Angel @kjeron @Luke @Magus @Lauriel

There should be only one link (google drive or github) so players won't be confused and you won't have to update both of them. With github, you are providing an ability to download you mod using commandline tools and a possible auto-updates for you mod in the future.

All older version of WeiDU are packaged using UPX (cause of error) so they won't work on Big Sur (they would have to be recompiled/repacked).

@Noobie While the component is present inside mod code and readme itself, the readme located here: https://gibberlings3.github.io/Documentation/readmes/readme-cdtweaks.html dosen't mention about it. It's because this tweak was added after version 9 was released. PI is following modder wish to only download mod releases, not the 'latest bits of code'. In order to get this component, you can manually download the 'latest bits of code' of TA here: https://github.com/Gibberlings3/Tweaks-Anthology/archive/master.zip and replace TA directory with it.

It looks to good to be true. It turns out that using out_path which is essential for overcoming HANDLE_CHARSETS quirks is incompatible with AUTO_TRA: I will investigate more, right now you can't use this if you are not wiling to resign from using AUTO_TRA function.

@Mike1072 How about you? Wanna accept PR?

@jastey How about PR with full set of changes and also updated Polish translation? Will you be able to merge and create release?

@TotoR @Angel 1. Classic BG2: I'm getting error when I'm trying to install ALL mod components: ERROR locating resource for 'COPY' Resource [divine_remix/spheres/lua#ooze.2da] not found in KEY file: [./chitin.key] ERROR Installing [Implement sphere system], rolling back to previous state WARNING: Unable to uninstall STRING_SET references from [divine_remix/backup/1000/UNSETSTR.1000]: Invalid_argument("index out of bounds") Will uninstall 7366 files for [DIVINE_REMIX/DIVINE_REMIX.TP2] component 1000. ERROR: error copying [divine_remix/backup/1000/spellbook_CLABPR02_1_0.2da] 2. Classic BG2: When I'm trying to install only component 1000 "Implement sphere system" I'm getting different error: Copying and patching 1 file ... ERROR locating resource for 'COPY' Resource [divine_remix/spheres/ludr0.2da] not found in KEY file: [./chitin.key] Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. ERROR Installing [Implement sphere system], rolling back to previous state Will uninstall 4517 files for [DIVINE_REMIX/DIVINE_REMIX.TP2] component 1000. Uninstalled 4517 files for [DIVINE_REMIX/DIVINE_REMIX.TP2] component 1000. ERROR: Failure("resource [divine_remix/spheres/ludr0.2da] not found for 'COPY'") Please make a backup of the file: SETUP-DIVINE_REMIX.DEBUG and look for support at: http://gibberlings3.net/forums/index.php?showforum=29 Automatically Skipping [Implement sphere system] because of error. Reverting those two lines fix the problem. Are you sure about those changes?

@Magus When you have 20 mods, re-downloading them is fine. If you have 300+ and among them are such monstrous as RoT, delta updates are very handy.