![[Mod] Torabi](../../../data/assets/gravatar/torabi.png)
[Mod] Torabi
- torabi
- torabi
- America/Boise
- Yes
- No
MC-23725
armoredinventory.png
When you wear any armor and punch with empty hand, you can see only your shirt during punch animation.Any armor you are wearing will not be rendered in the 1st-person view. The default armor textures do no cover any area that is visible in 1st-person, but a resource pack may provide textures that do. The arms will be rendered in 3rd-person, or on other players, but not on yourself in 1st-person view.
Steps to Reproduce:
1. Use the ArmorTest.zip resource pack attached to the issue.
2. Equip any chestplate.
3. Your arms should be bright green in 1st-person view, but are not.
relates to
duplicates
In 1.6.2 and earlier fully grown wheat/carrots/potatoes would pop-off into item form when the light level in the block was reduced to 0. Since snapshot 13w36a wheat no longer does this, this includes the current 1.7.2 release.
The screenshots show the results of placing a block above the water, reducing the light level of the wheat to 0. In 1.6.2 the wheat pops off, in the snapshot the wheat remains.
Creative or survival.
Wheatnot popping off in light level 0Crops (Wheat/Carrots/Potatoes) not popping off in light level 0
relates to
is duplicated by
duplicates
is duplicated by
is duplicated by
relates to
is duplicated by
is duplicated by
duplicates
duplicates
Beacons Work on lava but not on waterLava does not disable Beacon
Beacons work under lava but not under water and its so annoying because both of them are not solid blocks and they are liquids. :/
What i expected:Both of them work or both of them don't work.
Whats happen:Only the lava one works.
Beacon beam works under both stationary and flowing lava, but does not function under stationary or flowing water.
A comment with security level 'global-moderators' was removed.
Command: setblocksign not workingCommand: setblock minecraft:sign produces a confusing error message
The command:
"/setblock ~ ~ ~ minecraft:sign"not workingerror message: "There is no such item with name minecraft:sign"
But the id of the sign is minecraft:sign
It worked very well with an id number in previous releases
The command:
"/setblock ~ ~ ~ minecraft:sign" produces the error message:
"There is no such item with name minecraft:sign"However, minecraft:sign is an item, and works with commands such as /give.
setblock requires a block, not an item, and so the correct names to use for setblock are "minecraft:wall_sign" and "minecraft:standing_sign", which are the blocks produced by the sign item when it is placed in the world.As such, it would be less confusing if the error message instead said:
"There is no such block with name minecraft:sign"
all
relates to
Opening the creative inventory
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
is duplicated by
relates to
duplicates
is duplicated by
relates to
duplicates
duplicates
is duplicated by
is duplicated by
Piston vanishesFalling sand can replace pistons, destroying them
relates to
is duplicated by
relates to
relates to
is duplicated by
is duplicated by
duplicates
is duplicated by
Going below level -40 does damagetotheplayer until he die,like in creative mode.When a player goes under Y -40 in spectator mode, he takes damage from the void like in creative mode and he dies.
duplicates
is duplicated by
Sandfalling too earlySand/Gravel broken by piston instead of being pushed upwards
relates to
Sand/Gravel broken by piston instead of being pushed upwardsFalling sand breaks if a solid block is pushed into its space
is duplicated by
relates to
is duplicated by
relates to
Breaking Minecart(with arrows, or in snowballs in creative)while ridingInItMakesYouFallThroughBlockBreaking Minecart or boat while riding in it makes you fall through blocks
is duplicated by
duplicates
Left Shift+Left click don´t work inhorsesinventoryLeft Shift+Left click doesn´t work in player inventory while riding horse
Left shift+Left click
don´t work in horses and donkeys/mules inventory to move items faster.Left shift+Left click will not move items between the hotbar and the player's inventory while riding a horse, donkey, or mule. It will move items between the inventory and saddlebags, however.
is duplicated by
Put your operating system (Windows 7, Windows XP, OSX) and Java version if you know it here
duplicates
duplicates
duplicates
is duplicated by
is duplicated by
is duplicated by
is duplicated by
duplicates
duplicates
is duplicated by
is duplicated by
is duplicated by
Comparatornot responding to tobrewing standComparator will not distinguish between 3 and 4 items in a brewing stand
Since the "fix" that made comparators able to recognize full stacks of items in the brewing stand, the comparator can no longer recognize the difference between a brewingstand with a brewing incredient in it and one without. Obviolsy this ability to recognize if there is an ingrdient in the brewing stand is essential to pretty much any redstone work that includes brewingstands and comparators...
How to recreate:
1. Put 3 water bottles in a brewing stand.
2. Place a comparator from the brewingstand facing another comparator.
3. Try to see if you can insert any value into the comparator, being faced by the one from the brewingstand,that makes the output turn on/off depending on the fact if there is an incredient in the brewingstand.
4. You will come to learn its impossible and realize its broken.
The "fix" breaking this mecanism should defenately be reverted since being able to tell if there is 1 incredient in the brewing stand is critical to automate brewing and to work with brewing and redstone in general.
Here is a link to the "fix" i talked about https://mojang.atlassian.net/browse/MC-7058?jql=text%20~%20%22comparator%22Since the "fix" that made comparators able to recognize full stacks of items in the brewing stand (
MC-7058), the comparator can no longer recognize the difference between a brewing stand with a brewing ingredient in it and one without. Obviously this ability to recognize if there is an ingredient in the brewing stand is essential to pretty much any redstone work that includes brewing stands and comparators...How to recreate:
- Put 3 water bottles in a brewing stand.
- Place a comparator next to the brewing stand, facing away from the brewing stand, and extend a line of redstone from the output of the comparator.
- The output will be 11.
- Place a single brewing ingredient in the top slot of the stand.
- The output will still be 11.
- Continue adding more of the brewing ingredient to the top slot until the output increases.
- The output will not increase until you have 10 ingredients in the stand.
duplicates
@[Mod] Torabi: Yup 
@[Mod] Torabi: Honestly can't say, as I was able to reproduce it with two hoppers, a comparator and a couple pieces of redstone to complete the clock circuit, with nothing else attached, however attaching more did seem to make it slightly worse but nothing I can confirm. The lighting update I doubt because there is no light output from my setup, but you could be correct on the formula issue, just haven't found anything to pinpoint and confirm.
Disabling Advanced OpenGL solves this issue (Options -> Video Settings -> Advanced OpenGL -> Off)
If you don't have that option in your video settings, please check your .minecraft/options.txt for the entry
advancedOpengl:false
If it's true, change it to false (Quit Minecraft, edit this file, restart Minecraft)
Affected:
NVIDIA GeForce GT 750M Yegor Wienski
Nvidia GeForce 650 Ti Boosted, latest drivers Justin
Nvidia GTX 460 with latest drivers (337.88) [Mod] Torabi
NVidia GeForce 680 Michael Turner
ATI Radeon HD 2600 XT GL version 3.3.9901 Compatibility Profile Context, ATI Technologies Inc. jeremy branscum
GeForce GTX 660M/PCIe/SSE2 GL version 4.4.0, NVIDIA Corporation Kyle
OpenGL: NVIDIA GeForce GT 750M OpenGL Engine GL version 2.1 NVIDIA-8.26.21 310.40.35f08, NVIDIA Corporation Yegor Wienski
AMD Radeon HD 6520G GL version 4.2.12422 Compatibility Profile Context 13.152.0.0, ATI Technologies Inc. Anon Ymus
Not affected:
AMD Radeon HD 6700 Series GL version 4.4.12874 Compatibility Profile Context 14.100.0.0, ATI Technologies Inc. (AMD Catalyst 14.4, no Advanced OpenGL Switch) Kumasasa
Entire chunks do not visually render, however, their blocks can still be mined/pick blocked/broken like normal. Block updates do not cause the chunk to render.
Relogging does fix the problem, however new chunks will then be visually unloaded.
Disabling Advanced OpenGL solves this issue (Options -> Video Settings -> Advanced OpenGL -> Off)
Or just simply press F3+A to reload the nearest chunks.
If you don't have that option in your video settings, please check your .minecraft/options.txt for the entry
advancedOpengl:false
If it's true, change it to false (Quit Minecraft, edit this file, restart Minecraft)
Affected:
ATI Radeon HD 4300/4500 Series GL version 3.3.11653 Compatibility Profile Context, ATI Technologies Inc. Thijmen F
ATI Radeon X1600 OpenGL Engine GL version 2.0 ATI-1.5.48, ATI Technologies Inc. Simons Mith
Nvidia GTX 460 with latest drivers (337.88) [Mod] Torabi
AMD Radeon HD 6800 Series , Driver version: 9.12.0.0 & Driver version: 14.100.0.0 Marcono1234
GeForce GTX 660M/PCIe/SSE2 GL version 4.4.0, NVIDIA Corporation Kyle
Not affected:
AMD Radeon HD 6700 Series GL version 4.4.12874 Compatibility Profile Context 14.100.0.0, ATI Technologies Inc. (AMD Catalyst 14.4, have no Advanced OpenGL switch) Kumasasa
pillar up from the bottom of the sea all the way up. keep stacking until the blocks turn invisible (about two blocks above water)
This is cancelled when mipmapping is turned on/off
NP.
Meanwhile [Mod] Torabi has cleaned up the LAN skin issues and made this ticket to the new parent ticket of "Host skin invisible to others".
[Mod] Torabi, there is an attempt at separation, but it fails big time and then some. I doubt the plugin API will automatically make them get things right, although I don't know what it actually does.
A very basic fix for those wanting to mod their current MCP-less client:
1.7.10: xi.class: at 0x1DD9, change 2A 1B B5 00 69 to 00 00 00 00 00.
14w28b: acy.class: at 0x1E3E, change 2A 1B B5 00 58 to 00 00 00 00 00.
This keeps the client from thinking it owns the boat.
For increased responsiveness, also do:
1.7.10: xi.class: at 0xE1B, change 08 to 03.
14w28b: acy.class: at 0xE8C, change 08 to 03.
This makes the boat interpolate to the new position faster, which is potentially jerkier but more responsive. This is as fast as it would interpolate, had the bug not been there. Boats not ridden by you that are 'supposed' to interpolate slowly now also interpolate faster, but that shouldn't be an issue. A more granular fix would be much more elaborate than the change of a single byte, when it may not even be better.
Whoops. I didn't spot [Mod] Torabi's comment somehow. Yes, it is. I figured it may be that way to keep a better view inside small spaces. But regardless of where the game puts its camera, it shouldn't use different positions for different purposes.
[Mod] Torabi: That's not really going anywhere. You can pull the entire game apart like that. Why don't you simply fall over, given the way your legs move? Right, because you only fall over when you die, moments before vanishing in a puff of smoke. Not that you'd normally see that in case of your own body because your arm (the only part of your body you can see in first person) disappears. Makes sense.
Simplified bounding volumes are much more reasonable than air barriers where you couldn't possibly grab something at any level. Sneaking basically activates simple AI that helps you not to fall off and shouldn't change physics drastically. So far the only deviation is that it makes you stop faster, at a point where you can usually stop almost as fast.
Okay, enough pedantry. There are relevant arguments up here somewhere. I have nothing to add.
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
@[Mod] Torabi I'll test that when I get back home from school. I've got an alt account I can use for that.
Confirmed for
- 1.8.5 like [Mod] Torabi said 30000000.0 works though
Reproduced in 1.8.7.
------
So your solution is to just change when the lag happens? Meaning that if you make multiple changes, it could lag enough to crash the game? I don't see how that is better at all.
It would only do the calculation once, using the final value (and not do any recalculations if there was no change). So no, it wouldn't make the lag worse; it would just do the same amount of lag as 1 change, but only once.
The reason why the behavior is bad is not only because of the lag, but because moving the mouse during the lag causes the value to change again, leading to more lag and having the value unchanged. If anything, that part should be fixed.
Resource packs successfully do this delayed recalculation – it doesn't change everything immediately when you add or remove one; it waits until you exit the screen.
However, it doesn't seem like it would work here.
Same here. The problem could be solved in 5 minutes. Cut the code which gets executed when the slider changes and paste it to the click "Done" event. Solved... (and maybe add a text box which says that it may lag now because the game has to render everything again and no one would ever have a problem with it).
Due to the way that settings work, it's probably not possible to just do that. (The 'GuiOptionsRowList' and 'GameSettings' have no idea what a 'Done button' is). They simply update the setting, and if something needs updating, update it.
if (p_74304_1_ == GameSettings.Options.MIPMAP_LEVELS) { int var3 = this.mipmapLevels; this.mipmapLevels = (int)p_74304_2_; if ((float)var3 != p_74304_2_) { this.mc.getTextureMapBlocks().setMipmapLevels(this.mipmapLevels); this.mc.getTextureManager().bindTexture(TextureMap.locationBlocksTexture); this.mc.getTextureMapBlocks().func_174937_a(false, this.mipmapLevels > 0); this.mc.func_175603_A(); } }
That's called whenever the mouse is dragged over the slider and the mouse is down, which isn't an issue most of the time but is when you're recalculating everything. (Of course, it does in fact only update the value if the value changed, which does mean that the lag isn't as bad as it could be 
)
So making it apply immediately prevents that kind of problem. However, it's probably possible to move the recalculations to when the player stops moving the slider, rather than as soon as they start moving it. Fortunately, we can fix this report up and reopen it.
Indeed, that's the best solution. There still would be lag, but it wouldn't be double-lag nor would it lead to accidental choosing.
However, the way the code is, it seems hard to do that as well. The slider works by setting the setting value and then updating its displayed text with the value from the setting (getting the display string is done in GameSettings.java), so if changing the actual value is delayed, it doesn't update.
It would be possible to move the formatting code into the slider itself, but that seems suboptimal. However, it's still a better solution than what's currently happening.
I'd write up some code for that, but... MCP's values for the settings are horrible and I don't want to deal with them.
This comment turned out way longer than I expected, and probably is a little confusing; sorry.
ok, thanks [Mod] Torabi that clears it up completely for me, that was the only thing I was still confused about
[Mod] Skylinerw it might be, but that doesn't mean it won't get updated
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
The bug
When summoning a slime with the Tag NoAI:1b it can still damage the player.
How to reproduce
- /difficulty hard
- /summon slime ~ ~ ~ {Size:3,NoAI:1b}
- /gamemode survival
- Walk into the slime and die a slimy death
Video: https://youtu.be/ZkI3uU7hoBA?t=2m33s
Fix
Having in mind the overall AI-System this is a hack. See note below.
There is a method canDamagePlayer() in EntitySlime.java. A check can simply be added there.
... protected boolean canDamagePlayer() { // Added && !this.isAIDisabled() return this.getSlimeSize() > 1 && !this.isAIDisabled(); } ...
@EDIT I didn't find MC-67667 somehow. Searges comment declares it as "Won't fix".
I still think this should be changed as damaging logically would be part of the AI, even if it's not directly inside the AI code.
Note: As [Mod] Torabi pointed out in his comment, this is probably not so much viewed as "Won't fix", but rather will likely get fixed properly in future by moving this part of entity behaviour to the AI-Code.
Looking at it, it looks like a simple task at the beginning, but soon you realize that it probably would make sense to relocate the EntitySlime in the class hierarchy and I think form there it will feel like this soon. It's understandable why it gets ranked less important than other issues for now.
[Mod] Torabi Thank you for clearing that up!
I guess it's not even always obvious for people with programming experience as the overall goals are not always known/communicated as you did here (It probably should have been clear looking at the developments of AI-System though).
So it's not that much "Won't Fix" but "Fix proper later".
I find that most bugs are caused by old bad code design in one way or the other. I wonder how their "code that needs to be rewritten"-list looks like
qmagnet Ture, the title could have been more clear
[Mod] Torabi ProfMobius (Thomas Guimbretiere) Thank you! That's pretty much what I was thinking when finding out about it. It's nothing severe, but something that should be looked at eventually
This is how you could solve this (using [Mod] Torabi's method):
/scoreboard objectives add potionCount dummy
/stats entity @a set AffectedItems @p potionCount
/scoreboard players set @a potionCount 0
/execute @a ~ ~ ~ /clear @p splash_potion -1 0 {Potion:"minecraft:water"}
/execute @a ~ ~ ~ /tellraw @p ["",{"text":"Matching potions: "},{"score":{"objective":"potionCount","name":"@p"}}]
[Mod] Torabi Always a delight to read your comments, thanks a lot for the effort, the time you put in.
It makes it so much easier for me to explain such things to upset people (me, being not a native nor really eloquent English speaker and too awkward to begin with).
I already did understand the general WaI-issue from your first post I was referring to, but it can't be stressed enough.
The more people know about it, the less mean comments or "bad vibrations" will arise in the future.
Developer comments explaining exactly what is intended and what is not would be nice, but are not always a reasonable expenditure of their time.
I don't expect any of the developers to waste their time on a reply, I rather have them more bugs fixed - but I hoped that any of the mods or very experienced people would reply and explain, and that hope wasn't in vain, thank you };] <3
Marcono1234's "workaround" doesn't work for bats by the way (I'm sure I tested it correctly), but thanks to what he and even more so [Mod] Skylinerw said I completely understand the problem with effects versus attributes, and why it can be considered as "works as intended".
I hope fixing attributes for flying + swimming mobs will be possible, but if not I'll keep in mind what you wrote (and I already knew thanks to you) about the current code situation.
If it's sure that it will be fixed someday when all the code is rewritten then it's just a matter of time.
I play Minecraft since 2010, I don't mind waiting as long as I know it's not futile };]
So, again a huge thank you to you all also on behalf of others for taking your time and explaining it.
Take care!
see[Mod] Torabi added a comment - 03/Nov/15 4:41 PM
They did not intend for mobs to use elytra, but did not specifically prevent it from functioning or being put on them. Whether or not it would be difficult to implement is irrelevant to whether or not they desire to do so. This is a feature request, not a bug.
mobs weren't intended to use elytras in the first place, it's unsupported
"The change that caused this issue was made deliberately, and presumably for a good reason. The fix provided may help Mojang in understanding and fixing the issue, but probably can't just be dropped into the original code due to obfuscation, and they may not want to fix it in that way for the same reason they made the change in the first place."
Actually, us developers will look at code, see 2 things that appear to do the same thing, but miss the slight difference in the 2, or worse, don't clearly see what happens deeper in the flow.
So we then say "let's simplify things! Delete the extra". We test, and everything works... So it seems like a good idea. Deleting code usually is a good thing.
But in this case, the problem isn't seen until larger servers, and until Mojang starts testing updates against 100 player servers...It's going to rely on the 3rd party community to clean up the mistakes, as we're the ones that have in depth profiler data on how the code behaves under heavy load.
The devs don't copy and paste our patches directly of course, but they'll know how to apply it based on logic (hince "paper patch 78" was mine [except for the part that got modified and caused bugs] as well as 2 other performance changes I contributed that landed in 1.9)
[~scott.barnes@gmail.com] that doesn't have anything to do with this issue and would not be a good way to improve the server. That would extremely over complicate the design and make it even harder to make real optimizations.
[Mod] Torabi I wasn't saying simplfying code was wrong. I totally agree that when you see things that appear to do the same thing, to condense it. I was saying that this regression was very unlikely to be intentional, and a mere side effect of the change, as you previously implied they intentionally changed the behavior of the code to always touch the unload queue, and I was saying I disagree and I believe the unload queue behavior change was merely an unintended side effect.
[Mod] Torabi DicoTheRedstoner I can confirm that it is caused by the update order.
Currently: west east down up north south
Depending on if the piston in front or the one below get updated first the circuit behaves different.
It's impossible to avoid all directional behaviour because the updates need some order, but the y-axis shouldn't be updated in between the two other axis.
Because that causes everything that depends on something updating a y-direction before a horizontal one or the other way around, to be directional.
The question is: What order would be best?
Y-Last: west east north south down up
Y-First: down up west east north south
Y-Split: down west east north south up
I think it would make sense to keep the horizontal directions in the same order they have been before to minimize the things that would break. I also don't see any advantage changing it.
Of course you could also switch the places of up and down in all of these.
No matter how you change it, it would break some things that depend on update orders. They would be fixable though.
I made a mod that allows to set the update order with a command (E.g. /updateorder west east north south down up).
If you want to try how different update orders would behave you can download it here: http://www.mediafire.com/download/b9mjwuimu2ei7wg/1.9_UpdateOrder.zip
Video about it with a more general/theoretical approach: https://www.youtube.com/watch?v=aRr3NpmQiCg
Please do not use the comments to discuss, take discussion to the discussions page on reddit.
As weighted pressure plates have to be changed now that the decision about this gamerule seems final, please participate in a discussion in this Reddit-thread here what your ideas for a change for weighted pressure plates would be so they'd be of use again for the technical community.
1.11 will introduce the new gamerule "maxentityCramming" which will be "ON" by default and set to "24".
With this default-ON-gamerule not more than 24 entities at one time will be able to be in one spot, more than 24 will suffocate and die.
"maxentityCramming" is a pure performance gamerule.
While it is very useful for the Creative community and also for servers which suffer from entity lag, it should be set to "0" by default = OFF.
Reasons
As it's only a performance gamerule, servers and singleplayers who use commands should set the amount of wanted entities in one spot on their own account, if they want to do so.
As there are also players and servers though which are "dedicated decidedly Vanilla Survival" and do not make use of any commands including gamerules as this would go against "Vanilla Survival", this will force them to play with that gamerule and its 24 default entities in one spot.
Those Vanilla players and servers will not be able anymore to e.g. make proper Elytra boosters, Elytra Launcher stations across their world (mainly Overworld+The End dimension), which will be a negative change for those Vanilla players and servers and their infrastructure by losing this awesome feature.
Elytra is very much loved, but only with Elytra Launcher stations they can be really enjoyed and can be practically used on Vanilla Survival servers and Singleplayer worlds.
As 24 entities will basically never be in one spot without a player being responsible for it, "maxentityCramming" gamerule should be OFF by default, as it's only really useful for non-Vanilla-servers and the Creative Tech community. If a player is willingly responsible for the accumulation of mobs in one spot, it's up to their decision how to deal with possible lag and, dependent on the quality of their hardware, set maxentityCramming accordingly. If a player willingly accumulates mobs in one spot and does not want to use that gamerule, it is, including possible lag, also their very own decision. This highly individual adjustment and decision should not be pre-made for them.
Again: The gamerule can absolutely help servers regarding their performance if they want to.
Servers that use plugins and/or commandblocks do have admins who also know commands well enough and can set "maxentityCramming" themself if they see the need for it.
Also, what are *iron pressure plates then still for?*
An iron/heavyweighted pressure plate changes the signal strength it gives off depending on the number of entities on it.
Signal strength of 15 is reached with 141+ entities.
The default of 24 entities with the "maxentityCramming" gamerule renders them pretty much useless, even more so as golden/lightweighted pressure plates detect only up to 15 entities.
There was the argument that at least those pressure plates would work as intended for those people who use commands to turn off that gamerule.
As the technical community is the main target group to use these pressure plates, and as those who really can make use of those pressure plates are nearly all "decidedly Vanilla" players who would never use commands for their Vanilla worlds, it makes no sense to deprive them from making use of those pressure plates, as they are nearly the only ones using them in the first place, as highly technical players with "many entities being crammed in one spot intentionally".
I'm not a native English speaker so I cannot word it so well like [Mod] Skylinerw can, whose comment over on Mojira-Reddit I will thus mostly quote, as he mentioned many things I and some of my technical-player-friends I showed it agree to:
Regardless of if the gamerule's primary objective is to boost performance or affect gameplay, it's not taking into consideration that it's blocking another feature that already existed.
Why have weighted iron plates in the game if, by default, 12 of its 15 states cannot be used without cheating?
Not to mention that gold plates already encompass some of the remaining available states for iron, even further reducing the usefulness.
A singleplayer-playing, cheats-off player taking notice of the useless weighted plate feature has no way of fixing it without using a third-party tool, which does not mean that that player knows that such tools exist and how to use them. Nor does that necessarily mean they are even aware that there is a way of fixing it.
Driving the player to using a third-party tool to fix a feature (that was previously fully available and could otherwise have been defaulted to fully available) is not something that should happen.
That also does not mean that players should "learn" to enable cheats on world creation.
Enabling cheats is optional, not a requirement for being able to fully access all survival features.
Weighted pressure plates were not cheating, after all.
The primary issue I have with it is that a cheat, by default and with no recourse for some, blocks a survival feature that was previously accessible, and requires cheating or (for some) requires third-party tools to access it again.
Keep in mind that weighted plates are not restricted to the technical community.
Everybody has access to this feature, not just a single sub-community, so it does impact everybody (including non-technical players following a tutorial that makes use of weighted iron plates).
An existing and intended feature (weighted iron pressure plates) is being hindered by default for everybody and requires cheats to access them fully again.
Possible solutions to this issue are to change the default value of the gamerule up to the highest value that iron plates can detect.
The popular solution is to change the default of the gamerule to 0 and let players/server admins decide when to use it, while iron plates become fully accessible again.
However, none of those solutions work when the gamerule is changed.
What would probably be an unpopular solution is to remove iron plates entirely, since in their current state, they are near-useless.
I'd like to add to SkylinerW's last sentence here that a removal of weighted pressure plates in favour of the "maxentityCramming" as default-on-gamerule would not only make all technical contraptions which make use of them void, but I'm sure that the reaction of the community would be even more negative than it already is, and they'd oppose that gamerule in the way it is planned of being implemented even more.
Furthermore, as we can see in MC-107171 this gamerule is bugged, entities also take too much damage etc., so it needs to be changed anyway already.
Possible Compromise
As suggested by [Mod] Torabi:
| I think a good case can be made for defaulting to 0 for existing worlds, to avoid damaging contraptions that players have already made. |
I personally could live with that, but I'm not going to have the arrogance to want to decide this for everyone, I only try to mediate between the community and Mojang/Microsoft.
Thus:
Addition to the compromise
Upon creating a world in 1.11+, one could have an option to chose whether maxentityCramming should be OFF/0, or default/24, or, if also possible, inserting an individual value.
In order to figure whether or not the community would be fine with Torabi's idea, I created a poll.
Poll for "worlds created prior to 1.11 should have "maxentityCramming" default-off"
https://twitter.com/LapisDemon/status/784755247596134401
If there is an important reason which I don't see, why "maxentityCramming" was introduced as default-on with the value of 24, and not as an option, please do tell.
On which grounds has it to be "on" and set to "24"?
I know many not only Vanilla Survival players would like Mojang to reconsider adding this gamerule in 1.11 as default "on".
If possible code-wise and if the community would be fine with it, please consider adding some sort of gamerule-selection for this for worlds being created in 1.11+.
Thank you in advance for considering it.
[Mod] Torabi I have to disagree with you, for the first time };]
| people most in need of performance options will also be those least likely to be able to find them, and thus they should be on by default |
People who don't know about this gamerule will even more so not be capable of creating a system where so many mobs are crowded in one single spot.
I also wouldn't take them as not as smart as they are or can be. If a newbie experiences problems, they will very likely ask in the community, their friends etc., and in the end they'll know about that gamerule, via forums and the likes. More and more people, also young people and newbies, use Youtube and Minecraft forums and the likes as general platform to search for.
People nowadays, including newbies, are not as ignorant as they were a few years ago still.
But again: I argue that people who don't know commands are not versed enough to create systems which contain a big amount of entities in one spot.
Servers which suffer from entity lag the most are usually also those who are so big that they got capable admins who do know about such a basic gamerule very well and can take measures however they see fit.
Servers which suffer from entity lag also do fairly know where it comes from.
Again: Entity lag is in nearly 100% of the cases player-induced, willingly and knowingly.
By making this gamerule default-on with a set amount of entities, it's taking away the Vanilla players' individual decision and patronizing them.
To decide this per default for "decidedly Vanilla" players and servers who cannot use any gamerules is depriving them of their gaming experience.
I'd argue that an individual decision has to prioritized over those very few cases where this gamerule can help newbies.
Again: Newbies play the game "as intended" and in the most cases don't do anything that can cause entity lag.
And what about the heavy- and lightweighted pressure plates?
There is a reason why they were implemented.
That default-on-gamerule is taking away for decidedly Vanilla players the majority of the reasoning why they were implemented in the first place.
Although the setting was removed, shaders are still used when spectating creepers and spiders. This report should be reopened. EDIT: Reopened by [Mod] Torabi.
This issue still occurs in 1.10.2, by the way.
[Mod] Torabi I will try to make it short, I feel I should rather open a post on Mojira-Reddit and link it in my post up there, but I feel I have to reply to you here so people don't think I'd agree with you or wouldn't have counter-arguments };] I don't know why you are arguing with me here and didn't make the suggestion to discuss this rather on Reddit, but I guess it might be maybe an emotional matter to you as well }=)
| Players who may produce lag-inducing situations unintentionally: [...] They're unlikely to know about the gamerule, and the only way it will really benefit them is if it's set to a low value by default. If it turns out to inhibit what they want to build, they can research the issue and make an informed decision. |
You can turn around this argument very well.
We could either talking about all the other gamerules where one could also say the very same things you said, or:
People who upgrade their world might be unlikely to know about this change and upon loading their world in 1.11 lose their entities that they willingly "crammed" into one spot.
As longtime-mod here on Mojira I don't have to tell you about the "poostorm" that would come after that.
| I think a good case can be made for defaulting to 0 for existing worlds, to avoid damaging contraptions that players have already made. |
Now that would be a compromise I personally could live with, but I'm not sure about most technical people/servers.
If it would be possible code-wise, that might be a way to not harm all old worlds/servers/players, but then it would have to be made very clear by Mojang..
I created a tweet-poll - will last for a week https://twitter.com/LapisDemon/status/784755247596134401
I will add your idea into my initial bugpost with an explanation what I mean with "to be made very clear by Mojang".
That being said, I really want to know why this decision was made, and as much as I like your theories, I'd like to hear from Mr. Bergensten himself, why.
I will open a post on Reddit and elaborate on the reason, why.
I'll be (as always) very open and maybe a bit emotional, but I really do love this game and most of its community; it's not as if I would want to harm anyone here, really.
I'm the first one trying to support the Devs, but some things just have to be said.
Edit:
Further discussion please on the Mojira-Reddit https://www.reddit.com/r/Mojira/comments/56h81l/discussion_maxentitycramming_gamerule_in_111/
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
I don't get why the two bug reports about horses are marked as duplicate of this bug. As [Mod] Torabi said, this report is about the mob AI not taking advantage of the jump boost. But the bug reports about horses are about the effect not getting applied to the horse.
[Mod] Torabi I can see where you're coming from, and usually I'd fully agree, but I learnt from an insightful comment-reply of yours here on the bugtracker years ago that not everything that gets resolved as "WaI" won't hypothetically ever be fixed - sometimes it can be that at that point in time it couldn't be fixed due to the state of the code for example, but that it could be revisited later, which is also what I've read from Devs. We all know that things can change in Minecraft over the years, and that "WaI" or "Won't Fix" is not set into stone, and if this change would benefit mapmakers, this should be taken into consideration, even more so considering this seems to be an inconsistency as I tried to explain in my previous comment, and Mojang seems to not be adverse towards fixing inconsistencies.
On the other hand, I can see how changing this could potentially affect other parts negatively, and thus I won't continue to argue
Just trying to explain a different perspective on this, and that others, who'd bump into this bugpost would not potentially be aggravated towards a decision Mojang or you Mojira-mods did, or at least can understand the reasons, why. Uncertainty and assumptions often lead to disappointment and sometimes even hate, toxic criticism, more or less hidden from public, which can accumulate, whereas knowledge, background intel, can hypothetically lead to an understanding and may lead to constructive criticism as well as input (e.g. on the suggestion website).
If you truly can't see hope for such a bugpost due to the aforementioned reasons (potential benefit, apparent inconsistency, changes of the code and potential new fixes over time), then, of course, the only way remaining for voforan would be to make a suggestion.
They are skeletons, animated by who knows what evil force. They need not be bound by human limitations. Also, all mobs have supernatural player tracking abilities. However, it is interesting, and Gravity notes, that their first shot has impeccable accuracy and speed, while their aiming on subsequent shots tends to be pretty laughable.
minecraft.exe is just the launcher. What you need to allocate memory to is Java. What's your rendering distance set to?
I was under the impression that the main point of water being unplaceable in the Nether was to prevent you from turning lava into obsidian, whether for easy collection or safety. You can still bucket or block it up, but that's not nearly as quick and easy as placing a water source and converting large swathes of it to obsidian.
Related to/duplicate of
MC-67?The EnderDragon is a unique mob, in that it only naturally spawns once. It's intended to persist until you kill it. The Wither, however, does not spawn naturally, but is created by the player, and multiple of them can be created.
To elaborate on what Aaron Mills said, mushrooms can be planted on any? block, as long as the light level in that space is below 13, and it's not open to the sky. However, the lighting rules do not apply if the mushroom is planted on mycelium – the light level or sky visibility does not affect mushrooms planted on mycelium.
Also refer to
MC-20. Apparently pistons are also affected.This is actually the better written of the two reports. Mark
MC-202as a duplicate of this one?Is it just slimes, or do other mobs still revert farmland to dirt when they jump on it?
Does it re-center if you close and then reopen your inventory?
I think it's probably for the best if it doesn't re-center immediately, because it could cause the player to click somewhere they didn't intend if the inventory window moves under their mouse cursor. Imagine trying to place an item near the edge of the inventory, and it moves suddenly on you, but you still click in the same place, resulting in you dropping the item you were holding on the ground – or maybe in a pit of lava.
Related/Duplicate
MC-218Related/Duplicate
MC-233Duplicate of
MC-155?Inventory and Ender Chest contents are stored based on the player's name. If your name changed for any reason, including connecting to the server without logging in to minecraft, you won't be able to access the proper inventory.
Not only Works As Intended, but also a duplicate of
MC-148!Spiders that are not currently chasing you turn non-aggressive in the daytime. If the spider takes damage from another source, they will stop chasing you. Thus, in the daytime, if a spider is chasing you, but takes falling damage, they stop chasing you, and turn non-aggressive.
Duplicate of
MC-477.Break as in turn into an item, or break as in be destroyed? Both can occur to the anvil.
Duplicate of
MC-7? Or not, because it specifies a later version?Gravity, if that's the case, then why can't you feed a cow more wheat in that 5 minute interval? There's an inconsistency there, and it seems like one of the two is probably wrong, though it's not clear which.
Duplicate of
MC-410, which is marked Works As Intended.Paintings and Item Frames are technically entities, not blocks. The Mob Griefing rule only affects blocks.
The question is why can't tile entities be pushed by pistons? I've never seen an answer to that, just the repeated statement that they can't. Yes, pistons use tile entities themselves for the block being moved, but the NBT format has a compound type that should allow the piston to package up the tile entity of the block being moved, then unpack and recreate the tile entity at the destination. Or just change the X, Y, and Z values of the tile entity to match the new position.
So was it a deliberate, game-balance sort of choice that blocks with tile entities cannot be moved by pistons, or something that just seemed like too much work to implement?
Duplicate of 136? Does it happen while extending, or while retracting?
The previous functionality was a bug. A very strange one, with some useful properties. They've kept some "buggy" behavior in the past, when it was useful, and didn't negatively affect other things, but this appears to be something they either weren't aware was being used, or was changed to fix some other issue.
The wiki lists "Fixed being unable to switch tools of the same kind in your inventory." in the changes for the 12w18a weekly build (before 1.3.2), and at the time, I hoped that it meant the issue described in this ticket had been fixed. However, the change list on the Mojang page didn't mention it.
The ability to repair tools by combining them made it so that you'd want to swap tools out before breaking them, and this bug makes that a pain if you want to keep your inventory organized.
But didn't chests display the cracks in the past?
Duplicate of
MC-404.Duplicate of
MC-272. Also probably intentional, as the inventory suddenly shifting around the screen could cause the player to drop items accidentally.And why isn't the game closing its sockets correctly? Software should respond appropriately to the user interface elements, such as the close button, or should disable the button.
That's because they are not accepting suggestions through the bug tracker. Just bug reports. Currently, the correct place for suggestions is the Minecraft Forums suggestions board.
The bug tracker is only for reporting reproducible bugs, so that they can be fixed. You need the support forum.
Post in the suggestions forum
Duplicate of
MC-858?According to
MC-398, (of which this is a duplicate), this issue will be fixed in the next version.Allow me to attempt to translate, for posterity:
There's a Pigman skin in the game, so why don't they spawn?
Mobs can only swim upwards in source blocks, not flowing water. Otherwise, they could swim up waterfalls. Then again, the player can...
This behavior is extremely useful for mob drowning traps. Whether that's a strike for it or against it in the developers' eyes, I don't know, but this behavior has existed for a very long time without being changed.
But it's a problem that nobody but you is having, and thus, there's probably no bug to be fixed, but an issue with your system.
Also, I've read elsewhere that Java 7 isn't stable on Macs yet. That's probably your problem, and there's nothing Mojang can do about it. You'll have to use Java 6 until Oracle/Apple gets it figured out.
Java 7 does not work properly on Macs. Thus, all Mac users attempting to run Minecraft with Java 7 are likely to have some sort of issue. Thus, Minecraft doesn't use Java 7 on Macs unless you force it to. You're causing your own problems.
EntityPigZombie extends EntityZombie, so it should inherit that attribute. Have you actually tested this in-game? Zombie Pigmen are armored (2 points), which may explain any difference in actual damage from expected damage.
Falling anvils damage things they fall on. I'm not sure if it's intended to damage transparent blocks, however.
Duplicate of
MC-95.Quasiconnectivity bug? Related to
MC-108?Soulsand is only 7/8 of a block tall. Thus, standing on it puts your feet below the surface of adjacent lava. I'm not sure that this is a bug. You should probably be on fire from being that close to lava anyway. It's called convection.
I do believe that's called "Ice".
But the description says that format codes can be used from within the game – they just must be pasted in from the clipboard instead of typed. Is that supposed to work?
Is this the same issue as the next one (
MC-1622)? That's listed as fixed in 1.4.4.Sounds like all the other tickets in which the sounds didn't play initially because they either failed to download, or were still downloading.
MC-395,MC-489,MC-981,MC-991,MC-1085, MC-1103,MC-1104,MC-1224,MC-1325,MC-1526, andMC-3055. I probably missed a few too.Duplicate of
MC-324? This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.Related to
MC-65.Duplicate of
MC-119.As Alec said, this is a duplicate of
MC-1417.Is there another sound file in the game that you think was intended for the Fire Charge?
Capitalizing the first letter of each word is a crime against the English language, and assault on the reader.
This sounds like a feature request. Try the suggestion forum.
Duplicate of
MC-206.No, submitting feature requests to this tracker would also be a feature request, not a bug. They are not accepting feature requests on this tracker at this time. The correct place for those right now is the suggestions forum.
Duplicate of
MC-676.Related to
MC-67, though that only specifies joined entities, such as a minecart with something in it.To clarify: You put the item in the beacon's gui slot, but do not click the check box to consume the item and activate the beacon. The item remains in the gui slot, but if you break the beacon, the item is lost instead of being expelled.
Related to
MC-1847?This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
This apparently is an issue with the newer version of Paul's 3D Sound System used in Minecraft 1.4.2 and PowerPC Macs. Try replacing minecraft.jar/paulscode/sound/codecs/CodecJOrbis.class with an older version, such as that from Minecraft 1.3.2.
Kevin, lily pads are transparent blocks, just like stairs and beds, which this, and
MC-2250are about. The only one that might be a separate issue isMC-3402, which does not specify a particular block.However, the timer stops while the chunk is unloaded. That may explain why some people would believe different time values.
It should be clarified that this is about wild wolves, not tamed wolves. From Grum's comment, it looks like he thought this was about your tamed wolves not becoming angry at something you hit and kill, rather than wild wolves not becoming angry at you for killing their packmates.
Duplicate of
MC-233.That is joyous. I vote that it not be fixed.
That would be awesome. As a workaround in the meantime, I've found that attaching the hinge of the trapdoor on a different side than the ladder makes going up much easier, though it's still not perfect.
So has the status on this changed, since Dinnerbone has marked
MC-1969as fixed in 12w50a? This certainly seems contradictory with the claim that the behavior listed here is "by design, and thus not a bug", though I suppose he could have decided to change it anyway.Except now it's marked fixed. It's not clear what the resolution is, whether passengers are teleported or just empty minecarts. But it is something we someone could check, right now, since 12w50a is out.
Would you please expound upon that? Why is it intentional? Is this a technical limitation, or a deliberate gameplay choice?
What's confusing about this is that apparently the top is biome-colored in fast, but the sides are not. Why is the top still colored in fast, if it's an expensive operation? If the method used for the top is different, and isn't an expensive operation, then why isn't that same method used for the sides?
It would probably look better if it were at least consistent.
This is either a bug, or Working as Intended, but certainly not a feature request. It is inconsistent and unexpected behavior. It previously did not occur, but now does as a result of a code change.
Duplicate/related MC-3059?
Didn't sand falling on a torch previously cause the sand to turn into an item? I've read about people using that as a fast way to harvest sand and gravel.
Why is everyone acting as if this must be an all or nothing feature? The command could be modified to check whether an item can stack or not, and respond appropriately. I think it would be nice if using /give with non-stackable items would give you all the items you asked for, but not in a single stack.
I never realized boats in MC had a front and a back. The icon appears to, but the entity does not. Almost every time I get in a boat, I have to fight it to get it to move in the desired direction. Maybe you should always be faced in the direction of the front of the boat when you get in it?
Determining which blocks should be rendered isn't a completely free operation either.
I think what the reporter is saying is that the item created by breaking the cactus block doesn't always clear the base of the cactus, thus being destroyed with no chance of being picked up. They're saying that the item should fly further, or at a different angle, or just reliably not fly directly at the base of cactus.
They're not saying that cactus blocks destroying items is a bug.
Related to / blocked by
MC-3471?There have been a number of similar issues reported, but most of them are just about the clouds forming underground. This is the only one I can find that clearly describes how everything above the clouds is invisible, replaced by open skies, when you're within the clouds.
What I find odd is that it doesn't either deactivate the portal on the other side, or reactivate the nether portal when someone goes through from the other side.
I suppose this is because it's searching for the nether portal blocks itself, and not the obsidian structure, but when this happened to me, the second nether-side portal overlapped the first one. It was messy.
Some items are supposed to stack. Others are not. The /give command should not circumvent that, because it causes other code that does not expect stacked items to perform in unintended ways. That, or those other instances should be fixed to properly handle stacked items.
When a dispenser is triggered, it picks an item from its inventory at random. It then uses it in a way appropriate for that item. Empty buckets, when used on water and lava source blocks, remove the source block and change into the appropriate type of full bucket. The current behavior is just the consequence of that.
What you're asking is that it should not pick randomly, but should choose which item to use based on the block in front of the dispenser. This is a request for a change in functionality, not a bug report.
Related to
MC-418, should be a similar fix.Aha! I knew I've seen a couple other reports like this on the tracker!
MC-362andMC-2293are both the same problem, but without enough information, so they were marked as "Cannot Reproduce" and "Incomplete". However,MC-2131is still open, and describes the same problem.Lava is not water. Unfortunately, minecraft's simulation of lava is not only inconsistent with reality (like virtually every other video game with lava), but also inconsistent with the consistently inconsistent portrayal of lava in fiction.
You probably shouldn't be able to swim, or even sink, into lava. It's more like sand, except ridiculously hot. It's molten rock.
Quite a few issues on the tracker already like this.
MC-95,MC-756, andMC-1291are all probably relevant.As per
MC-1291andMC-4141, it's likely this has not been fixed.Failed connection? My guess is that they attempted to connect, but failed for some reason. Perhaps the connected line only shows up once the player has connected, but the disconnected line will show up even if they didn't complete the connection?
Sounds kind of like
MC-4068. AndMC-73, andMC-754. They're probably all related. Pretty sure it's not an intentional limit, since the new maps are intended to be copyable, servers, can have a lot of players, and a marker shows up if you put a map in an item frame, so they would have to have expected you to need more that 3 makers.Then all other instances of item handling code that assume an item cannot stack should be modified to handle stacked items correctly, so that things like an entire stack being used/consumed/destroyed instead of a single item from the stack won't happen.
Then how would you know someone had even tried to connect? I think in such a case, there should be a "connection failed" message, instead of either the connected or disconnected message.
But should snowballs cause damage to armor, when they don't do any damage to players? That's what it sounds like the report is saying, but I'm not sure that they do.
Metadata is precious. There are only 4 bits per block, and thus 16 possible values. For slabs, the most significant bit is used for orientation (1 == upside-down, occupies the top half of the block instead of the bottom half). That only leaves 8 possible varieties/textures, of which they've now used 7, including the unburnable "wooden" slab that was kept as a concession to existing maps.
What people are suggesting is that they reserve the last available value for a block they never intended to exist, and you've never been able to get legitimately? It's one thing to expect them to never break legitimately built maps with an update, and another entirely for them to never break unintended things created through unsupported methods. You had to do something outside the norm to create it in the first place, so you should expect to do something equally outside the norm for it to survive an update. The game as intended should not be harmed or limited by the developers bending over backwards to support things they never intended.
I would think that with mobGriefing false, the sheep would still eat grass, but it wouldn't change the grass block into a dirt block. mobGriefing false does prevent farmland from being reverted to dirt when jumped on, does it not? That seems like the most similar event.
I believe this is Working as Intended. The item in the right slot is always consumed. It is up to the player to figure out the most efficient way to use the anvil. Sometimes the experience level costs will vary just by switching the items in the two slots, and Mojang has said that this is intended. See
MC-3880and MC-4129.Dup/Related
MC-1720,MC-1829,MC-3513?Related to
MC-242, but this is more specific.Duplicate of
MC-4534.Dup/Related
MC-3332?Whether or not a particular behavior is a bug is up to the developer. If it's working how they intended it to work, then it's not a bug, no matter how much the user may dislike it.
What you're requesting would make more sense to you, but could be confusing to someone else, and may break their creations.
Duplicate of
MC-4061. Do you still have the world this occurred in?Can you zip it up and attach it to the ticket, so that the Mojang can research this? This sort of bug has happened to a couple of people, but nobody's figured out a way to make it happen on demand, making it hard to determine the source of the bug.
Before 1.2, biomes were recalculated every time it loaded the chunk, meaning that when the generation function changed, the biome in a chunk could change. Since 1.2, biomes are calculated once, and stored in the save file. Thus, even if the biome generation changes, existing worlds should not be altered.
What we need is a conversion tool for old worlds that will calculate the biomes for the version the world was created in, and store it in the new format, so it won't get changed.
Xavier, that's how it works now. Biomes won't change on you. But the trick is getting pre-1.2 worlds, where that information wasn't saved, into the post-1.2 format with their biomes intact.
Though I'm not actually sure what happens if you go directly from beta-1.8 to say, 1.4. There is a conversion process, but I don't know what it uses to determine the biomes. I've got a 1.8 world myself that got messed up by multiple biome changes, and it was exceedingly frustrating. I haven't tried importing my backups into 1.4 to see what would happen yet.
The unsupported block in question doesn't look like a double slab. If it is officially added, perhaps it would be better as a variant of another block, such as block 1.
That's ridiculous. Of course Java will allow it, just like it allows the lid-opening animation. The programming language itself is rarely a limitation. The question is just how much work it will take to make it work with the rest of the code.
I'm experiencing this in survival as well.
Duplicate/Related to
MC-5927?Hmm... Isn't this interesting. Compare with
MC-5735.Minecraft includes some Bouncy Castle code. So it's probably an interaction between the code embedded in Minecraft, and the external Bouncy Castle security provider. I don't have any idea which component the bug lies in though.
Then use Java 6, or try a different version of LWJGL. Or post in the official support forum, and see if they can help you: http://www.minecraftforum.net/forum/151-unmodified-minecraft-client-support/
That is the question at hand. Is it intended that the sound always play relative to the player, or to the camera? Only one of the developers can answer that.
More useful for you, maybe, but certainly not more useful to the developers. It's not like these bugs only happen to you, or that when they fix them, they will only be fixed for you.
Possibly related to
MC-2758orMC-7082?Sharpness, Smite, and Bane of Arthropods are all mutually exclusive, regardless of the tool or enchanting method.
Standing next to a lava flow in real life will melt your shoes, if not set your legs on fire. You don't have to touch it, just get close to it. Then again, lava also tends to be significantly more viscous and denser than water, so you wouldn't sink in it either. Minecraft gets this wrong, just like virtually every other game, or fictional portrayal. However, fire can set various flammable blocks on fire at a distance in Minecraft, showing that they're not entirely unaware of the concept.
Tails, this actually doesn't appear to be a duplicate. The report is about the "mining" sound, not the "breaking" sound. Normally while mining a block there is the sound of you hitting it with your fist or tool. Hitting an anvil is completely silent.
Probably related to or a duplicate of
MC-1720.My point is that there's no clear basis on which to call this a bug. Both the behavior expected by the reporter and the game's behavior are unrealistic. However, the game's behavior is also consistent, in that the player is inside the lava's block (visually, and as per the coordinates), and thus is set on fire.
A random person says "Works as intended." A random mod then changed the resolution field to "Works As Intended". Occasionally, if you're lucky, a developer will actually be involved, or a source can be found of them saying that some thing or another is intended.
It really doesn't matter whether an issue is classified as a bug or a feature request. What matters is that you make a compelling argument for the change, and the developers have a chance to see and consider it. So go with the flow. If an issue you care about is rejected here, don't fight it – post on the suggestions forum or subreddit.
A redstone signal does not "lock" the hopper. It merely stops it from operating, meaning that it no longer pulls items from the space or container above it, and no longer pushes items into the space or container pointed to by its output. Because hoppers are containers, hoppers can pull items from other hoppers, regardless of their operational state.
The primary purpose of hoppers, as far as I can tell, is to give us a way to automatically put items in containers and pull them out. The enables the automatic collection of mob drops and the transportation of items via minecarts. They weren't necessarily intended to make sorting machines, but people will figure out a way that works regardless.
And, to put it simply, it's easier to program the way it is.
What's most likely happening is that the lower minecart with hopper is sucking items out of the upper minecart with hopper. Try disabling the upper minecart by running it over a powered activator rail – the items should continue to be pulled from the upper cart into the lower one. Conversely, run the lower minecart over a power activator rail, and it should stop.
It's not exactly the same issue, but it would be resolved at the same time, because it involves the same code.
It really doesn't matter whether an issue is classified as a bug or a feature request. What matters is that you make a compelling argument for the change, and the developers have a chance to see and consider it. So go with the flow. If an issue you care about is rejected here, don't fight it – post on the suggestions forum or subreddit.
Hmm... Sounds like it might be related to
MC-4061.Woah, wait, what? I've seen statements to the effect that anvils are supposed to give you more control over enchantments, and to allow you to extend the lifetime of a tool, but never make it last forever. The gradually increasing cost is supposed to force you to replace it eventually: https://twitter.com/Dinnerbone/status/259411094513266688
I would guess that by saying it's working as intended, you're referring to this: https://twitter.com/Dinnerbone/status/263034706084380672
But renaming is only supposed to provide a discount, extending the maximum lifetime of the item further, not make it so that the cost never increases.
https://twitter.com/Dinnerbone/status/298034460346171393
I wasn't suggesting a solution, I was suggesting a testing method to prove the exact cause of what you experienced. This is probably related to
MC-6266.A hopper normally needs to be attached to a container in order for it to put items in it, doesn't it? The primary purpose of hoppers is to pick up items from the world, and pull items out of containers. Do you really want a minecart rolling along spitting items all over the place, or needing to use activator rails at every stop to prevent it? The current design gives the greatest amount of control with the least amount of effort or resources.
And why would Mojang be interested in helping you help others pirate Minecraft? While they have a pretty lax stance on piracy, I don't think they'll appreciate your attempts to mimic the value-added services of authentication and custom skins that are supposed to be part of the motivation for purchasing Minecraft. You might want to get your moral compass checked; it seems a bit off.
And you think it's intended that it give a vague, unhelpful error message that doesn't help the player figure out what's wrong? It sounds more like a default, fall-through message, that's only there to catch errors the developers didn't anticipate, i.e. bugs.
Just imagine... what would it be like if only the 1755 valid reports out of those 9000 had been posted? If only people would learn to search...
Wouldn't it be better to make the buttons wider? I would think making the text fit in Spanish would make it pretty awkward or hard to understand. Some languages are wordier or take more space than others.
Related/Dupe of
MC-4061.The whole point is that other people can see your Minecraft account name, and using public information for authentication is a security risk. Using your email account for a login is also a security risk, but marginally less of one, since it's not publicly visible, and should only be known by people you have given it to.
It's intended for it to be impossible to remove players who are not logged in from the scoreboard? There's no indication on the wiki that the command "scoreboard players reset <player>" only works for online players. I haven't tested it myself, so cannot confirm either way, but it's definitely not possible to call it "Working as Intended".
I believe the reporter is referring to this or this. Maybe.
Minecarts, including those containing other blocks such as chests, furnaces, hoppers, etc. are actually entities, and not blocks. Shift-right-clicking only prevents the GUI from opening on blocks, so that you can attach blocks to things like chests. Because a minecart is an entity, and can move freely, you can't attach blocks to it – blocks can only exist on the 1-meter grid, and never in between two grid spots. Falling blocks, such as sand, gravel, and the anvil, cheat that rule by temporarily changing into entities while they are falling, during which time they do not function as blocks.
But why doesn't the XP drop on the ground like it does when a player pulls the items out? It doesn't actually give the XP directly to a player, it just spawns it, like when you kill a monster or mine coal. I doubt that it's actually "Works As Intended" that it doesn't generate XP when removed by a hopper, but it is possible. Seems more like it's just related to all the other hopper bugs at the moment.
It's not a bug. The doors are not on the same block. In your picture, one is on the wood, the other is on the stone. Doors can be positioned on any side, with the hinge at any corner, ever since 1.2 or so. If there's a wall, doors will automatically flip so that the hinge connects when you place it.
Sounds like
MC-4644, which was supposedly fixed for 1.4.6. Maybe it wasn't fixed completely?The slider exists because perceived brightness may vary depending on a huge number of factors, including: viewer, ambient light, monitor, video card, drivers, gamma correction settings, OS, etc. Because they cannot make it consistent across all those factors, the slider is provided so that the user may adjust it as necessary.
Their wool regrows after they eat grass. Are your sheep standing on grass blocks?
https://www.google.com/search?q=%22%E4%BD%A0%E5%A5%BD%E4%B8%AD%E5%9B%BD%22
https://www.google.com/search?q=%22%E4%B8%AD%E5%9B%BD%E4%BD%A0%E5%A5%BD%22
Google returns quite a few results for each (206,000 for the former, 1,900,000 for the latter). Even if it's technically wrong, it's apparently used that way by actual Chinese people. It may actually be intentionally "wrong", as several of the English messages certainly are, as they reference various internet memes.
Dupe/Related
MC-1029?You cannot set your spawnpoint (by sleeping in a bed or otherwise) in the Nether or the End, in order to prevent you from getting stuck there, since the materials necessary to leave are not available in those dimensions, but must be brought there from the overworld.
Regardless, this tracker is only for base, unmodded, vanilla Minecraft. MCEdit issues should be reported here: https://github.com/mcedit/mcedit/wiki/Reporting-Issues
Post feature requests on the suggestions forum or subreddit.
Hmm... Maybe related to
MC-1124?Does this occur when attempting to log into different servers with each client? While it makes sense for it to be intended when logging into the same server, I don't think it sounds like an intended error while logging into different servers.
It is interesting that you can find floating sand, but not floating gravel.
Pretty sure performance issues due to poor implementation qualifies as a bug. In the case of this issue in particular, fixing it may help with some of the ghosting or desynch type of issues people keep encountering.
Notch posted about this on reddit about a year ago. He confirmed that it was a bug, decided to leave it alone for the time being because people liked it, but warned that he might decide to fix it later. Mojang's bugfixing strategy hasn't changed, as far as I can tell. Bugs people like are generally left alone, unless they cause problems or get in the way of fixing some other, undesirable behavior. However, that doesn't mean they've given up the right to decide to fix bugs even if people like them. It's still their game, and the solutions they provide are usually better than the original buggy behavior people got used to.
As it is, obsidian is renewable. Even without exploiting the extra blocks nether portals make, the nether is practically infinite, and full of lava. It's not that the quantity of obsidian that can be created is very limited, it's about the danger in acquiring it.
I could see this being declared a feature, since there's some level of logic to it (flowing lava + redstone = molten redstone, molten redstone + water = obsidian), and that could be expanded upon, made into interesting gameplay, but string is a lot harder to swallow.
Ideally, the best solution should be applied to a problem. Looking at existing solutions before attempting to solve the problem yourself can be harmful, because it shifts your perspective from thinking about the problem to thinking about that specific solution. It can deter you from discovering a better one that is fundamentally different.
Also, implementing a bad solution to a problem can lead to a good solution never being implemented – people get used to dealing with the bad solution, and are resistant to change, even if it's for the better. Sometimes it's better to take a little extra time, and do something right the first time.
But why would it be difficult? I've only given the code a cursory look, but it seems as simple as changing the X, Y, and Z fields in the related tile entity. It's not clear if it's a mapping issue, a serialization issue, a transactional issue, etc. I'm not saying it's simple, just that it looks simple, so it would be nice to have an explanation why it's not, if that's the case.
@misa: I'm not saying that it's best to avoid all input or existing solutions, but that there can be hazards to jumping immediately to existing solutions without spending some time thinking about the problem yourself. You risk getting trapped in local optima, because you are skipping part of the creative process. That doesn't mean you can't come back to it, but you're less likely to do so, both because your problem is partially solved (though not necessarily optimal).
There are many possible strategies, and it's probably best to include both research on previous attempts and existing solutions (to take advantage of that which has been done by others), as well as personal research (so as to take advantage of whatever unusual traits you may possess that would provide new insight to the problem). The question of how much time and effort to spend on each strategy, as well as what order to execute them, will depend on the individual.
I'm primarily arguing against the demand that existing solutions be accepted and implemented without thought or analysis – here specifically that an innovator in a field should stop innovating and just do what someone else has already done, because that's what people are used to. Mojang may end up solving this particular problem exactly the way MCPatcher does – but it should be because they determine it to be the best solution, not because of any historical reason. Concessions to history generally end up being harmful long after anyone can remember why they were made.
MC-8648is marked "Works As Intended", while I would think it pretty clear that it isn't, given the links I've provided in the comments there.The texture pack unstitcher swaps the potato and baked potato textures. That's probably the cause of the experienced issue.
MC-6842.Also, just found this comment here on the tracker by Dinnerbone, posted after the tweet about renaming providing a discount, verifying that it's still intended that:
All switches (levers, buttons, pressure plates, detector rails, tripwire hooks) power both the block they are in, and the block they are attached to. Redstone Torches are the only exception, powering just the block they are in, and the block above them. It would make the most sense for the daylight sensor to behave like other switches.
However, other entities do not catch fire merely from proximity, but must come in contact with lava in order to ignite. Blocks and entities are inconsistent in the respect.
That line in the snooper data doesn't specify whether or not the client is modded, it specifies the client brand, which a mod may or may not change. Forge does, modloader might. It might be useful if they had a "modded" field in the snooper, but that's up to them whether or not they consider it useful.
According to Dinnerbone's comment on
MC-10026, the kill should go to whoever did the most damage, not necessarily the first or the last one to hit them.Duplicate of
MC-6484. The issue Kumasasa encountered while attempting to reproduce this one is probablyMC-3668.So... what should happen? Depending on how this behavior was changed, it could make climbing a ladder with a trapdoor at the top rather difficult.
Well, they've said a few times that issues are addressed roughly by vote count, with issues with more votes getting higher priority. It looks like this issue is sitting around 70th place, sorting by votes.
The resolution field applies to the issue report, not the bug itself.
This issue report is resolved. The resolution is that it's a duplicate report of
MC-5415. If you examine that report, its status is Unresolved. So while the bug has not been fixed, as indicated byMC-5415, this issue report is closed, and further comments on the bug should be posted atMC-5415. Also, if you voted for this issue to be fixed, you should go vote onMC-5415. Votes do not currently transfer from the duplicate issue to the it is marked a duplicate of, as per JRA-3731, so if you want the issue fixed, you should vote for the issue this has been marked a duplicate of.Redstone turning into obsidian is a bug. They've left it alone all this time because people liked it, and it wasn't hurting anything – thus, it wasn't worth the time it would take to track down the cause and fix it. However, it's never been declared a feature. If they accidentally fix it in the process of doing something else, they're not going to take the time to put it back, because, once again, it's not worth doing anything about it.
Along the same lines, it's not worth it to them to "fix" issues with it like it not working with powered redstone vs unpowered redstone. The fact that string now also triggers the bug may make them reconsider it as a problem, and lead them to spend the time required to fix it. In that case, they'd probably fix the original bug of redstone turning into obsidian, thus making none of them work.
Jeb considered and took action on
MC-973, a similar issue. That one only was painful, with no risk of seizures. I would think if that issue qualifies as a bug, so too would this one, which has a greater risk of consequences.It certainly can't be "intended" that Minecraft would cause seizures, and thus this may qualify as a bug in Mojang's eyes.
Telling potentially affected people to "just not play video games" as a solution is remarkably poor.
Gravel, while falling, is an entity and not a block. What you're seeing is Minecraft deleting the entity and placing the block. This is going to be very system-dependent, but it's interesting that FireHunterX only experiences it in survival, and not in creative.
Minecraft does not support partial transparency for armor textures. MCPatcher or Optifine may add partial support. Mojang is not responsible for bugs with modifications to their code.
If you would like to request that partial transparency support be added to vanilla Minecraft, post on the suggestions forum or subreddit.
You're still washing the leather armor, even if it's not dyed. Are you saying that washing undyed leather armor shouldn't consume water, or that you should be prevented from washing undyed leather armor?
The destruction animation is special, because it's not a timed animation, but an effect displaying the status of a block breaking. I don't believe you can put multiple frames in one file like you can other animations. You must follow the format of the existing animation: replace the destroy_0.png through destroy_9.png files, with one frame in each file.
There's nothing inherently wrong with any of the things you list, any more than there's anything wrong with bats or them making noise. The specific details that can cause seizures can be changed, generally without much, if any, perceptible difference to someone who wasn't at risk of being negatively affected in the first place. Once again,
MC-973. The problem was high-frequency noises that most people couldn't hear, and were painful for anyone who could hear. The sounds could be modified to remove the problem without any perceptible difference to people who weren't affected.This report is kind of difficult to understand, because minecraft beds don't have footboards. I had to look at the pictures to figure out that the issue is with the legs.
Issues are addressed roughly in order by number of votes. This issue currently ranks #62.
Issues are tackled roughly in order by the number of votes. Duplicate reports do not add to the vote totals, and so, in a way, the more duplicates an issue has, the less likely it is to get fixed quickly. Duplicates are usually submitted by users who are unfamiliar with the tracker, and either unwilling to search for existing reports or incompetent at doing so. They're equally unlikely to notice the voting feature or understand its importance.
Currently, 676 issues are marked "Fixed", 1334 are still open, and 10365 are Won't Fix, Duplicate, Incomplete, Works As Intended, Cannot Reproduce, or Invalid. Thus, out of 2010 potentially valid issues, 33.6% of them have been fixed. Since only 16.2% of the issues filed on the tracker are valid (out of the current 12375), I'd say Mojang's doing a pretty good job – at least twice as good as the community complaining about bugs.
As far as I'm aware, the spawnpoint protection is there for the benefit of new players on a server. It's not intended to protect spawnpoints set by the /spawnpoint command or sleeping in a bed. It's the player's responsibility to protect a player-set spawnpoint by lighting it up, but a player just creating a world or joining a new server doesn't have that ability, so the default spawnpoint is protected for them as a convenience.
But when you actually create the world, are cheats on or off? Given that the nature of the original bug was a contradiction between the UI and the functionality, it's important to test that the actual issue has been fixed, and not just the visual aspect.
How is the issue described here different from
MC-5733? They both describe the same "problem": hoppers connect to whichever block face you right-click on to place them, while the user expectation is that hoppers will automatically target an adjacent inventory (without considering the possibility that there could be multiple adjacent inventories, and thus it being unclear which one it should connect to in such an instance).Related to
MC-4661, possiblyMC-12000. Probably caused by the AI attempting to find a path to a point on the other side of the fence. The directional bias could be a result of the search algorithm.It really doesn't matter whether an issue is classified as a bug or a feature request. What matters is that you make a compelling argument for the change, and the developers have a chance to see and consider it. So go with the flow. If an issue you care about is rejected here, don't fight it – post on the suggestions forum or subreddit.
The world spawn point is stored in the level.dat file, and changing it changes both the default spawn point and the block protection area. Although I haven't examined the code to be sure, it's likely that the monster spawning algorithm uses this same, moveable spawn point, and not just one generated from the seed. So it is likely that the compass would point to it, single- or multi-player. Probably best if someone tests all this though.
Seems similar to
MC-6047, though not identical.Kinda related to
MC-590, in that a fix for one may inadvertently fix the other, depending on how it's done.Rather than create a new issue report, you should have commented on the original issue that there was still a problem, with proof, and someone would have reopened it.
Partially a duplicate of
MC-12643, and related toMC-108.As this issue is currently resolved as "Won't Fix", which prevents users from voting on it, I suggest that anyone that cares about it vote on
MC-10426, which is the issue for the custom kerning Grum mentioned as a solution for this issue.