Encoding items in Minecraft (2 of 5) - scaling up
Vložit
- čas přidán 21. 12. 2022
- This time, we use double-chests instead of hoppers as item filters. We also learn a new notation for long encoding schemes so that we don't have to write out hundreds of codes by hand. Lastly, we're introduced to the final problem of item encoding which we'll be solving next time.
Final map download: www.planetminecraft.com/proje...
Credit:
@DatNerd who got me into item encoders.
@_KK who made the font used to write out numbers with Minecraft blocks. - Hry
Wow, that scheme with cyan, magenta and yellow wool is actually so smart idea. I'm impressed how math and and imagination can work together and create so cool and useful things
17:55 this reminds me of Etho's approach with the Nexus, I think he had 256 items over 8 rows of chests, so he just assigned 3 bits for the rows and 5 bits to each chest in each row
similarly, you can have 8 of the 7-bit encoders for 10 bits in total, that way you can keep 90%
Etho once again somehow always years ahead
8:17 The number of stackable items in the game greatly depends on *how you count.* There might be about 800 if you donʼt count NBT, but then you get different-patterned banners, renamed items, *maps,* and *written books,* and you get I think more possible items than you could store if you converted your entire world to double chests of shulker boxen.
And sure, thatʼs extreme and you donʼt need to worry about all of those, but for any even remotely practical purpose, you probably need to worry about *some* of them (different ones depending on the server, of course, but renamed items, map art, and banner patterns are all relatively popular; for a contemporary example, what if you want to encode all of the cards in the current Hermitcraft seasonʼs card game?). To play it safe you need to handle the 0-token unknown code *and* leave plenty of room for expansion.
I like how the token-organized schemes have Pascal's Triangle built into them, like how the 4 bit code has a 1-4-6-4-1 structure
nice catch. there's a second connection too. The amount of tokens added to the filters by each section is also a row of pascals triangle. For instance with 4 bits, the 1-token/2-token/3-token/4-token codes respectively add 1/3/3/1 items to each filter (the previous row of pascals triangle). You can use this connection to search for optimal encoding schemes by searching through pascals triangle
A possible solution for the "54 item capacity" limitation of double chests could be to cram a bunch of entities into the same block. The TL:Dr is that you can shorten the machine to 10 filter slices using hopper minecarts. [Wall-of-text warning for below!]
At first I thought that chest- or hopper minecarts _won't_ work, because they'd snap to the rail below them - but it turns out they do. You just need to offset them far enough away from that rail, which I figured out while determining that *boats with chests* can also be drawn from by hopper minecarts. (More on the problems with boats in the bottom paragraph.)
The fact that you can overhang minecarts on either side of the rail means that the moving minecart can only draw from one side at once, i.e. the output signal won't be in binary any more. In fact, our stack of hopper-minecarts will pull from one(!) of several different double chests, and each of them can be its own digit value at the position of that slice.
4 double-chests per slice would offer the advantage that we are pulling through only 21.6 hopper minecarts crammed into the same spot, I.e. entity cramming will (hopefully) be no isssue. That means each slice gives its output as a base-5 digit (4 different "this chest" plus 1 "no chest" signals).
6 slices of those would mean that we are encoding our output as a 6-digit base-5 number where at most 3 digits are larger than 0. But that would require 113 items in each double chest.
What we _can_ do (if we are fine with encoding only about 986 outputs) is to use 10 slices with 4 chests for a 10-digit base-5 number where at most 3 digits are larger than 0.
And 11 slices (with 4 double chests) encode about 1114 (11-digit base-5) numbers.
The "draw-from-chest-boat" design has two problem. First, comparators can only monitor entity inventories indirectly, through their capacity to accept (or provide) items. And secondly the boat chests don't pull items on their own, and there are no entities that can push items into them. I.e. we have to push items into them with _blocks._ Luckily, both hoppers and droppers work. But the new bottleneck for detecting an item pulled from a chest boat will now be this pushing of items from non-crammable sources, specifically how many _different_ item types you can push into a chest boat.
You can again align 2 boats hanging over each side of the track, for a maximum occupied volume of 5*3*2, which you can push into through almost all faces of it's 6 sides, specifically from 53 *droppers* = 477 slots (which means you can make use of 17.67 crammed boats). I doubt that you can activate and feed items into all of them, but 477 is the upper limit. In reality, you'll probably want to keep the slice thickness down, so that you don't have to speed up your hopper minecart to over 5 blocks/second. With 2-block slices you can have 18 *hoppers* = 90 slots pushing from only 3 sides into 3.33 boats occupying 5*2*2 blocks. The problem with only having 90 slots in a 2 block slice is that double chests alone have 108 slots. And even though with chest boats the filter storage can't scale up indefinitely, they still easily offer more than 54 stacks per slice.
ooh, ive been waiting for this video, so excited to watch it!
thanks, hope it helped
6:35 it's a bit like how Rotary phone numbers work, New York has the phone code 121- because it'll take less time to dial and there's more people in New York
thats a great real world comparison
Since the fundamental limit of the amount of codes you can use is limited by the capacity of the chest could you just double the track and wire the other track into the same output and just use different codes on the second encoder so you keep the same amount of bits but double the amount of codes you could use so in the end you have two encoder tracks that go into the same output but have different codes in the chests Not sure if this would work but I think it should.
We're totally gonna do something like that for compressing the codes!
Totally hooked
Great lead-in and motivation for tackling the next problem
Incredible! Can’t wait for part 3!
holy moly! this reminds me what i love about math!!!
"concrete examples" that my good sir is wool.
The bigger problem I see here is if you want to input multiple selection one after rhe othernit will slow the process because you have to change items in the minecart every time...wath if we use a decimal encoder and imput direcly the number....maybe trougth lectern
Okay, the series are actually pretty interesting but what is the benefit of encoding the item on the run vs just having the code in some ROM?
You coud ad an and gate for two bits and basically make it so the chest is two times larger ? That way you could have a higher percentage of bit utilisation it seam ?
good idea. Turns out theres at least 3 reasonable ways to get higher bit utilisation and this is one of them
This locking with target blocks makes me think, shouldn't we have the same problem in the original design from the first episode? The minecart was passing over several hoppers with said item, and it could accidentally get two instances of the item pulled by one hopper...
the problem doesn't happen in the first machine because the hoppers and hopper-minecart only ever have enough time to pull out 1 item at a time. They're moving fast enough
@@whitestonejazz aahh I see, it's because with chests the hoppers are empty and could pull out items even when they shouldn't have. I misinterpreted the problem.
I don't know if you get to this later but I think I came up with a way of encoding 4000+ items, I'll share when I have something concrete
that will be great for storage tech
@@whitestonejazz I tried experimenting a bit and it's probably too cumbersome because it involves too much logic. The idea was to chain together multiple 64 bit encoders in a way that if you got any non zero output you would save the number as [number of iterations] [result] as two 64 bit numbers. You would only lose one number out of every 64. I also had an idea to use the same encoder with some kind of translation table to make it faster but I'm just not good enough at redstone for that. Maybe you can come up with a way to make all of this in a smaller space.
@@gnammyhamster9554 One thing that would be nice to solve too is an auto-filter loader. So some kind of device where you just fill up a single chest with your items and the auto-loader would assign each item a binary code and load it into the matching filters
@@whitestonejazz looking at your next video I realized my idea was very similar to your first design on video 3 but with the cart coming back when it got a result instead of doing through the whole thing. If you assign codes based on how often you need a certain items that design would be faster on more request items.
the tragic second act
well I tried. thanks for stopping by though :-]
I havent found a discord yet but you should make one if there is none
a discord for what? minecraft math puzzles? there's a storage tech discord already I found here: www.reddit.com/r/technicalminecraft/comments/m4mb1z/technical_minecraft_discord_links_technical/
@@whitestonejazz yeah I ment more tailored to your typical math puzzles and more channel centric