Botania (Fabric/Quilt)

Botania (Fabric/Quilt)

5M Downloads

All crafted botania flowers are a target for comparators

jmeansta opened this issue ยท 3 comments

commented

Mod Loader

Forge

Minecraft Version

1.20.1

Botania version

1.20.1-445

Modloader version

47.3.0

Modpack info

No response

The latest.log file

https://gist.github.com/jmeansta/69fc7421c29a23d712801106f90032b1

Issue description

Functional and generating flora are targets for redstone comparator. This means that the red stringed comparator mistakenly binds to these flowers.
redStringBug
Shimmering mushrooms, mystical flowers, and glimmering flowers do not display this incorrect binding.
Floating flowers and flowers placed on dirt-like blocks display the same behavior.

Steps to reproduce

  1. Place a functional or generating flower other than the thermalily
  2. Place a red stringed comparator pointed towards the flower
  3. Hold a wand of the forest and look at the red stringed comparator. The "red string" and rainbow binding box should appear around the flower, indicating that it is the target of the red stringed comparator

Other information

This bug was filed in response to the following conversation on the Violet Moon discord server: https://discord.com/channels/154261184701267969/1079855089767952496/1274970503802785792

commented

Hey, If anyone here is a dev, I'm a new dev trying to fix this issue, so can someone tell me where is thhe red stringed comparator defined?

commented

The red-stringed comparator is not the issue, as the vanilla redstone comparator will also attempt to read a signal from flowers, even though a solid block. This needs to be fixed in the special flower block and block entity classes.

commented

I think the fix that would make the most sense would be a boolean constructor parameter on the three block type classes used by special flowers (FloatingSpecialFlowerBlock, FabricSpecialFlowerBlock, and ForgeSpecialFlowerBlock) that tells the block if it should advertise the availability of a comparator signal, since there's no block entity reference where that info needs to be available.
That's an (internal) API change, so not sure if that's something to change in the 1.20 version.