Alex Campbell

Press F3 and t

" if "/time add 10" is hooked up to a 20 tick clock ... the sun will jump forward every second or so."

Isn't that expected? 20 redstone ticks is two seconds. So you told it to make the time jump forward slightly (half a second as the time is measured in game ticks) every two seconds.

Confirmed for 1.9.2.

http://xkcd.com/1172/

I have to agree with @Sycholic about passing the buck. Saying "Nobody has re-confirmed this in the last 2 years, therefore it's invalid" is just sticking your head in the sand (and by "you" I mean Mojang).

"Pending information" or similar would be a valid status, but only if there's someone at Mojang whose job it is to confirm bugs. Otherwise, it's just another way to disown responsibility.

TL;DR: Getting bugs fixed once they are reported is Mojang's responsibility. If I am expected to help Mojang, then I expect to be paid for my time, like everyone else working for Mojang.

Grum said in IRC this was a feature. I really hope he was joking.

You may be modifying the wrong method. Chunk coordinates are hashed in the (MCP names) LongHashMap.getHashedKey and LongHashMap.hash methods. MCP code follows:

private static int getHashedKey(long par0)
{
    return hash((int)(par0 ^ par0 >>> 32)); // <-- this is the part where I noticed the inefficient hashing. Every chunk lookup uses this hash function.
}

private static int hash(int par0)
{
    par0 ^= par0 >>> 20 ^ par0 >>> 12;
    return par0 ^ par0 >>> 7 ^ par0 >>> 4;
}

Don't undo what you did already, but make sure to change it in LongHashMap (above) as well.

Well, Grum's presence in this thread changes the "unlikely to be fixed" part. I still think it should be Mojang's job to see if bug reports are still valid.

The problem with X^Z is that nearby chunks tend to get the same hash. X^Z is the first stage of the hashing function, so no matter how good the rest of the function is, chunks 0,5 and 1,4 and 2,7 and 3,6 and 4,1 and 5,0 and 6,3 and 7,2 will always get the same hash.

A Python simulation of the existing hash function on a 65x65 chunk area centred on random coordinates showed that this creates an 8192 slot hashmap, with 272 slots used, and an average chain length of 15. If centred around the (0,0) chunk instead, the average chain length is 25.6.

Using Grum's suggestion to replace X^Z, the average chain length was 1.03 for a 65x65 area, 4.08 for a 257x257 area, and 8.14 for a 513x513 area.
Using Brandon's suggestion to replace X^Z, the average chain length was 1.28 for a 65x65 area, 1.31 for a 257x257 area, and 1.32 for a 513x513 area, .

I doubt anyone has a loaded region of 257x257 chunks (or even 65x65), so while Brandon's hash function generates a low, predictable rate of collisions (edit: bucket collisions, not hash collisions), Grum's may be a bit better for typical Minecraft usage. Grum's is also simpler.

I was going to check whether this still affects 1.7.2.
But then I realised - this is Mojang's job, not mine. If Mojang want to improve the quality of Minecraft, they should make some effort to do stuff themselves, instead of asking random community members to do it for free. That might be a good strategy to increase profits, but it's definitely not a good strategy to get bugs fixed.

If I tell you that this bug still affects 1.7.2, nothing will happen. It will not make the bug more likely to get fixed. You'll ask me again in 1.8 and 1.9 and 1.10.
Why should I expend effort to keep a bug report open that's not even likely to be resolved (except, perhaps, as WONTFIX)?
Why should I expend effort to do Mojang's job for them, without being paid or compensated in any way? (According to a very quick and unscientific Google search, the average salary of a software tester is over $75000/year.)
Why is it expected that I do Mojang's job for them?

If Mojang was not a largish for-profit company - if Minecraft was still developed by a single person in his spare time - then there would at least be a viable excuse for asking users to do your work for you.
But according to Wikipedia, Mojang is about 1/10 the size of Valve. That's not tiny. Mojang has 36 people, and not a single one is able to go through and re-verify bug reports?

Would you charge $1 per month a bug report is open? No, because that's utterly stupid. This is the same, just less extreme.

http://puu.sh/3wRi3.zip is a world which has this problem which has never been used with third-party software.

Yes.

MC-5672 was about worlds created from third-party software, and marked invalid because of that.
MC-22449 was about worlds created in Minecraft.

Is MC-22449 really a duplicate of this?
This is about having no option to convert alpha/chunk-format worlds.
MC-22449 is about crashing when converting beta/region-format worlds.

Is the beam stretching related to the choppy rotation?

Tim: Which design using this bug does allow rows to be controlled independently?

Edit: This would allow each row to be controlled independently if not for this bug: http://puu.sh/3AWbM.jpg

Here's a piston wall that actually doesn't depend on this bug: (the previously-posted one does)
http://puu.sh/3ATv7.jpg

This still occurs in the current Minecraft version, 1.6.2.

The old wooden slabs are only kept for technical reasons.
It's perfectly possible to make a BUD that doesn't rely on quasiconnectivity, and I don't understand why people act like fixing this bug kills BUDs.

Edit: In fact, it was possible to make a non-quasiconnectivity piston BUD in beta 1.7. No redstone blocks required.

http://puu.sh/3wRi3.zip is a world that cannot be converted.

I assumed that to do that you need a horse...