Falling Leaves (Fabric)

Falling Leaves (Fabric)

22M Downloads

How could I make a custom block drops leaf particles?

Closed this issue ยท 6 comments

commented

I'm making a custom leave. It has the tag #minecraft:leaves but the mod doesn't seems to reconize it as a leave block and no particle is generated. How does the mod decide what is a leave block?

commented

While the mod does check the #minecraft:leaves tag as well, in practice, the block needs to be a subclass of the LeavesBlock class, so that randomDisplayTick is called (see LeafTickMixin).

The mod does have an experimental setting that allows dropping leaves from any block, called "additional block states that drop leaves", where you can put your concrete block id like yourmod:block_id and after a restart of the game, it'll drop leaves as well.
Though, this is something only the client/user can configure, so it's only useful if you're building a modpack.
(This feature isn't used by default because of performance concerns.)

commented

P.S:
I think it's also possible to call LeavesBlock.randomDisplayTick from your own randomDisplayTick without your leaf block actually being a subclass of LeavesBlock.
Terrestria is a mod that does this if I remember correctly. (Because subclassing LeavesBlock can cause some potential compatibility issues if you're e.g. changing the leaf "decay reach" or whatever it was called that is usually a constant of 7.)

commented

Oh, great, happens that I'm focused on a modpack rather than a mod, so the config could suffice.

However, is it not implemented for 1.20.1?

commented

I added that feature early 2022 in Falling Leaves 1.9.0 for Minecraft 1.18.1, so it's definitely in 1.20.1 as well.
The name in the config file is leafSpawners (a set of block ids, with optional blockstates), you find it as "additional block states that drop leaves" under the "experimental" tab in the Mod Menu config screen.
It was specifically added because of this request of making wool/glass block leaves work (also have a look at that Reverse Tree ๐Ÿ˜…)
I'd still not recommend using the feature unless you absolutely have to - enabling it will cause all blocks in the player's vicinity to constantly check if they should spawn leaves, negatively affecting performance.

I'm also confused, how do you add a custom leaf if not through code?
If the block is not your own code and you cannot subclass LeavesBlock, you may still be able to add a custom randomDisplayTick method on the block's class which calls LeavesBlock.randomDisplayTick through a mixin.

commented

I am adding through code (tho KubeJS), however I can't extend the vanilla leaves class because of a render issue I'm having with Sodium + Polytone (Sodium seems to have an optimization for leaves involving mipmappings that causes Polytone animated textures to not look good). That's why I'm having to create "fake" leaves blocks that aren't part of the vanilla leaves class.

The config makes the client check all blocks, even those not added? If so, yeah, I definitely won't use it D:

I'll try what you suggested and add a LeavesBlock.randomDisplayTick call.

commented

The config makes the client check all blocks, even those not added? If so, yeah, I definitely won't use it D:

Vanilla does actually call Block.randomDisplayTick on all blocks by itself already (2x666 times per client tick), which will call LeavesBlock.randomDisplayTick polymorphically.

In vanilla Block.randomDisplayTick is an empty method and enabling Falling Leaves' leafSpawners feature will add at least add a registry lookup (to get the block's id) + a Set.contains check to it.

I haven't actually benchmarked the impact of that, or at least I can't remember if I did.
If I did, it definitely wasn't an exact science - benchmarking a GC'd and JIT'd language is hard.
It's definitely possible that it isn't as bad as I thought - it might even barely have any impact on performance.
I just assumed that the fact that Block.randomDisplayTick is an empty method might mean that stuff could potentially get JITed out and barely cost anything, whereas that couldn't be the case when using leafSpawners, hence I gated that feature behind an optional mixin.