[MC-1279] Slow (Choppy) Rotating Beacon Block Created: 30/Oct/12 Updated: 27/Oct/24 Resolved: 16/Oct/14 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Minecraft 1.4.2, Minecraft 1.4.7, Minecraft 1.5.1, Minecraft 1.6.1, Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 13w47d, Minecraft 13w47e, Minecraft 1.7.4, Minecraft 14w04b, Minecraft 1.7.5, Minecraft 1.7.8, Minecraft 14w33c, Minecraft 14w34a, Minecraft 14w34b, Minecraft 14w34c, Minecraft 14w34d, Minecraft 1.8-pre1, Minecraft 1.8-pre3, Minecraft 1.8 |
| Fix Version/s: | Minecraft 1.8.1-pre3 |
| Type: | Bug | ||
| Reporter: | John Swenson | Assignee: | Mog (Ryan Holtz) |
| Resolution: | Fixed | Votes: | 28 |
| Labels: | precision-loss | ||
| Environment: |
Windows 7 64 bit. Java 6.0.260.3 |
||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Game Mode: | Survival | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
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:
|
| Comments |
| Comment by Bentroen [ 19/Sep/14 ] |
|
Confirmed for 1.8. |
| Comment by Kevin Chang [ 29/Aug/14 ] |
|
Nope, definitely still a problem on 1.8-pre3 (reproduced with Score_Under the Human's procedure). |
| Comment by SuburbSomeone (lastname) [ 26/Aug/14 ] |
|
Nevermind. It's a little slow, and fluctuates a lot, but it's nothing a clean computer can't fix. |
| Comment by SuburbSomeone (lastname) [ 26/Aug/14 ] |
|
|
| Comment by [Mod] Ezekiel (ezfe) [ 25/Jul/14 ] |
|
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. |
| Comment by Jeppe Vennekilde [ 13/Apr/14 ] |
|
It's annoying because all they have to do, is just make the animation use a time that starts with the client. |
| Comment by score [ 12/Apr/14 ] |
|
Affects 1.7.8 |
| Comment by Thomas Mobley [ 24/Dec/13 ] |
|
Still has issues in 1.7.4.... |
| Comment by Maarten Thijs [ 25/Nov/13 ] |
|
13w47e |
| Comment by Kumasasa [ 22/Nov/13 ] |
|
What letter is the "current" snapshot |
| Comment by Maarten Thijs [ 22/Nov/13 ] |
|
still in current snapieshot |
| Comment by Maarten Thijs [ 22/Nov/13 ] |
|
thanks kumasasa |
| Comment by Kumasasa [ 10/Nov/13 ] |
|
Yes. |
| Comment by Maarten Thijs [ 09/Nov/13 ] |
|
hello? anymod home? can someone please reopen this? |
| Comment by Maarten Thijs [ 06/Nov/13 ] |
|
nope not fixed, still happens on servers. look at bdubs livestream if you want proof. I still have it on my server. please reopen |
| Comment by _zombiehunter [ 25/Oct/13 ] |
|
This only happend on servers for me. Can no longer reproduce it (tested with 1.7.2 server), seems to be fixed now. |
| Comment by _zombiehunter [ 13/Jul/13 ] |
|
@Alex Campbell: |
| Comment by Alex Campbell [ 13/Jul/13 ] |
|
Is the beam stretching related to the choppy rotation? |
| Comment by Dylan Rivers [ 11/Jul/13 ] |
|
Visible with Sphax PureBDcraft |
| Comment by _zombiehunter [ 10/Jul/13 ] |
|
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. |
| Comment by _zombiehunter [ 01/Jul/13 ] |
|
Just found that bug in SMP ... that's a nasty one :-P |
| Comment by Kumasasa [ 30/Jun/13 ] |
|
Both But: Crash report of Level time: 305662 game time, 1026962 day time |
| Comment by score [ 30/Jun/13 ] |
|
Alex, > 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. |
| Comment by Kumasasa [ 30/Jun/13 ] |
|
@John L
My theory: Proof: Recent most spammed issues (numbers as of time of writing this comment) |
| Comment by Kumasasa [ 30/Jun/13 ] |
|
Confirmed with the steps provided by Score_Under the Human |
| Comment by Alex Campbell [ 30/Jun/13 ] |
|
|
| Comment by score [ 17/Jun/13 ] |
|
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. 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). 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: |
| Comment by kasamikona [ 06/Apr/13 ] |
|
How the beam appears when affected |
| Comment by kasamikona [ 06/Apr/13 ] |
|
How the beam appears normally |
| Comment by kasamikona [ 06/Apr/13 ] |
|
This also causes the texture of the beam to not be animated, just 3 straight lines all the way up the beam. |
| Comment by score [ 29/Mar/13 ] |
|
This is the code, contains the original and the fix I propose (that is, doing the rotation incrementally and in an overflow-aware manner): 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. |
| Comment by WolfieMario [ 29/Mar/13 ] |
|
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! |
| Comment by score [ 29/Mar/13 ] |
|
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). |
| Comment by WolfieMario [ 29/Mar/13 ] |
|
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. |
| Comment by score [ 29/Mar/13 ] |
|
To repeat what I posted on another bug (so that it gets read and hopefully gets fixed):
|
| Comment by WolfieMario [ 24/Mar/13 ] |
|
Confirmed for Minecraft 1.5.1; there's now also a painful Z-fighting resulting from this. |
| Comment by asdf [ 14/Mar/13 ] |
|
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. |
| Comment by Alex Campbell [ 14/Mar/13 ] |
|
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. |
| Comment by John Swenson [ 10/Feb/13 ] |
|
Wow, thank you so much Jeppe Vennekilde! It worked like a charm! Props to you sir. |
| Comment by Jeppe Vennekilde [ 09/Feb/13 ] |
|
I have found the cause of the problem 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 |
| Comment by John Swenson [ 26/Jan/13 ] |
|
Ya its still of concern as of 1.4.7. I updated the affected versions, hopefully Mojang recognizes this issue. |
| Comment by asdf [ 26/Jan/13 ] |
|
I think it is. I seem to recall some mindcrack videos on recent snapshots with the issue still present. |
| Comment by asdf [ 01/Dec/12 ] |
|
I'm seeing this confirmed in many peoples' videos, though not in any of my personal experiences. On servers as well. |