Skyblock Alternate solutions to hopper limits

Current Trend: /limits
∞ hoppers
128 hoppers
48 hoppers
....

If you want your players to avoid certain habits, then create new ways for them to accomplish their tasks. Encouraging fun play-styles is better than placing restrictions.

Sometimes you need restrictions to quickly fix a problem. But as the server grows, you're just going to need to continually reduce the hopper count per player.

New mechanics could be invented to reduce loads on the server.

Possible new items/interactions:
- Spawners placed on top of Chests, instantly drop mob's loot into chest. Reduces extra mobs, killing drops, and the pile of hoppers at the bottom.


- Hopper pipes: New item that instantly transfers items from a hopper output to end. Reduces the multiple ticks of hopper movements.


- Hopper or Hopper Pipe leading into magma block destroys output items. Reduces item clocks that drop items into lava.


- Linked Chests: New Item or command line augmentation that causes the contents of two chests to be the same. This would allow players to dump items into one chest and have them drain into a hopper off the other one. Reducing the need for hopper trains or the above mentioned hopper pipes.


I hope to see new items or interactions that increase player's ability to be creative while not bogging down the server.

Edit:
To explain a little more how these items would reduce lag. Each item reduces the number of calculations needed per tick, or reduces the number of actors spawned into the world.
These interactions certainly are not vanilla, but this server does already have a lot of custom formulas and interactions.
The end goal of most people's tasks involving hoppers is farming or selling. Creating more direct routes to accomplish these would be ideal.

 

These ideas are thinking outside the box and very well explained/demonstrated and thats really cool to see but I personally dont feel like any of these suggestions fit the "vanilla multiplayer skyblock" experience that this server seems to have tried to achieve over its lifetime.

Also, as I'm sure you are aware, to implement these suggestions, plugins would need to be made/coded from scratch or make use of potentially (probably expensive) existing plugins that would need to be heavily modified/strengthened to fit into this server. You would then have to educate people on the server about how these new mechanics actually work and how to use them etc.

So yea, cool ideas, probably wont happen, I wouldn't mind if it did though : )

 

I really love these ideas and you're correct they would help the server lag issues.

The only problem with the spawner on chests is on /economy people usually just want cooked pork since that can be sold therefore have big contraptions to make sure the mobs drop the cooked meat so then would still have a convoluted system to take the uncooked meat and cook it then store it but probably will still be less lag generating than the current system

That being said, an absolute support for this thread as it is very well thought out and poses actual solutions rather than the usual "OMG I need more hoppers, fix the lag" threads

 

Maybe people can make it got to a sorting system then from there to a chest room
I like the idea although most blocks are 1.9 blocks plus it would make it hard for people like me who use 1.8 versions

 

Thats the problem, the item sorters generate a lot of lag too

 

Im not sure if this would truly fix or change things as the primary function of hoppers is to move an item from container A to container B, essentially. This only would create more objects to do that, more limits on blocks, thus restricting others from using these blocks to simply build with them. No support

Note: the lag comes from the items needing to be accounted for and processed, mainly. This suggestion sort of intensifies that function. Good idea though, I'll give you credit where it's due. I love the creativity

 

Nothing is technically lag free. Any action done on the server requires the host to process it. While these new mechanics use up server resources, it isn't a lot and uses less resources than current methods.

Support for all except the linked chests, as this could potentially be exploited to duplicate items.

 

If something is doing a hopper's main function and then MORE, it is doing more than what a hopper itself can do, which would be more considerably problematic than the hoppers themselves. It's logical.

 

Good idea, and I support the hopper pipe and the hopper pipe to the magma cube one!

These ideas are pretty cool

 

Perhaps I didn't explain well enough. Hopper pipes would not hold anything.
They would instantly transfer all contents down the pipe. No Slow movement.

If you have a chain of 10 hoppers, and want to move a full 320 cobblestone from one chest to the end. Lets say 4 items can move on tick.

• Each Hopper Tick, 10 hoppers have to calculate what their first item slot is, then request down the line to the receiving location if there is room for 4 cobblestone.
• Just getting to the point where all the cobblestone is out of the original chest we'll have done (320/4) = 80 ticks of hopper calculations
• Then to get it down all the way to the end will take 10*(320/4) = 800 ticks of hopper calculations

Using the Hopper pipes would use 1 Tick of the hopper calculations to move the full chest contents. This becomes relatively even more efficient, the further it goes.

 

Neutral, I would like this but I don't know if this is possible.

 

Hopper pipes sounds like a good idea given that the main reason for hopper usage ( dont quote me on that) is transporting items across long distances by this i mean several hoppers going in a line to a chest or somewhere else

 

This deserves a bump althought it's sort of hard to implement and is less important than things like MA.

 

I would love to have hopper pipes. Before I say anything about code im a complete amature, that being said I would think that unless you get the pipes to function as one "large hopper" you would have the same amount of lag as just using hoppers.
I also love the idea of hopper into magma block would break the item, but I understand some players prefer to play on 1.8.9 and not 1.12.2

 

neutral, seems cool, but i'm not sure these are nessacary, also this changes item functionality I think

 

support awsome idea pls add this to game

 

The reason you can join on 1.8 on a 1.12.2 server is plugins, the ones we have support this change certain 1.9+ blocks when playing on 1.8 to 1.8 blocks, eg. BoneBlocks = quartz or shulkers = echests.

Support I like this

 

Pil why'd you bump this.

I see your thinking way outside the box - so far outside the box that some would consider this "modded" or "not vanilla". Skyblock was made to keep things vanilla as possible while also having some aspects that are... almost kind of necessary - like trade shops to prevent people getting scammed, except people still do get scammed with trade shops, because people rename items.

This just seems something out of <Big other server> and I wouldn't exactly like this, even though this appeals to me the least since I don't use grinders.

Just seems unnecessary - yeah I like your way of thinking to reduce the mob drops, but that isn't the main problem that causes lag on both servers.

 

Cool ideas man, they would add a lot of fun little aspects to play with
But to be more transparent about lag on skyblock.net/survival (eco is a little different)

• Block Ticking (order of lag): Water, Observer, Torch, Fire, Repeaters, BlockDispenser
  Block ticking currently makes up only 10% of the servers cpu time.
  
• Spawning mobs uses ~5%
  
• Entities as a whole uses 21.41%
  
• Managing out going traffic to all the players (Updating entities for them when they go in a new chunk, handling their movements, sending chat etc) uses 20.54%
  
• Managing network traffic from all the players uses 17.02%

So as a whole the biggest sources of lag is updating the player on the status of the server, with entities AI coming in second.

Fun Fact: Skyblock is running a custom fork of Paper 1.12, with via version to allow 1.8 - 1.15 clients to join

Fun Fact v2: Here is the lowest entity count I have seen for weeks but normally item frames is the second biggest