Hot loading manifests rules are changing!

I think it does? (the event is triggered in that setup_biome_data fn, so it does trigger after load)
image

Doesn’t make much sense that it doesn’t. Especially since biomes can have applied_manifests in their json file too. :thinking:

Right, I confused it. That is basically the biome manifest.

I remember we couldn’t make it work so I ended up adding “fish filters” to the Trapper+ mod with or without Archipelago.

So regardless of having it or not, the filters are there. Considering that Archipelago is far more popular than Trapper+, it has not caused any major issues (I think only one person so far ever asked how to obtain fish).

But yeah, as far as I know what we were trying to do is still impossible, although I can’t quite recall the details. But indeed I think it was Mod A trying to alter Mod B in adding a change for Mod B to alter Mod A back.

There was also another alternative we tried out which we also couldn’t make it work but it was because mod loading order was alphabetical and it only worked when you renamed my mod __trapper_plus :stuck_out_tongue:

Sadly the problem is still here and with ACE a way to provide extensive inter-mod support is needed. The error message is thrown at me at main menu.

Hot loading manifests is only allowed before world generation completes -OR- for `client_only` manifests from client lua. Ignoring hot load for:/lostems/mod_support/stonehearth_ace/manifest.json```
1 Like

And more important than ever if you want to make a mod compatable with the game both with and without ace, help us team radiant you are our only hope XD

What is the problem exactly? I.e. what is it you are trying to do that requires manifest hot-loading?

Ace changed items in a way that if you make your mod compatible with it, it actually errors out when using without it. For example, shields in the base game uses leftArm while in ace it is offhand.
So we need a way to have our item work with base game, but when ace is on, change our item to be ace compatible.
So the idea was to hotload a mod if ace is on, and that mod would change our own items with the ace requirements.

1 Like

Adding to what Bruno said, we tried a few alternatives that seemed to sorta work. But depends way too much on load order and or luck. So yeah my hacky fix of mixing into ace’s manifest won’t be enough :confused:

LostEms needs a server script to simply alter some recipes. It gets loaded mods list via radiant.resources.get_mod_list(), compares it to the list of supported mods and hotloads manifests of deferred load submods:

lostems = {}

function lostems:_on_init()
   radiant.log.write_('lostems', 0, 'LostEms server initialized')
   local mods = radiant.resources.get_mod_list()
   local supported_mods = {
      'stonehearth_ace'
   }
   lostems._submods = {}
   for _, m in ipairs(mods) do
      for _, n in ipairs(supported_mods) do
         if m == n then
           table.insert(lostems._submods, m)
         end
      end
   end
--[[
   local mod_report = 'Enabled supported mods: '
   for _, n in ipairs(lostems._submods) do
      mod_report = (mod_report .. n .. '; ')
   end
   radiant.log.write_('lostems', 0, mod_report)
--]]
end

function lostems:_on_required_loaded()
   for _, n in ipairs(lostems._submods) do
      local func_name = ('_on_' .. n .. '_enabled')
      lostems[func_name]()
   end
end

function lostems:_on_stonehearth_ace_enabled()
   _radiant.res.apply_manifest("/lostems/mod_support/stonehearth_ace/manifest.json")
   radiant.log.write_('lostems', 0, 'stonehearth_ace submod manifest applied')
end

radiant.events.listen_once(lostems, 'radiant:init', lostems, lostems._on_init)
radiant.events.listen_once(radiant, 'radiant:required_loaded', lostems, lostems._on_required_loaded)
radiant.events.listen_once(radiant, 'stonehearth:biome_set', lostems, lostems._on_required_loaded)
return lostems

The problem is depending on situation one can hotload mods only in certain moments. No matter what one is doing, it seems mandatory to try doing so at radiant:required_loaded event. When starting a new game, it has to be done also at stonehearth:biome_set event to work.

However, the advantage of having a mod support server script is the ability to provide submods for combinations of supported mods.

There are numerous problems with hot-loading manifests at arbitrary time. A major one is that you can easily desync a multiplayer game by loading things dynamically, and JSON becomes mismatched between clients.

Another issue is that cached references or already-created objects can become invalid because a mixinto has modified their JSON. The engine in general assumes that game data JSON is immutable once the game is loaded, so it will do things like cache half the values loaded from a JSON file (e.g. if they need a more convenient in-memory representation) and read the other half on demand. If the JSON is modified by mixintos after the caching is done, you’re in undefined behavior territory.

Even the current state of allowing hotloading at biome selection is dodgy, since in theory nothing stops a mod from creating arbitrary world state before then. It was left in because stuff already depended on it, and the chance of bugs was worth not breaking compatibility.

In some cases, you can solve the need for a dynamic manifest by mixing into files from the other mod that might or might not be there. If the mod exists, they’ll go through, and if it doesn’t, it’ll just print a harmless warning.

In other cases, you can detect other mods in Lua and modify world state dynamically instead of messing with JSON.

If neither of this works, you can always fall back to requiring a mod, or making separate vanilla & ACE versions. It’s not ideal, but to be frank adding support for freeform hotloading is unrealistic at this point.

1 Like

I did this for mine with Auto Harvest a while back, where in my manifest I had something like:

"box_o_vox:entities:plants:peppercorn_bush": "autoharvest_mod/mixins/renewable_resource_node/show_autoharvest_ui.json"

Right. Making ace a requirement it is then.