The End of a Journey - Level 1000

[IridiumMika]

I did it. I reached the end of the game and there are no goals left, no numbers to produce.

https://steamcommunity.com/sharedfiles/filedetails/?id=3324646081

Along the way, I discovered some incredible powerful mechanisms to exploit to automate everything that was theoretically possible. Namely the devider with its 2 outputs and its handling of zeros.

In the end, I just had to flip some priorities to trigger a reset of my sequencer and reconfigure one belt for each digit of all visible future level numbers feeding into little MAMs, once, and nothing more.
When the time is right, the squencer injects a fixed amount of the next level number into a self-fed infinite duplicator, which feeds into the 23x main duplicator array, to produce the next 400k or so numbers, until the next injection. Fully autonomous, until the list of visible future numbers for that iteration has run out.
This meant the game progressed by itself, after each necessary manual reconfiguration, for several hours for the next 13 or so levels.

The one thing I didn't find a solution for was a prediction formula for the sequence of level numbers itself. I suspect the last 5 digits are random?

I want to share all the technology I developed during that journey with you. So here is the save file (on imgur aswell):
{LINK REMOVED}https://www.mediafire.com/file/k76oqvi5w4j8i65/BeltmaticLevel1000Setup.zip/file

And here is an album of all the critical components and an overview:
https://imgur.com/a/beltmatic-level-1000-setup-sCHTHHb

How far along are you on your journey?
Did you invent some special or complex things yourself?

[Citizen10Bears]

I'm quite new to the game and am a) shocked there are 1000 levels and b) overwhelmed by the complexity of your "machine"!

[IridiumMika]

True motivation through fun leads to many little discoveries after enough time.
Some useless, some powerful. And sometimes, they can be chained and scaled up to achive something seemingly impossible.

Like the smartphones we have, built on layers upon layers of little discoveries, scaled up to new industries, permanently optimized, to produce a glowing and thinking crystal slab, powered by bottled lightning. Our Magic.

The same can happen here in this game, there is no limit to the possible complexity besides the size of the construct.
And since you have learned, invented and built all of your own creation, you understand it, as long as you play with it. Some inventions are necessary to massively boost the ability to progress, so many people recognize this and create them on their own.

Like MakeAnythingMachines.

Some other things seem impossible until more obscure features have been discovered and recognized as a key to a solution, like number duplication by exploiting the divider outputs and a preparation pipeline by math while circumventing the 32-bit limit of the numbers.

Then there's a whole chapter of discoveries counting on the 0-math of the divider.
Getting both input streams back out, you are able to link their flow rate and therefore making them both dependent on each other. Now you have some kind of controllable switch or valve. Directing one stream in series through a divider chain, the other though the same dividers in parallel, one 0 travelling through the whole chain can let through as many numbers of the other stream, as you have chained dividers.
Now you have an amplifier. Like a transistor.
Scale and connect them in the right ways, you can theoretically achieve Turing Completion. A computer. But that I didn't try.

I used amplifiers to count the amount of seed numbers to inject into the infinite duplicator and then count the time until the next injection, forming a programmable sequencer. One tricky thing was the reset circuit to work as a NOT gate in respect to the input stream of each counter module, to activate a pump-back of 0's into the start configuration.

The infinite duplicator is a MAM, but instead of manually configured input belts, it get's its configuration by a seed number injection. As a duplicator, instead of just spitting both numbers out to somewhere else, one copy gets recirculated back to the input, forming an endlessly flowing loop. The second copy is the infinite output stream.

The main duplicator array are just castrated duplicators, chained together. The 32-bit limit makes them 3 times bigger because they have to copy 3 separate sections of the level number in parallel to stay below the billion mark after the digit duplication step.

limit: 2^31=2147483648
hypothetical number to be duplicated: 12 3456 7890

section 1:
digit duplication: 12 * 10001 = 120012
split: 120012 / 10000 = 12 Rest: 12

section 3:
digit duplication: 7890 * 10001 = 78907890
split: 78907890 / 10000 = 7890 Rest: 7890

with no limit:
1234567890 * 10000000001 = 12345678901234567890
12345678901234567890 / 10000000000 = 1234567890 Rest: 1234567890

[Hefsgaard]

Excellent work!

[IridiumMika]

Thanks!

[michaeljhuman]

Speaking as a software engineer, I will (a) admit I didn't fully understand your machine, but (b) It looks like you managed to inject logic gates into a game without dedicated logic gates. Looks very cool. I admit I am lazy, and so far I am ok with a simple base 10 number creator. But I can see the appeal of your level of automation.

[IridiumMika]

You are correct, there is a mix of a gate/signal concept, and partly also used as a current/transistor/capacitor concept. The counter modules contain a kind of NOT gate sensing the input current, a capacitor, feeding a transistor, which switches the input current to the output line, forming an AND gate, until the capacitor is drained. If the input current switches off, the NOT gate activates the charge-up of the capacitor via the clock at the top as a souce and a second transistor. Something like that.

[Lord Balder]

Very impressive indeed! This post got me back into the game, although i will not attempt to go for the max levels. That sounds absolutely mental! Level 100 is enough for me! 😉

I keep looking at your images and the longer I look the more I understand. The level number MAMs are very interesting. I like how compact they are, especially the number 9 calculation! However, this looks very slow, especially if there are multiple same digits... Well, Im not sure. Your example number has three 2s in it and the output does not seem to be too empty! But I would assume it looks different with nine 9s in a number. This is the reason why I prefer binary numbers. I always need exactly 31 bit and can just enable or disable them without worrying about special cases.

How long does it approximately take to get the first new number after reconfiguration? You used lots of storages, so I guess the remaining numbers will have a quicker start thanks to the full storages. But I could imagine especially an unconvenient first number takes forever. After all, the main array feed cant create numbers out of nothing and is depending on those initial numbers from the injector...

The idea of duplicating however is very clever! I will try to copy that approach and check how much smaller my MAM gets with that. I was about to point out that its better to keep the sections instead of joining them together each time, but then i noticed that you did exactly that in your main duplicator arrays. 😁 That saves like half the computing time! What I will add is denying the 31st bit and then split my numbers into only two sections of 15bit each. That reduces the calculation even further and I can still cover numbers up to a billion, which according to your level 1000 screenshots is more than enough to max out everything! 😎

One thing I still dont quite understand is the level sequencer. Those dividers are too nested for my brain to understand! 😵😅 How precise can you set up your target count? Is it always 480k or is there a way to reach smaller amounts, too? I saw a limit config label in one of your screenshots, but I have no idea what to do with that. 🤪

Still, once again: great job! 😤

[IridiumMika]

Thanks! You show great insight into my creation! There are some aspects which are not easily understandable or even visible, if one didn't go through the long but motivating process of iterating and optimizing again and again until there isn't anything left to accelerate reaching the next goal.
After around level 100 (?) when all upgrades where done, it got tedious and the end goal and the requirements to get there where completely unknown to me. So my new goal was to create a system, to fulfill ANYTHING the game is able to require, concerning a single level number, with maximum performance and minimum manual work.
So I assumed a requirement to create any number between -2^31 to +2^31, since I tested for those limits before. Before, I had a MAM for each of the 24 belts leading to the hub, but each of those MAMs had to be configured separately, manually. This would have meant that for each level-up I had to reconfigure 24 MAMs by deleting and pasting the digit input connections 23 times manually, after building the configuration for the first MAM. I couldn't have that! I'm lazy! :D So the need for a duplication module was born, and thank god the math works! At first I targeted something to duplicate single digits X * 11 -> XX / 10 -> X + remainder X, and got it working. But the application for 24 existing MAMs as a digit input with its belt salad was unwieldy.
The solution I recognized was that it could be generalized for multi-digit numbers. Because of the 2^31 bit limit, a module can maximally duplicate numbers up to 21474 (*100001), so I chose 9999 (*10001) as section size limit.
So the "MAMs", if you can call them that, worked not with up to 10 single digits, but with up to 3 numbers, each up to 9999 as "configuration inputs". Same system, but 3 instead of 10 corresponding calculation pipelines.
Smaller faster, easier to set up, nice!
Since I didn't know what the game will throw at me, and because I already had to tediously upgrade my MAMs to bigger numbers before, I designed the full duplicator to work with anything the game itself could. It could even work with negative numbers!
This is why each duplicator is a combo of 3 modules instead of 2, because maybe there could have been a level number up to the integer limit.
Level numbers exponentially rising with late-game integer overflow into the negative would have made sense for me, looking at the minecraft far lands 🙂

Concerning the slow mini-MAMs in the context of startup wait time after reconfiguration...
That, the big MAM on the left below the sequencer is for! The one with the double belt ring with quadruple digit availability to configure it.
This one is for the speed and flexibility to (almost) instantly inject a new number into the infinite duplicator. But those full-speed MAMs are a pain to connect. So I created and optimized mini-MAMs, which just need a "2"-Source and a "10" Source.
To set a new one up, just paste it onto a "2" and connect two other soruces able to add up to "10". Done in less than 1 Minute, comparing to like half an hour to connect a full-speed MAM to all the required number sources.

1. configure the big MAM and let it inject directly into the infinite duplicator to get productive again as fast as possible

Clean-up and reset:
2. reroute the sequencer output and 0-counter input (the "5"-source on the right) into trash modules (self-looped subtractors with one module input)
3. the missing 0-counter input triggers a full reset of all 0-counters, meaning the configuration storage content gets pumped back into the start configuration, which takes a while
4. all the mini-MAM configuration belts have to be deleted, stopping the input flow of past level numbers into the level number counters, triggering their reset aswell.

During that, there is quite a bit of trash flowing out of the sequencer output, that's what the output trash rerouting is needed. Since the infinite duplicator is isolated and fed via the big MAM, the present level numbers are already in production in the main duplicator array during that time.

5. After the sequencer reset has finished, I had to remember to switch the routing back to production! I forgot multiple times!😅 Whole next sequence wasted...
6. Cut the sequencer output belt to block sequence start until next level-up and when ready.

Sequencer start-up:
7. Reconfigure the big MAM and reroute to first counter of the sequencer. Simultaneously the "0"-counters (bottom row) are already busy to fill buffer storages for their turns. They are fed sequentially: when the first counter finishes and blocks, the overflow goes to the second counter to begin counting and filling, while flowing though the first counter's "input sensor" at the top to prevent its reset.
8. sequencer limits the level number injection amount via the counter module (top row) to around 1300, after that the counter blocks and input overflows into the trash next to it.
9. during this time, I can built all the configuration belts of the next 12 level numbers on the mini-MAMs which begin to slowly send their newly configured future level numbers into the sequencer
10. when the first level-up happens, I can reconnect the squencer output belt to start the sequence with the first pre-counted injection
11. sequencer switches to "0"-output (which gets filtered down the line) to wait for the next level-up
12. like with the first counter, the respective counters let the desired amount through, but since the sequence is runnung from right to left via priorisation on the output belt, the future level numbers are blocked by the flow of "0"s and fill storages instead to wait for their turn
13. when the level-up time has passed, the first "0"-counter has finished and its buffer run empty, the flow of "0"s stops on its output, and the now empty space on the main output belt fills with the product of the first mini-MAM. The time until this happens is more than enough for the mini-MAMs to generate the necessary amount of at least 1000 numbers for the injection.

The counter configuration storage on the top row has 80 "0"s with would let 800 numbers through via the dividers, but there are more "0"s on the belts around, so that it results in 1365 level numbers actually in this case, ready for injection. Plus the contaminated crap in the snaking belt below the storage, stemming from the reconfiguration of the MAMs.

I think the game requires 500 more level numbers for each new level reached.
To fulfill this rising production amount and wait time, I had to tune the bottom row of counters from time to time, so they don't inject the the next number too early.
To get to the amount of "0" in the counter configuration storage, you could just equate the amount of "0" to be counted with the amount of level numbers to be produced for the main array feed because of the same flow rate. The main array feed multiplies this amount by 24 to the hub.

So to calculate back:
For example the end-game requirement:
required level numbers / duplication factor
480k / 24 = 20 000 "0" to wait until next injection

For each "0" in the configuration storage, the counter let's ten numbers (here: "5"s) through, which get converted to "0"s.
20 000 / 10 = 2000 "0" in the configuration storage.

Because there are more "0" outside the storage on belts and the reset mechanism, the resulting number of let-through numbers is a bit higher, doesn't matter.

So in the end I just had to check that the next injection does not start before the level-up.
Even then, the main duplicator array has a massive inertia of additional 62k more produced old level numbers after the infinite duplicator to feed the array has already switched.

When the time came to increase the waiting time, I added more "0"s via the crossing belt from the far left going through all cofiguration storages, adding like 200 "0"s more to each counter module. In the sequencer screenshot on the left, there is a "5"-source with a 0-converter, below the two trash modules, with a cut-off belt pointing to the counter configuration storages. If you want a precise counter output, you can always calibrate by testing multiple count/reset cycles and adding or deleting some zeros from the storage, tuning up or down by 10 amount of the counted number.

One more thing: I forbade myself using any external tools or calculators to progress in the game. Would have been to easy in the beginning. So binary MAM configuration was out of the question for me. 😉

All those more 2-exponentiators also want to be fed, I have my reservations concerning the belt amount machine size and necessary input feed amount. Only the divider can conserve the input amount in the output, all other operators destroy a number during operaton. The less operations the calculation needs, the less you have to feed the machine.

[Elkir]

Nah how long did it take you

[IridiumMika]

https://steamcommunity.com/sharedfiles/filedetails/?id=3414423389
The save file says 425 hours, so I'll go with that.
Steam reports 488 hours, that would include time in the main menu and a little bit of progress lost because of some game freezes/crashes after long periods of running.
I was starting on the 2nd of July 2024, reaching level 1000 on the 2nd of September.
Most of the time the game ran in the background, so, active playtime of maybe 100 hours?
I graphed level vs playtime:
https://imgur.com/TjvEVnD