score

This is absolutely a bug and nothing to do with graphics drivers. However, it's a bug in lwjgl.

I have just reported it: https://github.com/LWJGL/lwjgl/issues/130

In that case it should be removed - if that exploit is present in multiplayer servers, then a malicious user could just avoid this with a modified or unofficial client, and so fixing it in the client end is the wrong way to go about it. However I don't think the exploit exists any more.

Even if it were a limitation of the world saving mechanism (I very much doubt it), in my eyes this would make it more of a bug. What's saner: fix a bug in the save system, or disable pausing? (I don't think that is the issue, though, I just think it's a bad design decision)

Affects 1.7.8

Right, I'm aware they do actually read reports, it's just generally frustrating that bugs like this go ignored for such long periods of time.

As for the "nothing like the actual source code" claim, I'm not so sure. I know it'd be nothing like the source code visually, but when it comes to the structure it would be nearly the same, and recognisably so. Things like this broken delegation to another method would be almost exactly as they were in the original source code, but with some names changed. A good starting point would be to run IntelliJ's "unused parameter" inspection on classes handling textbox input, and assuming nothing out of the ordinary is going on here it would find the bug instantly (or rather, narrow it down to one of maybe 5 lines of code, from which it would be easy for a human to determine where the problem lies).

Added the current version, just remembered to actually test it. This bug has been present since the inception of the new chat system around version 1.2.5 IIRC.

If only Mojang read bug reports... it is frustrating to know exactly the mistake made and exactly how to fix it in less than ten keystrokes in the IDE, and to report where the problem is exactly in the code, only to have this ignored for just shy of a year. It's not a matter of not knowing the solution, it's a matter of simply not reading this report.

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.

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.

Useless issue! How are Mojang supposed to solve anything from the info given here? Also, updating drivers more than once is not possible: if you update to the latest, how can you update it even further without time traveling?

You're missing several key details:
What graphics card / GPU do you have? How much onboard video memory? What version of OpenGL does it support?
What processor do you have? 32 or 64 bit? How much RAM do you have?
What version of Java are you using? ("Latest" is NOT a version number!) Have you tried "Force Update" from the launcher?
Does Minecraft crash? Fail to load? Freeze?
When? Before any window shows up? Before the login box? After login but before mojang screen? During mojang screen? During loading a world?

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.

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

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.

Tails, please re-open this issue.
By my calculations, this should start happening noticeably after the map has been online for around 45 days. It will also affect single-player worlds if you really have no life.
To reproduce this, see my CraftBukkit pull request: https://github.com/Bukkit/CraftBukkit/pull/1104#issuecomment-15567567

This is a real issue, caused by a clientside rounding error when the world uptime is cast to float.

Edit: "I'm almost certain it's serverside" - the description of the bug is guesswork, 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 we 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.

Just so that it's 100% obvious exactly where the bug is and why it happens (added a picture)

For the record (and for mojang): in the textbox class, the (overloaded) function used to find a word given a position and offset... ignores the offset. Looks like a copy/paste gone wrong.

As far as I'm aware MC-460 would be a granularity issue - Not only are imprecise positions are exchanged between the server and client, but since the exp orb accelerates with a value relative to the difference between a fixed distance and the nearest player's distance, any lag (e.g. the player spending longer close to the orb clientside than serverside) would quickly desynchronise the positions of the orb between the client and server.

It is frankly dumb luck that XP orbs (usually) aren't invisible for the first second after spawning: the only reason the position is corrected clientside so fast is because there's a special exception given in the entity tracker stating that all entities which have only just changed velocity should be updated to all clients as fast as possible.

This is also the (rather infamous) case with soul sand (the bug's as old as time itself), and with extended upward-facing pistons (extend while you have a block above your head to allow yourself to stand on the piston despite the head being in the way).

Michael, Adventure mode has recently changed from "you can't destroy blocks" to "you can destroy blocks with the right tool". You can chop down trees, so long as you have an axe of some kind, you can mine as long as you have a pick, but if you lose your tools you are stuck.
Silverfish blocks disguise as normal stone blocks, so in adventure mode they should ideally be breakable by the same tools that stone is breakable by (i.e. a pickaxe)

I had searched for a while for duplicate bugs (there's always one) but couldn't find it. I'd searched for "lilypad" (no space), "tall grass" (not just 'grass'), and "third person" (not 'f5 mode')... it's amazing how this other bug managed to avoid all those keywords, lol :/

This is great for having chests stacked on top of each other, or sunk into a wall (using backward staircase blocks).