Networks only works when opening a chest
The plugin Networks only works when I manually open a chest. Items are not transferred or processed automatically in the background — it requires me to interact with the chest first.
Is this the intended behavior, or is it a bug?
9 Replies
I agree with that. I'm not sure if it's because the chunk wasn't loaded or if it goes into inactivity mode after a certain amount of time.
I use the plugin on one of my farms to quickly send fuel to an automatic furnace system. However, if the sorting chests fill up, the items accumulate in the input chest. At this point, it's unclear whether it's due to the chunk loading or simply the long inactivity, but if I empty the sorting chest after a while (~ 30-60 min), the items from the input chest dont get transported anymore. Only after I actively open the Input chest once.
As far as I remember, putting items in via a hopper or updating the chest block with for example redstone doesn't activate the plugin either. The player has to actively open it once. Then it starts working again on its own.
Checking repeatedly in the background heavily affects performance, that's why Networks only does this on certain interactions.
However, hoppers picking up or transmitting items also trigger this event, so it shouldn't be possible to achieve a state of an item staying in a container.
Something that might be the cause of this issue though is, when you transfer items over a long distance all matching output containers are inside unloaded chunks.
This can be fixed by enabling the option
performance.loadChunks in ./plugins/Networks/general.conf file.
By default, this is disabled, since constantly loading and unloading chunks is not great for performance.
What method of transfering items into the container are you using?
It does check for hopper transfers.
If a hopper points into an input chest, it goes into the Network instead.
Same thing if an Input Hopper picks up an item.
Does this not work in a specific Paper version?Paper Server: paper-1.21.4-114
Networks v3.1.3
All my setup is in two adjacent chunks, so no unloaded chunks blocking the chain.
I have some carpet dupers throwing carpets into hoppers. The Hoppers are connected to some input chests.
Like 10 Blocks away there are three sorting double chests only accepting carpets. After carpets got transportet into the sorting chests, I take them out using a hopper again. If the chunk is loaded for a while and the furnaces are shut off, the carpet chests fill up with carpets. No trash chests present. After the sorting chests are filled up the carpets stay in the input chest.
The problem occures when beeing afk for a while with furnaces switched on. So the carpets from the sortingchests are getting burned. But the carpets from the input chest stay where they are so the sorting chests will run out of carpets after some time
I do have to admit Im using a chunk loader Plugin named WildLoaders to load the chunks when im off. But if im not wrong the problem also occures without using a chunk loader. I could try that out if you want
SpigotMC - High Performance Minecraft Community
⚡️ WildLoaders ⚡️ Load chunks without alts ⚡️ 1.21.5 Su...
While being afk Im standing like 128+ Blocks up in the sky so the input and sorting chests are just out of range of the players radius. But im still in the same chunk as the chests...dont know if that makes a difference
Might it be possible, that the sorting chests temporarily fill up to their maximum?
If this happens, the item will actually stay inside of the input chests until a player opens the chest manually.
Hoppers pointing into input chests actually never interact with the chest but instead directly feed the item into the network.
So the Input Chest is not actually scanned after an item was transmitted.
I'll try out the specific Paper version later.
Sometimes a bug in a specific Paper version causes issues with this plugin that don't happen in other versions.
That is exactly what is happening yea. But if the Sorting chest is full, the Input chest fills up as well. If I then remove one Stack from the Sorting Chest, the input chest will send a mew one. (Only works of Input Chest was not full already) I guess the Hopper somehow activates the chest to also take the otems Inside of it. If its full already no activation is possible...
Sounds good. But if this Scenario is far off the Plugins intended behavior, some kind of work around would be okay as well. :) -> well i could ofc just dump the overflowing items from the input chest into lava so the system does not run full :/
I identified the exact behavior:
1. Create a Sorting Chest accepting for example white carpet
2. Create an Input Chest as well
3. Fill up the whole Sorting Chest
4. Add some carpets to the Input Chest
-> Input Chest can not send the Item to Sorting Chest
5. Remove a stack from the Sorting Chest
-> Input Chest will not send the carpets stored in it to the Sorting Chest
6. Place a hopper facing the Input Chest and add 1 carpet
-> Input chest will send all carpets inside of it to the sorting chest (if enough space ofc)
The hoppers input activates the Input Chest making it transfer all items inside of it + the one from the hopper, if possible. If the Input Chest is full the hopper can not activate it by transfering an item to it, resulting in the Input Chest being blocked until player interaction.
Maybe some other kind of activation action would be an idea. So besides a hopper transfering an item to the Input Chest a redstone signal or a block update in general could be the solution. ...but I guess checking for the redstone signal the whole time would produce the same overhead right? Maybe a new "Redstone" Wand type to de-/activate Redstone interaction with no interaction as default... :P
okay, that's actually easy to fix by triggering a sort event additionally to get rid of items inside
I just never thought of a case where this was necessary