Hello there! I'm the one who found that 12 tall cactus at (0, 0) and yesterday we got a 19 tall one using multi-chunk seed finding (source). TheMasterCaver got the code analysis right but seed finding is never brute-forcing across worlds. There are way smarter ways to go about it. You can find the CUDA code used here: https://github.com/KaptainWutax/Kaktoos. The idea is to brute-force rng states right before the cactus generation code. Once such a seed is found, you simply walk back to the population seed and then back to a world seed. The theoretical max for a single chunk is indeed 90, but as you can see from the code a given chunk can place cacti in another one. Any given block actually intersects with 4 others pushing that limit to 360.
You can reverse-engineer the seed using my seed cracker showcased here: . Note that this only works for maps generated in 1.15 as I'm too lazy to support other versions.
Updating actually takes minutes. The reason is that fabric only has 2 hooks into the game and doesn't need recompilation. It uses a framework that allows you to inject directly into the bytecode called mixins(https://github.com/SpongePowered/Mixin). The decompiled source is only there as a reference and will contain errors. Additionally, the mappings provided by yarn(https://github.com/FabricMC/yarn) are free of use and any community member can PR to it, making deobfuscation extremely fast.
Point is, your implementation only offers a slight performance boost and fixes entropy issues that an average player is completely blind to. I honestly do not see a point in that since a multithreading friendly datatype is quite handy. Using smaller LCGs for feature generators also sounds a bit weird to me, how are those executed?
This piece of code has been added in 1.9 and helped boost seed cracking into levels of insanity. I am also well aware of the weaknesses of LCGs. When it comes to world generation, the bias is immense but for the average player, it is random enough. I find beauty in the fact that some seeds have extremely exotic features.
Either way, a (properly used) 64 bit RNG is 65536 times harder to crack - the thread I mentioned before said it took 8 hours for an average gaming GPU to find a match - which could instead be 60 years (Mojang already uses a 64 bit RNG for the biome generator, the only place in the code that uses it; even a randomly generated world seed will use Java's Random for only 2^48 possible seeds, plus every 32 bit value which isn't available from Random.nextLong, so most worlds will only take advantage of 1/65536 of the available seed space, making it much easier to find a biome match after you've found the 48 bit base seed since you only need to find the full 64 bit value that can be generated with nextLong).
When it comes to your random implementation, it does indeed help with the entropy but it stills has its flaws. An LCG at its core is still only slightly safer than a number line; you have just obfuscated the problem. If Mojang ever makes the LCG 64-bits, building lattices for decorator features would be the way to go.
It is possible to reverse-engineer a seed by brute-force within a reasonable amount of time if you know the locations of structures and biomes but this requires advanced programming knowledge (I'm not sure how hard GPU programming is but this will never run in any reasonable amount of time with an ordinary CPU-based program, which I could write in less than an hour, since up to 281 trillion seeds need to be checked (then you need to check up to 65536 seeds for the biome layout, possibly more if there aren't enough structures; this is only possible at all due to the RNG used by most world generation only using 48 bits, making the search 65536 times faster), plus I don't have any source code for the algorithms since 1.13, which changed the way many structures are placed):
If you don't enter a seed the game will choose a random seed, which will also always be a number and virtually always different (just storing "randomseed" would mean that every "random" world would have the same seed, otherwise it would still need to save an actual seed value or it would have no way to save the seed across sessions, which would completely mess up world generation. If you enter an alphanumeric seed it is hashed to a 32 bit integer; "0" is treated the same as entering nothing (it is perfectly valid to use 0 as a seed, and possible to enter a string that hashes to it, the game just needs to reserve one numerical value to tell it when to use a random seed).
It is extremely reasonable to brute force a seed on CPU actually. The trick lies in using the end pillars:
Random rand = new Random(worldSeed);
long pillarSeed = rand.nextLong() & 65535L;
List pillars = IntStream.range(0, 10).boxed().collect(Collectors.toList());
Collections.shuffle(pillars, new Random(pillarSeed));
As you can see, this gives us 16 raw bits of the structure seed, tuning the search down from 2^48 to 2^32. I recently made a mod for it, check it out .
0
Hello there! I'm the one who found that 12 tall cactus at (0, 0) and yesterday we got a 19 tall one using multi-chunk seed finding (source). TheMasterCaver got the code analysis right but seed finding is never brute-forcing across worlds. There are way smarter ways to go about it. You can find the CUDA code used here: https://github.com/KaptainWutax/Kaktoos. The idea is to brute-force rng states right before the cactus generation code. Once such a seed is found, you simply walk back to the population seed and then back to a world seed. The theoretical max for a single chunk is indeed 90, but as you can see from the code a given chunk can place cacti in another one. Any given block actually intersects with 4 others pushing that limit to 360.
0
You can reverse-engineer the seed using my seed cracker showcased here: . Note that this only works for maps generated in 1.15 as I'm too lazy to support other versions.
0
Updating actually takes minutes. The reason is that fabric only has 2 hooks into the game and doesn't need recompilation. It uses a framework that allows you to inject directly into the bytecode called mixins(https://github.com/SpongePowered/Mixin). The decompiled source is only there as a reference and will contain errors. Additionally, the mappings provided by yarn(https://github.com/FabricMC/yarn) are free of use and any community member can PR to it, making deobfuscation extremely fast.
0
Point is, your implementation only offers a slight performance boost and fixes entropy issues that an average player is completely blind to. I honestly do not see a point in that since a multithreading friendly datatype is quite handy. Using smaller LCGs for feature generators also sounds a bit weird to me, how are those executed?
0
This piece of code has been added in 1.9 and helped boost seed cracking into levels of insanity. I am also well aware of the weaknesses of LCGs. When it comes to world generation, the bias is immense but for the average player, it is random enough. I find beauty in the fact that some seeds have extremely exotic features.
When it comes to your random implementation, it does indeed help with the entropy but it stills has its flaws. An LCG at its core is still only slightly safer than a number line; you have just obfuscated the problem. If Mojang ever makes the LCG 64-bits, building lattices for decorator features would be the way to go.
0
It is extremely reasonable to brute force a seed on CPU actually. The trick lies in using the end pillars:
As you can see, this gives us 16 raw bits of the structure seed, tuning the search down from 2^48 to 2^32. I recently made a mod for it, check it out .