Applied Energistics 2

Applied Energistics 2

137M Downloads

Capabilities are not fully supported (Dupe/Void Bug)

Speiger opened this issue ยท 4 comments

commented

Describe the bug

Forge has a Capabilitity system that allows to listen to so you get notified that the owner removes the capability for any reason.
Such as: BlockRemoval, Access Changes etc etc.

This feature is not supported by AE, which is actually required for better performance since you no longer need to access the chunk for every inventory interaction and instead can cache it.

How to reproduce the bug

public <T> LazyOptional<T> getCapability(Capability<T> capabilityClass, Direction facing) {

There is a example.
https://cdn.discordapp.com/attachments/936697574948237413/1018948660832247818/2022-09-12_11-17-37.mp4

Expected behavior

Expected behavior is that listeners to said capability get a notification if the capability gets removed for any reason.
Not Supporting of this feature causes 2 bugs.
A dupe/void bug since you effectively keep the original inventory and create a new one.

Additional details

No response

Which minecraft version are you using?

1.19

On which mod loaders does it happen?

Forge

Crash log

No Crash

commented

This feature exists since 1.16 so all versions till then have this bug.

commented

image
Just to point this out, since its relevant,
because you think something is not good in your eyes you won't fix dupe/void bugs.
Good to know.
And with that any support from my side is canceled

commented

The LazyOptional system is an over-engineered and unnecessarily annoying attempt at solving something that's not even been proven to be a problem by proper profiler data. Fabric's API Lookup API proves that the system is unnecessary. As such, I have decided that none of my mods will get support for it.

If you want to fix the dupe bug on your end, you can either query the capability every time you access it from the block entity, or listen to neighbor updates. These approaches both have sufficient performance, and the former while slower will always be correct, while the latter combined with LazyOptional listeners should handle enough use cases for it to be correct in practice.

commented

Nope, it stays that way. GL