[1.9.4] Inventory Panel Suffers Severe Delay in Large Storage Networks
praetoras opened this issue · 6 comments
Issue Description:
Originally I had opened this thinking the inventory panel wasn't working at all. I figured I'd best do this under a more appropriate issue, and I've closed the previous one ( #3420 ).
I have a large storage network set up with RFTools Modular Storage, each with a tier 3 module (300 stacks of items). I have a lot of them. I had set up a storage network using several rows with 144 of the storage modules each. There is a severe delay in the Inventory Panel showing inventory for the network it is attached to. However, I'll state right out of the starting gate I'm not sure if this is fixable.
What happens:
I placed different colored wool "markers" throughout the network and then checked the Inventory Panel. It took 25 minutes for all of the wool pieces to show up, and when moving pieces of wool around or putting in more wool, the delay was between 5-10 minutes.
Related: To try and get around the 'network lag' of one storage network, I attempted to set up multiple inventory panels, each on a different channel/signal to different groups of storage. However, I discovered that unless the conduits themselves were completely separate from each other (from the panel to the storage units) the panels still attempted to scan the entire network, and so suffered the same amount of delay.
What you expected to happen:
In an ideal world, the delay would be a lot shorter, at least short enough to work with the items normally. Unfortunately, that may not be possible. I may just be pushing the system too far. However, if it isn't possible to speed up the scanning of large networks, being able to consolidate conduits so that inventory panels only search chests with matching color codes would be nice.
Steps to reproduce:
Build a large network storage of any type. RFTools modular storage are good to use and were used in this example. A group of 144 units is usually enough to start demonstrating the delay (I had 6 groups of 144 originally).
Affected Versions (Do not use "latest"):
- EnderIO: 1.9.4-3.0.0.40_alpha
- EnderCore: 1.9.4-0.4.0.24-alpha
- Minecraft: 1.9.4
- Forge:forge-1.9.4-12.17.0.1965-universal
Your most recent log file where the issue was present:
No logs present - there was no crash.
[pastebin/gist/etc link here]
When I developed that system I put a cool down timer between scans which is based on the number of slots the scanned inventory had. The reason for that was to limit server lag.
Do you know how many inventory slots each of your modular storage blocks has?
Those he's using are upgraded to 300, don't know what the limit is. I thought about limiting the delay per inventory to a double chest equivalent.
Again, thanks for the replies guys!
Henry is correct - the modular upgrades let each storage unit contain 300 stacks each. I run a server for several friends, so I was trying to provide them with plenty of room
I totally understand the lag part, too. I went into creating this issue under the assumption it was likely throttled for performance. I wasn't sure if there was a way to adjust it or not. If there is, fantastic, that would be great. If not, I'll find workarounds. I still love the Ender IO system.
I might need to create a separate "issue" for this, but have you all considered adding any kind of "advanced storage"? I may type that up later.
yes, I actually have considered that. A storage with a couple hundred slots that can only be accessed with a remote awareness upgrade. Saves from having to sync that huge blob of data to the client. And it could be aware enough that it tells the storage network when it changed, reducing any scanning lag to 0.
May be clusterize the storage and cascade scanning? Some intermediate block that could watch over small subset of storage and be an instant reference for panel? Even reroute scans to keep data on chest with the most similar content in one place?
I'm probably daydreaming… x.x