https://linen.dev logo
Powered by
Clustered Rehash Chunk Swaps
# open-problems
m
This will just be a subthread dedicated to figuring out the details of clustered rehash chunk swaps.
Rehash chunk swaps with cluster chunks have been done in early 2021 by cool mann ( ⁠https://discord.com/channels/961702940102504518/963534956565508207/970082815305736283 ⁠ ) and a bit later also by cheater codes and kerb ( https://github.com/CheaterCodes/easy-cluster )
Instructions for using cool mann's hekate setup: Teleport to 6700 100 -4650 Use view distance 16 This here is the cluster chunk loader. https://cdn.discordapp.com/attachments/1378287996834414702/1378288922509054002/2025-05-31_10.27.39.png?ex=683c0f16&is=683abd96&hm=4a5476bc0857c1476348e9722728e00d4331cf7794822b08721b87eea59a2d03&
Activate it and wait until all rail lines activated once. Depending on how fast your computer is this takes 30-60 minutes.
the contraption will then do one rehash chunk swap attempt every minute or so
How this thing does falling block swaps is something we haven't figured out yet and don't care about.
Applications of clustered rehash chunk swaps 1. ITT-less falling block swaps in the end Cluster chunks can be used to make the setup from this video 100 times faster:

https://www.youtube.com/watch?v=ZzeCdEv41aM▾

This then makes it finally feasible to obtain a full collection of all falling blocks in survival. For this we don't just need to cluster the glass chunk to increase chunk swap chances, but also use the cluster to improve the falling block swap chances. So the cluster needs to fulfill the following: a) Before the upsize: The glass chunk should have hash value near the end of the hashmap, and it should be highly clustered, so that the cluter wraps around and places the glass chunk near the beginning of the hashmap. c) After the upsize the glass chunk should be unclustered, but the 5x5 grid of chunks around it should be clustered as much as possible. We can even cluster chunks within 8 blocks of the sand blocks, because ITT isn't on.
2. Async lines in skyblock With a little bit of clustering the async line setup that I used for one block survival can be made much faster and more hardware-independent:

https://www.youtube.com/watch?v=urSXS1dhMVM▾

The setup uses 300 chest loaders anyway already just to upsize and downsize the chunk hashmap, and if we can just make those chest loaders into a cluster that would improve the setup by a lot.
3. Potential applications to random seed peaceful
I currently believe that rehash chunk swaps might be the most efficient way to get chunk swaps without beacons, which allows us to resolve the open problem of beating the game on a random seed in peaceful mode: https://discord.com/channels/961702940102504518/963534956565508207/1104388221435125933
But figuring out how many cluster chunks you need for a beaconless rehash chunk swap in the overworld would require some testing.
If we do this I would suggest loading the rehash chunk not from disk but from the AnvilChunkLoader cache. With this trick I think 500 cluster chunks should be enough to get beaconless overworld rehash chunk swaps, but that is currently just a guess.
@rpm0618 I created an open problem thread for clustered rehash chunk swaps where I collect everything we know about it.
I managed to find a world file for the setup by Kerb and Cheater Codes in June 2021: https://www.mediafire.com/file/khg49lyuxx5ksx7/Kerb+Cheater+Codes+Setup+14June2021.zip/file
It never worked though.
I must say, I really like the cool mann setup, and really dislike the Kerb+Cheater setup. Cool mann's setup is super pessimistic and controlling about everything, while the Kerb+Cheater setup is overly optimistic. Cool mann has 4000 cluster chunks, which is insanely big. But he still puts beacons below the stained glass. The beacons are probably not necessary, but he puts them there just to be sure. And he mines out the rehash chunk. That is definitely not necessary, but he mines it out just to be sure. And he only uses a single glass block instead of multiple glass blocks, because the dynamics of a single glass block are easier to understand and control. Meanwhile in the Kerb+Cheater setup we have an unnecessary chunk section in the rehash chunk, we load the rehash chunk with unnecessary block event delay, the area below the stained glass is not mined out, making the glass threads terminate already at y=64 instead of y=0, with a few glass threads even terminating at y=180. And the stained glass blocks start at y=255 instead of starting at y=256. The setup could be moved up one block. And then we push 1344 stained glass block with pistons. It is almost impossible to understand how the execution times of those glass threads interact with each other and the main thread. And then zero beacons, no AnvilChunkLoader cache tricks and only 1000 cluster chunks. And then it doesn't work. I'm tempted to clean up all the obvious inefficiencies in the Kerb+Cheater Codes setup, change it so that the rehash chunk gets loaded from AnvilChunkLoader cache instead of from disk, and then I would expect it to work and then it can be used to beat the game on Peaceful Random Seed.
r
I'm looking at this again. I still haven't been able to get a chunk swap with a hashmap size of less than 16k. I'm fairly certain that using a smaller hashmap size just won't work, unless I'm missing something major. I believe the reason is that the 
mask
value is cached per thread, and without a large enough hashmap size the cache doesn't get updated (probably some task switching thing or something? Still not entirely sure what causes the value to update). Making the 
mask
field 
volatile
does allow smaller hashmap sizes, but isn't something that could be done vanilla. As an interesting note, making the field volatile also seems to increase the chunk swap rates on the 16k size, so we're likely still hitting the cache there, just not all the time. Now I want to check my understanding of the falling block clustering part. With the piston clock generic method, we want to avoid clustering the chunk with the setup for fear of slowing down the async line. Is there something similar to be worried about with the rehash setup, or can/should I cluster the entire 5x5 region around the glass chunk after the rehash?
For some numbers, a 4000 chunk cluster at the 16k hashmap size seems to give around 1 chunk swap every 5-10 minutes (this is without any sort of tuning, just brute forcing it with cluster chunks). When I tried the same setup with 
mask
marked as volatile, I stopped the test after getting 9 chunk swaps in ~20 minutes, so the difference is significant. Quite annoying that afaik we can't do anything about it
m
"can/should I cluster the entire 5x5 region around the glass chunk after the rehash?" That depends on whether you're using ITT or not. You can do the falling block swaps without ITT, and then you can cluster the whole 5x5 grid. Or you can do them with ITT, in which case you only cluster the chunks that are more than 8 blocks away.
I think it's better to do them without ITT, and cluster the whole 5x5.
I think the most important application for clustered rehash chunk swaps would be for peaceful speedruns. You can probably do a rehash chunk swap with a 16k hashmap without using any beacons, and that might be better than the unload chunk swaps with over 10000 cluster chunks that Lucas Wills and CactusCreative were working on for peaceful speedruns.
r
Was not planning on using ITT. I'll run some tests without beacons in the over world to see what the rates there are, currently I'm using a void chunk in the end
m
The only reason to use a void chunk is if the threads run out too early. I think with 4000 cluster chunks you can easily load 4 chunk sections in the overworld without them running out.
You could even just take cool mann's hekate setup, remove the beacons and try whether it still works. I haven't tested it, but I would honestly expect it to still work.
r
The problem with coolman's setup is that it takes forever to load the cluster chunks, and often crashes half-way through haha, so I'm planning on remaking it.
Small sample size still, but at the moment it looks like not using beacons actually improves the rates a bit (in the end with a void chunk). Have gotten 11 swaps in ~40 minutes, so a bit better than 1 every 4 minutes. Will leave it running for a few hours to see how it does. Overworld testing will have to be later today.
m
Yeah, the cluster chunk loaders from cool mann's setup definitely need to be improved before anyone can use it.
r
So unfortunately, I think this might be a dead end. Still doing testing, but I think the synchronized block in the beacons is allowing the mask field to be updated. Haven't been able to get a chunk swap without beacons in the overworld (And I ended up having to use like 7k cluster chunks, 4k wasn't enough to keep threads from running out). Even with beacons the rates aren't great
Actually I'm not sure about that, I was getting swaps in the end without beacons. Like I said, need to do more testing
m
So having synchronized blocks outside the getBlockState() calls helps updating the mask inside the getBlockState() calls? That sounds rather mysterious.
Maybe we need slightly more than 7k cluster chunks with the mask caching issues.
But as long as it's less than 10k cluster chunks it has a very good chance of being competitive.
The unload chunk swaps people were working on either used 10k or more cluster chunks, or didn't work at all
r
Will try upping the cluster size then. My reason for thinking the synchronized block might be helping is admittedly rather flimsy, my preferred llm (claude, fwiw) says that synchronized blocks can force updates for cached variables that have changed across threads, and the fact that I ran a beaconless setup for ~ 2hours with no swaps and one with beacons has had 3 in an hour.
m
Ok, if the threads live long enough in both cases, then it's very interesting that beacons affect the rates at all.
r
The threads do appear to be living long enough, I have some code that is measuring how far along the glass thread is when the rehash happens, and it's fairly consistently in the middle of doing getBlockState calls when it rehashes (not always, but most of the time).
m
So our theory is something along the lines of: If we do many getBlockState() calls in which the mask never got updated and have no synchronized block inbetween, then in the next getBlockState() call the mask will be cached for much longer than if we had synchronized blocks between the getBlockState() calls.
r
basically, but I don't think it neccessarily matters how many getBlockState calls with the same mask happened before hand. Cache is maybe not the correct word for what's happening, as I understand it the effect is more that without the volatile keyword there's no guarantee about when the values will be synchronized (here's what claude says, take it with an appropriate grain of salt though: https://claude.ai/share/dab91860-708f-4a8f-aece-f0a423bc7cee)
One thing I might try is starting multiple threads, see if I can cause contention/context switching that way.
m
It sounds like one could drastically increase the chances for this with a modded operating system, even if one uses vanilla java and vanilla minecraft.
It might also be worth testing disabling the JIT compiler through the 
-Xint
JVM argument. That might also lead to less caching within the getBlockState() call, and as far as I can tell JVM arguments are usually allowed in glitched speedruns.
I mean, it takes over a minute to load a world with disabled JIT, but after it's loaded it's somewhat playable at view distance 2.
r
Okay false alarm, I think I just got very unlucky in my first test with no beacons, I've gotten 3 in an hour on this one (still just one glass). It is worth noting though that at 16k hashmap size the entire setup will need to load 12k total chunks, even if the cluster is only 7k. I haven't been following what's happening with the peaceful stuff so I'm not sure how reliable the 10k cluster unload method is, but if it is fairly reliable that one might end up being easier to do. Controlling chunk loading exactly is hard in the overworld.
Also, I'm pretty sure the cluster is only serving to increase the thread lifetime, and isn't actually helping with the rehash chunk swap itself. I.E. it's only hitting the race that you targeted with your setup. My evidence for that is my very first overworld setup getting ArrayIndexOutOfBounds errors from that initial check. so I switched to a chunk with the same hash in both the 16k and 32k hashmaps. Also the rates are lower than in the end.
m
"the entire setup will need to load 12k total chunks, even if the cluster is only 7k" I am aware of that. But I think 12k total chunk loaders is probably still less than 10k cluster chunk loaders. Even with a minimum rectilinear spanning tree, I think you'll have to load more than 12k chunks to get to 10k cluster chunks. "Controlling chunk loading exactly is hard in the overworld." Yes, that is the main drawback of this method. At least it's fully automatic, so you can run it until you get lucky with the uncontrolled chunk loading. "I'm pretty sure the cluster is only serving to increase the thread lifetime, and isn't actually helping with the rehash chunk swap itself" That is very surprising, but possible.
If we can't increase the chunk swap chances much, then using this for a general falling block setup doesn't make sense, but using it for beating peaceful mode does still work. All other approaches to beating peaceful are slightly even worse than this.
Actually, there is another very important thing to try: Instead of loading the rehash chunk from disk, you should load it from the chunk saving cache in the anvil chunk loader
In the 
AnvilChunkLoader
class there's the 
chunksToRemove
map, and if a chunk gets loaded from there it's much faster than if you load it from disk. That has a good chance of getting us from 7k cluster chunks back to 4k cluster chunks.
r
Do you know how to set that up? I.E. what are the conditions for that to happen? Or does that need some more research?
m
I don't have a setup for it. I think you should 1. unload a chunk with a lot of data that clogs up the chunk saving queue, 2. unload the rehash chunk, and then within the next gametick or so 3. reload the rehash chunk and ensure it causes the chunk hashmap to upsize.
A single savestated chunk should be able to stall the chunk saving queue for multiple gameticks
For testing purposes you can maybe mod the game so that the rehash chunk never gets removed from the chunk saving queue, but not sure
r
Okay makes sense, thanks.
We can increase them in the end. I still don't have a clear idea of what the difference is, but I can get around a swap every 5 minutes in the end. And I realized it's not as bad for the overworld as I thought, assuming we can use a set seed. We just have to pick one where there are no/few entities in the area of the setup that's entity loaded, no grass to random tick, etc. A big ocean essentially, and I can do some work to minimize the entity loaded area in the setup.
m
"assuming we can use a set seed" For the peaceful speedrun we can't set the seed, but we can kill all the entities in the area, and maybe dig away the grass at the view distance edge.
r
Okay, just more work then haha.
Okay, so I've had time to do some testing. I'm able to get chunk swaps with ~5000 cluster chunks when loading from the Anvil cache, but it's slower (~ 1 an hour) and with additional caveats: 1) I'm using carpet, and carpet backports a fix for (MC-119971)[https://bugs-legacy.mojang.com/browse/MC-119971] (I think it's not fixed in vanilla 1.12), which is in the anvil chunk loader and messes with the exact mechanism by which the queue works, so I've had to undo that and I'm not 100% sure I did that correctly. Like I don't know of anything I did wrong, but it's possible I messed something up there. 2) The setup is going to be way more complicated. I'm not sure there's an easy way to avoid using player movement to schedule the chunk unloads. Doing it right after an autosave might be possible, but we'd have to ensure the chunks we need are far enough away in the unload order that they only get evicted several ticks later. We would need to in that time finish the unloading of the extra chunks so that we can downsize the hashmap, and then reload them all again so we can do the upsize. Point is I'm not sure it's worth it just for the removal of 2k cluster chunks. Interested to see if you have ideas on how to make it easier/better.
m
For point 2), I think it's possible to use the autosave for the unload scheduling, if you only do an attempt at every second autosave instead of doing an attempt at every autosave. Although I did hope to get more than 2k cluster chunks from this. Why did mojang even implement a chunk saving cache if it only speeds up the chunk loading time by a small amount?
A simple setup with 7k cluster chunks might be superior than a complicated setup with 5k cluster chunks that only does an attempt every second autosave, especially since in both cases we'll have to load 12k chunks for upsizing anyway.
r
Let me do some more testing on lower cluster sizes, might be able to get it lower. I'm worried that will lower the rates even more though, and then doing every second autosaves halves it again.
m
"I'm worried that will lower the rates even more though" But you previously said cluster chunks don't really improve the success rates fro the actual race condition but only extend thread lifetime. I thought if you reduce cluster chunks, the rates would stay pretty much constant until they suddenly drop to zero when the threads die too early.
r
At the current cluster size of 5000, maybe 1/4 to 1/3 of the attempts have the threads not living long enough.
So if we reduce the cluster size, I'm worried more of the attempts will have the threads live not as long. I think that's the main reason for the decrease in rates from the 7k cluster.
m
So we have a very inconsistent thread lifetime. How wonderful.
(or a very inconsistent time on the main thread for loading the chunk)
r

https://tenor.com/Wkic.gif▾

But yeah, things are definitely not consistent
m
Although player unloading could also be done in an afk-able way if you push the player around with pistons
An afk-able setup with 5k cluster chunks doing an attempt per autosave and getting 1 chunk swap per hour would be good enough that I would send it to the speedrunners to try it
Actually, we could use the chunk loading cache and do attempts every autosave without adding much complexity, if we just completely overload the chunk saving thread and add so much data that the rehash chunk and most other chunk stay in the chunk saving queue for more than 45 seconds.
If you add savestates to a hundred chunks that you unload and reload every autosave, that should probably be enough to stall chunk saving permanently for most chunks.
r
I guess I should probably look at the rules for the speedrun, is duping allowed, or are people going to have to be making 5k+ books by hand?
Also, I haven't tried you're most recent suggestion yet, but I was able to get a cluster of 4.2k to work at roughly the same rates as the 5k by removing some stupid from my cluster finder. I attempted a roughly 2k cluster to see if we could downsize to the 8k hashmap, but that had 0 successful swaps overnight. Going to try for 3k to see how low I can get it.
m
It's a glitched speedrun, so duping will definitely be allowed.
r
4k looks to be about the reasonable limit. I do think a 3.5k cluster could potentially get a swap eventually, but it would be very slow. Most of the time the threads don't live long enough (to be clear, I haven't gotten a swap with less than 4k). I ran 4k overnight and got a little less than 1 swap an hour, so I think that's the number to move forward with.
m
I'm shocked by how optimized cool mann's hekate setup was already.
4k cluster chunks sounds very good.
r
Can't say the man didn't know what he was doing, that's for sure.
c
Do we have any tools for rehash swaps? That’s honestly the only thing keeping me from developing a setup for clustered rehash is because of my lack of tools.
m
I don't have any tools for rehash swaps. And I think rpm is mostly using profiling code that he quickly wrote himself.
r
I'm using profiling code that I'm writing (just basically putting strategic logging in carpet) and a custom cluster finder I'm developing. I can share it if you want @CactusCreative, but it's not at all complete (wouldn't even call it alpha quality) and requires a fair amount of technical knowledge and coding (it's in Rust) to actually use. I also already have plans to re-write it completely. So essentially, buyer beware, comes with no warranty, and I will not give a lot of support.
c
Thanks for keeping Rust alive. I plan to add a rehash finder to iCluster, with an option to calculate it in a way that after the upsize, it clusters chunks in the 5x5 for falling block swap
r
What kind of tools are you looking for then? I can share the profiling code I'm using, but that's even more of a mess lmao.
c
find glass chunk, cluster finding
r
Okay I have those. Like I said, very alpha quality, and the cluster finder doesn't currently do the falling block cluster after upsize (although I'm also planning to add that haha). LMK if you want it, and I'll push it up before I start on the rewrite I mentioned.
So I don't think we can permanently stall the unload queue. at least not with ~100 chunks,. 105 save state chunks only gives us a couple of seconds of time where we can re-load the rehash chunk from the cache (5 items in a hopper clock). Not sure that will be enough, will try increasing the amount of savestated chunks to see if we can get somewhere with a reasonable amount. Will have to figure out a good way to automate creating these chunks first, my hands are already cramping after placing >400 shulker boxes lmao.
m
If that is the case, instead of just adding more savestated chunks we should research first how to make a single chunk more heavy for the chunk saving thread. Although I don't have any clue about how to do that exactly
Maybe it's better to use chunks that have a lot of data, but make it such that that data can be compressed. The data compression might take a lot of time, and if the chunk actually gets written to disk that might also give a bit of extra time.
But if it's too difficult you can also just do an attempt every second autosave instead of trying to stall the chunk saving forever
Another thing: I believe the chunk saving thread has a lower thread priority than the main thread and the glass threads. If you run minecraft on just one or two cores, and also have some other programs running on those cores, that will probably slow down the chunk saving thread much more than it will slow down the main thread and glass threads.
It might even be helpful to just have a redstone clock on the main thread causing 0.05 mspt, so there aren't any gaps between gameticks in which the chunk saving thread gets extra execution time.
The chunk saving is done by the 
ThreadedFileIOBase
, which does 
thread.setPriority(1)
in its constructor, while the main thread and glass threads have a thread priority of 10 I think. We should definitely not add even more books, but exploit the thread priority to take away execution time from that thread.
r
I think I'm going to try using player movement to unload chunks. Reloading from the queue worked consistently enough with the single save-stated stall chunk, and using pistons to push the player seems reliable timing-wise.
My preference would be to avoid needing to make changes outside the game (i.e. for core affinity or requiring extra programs to be running)
m
Yeah, if you don't need it, it's better not to use it. Using pistons to push players sounds very good. But if you do ever need it, bullying the chunk saving thread is not that hard I think. You do need to restrict the cores, but you probably don't need to run any extra programs. A 0.05 mspt clock on the main thread should be enough to stall the chunk saving thread a lot.
r
Okay, I have a player movement based setup getting chunk swaps (it literally happened on the first attempt I had everything set up correctly, which I'm choosing to believe is a good omen lol), and I've managed to remove a lot of the non-vanilla stuff. I'm currently using carpet to turn on itt and simulate a permaloader, and I'm using custom commands to load the cluster and the extra chunks. Most of these are known qualities and will be easy to resolve, but I'm slightly worried about the extra chunks. We'll need a way to load them efficiently, and a way to keep them from unloading when we have a successful attempt so we don't downsize the hashmap and kill the async line. And preferably it's simple enough that I can write some code to spit out the litematica for me haha. Will think on that, but if you guys have any ideas lmk
m
Well, the first question is whether downsizing can actually kill async lines.
During upsizing the async line can get ArrayIndexOutOfBounds exceptions that kill it, but I'm not sure you can get those while downsizing.
I wouldn't try to keep all extra chunks loaded, but just look into whether you can keep the async line alive while downsizing. I think it's possible.
r
Hmm intersesting, will give that a shot
It seems like you're correct, have tried a couple times and the line hasn't died. That does simplify things a lot. Fully vanilla setup soon™ (hopefully lmao)
m
Nice!
c
You actually made a clustered rehash setup without getting bored and quitting? lmao
r
Getting bored? Nah making all the tools required is the fun part lol. And I don't have it yet lol, at least not fully, and not one that clusters the fb chances. This setup is for peaceful
c
Ignore what I said here
m
"and not one that clusters the fb chances" For general falling block swaps, I believe an unload based setup or a 1.8 setup will ultimately be better than a rehash based setup, unless you find a way around the non-volatile variable issues and do clustered rehash chunk swaps with a lot less than 4k cluster chunks. The unload double swappers I worked on half a year ago were actually very promising, even with just 500 cluster chunks. They still need a lot of work, but I think we will eventually get reasonable unload based general falling block swap contraptions with just 500 or 1000 cluster chunks. The 1.8 general method by Mxi is also very powerful, and if you combine the 1.8 general method with the usual 1.12 piston clock generic method you can actually get all falling block ids except for falling beetroot. The rehash setups seem to be by far the best option for peaceful and skyblock and any situation where you don't have beacons. But I currently believe they will in the long run not be competitive for general falling block swaps, because they are way too big, and they have serious competition. Although I can of course not predict where future discoveries will take us.
c
For peaceful mode, I am looking into an unload setup for only a thousand cluster chunks, but no lagspike and some other optimizations
m
Good luck. Doing it without lag spike is definitely the right thing to look into. But I'll be very surprised if you ever get below the 4k of the rehash setup.
c
I got a beaconless chunk swap with 2000 cluster chunks with a half second lagspike and mob switches. It’s probably possible
m
2000?
The last world download you published had 20000
c
Yes. 2 thousand.
I haven’t published the two thousand one.
m
It sounds implausibly good. Can you send me the world file for that one?
c
Yeah, I will get you that in a bit.
m
How many chunk sections does your unload chunk have?
c
0
I used mca selector to clear them
m
That's not exactly survival-friendly unless you're in a skyblock world or the end dimension
In the overworld the unload chunk will have at least 4 chunk sections, unless you have a very specific seed with a weird ravine creating a chunk with 3 chunk sections maybe
c
It probably doesn’t need to be a void chunk if you do maximum other optimizations.
m
I think that will make a big difference.
Because before the unload chunk gets removed from the loaded chunk hashmap, all the blocks from that chunk get written to nbt
c
I got the two thousand swap after twelve attempts with a void chunk
so it isn’t good chances already
m
Although having only 2k cluster chunks with a void unload chunk is still a good result. With 4 chunks sections you could probably get a beaconless unload chunk swap setup with just 5000-7000 cluster chunks
For peaceful it's good enough if it works at all
A 5% chance is good enough
c
the 30k setup had a 5% chance to not work
m
But I do think increasing the chunk sections of the unload chunk will increase the number of cluster chunks required.
c
Anyway I have to go now. I will give the world file when i am back
r
If we can get an unload swap working with 5-7k cluster chunks, that would probably be better than a rehash with 4k cluster + 8k extra chunks.
m
Yeah, but I won't believe in a 7k unload setup until I actually see it.
r
Before I get to lost in the weeds, do we have a good word tearing recipe for an end portal?
c
Yes.
I have it in my 20k world download
cauldron and water
m
"that would probably be better than a rehash with 4k cluster + 8k extra chunks" We should look into how many of those 8k extra chunks we can load with a really large view distance. For example view distance 32 loads 4425 chunks already. In 1.12 singleplayer you can go up to view distance 48. But when I try setting view distance to 48 on a carpet server it only loads chunks like with view distance 32, and I'm not sure whether that is a carpet bug or a vanilla bug. If view distance 48 actually works on vanilla it could load 9409 chunks.
It would probably best to use a view distance that loads slightly less than 6144 chunks, so we can downsize the chunk hashmap again and keep the setup afk-able.
At view distance 38 you should load 5929 chunks (if view distances over 32 actually work), which is the highest view distance which stays under the 6144 downsize limit.
So I think you really only need view distance 38 + 4k cluster + 2k extra chunks
Ok, I verified that the view distances above 32 work in vanilla singleplayer, even though they do not work on carpet servers for some reason
So we can just use view distance 38 to automatically load 5929 chunks and severely cut down the amount of extra chunks needed.
r
Hmm, that's an interesting idea, and if we're unloading the cluster on the autosave we can potentially cut down on the RD from 38, since the MST loading the cluster would still be loaded as well, counting towards the chunk count. The problem I see is that I think it actually doesn't allow it to be AFK-able? Currently the setup is designed so that the glass chunk is in view distance and always loaded, and the cluster chunks are chosen so that when the hashmap downsizes it re-clusters. If we're re-loading the cluster after each autosave, that would require re-loading the glass chunk after that finishes loading, which I don't think there's a way to do without update suppression, since we need the invisible chunk to stay unpopulated.
I guess we could potentially have them hold down right click and move the player past a lever for the player interaction, will need to see how reliable that is
m
"I guess we could potentially have them hold down right click and move the player past a lever for the player interaction" I would consider you an expert for that, because of your falling barrier setup. The only alternative to using an invisible chunk would be to make the glass chunk itself unpopulated. But that sounds like it would create more problems than it solves.
Although the player update doesn't necessarily need to come from a right click interaction. It could also come from a player movement packet that we could maybe produce afk-ably. I'll have to think about that a bit
r
Haha the barrier setup wasn't fully afk, I had a noteblock telling me when to hit the lever. But a similar setup blocking the lever until it was time, and then unblocking it could work, assuming the player doesn't double hit the lever or something. We could also just have the runner hit the lever manually, it's not that much effort and they already need to pay attention at least a little bit lol.
m
I think I can make a setup with a bit of ghost block technology, that gets updates from clientside movement packets due to falling down while filtering out all serverside motion packets.
We have ITT on, right?
r
yeah, itt is on
I don't know much about ghost block stuff (besides basic client vs server desync), how would that work?
m
My idea would be to stand on the edge of this gold block, and then use some ghost block technology to delete the gold block clientside but not serverside. https://cdn.discordapp.com/attachments/1378287996834414702/1479815212386488350/2026-03-07_13.16.23.png?ex=69ad68d0&is=69ac1750&hm=0bc6d1156773fcacb8db22805fea5f1bf96a3c49a1aff059b8800af56be0f553&
Gravity client movement packets will collide with the detector rail and send out comparator updates, while server motion packets will not collide with the detector rail because the gold block is there serverside
and then all the comparator updates coming out of the detector rail should be update suppressable
Nah, ok, my idea doesn't work.
It still crashes the server for some reason if I update suppress the comparator updates.
Forget what I said
Maybe we could do it with some kind of ghost mode, but it's better to not even start with that nonsense.
r
Darn, that would have been cool though. Thinking about it a little more, I honestly don't think it's that bad to have them flick a lever every once in a while. We can do something similar to my barrier setup where it's almost impossible to do it wrong, it's not like they're going to be leaving the pc alone during the run
Like, I don't think they'll literally be afk, and speedrunners do worse things than flick a lever every 45 seconds lmao
m
Actually test137e29's ghost mode would be perfect for this. Let me try that quickly
Nah, test's ghost mode also crashes the server if you stand in a detector rail and update suppress the comparator updates
I think a ghost dimension might work. But the nether-overworld ghost dimension is an infinite pain, and I'm not sure whether chunks in view distance would be loaded anymore, so I'm personally against it.
Ok, I found something that works: If you get pushed by a ghost piston head on the detector rail, that's always a client movement packet
You activate it. The rail pops off serverside but stays there clientside, and pushes over the pistons clientside. The piston in the middle of the picture is now sidewards facing on the client and upwards facing on the server. https://cdn.discordapp.com/attachments/1378287996834414702/1479821761104052445/2026-03-07_13.41.56.png?ex=69ad6ee9&is=69ac1d69&hm=e57cf0f49847a166ad85e314d184f7df4ade1fe13b04078c3fb573b81ea7cb49&
I feel like this is way more complicated than it should be.
Just make the player flick a lever
r
I've redesigned the setup for RD 32 and have switched out the chunk loading command for a chest grid. A new wrinkle has popped up though, not sure if I'm just getting unlucky or if lag is causing this, but for some reason the piston pushing the player is a lot less reliable. Like 2/3 times the player isn't pushed by the extension (phases through the head). Is there some alignment trick to make this more consistent?
I've mostly fixed this by using trapdoors to align & push the player. I realized that I've gotten rid of all of my custom commands at this point, so I have a world download if people want to test/build on it. There's a demonstration video here (

https://www.youtube.com/watch?v=9Uh4KxnzYP8▾

) showing a successful chunk swap, and I'll also try and polish up my notes on this. The only thing that should be left to do is the invisible chunk/async line setup (find liquid pockets/build radiators & savestates). Most of the infrastructure is already there (the bud line exists, for instance) but likely needs to be slightly re-worked (if we want to bring the async line back we'll need to load a few more chunks, and adjust the extra chunks the grid loads accordingly. I'm probably not going to be able to work on this for a couple days to a week, so if someone wants to push it over the finish line I'd welcome that. https://cdn.discordapp.com/attachments/1378287996834414702/1480722624475828325/Peaceful.zip?ex=69b15ea8&is=69b00d28&hm=8c39cca058043a8fe8967c813a74b570f5043e5f3af523f39820c7452c128461&
c
Do you prefer it be brought to the platform? I think that is useless. Just add like a piston bolt to go over. Do you have a preference for radiator vs liquid pocket?
r
Slightly cleaned up notes, lmk if you have any questions: https://gist.github.com/rpm0618/42e68af3551ccd35dfe95921bf116994 I'll try and get my cluster and setup utility code cleaned up as well, but that will probably take a bit longer. No preference for either bringing the line back or radiator/vs liquid pockets.
BTW I wouldn't blame you for having more questions, the notes are very rough still lol.
Also realized there are shulkers in the world download (in the stall chunk) lmao. They should be trivially replaceable with chests
c
Do you prefer async lines get brought to the platform? I do not think that it's necessary. Do you have a preference for radiator vs liquid pocket?
r
No preference for radiator vs liquid pocket The glass chunk is currently out of render distance, so if we didn't bring the line back for a visual indication of success we'll need some other way of indicating that, and the player will need to move quickly to make sure it doesn't unload (due to needing to unload and reload the cluster every auto save, the attempt happens pretty late in the auto save cycle, like 600 ticks in). That's the main reason why I was thinking about bringing the line back, but if you think it isn't necessary then that's a simplification.
c
I will use liquid pocket spots then after I design a savestate machine
Hopefully a simple piston bolt is fast enough, since the really fast ones need slime
m
"Do you prefer it be brought to the platform? I think that is useless. Just add like a piston bolt to go over." Bringing an async line over using a simple repeater line is usually less effort than building a piston bolt. I cannot possibly see anyone building a piston bolt in the speedrun. "Do you have a preference for radiator vs liquid pocket?" Since it's supposed to work on a random seed I would prefer a radiator. Ideally one that we just dig into the ground.
c
Good point on both things. Building a piston bolt in a speedrun does sound very ridiculous.
m
In the Anvil Cache Load section it says "Carpet has a fix for MC-119971 backported, so needs to be modded to match vanilla" So does this mean I can't use this with normal carpet?
"for some reason the piston pushing the player is a lot less reliable." The piston is often not pushing me either. Maybe we should ride on a llama to make all the movement serverside authoritative.
r
Ah damn, forgot about that. When I get a chance I'll check the code and see what the carpet version is doing, but iirc they do change the data structure and some of the logic. Not sure if that will affect things or not.
Okay I think we're safe? The carpet code replaces the ConcurrentHashMap with a normal HashMap and synchronized method calls. I took a quick look at the HashMap code, it seems like the bin calculation is the same, so the save order should be the same as the CHM one. I'll see if I can revert my changes and run a test with that version.
Okay, got a chunk swap with the carpet code, so it should work with normal carpet
m
Nice!
r
RE: working on a random seed It's not going to work on just any seed, at least not this exact setup. If the rehash chunk has more than 4 sections the rates go down significantly. I accidentally went up to 6 once while testing, and it took me a while to figure out why I suddenly stopped getting swaps (I think I got one or 2 over the course of ~8 hours). Also, I do think it's funny that we're going to be making people place thousands of chests in seemingly random locations, but building a piston bolt is out of the question lol. Like I agree with you, but the image of someone placing down all the chests for the chunk loading and then getting to the piston and bolt and giving up is funny to me.
m
" I do think it's funny that we're going to be making people place thousands of chests in seemingly random locations, but building a piston bolt is out of the question lol." It's not out of the question. It just seems that building a simple repeater or observer line to transport the async signal is way easier. Especially since you have to transport a signal to the player anyway to tell them whether the chunk swap even worked.
In the speedrun people could first run to the location of the rehash chunk, see how many chunk sections it has, and reset the run if it has too many.
Wait, is that actually realistic?
Can you run to the rehash chunk without having to savestate anything?
r
Yes, assuming RD is smaller than 32
m
It would be good for the run if we could check out the rehash chunk at the very beginning without needing savestate books
And yes, we can change RD in the middle of the run, it's singleplayer
So the strategy would be to start a new world, check out the rehash chunk, and only proceed if it has 4 chunk sections
r
I guess if we're thinking like that, it would make sense to move the setup closer to spawn. There's no real reason it has to be a couple hundred chunks out, it's where it is currently because it's in roughly the area I already happened to be when I started looking lol. The glass chunk locations are limited but not that limited, we can pick one closer.
m
I do think it's good if it's far enough out that it doesn't overlap with any possible spawn chunks, so we don't have to adapt the amount of chunks we need to load depending on spawn chunk location.
r
Good point. Do you know what the radius/distance is for? Like how far out can the down chunks be?
m
According to 5:56 of this video (

https://www.youtube.com/watch?v=Mv6GyBmZ9TI&t=356s▾

) in 1.8 the spawnpoint is almost always within 256 blocks of 0,0.
But I will also check the 1.12 code quickly to verify that
In 
WorldServer
Copy code
private void createSpawnPosition(WorldSettings settings)
    {
        if (!this.provider.canRespawnHere())
        {
            this.worldInfo.setSpawn(BlockPos.ORIGIN.up(this.provider.getAverageGroundLevel()));
        }
        else if (this.worldInfo.getTerrainType() == WorldType.DEBUG_WORLD)
        {
            this.worldInfo.setSpawn(BlockPos.ORIGIN.up());
        }
        else
        {
            this.findingSpawnPoint = true;
            BiomeProvider biomeprovider = this.provider.getBiomeProvider();
            List<Biome> list = biomeprovider.getBiomesToSpawnIn();
            Random random = new Random(this.getSeed());
            BlockPos blockpos = biomeprovider.findBiomePosition(0, 0, 256, list, random);
            int i = 8;
            int j = this.provider.getAverageGroundLevel();
            int k = 8;

            if (blockpos != null)
            {
                i = blockpos.getX();
                k = blockpos.getZ();
            }
            else
            {
                LOGGER.warn("Unable to find spawn biome");
            }

            int l = 0;

            while (!this.provider.canCoordinateBeSpawn(i, k))
            {
                i += random.nextInt(64) - random.nextInt(64);
                k += random.nextInt(64) - random.nextInt(64);
                ++l;

                if (l == 1000)
                {
                    break;
                }
            }

            this.worldInfo.setSpawn(new BlockPos(i, j, k));
            this.findingSpawnPoint = false;

            if (settings.isBonusChestEnabled())
            {
                this.createBonusChest();
            }
        }
    }
which goes to the 
BiomeProvider
and calls
Copy code
public BlockPos findBiomePosition(int x, int z, int range, List<Biome> biomes, Random random)
    {
        IntCache.resetIntCache();
        int i = x - range >> 2;
        int j = z - range >> 2;
        int k = x + range >> 2;
        int l = z + range >> 2;
        int i1 = k - i + 1;
        int j1 = l - j + 1;
        int[] aint = this.genBiomes.getInts(i, j, i1, j1);
        BlockPos blockpos = null;
        int k1 = 0;

        for (int l1 = 0; l1 < i1 * j1; ++l1)
        {
            int i2 = i + l1 % i1 << 2;
            int j2 = j + l1 / i1 << 2;
            Biome biome = Biome.getBiome(aint[l1]);

            if (biomes.contains(biome) && (blockpos == null || random.nextInt(k1 + 1) == 0))
            {
                blockpos = new BlockPos(i2, 0, j2);
                ++k1;
            }
        }

        return blockpos;
    }
which presumably returns a block that is within 
range
of 
x
and 
z
so the spawn points will be within 256 blocks of x=0, z=0
c
(Pre1.13 has spawn point within 256 blocks of (0,0) "at times" [useful for SSG seeds], while 1.13-1.17.2 has always a spawnpoint within 256 blocks of (0,0) or a direct spawn at (0, 64, 0) if no suitable block in the entirety of the 512x512 box is found, js)
m
Yeah, but if the spawn point is outside the 256 range in such a way that it overlaps with our setup, then you can just restart the run I would say
You can check that within a second of starting the run. Is F3 allowed?
c
But we aren't going to do 1.13.x blockstate corruption anytime soon lol
m
correct.
c
F3 is allowed in RS runs, it's checking the seed that is not
In pre1.3 F3 is banned because it displays the seed (lol)
m
Good. If we dig a radiator for the liquid pocket, then the setup is completely seed-independent
as long as the rehash chunk has only 4 chunk sections and the spawn chunks don't overlap our setup
And you can check out the rehash chunk and the spawn point relatively quickly, and it shouldn't take more than 5 tries until you get a good rehash chunk I would think
c
Btw, not trying to steal any time on my question, but is ghost dimension "playerchunkmap only" loading of a dimension useful for rehash/unload methods or is it pretty much indifferent from the regular world loading one? At the end I understand that the objective is to load specific chunks in a grid-like shape, but I was wondering whether being able to only use playerchunkmap vs having to deal with both systems (regular world loading & playerchunkmap) could be useful. (Obviously, to do what I just said, the idea is to get the respawn packet ghost dimension nether-overworld, the only one available in Any% RSP.. which isn't that hard once you setup a nether portal and ITT switch close to a bed respawn)
m
The only ghost dimension we can access prior to the end is a nether-overworld ghost dimension, and I find those incredibly painful to work with. We could use it if there was any advantage to it, but I don't see one so far. There's no difficulty scheduling chunk unloading when we want to. The difficulty is to stall the glass threads long enough, and for that I don't see an advantage of ghost dimensions.
I believe serverside you are just loading chunks around the player as normal in one of the two dimensions in which you're stuck inbetween
It can allow you to place blocks in unpopulated chunks. But we probably won't need to place any immoveable blocks in unpopulated chunks.
c
You can actually do that? I wasn't able to place anything in unpopulated chunks. Or at least, invisible chunks appear even in the ghost dimension (in the setup i use to access it)
c
only on the border you can or with a piston
c
Oh so you actually place blocks in the unpopulated server side chunk? Interesting
m
No, I think with the usual overworld->end ghost dimension you can place immoveable blocks in the middle of unpopulated chunks in the end. But you need to be very careful about which chunks you interact with, because every chunk you interact with gets loaded
c
I didn't test much thinking it was the usual invisible chunk that was unloaded but already populated
(It behaves identically with the player, got mislead lol)
c
For example in my multi async line chunk swap setup, you have to put beacons in an unpopulated chunk. And then when you use the setup, you place 16 stained glass using the trapdoors since you can stand within the block where the trapdoor is, allowing you to place blocks adjacent to it.
c
Btw nobody investigated much on the old player object in the other dimension or you can do little with that thing? (From what I understand from Captain_S0LO, it only exists in the subchunk from where the "split" started & only if that chunk stays loaded after entering ghost dimension)
I know obv you can push / move it using tile entities / entities and all that, but it is like another entity (so as if one spawned literally a player instance in a MP context) or it does still link with the current player for specific properties?
Also hmm, then you could technically use ghost dimension overworld-end to get easy bedrock, right?
Using the invisible chunk you can place a slime block where the bedrock will be (assuming an end gateway)
And then the silk touch fire setup
Easy because you can walk on the overworld floor in the end ofc lol
m
I've tried that but didn't succeed. In the overworld->end dimension you can place blocks in the end, but you cannot mine blocks in the end. In the end->overworld dimension you are loading chunks around yourself in the end. The only thing you can do here is use the overworld->end dimension to build a setup without requiring savestate books, and then go normally into the end and use the setup. But it's not easier than just using savestate books.
If you manage to get easy bedrock item using ghost dimension I'd definitely be interested.
c
The chunks don’t load in the overworld right?
m
If you are in the overworld->end dimension, you load chunks around yourself in the overworld, but place blocks in the end. This allows you to place blocks in unpopulated chunks in the end
In the end->overworld dimension you load chunks around yourself in the end, but can place blocks in the overworld
c
Hm I don’t know if it is a good idea for me to go to the ghost dimension in my survival world then.
oh well
m
The only serious applications of ghost dimensions so far is that the end->overworld dimension allows you to place immoveable blocks in the middle of unpopulated overworld chunks. There is no other method to do this.
But other than that I haven't gotten technical applications out of ghost dimensions yet
Although the credits warp has serious speedrunning applications
c
I did regenerate a random chunk from the ghost dimension somehow one time, the same day it was discovered
m
Btw, are you working on the rpm setup, adding the invisible chunk and so on? If you're not working on it, I would start to work on it. If you are working on it, I would wait and see what you come up with.
c
Yes, I am.
m
Ok, then I'll wait. Thanks for your work
I guess I can start making power point slides
c
Also I have changed my mind about using specific pocket spots and am going to use a radiator because the heightmap is being a nightmare
r
lmk if you have questions. Was anyone else able to get a chunkswap with it? Want to make sure it isn't too hardware dependent lol
If you have, I'm wondering how much of an effect the stall chunk is actually having on rates. I was thinking about the test I did this morning (switching the anvil chunk loader implementation), and I do find it a little odd that it didn't matter at all. I'm wondering if I managed to gaslight myself into thinking the stall chunk was helping, when maybe it was just coincidence that I started getting better rates with it (iircI fixed some things in my cluster finder as well around the same time). I won't be able to test this until later today or probably tomorrow, but if someone else can get similar rates without shulkers in that chunk we might be able to get rid of the player movement stuff.
m
The main issue is that it's not easy to tell whether you got a chunk swap. You did you even tell in the video without manually checking the chunk debug screen stacktrace after every attempt?
"I'm wondering if I managed to gaslight myself into thinking the stall chunk was helping, when maybe it was just coincidence that I started getting better rates with it (iircI fixed some things in my cluster finder as well around the same time)." From a code reading theoretical perspective I would definitely keep it.
Of course you can win the race conditions by luck without the stall chunk.
But I would definitely expect that the stall chunk makes it less hardware dependent
Even if it doesn't affect the rates on your computer, I would keep it, because it very plausibly might help on other computers
"we might be able to get rid of the player movement stuff." Can we?
Even if we get rid of the stall chunk, we do still have to put the rehash chunk in the chunk saving queue right before the attempt, right?
And that's what we need the player movement for
r
Yeah, good point. I was thinking we get rid of the stall queue entirely, but that was going to require more cluster chunks.
m
You can only get rid of the player movement if you keep the rehash chunk in the chunk saving queue for 45 seconds
I do want to use the queue, because 3k cluster chunks does make a difference
If we optimize the setup further (which I wouldn't do right now. Right now I'd just try to get over the finish line), then the first thing I'd do is increase the render distance from 32 to 38 so we have less extra chunk loaders
r
Yeah at the moment you have to watch the minimap. if the glass chunk gets re-loaded in the minimap after the attempt the only thing it could be
m
Although I am already impressed by the small amount of extra chunk loaders
Ok, that's good to know
I didn't know how you managed to tell in the video, but now it makes more sense
r
Can you get RD 38 on vanilla? Or is optifine or something needed for that?
The slider doesn't go past 32 on my singleplayer instance lol
m
Oh, wait, did I accidentally use mods?
Let me check
I was using liteloader with some mods
r
m
ok, then forget what I said
I didn't realize my client mods included something that increases the render distance maximum
Yeah, vanilla max is 32
But some client mod in my liteloader modpack is increasing the max to 48
Ok, then your setup is already optimal in terms of extra chunk loaders
c
yes i did
first attempt too
r
Okay awesome
c
i am still extremely impressed that you managed to make a clustered rehash setup without getting too bored
the closest i ever had to a clustered rehash setup was when I had actually finished planning it, and then actually coded some tools for it
but while i worked on building it i said i would finish it later and got bored and deleted the world file along with the tools
r
Haha thanks. I did almost get burnt out a couple of times, especially when myren had the render distance idea and I had to re-design everything when I was very close to being done lol.
c
For RD38 btw you need optifine
@rpm0618 I did have to modify your budline slightly, because part of it was going inside the invisible chunk
r
lol nice job me. For reference, the result of 
/loadedChunks size
should be 
12222
when the cluster and glass chunks are loaded, so if you need to make adjustments that's the number you're targeting. That comes from 12288 (hasmap upsize limit) - 65 (# of chunks that get loaded after player moves) - 1 (the extra chunk in the glass budline that gets reloaded after the player moves) Can add/remove chunks from the big rectangles of extra chunks to the right of the cluster to adjust as needed.
c
you know, someday i should design a radiator that i can use on all projects. right now I am always designing a new one each time i need it
I will probably do that after I finish this
r
Hard to tell in this picture, but make sure the radiator isn't directly below the glass. Needs to be fully air/transparent blocks below the glass, or the threads won't live as long (won't check as many blocks, they stop looking for beacons at a solid block)
Can just punch a hole through it if needed
c
im gonna move the glass
r
Gotcha
c
if needed
r
that works as well
c
also i very much appreciate you color coding everything
i never have the patience to do that
r
lol it's for my sanity more than anything else
c
wait
forgot the savestates
hmm how am i even gonna do that
minecarts ig
man this will suck
oh wait
it wont suck
i forgot about chest minecarts
r
chest minecarts suck too, at least they did in 1.8 lol, I was thinking if possible we should place chests in the invisible chunk, although I haven't thought through the exact process a runner would need to take there. The savestates need to be pretty fast as well, since the area gets loaded relatively late into the autosave.
c
r
As long as it works lol, I had problems getting that reliable when I was doing 1.8 stuff
Never figured out what was going on there exactly, but I didn't look into it too much
c
Idk why i though savestates would be hard. Maybe because of my dream last night where I had to use savestates but I had to put 2 savestate books into each hopper minecart
c
Just did a few tests on MCP. overworld-end ghost dimension keeps loaded overworld spawn chunks or player RD centered ones on the playerchunkmap (it seems, still have to check) the other dimension (the end) is completely unloaded, the player can't load any chunk in view distance and each chunk gets loaded when you place things (but not when you are inside apparently).. (or you add stuff to keep them permaloaded ofc) [ok this makes sense, since the player is not in those chunks lists and the playerchunkmap used is for the overworld one, since it thinks the player is in the overworld] Edit: nvm you need a third id to swap from overworld-nether to nether-overworld (namely the end), so ok i'm just wrong lol (for any% RSP 1.9+ ofc)
Ok so hmm now I'm trying to figure out the nether portal registering player part (i'll prob output the lists for a target chunk). I tried to enter in a nether portal and return there in the end in ghost dimension but i don't see anything about an old player object. Is it there only in the list or i'm missing something?
I suppose mining with beds [the end explosion] isn't exactly what we'd want (place to break XD), so ok i see the problem (we can only place but not break anything "directly")
Anyway my idea in short (from stuff i understand so far) [not trying to waste time, so read only if you care lol]: || - "could" we use nether-overworld ghost dimension with this idea in mind? - only 256 spawn chunks loaded in the overworld - placing blocks that permaload "wireless" specific chunks in the overworld using nether-overworld ghost dimension to have 256 + cluster chunks loaded. - you can never load any other chunk in the overworld beside the 256 + the one you permaload (as long as you don't leave the ghost dimension) [exception if fire around the spawn chunks perimeter, but that is so unlucky lol (and unavoidable regardless)] - the only nether chunks loaded are those of the player RD, but anyway this is done in the overworld so shouldn't matter if i get it right (if it matters you can always remove fire from a very specific square section of the nether with RD2 before proceeding with async lines [or you can die and stay in respawn screen since that will unload nether chunks but overworld permaloaded chunks still work]) The only catch is having to setup all chunk suppressions before entering the ghost dimension.. and never messing up after that..not sure if really worth lol. The added difficulty is navigating the mess of nether-overworld grid chunks.. yep ||
Anyway i'll test stuff i said myself later, just showing the idea i wanted to use the ghost dimension for, maybe entirely wrong but yep xD. I think 3k chunks is still a long journey regardless of where we do it
Well actually you can still do one thing, you can place books in a chest in the new chunk in the end to easily regenerate it later. (You can still interact with all tile entities of the non-breakable dimension if the block appears in its place [except chests from the breakable dimension, which can only be broken if the player isn't in the chunk list])
Oh i forgot to test this one (i'll do it rn): - when you enter end or enter/leave nether, there's a tick or so (caused by movement packet if lag [RD32 + FPS10]) that sets your old coords in the new dimension after warp - the player could load at this very precise moment an unpopulated chunk that suppresses another Will this generate still a ghost dimension? Time to figure out
(Or i can check the teleporter code and see if this happens before or after dimensionId set, seems a fun "wrong warp" teleporter device regardless)
m
"each chunk gets loaded when you place things (but not when you are inside apparently)" The chunks do get loaded when you move around inside them. It's just that all chunks get unloaded every gametick if there is no player in the end.
"placing blocks that permaload "wireless" specific chunks in the overworld using nether-overworld ghost dimension" I doubt any overworld chunks get permaloaded. They get loaded, until the next autosave, and then they get unloaded.
c
Hmm the Drop is 0 when I place a block in a chunk. Wouldn't it be 1 if that was the case? Depends on the phase i'm checking maybe
Like it should be Loaded: 1 and Drop: 1 for it to be constantly loading and unloading if the player is in right?
(I refer to the loaded chunks hashmap total and the dropped chunks [100 max] ones)
ok i thought we had something to keep them loaded without a wire that loads "only" them all at once and that we could turn on/off wireless someway
Ok actually, item shadowing, hmm
You can interact with the chest of these chunks and place a shadowed item in it. But ok yeah i can't think how that would keep it on
I'm checking the phase of the stained glass being placed (just convenience for the static function where i can inject code)
Ok on retrospect i forgot it's multithreaded, i should switch from that lol XD (but yeah i recall it does show 1 and 0 at times. Unsure if it's because the placement of the block happen before the chunk is marked as Drop, maybe it is that) [ok i'll actually code a proper function to check exactly when a chunk enters the loaded and drop hashmaps] Hmmm ok i'm 99% it is this mb. However it is also a non-issue, you just interact from a chunk from outside, not too bad [like you just stay on the neighbor chunk and place the chest on the target one]
c
c
Ok a better way to rewrite this: - In The End you only load and immediately unload the only chunk you are in (since playerchunkmap is looking at the overworld), but then all unloaded The End chunks around you with overworld blocks can be interacted from outside
c
@rpm0618 So I have all the invisible chunk stuff placed, but when should I flick the lever for it? Because it just automatically reloads normally after an autosave
r
So there's a hopper clock that is currently activating the bud line every autosave. That should instead be hooked up to a light/noteblock that informs the player it's time to hit the lever.
c
r
c
Okay.
r
If you think the timing is too tight you can add more items into the hopper clock next to it, that's the one that activates everything else
c
Speedrunners when they see the maze they have to load lol. If only we could on/off chunk wireless... (ok the wireless thing is never happening)
r
That's not even half of it lmao
c
Well this isn't 1.8. So absolutely not.
c
So in 1.9-1.12 there's really nothing that can load wireless chunks.. sad. All i know is that teleporter + item duplicate (ex: pearls) in same coords across two dimensions, but yeah that's all
c
it will make it not be the player phase
r
Only if ITT is off, but yeah the first time it's activated it wouldn't work lol
c
So should I use the first lever before I get in the tub?
r
Either that or make the line shorter, I think the player can reach farther than where the lever is currently placed. Just make sure to test in survival, I think reach distance is longer in creative?
c
About loading stuff and keeping them in memory, turns out that if you switch from RD32 to RD2 during dimension travel, the multiplayer cache doesn't deplete (if done fast enough) and sometimes you get instantly in an unloaded chunk section OR a "server frozen status" (until you switch RD back). I wonder if this is like some useful gimmick or just another playerchunkmap issue on the top of other issues about it.
(Using this fact you can get "easily" 8000 chunks loaded on the cache when in the nether without any prior setup with vanilla RD32)
The multiplayer server cache seems pointless, since the client still requires server validation (from a hash from what i've read), but not technical enough to know details of this fact lol
(Ok after this i'll stop with my question, but this seemed at least slightly related so i was curious if it is just a random client side only behavior or there's something more broken behind it. This does actually generate an invisible chunk right when you return from overworld [and right after swap RD32 with RD2], so it is weird lol)
r
When you say "loaded on the cache" what does that mean exactly?
c
The multiplayer server cache value you see on F3
r
Unless that corresponds to the actual chunk hash map in the overworld (which I don't think it does? Could be wrong there) that's not that helpful unfortunately. We need actual loaded chunks, and we need like 4k of them to be very specific chunks
c
Normally that matches around the actual loaded chunks (not at all, but like by view distance it sort of does [obviously not the spawn chunks]). Using what i said you can get double of them (RD32 from both overworld and nether at once) and also get that weird invisible chunk behavior which does affect gameplay (so it is not just client side).
It does make an actual effect on gameplay with the invisible chunks (or the server frozen effect/"player is stuck with rotation and uncapable to move"), so idk whether it's playerchunkmap issue or actual load of 8000 chunks, i'll doublecheck tomorrow. I noticed that when you move around the nether, the 8000 chunks decrease if you re-explore the same chunks of the overworld. So the multiplayer chunk cache prob dupes the entries of both server worlds.. but yeah i dunno if that is any useful other than potential memory leak xd
What i think is that those chunks get only stored in the multiplayer chunk cache but unloaded from the actual overworld hashmap.. but this still manages to mess up the playerchunkmap someway. (Or at least, something does that)
r
My guess (just based on gut instinct) is that the chunk cache is a clientside thing, and it's counting the number of chunks the client has cached locally. If you can test in carpet, and it matches exactly with the output of 
/loadedChunks size
that's a better indication that it might be the actually hashmap size, but I don't recall a place where that is ever being sent to the client directly.
c
To test what i said you can just open a new random world, place a nether portal, increase RD to 32, wait to load all chunks, then enter nether (version 1.9.0 is the one i tried), switch immediately to RD2 after travel (as fast as possible) and check F3 to see if the chunk cache loads suddenly and returns to ~4000 chunks in the nether despite having just set RD2. Once you have that, you switch to RD32 again and you will get to 8000 in cache. Idk whether that is real loaded (can't test)
Just saying ofc, i'll make a vid tomorrow if nobody can replicate (in my pc this happens often)
(Doing this the other way [overworld to nether] might cause the player to spawn immediately on an "invisible chunk stripe", or at least it happened to me)
I didn't test whether you can keep that cache growing, but perhaps you can chain this multiple times (it would probably only cause a OOM at best anyways)
I think the problem of testing in carpet is that this is a singleplayer specific glitch likely, so using a server might prevent this to happen at all. (Especially since differences in server side RD exist here), but i can easily test in MCP
r
Pushed my rehash cluster finder utility to https://github.com/rpm0618/mc_utils (still need to update readme and release, and it could use a bit more polish/bug fixes, but the code is there for perusal/use)
c
hm i think i need to slightly change the budline
that was a nightmare for some reason
c
Btw, just to know, these invisible chunks are different from the one achieved with RD?

https://youtu.be/S7sRjFcfoig?si=BuN3pmrizl3r_c9u▾

c
they are normal invisible chunks
c
I know at least two types of invisible chunks in 1.9+
One that doesn't disappear if you change RD (above)
c
this one is useless
c
One that does disappear if you change RD (below)

https://youtu.be/gIFTcA0mjlE?si=uusyb8hm1tNTVfse▾

Ok well the ones of these two videos to make it short. Xd
(My other videos are just variant or exploit related to them)
I just wonder how many "types" of invisible chunks we can have lol.
I know in principle they are two, client and server chunks (where server are the most important, since client will mostly cause desync only issues)
But there is also playerchunkmap and server world hashmap distinction (since these store the chunks in their own individual hashmap)
And there's also singleplayer / multiplayer chunk cache, which i assume it is only used indirectly though
So i think there are at least five "types" of chunks, but only two are actually updated (ignoring the cached ones)
[I'm not referring to their state, like lazy, unloaded, unpopulated, etc...]
Now in practice, i think we want to have invisible chunks in the server world hashmap (for clustered rehash)
So i suppose if those two invisible chunks are both from playerchunkmap, then... they are useless, right?
c
c
Ok basically, that's where the ghost dimension comes in, because i noticed the invisible chunk carry to the other dimension as well (since you never close the previous world server, so they... obviously stay in place [if on spawn chunks]) .. but i guess it is visual only...
Minecart chests with random garbage books 🔥
c
The bee movie script works well as a savestate book, i dont know why you need to know but now you do
i used regular books here tho
c
The entire bee movie script can fill a chunk?
c
yes
in surprisingly few books
c
Ok nvm i see, the whole movie script split in various books placed in the minecart chest... epic lol
c
i didnt use the bee movie here
c
Yeah i meant, you'd do that likely
c
i just decided to say for no reason
c
Is it possible for a single book to oversize a chunk or highly unlikely?
Never checked this enough lol
(Non-signed) Written books cannot be linked with item shadowing right?
That would be so epic if it worked lol
c
absolutely not
c
I somehow never tried this
(Changing a written book content while shadowed, but i suppose it does break the link)
I know you can overstack item in chest outside their limit (with 1.12.0 overstacking), but yeah that's all [the stack will disappear when reloaded, but until it stay loaded, the container does indeed have an overstacked item]
Expected, i wondered if the random garbage encoded could have been optimized to be extremely high to the point where you could copy paste a very specific sequence to do it lol
I know 1.13-1.14 resource pack can allow a similar concept on signs. 1.9-1.12 is in the cursed range where it is not possible
anyway this is what i tested, the variant of the playerchunkmap with chunks that stay "invisible" with RD changes, then i entered the ghost dimension overworld - end and then i tped there.. and it's a much larger zone somehow, idk https://cdn.discordapp.com/attachments/1378287996834414702/1481417469137649855/2026-03-11_23.19.45.png?ex=69b33d08&is=69b1eb88&hm=dc1907483a5ecbd3aaa7f1ee7c8a13d3800837e7edd4167a0bf3855e9eeba335& https://cdn.discordapp.com/attachments/1378287996834414702/1481417470312059060/2026-03-11_23.22.07.png?ex=69b33d08&is=69b1eb88&hm=07106c09510a99f4c8a3d5cf51fcaf26fee43f56a153d5ac1b4e5e31e7f4b5da& https://cdn.discordapp.com/attachments/1378287996834414702/1481417471238996213/2026-03-11_23.22.19.png?ex=69b33d08&is=69b1eb88&hm=407fe1e96ec5295d0da9a3f853329bfaa3b17dede71122d4bdd30b277047d43d&
for some reasons the 3D yellow debug grid only appear on those 2 chunks
i don't understand the criteria lol
the stained glass has the debug code that prints useful info xd, that's why i've placed it if you wonder
ah nvm i see
the debug grid only applies to the last chunk after you enter in an unloaded area
i found a way to break tile entity from the other dimension in the ghost dimension
in creative.. unsure if that applies to survival lol
seems creative only, weird..
c
I think I have finished the invisible chunk system. Let’s hope to Christ this works
damn it my savestates are broken
i am gonna be so happy when i see an async line from this
this project has gone on long enough
c
btw i've lurked the code a bit and theoretically a chunk swap from playerchunkmap should be possible
at least, what it actually does is to use the chunkprovider for the world to load chunks (so it basically does already what world loading does, just for the player)
private final Long2ObjectMap entryMap = new Long2ObjectOpenHashMap(4096); private final Long2ObjectMap loadedChunks = new Long2ObjectOpenHashMap(8192);
if you swapped the chunk on the playerchunkmapentry, you'd also swap them on the chunkprovider i think
(the playerchunkmapentry is a wrapper for the chunk for the player, for what i understand lol)
the only difference is the initial capacity of the hashmap, which is halved for the playerchunkmap
c
only problem is you need to restart the server every attempt, which i am trying to fix
r
Why do you need the restart?
c
savestate problem
r
ah rip. Good work getting the async line though!
c
these savestates are being a pain in the ass.
i am gonna have to design a better solution for it
r
Is it the minecarts? I never got them working correctly in 1.8
c
the budded pistons don’t ever fire
well one of them
they only fire when i repopulate manu
you know what
i think i know the issue
the repeaters that update them must be too close to unloaded chunks
r
Ah, the old classic
I've lost soo much time to that issue in various builds lmao
c
I am so stupid lmao
you know what this means, new savestate system
or sort of new
Okay I will have to modify this a lot more tomorrow
hmm chest carts keep getting deleted by the server, i think i need to find another way
Any ideas for a better way to savestate?
m
We can place chests at the chunk border inside the unpopulated chunk. That's annoying to build, because it requires an invsible chunk while building, but possible. After that you can just use droppers to put books into the chests.
Actually a bit easier: You can have chest minecarts already in the unpopulated chunk, and droppers can put items directly into chest minecarts
That might be slightly less annoying to build that putting actual chests in the unpopulated chunk
So I would have chest minecarts with checkerboard of type 1 savestate books inside the unpopulated chunk at the chunk border already saved to disk.
And on the other side of the chunk border, outside the unpopulated chunk you have droppers with type 2 savestate books facing into the chest minecarts.
Actually, all you really need in the unpopulated chunk is a rail at the corner. Then a dispenser from outside the unpopulated chunk can place a chest minecart directly on the rail, and a dropper can put items into the chest minecart
If you have this on a chunk corner, the dispenser can place a chest minecart and the dropper can place book items into the chest minecart. https://cdn.discordapp.com/attachments/1378287996834414702/1481778407951044750/2026-03-12_23.17.25.png?ex=69b48d2e&is=69b33bae&hm=94f8aea0fcfc27577c2b1e1f749ae9bca1704e9375104174c636c6abb2e51ccf&
But actually inserting all books through a single dropper seems super annoying. I think you can just put chest minecarts with type 1 savestate books in the unpopulated chunks saved to disk already for the savestate contraptions. That's possible to build without even requiring an invisible chunk
c
why do bad things happen to good people
okay new savestate solution I guess
m
Also, another way you can push chest minecarts across chunk boundaries in lazy chunks is if they are inside farmland that converts to dirt. In 1.12.2 they introduced a feature, that farmland pushing up entities will register those entities in the chunk they're in. So if you have the chest minecart in a farmland, push it into the unpopulated chunk, and then push another block above the farmland to convert it to dirt, then the chest minecart should be properly registered in the unpopulated chunk and the savestates should work. https://cdn.discordapp.com/attachments/1378287996834414702/1481940782142459994/2026-03-13_10.02.39.png?ex=69b52467&is=69b3d2e7&hm=a5b24b6a5e4fabb362846b6e0d9686e09f8bd9becb558d5ed6c244cc9ad42f62&
Although note the farmland trick only works in 1.12.2 and not in 1.12.0 or 1.12.1
r
I like the farmland trick, if people want to do it in earlier versions they can kobra in some chest minecarts or something
c
yeah, and it makes them learn technical minecraft
r
I should be able to jump back into this later today or tomorrow btw, so I can be of more help soon
c
i love the farmland idea.
I will finish this today.
hmm
the problem is I need 2 chest minecarts
r
One in each corner chunk should work, so basically have 2 of the above setup and mirror it around the corner
FYI, I think this configuration doesn't work. I added some logging code and the minecart is only added to the chunk when it's actually pushed up by the farmlan, and unless I did it incorrectly that didn't happen with the minecart clipped into the farmland. Needs to be resting on top, something like this https://cdn.discordapp.com/attachments/1378287996834414702/1482116710059475039/2026-03-13_16.40.18.png?ex=69b5c840&is=69b476c0&hm=94ca9f026df1a41f0a7e6448e6d3a00b08a72d7e1dea2e18d8595d8e3b944c2d&
Actually this seems inconsistent as well
m
Ok, that's good to know.
But I'm confused how this would ever be inconsistent.
r
The order the pistons are powered in matters, from what I can tell
m
Unless the farmland converts too early before the chest minecart isi n the chunk
Yeah, update order can matter here I guess
The farmland converts to dirt as soon as b36 is above it
r
ah didn't realize b36 did that, that makes more sense then
c
I am going to now try and find a solution
r
I have a setup that powers it correctly, it's just a bit ugly at the moment
c
oh nice
what does it look like?
r
c
If you would like to also work on from what I currently have I can open the server.
r
I'm about to grab dinner, can jump on after
c
Okay, IP is human-shares.gl.joinmc.link
I also put you as OP if your ign is the same as your discord. I am going to be gone for a bit
If anyone else wants to join they are free to as well
r
We might have a problem with the savestates. It takes absolutely forever for chunks to write to disk when the cluster is unloading. (Essentially the thread gets stalled out, which might be why the stall chunk in the setup didn't seem to matter that much when I tested it locally) @CactusCreative when you get a chance can you let me know the exact coords of the chunks that need to be save-stated in the current setup? Maybe we got lucky/can find a different location with a more favorable save order, but I'm worried we might have to end up doing attempts every 3rd autosave,
Smaller issue, at least with my current JVM arguments the rail line update suppresses itself the first time it's used lol. Presumably we can make them use a higher stack size argument for the run?
c
I was thinking every second autosave would be a good idea.
I can load up the world in a bit.
I am designing something in prototech right now
m
We could also relog after every attempt to guarantee the savestates work. Then it wouldn't be afk-able, but it might even also allow us to do the attempts much more quickly. If the chunk saving problems can be solved, it's better to keep it afk-able. But if those problems turn out to be unsolvable, we will have to use relogging.
c
Thats what i had to do when i actually got the async line
r
It's not really afkable anyway, we still need player input, so it might be worth it to just have them relog
But I'll keep digging around this for a little bit first
c
Okay I will open the server. Same IP as yesterday.
It's up now
human-shares.gl.joinmc.link
wait i forgot to set view distance back to 32
r
nw, since it's all budded it's easy to do that lmao
c
Looking like we are getting close to done
pretty excited for that
If you guys want the server started again, send me a ping.
but give me a little bit because i cant do so right now
ok now i can start it upon request. I changed the backup command so everyone can use it and am using the carpet i changed from but removed the code i added to bans
@rpm0618 Did you already subtract from the extra chunks?
r
I'm working on it, but it might be a little bit sorry. Have irl stuff to do
c
Yeah thats fine
I just tested the savestate in a copy. Right now the problem with it is the normal savestate machine rather than the one that was just designed
ok i fixed it, i forgot to replace a repeater at some point
m
Nice!
r
nice. Was that a "natural" async line? I needed to make some updates to the setup to get a successful chunk swap, but I think the backup you gave me was a bit corrupted so potentially it just had old stuff (for instance, the cyan line wasn't completely moved over, sections were still in the old spot
c
not a natural one
ok hold on
r
Don't bother, I fixed it already
c
So is the setup complete?
r
Not yet, I haven't adjusted for the increased spawn chunks yet.
Just for the extra chunks the cyan line loads
c
couldnt we just wait an autosave?
r
That's a good point, in singleplayer you can force an autosave by pausing right?
c
yes
Could you send me your current world file?
r
c
thanks
r
oh wait, hold on
I think we need to remove 2 of the extra chunks first, I wasn't testing with the savestate contraptions and they load extra chunks
c
alright just do that then i can test it
r
c
Okay the savestates are working I think
nevermind yeah we will have to relog or do it every few autosaves
no wait
uhm
the other one succeeded
r
hmm, interesting lol
c
I think we will have to relog
I fixed the savestater i think
I can't test it in singleplayer right now because I am getting 0 FPS. Let me know how well it works,
r
Did you make any changes to the setup, or can I just use the download I sent you?
c
use the one you sent just fix one of the repeaters and delete the redstone i used over the piston that keeps it from un bud powering
r
which repeater?
c
near the suppression chunk savestate
r
Or is it obvious and I just have to apply eyeballs?
c
actually i will send you my file since it’s pretty invisible
hang on
@rpm0618
r
Thanks, will be a couple of hours at least before I can try it fyi
c
Alright,
Really?????????? A particle???? [17:49:30] [Client thread/FATAL]: Reported exception thrown! f: Ticking Particle at btg.b(ParticleManager.java:317) ~[btg.class:?] at btg.a(ParticleManager.java:252) ~[btg.class:?] at btg.a(ParticleManager.java:231) ~[btg.class:?] at btg.a(ParticleManager.java:179) ~[btg.class:?] at bib.t(SourceFile:1727) ~[bib.class:?] at bib.az(SourceFile:1000) ~[bib.class:?] at bib.a(SourceFile:419) [bib.class:?] at net.minecraft.client.main.Main.main(SourceFile:123) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_202] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_202] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_202] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_202] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at org.prismlauncher.launcher.impl.StandardLauncher.launch(StandardLauncher.java:115) [NewLaunch.jar:?] at org.prismlauncher.EntryPoint.listen(EntryPoint.java:129) [NewLaunch.jar:?] at org.prismlauncher.EntryPoint.main(EntryPoint.java:70) [NewLaunch.jar:?] Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
it could have been anything
but of all things
a particle crashes the game
m
Well, the problem is not really the particle, but the fact that it ran out of memory.
We might need to use JVM arguments to allocate more memory, if this setup consistently runs out of memory.
r
Made some more changes/fixes to the savestates, hopefully they should be working now. Also updated the lever the player flicks to remove the repeater. Current (still existing) issue is that the bud line reset circuitry doesn't work when the other end of the line gets suppresed. That will need to be redesigned, or we get the player to flick the reset lever manually as well. https://cdn.discordapp.com/attachments/1378287996834414702/1482906386135257208/working_savestates.zip?ex=69b8a7b1&is=69b75631&hm=29e16e26a205276f97c8ed58320632c78fedad27db99a3398c5391c45744ca81&
c
Do we still need to relog every attempt with the “fixed savestates”?
r
Yes, that's still required. I don't see a good way around that unfortunately. Also, I need to increase my jvm stack size (
-Xss4m
) or the rail line update suppresses itself before getting to the invis chunk setup.
c
Mine is -Xss10m
anyway, i can try and fix the budline
and is that all we need
?
r
I think so, unless we find something else lol FYI I probably won't be able to actively help for the next couple of days, but I should be around to answer questions
c
Here is an active world file. If it crashes when you join it means you must delete your playerdata since it means when we were all on the server you left the game too near the setup. I did make a few tiny changes like adding a fix bud line lever right next to the other lever in the tub. https://cdn.discordapp.com/attachments/1378287996834414702/1482937933634867251/active_peaceful_setup.zip?ex=69bc10d3&is=69babf53&hm=46851919e9222cff061c1a9625762e9dc7748d677391fa833ec22e1b748a3bd1&
oh sorry its not active
i forgot to delete the two chunks
you will need to use mca selector to make it active
it also looks like this save file still has the purpur stairs so I must have forgotten to give that at some point. If this ever gets published, we need to have the save file to have the signs.
c
I know it might probably not matter much, did you check what happens to the player when it does netherwarp with a pearl while riding an entity in 1.9? It seems like it can be in two places at once, unsure if it could help here with the setup idk
Specifically throwing a pearl in the Nether in a Nether portal while riding an entity (doing this in the Overworld seems to work differently, perhaps only in spawn chunks)
In the overworld you can get in a phantom state where... nothing really useful happens .. other than you can somehow punch the boat you are in (this is normally impossible because client side should prevent you from interacting with your own rideable entity). This used to be only possible up to 1.2 i think?
just pearl until you somehow get removed from the boat (this shouldn't happen but it happens client side only at times, clueless. low RD achieves it faster)
this is what should happen (client side clip through the block below you) and you can phantom over in the client side by moving around https://cdn.discordapp.com/attachments/1378287996834414702/1483803234177912934/2026-03-18_13.24.11.png?ex=69bbeaf2&is=69ba9972&hm=09487357d94de42db6718d9401e462735f596271ff47db0aa034128ae82453a5&
Ok I won't say anything more (to not fill the chat), just showing that you can get the player in a weird state, maybe useful for chunk swaps idk
c
So I have gotten a few chunk swaps and now I am going to add some very tiny but kind of important things and create the world file, so if this ever is published outside this discord, then we have a perfect save file available.
Change 1: Fix the purpur stairs in the word tearing setup.
I added some signs too.
r
Awesome, anything cheaty still, or are we actually done lol?
c
we are absolutely done
r
As an fyi, the line to reset the budline isn't connected, at least in the inactive world download
c
i actually somehow forgot to connect that???????
r
c
lmao where did the piston go
r
lmao do you have it on your end? That's funny
c
yes
its also not there
idk when i broke it
m
Speedrunning instructions: 1. Check out the rehash chunk. If it has more than 4 sections, end the run. 2. Build the radiator. Test whether the radiator works (This might require making a backup). If no liquid pocket spawns in the radiator, end the run. 3. Build the whole setup, and beat the game. Rules: 1. Litematica must be allowed. 2. Making backups should be allowed, but the time you spend in backups should be added to the speedrun time. 3. The autohotkey script for creating savestate books should be allowed.
Am I missing anything important in those instructions or rules?
c
Looks good to me.
r
I think those look good.
c
👀 speedrunning instructions
I suppose loading overworld chunks by sending item from nether to create the grid for the cluster chunks is too slow compared to "wiring" everything together in the overworld?
Not an expert here but i suppose that's the first thing one would think when trying to do a real run of this
(I refer to the "glitch" that makes item dropped in a nether portal block to load a single chunk at the same coord of the nether in the overworld) [also works the other way around]
Oh well i'll check how the current setup works and see whether it could be made faster or not. (The idea is just to find the "lowest resource way" to prepare the cluster chunks [also makes it less tedious in a real run, less on the player and more in the strat])
This specific question comes from these three facts: - Nether roof is clearly fast to move around and making portals to the overworld in precise location is quite fast as well [especially if you show chunk borders with F3] - Sending items through a portal could be automated or wired together in some way perhaps (+ using the "glitch" i said earlier on) - Shadowed items on chests + redstone comparator to use the player inventory to send a signal to multiple places or something (?) Idk. [This is possible, but not sure where to use it lol]
(Version 1.12.0 ofc)
r
Well the setup at the moment requires 1.12.2 (for the farmland trick of registering entities in chunks), and I'd be surprised if the setup you're describing would take a shorter amount of time to set up anyway. Yeah you're on the roof, but you're building way more stuff per chunk you need to load, and you have to find a repeatable way of triggering all that (it would need to survive a relog in singleplayer)
c
The thing is, we don't have elytra and overworld can have chunks in the ocean and stuff like that
r
If you can come with with a viable setup then let us know, but I'll need to see it before I believe it
c
I think the roof is consistent (even if not so good looking to see for that many chunks lol)
r
Yeah, but it adds a ton more complexity
Into an already complex build
c
Yeah i know this is complex above complexity, ofc my idea only works if what i described could be done relatively fast and.. yeah with more than a single attempt after a backup lol
1.12.2 is only annoying for duping, but yeah that's fine (it doesn't really matter much anyway and ok that farmland trick def matters)
Afaik shadowed item do survive a relog, but i think chest one do unlink, right?
If they don't, then the issue is reloading the whole thing in the nether, but i think a few netherwarps with RD32 can do it (just a few pearl throw on carefully placed portals with no overworld counterpart)
If they don't, then that's the reload i have in mind, since shadowed item can affect a redstone compator output and if many instances of these do it at the same time, then they are all chained together and can be reused endless.... to load like 5000 nether portals by just changing the itemstack in an overworld chest in spawn chunk you place somewhere
But yeah i'm not saying this isn't painful, especially the fact of building a portal for each chunk..
c
I wonder who is gonna try the speedrun
i hope it doesn’t have to be me
r
Maybe we do a Prototech Peaceful server lmao
c
lmao
that would be funny
c
Coop first completion seems realistic with multiple people
But also incredibly difficult to coordinate lol
c
but it needs single player
c
Oh cannot work in a server where all but one logs out?
Idk just wondering if this is singleplayer specific
r
Final bit can be in singleplayer, but I'm for sure not going to be doing all that by myself lol
c
you could make multiple tubs and synchronize the entry of the tubs
but that is complicated as hell
r
You would just have everyone else log out, and you'd have to wait longer and restart the server a bunch lol, but I think it should work in multiplayer
c
Btw i found a way to move outside of the server player (as the client player) in 1.9.x very easily. probably useless but now I see why they fixed riding mechanics by removing the player in 1.10 lol [it's also the easiest way to execute phantom mining]
I also almost found a way to get a chest from far away and return back, but sadly too terrain specific (or seems like both chunks must be loaded) [combining the fact the client player stays in the old chunk and the server player is in new chunk + calling code that tries to sync both "players" back to old chunk, thus getting items from far away and return magically back]
It's 1.9.x only so prob bad [no observer]
(This is in reference to how much i tried to find a glitch to load chunks far away and return to where I started XD)
m
The chunk loaders are just 1 chest per chunk.
c
yeah i dont understand how using nether portals is any easier
m
We don't even need to put hoppers in the cluster chunks, because we aren't even permaloading anything. We are just reloading everything after every attempt
c
permaloading would also make no sense since we have to relog every time
and also downsizing would be really difficult
c
Wireless loading those chunks on demand with item shadowing, but realized it is not necessary
If we just can load all them once for attempt
Not even my method does permaload anyway
(You can't permaload the nether)
c
what are you talking about
c
Doesn't the nether dimension stop loading when you leave it? [Outside of overworld spawn chunks keeping it loaded]
Ok i think that statement was vague, i meant we can't permaload chunks in the nether and also quit the nether to go to the overworld at the same time. (And that nullifies the whole point of having a wireless loading system)
(Without anything complex with overworld spawn chunks)
r
You're correct, the nether unloads if no one is there
c
i thought you meant permaloaders just don’t work
m
Also we need to add to the instructions to use the JVM arguments 
-Xmx4G
and 
-Xss4m
because otherwise it just crashes from out of memory. By the way, how many attempts do you guys need to get a chunk swap with the setup? I'm not getting any on my computer after 10 attempts or so.
c
range from 10-40 attempts
you are relogging after every attempt right?
m
Yes
I'm actually reloading a backup after every attempt
But so far it's just bad luck or my computer not being good enough to handle the setup
c
Your computer is definitely good enough. From seeing your F3 screen in a video you have the same specs as me
m
How long do I need to wait between levers 1 and 2 or does that not matter?
c
lever 2 unlocks a repeater so usually i wait a cycle
m
an autosave cycle?
or what cycle?
c
yeah, rpm shows in his video
m
Do you just manually count 45 seconds, or how do you know when the autosave cycle is over?
c
i think the piston that comes from the detector pulses
m
Something that confuses me, is after one of the failed attempts, I flew to the radiator, and the invisible chunk was populated. But my game wasn't frozen and I didn't have an async line. I'm not sure yet how that can happen https://cdn.discordapp.com/attachments/1378287996834414702/1484949542637015121/2026-03-21_17.15.25.png?ex=69c01687&is=69bec507&hm=a8e191e23f64877d54d4ecc9fee86d6b1b1cdbc770be97f7cf1a55914e5c0e03&
The world file definitely has the invisible chunk unpopulated
even ungenerated
c
you probably unloaded the observers when flying over so no lagspike
m
... I don't quite believe that explanation?
The invisible chunk gets loaded way before the observers at the player platform get unloaded
There are like only 32 chunks between the invisible chunk and the observers, and the player loads a 64 wide strip of chunks
c
did the chunk get unloaded at all or anything? because we do know the savestates only work if you relog
the chunk is out of view distance
m
Yes. But right after using the setup, if I fly to it quickly, I should either find an invisible chunk.
Or if the invisible chunk unloaded already again I should find that my game freezes
Anyway, I'm going to do more testing
c
maybe somehow i broke the line in the world download? i will check in a bit
m
The line looks fine actually
If you need to wait an autosave cycle between lever 1 and 2 then we need an autosave detector, because there is nothing indicating when the autosave cycle is over on a vanilla client. I'll guess I'll try using a 45 seconds external timer right now
c
you can also check file last modified to see an autosave
m
That's actually really good
Invisible chunk is populated again, but no freeze or async line. It seems to populate before the cyan line loads the required chunks
c
did i maybe mess up the budline?
m
Nah, the invisible chunk generator works if I don't do anything else, so the budline is fine
c
you can maybe run the setup on carpet so you can use chunk debug
m
c
if it looks like that it can’t be any good
@rpm0618 how bad though
Does this happen every single time?
m
Yes
c
Okay, then probably not a hard fix
hmm i am not managing to reproduce the 0 tick issue
unless itt is off
isnt the cyan line supposed to come after the invisible chunk?
m
The setup is probably fine. The cyan line only breaks if I fly to the invisible chunk and come back, but that's ok
I'm just not getting the chunk swap so far
c
so flying over probably turns itt off
m
yes
c
I am going to try and get a chunk swap on the world file i sent incase i did something bad
m
Thank you very much for your work
Ok, I think the setup is fine. The invisible chunk just populates without freezing the game when you fly over, because when you fly over with view distance 32 you turn off ITT before you populate the invisible chunk
I'm just getting bad luck with the chunk swaps
c
I will try it more later. What really matters is we get at least one chunk swap with the world file.
if someone feels like it they can code a profiler server so people can know how well it will work and stuff
r
You don't need to wait a full cycle, and there is an autosave detector, it's just not very visible or easy to use lol. The instant line next to line 1 is the autosave indicator (the one that 2 locks with a repeater). When you flick lever 1, it will pulse once then turn off, then you should be safe to flick lever 2 off. I'm not at home, on my laptop atm. Can try a little for a line, but don't have a ton of time. https://cdn.discordapp.com/attachments/1378287996834414702/1484975140793221211/image.png?ex=69c02e5f&is=69bedcdf&hm=2e0d6a2c26eda4e70a8050c84fb53ef3dca2ecaa789c46a836de6eb6fd73eedd&
c
i see
r
profiling server is a good idea, I can work on this tomorrow probably
c
Okay. I dont have time to make one so if you can that’s great.
Someday i will add profiling features to vastech carpet
r
Has anyone gotten a line with the world download yet, or should I start trying?
c
if you could try that would be good
r
I got tired of the piston failing to push me, so I did what I probably should have done initially and replaced the water tub with a minecart on a rail that the piston pushes instead. I also updated how the cluster is loaded so that it no longer loads it upon load, instead there's an explicit trigger for the autosave. I can confirm that the setup is acting correctly (void chunk is correctly triggering the rehash while the glass thread is running). Unfortunately, I still wasn't able to get a line. It seems like the thread is no longer living long enough, it isn't making it to the end of the rehash. Not sure why that's happening now, maybe the rehash is slower for some reason? We have some leeway to increase the cluster size, but that would involve moving the setup (or at least the glass chunk part). I'm going to try increasing the number of stained glass moving in the chunk tomorrow, see if that helps first before I commit to moving things. I don't yet have a good handle on how much longer the rehash is taking. https://cdn.discordapp.com/attachments/1378287996834414702/1485469088477085837/peaceful_improved_nonactive.zip?ex=69c1fa65&is=69c0a8e5&hm=0aeea5ff30b8e5720ceb380100968d41187b511ec79989d3d2878060f8a49b2b&
m
That does look much better than the unnecessary water stream. Haven't gotten an async line yet, but this is definitely an improvement
r
Okay, I was able to get a line with this world but I wasn't recording (was also in carpet), I'll see if I can get one again. I added a second piece of stained glass, but I don't think that was what made it work. I also changed the procedure slightly, instead of restarting the server between each attempt, I waited a while to let anvil finish working through it's queue. My rationale for that is I was seeing the first rehash take too long on every single attempt when it was on initial world load, and something needed to be cached/jitted/whatever to make it work more reliably. I'm currently using a mod that tells me when the queue is empty. If that ends up being the reason, we can add a hopper clock that the user will need to wait out before trying again, and just make sure it's long enough for most hardware. https://cdn.discordapp.com/attachments/1378287996834414702/1485773204193542236/peaceful_improved_working_nonactive.zip?ex=69c315a0&is=69c1c420&hm=f0f0ff0023e0871028dad9947e959c4943bc3d316997c2541f17aee921ed1229&
c
oh thats amazing
r
Okay, video incoming. A couple of things to improve: 1) On both attempts, the line managed to brick itself slightly and needed to be repaired. Potentially this is because of the two stained glass threads and getting rid of one of them will fix that? 2) We need an easy way to replace the final observer in the line when it gets bricked. 3) I am so bad at survival minecraft lol. Please don't make fun my word tearing attempt 🤣 https://cdn.discordapp.com/attachments/1378287996834414702/1485784803105312768/0001-48841.mp4?ex=69c3206d&is=69c1ceed&hm=a1784c0f2cfa8e1dcdf1775a231f61b82e548a109e55a0b2c8182e89a31d72e9&
Okay, got a line with only 1 glass, and the line still partially bricked. Another weird thing, the item frame keeps popping off, I'm not sure why that's happening.
c
bricked?
r
Some of the observers get perma-powered (see around 5 mins in the video above)
c
just replace the observers past them
r
They just need to be replaced, but I'm not sure why that's happening
c
because they are async lines?
to replace it we need to dig under, when testing word tearing i use a piston ti reset but myren told me in a youtube comment that its bad to do that
r
lmao yeah, but that should only really happen when two threads are updating the same long I thought, and I don't think that's happening here. Perhaps I just don't understand the bricking behavior as much as I thought I did
The palette is directly underneath, although I guess at this point we don't need it anymore so it's okay to destroy it
c
yeah
r
Okay, got a line in singleplayer as well. I'll clean up the world a bit and post it
Instructions: 1) Relog against cobble wall 2) Flick lever 1 3) Wait for the line that is being locked by lever 2 to blink once and then turn off 4) Flick lever 2 5) Enter minecart 6) Wait for noteblock 7) Flick lever 3 8) Press button 4 (no need to wait for lagspike to finish) 9) Wait for piston to push you In failure case: 10) Get out of minecart 11) Flick lever 2 12) Flick lever 1 13) Press button 5 14) Align agaisnt cobble wall 15) Wait for lamp to turn back on (~2.5 minutes) 16) Repeat from step 2 In success case: 10) Get out of minecart 11) Flick lever 2 12) Flick lever 1 13) Do word tearing and beat the game. If no success within 5-10 attempts, it's probably a good idea to reload from a backup incase something broke in the setup. https://cdn.discordapp.com/attachments/1378287996834414702/1485818996757500065/PeacefulInactive.zip?ex=69c34046&is=69c1eec6&hm=0818d836d8d2d39663ed896985dee9afc44b4be29bd0a8fc1aedd8983ce48333& https://cdn.discordapp.com/attachments/1378287996834414702/1485818997374193717/PeacefulActive.zip?ex=69c34046&is=69c1eec6&hm=511c7867472ead31d8367a545e4617fe3a57e26eca7c9386a6e9d50f78d16ee6&
c
nice
r
Now it just has to work on myren's pc for the video lol
c
oh yeah a video
r
I'll hopefully have time tomorrow to work on a profiling server, extracting the code I have in my custom carpet into something that people can use to verify
c
i cant reach button 5 do i need to get out of the cart
r
See step 10 🙂
c
oh i got confused with 4 and 5
somehow
r
I think in your previous labeling that button/lever was step 5, that's probably what happened lol
m
Thank you very much. I'll try to get it to work on my pc, but if I don't get it to work within a few days I'll make a video about it anyway
In vanilla singleplayer with extra memory
I do agree the observers get bricked in rather strange ways
Ok, I managed to get the async line and get the word tearing for the end portal in vanilla singleplayer.
I'll record a singleplayer video showing how to use this thing and get the end portal, and make power point slides explaining the history of the challenge and the mechanics we use. But additionally it would be nice to have a joint recording session where we give a tour through the setup and show all the various parts.
@rpm0618 @CactusCreative @Crafterdark When would you have time for a video recording session about the peaceful async line setup?
Also @Crafterdark can you write up a summary of the history of the 1.9+ RSP challenge? How long have you been thinking about this?
r
Awesome! I'm free after today, or after tomorrow
m
I have time after today, but I won't have time tomorrow at .
r
I probably can't record Thursday, but I'll be free after on Friday, and then the weekend should be wide open
m
I'll also have a lot of time on Friday and the weekend
c
I will see what I can do. I am best on the weekend or Friday.
Hopefully sooner but if not the weekend i can for sure do
Would you think it would be good to use my server or do you have something you would rather use?
My time zone is CDT. 3 PM for me is for you.
i didn’t realize that the async line was there. Maybe I should have not taken the schematic from my peaceful unload setup and instead built it from scratch in a way similar to the itear where the palette is above
m
If you have a server, we can just use that.
c
Perfect.
Same thing I used when we all developed on the setup together.
However I fixed the ban code so it doesn’t randomly just not accept people
c
A long while haha. I might try to do it soon. So tldr: how many cluster chunks are required for the above method? (Sorry I don't have time atm to check better)
c
4200 i believe and a bunch of extra chunks
c
If only we could load chunks in a grid with some bug lol
c
why
we should not permaload anything
c
But you have to load those specific 4200 chunks still
c
yeah so we use a chest grid
c
Yeah i meant that, skipping to place the chests lol. (But ok not happening lol)
I was speaking in a speedrunning point of view btw. Heh
(Because ofc an alternative that does the same as placing all those chests on 4200 chunks would be faster likely)
c
i really hope someone does the run
c
Still I'm quite hyped to see the any% RSP 1.9+ first run
It's been years xD
Sending minecart chests to specific chunks 🧠
c
huh
c
Jk, i wish
Or at least the idea wouldn't be bad if we could, but i doubt there's anything in the code
Or only regular chests work?
I'm not entirely sure if we use chests to temporarily load all chunks in a "chained" fashion or if it's a way to keep them loaded until the next autosave
c
only regular chests
the reason chests even losd chunks is because they check if they are a double chest
c
Because if i understand correctly, all we care is that these chunks (after loading a large area with RD) are loaded for longer than those that get unloaded so we cluster a specific (target) chunk in the hashmap
Oh xd
So they all get chained and then the next autosave they all unload right?
c
yeah
it is a chain
used for most cluster loading
c
Ooh i see, but only one chest is required? If yes then i might be overrating the time required lol
c
only one
oer chunk
c
Oh.. ok then it's much faster than i thought (well still 4000 ones..)
Placing chest WR :tf:
c
plus like a thousand or so extra chunks
m
I just counted the chests in mc-edit and it appears there are only 7703 chests in the whole chunk loading grid, including the extra chunks
I expected this to be much higher
c
my guess was 8k, close enough
m
Those tree shapes are insanely efficient
c
yeah, i added a thing to my carpet so i can use earths finder and import a tree because i like it so much
r
Oh that's neat, didn't know mcedit had a feature like that. And that number tracks, it's a little more than the full amount of cluster chunks which makes sense.
m
If you select a region, and click "Analyze" it gives you a list of what blocks there are.
c
couldnt chests in structures count then
m
My mc-edit selection was at y=256
c
ohh i see
i thought you meant region like mca region
m
Btw, instead of recording something on the weekend, I would prefer to just get it done today. rpm said he'll have time in 1.5 hours, and we don't necessarily need Crafterdark in the video (although he will be mentioned in powerpoint slides). @CactusCreative Do you have time in 1.5 hours or so?
c
I can try to.
m
rpm said he has "time after that". So we can also do it in 2 or 3 hours if that fits better for you
c
at around would be ideal
m
That would be fine with me too
@rpm0618 Would today in 3 hours be a good time for recording for you?
r
Yes, that works for me
c
Perfect
So basically we just need to give the viewers a tour of the setup?
m
We first record an intro, and then a tour of the setup.
c
Ah okay.
m
Video Structure: 1. Intro, including rpm and cactus 2. Power point slides, history of peaceful challenge 3. Singleplayer instructions for using the setup 4. Instructions for building the setup, including rpm and cactus
c
And the setup is now 100% complete?
m
I managed to get an async line and the end portal word tearing in full vanilla singleplayer
c
ok
m
And I wasn't even sitting in the minecart when I got the async line because my chunk saving thread was just that overloaded, lol
c
is the line being bricked too much of a problem since the user will probably snake the async line their own way
and of course the water being updated is slightly bad
m
It is really not a problem
It is just super confusing, because the async line has no reason to brick there
I don't understand it at all
Yes, you just have to place a block there after getting the async line
c
could decrease chances or potentially cause a wet floor maybe
m
Tour: 1. Go to rehash chunk, explain that it needs exactly 4 chunk sections 2. Go to liquid radiator, explain what chunks to savestate, and that the radiator needs to be tested 3. Show the cluster loading grid 4. At player platform, explain how to adjust the time for clearing the chunk saving cache
That's what we will record together
c
okay
m
The rest I will record on my own
r
Glad I'm not the only one confused by this lol
c
Hi, i'm quite busy, not sure if I can contribute in the video itself, but I will write my short essay of the history of any% RSP 1.9+ from my old failed ideas if you want haha
m
Yeah, that would be helpful for my power point slides about the history of the challenge.
How long have you been working on it?
c
(In all seriousness, depends if you want this to be done asap or in like a week, because despite my long essays, i don't have that much free time lol)
Obviously on and off for years, by scattering ideas there and there in #glitched in javacord, surrending and going back months later cyclic XD. My most dream idea was to find a block data changer (kinda like damage value changer) or RNG manip of the portal room. [Technically the first one is what blockstate corruption is, even if i never thought it would have used multithreading exploit in a singlethreaded game haha]
m
This doesn't need to be finished right now, it would be nice to have it in 1-2 days or so
I will definitely quickly go over RNG strategies in my power point slides.
c
I also very recently checked the code and technically the RNG strategy isn't completely impossible (but i also think it is inhuman to apply in a real world). Very short explanation (i promise): The stronghold generation is after mineshaft and villages and if I get it right, you can probably hope for a portal room in a mineshaft/village chunk with something observable by a redstone comparator / observer / similar thing to "arbitrarily extend the RNG". The only issue is that this only moves RNG by 1 linearly so you'd still move in a strip and it's likely still a trillion chance. (Correct me ofc)
Or at least, you'd have to reverse the RNG to know the advances and that breaks the random seed rules xD
(This is also a reason for broken 12 eyed portals, but y'all know that probably)
Only objection is that we know how many 12 eyed strips there are in the Java LCG when linearly moved, but i think it is seed dependent for the advances as well (speaking vaguely since it is mostly a theory)
Ok well now you get a short summary of one of my recurring ideas, if you want to debunk/mention it c:
Given this is truly infinite advances (1) and that we could somehow use a way to know the advance by some any-world-manip (2), then this idea would make sense, but in practice i'm very aware this is very difficult to be real in practice
c
We are gonna use the inactive setup right?
c
One idea (maybe useless but relevant to skipping the chest with books) Let's suppose i create an invisible chunk with RD of a chunk that is still ungenerated. Then i create a redstone suppressor and then in the exact moment i place a block that loads the chunk, this triggers the suppressor. This should skip the population of the new chunk and crash? Or can it still be caught and skip population? Not sure what would happen lol.
For reference, you can place blocks in ungenerated chunks in ghost dimension and population never triggers but can re-trigger when you reload the game
(I tested by placing stone in the overworld-end ghost dimension and seeing diorite/andesite/etc at their place, so you could place blocks but see the population phase run at a second stage)
Obviously, you'd use what i said to place an observer cycle to get ITT/IF

https://youtu.be/gIFTcA0mjlE?si=JcI_dGqAcWSmclv4▾

This video in other words (and the redstone suppressor idea)
m
Yes, we will just give a tour around it.
c
(Ok i'll just try it and see). It could be used to replace savestates, but i don't know if it's worth that RNG xd
c
In just a second i am going to turn on the server
@Myren @rpm0618 same ip as last time
oh shoot my view dist is 10 still
well we are not using the setup so its fine
ill use carpet to increase
ill just keep it at 10
so you can successfully join
we are not using the setup anyway
m
It might still take a few days before I finish the video because I got seriously sick yesterday. Once I get better I should be able to finish it in a day.
c
Alright, get better soon.
r
Nw, feel better!
c
Hi, get better!

▾

🎆 (now someone must run it heh)
(Kinda salty that the only designs that work require the most [4000+] cluster chunks XD) ||(It would be a free WR still c:)||
c
yoooo
c
Is it realistic 15s for placing each chest? If if is, then 16 hours nonstop lol
c
yeah if you fly hack and air place
no
c
Ah wait i'm confusing
That's the other way around xd
Ok i'm speaking of overworld - nether one
Which is convenient if you could actually get it (you can't)
And that would still only place stuff in nether
I guess my idea is only realistic in the nether (horse/minecart + nether roof)
But i know, the moment you create an async line, boom, all gone :tf:
If only there was an alternative to chest that was an entity
(I guess there's not)
Falling Chest xd (i'm clearly joking but)
c
wed need cluster chunk grid for getting falling chest
c
2050 strats be like, finding a falling block all you want glitch to create falling chests to send by netherwarp to specific coordinates so we skip 16 hours worth of walking + 16 hours of harsh terrain 🔥
I mean sure you gotta send 4000 falling chests to specific coordinate, so ok maybe it's not that big of a skip
ACE to create an elytra in 1.8 to do the run faster (coping). This category just doesn't want to be done fast ig lol.
But still, insane that we got a working setup, going to take 24h+ but would be historic for sure.
c
whos gonna do the run
because someone definitely will i know that for a fact
i just hope it isnt me
r
Prototech peaceful server when
c
If only ghost dimension allowed something more to be used (but ok ig i can't see any usage of nether - overworld. No terrain, no nothing. Only thing is ITT but nothing an autosave can't do)
c
oh that would be cool but someone would have to take the world into their singleplayer
i know the speedrun will be done though
i just hope i dont have to
c
Surely we can find an usage for the integer limit items of 1.9-1.10 or the ghost hover with pearl when riding an entity (1.9.x only)
In 1.9 you can completely split from the server side player (in singleplayer), but that doesn't help too much i guess [no interaction when you go outside build reach]

▾

i doubt it will ever help, but in case there's something useful to it. Too bad it's 1.9.x only so the 1.12.2 requirement (for farmland trick) is broken anyway
m
@rpm0618 @CactusCreative It looks like there are often naturally generated chunk loaders, like chests in dungeons on chunk borders, even in our setup. So for the speedrunners we need to find a vanilla way to count the total loaded chunk amount, or find a way to detect the chunk hashmap upsize. The detection mechanism doesn't need to be automatic, it just needs to be something the player can notice. The most promising way to detect the chunk hashmap upsize would be to put a lag machine in the glass chunk. Before the upsize the glass chunk is heavily clustered, so you really notice the lag, but as soon as you upsize the lag goes away.
My ideas aren't fully worked out yet, but we need to add a chunk hashmap upsize detector, so people can tell whether they have the correct amount of chunks loaded. This detector would just be off when actually using the setup, but you would use it once before operating the setup just to tell that the number of loaded chunks is correct.
I think for the upsize detector we just need to put a redstone clock in the glass chunk, and add a line that allows you to turn it on or off from the player platform. If you turn the clock on, and it's really really laggy, then you know you haven't upsized yet. If you turn it on and get no noticeable lag, you know you upsized already. https://cdn.discordapp.com/attachments/1378287996834414702/1487371963340034129/2026-03-28_09.44.09.png?ex=69c8e696&is=69c79516&hm=43c7ee1b018e7fc6232db09b7150c1358078f46a5aa76a723ef8ce9e88d0ce31&
This would then be a vanilla way to tell whether you have too few or too many chunks in the setup
Another completely different thing we should consider adding is a "savestate breaking" detector, that automatically turns on a lamp if some savestated chunk got broken. I'm not yet sure how to detect that, but it should definitely be detectable as well
r
I suppose loading the world in a separate verification server to verify the cluster & chunk loading grid is out of the question?
m
We are allowed to make backups as far as I know, but I think we are only allowed to interact with them in vanilla.
Just putting a redstone clock in the glass chunk and measuring lag is actually a shockingly easy solution for detecting whether we have the right hashsize
c
oh god
finding those chests will be so difficult
m
You don't have to find the chests. You just need to measure how laggy a redstone clock in the glass chunk is, and then adjust extra chunk loaders accordingly.
c
Oj right
m
If you put a clock with a lot of dust in the glass chunk you can easily tell whether it has 4000+ clustering or 0 clustering
c
you dont need to break the bad ones
m
and then you know whether you have the right hashsize
c
then i guess you can repeatedly do that
m
We might need a contraption where one can easily adjust the amount of extra chunks being loaded, to make this process easier.
But I'm not entirely sure how it would look like and what exactly it needs to do
c
chests cant be pushed with pistons
this might be really stupid, but maybe double chests wont check if they are a double chest in another chunk if they find out they already are?
wait
we cant push the extra chest even if this did work
m
You don't need to use chests for chunk loading, unless it's convenient
c
true
it is quite convenient though
m
99% of the chunk loaders should indeed be chests
But we could maybe have 1% of more complicated non-chest chunk loaders that can be toggled via redstone from the player platform
c
yeah for some reason redstone chunk loaders are super laggy
thats why i didnt make the multi async line setup forge friendly
m
I don't think we will get more than 50 naturally generated dungeons with chests on chunk borders. So if we just have 50 chunks whose chunk loading can be toggled from the player platform, and add a lag-o-meter at the player platform and a clock in the glass chunk with redstone dust, then we should be fine
c
yeah
what about those other chunks that get redstone loaded already
m
Those other chunks are necessary for the contraption
c
oh
m
I want to take away 50 extra chunk loaders, and add 50 toggleable chunk loaders somewhere else
c
for some reason i thought that they were just loading some extra
that sounds like it should work
two ideas for that, one being really stupid 1. make a computer to disable some (lets not do this) 2. just make them walk down the redstone lines and flick off some repeaters
let me just design something for the first one really quick
r
Those are needed because the player moving adds chunks to the hashmap before it unloads the others. So in order to keep the chunk hashmap from upsizing to early, we keep 65 (RD * 2 + 1) chunks unloaded, and then right before we do the attempt (but after the player has moved) we load those extra chunks on the orange line to get us up to 12288
c
i see
m
I'm considering a new savestate concept where you just directly dispense book items into the chunk. If you have one dispenser filled with stacks of type 1 books, and one dispenser filled with stacks of type 2 books, and activate them in an alternating fashion 50 times, then you should get in the entity list of the chunk the books in an alternating fashion that can't be data compressed (as long as the chunks stays loaded. If it becomes entity-processing the book items might stack together). https://cdn.discordapp.com/attachments/1378287996834414702/1487549594492604426/2026-03-28_21.28.55.png?ex=69c98c04&is=69c83a84&hm=bcdfd106d2118d8ed9b55fad4362cdadd304480ab0218ac025bde60dd5474202&
This would not only have the advantage of working in 1.12.0, but if we additionally combine it with ITT item duping glitches to dupe the savestate books instead of using savestates to dupe savestate books, then the savestates would not be broken by savestate failure from the chunk saving thread being overloaded.
but I still have to think about whether this really makes sense
c
that uses slime block
we need a different thing
m
Yeah, it's not that difficult to make a clock without a slimeblock
c
that should work
m
Also after thinking about it more, I think it's better to not put a clock in the glass chunk
but a short observer line
and then add a button at the player platform with which you can activate the observer line for a lag spike
and the lag spike will tell you whether you have 0 clustering or 4000+ clustering
Detecting clustering with observers in the glass chunks seems to work well. I put 14 observers in the glass chunk, and without clustering they create no noticeable lag at all, while with the 4000 clustering you get a 5 second lag spike.
The only issue for properly testing hashsize is getting the setup to a state where it actually has loaded all chunks except the rehash chunk. The setup seems to be in that state for less than a gametick, making it difficult to perform a measurement at the right time.
PreviousNext
Powered by