-
-
Notifications
You must be signed in to change notification settings - Fork 507
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Dandelifeon to respect enchanted soil #4660
base: 1.20.x
Are you sure you want to change the base?
Conversation
I feel like the enchanted soil status should probably have an effect on the boundary cell check somehow, but I'm not sure if the adjacent flower also needs to be on enchanted soil, or if otherwise boundary cells from non-boosted flowers should just be ignored. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See code comments. Functionality-wise it looks good to me, though.
Xplat/src/main/java/vazkii/botania/common/block/block_entity/CellularBlockEntity.java
Outdated
Show resolved
Hide resolved
Xplat/src/main/java/vazkii/botania/common/block/flower/generating/DandelifeonBlockEntity.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment in code. Also, please rebase onto current 1.20.x
branch head to fix the dependency issues with VanillaGradle.
Xplat/src/main/java/vazkii/botania/common/block/block_entity/CellularBlockEntity.java
Outdated
Show resolved
Hide resolved
8633982
to
ae52012
Compare
c21f015
to
d43da4c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
public boolean hasPoweredParent(Level level) { | ||
return flowerCoords != null && level.getBlockEntity(flowerCoords) instanceof DandelifeonBlockEntity && level.hasNeighborSignal(flowerCoords); | ||
public boolean hasActiveParent(DandelifeonBlockEntity dandie) { | ||
return flowerCoords != null && dandie.getLevel().getBlockEntity(flowerCoords) instanceof DandelifeonBlockEntity parent && dandie.getLevel().hasNeighborSignal(flowerCoords) && (!dandie.overgrowthBoost || parent.isOnSpecialSoil()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This or-check at the end is weird to me. It's true if the flower it's being transferred to is not boosted, or if the current flower is boosted. (Did i get that right?) So this returns true when both are boosted or neither are boosted, and false if the old flower is not boosted and the new one is. But if the old flower is boosted and the new one is not, this will still return true, right? Which we don't want, right?
It would also be nice if these variable names better reflected which flower it's coming from and which flower it's going to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is always called by the new flower, so we only need to make sure that either this is a normal tick (we aren't in an overgrowth tick), or that the other flower is also enchanted, and therefor will tick as well. This means that adjacent flowers will only share cells on ticks where they both are ticking. If the old flower is boosted and the new one isn't, then the new one won't be ticked, so this will never be called, and thus the return value doesn't matter.
Fixes #4405