Issue PepperCode1/Continuity#115 has recently been reported and describes a resource reload loop. The errors contain Forgero classes and methods, but according to the issue report, the problem is resolved if Continuity is not present, leading me to believe it is an incompatibility. Is it possible to fix from your side?

While I do not know exactly why errors occured in the user's setup because they were not using any external resource packs, after inspecting Forgero's code I can see how an incompatibility can arise that will lead to the same error. It can be fixed by performing this change:

ReloadableResourceManagerImplMixin.java
-         if (id.getNamespace().equals(ForgeroInitializer.MOD_NAMESPACE) && id.getPath().contains(".png") && id.getPath().split("_").length > 1 && !id.getPath().contains("transparent")) {
+         if (id.getNamespace().equals(ForgeroInitializer.MOD_NAMESPACE) && id.getPath().contains(".png") && id.getPath().split("_").length > 2 && !id.getPath().contains("transparent")) {

That class is no stranger to reload loops, so that very probable that this mixin is causing issues. Would your mod create textures with the forgero namespace when it is installed? I struggle to see how your mod could have anything to do with this. I'll have to look into it when I get back home though, so it might be a while untill I can resolve the issue.

That mixin is in dire need of a rewrite, which I will get to. Someday. The bug was reported when used with forgero 0.8.4, this issue might also be resolved by updating to 0.8.5.

I'll also have to test the proposed change to see if that does not cause any problems with the texture generation pipeline.

Yes, Continuity may create Identifiers and sprites with the Forgero namespace if a resource pack chooses to use the namespace. Like I said I don't know why it happened here because the user was not using any external resource packs, but the case of another mod creating Identifiers with the Forgero namespace should not be excluded.

Yeah, I'll rework the texture service to look up the textures in a registry instead of trying to match them against broad pattern like this. It was only a matter of tile before that garbage mixin started creating issues.

Thanks for the heads up!

Hey, I'm the one who originally reported the issue on Continuity's end. I updated Forgero to forgero-0.9.0-pre-3-BETA-1.19 and it seems to have solved the issue for me at least.

Right! There's still some unresovled issue in the pre-release, but it's nice to see that it contains a fix for the problem.

I'll probably create a separate issue for reworking the mixin to prevent issues like this in the future!

I am pretty sure the newest 0.9.0 update will solve this issue when its released. The update also introduced the fix explained earlier where it only matches preregistered textures. I have tested with forgero-0.9.0-BETA-1.18.2, and it seems to work.