I guess it is because iron doors are handled as "doors" internally.
With wooden doors not eating/drinking/whatever makes sense because you right click the door to open it.
However since you can not open an iron door by right clicking it this should be changed for iron doors.
I can confirm this on Debian wheezy for 1.4.6-pre.
In my case the problem occurs when changing from a dual monitor configuration to single monitor via XRandR and pressing the login button after that.
The problem does not occur when the original screen configuration is maintained until LWJGL has loaded, after that you can safely disable the second monitor.
I use a bash script that deactivates the second monitor after LWJGL has loaded as a workaround but it should probably be fixed in the LWJGL version downloaded by Minecraft.
They did a "sneaky update" on 1.4.6-pre, may or may not be somehow related to MC-4872, but the stack trace looks slightly different.
Furthermore it is a different exception. So test on the redownloaded version as Tails said...
While it would be more comfortable to have Minecraft download texture packs >10MB (for example in your case),
it is technically speaking not a bug in vanilla Minecraft as texture packs that only contain the custom textures required for vanilla Mincraft should not exceed the limit.
@Michael Coppola While this might (I have not tested it, but it should) result in an error, it is not a real argument as there is no point in adding Megabytes of data to a texture pack.
OK, now I understand what the dummy file was for
But is it possible using the worst possible .png compression to make a texture pack containing only textures for the current version - 1.4.6 - that is that big?
You speak of a "common scenario", but the texture packs I use are <5MB, can you provide a link to a texture pack that includes only 1.4.6 textures and exceeds the 10MB limit?
If so, it would be a bug.
If not, it would not be a bug since the limit is sufficient for the version it is included in. When future versions require a higher limit - e.g. because of the new format - it will probably be increased but at the moment I do not see the necessity to do so for vanilla Minecraft to function properly. That said, I still think it should be increased as there are obviously people that would benefit from it and I do not see any negative effects, but technically speaking it would not be a bug then.
OK, so to sum it up, we agree on what type of issue this is and that it should be fixed.
The misunderstanding came up because Mojira currently does not use other issue types than "Bug".
So @Mojang: Please add "Improvement" and / or "Feature Request" to the list of issue types.
Voting up these issues would show quite clearly what the majority of the players would like to have in the game, not just which bugs they want to see fixed, and is more structured than the forum.
Furthermore different priorities could prevent bugs like MC-4715 to make it into the final versions.
That makes sense, but in that case there should be two boxes, one that prevents them from fitting in smaller spaces and one that enables the player to hit the parents.
Daniel
MC-4559
I can confirm this on Debian Wheezy with OpenJDK 6
You just have to see "through" the explosion.
Tomas, I agree. I have this issue with cows.
I guess it is because iron doors are handled as "doors" internally.
With wooden doors not eating/drinking/whatever makes sense because you right click the door to open it.
However since you can not open an iron door by right clicking it this should be changed for iron doors.
I can confirm this on Debian wheezy for 1.4.6-pre.
In my case the problem occurs when changing from a dual monitor configuration to single monitor via XRandR and pressing the login button after that.
The problem does not occur when the original screen configuration is maintained until LWJGL has loaded, after that you can safely disable the second monitor.
I use a bash script that deactivates the second monitor after LWJGL has loaded as a workaround but it should probably be fixed in the LWJGL version downloaded by Minecraft.
When they rewrite the rendering engine (http://www.minecraftwiki.net/wiki/Redstone_Update#Rendering_engine_rewrite) they should consider updating to a more recent version of LWJGL that fixes this.
They did a "sneaky update" on 1.4.6-pre, may or may not be somehow related to
MC-4872, but the stack trace looks slightly different.Furthermore it is a different exception. So test on the redownloaded version as Tails said...
While it would be more comfortable to have Minecraft download texture packs >10MB (for example in your case),
it is technically speaking not a bug in vanilla Minecraft as texture packs that only contain the custom textures required for vanilla Mincraft should not exceed the limit.
@Michael Coppola While this might (I have not tested it, but it should) result in an error, it is not a real argument as there is no point in adding Megabytes of data to a texture pack.
OK, now I understand what the dummy file was for
- it will probably be increased but at the moment I do not see the necessity to do so for vanilla Minecraft to function properly. That said, I still think it should be increased as there are obviously people that would benefit from it and I do not see any negative effects, but technically speaking it would not be a bug then.
But is it possible using the worst possible .png compression to make a texture pack containing only textures for the current version - 1.4.6 - that is that big?
You speak of a "common scenario", but the texture packs I use are <5MB, can you provide a link to a texture pack that includes only 1.4.6 textures and exceeds the 10MB limit?
If so, it would be a bug.
If not, it would not be a bug since the limit is sufficient for the version it is included in. When future versions require a higher limit - e.g. because of the new format
OK, so to sum it up, we agree on what type of issue this is and that it should be fixed.
The misunderstanding came up because Mojira currently does not use other issue types than "Bug".
So @Mojang: Please add "Improvement" and / or "Feature Request" to the list of issue types.
Voting up these issues would show quite clearly what the majority of the players would like to have in the game, not just which bugs they want to see fixed, and is more structured than the forum.
Furthermore different priorities could prevent bugs like
MC-4715to make it into the final versions.That makes sense, but in that case there should be two boxes, one that prevents them from fitting in smaller spaces and one that enables the player to hit the parents.
Confirmed.