Thue

This actually seems to be fixed in 1.8.1-pre3.

The attached minecraft testcase world zip also still reproduces it. Might be the easiest way to consistently test.

It is perfectly possible for the internal server to tell whether it is a singleplayer world. It already does this for example when pausing the game on singleplayer.

Saying that it should not work in singleplayer because of irrelevant and easily worked-around technical non-arguments is silly.

Closed as "works as intended"? While it may make sense not to give the achievement in multiplayer, surely it should be given in singleplayer?

[Mod] Torabi wrote
> Fixing it isn't always as simple as just changing a few settings.

If your IPv6 connectivity is broken, then just turn it off locally. It is as simple as changing a few settings: http://www.techunboxed.com/2012/08/how-to-disable-ipv6-in-windows-8.html

Forcing people with broken IPv6 connectivity to turn it off locally is soooo much more correct than breaking Minecraft for IPv6.

The old way of double-tap sprinting is still there. So just because there is a sprint button, it doesn't mean that there isn't still a bug in the double-tap sprinting. The sprint button doesn't remove that bug.

WTF grum? That makes no sense whatsoever?

This means that if you are shooting a bow, and there is a fence in front of you, you can't draw the bow. Which I have run into several times. Same with blocking with a sword. So the bug has real consequences.

If you are holding a leash then yes, a fence is interactive. But there is no reason to make it interactive when holding a bow.

I have a similar problem on Ubuntu 12.04.

On a related note: I will have to leave in the 30 second sleep to to to work around this bug, since I don't have a good way to know which version a given minecraft binary is... If minecraft_server.jar supported a --version argument it would be very handy.

The bug seems to no longer be present in 1.6.2, neither in vanilla or bukkit.

Related but not a duplicate.

> Feel free to make a guide that moms can follow to debug their broken ipv6 stack.

Perhaps do the same that Microsoft does to check whether the Internet is working. Have a central computer at Mojang.com with IPv6. If a Minecraft server has an IPv6 address, and the minecraft client can IPv6 test connect to that (with a catch all) around, then IPv6 is working. If not, then use IPv4.

And of course write out an error message if the user's IPv6 configuration is broken.

According to http://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting :

> As of May 2011, IPv6 brokenness as measured by instrumenting a set of mainstream Norwegian websites was down to ~0.015%

So you prefer IPv4 because of those 0.015%?

Now a lot of systems have latent IPv6 via Teredo, and you should of course prefer IPv4 on those, but you should not always prefer IPv4 IMO.

The fact that this "invalid" bug was fixed shows that it was not invalid in the first place. IMO the mods should be more careful with the "invalid" tag.

I tested for 1.5, and from the changelog have no reason to think it was fixed in 1.5.1. It is a bit laborious to test, so I will probably not retest until 1.6, unless asked by the developers.

In 1.5.1, the orb position seems to be synced once every second or so.

Which makes it really easy to demonstrate that there is problem with halfslabs. The client seems to think that the orbs can travel up a halfslab, while the server thinks not.

> Client predicting where the entity is VS server having it at another place. Not trivial to fix, will eventually be taken care of once the client stops having a mind of its own.

The funny thing about the attached save is that even after what are obviously client-server syncronization events, where the item jumps back up to where the server thinks it should be, the item still falls down again. So I would think that the problem is not the client thinking for itself about where the items land, but rather that the client's hitboxes differ subtly from the servers (or alternatively that the item position coordinates are not sent with enough precision).

Unless it is important that you know RIGHT NOW, I will retest once 1.5 is out.

Does this mean that 1) is also fixed, and we can actually disable spawn protection entirely? That would be excellent!

I met Dinnerbone online on oc.tc, and he said in chat that he was aware of the bug. I killed Dinnerbone as revenge for the sprint bug, of course! 😛