Closed mfrankov closed 1 year ago
The same changes as outlined above, but for energyCapability
.
The same changes as outlined above, but for dustCapability
.
fill
. Given you returned 0 for !storedDust.isDustEqual(dust)
regardless of the simulate action, pulled that into the first test. Then pulled out the replicated computation around filtering into dustAmountPostFilter
. Finally folded together the simulate/not-simulate cases by pulling in the if (!action.simulate())
check into the appropriate blocks.The same changes as outlined above, but for fluidCapability
.
dustCapability
this was more involved in fill
given a lot of redundant checks being folded together. Also, like with dustCapability
there's a nuance in drain
where you need to copy what is being removed before calling shrink
(I added a comment this time as a reminder for the future).I wasn't as able to test the dustHandler
in my setup, but I tested this with a FluidPump
pedestal connected to a Drain
pedestal (each with just 1 work area below the pedestal, and confirmed if you transfer multiple buckets from the Pump
that the Drain
waits/buffers the extra fluid and later places it if you pick up the fluid sources from in-world).
IExperienceStorage
toBasePedestalBlockEntity
to reduce the need to interact withLazyOptional
s within your own class.LazyOptional
value toexperienceCapability
which is only used within thegetCapabilities
.sendExperienceToPedestal
to use theLazyOptional.map
method and a lambda function to make it perhaps slightly clearer to read.