AL|EN

@jastey Above install order dependency could indeed introduce troubles (infinite loop etc) - right now it's best to use all involved tp2 names until the solution for such setup can be well-thought. Regarding two mods with excluding rules: one of the rules would have to be disabled in order to continue installation. Later, I'm hoping that two modders can collaborate to resolve such impossible-to-fulfill rule. If the mod A has cross-content with mod B + mod B has cross-content with mod A, at the same time both which needs to be installed after each other, then there is no correct install order so it can't be solved via install order rules. Either changes are needed for both mods or the 3-rd 'component C' is required with rules regarding install order of "AFTER = A,B" and also regarding requirements of mod A + mod B being installed.

@jastey Sorry for late reply, I'm on vacation right now. Sure, you can tell him that you, as a modder find it userful and you need it, this might turn the tides. I hope for the best.

@subtledoctor Big thanks for recent mod updates, especially filling install order rules. It looks like this: I'm nitpicking but could you alter Faiths_and_Powers_Multiclass.ini 'Name=Faiths and Powers' into 'Name=Faiths and Powers Multiclass' so PI won't display two identical 'mods'? It's just cosmetic thing, tho. BTW: I saw that you 'Download' link contains '/releases' - it doesn't need to be added for mod updates from release but right now, it doesn't matter

@lefreutCurrently no, but I have something prepared. My hope is that it would be something more than 'ModA has conflict with ModB'-thing while giving the same outcome to the player. Stay tuned.

@jasteyYes, I did, he is aware about it. We can talk about implementation details but first there must be a will to do so.

@jastey Basically, it's a copy of LABEL with different name and without any duplication validations. I've explained it here. It can be implemented (it's basically a copy of LABEL with less code) but for that you have to ask wisp.

The BEFORE/AFTER is implemented, REQUIRE will follow next. Nothing has been changer in terms of providing install order for single components - the only workaround would be to to this 'sync' thing which might fail. I'm afraid that without weidu support, I cannot be done nicely. You have valid concerns, mistake can be made. I'm hoping that if such mistake will be spotted (which will be much easier that reading the readme), modder will be notified and it will be collaboration in order to mitigate the problem. Im also looking at the limited scope: when someone install 5 mods for eg: Ascension + SCS + NPC, the Ascension/SCS can provide install order for all mods which are currently on 'compatibility list' and it would represent 'best possible' install order for this limited scope of 5 mods. Isn't all of this worth it? Anyway, thanks for contribution.

@subtledoctorIf you are interpret the "AFTER = x, y, z" as "the other mods that go after this one are: x, y, and z" it's wrong. By definition, you mod can't provide or modify the install order of other mods. That is why the install order relationship are created by using you mod as starting point in relation to other mods, not other way around. The 'FORMER(EARLIER)' and 'LATER' keywords are used for 'REQUIRE ' statement although I think than 'EARLIER' sounds better than 'FORMER'. @DavidW If you have concerns about the reliability of the solution, please report them. I don't see any iceberg on the horizon which might sink the whole fleet of ships but you never know. I'm aware about the problem of 'install order groups/sections' being similar to mod 'categories'. Those names came from my limited knowledge about 'general rules of install order'. The 'AI' was named mainly for SCS because many other mods have relationship with it. I like the idea of having 'dynamically-responsive' install order group which in fact is a very nice replacement for the 'AI'. Regarding expanding it with more tags/groups (I will stick to 'groups' terminology for now), I think that I see the idea it but I need more info: - the relationship of 'add_kit' and 'responsive_to_kits' must be hard-coded and unchangeable by players, right? - do you assume that the mod can provide more that one 'install order group/tag'? - more pairs: 'add_npc' + 'responsive_to_npc', 'add_items' + 'responsive_to_items', 'add_spells' + 'responsive_to_spells', what about other ones? - do you have idea how to name 'before-dynamically-responsive' and 'after-dynamically-responsive' ? Agree on the 'UI-Patching', I will also rename UI-Overwrite into more general one: Overwrite.

PI doesn't yet use it yet, don't worry about updating the labels for now. I hope that if there won't be objections regarding making labels globally unique, I can use them for saving components/install order/etc. You are correct about the context usage by using weidu functions, but at the same time, PI can use them for much more. After you update labels across two or more involved mods, the only thing which would still work would be MOD_IS_INSTALLED/ID_OF_LABEL. Everything else will stops working: players private saved mod/component list players private sorting order lists public 'install order lists' public mod compilations It is exactly the same situation which would occur if you would change DESIGNATED and update the number across other mods. So if the modder is willing to use the labels in order to mitigate DESIGNATED problems, at the same time creating those labels as globally unique and unchangeable will protects all the rest. Yes, even you simplified version will be unique. Also yes - if the original author of the component code will include the prefix, it can tell people who to thanks even if the component will be transferred/donated into other tp2's.

Well, congratulations on being the first person who will use those features! Being young obliges There is no yet defined list of 'types', I was thinking about standard ones like Fixes, Quests, NPC, Items, Spells, Kits, Tweaks, AI, Sounds, Portraits. Two addition would be "UI-Override" and "UI-Patch" since how UI mods are created and applied. But modders can establish more if there will be need for it. I don't like the 'Misc' - it's too general. If the component doesn't fit into any of the standard type, it's better to ask community then blindly set type. The main purpose of the component determines it's type. Dependencies already listed in the TP2 file cannot be read and used outside of the weidu. Yet, cloning them inside ini will make them "out of sync" after tp2 update so it's a dead end.

@LaurielYou label is fine as long as you understand that even if the label contains 'TRANSITIONS' which match tp2 name of you mod, it has to stay the same after theoretical transfer into different tp2 (you mod or someone else). You might also suggest for a better term.

Yes! This is it. The last point ensure that player saved mod list/ mod compilations won't break. Now I see that using tp2 name might bring confusion. I'm using it because it also represents the name of the 'orgin mod' which contains code/component. Does anyone have suggestion how to better represent this part? Like 'display name of the mod without spaces/special characters' ? BTW: You can add labels into you mod and don't use them - it would still be a benefit for other mods(they can use ID_OF_LABEL) and PI.

No. Even if could be read, it can't be bound with specific component.

The only valid alternative for using prefix as part of the labels is adding 'special magic sting' at the end of the label itself: LABEL "CD_TWEAKS_REMOVE_HELMET_ANIMATIONS_01AN4Z07BYMQJ" or using second label with only 'special magic sting' LABEL "01AN4Z07BYMQJ" The advantage is that it's a no-brain operation: you generate 1000 of them, putting into every component and you don't have to worry about anything as long as you don't change it for already established code/component or use for another code/component. It 100% globally unique and at the same time, PI can validate/detect it. The downside is that it looks ugly. And 'special magic sting' needs to be generated outside of weidu...

But using tp2 as part of the ID is fine until one modder decide to transfer/donate his components into another mod tp2. Knowing that and being a witness of broken players saved mod lists/mod compilations etc I can't turn my eyes away. How do you feel about the requirement of globally unique labels (which can be achieved unconsciously during their creation) vs the potential benefits?

@DavidWCamDawg come with the idea of having modders prefix as part of the LABEL so they can be unique globally. It would be very helpful because the usage context of the LABEL in PI is free from weidu limitation - labels are not bound to tp2. It's like solving two problems at once by using well established and accepted 'modders best practices'. So I support this idea. Even without modder prefixes, current usage of the LABEL across multiple mods and authors indicate that they are globally unique so I don't see any reason why they shouldn't be treat that way. There is no documentation yet because I don't know yet what are opinion about this. But for sure, crafting labels with modder prefix is the best way to go.

Hi, Sorry for late reply, I'm out of the loop. I've tested this and cannot reproduce the issue: EET:0:EET core (resource importation) DeitiesOfFaerun:0:Base Cleric Changes (required for all components) DeitiesOfFaerun:2:Spheres System (by Kjeron) DeitiesOfFaerun:6:Install kit: Nightcloak of Shar DeitiesOfFaerun:64:Viconia, the Nightcloak of Shar installing those mods in this order doesn't produce any error: ProjectInfinity-Weidu-Debug-DeitiesOfFaerun-2.log

Hi @DavidW It won't. Bypassing translation system won't help as there is nothing wrong with it or with translation itself. You can quickly verify this by looking at the mod files directly: here and here. Since the report indicate that the problem exist in other translations as well, this might be problem with Ascension mod code, another mod interfering or installation procedure problem.

Well, according to bug reports for "Tower of Deception - Warblade of Twilight" sword, this effect never worked. I have experiment with opcode#188 and the only effect which I as able to get was "remove delay between casting spells" aka permanent Improved Alacrity. If you have any examples how to achieve working "set specific number of spells per round" please share but I don't see how this opcode could do this if the only valid parameter has disable/enable switch.

Well, it seems for me that the effect has one and only one purpose: remove delay between casting spells. So the description should reflect that. Also, the 'how to enable' section should be much more clear: 0 to disable, 1 to enable, without all of this confusing 'any non-zero to enable ...' intricacies of the engine.

@Lightbringer Good to hear that it's working. Thanks! I agree that having constant "Improved Alacrity" is way too much for an sword which can be used by Fighter-Mages, which are already overpowered anyway. But I'm not going into the 'mine field' of balancing items If you have any other contribution, feel free to share/send them into https://github.com/InfinityMods/TowerOfDeception (former BigWordProject repo) @Mike1072 We have hijacked thread, can you split: https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=281648 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282076 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282079 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282138 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282142 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282162 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282167 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282183 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282200 https://www.gibberlings3.net/forums/topic/27741-mod-compatibility-list-for-eet/?do=findComment&comment=282218 into a new topic "Tower of Deception - Warblade of Twilight"?

Yes. If you would like to send multiple changes that don't include previously commited changes (commit 1 - only fix for item1, commit 2 - only fix for item2, without item1 changes) then some amount of git/github trickery with branches would be needed. But you did good job with single commits.

@Lightbringer I think that I might fixed the spell stuff of the item: - reset "Unused" value of 2 to 0 because according to opcode 188 description "Parameter #1: Irrelevant" - set "Cleanse auta" to Yes/1 as per Near Infinity calls it. - set "Dispel/Resistance" to "Not dispel/Bypass resistance" - I get inspiration from the Robe of Vecna Item effect works as indeed: no waiting time between casting spells. The effect doesn't 'allows the wielder to cast 2 spells in one round" so the description of the item is very confusing. But atleast it is fixed somehow, can you try and confirm? va#calan.itm

Hey, this is attempt to clarify some things related to https://gibberlings3.github.io/iesdp/opcodes/bgee.htm#op188 Current description: #188 (0xBC) Spell Effect: Aura Cleansing Variants: PST Parameter #1: Irrelevant Parameter #2: Stat Value Description: Set the 'Stat Value' field to any non-zero value if you want no time needed between spells. Old update by aVENGER: https://www.gibberlings3.net/forums/topic/22847-bg2tob-a-few-opcode-description-updates Parameter #2: Constant Description: Set the 'Constant' field to 1 if you want no time needed between spells. Near Infinity description: My own testing observation: - set "Cleanse auta" to Yes/1 works as indeed: no waiting time between casting spells - in addition, I've set "Dispel/Resistance" to "Not dispel/Bypass resistance" for item It's the first time I'm dealing with this and it is confusing. I thing that opcode description need to be updated. What to you think?

@Lightbringer abg1 is long gone, I will take care about updating mod repository and also preform some cleanups. Thanks! The bug with casting time will require some investigation: @argent77 I might be wrong but does those values should be the same?