Slow (Choppy) Rotating Beacon Block

I'm seeing this confirmed in many peoples' videos, though not in any of my personal experiences. On servers as well.

I think it is. I seem to recall some mindcrack videos on recent snapshots with the issue still present.

Ya its still of concern as of 1.4.7. I updated the affected versions, hopefully Mojang recognizes this issue.

I have found the cause of the problem
if you change the NBT tag Time and DayTime in the level.dat file to 0 (both have to be changed), it will fix the problem, and if you change it to a very high number it will cause the problem (i used 989210110 because it is from another world with the issue)

So the issue isn't connected to minecraft 1.0, but to the age of the world. If you can't wait for mojang to fix the issue, all you have to do is use NBTExplorer, open the world with it and change Time and DayTime to 0

Wow, thank you so much Jeppe Vennekilde! It worked like a charm! Props to you sir.

Probably caused by casting the world time to a float somewhere. Should be a really easy fix for Mojang, too bad they probably haven't seen it yet.

Ah, floating point precision errors. You have plagued us since the beginning. First you reared your head as we approached the farlands, now you show it again as time itself.

Confirmed for Minecraft 1.5.1; there's now also a painful Z-fighting resulting from this.

To repeat what I posted on another bug (so that it gets read and hopefully gets fixed):

... the real cause is the server sending a world time that is large, and because of how floating-point ( https://en.wikipedia.org/wiki/Single-precision_floating-point_format ) calculations are made, adding a tiny number (rotation amount) to a huge number (world uptime) tends to round down so far that it has literally no effect on the resulting number whatsoever. For an example of this, if you store the number 10000000000000000 as a single-precision floating point number, it rounds to 10000000272564224. Try to add 1000000 to this? The result is 10000000272564224, which is exactly the same as what you started with.

If the rounding error is fixed in the client (the fix I propose to craftbukkit is a hack to avoid the rounding error entirely, and is not the "real" fix), then beacons will rotate properly again. A cast to double would fix* this but that's cheating IMHO. The best solution would probably be to add the amount of ticks elapsed since last check to a tick counter (as float or double), instead of using the total world time, and then if it exceeds k (where k = 2pi / 1.5 / 0.025, determined from Minecraft's code as the rotation period of a beacon beam in ticks) subtract k from it. Saying that, since beacons have rotational symmetry every 90 degrees you could probably get away with k/4, but since there's very little granularity with numbers that small anyway, saving 2 mantissa bits won't really net you much benefit.

*Casting to double as the solution would mean it still suffers rounding errors, it'd just take much longer until it happens.

Another option is to use world time, but modulo one day (so animationTick = time % 24000), if the animation loops like that. Actually, the ideal solution would be to figure out how many ticks it takes before the animation loops, n, and make animationTick = time % n.

24000 does not evenly divide by pi, and using time%n is pretty much what they do now (it's done implicitly in their call to sin/cos) - it will be affected by the same rounding error, except at a different point in time (it will result in the beacon performing a very small turn then resetting to its original position over and over again, a visual analogue to the sound of a broken record).

Can you please show their code? I haven't seen the exact code they're using. Also, I think it's safe to say no integer will ever divide by pi, meaning any fix must be an approximation. In fact, does Minecraft even use explicit calls to sin/cos? Last I checked, they're using an approximate lookup table, built at the game's startup, to speed up calculations.

Now, I might be able to explain my solution better if I knew what measurements were used here. But hypothetically, if it takes 80 gameticks (4 seconds) for the beacon to complete its spin, the rotation would be (2*pi)/80 radians per tick. Now, obviously, you can't safely increment the rotation angle by (2*pi)/80 every tick; the rounding error would add up. But if you recalculated the angle, as (2*pi*tick)/80, you'd end up with a value as close to 2*pi as you'd ever get: Java uses an intermediate 80-bit floating point format when doing calculations on most machines, even on floats. Thus, there would be no broken record effect: if the animation takes 80 gameticks, doing time % 80 would allow you to retrieve the correct rotation angle.

If they're relying on sin/cos for its "modulo effect", then of course it's not working: the larger the angle becomes, as a floating point value, the less precise it gets. The pitfall of floating point values is that, at large numbers, the gap between successive representable values increases. ((2*pi*time)/80) % (2*pi) is not equivalent to (2*pi*(time % 80))/80, even with the internal extended floating point format used during calculations. You want to make the integer as small as you can before switching to the realm of floating points.

If the animation is meant to take a non-integral number of ticks, however, this solution wouldn't be possible by definition. But I'm not sure why they would do that - then again, I'm also really not sure why they would make beacon animation tied to server time in the first place!

This is the code, contains the original and the fix I propose (that is, doing the rotation incrementally and in an overflow-aware manner):
https://dl.dropbox.com/u/518733/beacons%20yay.png
The rotation period is derived from the calculation at the definition of var14.

Note the calls to Math.sin and Math.cos - for some reason they chose to not use the lookup table, which sort of defeats the point of having one. That said, there's a CPU instruction for sin/cos on x86.

This also causes the texture of the beam to not be animated, just 3 straight lines all the way up the beam.

How the beam appears normally

How the beam appears when affected

It saddens me that this bug, to which I and others have provided no less than three different solutions of varying efficacy, still goes entirely unnoticed by moderation staff and Mojang alike.
I would like the moderators to change the status of this bug from "Community Consensus" to "Confirmed", as I have proof (via reproduction steps) that this bug exists and affects vanilla Minecraft:

You will need NBT Explorer (or a similar tool) to view the contents of your world's level.dat file. You will not need a copy of the Minecraft server as this bug equally affects single-player worlds.

1. Note that the "Data/Time" field in a world's level.dat is a monotonically increasing integer (disregarding its storage class limitations which should not affect it in any real-life situation).
2. Note that over time, it may reach inordinately high values due to its unchecked growth.
(The reason for these two first steps is to explain the justification for the step which is to follow)
3. Simulate a long-standing world by modifying its value to something relatively large. Each increment of 20 is equal to one second of world uptime, so to simulate a server which has been running for two months, set it to 20*60*60*24*30*2, which is 103680000. After setting this value, save the modified level.dat.
4. Load the world and place a beacon. Note that even in single player mode, its animation lags.

Notice how after two months of uptime (whether simulated or real), the beacon animation is very noticeably choppy. Setting the time back to 0 fixes the issue, however it is possible to reach high values for the Time field in vanilla Minecraft without any mods or cheats, but impossible to reset it back to zero without mods or cheats. Additionally, without this relatively esoteric knowledge, I doubt anybody would discover the fix by themselves.

These instructions are a practical way to reproduce and understand the bug. For a more technical explanation of why it happens and how to fix it please see previous comments.

Please elevate the status of this bug to "Confirmed". I believe I have provided enough information to prove that it is a real bug which affects vanilla Minecraft in this comment. If this comment is lacking in any information which could otherwise result in this bug becoming confirmed then please make me aware of this.

-----------------------

tl;dr version:

I've proven that this bug exists:
1. Open your world's level.dat in NBT Explorer
2. Open "Data", then double click on "Time".
3. Change it to 103680000
4. Press save
That simulates a world which has existed for a long time. Now play on it and look at the beacons.

MC-12816 and MC-13400 are a different bug (and the second one was incorrectly closed).

MC-1379, MC-2072, MC-3752, MC-4020 are duplicates of THIS bug report, which is NOT marked as resolved. The policy is to have one open ticket per bug, and to close duplicates so that there aren't more than one open ticket about the same bug.

Confirmed with the steps provided by Score_Under the Human

@John L
Your theory:

...if issues such as this one were not treated with ignorance, the claimed high percentages of duplicates would not exist...

My theory:
If the bug tracker wouldn't be spammed with an insane amount of duplicates, the mods and devs would've be able to care about the real issues.

Proof: Recent most spammed issues (numbers as of time of writing this comment)

• MC-17673: 74 duplicates (Not yet implemented)

• MC-18368: 88 duplicates (Working as intended)

• MC-18375: 62 duplicates (Working as intended)

Alex,

> MC-12816 and MC-13400 are a different bug

While they do appear superficially different in their manifestation, they are actually the same bug, and that is a rounding error in beacon state calculation caused by a large world time. Essentially, because of a quirk of Java it's allowed to be rounded to approximately 7 significant figures, and kept that way during all subsequent additions/divides/etc, without so much as a warning from the compiler.

Both MC-13400 and MC-12816 linked to this ticket.

But: Crash report of MC-12816:

Level time: 305662 game time, 1026962 day time

Just found that bug in SMP ... that's a nasty one 😛

This happens all the time when playing SMP (1.6.2), it's much more obvious when using HD packs (not even choppy movement, the texture is broken too). Uploaded screenshots of expected behavior (Singleplayer) and how beams look like in SMP.
Anyone update the affects versions? Thanks!

Visible with Sphax PureBDcraft

Is the beam stretching related to the choppy rotation?

@Alex Campbell:
Most likely yes.

This only happend on servers for me. Can no longer reproduce it (tested with 1.7.2 server), seems to be fixed now.

nope not fixed, still happens on servers. look at bdubs livestream if you want proof. I still have it on my server. please reopen

hello? anymod home? can someone please reopen this?

Yes.

thanks kumasasa 🙂

still in current snapieshot

What letter is the "current" snapshot 😉 ?

13w47e 😛

Still has issues in 1.7.4....
Just sayin'....

Affects 1.7.8

It's annoying because all they have to do, is just make the animation use a time that starts with the client.
It couldn't matter less if the beam animation is not synchronized for everyone which i highly doubt it would be anyway

Is this still a concern in the latest Minecraft version 14w30c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

It's back.

Nevermind. It's a little slow, and fluctuates a lot, but it's nothing a clean computer can't fix.

Nope, definitely still a problem on 1.8-pre3 (reproduced with Score_Under the Human's procedure).

Confirmed for 1.8.