Minecraft physics? You mean gravity, fluids spilling, motion...?
Rollback Post to RevisionRollBack
I got into chiptune music composition.
You can listen to them on my Youtube channel : https://www.youtube.com/channel/UCjWYbJGk7nvNDbnCvMlZGkw
Descriptions are in french, you'd just need some google translation copy-paste...
Also made some more or less complicated datapacks, shared here (planetminecraft).
You can teleport 400 blocks away by headbutting Ravagers. This happens because the Ravager's special attack uses the equivalent of something like Knockback 40 or something totally silly like that.
Another exploit allows you to ignore the RNG as it applies to the Fortune enchant, guaranteeing that you always get the max amount of drops per ore.
Another exploit allows you to ignore the RNG as it applies to the Fortune enchant, guaranteeing that you always get the max amount of drops per ore.
I find this exceedingly improbable unless you are hacking the game or using advanced tools; there is a reason why they call it a "random number generator" and even if it isn't technically random (pseudorandom) you'd have to know the exact position in the sequence (2^48 or 281 trillion numbers long) at any given moment and exactly how many times you need to do something to advance it to the next point where Fortune yields its maximum drops, and avoid doing anything that calls it (I do know that somebody was able to exploit the enchantment RNG in this manner, but there is a lot more data exposed than a simple drop probability; you put an item in the table and check each level, repeat for different numbers of bookshelves, giving you many data points, then enchant and re-check the levels (which remain fixed until you actually enchant). However, Fortune III is a simple 1/5 chance of giving 2, 3, or 4 times the drops (2/5 for 1x), with only a single RNG call used).
The only way I could see this being exploited is during world generation, as the structure generator for villages uses the same RNG as the "World" object (this explains why sheep colors are bugged (unlike most mobs with variants their colors are linked to the chunk they spawn in, and are the same over large regions), since they use the same RNG immediately after the village generator).
That said, Mojang really needs to do more bugfixing; I doubt this could be exploited in TMCW since I use a separate RNG for structure generation (sheep still use a per-chunk seeded RNG so "pink sheep" seeds still work, but they are properly randomized from chunk to chunk) as well as block drops (I suppose one could still somehow crack the sequence but I also use a 64 bit RNG, instead of Java's Random, which only use 48 bits for 1/65536 times the sequence length - this is also why it is possible to find a world's seed by simply knowing the locations of structures, as something that takes 8 hours would take 60 years if they used a proper RNG).
I find this exceedingly improbable unless you are hacking the game or using advanced tools
Ask Gnembon, Ilmango, Docm77, or the other regulars on the SciCraft server. They were the ones to discover it, and they let MumboJumbo record it in a youtube video. It was discovered in the 1.13 era, and it was a completely accidental discovery resulting from the intended use of the redstone machine that exposed it. The entire exploit is essentially built into the game itself, and is exposed via the (ab)use of the redstone system.
If I recall what was said in the video, basically enough tick/update requests are made that it outright drowns out the RNG call so the game never sees the true result and for some really bizarre reason the game defaults to the max value instead of the base/min value. This could have been fixed since 1.13, though.
If I recall what was said in the video, basically enough tick/update requests are made that it outright drowns out the RNG call so the game never sees the true result and for some really bizarre reason the game defaults to the max value instead of the base/min value. This could have been fixed since 1.13, though.
This can't possibly be correct though; there is no way to "drown out" the RNG call or make it output a certain value:
/**
* Returns the usual quantity dropped by the block plus a bonus of 1 to 'i' (inclusive).
*/
public int quantityDroppedWithBonus(int par1, Random par2Random)
{
if (par1 > 0 && this.blockID != this.idDropped(0, par2Random, par1))
{
// Calculates drop multiplier with a single RNG call; Fortune III results in 5
// values from 0-4, with 0 being treated the same as 1.
int var3 = par2Random.nextInt(par1 + 2);
if (var3 < 1) var3 = 1;
return this.quantityDropped(par2Random) * var3;
}
else
{
return this.quantityDropped(par2Random);
}
}
// Same method as above but for redstone ore only; effect of Fortune is 0-level instead of
// being multiplicative.
public int quantityDroppedWithBonus(int par1, Random par2Random)
{
return this.quantityDropped(par2Random) + par2Random.nextInt(par1 + 1);
}
// This is only for redstone ore; other ores simply return either 1 or 4 without making another RNG call
public int quantityDropped(Random par1Random)
{
return 4 + par1Random.nextInt(2);
}
If this single RNG call were really broken there would be MUCH bigger issues as this would affect everything that uses the RNG (you'd even be able to manipulate world generation to e.g generate structures, including ores, where they shouldn't exist, or even change biome/terrain generation (excluding a case that relies on the way the game decorates chunks, where you can actually make dungeons generate by pushing blocks into the outermost edge of generated chunks, which are not decorated until the next row of chunks out generates, but this does not actually manipulate the RNG). You could also manipulate mob AI (random pathfinding), and much more, even game rendering - I can only see actual memory corruption as causing this to happen, and that can't happen in Java (buffer overflow attacks). Random is also threadsafe, so even if two threads accessed it it will still work properly (which shouldn't happen anyway for the RNG in question).
Either way, I can only see this happening if you were able to figure out the exact location in the overall RNG sequence; just because you got max drops one time doesn't mean that you'll get it after 5 more calls (only on average) and there is no way I can see even a known sequence being used to figure out where in the overall sequence it is (unless you had access to the output from nextInt() or nextLong(), which output 32 or 64 bits at a time; however, with Fortune III you only have 5 numbers to work with (a little over 2 bits), and only 4 of those are visible in drops since 0 is treated the same as 1; 1,1,2,3,4; so a sequence of e.g. 10 of these numbers will likely occur many times in the overall sequence).
The *actual* way it works is by setting the seed of the RNG. they cause so many updates that chunks are constantly, and consistently, reset, which means the seed of the RNG can be controlled, which then controls the value of the RNG roll.
The *actual* way it works is by setting the seed of the RNG. they cause so many updates that chunks are constantly, and consistently, reset, which means the seed of the RNG can be controlled, which then controls the value of the RNG roll.
This sounds like quite a major exploit if you can make the game reset chunks that easily (depending on exactly how they "crash" the chunks), and the RNG manipulation is due to sloppy coding, due to the same reason as MC-2788, which is caused by structure generation and sheep wool colors using the "world" RNG, both of which make no sense from a proper coding perspective; if you want sheep wool colors to be based on the world seed use the chunk coordinates to determine the seed during world generation spawning (as I do in my own code, which prevents the world RNG from being affected by saving the state before the chunk seed is set and sheep are spawned, then resetting it. If I ever modify sheep directly (I prefer not to modify or add new classes unless necessary) I'd completely bypass having to use the world RNG):
// Bad code (vanilla); uses a completely unrelated RNG in the World class
protected boolean canSpawnStructureAtCoords(int par1, int par2)
{
int var3 = par1;
int var4 = par2;
if (par1 < 0) par1 -= this.field_82665_g - 1;
if (par2 < 0) par2 -= this.field_82665_g - 1;
int var5 = par1 / this.field_82665_g;
int var6 = par2 / this.field_82665_g;
Random var7 = this.worldObj.setRandomSeed(var5, var6, 10387312);
/**
* puts the World Random seed to a specific state dependant on the inputs
*/
public Random setRandomSeed(int par1, int par2, int par3)
{
long var4 = (long)par1 * 341873128712L + (long)par2 * 132897987541L + this.getWorldInfo().getSeed() + (long)par3;
this.rand.setSeed(var4);
return this.rand;
}
// Called when a sheep is spawned uses World RNG to choose a color (even though every entity has its
// own RNG)
public EntityLivingData onSpawnWithEgg(EntityLivingData par1EntityLivingData)
{
par1EntityLivingData = super.onSpawnWithEgg(par1EntityLivingData);
this.setFleeceColor(getRandomFleeceColor(this.worldObj.rand));
return par1EntityLivingData;
}
// Proper code (spawnRNG is local to the structure generator; this code also applies a world-seed specific
// offset to the grid used to position structures within regions so they aren't the same for every seed; in
// vanilla villages can only generate at chunk coordinates 0-23 plus multiples of 32)
protected boolean canSpawnStructureAtCoords(int chunkX, int chunkZ)
{
int x = chunkX + this.offsetX;
int z = chunkZ + this.offsetZ;
this.spawnRNG.setChunkSeed(x / this.maxDistance, z / this.maxDistance);
// Hack to avoid having to modify/extend EntitySheep to use a proper RNG; ensures that sheep wool colors
// are still tied to the world seed (allows for "pink sheep seeds") without affecting the World RNG
Random rnd = this.worldObj.rand;
long seed = rnd.nextLong(); // Saves "seed" so it can be restored later
rnd.setSeed(chunkSeed + 4L);
this.rand.setSeed(chunkSeed + 4L);
this.performWorldGenSpawning(biome, blockX, blockZ);
// Resets World RNG (not to previous state but other than a "jump" sequence is unaffected by world
//generation)
rnd.setSeed(seed);
Does anyone know any ways to defy (not obey) minecraft physics?
Thank u <3
use a boat at the 255 block limit and ride off of it, you will fly
OG cavegame player
Minecraft physics? You mean gravity, fluids spilling, motion...?
I got into chiptune music composition.
You can listen to them on my Youtube channel :
https://www.youtube.com/channel/UCjWYbJGk7nvNDbnCvMlZGkw
Descriptions are in french, you'd just need some google translation copy-paste...
Also made some more or less complicated datapacks, shared here (planetminecraft).
You can teleport 400 blocks away by headbutting Ravagers. This happens because the Ravager's special attack uses the equivalent of something like Knockback 40 or something totally silly like that.
Another exploit allows you to ignore the RNG as it applies to the Fortune enchant, guaranteeing that you always get the max amount of drops per ore.
I find this exceedingly improbable unless you are hacking the game or using advanced tools; there is a reason why they call it a "random number generator" and even if it isn't technically random (pseudorandom) you'd have to know the exact position in the sequence (2^48 or 281 trillion numbers long) at any given moment and exactly how many times you need to do something to advance it to the next point where Fortune yields its maximum drops, and avoid doing anything that calls it (I do know that somebody was able to exploit the enchantment RNG in this manner, but there is a lot more data exposed than a simple drop probability; you put an item in the table and check each level, repeat for different numbers of bookshelves, giving you many data points, then enchant and re-check the levels (which remain fixed until you actually enchant). However, Fortune III is a simple 1/5 chance of giving 2, 3, or 4 times the drops (2/5 for 1x), with only a single RNG call used).
The only way I could see this being exploited is during world generation, as the structure generator for villages uses the same RNG as the "World" object (this explains why sheep colors are bugged (unlike most mobs with variants their colors are linked to the chunk they spawn in, and are the same over large regions), since they use the same RNG immediately after the village generator).
That said, Mojang really needs to do more bugfixing; I doubt this could be exploited in TMCW since I use a separate RNG for structure generation (sheep still use a per-chunk seeded RNG so "pink sheep" seeds still work, but they are properly randomized from chunk to chunk) as well as block drops (I suppose one could still somehow crack the sequence but I also use a 64 bit RNG, instead of Java's Random, which only use 48 bits for 1/65536 times the sequence length - this is also why it is possible to find a world's seed by simply knowing the locations of structures, as something that takes 8 hours would take 60 years if they used a proper RNG).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Ask Gnembon, Ilmango, Docm77, or the other regulars on the SciCraft server. They were the ones to discover it, and they let MumboJumbo record it in a youtube video. It was discovered in the 1.13 era, and it was a completely accidental discovery resulting from the intended use of the redstone machine that exposed it. The entire exploit is essentially built into the game itself, and is exposed via the (ab)use of the redstone system.
If I recall what was said in the video, basically enough tick/update requests are made that it outright drowns out the RNG call so the game never sees the true result and for some really bizarre reason the game defaults to the max value instead of the base/min value. This could have been fixed since 1.13, though.
This can't possibly be correct though; there is no way to "drown out" the RNG call or make it output a certain value:
If this single RNG call were really broken there would be MUCH bigger issues as this would affect everything that uses the RNG (you'd even be able to manipulate world generation to e.g generate structures, including ores, where they shouldn't exist, or even change biome/terrain generation (excluding a case that relies on the way the game decorates chunks, where you can actually make dungeons generate by pushing blocks into the outermost edge of generated chunks, which are not decorated until the next row of chunks out generates, but this does not actually manipulate the RNG). You could also manipulate mob AI (random pathfinding), and much more, even game rendering - I can only see actual memory corruption as causing this to happen, and that can't happen in Java (buffer overflow attacks). Random is also threadsafe, so even if two threads accessed it it will still work properly (which shouldn't happen anyway for the RNG in question).
Either way, I can only see this happening if you were able to figure out the exact location in the overall RNG sequence; just because you got max drops one time doesn't mean that you'll get it after 5 more calls (only on average) and there is no way I can see even a known sequence being used to figure out where in the overall sequence it is (unless you had access to the output from nextInt() or nextLong(), which output 32 or 64 bits at a time; however, with Fortune III you only have 5 numbers to work with (a little over 2 bits), and only 4 of those are visible in drops since 0 is treated the same as 1; 1,1,2,3,4; so a sequence of e.g. 10 of these numbers will likely occur many times in the overall sequence).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
The *actual* way it works is by setting the seed of the RNG. they cause so many updates that chunks are constantly, and consistently, reset, which means the seed of the RNG can be controlled, which then controls the value of the RNG roll.
Creator of Metroid Cubed 3, a Metroid-themed mod! Become a donator today!
This sounds like quite a major exploit if you can make the game reset chunks that easily (depending on exactly how they "crash" the chunks), and the RNG manipulation is due to sloppy coding, due to the same reason as MC-2788, which is caused by structure generation and sheep wool colors using the "world" RNG, both of which make no sense from a proper coding perspective; if you want sheep wool colors to be based on the world seed use the chunk coordinates to determine the seed during world generation spawning (as I do in my own code, which prevents the world RNG from being affected by saving the state before the chunk seed is set and sheep are spawned, then resetting it. If I ever modify sheep directly (I prefer not to modify or add new classes unless necessary) I'd completely bypass having to use the world RNG):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
It's actually incredibly complicated to do as you have to overload the chunk's block updates.
Creator of Metroid Cubed 3, a Metroid-themed mod! Become a donator today!