Filtered Hopper Better With Mods
Hoppers in and of themselves do not create significant server lag. Only uncovered hoppers create rule-worthy lag.
Better With Mods Wiki Minecraft
The lag is not being caused by the item-moving code of the hopper blocks. The lag is being caused by the search-for-item code only on uncovered hoppers. When the top of a hopper is not covered by a block-type having an inventory slot (so that the hopper will switch to pull-from-container mode), the hopper block constantly checks the block above it for things to suck in.
Solid blocks (non-inventory-slot blocks) don't toggle the hopper mode.In respect of 'hopper lag', we currently have an informal rule (per Rodzyn on in-game chat) of about 5 hoppers in length for a hopper chain. However, we're still seeing an escalation of server lag as we build out the map. Looking into it briefly, I find that limiting length of hopper chains is not going to help us, as is shown in this recorded test. Furthermore, one of the most common reasons to build a long hopper chain is not creating significant hopper lag:A hopper-driven inventory sorter creates hopper lag only on its top row of hoppers, and that can be fixed with inventory slot blocks, per Accidental Gaming's demonstration. Simply place furnaces on top of the hoppers on the top row, and the entire mechanism will be relatively lag-free. A single-hopper chicken egg machine is probably creating more lag per-machine than any item sorter would do (if all of the item sorter hoppers are covered properly), because the sorter is effectively the same structure as an auto-furnace, and its redstone circuit is nearly always emitting no signal.
The player placing items into a sorter or furnace 'input' chest is the same as the player toggling an on/off switch.If you feed the server's region files into the blockfinder tool, looking for hoppers, you'll probably find much of the ongoing lag problem: instances of uncovered hoppers, increasing over time.Make it a rule to put 'inventory slot' blocks on top of hopper chains, and discourage uncovered hopper machines instead.Gamepedia Minecraft Wiki has, showing that 'activated hoppers' are the problem, and if you understand what 'activated' means in this context, it matches with the rest. Covering a hopper with an inventory-slot block deactivates the hopper until an item is in the neighbor block's inventory.
Thusly-covered hoppers are essentially lag-free because they are rarely activated.Edited October 14, 2016 by AllOfMyNope. That's very interesting and helpful research. I wasn't aware of that difference between 'activated' and 'deactivated' hopper, from now on it will be like you suggested, amount of hoppers won't be big issue as long as they're all properly covered with inventory blocks.Main reason I opted for low hopper rule was to keep it down to reasonable levels, single person might not be able to cause significant lag but having dozens of people putting dozens of hoppers piles up. However as shown at the video, as long as hoppers are covered, you need really huge numbers to make it a problem. Main reason I opted for low hopper rule was to keep it down to reasonable levels, single person might not be able to cause significant lag but having dozens of people putting dozens of hoppers piles up.Definitely; I agreed and left it at that until someone on in-game chat mentioned the furnace thing.
Filtered Hopper Better With Mods
Google showed a reddit thread and that video. That left me to wonder if the server's unique player count isn't high enough for permanently activated hoppers to accumulate over time as people craft them for normal open-topped hopper purposes (they're ostensibly allowed about 5 of those). That's at least 1:5 of player:hopper, and we can count on some people building none while others build more than 5 and hide them in the world.That's where the blockfinder tool comes in. This was updated last month. Some thoughts as I read it:Feels like Xel already lowered merge-radius.I know item-despawn-rate is higher than 1 minute, and agree that setting that aggressively low will also require keep-inventory to be on (therefore lowering risk and difficulty).
Yet, Minion Land is already effectively a build-only server, so assuming that in a BungeeCord setup you have separate config for each linked server, just let Minion Land (the big laggy one) have that, and let Far Lands be the riskier map.Our view-distance is at 10 (I think), and that's already too low for preference, so maybe that's the big lag we just live with.Entity-activation-range is already fairly low; low enough to break most mob farming attempts.Wiki author is unaware that ticks-per hopper-check isn't in play, or they're running a. If what's shown here (it's for 1.8 version of Minecraft) then placing furnaces might actually be counter productive.
At the same time it shows that hoppers even in their active state should not be significant culprits in lag situation.I don't know our current settings in spigot.yml but I already had in mind taking interest in max-tick-time setting. I took a quick peek at my config for Stivarstead and apparently I had it set to 1000. Can't remember why I had it set so high, if that's the default or suggestion I picked up but if that's default and Xelphos didn't change it then it's way higher than suggested values. If what's shown here (it's for 1.8 version of Minecraft) then placing furnaces might actually be counter productive.
At the same time it shows that hoppers even in their active state should not be significant culprits in lag situation.I don't know our current settings in spigot.yml but I already had in mind taking interest in max-tick-time setting. I took a quick peek at my config for Stivarstead and apparently I had it set to 1000.
Can't remember why I had it set so high, if that's the default or suggestion I picked up but if that's default and Xelphos didn't change it then it's way higher than suggested values.Good catch with this video. That extra TPS loss in Spigot 1.8. for covering (what was that, 250,000?) hoppers with an inventory block is surprising. Hopper lag is still present (with a much higher ceiling on hopper count) in large Spigot servers, and the Internets hath lead me astray on the furnace thing for Spigot.
Glad you found the video, cuz I felt like we'd either have to test it ourselves or assume that Spigot referenced Vanilla for what lead to that quirk in Vanilla.I still wouldn't take from that demonstration that hoppers are insignificant across the lifetime of a server. They get built for a purpose and then left behind to tick away at nothing. It's an overhead problem. Video shows that Spigot at c. I know for a fact that Xelphos set container checks to be 3 times less frequent and to balance it made hoppers move 3 items at a time. Those settings would make the lag gap between active and inactive hopper even more noticable.Sorry to necro the thread - but I've been racking my brain for the past two days trying to make an auto-shop design work on the Farlands.The setup mentioned could finally be the explanation I've been trying to find.The design I'm using is supposed to do a 1:3 ratio transaction utilizing a simple dual hopper filter system. Somehow though for every transaction the lower hopper would pull 3 instead of one item, kinda ruining the system.
Stoked Kiln Sevtech
(filter setup: 18/1/1/1 filter with a comparator sending a signal for any additional items defined by the filter, activating the pulling hopper for one check then locking up again - it keeps depleting the filter to 16/1/1/1 though instead of the expected 18/1/1/1).Do I understand that correctly? And if so - is there a way to adapt? Or am I stuck with making my shop's 'cost' in multiples of 3?Edited December 19, 2016 by BobBungle.