What I'm proposing is to add a new symbol to the dependencies specification that indicates "this mod should load before the dependency or optional dependency" instead of after.
Let's call the symbol a "before" symbol, and for this example the symbol can be this: "¬" (it could be something else).
Mod A has some dependencies:
"¬ mod-b >= 0.1.1" would mean that mod B is required, but mod A should load first.
"¬? mod-b >= 0.1.5" would mean that mod B is optional, but mod A should load first.
"¬! mod-b" wouldn't change anything, it's still incompatible.
This would allow you to do things like:
Mod A requires Mod B with "¬ mod-b >= 0.1.1"
and Mod B requires Mod A with "mod-a >= 0.1.1"
The above means both mods require each other but there is no dependency loop because the agree on the order.
Also Mob B can specify an optional dependency of Mod C to make sure it loads after Mod C.
Mod C could then later decide that it needs mod A as a dependency, so inserts itself between the two mods in a way that isn't otherwise possible.
Add mod dependency symbol that indicated load before the dependency or optional dependency.
Re: Add mod dependency symbol that indicated load before the dependency or optional dependency.
This does not seem necessary if you control all mods involved.
What is your use case?
What is your use case?
Re: Add mod dependency symbol that indicated load before the dependency or optional dependency.
The use case is when mod C is a third party mod and you want to allow it to slot between mod A and mod B.
Space Exploration as an example, the main mod is designed so people can require it, make changes, and slot things in. The postprocess mod has some stuff that needs to run after everything else so it needs to be able to set optional dependencies of mods that may now or later require the base space exploration mod.
The postprocess mod can require the base space exploration mod, which is fine, but the risk is someone trying to load space exploration without the postprocess. It would be nice if the base mod has some way of saying that the post process mod is required too without causing a loop.
Space Exploration as an example, the main mod is designed so people can require it, make changes, and slot things in. The postprocess mod has some stuff that needs to run after everything else so it needs to be able to set optional dependencies of mods that may now or later require the base space exploration mod.
The postprocess mod can require the base space exploration mod, which is fine, but the risk is someone trying to load space exploration without the postprocess. It would be nice if the base mod has some way of saying that the post process mod is required too without causing a loop.
Re: Add mod dependency symbol that indicated load before the dependency or optional dependency.
It sounds for me like trying to fix a problem with data, data-updates, data-final-fixes that accurs between the mods.
My guess is that some of the mods don't adhere to basic rules like not defining new entities in updates/final stages.
My guess is that some of the mods don't adhere to basic rules like not defining new entities in updates/final stages.
Re: Add mod dependency symbol that indicated load before the dependency or optional dependency.
If your mod derives new things from old things, you have to either: run in data-updates, depend on every mod that could possibly define a new thing you derive things from, or provide an API for other mods to register their thing with your mod.
All of the compression mods, for example, have this nature.
That said, I get the impression that for this particular use case that it would be semantically equivalent to have:
* pre-work mod - perhaps x library, or x base
* other mods that depend on pre-work mod
* post-work mod, which depends on the pre-work mod, and is named as the primary mod.
Alternatively, I suggested elsewhere that to support mod packs it might be useful to request that the data phase is skipped for component mods, and allow the mod pack to perform the data phase by requiring __component-mod__/data.lua as part of the mod pack's data.lua, including combatability patches between mods.
All of the compression mods, for example, have this nature.
That said, I get the impression that for this particular use case that it would be semantically equivalent to have:
* pre-work mod - perhaps x library, or x base
* other mods that depend on pre-work mod
* post-work mod, which depends on the pre-work mod, and is named as the primary mod.
Alternatively, I suggested elsewhere that to support mod packs it might be useful to request that the data phase is skipped for component mods, and allow the mod pack to perform the data phase by requiring __component-mod__/data.lua as part of the mod pack's data.lua, including combatability patches between mods.