Alex Campbell
- immibis
- immibis
- Europe/Stockholm
- Yes
- No
MC-714![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Empty minecarts and storage minecarts currently lose 4% of their momentum every tick, or 56% every second. They've always done this, but before 1.6 it was easy enough to compensate by using a stronger booster. However, powered rails always apply a constant acceleration of 1.2 m/s/tick.
With this level of drag, an empty minecart can never move at maximum speed for more than 1.6 seconds after leaving a stretch of powered rails of any length (and it will stop completely after a few more seconds). This makes powered rails impractical for boosting empty carts and storage carts, unless you're in creative as one powered rail is required every 4 blocks to maintain maximum speed. (compare to 1 every 36 for players)
The only alternatives I've found for empty cart propulsion are powered carts (which are very slow and must be fueled manually) and spin boosters (which are very unreliable and likely to be removed).
PS. I would have made this issue an Improvement, but the issue creation form won't let me select any type other than Bug.
Performance issue: Chunk coordinates use a bad hash functionServer performance issue: Chunk coordinates use a bad hash function
Minecraft stores all loaded chunks in a hash table. The hash function used starts by XOR'ing the chunk's X and Z coordinates, so that many nearby chunks will get the same hash. This causes chunk lookups - and block updates, block lookups, tile entity lookups, etc - to take O(sqrt(N)) time instead of O(1), where N is the number of loaded chunks.
For a server with 10 players and a view-distance of 10, there will be 4410 loaded chunks, and chunk lookups will be
about66 times slower than they should be.Minecraft stores all loaded chunks in a hash table. The hash function used starts by XOR'ing the chunk's X and Z coordinates, so that many nearby chunks will get the same hash. This causes chunk lookups - and block updates, block lookups, tile entity lookups, etc - to take O(sqrt(N)) time instead of O(1), where N is the number of loaded chunks.
For a server with 10 players and a view-distance of 10, there will be 4410 loaded chunks, and chunk lookups will be up to 66 times slower than they should be, or 20 times slower in the best case.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
I still think it should be Mojang's job to see if bug reports are still valid.
You're a modder yourself, right? Do you check if every bug reported to you about your mods is valid from version to version? Do you really think it's even possible to do so, for all reports?
You're smart enough to identify a bad hash function. You're obviously a reasonably skilled programmer. So why isn't it obvious to you that:
- Number of employees checking bug reports cannot possibly scale with the number of users reporting them.
- The user is the one person best situated to verify whether or not their own experience has changed.
Mojang cannot determine what is happening on a user's computer. Depending on how clear the report is, they may not actually understand what the problem is. So unless you're suggesting they fly out to the user's home and see the problem in person (which would scale particularly poorly as a solution), I don't really understand what you're getting at.
From another angle, when Mojang does check reports, and closes them because they think they've fixed it, someone tends to come along and complain that it isn't fixed, and the report was closed prematurely. As the saying goes, damned if you do, damned if you don't.
When was the world originally generated?
Please attach a screenshot of your pyramids.
You also can't punch things from 12 feet away IRL. Minecraft isn't real life.
I agree this should be changed, it's inconsistent with other things you right-click to activate.
It seems the max spawn delay is actually 1 tick lower than what you set it to in 1.4.2, so if you set the maximum to the minimum + 1, there will be no variance.
The ability to set these properties on spawners was a deliberate feature in 1.4.
If a feature doesn't work as intended, that's a bug.
This happens if you have the world open in a different Minecraft instance, with no visible error message.
Farming wood is easy, farming sugar cane is easy, but THREE TO SIX COWS PER BOOKSHELF?
@Meta
The selection box and collision box are different things - look at fences or stone walls.
There used to be an item duplication bug that involved having a crafting table open while water pushed you into a nether portal. Notch's "fix" was to close all GUIs when in a nether portal.
I think that was a list of resolved tickets that were not duplicates, not actual fixed bugs. In this case the "fix" was saying "No, we won't change it back."
I've discovered it's actually not hard to get that much leather, if you can find 2 cows to start with (Notch y u nerf animal spawning?)
Why?
Is it intended?
@John Smith: It caused the game to crash if you had a loop of comparators.
This was marked as a duplicate of
MC-220instead ofMC-2201.@Oscar Parker: Empty buckets are not fuels, so there is no reason they should work the same as fuels.
Has this design ever worked? This is how rails are intended to work...
What is the expected behaviour?
If you have a clock, it's obvious that it's constantly updating.
If you just have a comparator, it's not obvious at all.
Not to mention the lag caused by people using comparators for purposes that don't require constant updating.
If you want a clock, why not just make a clock?
When there are two different ways a corner rail piece could connect, a redstone signal will switch between them.
In step2.jpg, both of the corner pieces can switch directions while still connecting (note that it doesn't care whether the other piece stays connected or not).
In step5.jpg, neither piece can switch direction without becoming disconnected at one end.
@Roadsguy:
They're invalid data values. There is no correct way for them to be placed.
As an analogy, you can't try to write a program by mashing your keyboard, complain when it doesn't work, and say you expected "the program to run correctly."
I'm not sure what you're even trying to achieve by spawning invalid items.
Pressing the button leads to step3/4.jpg because only the rail that receives the redstone signal is affected.
Your proposed changes would not prevent any rails from switching that could switch before, but they will make rails switch that did not switch before, possibly breaking things.
Your stations are broken, not the game, and I don't think Mojang will change a game mechanic that isn't broken in order to fix someone's minecart stations while breaking a lot of other ones.
A bug is a mismatch between expected behaviour and actual behaviour. The wiki documents actual behaviour. The intuitive thing to happen is for the hopper to extract the empty bucket.
This works fine in 1.4.7. Has it been changed in the snapshots?
Why do you expect the items to go to the first hopper below the pipe?
It might affect adventure maps.
Didn't Jeb say this wouldn't be fixed, some time in 2011?
Jakob, that would be a separate bug with its own fix.
@Adric Blake:
minecraft.exe is just minecraft.jar with a small Windows launcher attached. It's still a valid jar file and can be run in Java.
Perhaps people are arguing it because feature requests don't belong on this tracker.
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.
@NightKev: I didn't say it was a feature request, I said feature requests don't belong on the tracker, and that's why people are arguing about whether it's a feature request or not.
after X ^ Z the rest of the function is:
private static int hash(int par0)
{
par0 ^= par0 >>> 20 ^ par0 >>> 12;
return par0 ^ par0 >>> 7 ^ par0 >>> 4;
}
X and Z are ints. I haven't tested any alternative options.
Perhaps not twice as fast, but noticeably faster.
I counted the number of times the digging sound plays before the block breaks, when breaking certain blocks in 1.2.5 and 1.5.2.
In 1.2.5:
In 1.5.2:
Please re-open.
Guthrie: How is that related to /whitelist list?
World seed: 1342824358176851538
Village coordinates: -292 69 246 (also the coordinates of the block the torches are supposed to be attached to)
@Tails: Nothing on this ticket suggests that mods are installed, so why close it as a duplicate of a ticket that was marked invalid due to mods being installed?
MC-12816andMC-13400are a different bug (and the second one was incorrectly closed).MC-1379,MC-2072,MC-3752,MC-4020are 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.Affects Minecraft 1.6.1.
Villagers can ride horses in 1.5?
Is the portal crossing a chunk boundary?
I assumed that to do that you need a horse...
http://puu.sh/3wRi3.zip is a world that cannot be converted.
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.
This still occurs in the current Minecraft version, 1.6.2.
Here's a piston wall that actually doesn't depend on this bug: (the previously-posted one does)
http://puu.sh/3ATv7.jpg
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
Is the beam stretching related to the choppy rotation?
Is
MC-22449really a duplicate of this?This is about having no option to convert alpha/chunk-format worlds.
MC-22449is about crashing when converting beta/region-format worlds.MC-5672was about worlds created from third-party software, and marked invalid because of that.MC-22449was about worlds created in Minecraft.Yes.
http://puu.sh/3wRi3.zip is a world which has this problem which has never been used with third-party software.
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.
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.
You may be modifying the wrong method. Chunk coordinates are hashed in the (MCP names) LongHashMap.getHashedKey and LongHashMap.hash methods. MCP code follows:
Don't undo what you did already, but make sure to change it in LongHashMap (above) as well.
Grum said in IRC this was a feature. I really hope he was joking.
Why does the launcher need to "prevent tampering with vanilla versions"? Surely the user can do whatever they want with their own computer (and they can just treat the files like mods and they won't be checked anyway), so what is the point? Just curious.
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.
http://xkcd.com/1172/
Confirmed for 1.9.2.
" 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.