Jump to content

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


AL|EN

Recommended Posts

By dynamic I mean that if someone will install 5 mods, only rules from those 5 mods will be loaded (and from already installed mods). The maintenance is the same as covering additional install rule for newly released mod inside readme, you simply add it's tp2.

Link to comment

 Additional ideas how to improve this solution:

1. Mod can link to the online install order list:

InstallOrderList = https://github.com/subtledoctor/MacOS_Weidu_Launcher/blob/master/Mac_Weidu_Launcher_v7.app/Contents/Resources/mod_order.txt

@subtledoctor How about that?

 2. Mod types (originally suggested by @Angel )

- every mod will set their 'type' like NPC, Kit, Spells, Tweaks, UI

ModType = Kits

- then a mod can declare BEFORE/AFTER as:

Before = Kits, MyMod

After = NPC, OtherNPCMod

- in future, when the new Kit or NPC mod will be created, the author would simply need to declare his mod as one of the type so the rules from other mods will account for it

Hey @CamDawg, @argent77 @jastey, @DavidW, @Gwendolyne, @Grammarsalad you have lot of mods which dependencies, please share you feedback, especially if you feel that it's not going to work.

Edited by AL|EN
Link to comment
On 3/20/2020 at 10:56 AM, AL|EN said:

Mod types (originally suggested by @Angel )

- every mod will set their 'type' like NPC, Kit, Spells, Tweaks, UI


ModType = Kits

- then a mod can declare BEFORE/AFTER as:


Before = Kits, MyMod

After = NPC, OtherNPCMod

- in future, when the new Kit or NPC mod will be created, the author would simply need to declare his mod as one of the type so the rules from other mods will account for it

This sounds very cool.

I also have install order info of the kind:

Mod A should be before/after any mods of type "xyz" BUT is also of type xyz (example: Grey the Dog should be last NPC mod if possible and is NPC mod itself) - would this be covered?

-Would the rule apply to the whole mod even if it consists of optional components or could single components be tagged, too? In bgqe there is only one component which needs to be installed before bg1npc. If the player doesn't even want to install it there would be no reason to insist on the other components being installed before.

-Would the player be able to actively ignore the rules in case that's the only way for three mods to work together? For example, conflict between bgqe and bg1npc in the mentioned component is that one quest path will be inaccessible. But maybe the player knows the risk and decides that he needs to install bgqe after bg1npc because of some other install order conflict (just an example) and wants to solve the quest with the remaining path anyway.

Or, in case there are two NPC mods that require to be installed "last", the player could chose one if the reason for this rule is stated clearly. For example: Grey should be installed last as NPC mod or he will not react to some encounters properly (by sniffing monsters out for example). But it's not a mod-breaking incompatibility, more a suggestion.

Which raises the question - would it make sense to be able to tagg this as "has to" install orders and "should be/recommended" install order info? Meaning the player could skip the latter but not the former.

Link to comment
8 minutes ago, jastey said:

 

-Would the rule apply to the whole mod even if it consists of optional components or could single components be tagged, too? In bgqe there is only one component which needs to be installed before bg1npc. If the player doesn't even want to install it there would be no reason to insist on the other components being installed before.

This is something I am working on for my own install order. Occasionally with a large number of mods you end up with a situation where differnt people advise that a mod must be installed both before and after another mod, and breaking out the components to understand the real compatibility issues is the only way.

11 minutes ago, jastey said:

Would the player be able to actively ignore the rules in case that's the only way for three mods to work together? For example, conflict between bgqe and bg1npc in the mentioned component is that one quest path will be inaccessible. But maybe the player knows the risk and decides that he needs to install bgqe after bg1npc because of some other install order conflict (just an example) and wants to solve the quest with the remaining path anyway.

Perhaps have a way to distinguish between a mod that is in direct conflict with your (edits the same resources differently, breakd functionality etc.) and one that may just result in a suboptimal play experience or missing story content. that would let the player choose.

Link to comment

In the end, it would depend on how much effort the modder would spend to tagg the mod and its components. If a modder says that it's sufficient to have one category tagg and one install order tagg for the whole mod then that's their decision. But it would be great to be able to tagg components separately if wanted.

So my contribution to this dicsussion would be:

-have a tagg for the whole mod

-be able to tagg components additionally, where the componant tagg overwrites the mod tagg

-have two categories of install order taggs: absolutely essential or the game will break technically and really really good idea to do it like this or you'll miss out on contents or have other content issues - OR give the player the possibility to ignore warnings after reading the explanations for the install oder (assuming it's available)

-be able to give a short explanation for the listed install order so the reason is clear (might also help for maintainers later to understand whether the order is still necessary and/or whether it can be fixed with cool new weidu functions or the likes.)

 

Link to comment
7 hours ago, Blash2 said:

It would be nice to have an online install order where single modders propose changes, and those changes have to be approved by other mod authors, so a discussion may arise in not very clear situations. Something like pull requests on GitHub.

There is a dedicated thread for discussion about this.

@jastey

- Optional descriptions/explanations for the rules won't be a problem.

- The edge case of "Grey the Dog should be last NPC and it's also NPC" can be covered when I will implement "BEFORE/AFTER ALL".

9 hours ago, jastey said:

-have two categories of install order rules: absolutely essential or the game will break technically and really really good idea to do it like this or you'll miss out on contents or have other content issues - OR give the player the possibility to ignore warnings after reading the explanations for the install oder (assuming it's available)

I don't like the idea of two separate rule weight/importance because there is no harm when the install order rules are enforced even for simple extra content/minor things. I believe that such disquisition would introduce confusion.

I would like to keep all mod rules as 'forced', because I want to assure modders that their effort of determining install order won't be wasted.

But it is inevitable that eventually, two or more mods will have mutually exclusive rules. Especially when I include 'mod conflicts' in the future. An they must have the ability to be ignored by the 'power gamers' who know what they are doing. If that will happen, weidu.log will reflect this fact so debugging install order problems can be handled.

So this is my proposition would be: for the current phase with a little amount of rules I will keep rules as forced until the first unsolvable case and then handle the ability to ignore rules.

How does it look for you?

9 hours ago, jastey said:

-be able to set rules for single components additionally, where the component rules overwrites the mod rules

First of all, there is no way to read rules data from tp2 (but it is the best place to store them, pitty).

So it would have to be defined inside .ini. Can be technically done but it exposes you to the risk of mistakes due to lack of synchronization with the content of tp2. In your own words, people tend to forget about things. It would require some degree of duplicated work: if you want to have different rules for specific components, each of it would have to be included inside modname.ini and you would need to keep things synchronized between ini and tp2.

The only way how to significantly reduce de-synchronization of the tp2 and ini is to use LABEL as component reference. Using DESIGNATED numbers for this is no-go, it would generate more problems than it's worth it.

Thinking about this makes me afraid that implementing such feature in sane, easy to maintain and error-prone way would require something which I can only describe as next generation of tp2 mod definition file ...  like tp4.

Edited by AL|EN
Link to comment
19 hours ago, AL|EN said:

for the current phase with a little amount of rules I will keep rules as forced until the first unsolvable case and then handle the ability to ignore rules.

Sounds reasonable!

19 hours ago, AL|EN said:

Can be technically done but it exposes you to the risk of mistakes due to lack of synchronization with the content of tp2. In your own words, people tend to forget about things. It would require some degree of duplicated work: if you want to have different rules for specific components, each of it would have to be included inside modname.ini and you would need to keep things synchronized between ini and tp2

Hm, that's true. Maybe for a start, would it make sense to make it available to modders like a feature they can use until a better way is found or would you prefer to prevent "messy" solutions from the start? I don't think I would start this for bgqe but just define it should be installed before bg1npc as a whole, but there might be mods where the components really ought to be installed at different positions. Oh - a good example is Ascalon's Breagar: it has a Crossmod Component which should be installed as late as possible, but there might be other mods adding crossmod with Breagar that need to be installed AFTER Breagar.

Another example was mods with components that qualify for different mod categories. How would you treat those?

19 hours ago, AL|EN said:

- Optional descriptions/explanations for the rules won't be a problem.

- The edge case of "Grey the Dog should be last NPC and it's also NPC" can be covered when I will implement "BEFORE/AFTER ALL".

Cool!

Is there a list with mod categories already? I just figured a category "CROSSMOD" might make sense, too.

Link to comment

@jastey

I think that using term 'categories' when it comes to install order is a bit misleading, after all categories can be anything like 'mods with dragons'. That's why I prefer 'install order groups/sections'. 

I would like to prevent "messy" solutions mainly because I don't want to start with some unnecessary limitations and doing workarounds for them. Mods with components for different install order groups will be handled later when modders request such additional feature.

Regarding 'CROSSMOD': there are mods especially created for this purpose  so it can be added, I assume that you idea is that it would be after NPC, right?

Link to comment
1 hour ago, AL|EN said:

That's why I prefer 'install order groups/sections'

I prefer that too.

1 hour ago, AL|EN said:

Regarding 'CROSSMOD': there are mods especially created for this purpose  so it can be added, I assume that you idea is that it would be after NPC, right?

After Quest and NPCs would be my guess, yes (since Quest is before NPC that's a yes to your question). Or would there be a case of crossmod for non-quest non-npc mods? 🤔

1 hour ago, AL|EN said:

Mods with components for different install order groups will be handled later when modders request such additional feature.

Breagar put all the crossmod stuff into an extra component especially to be able to install it later and not make the main component dependent on it.

We could

1. put the whole Breagar mod into an install order that works for the crossmod component, too - might not work for all mods

2- make more work for me by making the crossmod an own mod/moving it to Crossmod Banter Pack - there are plenty of other mods that have crossmod stuff, too

3- make more work for you and insist you add component-wise install order categories - might not be supported by all modders so the work was for nothing

We can see how far we get with option 1. Still, the idea of the separate component for crossmod stuff is a bit mute if mods have to be put into one install order slot for all components, is all I was trying to say.

 

Link to comment

@jastey That's very valid point, I don't want to discourage mods to split their components. If only there was a way to put extra component keyword into tp2...

@Wisp Any chances for adding new component keywords into weidu itself, which I requested 3 years ago? Or this is out of the questions and I should look for for workarounds?

Link to comment

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...