Forge Version 43.1.52
canary-mc1.19.2-0.1.1

Latest.log
https://gist.github.com/P3rf3ctXZer0/0fcdb0a638aeee4d44ee70db02fd4e9b

The game starts up if I use canary-mc1.19.2-0.0.9 anything past this has the issue listed below.

Talking to Thutmose this is the fail point

https://gist.github.com/P3rf3ctXZer0/e19edca83c8a17ba4a3b5903daa3d24a

@TheDogeOfTheInternet Thanks for your suggestion it get worked! I hope you have a good day!

getting this as well

I'm also getting mixin crashes with the latest update.

same with me

Same errors for my 1.19.2 server as well

The log provided shows that this is the same issue as described here.

AbdElAziz333 described the fix as being:

in LevelChunkMixin you should replace lambda$updateBlockEntityTicker$7 with m_187960_ and in common.entity.EntityClassGroup you should replace canCollideWith with m_7337_ and canBeCollidedWith with m_5829_.

To me, this seems to suggest that it's some sort of reobfuscation oversight. Surely there should be some automated way of building such that the exported mod uses the obfuscated names in Minecraft rather than the deobfuscated names available with MCP.

i forgot changing the method names to SRG names, i am very sorry about that.

i forgot changing the method names to SRG names, i am very sorry about that.

I'm not an expert at Minecraft Forge or the Minecraft modding system in general, but shouldn't you be able to build such that you don't need to manually change between deobfuscated names and SRG names?

Looking at the Minecraft Forge source code, there seems to be a way to implement hasMethodOverride() in ReflectionUtil to avoid this issue: if you call clazz.getDeclaredMethod(ObfuscationReflectionHelper.remapName(INameMappingService.Domain.METHOD, methodNameInSRG), methodArgs) (as seen here, using Forge's ObfuscationReflectionHelper and INameMappingService classes) instead of the current clazz.getDeclaredMethod(methodName, methodArgs), I think this would mean you would only have to store the SRG names in the code, but the dev builds would also work due to the remapping. I'm not 100% sure, but it might be good to try.

I'm not so sure about the lambda one in LevelChunkMixin, since I was under the impression that @Inject was meant to remap everything automatically. However, looking at these docs, they mention that inner classes can have issues with deobfuscation. I'm not 100% sure how lambdas are implemented in Java, but the $ notation seems potentially suggestive of inner classes to me. The docs say that it can be resolved for private inner class fields by using an aliases value in an @shadow or @overwrite annotation, but since you use this inside an @Inject annotation, I'm not sure if it's possible to do so. Maybe it would be worth asking on the Minecraft Forge forums or something if this is possible.

I will try that, i really appreciate your help!

The issue is fixed in the new version.