Bug Description

when using Dynamic Resources with the backpackd mod the model

Reproduction Steps

enable Dynamic Resources and have the backpackd mod and Dependencies installed

Log File

latest.log

This is likely to not be fixable on my end; they apply a mixin to the ModelBakery here instead of using Fabric's standardized Model Loading API. Model bakery mixins generally do not work well with dynamic resources. Please report it to them (though I am unsure if they will fix it).

I don't see why this can't be compatible, especially since I use a non-invasive code injection. I cannot use the Model Loading API since I would need to know the location of the models. My Mixin loads all models from a specific directory, unbeknownst of the models within it. I'll look into why it's not being loaded.

After some testing, Dynamic Resources additionally doesn't load models registered by NeoForge's ModelEvent.RegisterAdditional event.

This you can't do with RegisterAdditional as you need to provide the exact resource location of each model. Basically I am loading a whole directory, not a file. I am doing this because you can create addons packs for Backpacked simply through an RP/DP combination.

Would calling listResources yourself on the client's resource manager from the event handler work?

Ok, so the bug here was probably unrelated to the mixin, it was just that I forgot to implement loading of the standalone/fabric_resource variants in 1.21.1 (although I did do it in 1.21.3), so it simply couldn't load the backpack models. a29bdb2 fixes this.

After some testing, Dynamic Resources additionally doesn't load models registered by NeoForge's ModelEvent.RegisterAdditional event.

ModelEvent.RegisterAdditional is not important for dynamic resources because it does not need to know all the model locations up front; it just has to know the correct way to load any ModelResourceLocation it's provided.

I don't see why this can't be compatible, especially since I use a non-invasive code injection. I cannot use the Model Loading API since I would need to know the location of the models.

This might work in 1.21.1 but I can assure you right now it almost certainly will not work when you port to anything newer; the vanilla code isn't amenable to loading one model at a time anymore, so my new approach is to handle the model loading myself, but still invoke all the platform model loading APIs. Any mixin-based model logic is highly likely to have issues I cannot fix, so I provide no guarantee it works.

For your use case I'm unsure why you need the mixin if you are already using RegisterAdditional; NeoForge should already be aware of and bake all the models you provided there.

For your use case I'm unsure why you need the mixin if you are already using RegisterAdditional; NeoForge should already be aware of and bake all the models you provided there.

I'm not using it in Backpacked, however I am in my Furniture Mod. In Backpacked, I load all models from a special directory in the assets. This you can't do with RegisterAdditional as you need to provide the exact resource location of each model. Basically I am loading a whole directory, not a file. I am doing this because you can create addons packs for Backpacked simply through an RP/DP combination.

Ok, so the bug here was probably unrelated to the mixin, it was just that I forgot to implement loading of the standalone/fabric_resource variants in 1.21.1 (although I did do it in 1.21.3), so it simply couldn't load the backpack models. a29bdb2 fixes this.

I'll give this a test

Would calling listResources yourself on the client's resource manager from the event handler work?

That seems to be the right solution. Thanks for the tip.