Failing to place blocks in creative mode causes an animation
If you right-click to place a block, and the block cannot be placed in that location, then in survival mode nothing at all happens, but in creative mode the item animates, sort of like half of the item-switch animation. This is distracting and misleadingly suggests that something happened.
Linked Issues
is duplicated by3
MC-13820Right-clicking ground with non-placeable blocks such as armor causes the arm animation do to the same animation when feed animals with wheatDuplicateMC-14827If you right click the ground with a regular golden apple, the horse give animation appears.DuplicateMC-21508Right clicking with any item in creative makes the item bounce Duplicate
Created Issue:
Failing to place blocks in creative mode causes an animation
If you right-click to place a block, and the block cannot be placed in that location, then in survival mode nothing at all happens, but in creative mode the item animates, sort of like half of the item-switch animation. This is distracting and misleadingly suggests that something happened.
Added Affects Versions: 1.4.5
Added Affects Versions: 1.5.1
Added Linked Issues:
is duplicated by
Added Linked Issues:
is duplicated by
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
Added Affects Versions: 1.6.2
Added Affects Versions: 13w42b
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
Deleted Comment:
A comment with security level 'global-moderators' was removed.
Added Fixed Versions: 15w31a
Added Affects Versions: 1.8.6
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
Removed Fixed Versions: 15w31c
Added Fixed Versions: 15w36b
Confirmed in 1.4.5.
Still in 1.6.1 It happens to all items/blocks that cant be placed there.
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Confirmed in 1.6.2.
Can confirm in 13w42b
Still a concern in 14w08a.
Is this still a concern in the latest Minecraft version 14w30c? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Still in 14w30c.
Dear mods, do old bugs (as opposed to ones that were, say, introduced in the current snapshot series) really need this frequent of reconfirmation? I think it's much more likely to cause a false closure if the reporter(s) aren't persistent.
We have an incredibly large number of tickets, and many tickets are bugs that end up getting fixed, or are invalid, but their ticket remains open simply because they get hidden in the collection. By resolving stale tickets, and reopening them at the owners request, we guarantee that only the valid tickets get reopened, which helps reduce the number of invalid tickets in the system.
Hm, I see the point that there's a lot of noise. I wish you would at least request updates for the most recent release version, not snapshots (unless it was a bug introduced in a snapshot). A reporter shouldn't need to install pre-release versions just to usefully report a long-standing bug.
Good point, and we've come across that issue before and switched out behavior before. The current stance is that installing the snapshot is no longer that hard, and that snapshots are considered the most recent version to developers, so if its fixed in 30c, theres no reason to ask if its fixed in 1.7.10. We may change this behavior in the future.
The point of the snapshots is to allow bugs, and attempts to fix them, to be tested before each release. If we only asked for confirmation that bugs still existed in the current release, then more bugs would survive the snapshot phase, and general users who only play releases would be stuck with them for yet another release cycle.
Reporters are not obligated to use the snapshots, though it is very easy to do so using the current launcher, and presents no risk to existing worlds if configured to use a separate directory. The bug tracker is public so that multiple users may contribute to a ticket by commenting on it, and either the reporter or a moderator can update the affected versions based on input from other users. The affects version/s field does accept both the current release and the latest snapshot, so confirmation that the issue still exists in the current release is useful.
All that said, updates to the tracker have given us new tools to manage tickets, and our confirmation policy has changed accordingly.
Same in 1.8.8
Fixed in some 1.9 snapshot.