Mod loading order confusion

[Pi-C]

One of my mods was reported to crash in the handler for on_entity_damaged because another mod had destroyed event.entity of the previous event (if damage_type is "impact", on_entity_damaged will first run for the damaged entity by event.cause, then the event will be raised again for event.cause of the first event, with event.entity of the first event becoming event.cause of the second). I couldn't reproduce that at first because the other mod was loaded after mine. Finally, I discovered that the mod loading order was changed when a third mod was present:

• [-] autodrive + SchallTankWoodcutting: Neither of these mods depends on the other, so mods should be loaded in alphabetic order. As expected, autodrive is loaded first, so it gets the event before SchallTankWoodcutting can destroy the damaged entity and the game doesn't crash (see autodrive+woodcutting.log).
  
  [-] autodrive + SchallTankWoodcutting+ SchallTransportGroup: autodrive has an optional dependency on SchallTransportGroup, but neither SchallTransportGroup nor SchallTankWoodcutting depend on each other. I'd expect that mods are loaded in the order SchallTransportGroup --> autodrive -- SchallTankWoodcutting, but the actual loading order is SchallTankWoodcutting --> SchallTransportGroup --> autodrive (see autodrive+woodcutting+transportgroup.log).

Mod loading order sometimes works in mysterious ways, but I'd really like to understand how in a game with just these three mods the order of SchallTankWoodcutting (which neither autodrive nor SchallTransportGroup depend on) could be affected by the presence of SchallTransportGroup. Any explanation?

(Closing the circle: I know that the problem of my mod crashing when both SchallTransportGroup and SchallTankWoodcutting are active could be fixed if an optional dependency on autodrive was added to SchallTankWoodcutting. Unfortunately, Schallfalke hasn't been active for over a year, so there's no way to get that fix implemented.)

[BrainGamer_]

The game gives all active mods an order that takes into account their dependencies first and their internal names second. This order determines the load sequence of mods at game startup, as well as the order in which events are sent during runtime. Specifically, the depth of each mod's dependency chain is taken into account first, sorting the the shorter ones to the front of the queue. For mods with identical chain depths, the natural sort order of their internal names then determines the definitive ordering.

The game figures out the dependency chain length of each mod (as in: what is the longest dependency chain for a mod that needs to load before it can load) and then loads mods from the shortest chain length to the longest. Mods that have the same dependency chain length are sorted based on their internal mod name (case insensitive natural sort order).

In your example case here that results in the following:

1. core (core is always the first thing to load)
2. base (dep chain length: 0)
3. SchallTankWoodcutting (dep chain length: 1)
4. SchallTransportGroup (dep chain length: 1)
5. autodrive (dep chain length: 2)

The order of 3 and 4 is determined by their internal mod name since they both have a dependency chain length of 1.

[robot256]

It looks all the mods without dependencies present are done first, then the dependent mods are done, probably in tiers.

Honestly it might be time to retire support for SchallTransportGroup. I went along with because it didn't seem to hurt anything, but Schallfake insisting that every other mod add a dependency and code was never the right way to achieve its goal. It ought to be entirely automatic and contained within the group mod's data-final-fixes file. Removing your dependency and compat code won't materially affect anyone's game, just the creating menu layout.

[Pi-C]

The game figures out the dependency chain length of each mod (as in: what is the longest dependency chain for a mod that needs to load before it can load) and then loads mods from the shortest chain length to the longest. Mods that have the same dependency chain length are sorted based on their internal mod name (case insensitive natural sort order).

Thanks a lot for this very detailed explanation! I didn't know about the impact of dependency chains, but that actually makes a lot of sense and accounts for unrelated dependencies of unrelated mods messing up things.

Honestly it might be time to retire support for SchallTransportGroup. I went along with because it didn't seem to hurt anything, but Schallfake insisting that every other mod add a dependency and code was never the right way to achieve its goal. It ought to be entirely automatic and contained within the group mod's data-final-fixes file.

I've removed the optional dependency on SchallTransportGroup. Originally I believed that it should load run first so its item-group would exist when I created subgroups for it in data.lua. Then I thought I'd have to move the code for assigning subgroups to data-updates.lua, but it turned out that isn't even necessary.

Unfortunately, removing the dependency on SchallTransportGroup will only fix my issue with SchallTankWoodcutting in some cases. It would work in the scenario from my original post, where autodrive is the only mod besides those two. But with lots of active mods (the saved game for which I've got the bug report contained >300 mods) chances are that loading order may be changed due to the mechanism described by @BrainGamer. I've already considered making a fork of SchallTankWoodcutting that includes a hidden optional dependency on my mod, but I'm still shying away from that as it is a temporary solution and temporary solutions usually stay forever and I'd have to take care of yet another mod …

[robot256]

I guess the only other solution is to mark it incompatible in your mod

[Pi-C]

I guess the only other solution is to mark it incompatible in your mod

Yes, probably. I thought I could get away with just blacklisting the vehicle from SchallTankWoodcutting, but the mod doesn't create a new car prototype! Instead, it acts on impact damage caused by any vehicle with vehicle.type == "car".

By the way, SchallTankWoodCutting is licensed under Bob's mods Copyright. This includes the sentence

Exceptions to the no modification rule include:
Minor bug fixes/tweak for compatabillity reasons, such as altering the dependancies line in info.json to force a load order in a modpack.

The way I understand this, a fork that duplicates the complete mod, adds a new dependency, and conflicts with the original mod should be covered by this license. Do you agree?

[BrainGamer_]

Exceptions to the no modification rule include:
Minor bug fixes/tweak for compatabillity reasons, such as altering the dependancies line in info.json to force a load order in a modpack.

The way I understand this, a fork that duplicates the complete mod, adds a new dependency, and conflicts with the original mod should be covered by this license. Do you agree?

I'd read it the same way yeah. Publishing a fork that fixes a compatibility issue should not break this license.

[Pi-C]

I'd read it the same way yeah. Publishing a fork that fixes a compatibility issue should not break this license.

Good! I've just got the next report related to SchallTankWoodcutting (this time without SchallTransportGroup) loading before autodrive, so it seems I must make a fork after all.