mojira.dev
MC-1279

Slow (Choppy) Rotating Beacon Block

So it seems if you power a beacon block in worlds generated before 1.0 [official release] (not sure about this, but that's what I am assuming) the particle beam effect rotates really slowly and appears choppy. Note that I am on a single player world, NOT a server. I haven't tested this on a server. I tested this on newly generated worlds and it works perfectly fine, but old world saves affect it somehow. I tried pyramids of all sizes, being in creative/survival/etc.. doesn't change a thing. Hopefully there will be a fix for this so I can use beacons on my preexisting adventure map world!

Steps to reproduce:

  • Create a world

  • Let it run for 60 days in real time
    or

  • set the level time to 103680000 (level.dat / Tag "Time")

Related issues

Attachments

Comments

migrated
[media][media][media][media][media][media]
asdf

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

asdf

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

John Swenson

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

Jeppe Vennekilde

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

John Swenson

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

Alex Campbell

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.

asdf

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.

WolfieMario

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

score

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.

WolfieMario

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.

score

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).

WolfieMario

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!

score

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.

kasamikona

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

kasamikona

How the beam appears normally

kasamikona

How the beam appears when affected

score

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.

Alex Campbell

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.

kumasasa

Confirmed with the steps provided by Score_Under the Human

kumasasa

@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)

score

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.

kumasasa

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

But: Crash report of MC-12816:

Level time: 305662 game time, 1026962 day time
_zombiehunter

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

_zombiehunter

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!

Dylan Rivers

Visible with Sphax PureBDcraft

Alex Campbell

Is the beam stretching related to the choppy rotation?

_zombiehunter

@Alex Campbell:
Most likely yes.

_zombiehunter

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

Maarten Thijs

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

Maarten Thijs

hello? anymod home? can someone please reopen this?

kumasasa

Yes.

Maarten Thijs

thanks kumasasa 🙂

Maarten Thijs

still in current snapieshot

kumasasa

What letter is the "current" snapshot 😉 ?

Maarten Thijs

13w47e 😛

Thomas Mobley

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

score

Affects 1.7.8

Jeppe Vennekilde

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

Ezekiel

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.

SuburbSomeone (lastname)

It's back.

SuburbSomeone (lastname)

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

Kevin Chang

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

Bentroen

Confirmed for 1.8.

John Swenson

migrated

Confirmed

precision-loss

Minecraft 1.4.2, Minecraft 1.4.7, Minecraft 1.5.1, Minecraft 1.6.1, Minecraft 1.6.2, ..., Minecraft 14w34c, Minecraft 14w34d, Minecraft 1.8-pre1, Minecraft 1.8-pre3, Minecraft 1.8

Minecraft 1.8.1-pre3

Retrieved