didnt create a crashlog but this is the log file i do have.

https://pastebin.com/vK5EfqvU

I'd recommend removing Not Enough Crashes as it is conflicting with better loading screen.

Also, Cull Leaves mod is conflicting with Sodium but not crashing as far as I see.

Looks like Combat Tweaks has conflicting redirect mixin with Fabric Item API.

Combat Tweaks' redirect
Fabric API's redirect

Not sure how to fix this though 😞
@Technici4n @CammiePone

I suggest that CombatTweaks should fix it.

@CammiePone said she'd fix it on her side, so closing.

Yea, I'll get to fixing it eventually. For now, if you wanna use CCT, just use an older version of FAPI. I plan to use MixinExtras to remove all of my redirects in my mods eventually.

That doesn't help if fabric API doesn't use it though. Something to consider I guess.

Oh I assumed if my mixin applied first, Fabric API's would just redirect the call in the parameters of my inject

Wait, what is even the purpose of this redirect? It does the exact same thing as vanilla does it not?

My mixin does data-driven attribute modifiers, hence why I redirect on that method. I'm not sure what the Fabric API redirect is even used for.

I get that it's for stack-aware attributes, but also you can literally get the stack with the entity and the slot, and odds are if you have access to the slot, you can get access to the entity somewhere down the line.

Wasn't linking attributes to your entity locked to mods when the fabric entity attribute api was made

sorry saw attributes thought it was entities, this is item stuff.

Looking at it, it's just a hook extension for stack-aware attributes as you said. I don't think removing it is ideal since having these hooks inside an Item class simplifies logic a lot and saves the modder time in implementing it. Otherwise, "somewhere down the line" really just becomes having to shove down logic wherever you can find a space for that.

B sounds interesting. What use cases would this event have? (other than your use case)

Only ways I can see this working is if:
a) we both use MixinExtras
b) an event is added to FAPI so I can move my stuff to that, or
c) I attempt to implement the stack-aware attributes on my end, set mine to a ModifyVariable to completely negate FAPI's mixin, and pray that works

Option A would be great for other modders since then they get access to MixinExtras, but seems the least likely to happen. Option B is probably the best middle-ground since then we both get what we want simultaneously. Option C is what's probably going to happen because what recourse do I have against the API everyone uses suddenly bricking my mixin?

Modders adding attributes to other items in-game, whether they be vanilla or modded, especially their own attributes (i.e. someone makes a magic resistance attribute they want to apply to gold armour)

IMO having an event would be reasonable, changing Mixin in any form is currently no priority. Minecraft relies on item attributes staying consistent for the same stack, so such an event would look exactly the same as the Item extension and run after the item method invocation.

The event is a good idea, but in the meanwhile it looks like it should work fine with a ModifyVariable.

The event would give a chance to modify the existing map. How is it different from a ModifyVariable placed after the method calls?

It would, assuming I can capture it and manage to apply after your redirect. ModifyVariable likes to not work half the time it should for me. Sadly, only thing I can reliably target is when the variable is stored, and I dont remember how much redirects change the code, or if they add additional lines anywhere.

INVOKE_ASSIGN didnt let me target the correct variable last time I tried it with a Modify Variable in FluidRenderer, so I think it targets in the bytecode before the variable is actually stored.

In this case it might work since the variable already exists, but I'll have to check tomorrow.

I'm pretty sure they just replace the method call. It should be safe to target the vanilla method with INVOKE_ASSIGN, in a mixin that applies before fabric's. Then fabric's mixin will replace the method call and your modify variable hook will still be there. You can add -Dmixin.debug.export=true to check.

Closed by #2175.