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

[jastey]

4 hours ago, DavidW said:

My main concern about reliability is that I don't really trust people to reliably work out the preferred install order for mods, including their own mods, so I'm unconvinced this will converge on truth rather than ending up messy or self-contradictory. But I'll be happy to be proved wrong.

I see this more for the things where the modders *know* about dependencies. I am thinking about included crossmod content (which only works if the mod is installed after the one it has crossmod for), known dependencies, known incompatibilities depending on install order etc. Almost all of my mods have some such and I would appreciate a possibility to be able to specify the ones I know about. The reason for the idea of putting this into the mods themselves was the knowledge that an overall mod order list will not work because noone will contribute to it (in the long run).

But yes, of course there could be cases where modders tagg their mod wrongly and PI might take the blame. But would this be a reason not to integrate something like this? It's a good question.

[AL|EN]

On 9/5/2020 at 10:49 AM, jastey said:

Is this already ready for implementation? I thought we got stuck in discussion about features. Is the problem about tagging mod components differently solved? Because I'd definitely need that.

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. 

5 hours ago, DavidW said:

No more info to offer, sorry. Those were my offhand thoughts on the subject, not the abstract to a well-worked-out thesis.

My main concern about reliability is that I don't really trust people to reliably work out the preferred install order for mods, including their own mods, so I'm unconvinced this will converge on truth rather than ending up messy or self-contradictory. But I'll be happy to be proved wrong.

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.

[jastey]

On 9/7/2020 at 9:28 AM, AL|EN said:

the only workaround would be to to this 'sync' thing which might fail.

What would that be? Is giving this weidu support an option? As much as I would like to support this, I have several mods where global install orders for the whole mod really doesn't make sense.

[AL|EN]

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

[jastey]

@AL|EN did you ask @Wisp for a feature request? I wouldn't mind posting one but I still don't exactly get what exactly is needed here.

[AL|EN]

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

[lefreut]

Is there a way to specify mutually exclusive mods? My UI mods come in different skin flavor. If you choose to install one (LeUI for example), you should not install LeUI-BG1EE or LeUI-SoD or any other UI overwrite mod.

[AL|EN]

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

[jastey]

On 9/8/2020 at 5:12 PM, AL|EN said:

but first there must be a will to do so

The will of who? Do you want me to weigh in to persuade @Wisp this is worth the trouble?

[jastey]

On 9/12/2020 at 7:14 PM, jastey said:

The will of who? Do you want me to weigh in to persuade @Wisp this is worth the trouble?

@AL|EN

[AL|EN]

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

[jastey]

Thanks! Have a nice holiday!

EDIT: Look here: https://forums.pocketplane.net/index.php?topic=29951.0

[jastey]

On 9/4/2020 at 8:31 PM, Lauriel said:

@AL|EN, so is something like this about right?

 

Sorry - spose I should give a link to something describing my mod:

 

@Lauriel

This comes a bit late, but Transitions needs to be installed before NPC mods, maybe even quest mods. It's not what the community calls a "tweak". Tweaks are mods that should be installed very late, so they can apply general changes to mod added contents, as well. Transitions and also Endless BG1, as well as Imoen4Ever need to be installed early. I think we'd need a new category for that?

[Lauriel]

2 minutes ago, jastey said:

I think we'd need a new category for that?

I agree - what should we call them?  Story changers?  LOL  Would anyone even understand what that is?  It's late here so ideas aren't flowing...but I'll sleep on it.   Right now, my ini looks like:

Type = Tweaks
Before = NPC, bg1re
After = c#endlessbg1

I just now took out the requireformer = EET ... oops.  A little late...I'll put up a new release this weekend after I test a few things.

[jastey]

Hmm... I like Storychanger, actually. Question is whether it will be appropriate for all mods that need to go into this category. Maybe something like Tweak_early? Players don't get to see these category names anyway so it shouldn't lead to confusion.