Skip to content

Fix proxy not updating core being removed or disconnected - #56

Closed
DayBr3ak wants to merge 1 commit into
LITW-Refined:masterfrom
DayBr3ak:fix-multiblock
Closed

DayBr3ak wants to merge 1 commit into
LITW-Refined:masterfrom
DayBr3ak:fix-multiblock

Conversation

@DayBr3ak

@DayBr3ak DayBr3ak commented Apr 9, 2026

Copy link
Copy Markdown

Should fix #53

@Pilzinsel64 Pilzinsel64 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fine with this approch, to be honest. But I don't know another good and working way at the moment...

First of all I don't like the Storage Core to reference the Inventory Proxy. But When breaking the sotrage core, it already notifies its nieghbors (if I remember correctly).

Any storage block (probably StorageMultiblock) should overwrite something like onNeighborsChanged and listen (I hope this was for Blocks and not only TEs). If their neighbor is part of the storage network, then validate the connection again (if required, only for proxy and panel, e.g.) and notifiy all it's neighbors too (e.g. by marking as dirty or if there is a better way).

Second, EZStorageMEAdapter should cache the EZInventory object when it checks for null and then use it again in the next lines. This avoids duplicated .getInventory() calls. Like TileEntityInventoryProxy is doing it already.

What do you think? Do you want to try this approche, if it works?

@DayBr3ak

DayBr3ak commented Apr 10, 2026

Copy link
Copy Markdown
Author

I can't really figure out the subscriber thing with how it's done, sorry

Up to you if you want to merge it or not, but I'm not sure I want to spend more time on this

What has been done:

Now when the multiblock is updated, and especially when a connecting block is broken, we identify all possible multiblock group instances.
The groups containing a core update themselves like before, the groups containing no cores but a proxy, clear themselves of the core reference

@Pilzinsel64

Copy link
Copy Markdown
Member

Thanks for this! Going to try a bit around this weekend using your code as reference. I'll let you know the result. :)

Pilzinsel64 added a commit that referenced this pull request Apr 10, 2026
@Pilzinsel64

Copy link
Copy Markdown
Member

Tried my luck in #58, but didn't tested it yet. I need to get out of the forest to have a better overview what I eventually missed or is not required. Will review & test it tomorrow probably.

@Pilzinsel64

Pilzinsel64 commented Apr 28, 2026

Copy link
Copy Markdown
Member

Closing, the other PR has been merged. But to be honest, it still needs some more tests for Proxy & ME adapter. Just didn't came around yet. Feel free to test the changes from master, if you want. I apprechiate any feedback.

Thank you anyway a lot for your contributions! They are really great. 🙂

Also closing this, GitHub hides this PR for me for an unknown reason anyway, I would never find it again... 🤦‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Breaking connection between the core and the proxy keeps the proxy connected "wirelessly"

2 participants