AL|EN

@jastey By the way how you describe it, it's not a 'conflict' - it's just a two install order rules which can't be fulfill at once so the player would have to choose which mod comes first but he is still able to install both mods and get some content from both mods. So regarding 'separate mod C' - sort off, for eg ModC-CrossContentForNPC.tp2 under the assumption that it has "AFTER = A,B" rule (I will skip example with components because of limitation): A.tp2-NPC Alia B.tp2-NPC Bob C.tp2-CrossContentForNPC Then, the install order of A and B doesn't matter so the mod C is installe

@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 insta

@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: Asce

@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 i

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

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

@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/det