Jump to content

Dynamic Install Order - providing enforced install order rules for you mods


AL|EN

Recommended Posts

Posted
3 minutes ago, Endarire said:

What about a section for recommended befores and afters, but not required?

I'd like that. But that depends on whether @AL|EN (sorry man I know you are busy elsewhere currently) could integrate such categories and what the players' possibilties are to ignore the given install order in case of conflict for the exsitent categories.

Posted

@jastey Coming back to this, I need you to provide examples of rules for "Ascalons Breagar" but for each component of the mod. It doesn't have to be full list (or even the list which you finally put into the mod itself), I just need valid example for mod which require defining the specific rules for specific components.

Posted

@AL|EN example for ACBre:

Component 0 ~Breagar: Contents~:

Quote

Type: NPC

BEFORE: cdtweaks, c#brandock, c#brage, c#grey, EET_end, Tweak

AFTER: EET, imoen_forever, Tweak_early

Component 2 ~Breagar: Crossmods and PID~:

Quote

Type: Crossmod

AFTER: ACBre:0, NPC

Component 10 ~Change Breagar's dialog timer? (Default is 30 minutes between dialogues.)~:

Quote

Type: NPC

AFTER: ACBre:0

 

Posted (edited)

@jastey Thanks, let me see what I can do.

Since you used 'ACBre:0' as reference, I must clarify: You cannot set those rules as DESIGNATED-based for oblivious reasons. Specification doesn't mention about it anywhere.

Edited by AL|EN
Posted
5 minutes ago, AL|EN said:

Since you used 'ACBre:0' as reference, I must clarify: You cannot set those rules as DESIGNATED-based for oblivious reasons. Specification doesn't mention about it anywhere.

You mean this is not possible for the dynamic install order syntax?

What would be the best way to give syntax for the components, then. Repeat the overall rules or just leave them out completely?

What I mean, would this make more sense:

Component 2 ~Breagar: Crossmods and PID~:

Quote

Type: Crossmod

BEFORE: cdtweaks, EET_end, Tweak

AFTER: EET, imoen_forever, NPC, Tweak_early

Component 10 ~Change Breagar's dialog timer? (Default is 30 minutes between dialogues.)~:

Quote

Type: NPC

BEFORE: cdtweaks, EET_end, Tweak

AFTER: EET, imoen_forever, Tweak_early

Posted (edited)

@jastey

15 minutes ago, jastey said:

You mean this is not possible for the dynamic install order syntax?

What would be the best way to give syntax for the components, then. Repeat the overall rules or just leave them out completely?

I'm working on the way for mods to be able to set rules inside a component using METADATA keyword. But it doesn't mean that those rules can directly target other components (even from the same mod) using DESIGNATED numbers.

Note that I could allow for using LABEL as reference but only under the condition that all labels from all mods are globally unique. I don't want to make any promises since this isn't set in stone yet.

 

15 minutes ago, jastey said:

What I mean, would this make more sense: 

Component 2 ~Breagar: Crossmods and PID~:


Type: Crossmod

BEFORE: cdtweaks, EET_end, Tweak

AFTER: EET, imoen_forever, NPC, Tweak_early

Component 10 ~Change Breagar's dialog timer? (Default is 30 minutes between dialogues.)~:


Type: NPC

BEFORE: cdtweaks, EET_end, Tweak

AFTER: EET, imoen_forever, Tweak_early

Yes, that will do.

Edited by AL|EN
Posted
13 minutes ago, AL|EN said:

Note that I could allow for using LABEL as reference but only under the condition that all labels from all mods are globally unique. I don't want to make any promises since this isn't set in stone yet.

Aren't LABELs globally unique? The whole LABEL thing if used instead of DESIGNATED numbers would be useless if they wouldn't be.

Will PI still list the components of one mod in the correct order? If the "component wise install order syntax" leads to optional components accepted before main components then it doesn't make much sense.

Posted
49 minutes ago, jastey said:

Aren't LABELs globally unique? The whole LABEL thing if used instead of DESIGNATED numbers would be useless if they wouldn't be.

Docs don't mention about it and weidu usage context allows and even encourages (because of the syntax) them to be not globally unique. I believe that we need strong commitment from modders community that LABEL's should be treated as modders prefixes.

49 minutes ago, jastey said:

Will PI still list the components of one mod in the correct order? If the "component wise install order syntax" leads to optional components accepted before main components then it doesn't make much sense.

That's valid concern.

Let me ensure you that there are no danger because even if somehow player would shift ACBre components into incorrect order, the rules from weidu's REQUIRE_COMPONENT/FORBBIT_COMPONENT/MOD_IS_INSTALLED won't allow for incorrect installation.

I should not be surprised that such system of dynamic install rules could be also use in order to set internal dependences for the components of the same mod. I see potential benefit where incorrect install order for internal mod components can be detected, present to player and avoid facing the 'ModA:2 require ModA:1' during installation. Even if there is double work involved and small chance of possible de-synchronization (but much smaller if rules are set in ini).

As of today, WeiDU's REQUIRE_COMPONENT/FORBBIT_COMPONENT/MOD_IS_INSTALLED are used in order to ensure correct order not only for installation but also for re-installation.

Ideally, PI would read those and add extra rules for internal components of the mod. But I cannot do this unless 1) I would recreate weidu parser. 2) weidu would introduce tp3 as a replacement for tp2 (this is one of things on weidu roadmap).

Right now, let's wait and see how it things go with globally unique LABEL's and if everything will be agreed, I could offer using LABEL's for rules which would handle the case of setting rules for internal mod components.

Posted

@jastey

I need some more info:

Do you know any of NPC mod needs to be installed AFTER "ACBre: Component 0 ~Breagar: Contents~" and BEFORE "ACBre: Component 2 ~Breagar: Crossmods and PID~:" (assuming someone is doing manual install when he quits and re-run installer)

 

Posted
23 minutes ago, AL|EN said:

Do you know any of NPC mod needs to be installed AFTER "ACBre: Component 0 ~Breagar: Contents~" and BEFORE "ACBre: Component 2 ~Breagar: Crossmods and PID~:" (assuming someone is doing manual install when he quits and re-run installer)

I put "NPC" in there as a condition for the Crossmod and PID component which would mean it would need to be installed after any NPC mods. Do you want it more specific?

On 10/14/2020 at 11:49 AM, AL|EN said:

weidu usage context allows and even encourages (because of the syntax) them to be not globally unique.

Right, my bad. I always understood they'd have to be globally unique but I see that from the syntax of tp2 name+LABEL they do not have to be.

Posted (edited)

@jastey I believe that I get the specific mod names from tp2:

DSotSC
Amber
Auren
ToBR
BGQE
ToD
AsQ

The question still remains: does any of those mods needs to be installed AFTER "ACBre: Component 0 ~Breagar: Contents~" and BEFORE "ACBre: Component 2 ~Breagar: Crossmods and PID~"? So the "Ascalons Breagar" mod would need to be installed using two-phases?

Like this:

ACBre:0:Breagar: Inhalte
amber:0:Amber the NPC MOD
ACBre:2:Breagar: Crossmods und PID

?

Edited by AL|EN
Posted

Short answer is no. Since the crossmod for these mods is inside the Breagar component ("2"), the mods would need to be installed before the Crossmod and PID component. But the main Breagar component would not necessarily need to be installed before the mods.

It might seem that simply putting the whole Breagar mod after these mods would have sufficed to solve this conflict. The component-wise install order gets interesting the moment there are three mods that need to be installed before/after in a way that simply putting one after the other in total wouldn't suffice as an install order.

Posted

@jastey Alright, there is nothing to worry about for now.

BTW: I've made mistake when I wrote "Yes, that will do" - until the 'mod types' will be implemented, you can keep 'NPC', 'tweaks_early' etc but you have to add all NPC explicitly. The 'mod types'  will require some more brainstorming and changes to PI.

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...