Tristan, consider what would happen in the case of a server side mod that changed some behavior the client was expecting. For example, a new enchantment that made the player walk on water. When a player is above a water block, the client may predict them jumping in and play a certain sound, but if the server decides the water should act like a solid block, the sound would be buggy and jarring.
@lol768 I realize there is currently no such behavior in the game; that was the point. I was attempting to demonstrate the usefulness of "server-sided" sounds with a hypothetical mod. If the water splashing sound was initiated by the client, then there would need to be a client side mod in addition to the server side mod, or the sounds would be wrong. Whereas with sounds initiated by the server, the mod could be server only and hence simpler.
Acknowledged as problem with client side prediction but closed as wontfix? Unless I'm missing something, that means we'll have to live with it for the time being.
@Robby Lee - I admit I am no great expert at Minecraft combat, but I've heard this complaint many times from others and witnessed such problems in many LPs. It seems to have started with the SMP/SSP merge. It used to be easy to time attacks in SSP and hard in SMP. Now it's hard in both.
I'm kind of ambivalent about this and interested to see how Mojang responds. I hate accidentally placing enchanted signs and losing their enchantment, but I feel that's part of the tradeoff and always has been.
Beyond that, since enchanted signs are not obtainable through regular gameplay, I'm not sure this will be considered a legitimate bug. If it is, I wonder it'll get a very high priority. Though we may be surprised!
I think they key question is whether the current behavior is intended or not. If it is, then you're making a feature request. If it's not, then it's a bug report. Only Mojang can answer that question.
Also, I wouldn't rely too heavily on features as they existed in snapshots. Even if the feature was unchanged for a moderately long time chronologically, it was still the snapshots. They are, by definition, subject to change.
Oops, my mistake, you're right. It was in a release and then changed. I still wouldn't consider that iron clad evidence, though. Several other game mechanics have changed after being in the game for a while.
I think my comments might be making my opinion seem a bit stronger than it actually is. My feeling is that Mojang will consider this not-a-bug, but I'm really not sure. I guess we'll eventually see how they respond.
Carey Tilden
MC-270
No text in the body. Two bugs listed in the subject. Not the best bug report I've seen.
Edit: looks like the bug report was edited after I made my comment. Looks better now.
I've seen the same thing when digging straight up too. For example, when chopping down a tree.
I've had this problem with spiders, zombies, endermen, slimes, magma cubes, etc. Anything with a melee attack. It seems like they have real long arms.
I understand they're not actually bound by human reaction times, but it'd be nice if we even had a chance.
Tristan, consider what would happen in the case of a server side mod that changed some behavior the client was expecting. For example, a new enchantment that made the player walk on water. When a player is above a water block, the client may predict them jumping in and play a certain sound, but if the server decides the water should act like a solid block, the sound would be buggy and jarring.
@lol768 I realize there is currently no such behavior in the game; that was the point. I was attempting to demonstrate the usefulness of "server-sided" sounds with a hypothetical mod. If the water splashing sound was initiated by the client, then there would need to be a client side mod in addition to the server side mod, or the sounds would be wrong. Whereas with sounds initiated by the server, the mod could be server only and hence simpler.
Acknowledged as problem with client side prediction but closed as wontfix? Unless I'm missing something, that means we'll have to live with it for the time being.
@Robby Lee - I admit I am no great expert at Minecraft combat, but I've heard this complaint many times from others and witnessed such problems in many LPs. It seems to have started with the SMP/SSP merge. It used to be easy to time attacks in SSP and hard in SMP. Now it's hard in both.
I'm getting a similar crash. Attached another crash report in case it helps.
This bug tracker is for reporting unintended behavior.
I'm kind of ambivalent about this and interested to see how Mojang responds. I hate accidentally placing enchanted signs and losing their enchantment, but I feel that's part of the tradeoff and always has been.
Beyond that, since enchanted signs are not obtainable through regular gameplay, I'm not sure this will be considered a legitimate bug. If it is, I wonder it'll get a very high priority. Though we may be surprised!
I think they key question is whether the current behavior is intended or not. If it is, then you're making a feature request. If it's not, then it's a bug report. Only Mojang can answer that question.
Also, I wouldn't rely too heavily on features as they existed in snapshots. Even if the feature was unchanged for a moderately long time chronologically, it was still the snapshots. They are, by definition, subject to change.
Oops, my mistake, you're right. It was in a release and then changed. I still wouldn't consider that iron clad evidence, though. Several other game mechanics have changed after being in the game for a while.
I think my comments might be making my opinion seem a bit stronger than it actually is. My feeling is that Mojang will consider this not-a-bug, but I'm really not sure. I guess we'll eventually see how they respond.
This has been a long standing issue. It's actually kind of nice sometimes, because you can hit hostile mobs through the corners.
Did you choose the wrong resolution by accident? It's currently marked as fixed.
Sounds like a user support issue more than a bug in Minecraft.
Does this happen in the same spot every time? If so, what are the coordinates?
If this was marked as a duplicate, why was it changed to fixed? Now the bug fix is counted twice.
Should this be marked duplicate instead of fixed?
Still happens to me sometimes in 1.4.5