Dynamic Crosshair causes rendering issues and crashes with Tinker's construct
BookWyrm114 opened this issue · 8 comments
I honestly have no idea how or why this mod would cause a conflict but here's the crash log: https://crashy.net/thuiaXNggPH7JK4OFEAc
and here's the issue I made on the tinker's construct github: SlimeKnights/TinkersConstruct#5059
No, I just successfully managed to replicate the crash with TC+DC+REI. Hovering over any modded fluid in REI causes this crash, but only if DC is installed. It is a weird one, because I don't do anything with rendering.
However, I do use Mixin accessors to access BucketItem::getFluid (yarn mapping); and if Forge modifies that class (it looks like there's a FluidBucketWrapper), the pure existence of the Mixin might cause the crash. If that's the case, I'll have to see if migrating to accesswideners fixes it, or if I need to learn more about Forge modding.. definitely seems like it's on my end, though.
Removing all uses of that mixin, but leaving the mixin loaded replicates the crash. So it is the pure existence of that, as I suspected. I will have to think about how to properly handle this across the two loaders, then. The port did feel too easy :)
Interesting. The offending line will most likely be https://github.com/Crendgrim/DynamicCrosshair/blob/1.18/common/src/main/java/mod/crend/dynamiccrosshair/handler/VanillaUsableItemHandler.java#L234
This works fine on Fabric, but it is not impossible that Forge modifies some class behaviour here in a way that I was not anticipating.
I am still not entirely convinced there is not some mod registering a bucket with a null fluid for the record. So it may not entirely on your side either. Might be worth additional digging to see if this issue happens with just Tinkers and Dynamic Crosshair, no additional mods.
Forge does have access transformers if you need to access a private field. So if you make the mixin fabric only that is an option. That said, there should be a way to get accessors on forge, I have seen others use it before.
I suspect the issue here is Forge makes it a Delegate instead of a Fluid though
Yep! Architectury also has a setup to automatically translate Fabric AccessWideners to Forge's AccessTransformers, so I could likely use that. I was happy that the mixins just worked™ before I was aware of this issue, but apparently there's pitfalls.
I suspect the issue here is Forge makes it a Delegate instead of a Fluid though
Yeah, I am afraid I will have to learn proper Forge modding now and understand these concepts & how Forge implements them.
Ah, much easier: Forge just makes that function public on its own. With the mixin abstracted away, it seems to work perfectly fine.
I will have a look at all of my other accessor mixins to see if there's more candidates for similar crashes and then push a fixed version :)