This reminds me of an infinite-distance teleportation exploit that we found in Minecraft since, for a few updates, Mojang were only checking for NaN values on the X and Y axes, checking the X axis twice.
You could teleport from [orig_x, orig_y, orig_z] to [orig_x, orig_y, NaN] and then to [desired_x, desired_y, desired_z] and since the Euclidean distance between any two consecutive position vectors would be NaN, dist >= kick_threshold always turned out to be false.
Which versions were those? Minecraft’s been rather uniquely plagued by this issue, tho I suppose it’s gotten better in more recent versions.
Due to the difficulty of trusting a JVM without value types to have reasonable performance when allocating vectors at a Mississippian rate, vectors were nearly always passed around decomposed. Doing crap like world.getBlock(x + dx, y + dy, z + dz) gets tiresome very quickly, and expressive power is not a noted property of Java. You might make wrapper types, but then find that you run into an issue akin to function coloring, or C++ viral constness. You’re still going to have to compose or decompose the vectors at some point, and there’s still the performance concerns. A script called xyz, which turns x + max, into x + max, y + max, z + max, allowed me skip past the traditional copy-paste bugs.
This reminds me of an infinite-distance teleportation exploit that we found in Minecraft since, for a few updates, Mojang were only checking for NaN values on the X and Y axes, checking the X axis twice.
You could teleport from [orig_x, orig_y, orig_z] to [orig_x, orig_y, NaN] and then to [desired_x, desired_y, desired_z] and since the Euclidean distance between any two consecutive position vectors would be NaN,
dist >= kick_thresholdalways turned out to be false.Which versions were those? Minecraft’s been rather uniquely plagued by this issue, tho I suppose it’s gotten better in more recent versions.
Due to the difficulty of trusting a JVM without value types to have reasonable performance when allocating vectors at a Mississippian rate, vectors were nearly always passed around decomposed. Doing crap like
world.getBlock(x + dx, y + dy, z + dz)gets tiresome very quickly, and expressive power is not a noted property of Java. You might make wrapper types, but then find that you run into an issue akin to function coloring, or C++ viral constness. You’re still going to have to compose or decompose the vectors at some point, and there’s still the performance concerns. A script calledxyz, which turnsx + max,intox + max, y + max, z + max, allowed me skip past the traditional copy-paste bugs.“I accepted the number of homogeneous blocks to be 5 on the average.”
Fascinating examples, although that assumption seems arbitrary.