The Einhaender

Also, there is no setting to select what input cycles through the hotbar; it is permanently fixed to the vertical scroll wheel. Admittedly, resolving this would require issue MC-85743 to be fixed as well, which has been marked as "invalid".

This kinda-sorta relates to MC-42367, but only in that comments on that issue requested a way to disable the scroll wheel as a work around.

I believe this issue should be reopened. If I can bind the drop key to arbitrary keys like mouse buttons, 'SYSRQ' or 'NUM LOCK', it would seem logical to be able to bind it to ANY input, including the scroll wheel.

I imagine it might not be worth the effort it would take the devs to fix this, but if that's the case, this should be closed as "won't fix", not as "invalid".

Still in 15w44a

in 15w44a this issue is fixed.
Thanks Mojang!
(Forgive my noobishness, but I can't figure out how to add 15w44a to the fixed version list. Could someone teach me how/do it for me please?)

Its been almost a month since I made this bug report. Is there anything further I can do to help get it fixed or at least confirmed?

This bug still exists in 15w38b.
Is there anything I can do to help get this bug confirmed?
(btw, bugs.mojang.com really needs an page explaining what to do AFTER submitting a bug report and how to help confirm/update other people's bug reports)

duplicates MC-88929

duplicates MC-88929

duplicates MC-88929

(Sorry for the inactivity)
I tested again in 15w38b; Minecraft lagged but would not crash. Possibly because I'm using a new computer: 8 GB ram instead of 4, faster CPU, and a graphics card.

After some experimentation I isolated the cause; it is setting the FollowRange attribute to 999:

/summon VillagerGolem ~ ~1 ~ {Attributes:[{Name:generic.followRange,Base:999}]}

Further testing shows that there is no lag when there are no hostile mobs in the world (eg. superflat void world), some lag when there are only a few hostiles in the world (lag is mostly after the golem kills a hostile, but before it starts tracking another), and when I tried it in a standard minecraft world at night, the server froze (couldn't open chests) almost immediately, and F3 showed RAM usage climbing. Within a minute or two F3 said "Allocated: 100%", (apparently a limit on the JVM, as only 60% of my computer's RAM was in use and the computer did not start using swap). Once Minecraft had used all the ram it could, FPS dropped from 60 to zero. Minecraft stayed in this state for at least 10 minutes; I even held F3+C for a full minute and Minecraft wouldn't crash.

Its possible that the Iron Golem's tracking has a bug in it making it lag and eat memory (crashing some computers), but I think it is more likely that this is an inevitable result of the Iron Golem trying to track every mob in a 1 km radius. So I'm thinking that nothing needs to be fixed and map makers just need to be cautious when increasing the follow range.

edit: FYI, I tried to save and exit world, which is supposed to cause the crash, but the game doesn't respond, stays frozen on the pause screen. X-ing out of Minecraft works, but when trying to log back in it stays frozen at 0%, at which point I couldn't close the window using the X button and had to kill java from the system monitor (Ubuntu equivalent of Window's Task Manager).

I can confirm.

In a new world using 15w36c I went to the nether, placed a command block and couldn't open. Relogging did fix.

edit: relates to MC-87872

This bug still exists in 15w36c

I have observed this bug as well.

dang. MC-64066 didn't show up in my searches. Is there anyway I can delete this report or mark it as a duplicate?

Sorry, I would have sworn I had already attached a crash report.