Textures and Effects are off when far away from the center of the map

You'll see that the torches are in one place and the flames for them are in random places around them.

Also managed to reproduce at 10,000,000, 65, 0. Placed a single redstone dust down which rendered as a line.

Side note: entity count on debug screen changing rapidly for no apparent reason that far out.

It gets worse at 19999999 14 19999999.
The farthest you can go before it won't let you /tp anymore.
Which one is the Entity count?

E. Visible/Total. It shouldn't change too much when not moving around.

This is related to the Far Lands. Per minecraftwiki:

Redstone stops rendering and connecting correctly after block X/Z of ± 4,194,303
After X/Z of ± 1,048,576 redstone is still small but it got a little bigger and After X/Z of ± 4,194,303 it does not appear as a single pile at all except for the corners past X/Z of ± 8,388,607 where it appears as a very large pile until you get to X/Z of ± 16,777,216 the redstone appears two times the size of the large pile and could only render in certain places.

The title says that it is related to the Far Lands.
"Textures and Effects are off when far away from the center of the map"

Flower Pots have their own glitchy effect if you place enough of them in a row.

Anvils don't fall, they just break.

Okay. I guess as long as you KNOW that you're reporting something that isn't a bug, it's all right.

Spawning a Ghast crashes the game saying that Minecraft ran out of memory.

I liked the old Farlands better!

At least you would get all laggy for a reason; there would be these giant glitchy walls and stuff.

This is just bad textures.

While these large coordinate bugs may have many different reasons around the code, the redstone wire seems to have easy fix...

Fix for redstone wire

RenderBlocks.renderBlockRedstoneWire()

//        float var34 = (float) (x + 0);
//        float var35 = (float) (x + 1);
//        float var36 = (float) (z + 0);
//        float var37 = (float) (z + 1);
        double var34 = (double) (x + 0);
        double var35 = (double) (x + 1);
        double var36 = (double) (z + 0);
        double var37 = (double) (z + 1);

The 32-bit float simply run out of resolution/accuracy with the large coordinates. The solution is a bit of "ugly", but it got the work done, as I'm looking at perfectly fine wires at coordinates near X&Y of 17,000,000.

There are more unnecessary (and sort of harmful) (float)-casts in that same method, but they are for Y-coordinates, and since Y-coordinates are, for the time being, very limited, they do not show similar problems. (That whole class seems to be littered with those float-casts, many of which seem to be unnecessary and possibly causing similar issues for other blocks/visuals.)

Fix for torches

BlockTorch.randomDisplayTick()

//        double var7 = (double)((float)par2 + 0.5F);
//        double var9 = (double)((float)par3 + 0.7F);
//        double var11 = (double)((float)par4 + 0.5F);
        double var7 = par2 + 0.5D;
        double var9 = par3 + 0.7D;
        double var11 = par4 + 0.5D;

Same reason as for redstone wire.

I'm still not going to understand why this sort of thing happens.

Fix for fire's smoke
This time no source code as the changes cover almost the whole method. But its the very same fix, in BlockFire.randomDisplayTick(), change floats to doubles and remove casts to float when the variables are handling coordinates. This also includes sound generation coordinates.

Fix for rain

EntityRenderer.addRainParticles()

...
        if (this.random.nextInt(var14) == 0) {
//          var8 = (double) ((float) var17 + var22);
//          var10 = (double) ((float) var19 + 0.1F) - Block.blocksList[var20].getBlockBoundsMinY();
//          var12 = (double) ((float) var18 + var23);
            var8 = (double) var17 + var22;
            var10 = (double) var19 + 0.1F - Block.blocksList[var20].getBlockBoundsMinY();
            var12 = (double) var18 + var23;
        }

//      this.mc.effectRenderer.addEffect(new EntityRainFX(var3, (double) ((float) var17 + var22), (double) ((float) var19 + 0.1F) - Block.blocksList[var20].getBlockBoundsMinY(), (double) ((float) var18 + var23)));
        this.mc.effectRenderer.addEffect(new EntityRainFX(var3,
            (double) var17 + var22,
            (double) var19 + 0.1F - Block.blocksList[var20].getBlockBoundsMinY(),
            (double) var18 + var23));
     ...

There is one more similar bug just before the changed spot, for the case of rain falling on lava.

I'll leave fixing that and the rest of similar cases all over the code for Mojang. I think the fixes already provided should give the idea.

Rain? There was no issue with rain last time I checked.

Rain may have gotten fixed since, but at least in 1.4.7 (the version I can actually work with at the source code level) it has an issue; the drops/splashes are concentrated on block corners, and apparently on every second block's corner at that (or something).

Edit: nope, not fixed, rain still gets its splashes weirdly in 1.5.

They should undo the stupid 30,000,000 block boarder thing and then this problem would be solved. Anyway Minecraft is supposed to have infinite worlds, right? _

@Michael Connel
Easier said than done. Most of these high-coordinate problems come from the simplified coding used in Minecraft. It happily uses floating-point values (in many cases even just the 32-bit single-precision ones). These run out of resolution/accuracy even before reaching 1,000,000 coordinates. Doubles do add quite a bit more room, but there are still limits.

The proper solution is to use floating-point math only with relative coordinates, and integers for the absolute part. But that is the part "easier said than done". Things get complicated (and also slightly less efficient) really quickly, trying to keep all math correct when there are multiple frames of reference.

Note, that 30 million gives total range of 60 million meters, or 60,000 kilometers. That is more than the diameter of Earth. It also gives square area about 7 times larger than Earth's area, and Earth's area seems to be plenty for quite a few billion "users". (Granted, not everyone on Earth has his own castle, town, farm and a beautiful ocean view, but still...)

Please unlink MC-31653 as a duplicate of this one. It may relate to it, as well as MC-3493, but the problem described in MC-31653 is new to 13w38a.

In the newer snapshots, 13w38c included, these effects manifest as early as 50000. I would not consider that "far"; this dramatically reduces the non-bugged world's size. If MC-31653 will not be re-opened, please update this ticket's description and title to acknowledge that it happens at least as early as 50000.

Carl and Gerrard: I am unable to confirm 50,000. However, after much testing with 13w39b, I have found exact boundaries where these glitches start to appear.
Glitches begin exactly outside these boundaries:

x: 1048575 z: 1048575

to

x:-1048575 z:-1048575

Anything inside renders correctly. These coordinate matches with Markku's comment. Confirmed coordinates using redstone and flower pots.

Notably, this number (1048575) is exactly 1024*1024-1 (as computers begin with 0 for indexing).

Confirmed coordinates using redstone and flower pots.

Have you tried it with ice and the selection cursor? This ticket does not refer to those at all, and yet MC-31653 was closed as its duplicate. For me, redstone and flower pots don't begin to glitch at 50,000, but ice and the selection cursor do. They don't become giant or lose faces, but they do begin vibrating noticeably and erratically, failing to align properly to the grid, and it's extremely distracting. Sometimes the selection cursor will dip inside solid blocks, becoming invisible, for example.

The effect doesn't begin exactly at 50,000, but I'm able to notice it easily around 50,000 64 50,000 (that's both axes - I have a harder time noticing it when it's only a single axis). It progressively gets worse as you go farther from the origin, and is very blatant at coordinates such as 1,000,000 (notably less than your overflow figure). I'm just mentioning that it's noticeable at 50,000 because a coordinate like that is perfectly viable in survival (I've been that far quite a few times without cheats).

I can confirm that flower pots and redstone don't begin to glitch until 1,048,575 - but these really are different bugs. The redstone glitches happen in 1.6 as well (and date very far back). The ice/water/selectioncursor glitches did not begin happening until one of the snapshots changed how rendering works, and the not-affected region of the world for this bug is drastically smaller.

Also did my testing in 13w39b, and the issues are still present.

EDIT: Also effects entities as early as 50,000: very noticeable with paintings and item frames.

EDIT 2: Okay, I found an incredibly blatant way to reproduce it: toggle cinematic camera mode. In this mode, the cursor doesn't stop moving when you stop moving it, and the camera can continue to glide at incredibly small increments. The positions of ice/water/selectionbox/entities change any time the camera re-orients, even if nothing has visibly changed on-screen. Thus, if you try to keep your camera still in Cinematic Camera mode, you'll see the effected blocks/entities jitter depending on how far you are from the origin. I'll try to make a GIF.

Btw, the MC-10402 is also still in effect in 1.6.4.

Just adding water to the list of things that is off..and not just from water thats on the other side of the wall...so here have a pic that shows water not flowing with more of the redstone glitching. also I found that the redstone logic seems to still being working...if you can follow the redstone well enough to actually wire it up. Also just to let you know-it is still in 13w43a (see screenshots for proof)

Memory isn't an issue here either since i have 10 gb or so dedicated to minecraft when it runs...if thats a problem i can try without that setting in the launcher but i would expect similar results. my system is:
Win7 x64 SP1
16GB ram (10 to MC)
A8-3550mx
Radeon 7690m
Java 7 Update 21

Jumping in frames is gone, rendering of frames and contents of frames is still jacked.

when facing:
East Positive X: You are able to see what is in the item frame, however frame is nearly black.
West Negative X: Looks perfect.
North Positive Y: Color of item frame looks good, but you cannot see any item put into the frame.
South Negative Y: Same as North Positive Y.

From my testing. 14w10c - XYZ: 10Million , 70, 100

For some reason I can't reproduce this.

I can't reproduce this

Fluffy89502 - Your not out far enough...your at about 1,000,000 and most of these effects start out around 10,000,000 or so

On 14w11b at least redstone (wiring) has some rendering quirks at around 1,500,000 1,500,000. Didn't bother checking other cases or further distances.

Confirmed for 14w18a. Rainfall doesn't show properly when you're at 30 000 000.

well, try putting redstone in the edge :3

not fix :/

@alexzombie04 Not fixed in 1.7.10, the issue states it was fixed in Minecraft 14w32a

Tripwire is weird too so are couldrons

found first effects at 500,000 in 1.7.10

According to MC-72561 (and some of battlefieldkille's other issues), this bug is back in 1.8. (The issues are basically the same as this one and can be marked as Duplicates instead of just related 🙂)

MC-70646 (duplicate of this issue) is also for 1.8.

FallingSand entities have glitches too: They appear to be offset

I can confirm that there are some glitches near the world border in 1.8.2-pre4 - see http://youtu.be/VKb2Ejb35ls.
First of all, Pistons are glitching depending on their distance to the world border. A piston at 1,000,000 / 1,000,000 moves a little bit when retracting - if it is directly near the world border, it goes crazy (see MC-70646). Also, near the world border, the sound stereo system seems not to work correctly what actually depends on where you stand, in which direction you look and where the sound is played from.
Please reopen.

Confirmed for

• 1.8.7

• 15w36d

For:

• FallingSand

• Extending Pistons (animation)

• piston_extension

• Blocks that have special properties like sand, redstone lamps,... pushed "in" the worldborder

• Rain: MC-50142

Ticket is yours now, please update the description accordingly.

Falling Sand seems to appear offset from other blocks after 262144, tested on 18w02a.