What To Do Next?
LemmaEOF opened this issue · 11 comments
Woo, the Bithop version for modjam is complete! There's one more desync issue (#2), but it won't be seen often for the bithop's main purpose, and I'm gonna keep poking at it in the background. update: sync issue fixed! Let's see what there is to do next:
- Sideways hoppers
- No sideways bithops, not really needed; these are just gonna be for single-block transfer, kinda like a translocator
- I wanna have big upward movement of items be a bit of a challenge (more on that further down), so I'm gonna put in some safeguard to make sure that sideways hoppers either can't have items pushed into them (they can only pull) or they can't push into other sideways hoppers.
- Hoppers with filtering
- I really would like to have this sort of thing be closer to vanilla, so I've been thinking of having them be "sticky" hoppers; hoppers that will never push out the last of an item stack they have. Then you can do the vanilla Minecraft filter thing of having a filter material (like anvil-named items) that will never go through the hopper, and so you can have up to five items filtered. Not gonna work for non-stackables, but I honestly think I like it that way.
- Low-lag upward movement
- In vanilla, it's tough to send items upwards. In vanilla 1.12.2, you've basically only got droppers or slime pistons. I kinda wanna keep the difficulty/needing to create something interesting to do it, but I do not want the server impact the vanilla methods have. 1.13 is adding water streams, but those still have lots of entities. I wanna see what I can do with TESR and stuff to have good upward mobiliy systems.
- More?
- A user on curseforge also asked for a low-lag hopper that still pulls from inventories above. I think adding a hopper that only interacts with TEs and not entities would be neat to add.
- @alexbobp had an idea a little while back for what they called a quantum hopper: a hopper that only fires with a 1/64 chance or something similar, but when it does fire, it transfers a whole stack at a time.
- Of course all of these are gonna need distinct, distinguishable models and textures. That might be a bit rough, so I'll see what I can do.
Give whatever feedback you can! Thanks!
Oh, I had an idea: fluxhops! Hoppers that transfer both items and RF. The RF is under the same transfer rules as items, as in no upward movement and only every eight ticks, but the rate would definitely be configgable. Maybe there would be higher tiers and stuff, but maybe not. Lemme know what folks think!
Tiny Issues and more improvements:
Issues:
Syncing the entire inventory is totally unessesary since its not visual. You increase network usage by a lot when doing that.
Checking the TileEntity every time when to send items.
Improvements:
Cache the TileEntity and remove the cache when it invalidates or the representing chunk unloads/isUnlaoded.
Not sync the entire inventory. You dont even need to sync anything since its blockstate based.
fluxhops in their main form are done! I might add upgrades in the future. we'll see.
Maybe add configs to disable certain items? The fluxhop doesn't fit the pack I'm working on (it's a heavily magic based pack with very little tech stuff).
Hmm. That'd need a good amount of rewriting of how registry stuff works, but it could be done. V2.0 is gonna have a big rework of how all the different hops exist, so that might be easier to do.
what about tightening the selection box around your hoppers? diet hoppers does it for the vanilla hopper but they didn't do it for yours (obviously).
@Boundarybreaker