Glitch_ placing block on non-visible side
Glitch_ placing block on non-visible side
This is a glitch which allows you to place blocks on the face where you
are not supposed to be able to look at. (e.g. placing a new block on the
opposite side of the block you are looking at)
Applications:
1. bridge/pillar downward
2. no looking back sprint(jump) bridge (ie. bedrock-like bridging)
3. other case that you’ll benefit from placing block where you shouldn’t be able to reach(but
the physical distance in within the reach)
2025/01/15 Update: This is not supposed to be an explanation doc but one for
research purposes, I was making a programming project so I procrastinate to study
this glitch since 3 months ago.
(Research hasn’t yet done so this is actually not intended to be public, but I’ll
continue the research soon. Please do proper credit if you’re make a video out from
here)
https://go.screenpal.com/watch/cZ6tXgncIP3
for pitch 0, z = 1, angle = 360/65536 deg (1 sig angle), the viable x coord will range from
0.000191748 ~ 0.0002876214
which turns out to be equal to position range that you’ll be looking on the left(pos x) side of
the block :
(ignore)
a weird thing I haven’t figure out is when have pitch 13 instead of 0, the range became
0.000191748 ~ 0.0002575299
Does not make much sense to me, a line parallel to y axis should be pitch constant
(edit: the ray moves out the bottom left edge of the block first, I’m dumb)
--------------------
Virox found something interesting - no looking back sprint jump bridge
(discord link doesn’t work: https://youtu.be/2vdWZH0RyBs?si=OxSRUKXcjWzk0fYu )
Sprinting forward without jumping is super easy with just spamming non-double click
butterfly https://go.screenpal.com/watch/cZ6tl1ncI9x
This works because we are in luck, we have a non-zero angle that does not move our x
coordinate when moving along the z axis.
This is an half angle (in this case, 0.00549 is the only numerical value within the same
decimal precision, so precise)
0.00549° Value Angle Index
Sin 0 0 0
Cos 1 0.005493 1 (16385)
Normal 1 (from mothball - a parkour movement simulator)
The sine part of the angle is working as it intended(floored down to 0), but the cosine part is
calculated with sine(90 deg - theAngle) and because of float point issue, it gets the wrong
value from the sine table. So here we have a non zero angle that acts like a zero on the x
axis. – further reading
---------------
The application is cool and fun, but what’s more important is to find why the glitch works –
down to the source code level preferably, but before looking at code I want to experiment
with the behavior of the glitch a little more.
I suppose aiming to slightly left to the “rib” of the block is always in the working range (if it
work at all), I made a quick code that generates tp commands for me when I input sig_angle
first attempt:
I had arguments set as default, zDistance = 2(to the front face of block), pitch 0, trying to
place the block at the back side. As a result, sig angle index from 1-63, only angle 1
works(being able to place blocks on the left side means not working). Which was
embarrassing. But clearly in virox’s clip he uses a different angle from index 1 (index 18) and
it still works.
Still I don’t know the exact reason, but further means wide angle range accepted from
experimentation. By making distance 2 -> 4, the possible angle-index range had increased to
1-3. Note that I wasn’t able to increase the distance more, because the whole time, I was
aiming at the back side of the block, the actual reach is 5, the maximum in creative. (angle
1-3 works in survival reach thankfully btw)
I claimed the only positive significant angles that could place block at the opposite
side is index 1-3
To extend the reach, we could try placing blocks at the bottom or top place which is also a
part of the glitch. That extends the reach by a block if we are aiming at the exact corner
closest to use on the left face. Quickly, I was able to get index 4 working. With more testing,
the angle range had become 1 - 475 (up to 2.60925292969 deg !)
https://go.screenpal.com/watch/cZ6tInncIWq
I also found factors other than distance, where you aim matters too. Look at this example:
475 works in survival, but 476, whatever I tried: creative mode, making the target block lower
to try out pitches, squeezing out more distance, it doesn't work, and that’s pretty strange.
----------------
Then I go looked at 1.8.9 minecraft’s code (the first time I do so lol, for this), I extract out the
possible related code that controls block-select/ ray-tracing
if (movingobjectposition != null)
{
return movingobjectposition;
}
}
if (flagAboutX)
{
deltaX = (checkX - rayOrigin.xCoord) / rayDX;
}
if (flagAboutY)
{
deltaY = (checkY - rayOrigin.yCoord) / rayDY;
}
if (flagAboutZ)
{
deltaZ = (checkZ - rayOrigin.zCoord) / rayDZ;
}
if (deltaX == -0.0D)
{
deltaX = -1.0E-4D;
}
if (deltaY == -0.0D)
{
deltaY = -1.0E-4D;
}
if (deltaZ == -0.0D)
{
deltaZ = -1.0E-4D;
}
EnumFacing hitSide;
if (!ignoreBlockWithoutBoundingBox ||
block1.getCollisionBoundingBox(this, blockpos, iblockstate1) != null)
{
if (block1.canCollideCheck(iblockstate1, stopOnLiquid))
{
MovingObjectPosition movingobjectposition1 =
block1.collisionRayTrace(this, blockpos, rayOrigin, rayTarget);
if (movingobjectposition1 != null)
{
return movingobjectposition1;
}
}
else
{
movingobjectposition2 = new
MovingObjectPosition(MovingObjectPosition.MovingObjectType.MISS, rayOrigin,
hitSide, blockpos);
}
}
}
return returnLastNonCollidableBlock ? movingobjectposition2 : null;
}
else
{
return null;
}
}
if (closestIntersection == intersectMinX) {
hitFace = EnumFacing.WEST;
}
if (closestIntersection == intersectMaxX) {
hitFace = EnumFacing.EAST;
}
if (closestIntersection == intersectMinY) {
hitFace = EnumFacing.DOWN;
}
if (closestIntersection == intersectMaxY) {
hitFace = EnumFacing.UP;
}
if (closestIntersection == intersectMinZ) {
hitFace = EnumFacing.NORTH;
}
if (closestIntersection == intersectMaxZ) {
hitFace = EnumFacing.SOUTH;
}
if the supposed ray collide facing is not detected(be set null), then it’ll be ignored.
if (d0 * d0 < 1.0000000116860974E-7D) {
return null; // No intersection if the ray is nearly parallel to the X plane