Dereffered item/fluid storage usage?

[SirEdvin]

So, as part of my CC:T add-on development, I usually come across strange bugs, like this one.

The main issue is that the multi-block tank actually refreshes on the first tick of the game, rebuilding fluid storage. Which causes strange issues in cases when peripherals are built for dummy fluid storage, which gets replaced. Ideally, this kind of issue should be solved by sending block state updates, but since there are no block state variables, there are no block state updates.

What I can do is use a dereffered strategy in such cases, and instead of caching storage like any generic peripheral does, I can always get fresh storage from blocks.

But the question is, should I do so, or can this be considered a bug in another mod?

[SquidDev]

Oh no. Computers not updating peripherals has been a very long standing issue, and I can't say I'm thrilled to see it again.

The problem with re-fetching the storage for each method call (which is what I think you're proposing with the deferred strategy) is that the storage may change types (or vanish), which then means your methods no longer work - Plethora used to suffer from this a lot. I guess it's no worse than the current problem of operating on an invalid storage though.

It might be worth opening an issue on Modern Industrialisation issue tracker asking if they'd be willing to fire a block update after the multiblock is formed.

We could also hook into comparator changes (which we do on Forge), but it doesn't look like MI supports comparators on fluid tanks, so not sure how helpful that'd be.

Strictly speaking what CC:T does (caching the storage) is wrong, but also unavoidable with the current peripheral system. Ideally Fabric would adopt an invalidation system like Forge has, but not sure how likely this is.