Black screen when used together with Falling Leaves

Question

Black screen when used together with Falling Leaves

toriato opened this issue 5 months ago · 21 comments

toriato commented 5 months ago

When using Falling Leaves together, the screen gets stuck on black after the Mojang logo appears. Although I can still interact with the interface using the mouse and hear button sounds, indicating that the game hasn't completely crashed, I'm unable to actually play the game.

Versions in use:

Java 21.0.3
Minecraft 1.21.5
Fabric 0.16.12
fallingleaves-2.0.0+1.21.5
WilderWild-4.0.5-mc1.21.5

Possibly related logs:

[02:05:36] [Render thread/ERROR]: Mixin apply for mod wilderwild failed wilderwild.mixins.json:client.wind.fallingleaves.ConfigDefaultsMixin from mod wilderwild -> randommcsomethin.fallingleaves.config.ConfigDefaults: org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException Critical injection failure: @Inject annotation on wilderWild$forceAddCompatBecauseTheyDidntAgain could not find any targets matching 'Lrandommcsomethin/fallingleaves/config/ConfigDefaults;spawnRateFactor(Lnet/minecraft/class_2960;)D' in randommcsomethin/fallingleaves/config/ConfigDefaults. Using refmap mixins.wilderwild.refmap.json [INJECT_PREPARE Applicator Phase -> wilderwild.mixins.json:client.wind.fallingleaves.ConfigDefaultsMixin from mod wilderwild -> Prepare Injections -> handler$fnh000$wilderwild$wilderWild$forceAddCompatBecauseTheyDidntAgain(Lnet/minecraft/class_2960;Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfoReturnable;)V -> Parse ->  -> Validate Targets]
org.spongepowered.asm.mixin.injection.throwables.InvalidInjectionException: Critical injection failure: @Inject annotation on wilderWild$forceAddCompatBecauseTheyDidntAgain could not find any targets matching 'Lrandommcsomethin/fallingleaves/config/ConfigDefaults;spawnRateFactor(Lnet/minecraft/class_2960;)D' in randommcsomethin/fallingleaves/config/ConfigDefaults. Using refmap mixins.wilderwild.refmap.json [INJECT_PREPARE Applicator Phase -> wilderwild.mixins.json:client.wind.fallingleaves.ConfigDefaultsMixin from mod wilderwild -> Prepare Injections -> handler$fnh000$wilderwild$wilderWild$forceAddCompatBecauseTheyDidntAgain(Lnet/minecraft/class_2960;Lorg/spongepowered/asm/mixin/injection/callback/CallbackInfoReturnable;)V -> Parse ->  -> Validate Targets]
	at org.spongepowered.asm.mixin.injection.selectors.TargetSelectors.validate(TargetSelectors.java:346) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.readAnnotation(InjectionInfo.java:369) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.<init>(InjectionInfo.java:340) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.<init>(InjectionInfo.java:331) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.injection.struct.CallbackInjectionInfo.<init>(CallbackInjectionInfo.java:48) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:62) ~[?:?]
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:502) ~[?:?]
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486) ~[?:?]
	at org.spongepowered.asm.mixin.injection.struct.InjectionInfo$InjectorEntry.create(InjectionInfo.java:196) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.injection.struct.InjectionInfo.parse(InjectionInfo.java:664) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinTargetContext.prepareInjections(MixinTargetContext.java:1399) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.prepareInjections(MixinApplicatorStandard.java:731) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.applyMixin(MixinApplicatorStandard.java:315) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinApplicatorStandard.apply(MixinApplicatorStandard.java:246) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.TargetClassContext.apply(TargetClassContext.java:437) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.TargetClassContext.applyMixins(TargetClassContext.java:418) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:363) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClass(MixinTransformer.java:234) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClassBytes(MixinTransformer.java:202) ~[sponge-mixin-0.15.4+mixin.0.8.7.jar:0.15.4+mixin.0.8.7]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.getPostMixinClassByteArray(KnotClassDelegate.java:422) ~[fabric-loader-0.16.12.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.tryLoadClass(KnotClassDelegate.java:323) ~[fabric-loader-0.16.12.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:218) ~[fabric-loader-0.16.12.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:119) ~[fabric-loader-0.16.12.jar:?]
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526) ~[?:?]
	at knot/randommcsomethin.fallingleaves.config.LeafSettingsEntry.<init>(LeafSettingsEntry.java:16) ~[fallingleaves-2.0.0+1.21.5.jar:?]
	at java.base/java.util.stream.Collectors.lambda$uniqKeysMapAccumulator$1(Collectors.java:180) ~[?:?]
	at java.base/java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) ~[?:?]
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) ~[?:?]
	at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1715) ~[?:?]
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[?:?]
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
	at knot/randommcsomethin.fallingleaves.util.LeafUtil.getRegisteredLeafBlocks(LeafUtil.java:286) ~[fallingleaves-2.0.0+1.21.5.jar:?]
	at knot/randommcsomethin.fallingleaves.init.Leaves$1.method_14491(Leaves.java:89) ~[fallingleaves-2.0.0+1.21.5.jar:?]
	at knot/net.minecraft.class_4013.method_29490(class_4013.java:16) ~[client-intermediary.jar:?]
	at java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:787) ~[?:?]
	at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482) ~[?:?]
	at knot/net.minecraft.class_4014.method_67574(class_4014.java:60) ~[client-intermediary.jar:?]
	at knot/net.minecraft.class_1255.method_18859(class_1255.java:164) [client-intermediary.jar:?]
	at knot/net.minecraft.class_4093.method_18859(class_4093.java:23) [client-intermediary.jar:?]
	at knot/net.minecraft.class_1255.method_16075(class_1255.java:138) [client-intermediary.jar:?]
	at knot/net.minecraft.class_1255.method_5383(class_1255.java:123) [client-intermediary.jar:?]
	at knot/net.minecraft.class_310.method_1523(class_310.java:1308) [client-intermediary.jar:?]
	at knot/net.minecraft.class_310.method_1514(class_310.java:936) [client-intermediary.jar:?]
	at knot/net.minecraft.client.main.Main.main(Main.java:265) [client-intermediary.jar:?]
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:480) [fabric-loader-0.16.12.jar:?]
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) [fabric-loader-0.16.12.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) [fabric-loader-0.16.12.jar:?]
	at org.prismlauncher.launcher.impl.StandardLauncher.launch(StandardLauncher.java:102) [NewLaunch.jar:?]
	at org.prismlauncher.EntryPoint.listen(EntryPoint.java:129) [NewLaunch.jar:?]
	at org.prismlauncher.EntryPoint.main(EntryPoint.java:70) [NewLaunch.jar:?]

Full log:
latest.log

AViewFromTheTop commented 5 months ago

anyway

AViewFromTheTop · Answer 1 · 2025-04-07T22:09:39.000Z

I didn't even know about this mixin - this could have been a PR, ya know? 😅

I'll look into adding the config defaults tomorrow, so you can get rid of the broken mixin.

That said, I don't quite understand why palm_fronds are categorized as a conifer - I guess the texture is closer to needles? Hm... yeah, I'll allow it.

Another question though: Why do the *_maple_leaves not drop leaves, most maple trees are deciduous, no?

In all honesty I just didn’t feel like making a pr
I’ve not enjoyed some of my time interacting with certain other members of the community and I’ve preferred to keep myself closed off to new people
nonetheless
as for palm fronds, no clue
I just didn’t want them dropping custom leaves
maple leaves don’t drop leaves since wilder wild has its own leaves
ww itself adds falling leaves for all tree types, but maple leaves are more unique and special

AViewFromTheTop · Answer 2 · 2025-04-07T22:10:27.000Z

I just haven’t updated to new falling leaves yet, that’s all the issue is (though I am upset that the require = 0 thing just… doesn’t work.)

AViewFromTheTop · Answer 3 · 2025-04-07T22:11:09.000Z

oh. well that explains it I forgot to add require = 0

Fourmisain · Answer 4 · 2025-04-07T21:42:16.000Z

I didn't even know about this mixin - this could have been a PR, ya know? 😅

I'll look into adding the config defaults tomorrow, so you can get rid of the broken mixin.

That said, I don't quite understand why palm_fronds are categorized as a conifer - I guess the texture is closer to needles?
Hm... yeah, I'll allow it.

Another question though: Why do the *_maple_leaves not drop leaves, most maple trees are deciduous, no?

toriato · Answer 5 · 2025-04-07T17:19:39.000Z

I'm not sure if this is an issue with Wilder Wild, so I’ve posted the same issue on both projects. If this bug isn’t directly related to this project, please feel free to close this issue.

Fourmisain/fallingleaves#76

toriato · Answer 6 · 2025-04-07T17:20:41.000Z

Oops, I accidentally closed it. If this is a valid issue, please reopen it.

AViewFromTheTop · Answer 7 · 2025-04-12T22:50:52.000Z

Apologies for the absence, I'm back! (A bit)

AViewFromTheTop · Answer 8 · 2025-04-12T22:54:52.000Z

Wow... Not only immoral but illegal too then! I hope he's been reported to the police.

not much we can do :|
different country

Exactly! And the vanilla spawn chance for the maple leaves block is 0. It's set in the constructor of LeavesWithLitterBlock as 0F.

im stupid
uh
bruh.......

Yeah, depending on third parties in general is always a tradeoff. They might stop maintaining the project (recently happend to me with BRRP), take long too update (Forge, but I consider that a good thing) and/or the project may contain bugs that won't be fixed (I ended up patching Cloth Config via Mixin). So is the way of software engineering.

What bugs does cloth have that you patched? May be useful for us, too.
It's not like I haven't already made my own mixins on Cloth to support our config syncing system.

Yeah, I've written metric tons of mod compats, though I never use @Pseudo because it'll log a warning in the console when the class is not found, so I use mixin plugins instead. (Also I think you just pinged somebody 😄)

it logs a warning?!??!?!
bro
that's literally the whole point of the annotation why does it log a warning
oh well... at least mixin plugins work lol

Yeah, there's generally not a lot of reasons to have Falling Leaves anymore, except for the costumization aspect, that and I guess it works on any server (client-side Wilder Wilds when? 😄)

i'm not so sure i'm on-board with WW being a client mod.
could definitely be an addon!
but then people will suddenly be missing features...

Fourmisain · Answer 9 · 2025-04-13T09:27:25.000Z

What bugs does cloth have that you patched? May be useful for us, too.

Can't quite remember the details, but the GsonConfigSerializer.deserialize() returns null when the json file is empty, which would then crash the game on load with no counterplay. I patched it to return a default config instead.
Did this because I got a crash report for this once, still not entirely sure how the config ended up empty in the first place.
I think this can happen when the config is created for writing but the writing itself fails or is aborted for some reason.

Cloth Config also doesn't close their readers/writers when an exception is thrown (no try-with-resources), which might cause issues as well, but that part I left alone.

that's literally the whole point of the annotation why does it log a warning
oh well... at least mixin plugins work lol

I think @Pseudo is mainly a compile time thing, like if you do @Mixin(targets = "does.not.Exist") without it you'll get a compile error.
The warning for mixins into missing classes is a general thing from what I remember.
(Just tested it: There's actually two warnings, one saying "Error loading class ... (ClassNotFoundException ...)" and "@Mixin target ... was not found". @Pseudo disables the latter but not the former.)

Talking about this reminds me of this weird hack I used before Modrinth Maven was a thing.
@Pseudo is just fine if all you wanna do is mix into a class, but when you want to call into a non-existent class (like NonExistent.doThat();), what do you do?

Inspired by C header, you can actually just create that class in your own project and put an empty method inside, do the call on that, build the project, then rip the .class file out of the jar afterwards.

I used this a lot for dependencies that were CurseForge only with no maven access. It also has the plus of causing less build issues (due to outdated transitive dependencies or something).

Though on could also just use reflection, if performance isn't an issue.

i'm not so sure i'm on-board with WW being a client mod.
could definitely be an addon!
but then people will suddenly be missing features...

It was merely a joke... unless!
That was merely another joke!

It's kinda interesting to think about though, Fabric Loom supports splitting projects into client and server/common sourcesets. Using that you could theoretically make a build for just the client part of it.
Sounds like a lot of work though, if not a ton.
I personally never used that feature either because it seemed like a hassle and the issue it is supposed to solve (server crashes due to referencing client code) I only had like... once, so I didn't feel compelled to try it.

Fourmisain · Answer 10 · 2025-04-08T07:42:30.000Z

In all honesty I just didn’t feel like making a pr
I’ve not enjoyed some of my time interacting with certain other members of the community and I’ve preferred to keep myself closed off to new people

Understandable, I also had some bad interactions in my time - one of them I was thinking about for what felt like years - and certainly did some hackery in my mods for compatibility as well... 😅

maple leaves don’t drop leaves since wilder wild has its own leaves
ww itself adds falling leaves for all tree types, but maple leaves are more unique and special

Ah, that makes sense, they'd both drop otherwise! At least pre 1.21.5.

I just checked the maple leaves and palm fronds in 1.21.5 (after removing the offending mixin) and they do only drop their custom leaves as they should, without any config changes.

It's a little odd though, because the spawn rates cannot be changed and the maple leaves appear as having 0% spawn chance.

Hm... oh. Oh no.
I just realized that the way both our mods spawn leaves is completely incompatible with each other.

Falling Leaves modifies LeavesBlock.makeFallingLeavesParticles() to (optionally) replace the call to LeavesBlock.spawnFallingLeavesParticle() when configured to do so.

Wilder Wilds targets animateTick to (optionally) replace the call to LeavesBlock.makeFallingLeavesParticles, so it applies one step earlier.
It also uses it's own spawn chances LeafParticleData.particleChance() instead of the vanilla LeavesBlock.leafParticleChance - which I don't quite understand, why not use the latter?

I was hoping you'd be using the vanilla system to add leaves to your blocks, i.e. override LeavesBlock.spawnFallingLeavesParticle() for each block, but I do realize that you want to replace leaves from vanilla blocks as well, so in the end you have to have a general mixin like this anyway.

Well, that's a pickle.

Considering Wilder Wilds has a config to adjust spawn rates as well, I'm actually not sure if it even makes sense for the two mods to be used together anymore.
Plus your leaves just look better!

Definitely need to think about this more.
I may try and hack in compatibility using big guns like MixinSquared, stuff will surely break sometime down the road.
(Maybe I also add wind to your particles like I just saw you add to ours! Maybe I can also finally finish the wind sync - I was kinda waiting for the WW and wind split you were talking about... 😅)

But yeah, currently completely unsure, thinking cap needs to be put back on.

AViewFromTheTop · Answer 11 · 2025-04-08T07:44:37.000Z

Oof. Wind being split…

AViewFromTheTop · Answer 12 · 2025-04-08T07:45:36.000Z

It’s safe to say that’s no longer happening.
I’d pushed that plan to happen alongside multiloader support, then the person I was working with on multiloader kept lying about being available and was later caught dating a young teenager…
So 😭😭😭

AViewFromTheTop · Answer 13 · 2025-04-08T07:48:27.000Z

Also
I’m very picky with details, the differences in leaf spawning chances are absolutely intentional.
I’d chosen them starting on 1.20.1, and increased the chances for 1.21.5 since that’s now a more acceptable feature to show up commonly. Nonetheless, things like spruce needles spawning as commonly as, say, acacia leaves, really never sat right with me.

AViewFromTheTop · Answer 14 · 2025-04-08T07:56:14.000Z

As for something like Mixin Squared, I’d personally argue against it as it isn’t part of fabric loader (at least currently.)
Typically extra dependencies will just make work more tedious, at least from my experience. What I do think would be a good enough solution (assuming you want your mod’s leaves to replace mine, in all fairness I don’t know why else someone would install WW + your mod if they didn’t want your leaves instead- unless they’re using it for the automatic falling leaves on modded ones) would be to use a mixin @at(“FIELD”) here, and make it always return false.

AViewFromTheTop · Answer 15 · 2025-04-08T07:57:18.000Z

@Fourmisain just mentioning you again in case you didn’t get notifs

Fourmisain · Answer 16 · 2025-04-08T09:33:43.000Z

It’s safe to say that’s no longer happening.
I’d pushed that plan to happen alongside multiloader support, then the person I was working with on multiloader kept lying about being available and was later caught dating a young teenager…
So 😭😭😭

If you say young, I hope it's not that young 💀👮‍♂️🚓

I’m very picky with details, the differences in leaf spawning chances are absolutely intentional.
I’d chosen them starting on 1.20.1, and increased the chances for 1.21.5 since that’s now a more acceptable feature to show up commonly.

Ah, what I meant was that you could have modified LeavesBlock.leafParticleChance directly, or alternatively adjust only the frequencyModifier() to get the chances you want, so you don't end up having two separate spawn chances.

I think there's an inconsistency with that: The maple leaves have a leafParticleChance spawn chance of 0, so if you turn "New Falling Leaves" off, they won't drop any leaves.

Not a big deal - because why would you ever turn that off - and also I can just read LeafParticleData.particleChance() from your mod.

Nonetheless, things like spruce needles spawning as commonly as, say, acacia leaves, really never sat right with me.

Same, I was kinda bummed Mojang went ahead with this as-is when people were complaining about conifer evergreens spawning regular leaves.

As for something like Mixin Squared, I’d personally argue against it as it isn’t part of fabric loader (at least currently.)
Typically extra dependencies will just make work more tedious, at least from my experience.

It's not that bad, it can be jar-in-jar included and will just work. You had to do this with MixinExtras too before it was included in Fabric Loader.
It is also very unlikely to break in the future, as the semantics of Mixin² won't change, it'll always just be a mixin into a mixin class.
(MixinExtras historically had some issues mixing old beta releases with newer releases because the injectors changed slightly in semantics - though it now has a forwards-compatibility system.)

What I meant with "stuff will surely break" is more the integration with your mod, like reading your spawn chances, modifying your stuff and all and not catching some NoClassDefFoundError / NoSuchMethodError.

What I do think would be a good enough solution (...) would be to use a mixin @at(“FIELD”) here, and make it always return false.

Ah, I thought I'd need to use Mixin² to be able to adjust the spawn rates, but that's all inside addFallingLeafParticles() as well, nevermind!

in all fairness I don’t know why else someone would install WW + your mod if they didn’t want your leaves instead- unless they’re using it for the automatic falling leaves on modded ones

That's what I'm trying to figure out, is there even any reason to use them both?
There's a few small / niche features here and there (like snowflakes, Seasons integration, turning wool blocks into leaf blocks etc), but other than that it feels like it's only relevant for modded leaves - and most biome mods are yet to release for 1.21.5, so it's hard to say if that'll make it worth.

Fourmisain · Answer 17 · 2025-04-08T10:03:08.000Z

Ah, what I was gonna say:
Don't try to fix ConfigDefaultsMixin, just remove it.
The FallingLeafParticleMixin is probably fine, looking at it from a glance.

AViewFromTheTop · Answer 18 · 2025-04-09T14:39:11.000Z

If you say young, I hope it's not that young 💀👮‍♂️🚓

Oof. I consider 13 young.
Even 18 is young for me and I’m 19, almost 20.
But 13???? And he was at least 20?

Ah, what I meant was that you could have modified LeavesBlock.leafParticleChance directly, or alternatively adjust only the frequencyModifier() to get the chances you want, so you don't end up having two separate spawn chances.

Oh. Eh….
I disagree. It maintains the readability of the config for users while also maintaining the differences in commonality.

I think there's an inconsistency with that: The maple leaves have a leafParticleChance spawn chance of 0, so if you turn "New Falling Leaves" off, they won't drop any leaves.

Strange..?
I don’t think that’s the case in 1.21.5.
If you turn them off, they should drop from their respective leaves the vanilla way.

Same, I was kinda bummed Mojang went ahead with this as-is when people were complaining about conifer evergreens spawning regular leaves.

Yeah. Awful decision. Even the spawn rate being the same is strange.

It's not that bad, it can be jar-in-jar included and will just work. You had to do this with MixinExtras too before it was included in Fabric Loader. It is also very unlikely to break in the future, as the semantics of Mixin² won't change, it'll always just be a mixin into a mixin class. (MixinExtras historically had some issues mixing old beta releases with newer releases because the injectors changed slightly in semantics - though it now has a forwards-compatibility system.)

Yeah, we were early adopters of MixinExtras quite a while before it got added lol. It just makes things clunkier honestly. We have our library mod embedded into our big mods which is enough. There are plenty of issues with the embedded version not matching the latest release, or embedded versions in other mods. If it’s not your mod that you’re embedding, it can get quite annoying to deal with the issues players will report sometimes.

What I meant with "stuff will surely break" is more the integration with your mod, like reading your spawn chances, modifying your stuff and all and not catching some NoClassDefFoundError / NoSuchMethodError.

The @pseudo annotation for mixins will ignore any classes that aren’t present at runtime. It’s very important for mod compat.
As for accessing it outside mixins, at least our Library frozenlib does something for that.
You can make a mod integration class. So, you’d have an abstract class, and have the class for when it isn’t present and class for when it is. Then it will load whichever one accordingly.
It certainly is doable, though making that system just for one mod on your end is… kind of silly.

Ah, I thought I'd need to use Mixin² to be able to adjust the spawn rates, but that's all inside addFallingLeafParticles() as well, nevermind!

ye!!!

That's what I'm trying to figure out, is there even any reason to use them both? There's a few small / niche features here and there (like snowflakes, Seasons integration, turning wool blocks into leaf blocks etc), but other than that it feels like it's only relevant for modded leaves - and most biome mods are yet to release for 1.21.5, so it's hard to say if that'll make it worth.

I didn’t at all consider that 1.21.5’s changes would lead to those mods adding their own leaves… which they’d almost have to.
Uh…
Well.
Still.
You have a thing with groups of leaf types that you can assign modded leaves to. With WW you have to add your new particle and chances, etc, through code.

Fourmisain · Answer 19 · 2025-04-09T17:59:37.000Z

But 13???? And he was at least 20?

Wow... Not only immoral but illegal too then! I hope he's been reported to the police.

Oh. Eh….
I disagree. It maintains the readability of the config for users while also maintaining the differences in commonality.

Fair.
In Falling Leaves I had the same question for 1.21.5 whether to let the user choose the precise spawn chance or a multiplier.
We used the latter for ages, but even vanilla has different spawn chances for different leaves now, so multipliers seemed like a no-go.
After thinking about it for a while, I ended up with a system where the (default) multiplier is calculated as the ratio of leafParticleChance over a base chance of 0.01, so Oak ends up being 100%, Pale Oak 200% and Cherry 1000%.
That way the "old" multiplier system could be kept, the user sees the a clear representation of the actual spawn rates, and there's no "duplication" of spawn chances.
(Up to the point where if a mod updates their spawn chances, this will also reflect in Falling Leaves - which can be considered both good and bad.)

If you turn them off, they should drop from their respective leaves the vanilla way.

Exactly!
And the vanilla spawn chance for the maple leaves block is 0.
It's set in the constructor of LeavesWithLitterBlock as 0F.

Yeah, we were early adopters of MixinExtras quite a while before it got added lol. It just makes things clunkier honestly. We have our library mod embedded into our big mods which is enough. There are plenty of issues with the embedded version not matching the latest release, or embedded versions in other mods. If it’s not your mod that you’re embedding, it can get quite annoying to deal with the issues players will report sometimes.

Yeah, depending on third parties in general is always a tradeoff.
They might stop maintaining the project (recently happend to me with BRRP), take long too update (Forge, but I consider that a good thing) and/or the project may contain bugs that won't be fixed (I ended up patching Cloth Config via Mixin).
So is the way of software engineering.

The @pseudo annotation for mixins will ignore any classes that aren’t present at runtime. It’s very important for mod compat.

Yeah, I've written metric tons of mod compats, though I never use @Pseudo because it'll log a warning in the console when the class is not found, so I use mixin plugins instead.
(Also I think you just pinged somebody 😄)

As for accessing it outside mixins, at least our Library frozenlib does something for that.
You can make a mod integration class. So, you’d have an abstract class, and have the class for when it isn’t present and class for when it is. Then it will load whichever one accordingly.
It certainly is doable, though making that system just for one mod on your end is… kind of silly.

Interesting.
Actually did something similar with Chat Heads where the config is an abstract class and it'll use a default config class when Cloth Config is not installed.
But yeah, in this case it'll probably just be a simple
if (FabricLoader.getInstance().isModInstalled("wilderwild")) hackTheMatrix();
and maybe a try-catch.

I didn’t at all consider that 1.21.5’s changes would lead to those mods adding their own leaves… which they’d almost have to.
Uh…
Well.
Still.
You have a thing with groups of leaf types that you can assign modded leaves to. With WW you have to add your new particle and chances, etc, through code.

Yeah, there's generally not a lot of reasons to have Falling Leaves anymore, except for the costumization aspect, that and I guess it works on any server (client-side Wilder Wilds when? 😄)

Fourmisain · Answer 20 · 2025-04-10T12:45:21.000Z

And the vanilla spawn chance for the maple leaves block is 0.
It's set in the constructor of LeavesWithLitterBlock as 0F.

Oh!
It also has an empty spawnFallingLeavesParticle() implementation.
I was wondering why I couldn't get it to work... 😅

You can extend TintedParticleLeavesBlock or UntintedParticleLeavesBlock so it uses the vanilla implementation.

Share to