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

[AL|EN]

Sure, but I would pretty much do it properly, with new keyword, where the usage context is clear and straightforward.

[Wisp]

@AL|ENCan you elaborate on this feature request? Maybe I'm skimming through this thread too quickly, but I'm not seeing much in the way of descriptions.

[AL|EN]

@Wisp Sorry, I was exhausted after dealing with this stuff, let me clarify:

I would like you to give modders a way to provide more data inside components, this is my proposition:

- create new "LABEL"-like component keywords, with different names
- add the new keywords and it's data into --list-components-json
- the keyword names are: "TYPE", "BEFORE", "AFTER", "REQUIRELATER", "REQUIREFORMER"

The purpose/context of the new keywords is the one that is discussed in this thread so weidu won't be responsible for 'handling' those keywords.

[Lauriel]

On 4/25/2020 at 12:44 AM, AL|EN said:

@Wisp Sorry, I was exhausted after dealing with this stuff, let me clarify:

I would like you to give modders a way to provide more data inside components, this is my proposition:

- create new "LABEL"-like component keywords, with different names
- add the new keywords and it's data into --list-components-json
- the keyword names are: "TYPE", "BEFORE", "AFTER", "REQUIRELATER", "REQUIREFORMER"

The purpose/context of the new keywords is the one that is discussed in this thread so weidu won't be responsible for 'handling' those keywords.

Is there any comment-like symbol that weidu will ignore inside a tp2 that PI could pick up and use for this purpose?

[AL|EN]

1 minute ago, Lauriel said:

Is there any comment-like symbol that weidu will ignore inside a tp2 that PI could pick up and use for this purpose?

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

[Lauriel]

Just now, AL|EN said:

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

Well, I guess that would depend upon where it was put and it's syntax, but it's a moot point.

[Lauriel]

I'm going to try to incorporate what I can into the ini file for Transitions.  I have the normal stuff, but just starting at the very first "thingie" I'd set, Type, I'm sort of at a loss.  Have you determined a set of types to pick from?  My Transitions mod would be a Tweak?  I guess, although it does add quests that's not it's main purpose.  Is there a Misc category?

I'm assuming (correct me if I'm wrong), that you don't want us to repeat dependencies already listed in the TP2 file.

 

[Lauriel]

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

Quote

Type = Tweaks

Before = NPC, bg1re

After = c#endlessbg1

RequireFormer = EET

 

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

 

Edited September 4, 2020 by Lauriel

[AL|EN]

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.

 

Edited September 4, 2020 by AL|EN

[jastey]

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.

[DavidW]

I didn't see this discussion when it originally got posted (we had a new baby at the time).

I have some doubts about whether this will really work, but putting them aside: my main thought is about the categories. As written, they're fairly player-focussed: 'kit', 'tweak', 'NPC', 'AI' and the like. But if you're writing a machine-readable system, I think you can do better than that. 

An illustration: AI mods. That's a perfectly sensible category for players: SCS falls into it, so does Tactics. But Tactics basically just dumps a bunch of BCS and CRE files into the override (I simplify, but only slightly) SCS needs to go at or near the end of an install order, but that's not because it's an AI mod; it's because it dynamically responds to resources already in the game. (e.g., it edits many CRE files according to what equipment they have, so trouble occurs if a mod gets installed after SCS and adds or modifies a CRE file).

The minimal version of this is that you need a category 'dynamically-responsive'. Some mods that look quite different from a player's point of view will go in that category, and mods (or mod components) in that category will need to be installed after mods that aren't dynamically responsive. A more ambitious version would move from categories to tags: a mod with a responsive_to_kits tag would need to be installed after a mod with an add_kit tag. (I'm unsure if that's really viable though.)

One other note: I don't think UI-Patch is a good category. UI patching is a technique mods use, not a feature of a mod. SCS patches the UI, for instance.

 

[Lauriel]

8 hours ago, DavidW said:

CS needs to go at or near the end of an install orde

I think yours would be one of the easiest to set up using the current system: After = EET_End, *

[subtledoctor]

Came by to glance at this thread again, and I am beginning to update my mods and add .ini files for PI to use.  And not to be a downer, but I don't like the syntax here.  "AFTER = x, y, z" sort of implies something like "the mods that go after this are x, y, and z."  Whereas, I gather that it really means something like "this mod should go after x, y, and z."  The "=" suggests a meaning opposite to the one intended.

If the  "=" is necessary for the file to be read, I would change the keywords to account for that.  Maybe something long and decscriptive, like:

THIS_MOD_LATER_THAN = a, b, c
THIS_MOD_EARLIER_THAN = x, y, z

Or maybe:

EARLIER_MODS = a, b, c
LATER_MODS = x, y, z

 

[AL|EN]

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

Edited September 8, 2020 by AL|EN

[DavidW]

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.