Conflict with fabric-carpet
octylFractal opened this issue ยท 12 comments
Versions
WorldEdit version: 7.2.1
Platform version: 1.16.3+
Describe the bug
WorldEdit's UPDATE mixin conflicts with fabric-carpet's same mixin, crashing the game.
To Reproduce
- Install both mods.
- Launch the game.
Expected behavior
The two mods should work together.
Workaround
Downgrade to 7.2.0, no UPDATE mixin -> no conflict.
Weird, I can run Carpet and WorldEdit mod without crash but when I add Library of Exile to mods then mc crashes.
Running Library of Exile with WorldEdit without Carpet doesn't crash.
Confirmed here as well.
Carpet 1.4.20 with WorldEdit 7.2.1 crashes game when loading world.
Remove either and no issues.
A question is whether when this is fixed, will both features (fillUpdates
from Carpet and WE's editing without updates) work together? Like, if someone disables updates in Carpet, WE won't force updates if WE updates are on, and the other way around.
Or will this be fixed by letting one of the features dominate the other? (with Carpet probably already offering the without updates functionality for WE since they are based on the same spot and it being more general)
Don't know yet, I think the only viable solutions I know of now is either:
a) WorldEdit drops UPDATE support on Fabric if Carpet is installed (we will probably implement this temporarily at least)
b) Carpet drops fillUpdates if WorldEdit is installed (up to them)
c) It becomes Fabric API, and effectively forces Carpet to accommodate/use the API mixin (this is tentatively possible)
We will not add special handling for Carpet in particular, we would just be checking mixin targets.
cant WE just change mixin priority so that either in case of conflict there isnt any ambiguity?
Because gnembon(owner of fabric carpet repo ) would likely be wiling to do that if necessary. But specifically checking for WE likely wouldnt be very neat in the code, not to mention that WE may not be the only mod with such conflicts, so I suppose that mixin manipulation would be best. Looking at the three options, it seems that the only thing now is to decide who does it... I know gnembon doesnt want to have to depend on fabric API for sure.
cant WE just change mixin priority so that either in case of conflict there isnt any ambiguity?
To my knowledge, no, though I would be happy to be proven wrong. I've asked and gotten no solution.
Closing as fixed in 56c8919
(Assume it didn't auto-close due to not being master)