[Mojang] Searge (Michael Stoyke)
- searge
- searge
- Europe/Stockholm
- Yes
- No
relates to
relates to
relates to
relates to
They do read bug reports, because the various developers occasionally comment, assign themselves to bugs, fix the bugs, and mark them fixed. However, there are over 2000 open reports, and over 40000 total reports on the tracker. Most of which are garbage, either because they're duplicates, incomprehensible, or not actually bugs. It's a lot of work to sift through it all looking for valid issues to address. And despite how many employees Mojang now has, very few of them are actively developing Minecraft. Something like 5, now that Mog (Ryan Holtz) and [Mojang] Searge (Michael Stoyke) have joined the team.
The vote count also figures into putting priority on fixing bugs. This one is also obviously not an issue for many people, as there are only two votes (one of them's mine!), and zero duplicate reports. The thing is, no matter how quick and easy it would be to fix something, there's still hundreds, if not thousands, of other things all demanding the same time and attention. Fixing this would mean something else gets put off, even if it's only by 5 minutes. With so many people filing reports, some of them are bound to be put off, no matter how fast they work.
Also consider that fixes based on decompiled code are useless to the Mojang developers, because it's nothing like the actual source code. I'm kind of surprised this bug survived the big code review, however.
Comment of [Mojang] Searge (Michael Stoyke) in MC-48402:
it's dx, dy and dz and you can not use negative values for them
[Mojang] Searge (Michael Stoyke) wrote
Use "/scoreboard players reset * score" instead of "/scoreboard players set * score 0" to remove scores from the players.
This behaviour may be intended, [Mojang] Searge (Michael Stoyke) wrote in MC-50145:
Use "/scoreboard players reset * score" instead of "/scoreboard players set * score 0" to remove scores from the players.
I take it you're not aware that the person in charge of MCP, [Mojang] Searge (Michael Stoyke), is now a Mojang employee? Mojang has provided both the MCP and Forge teams with inside information in the past as well. It's not lack of information that holds them back, but the difficulty of getting the code to decompile, deobfuscate, recompile, and reobfuscate properly.
They're not going to release the actual Minecraft source code. The fact that mods are compiled against MCP, rather than the original source, is itself useful. They've shared small bits of code, and have shared a lot of information with the community. But their goal is to provide a plugin API that makes it unnecessary for people to decompile Minecraft in the first place. That's the cause of many of the sweeping changes to the codebase that have made it so difficult for MCP and Forge to stay up to date.
What do you mean by "reset the world"? Are you exiting and saving? recreating the world?
It's intended that subtitles persist through multiple uses of the same title, within the same world. See [Mojang] Searge (Michael Stoyke)'s example.
The CustomNameVisible tag does not work on animals and mobs, because they have different rules about showing the name. For the other entities it should work.
Neither
{CanPickUpLoot:1}nor
{CustomNameVisible:1}Working.
[Mojang] Searge (Michael Stoyke) in MC-57793:
Some block types are only used internally and won't have an item anymore.
As [Mojang] Searge (Michael Stoyke) has said:
Use gamerule sendCommandFeedback to toggle this behavior
[Mojang] Searge (Michael Stoyke) in https://twitter.com/SeargeDP/status/492327454867226624:
And there we go, 14w30c is released and contains even more bugfixes. But probably also some more black patches, so we can lure trees back in
This report was closed as "Works As Intended" due to the following comment by [Mojang] Searge (Michael Stoyke):
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag
When summoning other mobs with the "NoAI" tag set to 1, they will not fall due to gravity, nor will they be knocked back by damage taken. Squid, on the other hand, are affected by gravity and knockback.
/summon Squid ~ ~ ~ {NoAI:1}
The tag does work correctly for other features, such as swimming. Ghasts will also be affected by knockback, though the tag does prevent them from flying around normally.
/summon Ghast ~ ~ ~ {NoAI:1}
[Mojang] Searge (Michael Stoyke) in MC-61587:
Mobs don't serialize their orientation
[Mojang] Searge (Michael Stoyke) did assign himself to the ticket, and didn't mark it "Works As Intended", so it very likely isn't. The problem is that one part of the code (which block affects the player) only seems to consider a single point, but another part (bounding boxes) considers an area. While that may have been intentional before, the consequences of that behavior intersected with Slime blocks probably isn't. Fixing it probably won't be a trivial change, however. Would you like it if landing mostly on a block next to lava also counted you as landing on the lava?
[Mojang] Searge (Michael Stoyke) wrote in https://twitter.com/SeargeDP/status/503927350199738368
Even though we "fixed" wither skulls in pre2, map makers should NOT use them as position markers anymore, they will not work in the future.
https://twitter.com/SeargeDP/status/503933548177268737
Armorstands as position markers, with Small, Nogravity and Invisible set to true, DisabledSlots set to 31. Until we have something better.
Invalid as nametags on mobs are supposed to become invisible as soon as you stop focusing on them with your mouse. As [Mojang] Searge (Michael Stoyke) wrote:
The CustomNameVisible tag does not work on animals and mobs, because they have different rules about showing the name. For the other entities it should work.
As [Mojang] Searge (Michael Stoyke) wrote:
Slimes can have one of three sizes, everything else is not supported.
[Mojang] Searge (Michael Stoyke) added a comment - 10/Jul/14 12:18 PM
Right now only commands support the named ids. NBT tags are updated later and still use numerical ids.
the enchantmet and effect names are the same issue, using the name in the tag is not supported, only commands
Please note that this is a bug tracker, not a discussion forum, and that this bug is already scheduled to be fixed in a future version. There's no point in discussing what is or is not possible, whether or not it it's a bug, and whether or not it should be fixed. Mojang has already decided to fix it. Check the ticket history, or just look at the fix version field up at the top.
[Mojang] Searge (Michael Stoyke) made changes - 29/Jul/14 4:21 PM
| Fix Version/s | Far Future Version - 1.9+ [ 15074 ] | |
| Status | Open [ 1 ] | Open [ 1 ] |
No.
[Mojang] Searge (Michael Stoyke) on 18/Jun/14:
the reset subcommand removes a score from a player completely. this is not the same as setting it to 0 using the scoreboard player set command.
Resolution Works As Intended [ 6 ] Assignee [Mojang] Searge (Michael Stoyke) Status Open [ 1 ] Resolved [ 5 ]
???
Because
the reset subcommand removes a score from a player completely. this is not the same as setting it to 0 using the scoreboard player set command.
or with other words: Because [Mojang] Searge (Michael Stoyke) coded this to work that way.
[Mojang] Searge (Michael Stoyke): Wow!
When bugs that have been around this long (and with over 200 votes) gets fixed it gives some new hope!
Good job! This is a big step in the right direction!
Sadface ![]()
I hope you will be able to fix it and get it in to a pre-3 or somethging.
Good that you are working on it at least [Mojang] Searge (Michael Stoyke).
We love you for trying to fix a bug as old as this one. ![]()
[Mojang] Searge (Michael Stoyke) on reddit:
I recommend {Invulnerable:true,Invisible:true,Marker:true}
Still not a bug per Mojang:
The CustomNameVisible tag does not work on animals and mobs, because they have different rules about showing the name. For the other entities it should work.
Thus, its still MC-57516
[Mojang] Searge (Michael Stoyke):
The CustomNameVisible tag does not work on animals and mobs, because they have different rules about showing the name. For the other entities it should work.
[Mojang] Searge (Michael Stoyke)
Custom names for items is fixed in the next version
Forward resolving to MC-65442, which [Mojang] Searge (Michael Stoyke) has marked "Won't Fix".
[Mojang] Searge (Michael Stoyke) tried to fix this by having the beacon eject the sacrifice item into the world when the player closes the beacon interface. The problem is that this incorrectly assumes that the only way for an item to get into the sacrifice slot is for a player to open the interface and put it there. Either hoppers and droppers need to be prevented from putting items in beacons, or the beacon blockentity needs to actually store the item in the slot. Currently, it's not saved, which is why destroying the beacon or reloading the world causes it to disappear.
[Mojang] Searge (Michael Stoyke) stated that this is intended behavior on MC-78527. If you want them to not immediately begin drowning, you should give the mob some air using a dataTag in the summon command. For example:
/summon Pig ~3 ~ ~ {Air:300s}
Relinking to MC-78527, where [Mojang] Searge (Michael Stoyke) has stated that this is intended behavior. Use a dataTag in the summon command if you want it to have air:
/summon Pig ~3 ~ ~ {Air:300s}
Duplicate of MC-66115. Issues related to NBT-changing commands will always be marked as intended, per [Mojang] Searge (Michael Stoyke)'s request.
As [Mojang] Searge (Michael Stoyke) has stated on several issues,
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
As [Mojang] Searge (Michael Stoyke) has stated on several issues,
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
As [Mojang] Searge (Michael Stoyke) has stated on several issues,
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Is there a particular reason anyone is worked up over this? What use are you hoping to put invisible armor stands to that is frustrated by them being invincible? Yes, this is less flexible. Yes, it's inconsistent. [Mojang] Searge (Michael Stoyke) had a particular use case in mind for invisible armor stands, and being able to damage them wasn't useful, so he just made them automatically invincible, rather than require the use of that tag as well. Basically, he made one use case require less work, at the cost of flexibility. Now, I agree that's kind of out of the norm for Minecraft, and maybe in conflict with the spirit of the game. But nobody's going to convince him of that by arguing semantics or trying to twist his words. I think the best chance you have of changing his mind is to propose something cool that you could do with invisible armor stands if they weren't invincible.
[Mojang] Searge (Michael Stoyke) in MC-61864:
Replacing blocks with tile entities is not supported, this is due to a limitation in the parsing of commands. It may be changed in the future, but not until after 1.8. This issue should be considered a feature request, not a bug.
[Mojang] Searge (Michael Stoyke) seems to be aware of the issue: https://twitter.com/SeargeDP/status/626414559100829696
Who says its not? [Mojang] Searge (Michael Stoyke) said that at first you could not get the structure block, but you can (however it seems like it currently does nothing)
According to [Mojang] Searge (Michael Stoyke), will be fixed in next snapshot by preventing shulkers from riding minecarts.
[Mojang] Searge (Michael Stoyke) Seems a bit crazy that they can't ride minecarts. Many of us like to create mob museums. To have one that must be moved with pistons only, especially considering where they spawn, would be incredibly painful. Consider making it so they can't teleport when in a Minecart.
Works as intended per Searge's comment:
[Mojang] Searge (Michael Stoyke) added a comment - 13/Aug/14 3:17 PM
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs, they will be marked as "working as intended",
[Mojang] Searge (Michael Stoyke) added a comment - 17/Aug/14 12:04 AM
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Per [Mojang] Searge (Michael Stoyke)'s comment:
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
Take a look at the following comment from Searge in MC-82854 (about different stairs rotation in snapshot 15w31a):
[Mojang] Searge (Michael Stoyke)
We unified the orientation of many items in the inventory
So, by that I expected that a few items (not only blocks) would be changed as well, so that all of them face the same way. And that's not what happened. For example, melons and glistering melons face opposite directions from each other since they were added, and that has never changed.
It's right that it's much harder to do it with items, since you can't specify which direction some of them - like a melon or a steak - are pointing to. So, I'm not asking that all the items face the exact same way - just that the similar-textured ones follow a pattern, like the melons.
Despite being that way since they were added, I've never found an opportunity to report that. But now that they're trying to "unify orientations", I think this makes sense to be reported. I did not play Minecraft when these items were added, which was very long ago. So, I don't know of any intended reason for them to face different ways. But if there was a reason, sorry, I didn't know anything about it!
Whitespace such as spaces and any characters used to define the structure of the data (curly braces, square brackets, commas, colons, etc) can cause ambiguity when used in a key or a value. Quotation marks remove the ambiguity, and were already required in some cases. While strict JSON is certainly more visually cluttered, and can require some extra effort to produce, it reduces confusion, both for the code that has to process it, and for the person writing it. Instead of getting strange errors or unexpected behavior when the parser interprets the data differently than the person expected, or wondering whether quotation marks will be required around a particular value, the answer is simply "always".
For Mojang, this makes future updates easier, because they won't have to make so many exceptions when parsing old data. As I said before, that's what caused signs to break in the snapshots.
user-f2760, as [Mojang] Searge (Michael Stoyke) said, "JSON parsing will be strict everywhere in the game". That means all commands will be changed in this way, even though they haven't yet. MC-37661 suggests that strict JSON not being accepted in some commands was a bug, that was then fixed, and now broken again, probably because they switched parsers at some point. In this case, it would probably be better to file a new issue than reopen MC-37661.
[Mod] Skylinerw wait, you have [Mojang] Searge (Michael Stoyke) on skype?
There are two basic motivations to declare something "Works As Intended", but only one of them is obvious to a non-programmer: the code produces the desired end result. However, in some instances, a programmer may care more about how the result is achieved than the result itself: they probably want the code to be elegant, easy to read, understand, and maintain. They may care more about performance than accuracy. Doing things the right way is sometimes more important than getting the right result. Catching corner cases can be both computationally expensive, and make it harder for them to update the code in the future without creating more bugs. If the undesired result doesn't interfere or disrupt their intended use case for the software, then it may make more sense to the programmer to not handle that corner case.
Here's the relevant history, as I understand it: The mob AI was originally built directly in the mob code, inherited when possible from one mob to another, with mob-specific behavior scattered throughout various functions. Jon Kågström was hired to write a generic artificial intelligence system, and built the basic targetting and pathfinding code before being moved over to Scrolls. Only a few mobs used this new code for a long time, with the remainder only being switched over fairly recently. However, it only handles very generic behavior, and all the unique behavior for each mob type is still buried in their respective classes, completely unconnected to the AI system, and therefore not controlled by it. The NoAI tag does one very specific thing, and that's disable the AI system for that entity. That's all it's supposed to do, and how that affect's the mob's behavior depends entirely on how much of that behavior is controlled by the AI system. From a programmer's perspective, that part's Working As Intended. The code that reads the tag, and the code that disables the mob AI work exactly as they're supposed to. The mobs just aren't designed correctly, because the AI system isn't developed enough to handle their specific behavior.
The right solution, and presumably the eventual goal, is to expand the AI system to cover a wider variety of behavior, and then rewrite the mobs to use it for all that behavior, removing all the special-case code scattered throughout their classes and consolidating it in code that interacts with the AI. That would be elegant, and far more maintainable. But the developers don't have time to do that right now: they're busy doing things like overhauling combat and the world storage format. Hacky solutions like scattering !this.isAIDisabled() checks throughout the code don't make the code more correct, even though they make it produce the desired behavior. They just increase the technical debt, make it even more work to eventually do the right thing the right way: expand and use the AI system. They're still trying to dig their way out of a massive pile of technical debt, and throwing a few shovelfuls more on top may not slow them down that much, but it still isn't going to help them get there any faster.
To summarize, [Mojang] Searge (Michael Stoyke) has marked many of these bugs as Won't Fix, and instructed us to do the same, because they don't view them as bugs so much as features they've yet to implement. The part they have implemented works correctly. The other parts they just haven't worked on yet. They could put in ugly temporary code to make it work how people want it to, but it's not a productive use of their time. This will eventually get "fixed", not as a result of deliberately setting out to fix it specifically, but as a byproduct of restructuring the code. They have done a lot of work on entities already in the 1.9 snapshots, moving code up the inheritance chain, like how mobs hold and use items. [Mojang] Nathan Adams has recently tweeted about working on the AI a few times. Maybe they'll get to upgrading the AI system in time for the 1.9 release, if [Mojang] Grum (Erik Broes) stops breaking worlds with every snapshot
.
[Mojang] Searge (Michael Stoyke) in MC-60182
Don't do that or assign more memory to your server instance.
[Mod] Neko as mentioned in the ticket, that comment from [Mojang] Searge (Michael Stoyke) is about sign RENDERING, which is what my original ticket was closed as duplicate of.
Fully understand that rendering limited by resource pack is "Working as designed". But its also affecting sign creation in a way that even a vanilla client with vanilla resource pack can't write a player's name on the sign when it should be able to.
Client should let you write the name, and then clients that have a resource pack that can fit all 16 characters can see it, and those that can't, can't.
The limit being enforced both directions makes it difficult to create signs.
Forcing a user to use a custom resource pack just to create a sign is silly.
probobly fixed for next snapshot as [Mojang] Searge (Michael Stoyke) said on MC-65040
Fixed again (for the 3rd time, fixing a 4th bug in addition to the 3 bugs I already found last time), hopefully it's now solved completely.
The behavior has changed. See [Mojang] Searge (Michael Stoyke)'s tweet on the matter. A change in behavior doesn't necessarily make either the old behavior or the new behavior a bug. Whether a particular behavior is or is not a bug is entirely up to the developer, and they are free to change their minds about what the intended behavior is.
ArmorStands can still have potion effects, however potion affects from thrown splash potions or lingering potions are not applied to them (see [Mojang] Searge (Michael Stoyke)'s comment).
The bug
ArmorStands can have potions but they do not affect them and they also show no particles.
How to reproduce
- Place an armor stand
- Throw a splash or lingering potion at the armor stand
- Inspect the NBT data of the armor stand (for example by using the /entitydata command)
You will probably find the ActiveEffects tag
{NoGravity:0b,HurtByTimestamp:0,Attributes:[0:{Base:20.0d,Name:"generic.maxHealth"},1:{Base:0.0d,Name:"generic.knockbackResistance"},2:{Base:0.699999988079071d,Name:"generic.movementSpeed"},3:{Base:0.0d,Name:"generic.armor"}],Invulnerable:0b,ShowArms:0b,PortalCooldown:0,AbsorptionAmount:0.0f,FallDistance:0.0f,DisabledSlots:0,DeathTime:0s,Pose:{Head:[0:3.6275797f,1:7.3224716f,2:0.0f],Body:[0:0.0f,1:-2.029889f,2:0.0f]},Invisible:0b,Motion:[0:0.0d,1:-0.0784000015258789d,2:0.0d],Small:0b,UUIDLeast:-7734517510628796835L,Health:20.0f,Silent:1b,Air:300s,OnGround:1b,Dimension:0,Rotation:[0:0.0f,1:0.0f],HandItems:[0:{},1:{}],UUIDMost:2428460478001139510L,Pos:[0:778.5d,1:56.0d,2:-1941.5d],Fire:-1s,ArmorItems:[0:{},1:{},2:{},3:{}],NoBasePlate:0b,HurtTime:0s,ActiveEffects:[0:{Ambient:0b,ShowParticles:1b,Duration:377,Id:19b,Amplifier:0b}]}
Note: This also causes them to consum lingering potions
[Mojang] Searge (Michael Stoyke) can you take another look at this, a very similar issue with glass just got fixed
(this is a duplicate of MC-61864 which states the following)
[Mojang] Searge (Michael Stoyke) added a comment - 16/Jul/14 11:16 PM
Replacing blocks with tile entities is not supported, this is due to a limitation in the parsing of commands. It may be changed in the future, but not until after 1.8. This issue should be considered a feature request, not a bug.
(no need to comment anymore)
[Mojang] Searge (Michael Stoyke) I think you misunderstood, when turning all those camerules to false, it still outputs server executed command's feedback in the server log, for example /gamemode
As [Mojang] Searge (Michael Stoyke) has stated on several issues,
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Squid and ghasts use the AI system to pick destinations to swim/fly to, thus stopping AI updates stops them from moving. However, because they respond to gravity differently than most mobs, they don't use the AI system for it. Knockback is presumably a similar situation. These may all get "fixed" once they expand the AI system so they can more easily move mob-specific behaviors to it, but for now are considered "Works As Intended".
As [Mojang] Searge (Michael Stoyke) has stated on several issues,
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
looked on the tracker quickly, saw no reports past 15w33a, give an example
my server is not having this issue at all anymore
if you mean "Tried to add entity with pending removal and duplicate UUID" that's MC-88922 and was a debug message for the code that [Mojang] Searge (Michael Stoyke) wrote to fix this
fix version: future version "next update"+ always means the next snapshot
don't beleve me, read [Mojang] Searge (Michael Stoyke)'s comment:
[Mojang] Searge (Michael Stoyke) added a comment - Yesterday 3:02 PM
This was a side effect of another attempted bugfix and is now reverted to the old behavior.
people, this is intended behaviour, see MC-96565
[Mojang] Searge (Michael Stoyke) added a comment - 10/Feb/16 5:09 PM
The NoAI tag just disables the AI for entities. If this also disables gravity for these entities, that's an unintended side effect.
in other words, anything that isn't done by the AI won't be blocked by the NoAI tag, pushing, coliding, taking damage, falling, is all not part of the AI
Please add [Mojang] Searge (Michael Stoyke)'s comment about the fix to the description
user-f2760 That means they won't get the full "inner circle" (triangle) of the first 3 Strongholds, at maximum 2 of them.. plus, of course, the other share of those 125 SH which happen to be within those narrow worldborders (or also not).
[Mojang] Searge (Michael Stoyke) Good that the ender eyes problem is solved }=)
Just wondering why the adjusted version (which contains better distribution of SH) is not possible which contain the old 3 inner circle Stronghold positionings?
double distance = 1.75D * this.const32 + this.const32 * (double)circle * 6.0D + (rand.nextDouble() - 0.5D) * this.const32 * (circle == 0 ? 1.0D : 2.5D);
I don't get why this is not possible, considering the old (in 1.8 generated) Strongholds wouldn't get overwritten when taking this code?
[Mojang] Searge (Michael Stoyke) Thanks for looking into it and fixing the eye of ender issue.
I was hoping the better distribution could be used while keeping the inner circle at the same size as it used to be as the increased distance to the first strongholds feels quite far to me as a survival player.
Thanks anyway ![]()
sorry, [Mojang] Searge (Michael Stoyke), still not fixed for me
[Mojang] Searge (Michael Stoyke) in MC-63391:
Only living entities can be on a team, items are not living entities, only mobs, animals, villagers and players are.
that's a no[Mojang] Searge (Michael Stoyke) added a comment - 11/Aug/15 10:39 AM
JSON parsing will be strict everywhere in the game, I recommend not using lenient syntax anywhere anymore.
Pilvinen this issue was resolved as intended by [Mojang] Searge (Michael Stoyke)
duplicate of MC-96565
[Mojang] Searge (Michael Stoyke) added a comment - 10/Feb/16 5:09 PM
The NoAI tag just disables the AI for entities. If this also disables gravity for these entities, that's an unintended side effect.
[Mojang] Searge (Michael Stoyke):
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
[Mojang] Searge (Michael Stoyke)
Our launcher downloaded the incorrect 1.9 version of the game in the past 10-15 minutes. It is now fixed, please restart your launcher.
[Mojang] Searge (Michael Stoyke) is this WAI?
[Mojang] Searge (Michael Stoyke) added a comment - 11/Jul/14 5:09 PM
If certain characters do not work, don't use them in your objective name.
same goes for teams
No, UUID's aren't be used internally by scoreboards, see MC-50247
[Mojang] Searge (Michael Stoyke):
We decided against using UUIDs for players on scoreboards. Scoreboards are not meant to be long term storage of persistent data and having players lose their scoreboard progress after a name change should not have too much impact.
Read 1 comment before yours, [Mojang] Searge (Michael Stoyke) resolved this as intended, if mojang says it's intended, it's intended.
It may, or may not be, mojang may fix that issue by printing it cursive everywhere instead, and then this can be considered inconsistant.
If mojang didn't want it to be cursive, then [Mojang] Grum (Erik Broes) would've marked this as intended instantly, instead of just assigning it to [Mojang] Searge (Michael Stoyke).
Becasue [Mojang] Searge (Michael Stoyke) said so:
[Mojang] Searge (Michael Stoyke) made changes - 29/Jul/14 3:43 PM
Status Open [ 1 ] Resolved [ 5 ] Assignee [Mojang] Searge (Michael Stoyke) [ searge ] Resolution Works As Intended [ 6 ]
Well, the implementation changed some time ago, so that might be why you expect different results, see [Mojang] Searge (Michael Stoyke)'s comment.
[Mojang] Searge (Michael Stoyke) made the call to say All other selectors work as intended so, that means it's intended you can't test for them.
Sorry, but [Mojang] Searge (Michael Stoyke) resolved it as such, so this is intended.
And [Mojang] Grum (Erik Broes) resolved MC-91224 the same way.
Because [Mojang] Searge (Michael Stoyke) said so.
From [Mojang] Searge (Michael Stoyke):
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
[Mojang] Searge (Michael Stoyke) I would recommend naming this command /tpfixed instead of /teleport, since tp can be interpreted as short form for teleport.
This ticket is for crashes on vanilla clients and servers only.
As a workaround, you can play on 1.10 for now: Start the launcher, select Edit Profile. In the Use Version dropdown menu, select release 1.10. Then click Save Profile.
Description: Server forgot to send required information to construct BlockEntity java.lang.RuntimeException: Missing BlockEntity at bqy.b(SourceFile:162) at bqu.a(SourceFile:100) at bqu.run(SourceFile:43) at java.lang.Thread.run(Thread.java:745)
http://hopper.minecraft.net/crashes/minecraft/MCX-2840146/
Ways to reproduce:
Confirmed: Piston extensions, for example placed on their own for decoration using /setblock ~ ~ ~ piston_extension
Confirmed: Flower pots placed in worlds created in 1.6.4 or older, even if the world has been opened in versions > 1.6.4 (MC-103992)
Unconfirmed: Command blocks, world download sent to [Mojang] Searge (Michael Stoyke) according to MC-104216
As [Mojang] Searge (Michael Stoyke) has made clear elsewhere, the NoAI tag can have unexpected results because of how some behavior and mechanics are implemented. The Ender Dragon is a complicated mob, especially after the fight was reworked in 1.9, and was not designed to work outside of that context. Too much of its behavior is dependent on multiple pieces working together, and when you fiddle with its internals, they no longer function predictably.
See this comment by [Mojang] Searge (Michael Stoyke):
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs
Might be wai,
leaving open for dev to decide about this.[Mojang] Searge (Michael Stoyke) added a comment - 05/Feb/14 10:53 PM
The @a selector (but only without a radius/area defined via r/rx/ry/rz) will include dead players in the next snapshot. All other selectors work as intended.
The bug
If you add a dropped item (or any Non-LivingBase entities) to a team, it follows the color team rule fine. The problem is, you can't target it with team=
Note
[Mojang] Searge (Michael Stoyke) added a comment - 10/Aug/14 12:17 AM
Only living entities can be on a team, items are not living entities, only mobs, animals, villagers and players are.
This is not correct, as it has the color, it is on the team, so it can be added fine. The only problem is that it can't be targeted via team=
How to reproduce
- /team add Test
- /team modify Test color red
- drop an item and run
/data merge entity @e[type=item,sort=nearest,limit=1] {CustomName:"{\"text\":\"Test\"}",CustomNameVisible:1b} - /team join Test @e[type=item,sort=nearest,limit=1]
- see the red name, indicating it's on the team
- /say @e[type=item,team=Test]
→
The command will not say "Test"
Code analysis
Based on 1.11.2 decompiled using MCP 9.35 rc1
The method net.minecraft.command.EntitySelector.getTeamPredicates(...).new Predicate() {...}.apply(Entity) returns false if the entity is not an instance of EntityLivingBase even though the method net.minecraft.entity.Entity.getTeam() is correctly implemented for all entities.
Let's quote [Mojang] Searge (Michael Stoyke):
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
(Also, this is not a discussion forum)
Yes, I'm refering to [Mojang] Searge (Michael Stoyke)'s comment; and we've been instructed to resolve any tickets regarding editing nbt tags during an entity's lifetime. (Not sure why they fixed slimes then.)
[Mojang] Searge (Michael Stoyke): Now that tipped arrows are a thing, should wither skeletons now be shooting wither arrows instead of fire arrows?
[Mojang] Searge (Michael Stoyke) added a comment - 16/Jul/14 11:16 PM
Replacing blocks with tile entities is not supported, this is due to a limitation in the parsing of commands. It may be changed in the future, but not until after 1.8. This issue should be considered a feature request, not a bug.
[~rajeshgot@yahoo.com], this is not the right place to report bugs (like, at all); but the behaviour you're describing is intended as stated by [Mojang] Searge (Michael Stoyke) in MC-91436.
The bug
@p and @r can target dead players when they previously could not. As well, the distance/dx/dy/dz parameters should also prevent the @a selector from targeting dead players, but do not. Via MC-46223:
[Mojang] Searge (Michael Stoyke) added a comment - 05/Feb/14 10:53 PM
The @a selector (but only without a radius/area defined via r/rx/ry/rz) will include dead players in the next snapshot. All other selectors work as intended.
How to reproduce
Place the following commands inside a repeating command block chain. They will state your name while alive and when dead, except for @e which correctly excludes dead players:
say P: @p say R: @r say A: @a[distance=..20] say E: @e[type=minecraft:player]
Erratic and Strange Mob Behavior in Overworld isn't a bug?
It's not erratic and strange, it's the exact behaviour that it's supposed to have. MC-85304 was marked as fixed by [Mojang] Searge (Michael Stoyke), not a moderator. It's supposed to be like that. You can't use it for mapmaking yes, but that isn't the intention of the ender dragon.
I have personally seen it work normally in earlier versions of the game
That must have been before the ender dragon behaviour has been revamped.
Discussions like these really aren't the purpose of this site; we don't consider this behaviour as being a bug, and unless a Mojang employee specifically says otherwise, it stays like that.
I'm sorry if I sound rude, I'm not a native English speaker.
Read [Mojang] Searge (Michael Stoyke)'s comment on MC-129623.
Also still experiencing this on pre7, if anything the problem is worse. Converting a 1.12 world, conversion time took several minutes, took about 5 minutes before the game managed to drop down from 2000-3000ms to 15-20ms tps. After waiting for that to calm down, I still can't Elytra fly across our spawn area without freezes, fps drops, chunks not loading towards the edge, and eventually a crash. This has crippled performance of our server world to the point that it's unplayable now. [Mojang] Searge (Michael Stoyke) Matthew
Kumasasa [Mod] md_5 [Mojang] Searge (Michael Stoyke) This issue has not been resolved at all. Why is it marked as resolved? My world is still unplayable. I have it uploaded to a Google Drive folder – if you send me an email to share it with, I can add you as a collaborator to download the world.
Again, this issue is not resolved, please do not mark it as such. This is still a game breaking update for server owners and single player owners alike.
If this is only observed using NBT-modifying commands, the precedent is "Won't Fix/Working as Intended" as per [Mojang] Searge (Michael Stoyke)'s comment here: https://bugs.mojang.com/browse/MC-66943?focusedCommentId=188032#comment-188032
Hi @[Mojang] Searge (Michael Stoyke),
It's a fresh new world, so it's not big (18MB), but max. 10MB is attachable here.
So here you can download:
https://www.dropbox.com/s/thpbgc6dcts5gc6/Test_Experimental.zip?dl=0
I hope it works, because I already deleted it before. Just I restored from Recycle bin. ![]()
@[Helper] Johnibur: I have a simple business laptop
Dell Latitude E5470
Processor: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (4 CPUs), ~2.5GHz
Memory: 8192MB RAM
Video: Intel(R) HD Graphics 520
It's not a gamer machine, I know. ![]()
Thank you for your report!
However, this issue is Invalid.
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs.
– [Mojang] Searge (Michael Stoyke)'s comment here inMC-66943.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs
Changing NBT during the lifetime of an entity is not supported:
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs.
– [Mojang] Searge (Michael Stoyke)'s comment here inMC-66943.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
[Mojang] Searge (Michael Stoyke) marked MC-66068, which this report is resolved as a duplicate of, as Works as Intended. Any new reports would also be resolved as duplicates of MC-66068. The bug tracker is simply not the correct avenue to convince Mojang to change this, and I would recommend pursuing other means of building support for such a change, such as the feedback site or the suggestions subreddit.
Thank you for your report!
However, this issue is Invalid.
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs.
– [Mojang] Searge (Michael Stoyke)'s comment here inMC-66943.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Thank you for your report!
However, this issue is Invalid.
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs.
– [Mojang] Searge (Michael Stoyke)'s comment here inMC-66943.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Duplicate of MC-10818/Won't Fix per [Mojang] Searge (Michael Stoyke)'s comment on MC-10818.
Both commands given are behaving exactly as expected according to this comment by [Mojang] Searge (Michael Stoyke).
In the first command, the main hand has the "disable remove" flag set. To fix this, DisabledSlots should be set to 65566 instead (or just 30 since placing is always disabled for the main hand anyway).
In the second command, the main hand's "disable remove" flag is not set, which is why you were able to take the item. There's no such thing as a "replace" flag (see linked comment).
Both these commands are behaving exactly as expected according to this comment by [Mojang] Searge (Michael Stoyke). This is an issue with the website shown in the screenshots, not the game.
In the first command, the main hand has the "disable remove" flag set, which explains why you can't remove the iron sword. To fix the command, use a DisabledSlots value of 65566 (or just 30 since placing is always disabled for the main hand anyway).
In the second command, the main hand still has the "disable remove" flag set. There's no such thing as a "replace" flag.
Thank you for your report!
However, this issue is Invalid.
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs.
– [Mojang] Searge (Michael Stoyke)'s comment here inMC-66943.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Using a radius of 65536 was an unintended side effect. We are not changing it back to the broken behavior. Instead I made a proper fix for the next version that will allow r=0 and/or rm=0 to be used to specify exact block positions. It will also center the radius around the blocks center position and not around on of its corners as it was before.
Please provide steps to reproduce.
My bugfix may also fix some other issues with scoreboard objectives that are based on stats.
The @a selector (but only without a radius/area defined via r/rx/ry/rz) will include dead players in the next snapshot. All other selectors work as intended.
The tag only prevents items from being picked up by players walking over the item on the ground.
You need to get the commands right:
/summon Item ~3 ~ ~ {Item:{id:"minecraft:stone",Count:1},PickupDelay:32767}But even then it's not working correct in the current snapshot, so I took care of it. The problem will be fixed in the next version.
The /testfor command still sometimes fails with spaces in NBT tags.
It should be sidebar.team.yellow
it's dx, dy and dz and you can not use negative values for them
You can't use selectors like @p in the components like you showed it in the example. Try to use * instead, that's how I implemented it and it should work.
To replace only air blocks, use the "keep" mode instead of "replace minecraft:air". Air is a special blocktype and can't be used as replace filter in this case.
Keep the discussion on topic and civilized in the future please, this is a place to report and fix bugs, not about complaining why something is still broken after being reported long time ago. If a ticket is annoying to look at, it's less likely to be fixed quickly.
The value to hide the additional infos from the tooltip is 32 (bit 5)
Works as intended.
Use "/scoreboard players reset * score" instead of "/scoreboard players set * score 0" to remove scores from the players.
While I agree that we could make it look less horrible by showing a proper error message instead of the exception, this is only a warning that files did not exist and empty ones are created.
We decided against using UUIDs for players on scoreboards. Scoreboards are not meant to be long term storage of persistent data and having players lose their scoreboard progress after a name change should not have too much impact.
I decided not to change the behavior of the existing stat, the scoreboard operation command can be used to calculate the difference between walked distance and crouched/sprinted distance.
This is not the place for feature requests or discussions. I recommend to post about it on the minecraftsuggestions subreddit, that's the best place to discuss this topic.
There are still some issues with cloning "active" redstone contraptions. I recommend not to use clone for anything while it's changing state (redstone turning on/off, pistons extending, furnaces cooking, etc.)
I've reopened this issue for now, but can't tell right now if we will be able to fix this or have to mark it "works as intended" later.
If you have a directory "playerdata" in your world directory and there are files named like 3bce967243f03d12a71c7fcdc529a9b1.dat, you can rename them with some dashes, in my example the correct name would be 3bce9672-43f0-3d12-a71c-7fcdc529a9b1.dat.
So the lengths of the groups of numbers and characters in the filename are: 8-4-4-4-12
We need more information about this and the server log file. It's not possible to use the user id to log in.
The only purpose of the Lock tag on blocks with an inventory is to prevent player interaction with them.
Some particle effects check if they are spawned in a valid area, bubbles are one of the types that's affected by this behavior.
There is a difference between a score of 0 and no score at all for a player or entity.
Did you have any player skulls in the area with the corrupted chunk?
This is only the case in offline mode servers. We do not support whitelist and banlist in offline mode, because they are pretty much useless without online mode.
This is only the case in offline mode and we don't support whitelists and banlists in offline mode, because they are useless without verified logins.
The world border is a dangerous place, don't get too close or expect to get hurt.
Since the farlands were removed many versions ago there is no real reason anymore to go so far away from spawn. As soon as a player manages to get there without using teleports or other cheat, we can reopen this ticket.
For now I'm not going to change this behavior because it would cause a performance hit for ALL fill operations. For this special case I recommend a workaround by filling with another block (like stone) first and then with lava.
I'll take a look at it next week.
No, I explicitly said before that only @a will work for dead players. Please read all comments before requesting that a ticket should be reopened.
the reset subcommand removes a score from a player completely. this is not the same as setting it to 0 using the scoreboard player set command.
This is not a discussion platform, it's a bugtracker. Please use it accordingly.
I'll make an exception this ONE time and answer your question here: The problem is not that the buckets disappear, the problem is that you can put more than one in the fuel slot in the first place. This will be solved differently, but the behavior that you describe is WAI.
if (operation.equals("=")) score1.setScore(score2.getScore());
if (operation.equals("<")) score1.setScore(Math.min(score1.getScore(), score2.getScore()));
if (operation.equals(">")) score1.setScore(Math.max(score1.getScore(), score2.getScore()));
Some block types are only used internally and won't have an item anymore.
Please upload a world that still has this problem, I have fixed it in 14w25b, so it should not happen anymore, but I can always use more test cases.
Use gamerule sendCommandFeedback to toggle this behavior
Use gamerule sendCommandFeedback to toggle this behavior
Example 1 does not work, because you need to set the author and title tags of a book, otherwise it's considered invalid and won't render text.
Try:
/give @p written_book 1 0 {pages:["{score:{name:player,objective:test}}"],author:Searge,title:Test}
Same is true in Example 2.
Try:
/give @p written_book 1 0 {pages:["{score:{name:player,objective:test2}}"],title:Test,author:Searge}
The fact that clients show scores from the client when the objective does not exist on the server is a bug and will be fixed eventually, but as it works with properly defined books, it's not a high priority to fix it.
Entity selectors can't contain spaces. We are considering to improve command parsing in the (far) future, until then, this won't work.
Please provide steps to reproduce, otherwise there is no way I can test if it's still broken or not. It's "works on my machine" approved right now.
The fix for this problem should fix most of the sound volume related bugs.
^ that
We explicitly stated that every world that was ever opened in 14w26a or 14w26b will be corrupted and you need to use a backup.
It's currently not planned to apply the team options to any entities in a team.
This is not a discussion board or user helpdesk!
Don't do that or assign more memory to your server instance.
Please do not report problems if you open worlds that were opened in 14w26a or 14w26b
Please do not post comments without actually trying it first. This issue is fixed and does not exist in 28a
I have to apologize, you guys are right. It's fixed in the next version. I was convinced that the delay cycle on repeaters was the other way around.
Please do not use the bugtracker as discussion board! This is a bug in 28a and will be fixed in the next version, as I said.
The format of this particle effect changed recently. It is an internal effect, so the fix is that this particle effect is no longer listed as supported in the /particle command. It can still be used, but needs to be changed to the new format.
Instead of _1_0 which was block id and metadata before, it now only takes one parameter. the new value in this case is _1 and this is calculated like this:
newId = blockId | (metaData << 12)
Right now only commands support the named ids. NBT tags are updated later and still use numerical ids.
Can't reproduce, please attach the world save and provide instructions of the exact steps to reproduce.
use name=... instead of Name=...
I tried the same seed and same position, world generates fine
Without the world save, this can't be reproduced
Works for me, I used /clone ~ ~ ~2 ~ ~1 ~2 ~ ~ ~4 replace move
That's due to how redstone works internally. there is no way to fix this right now, so I recommend not cloning anything with active redstone signals.
That's been the behavior of portal since they were introduced. If you destroy a portal and a new one is created next time you walk through the portal in the overworld, a completely new portal is created.
It would be a bug if the nether portal was still active and a new one would be created.
This is the way it works right now. The fact that it's a not easy does not make it a bug. This a feature request.
The onClick events only work on the root tag on signs, not in the extra tags. This may or may not change in the future, but for now it's WAI.
The wall signs (and some other blocks) only accept valid data values since the blockstate changes were introduced. only data values 2-5 are valid for wall signs.
Example:
/setblock ~ ~1 ~-1 minecraft:wall_sign 2
Closed due to the fact that people kept commenting or updating their comments on the issue after it was resolved. It's really distracting to get several mails per day for no good reason.
Please don't use the comments for off-topic posts. If you want to thank someone, use twitter. I'll be removing comments in the future that are not on-topic. That's not meant to be mean, but this is a bugtracker, not a forum.
Fixed for all but the rails.
I posted all infos that you need to update your commands in my last comment. Stop using the bugtracker as discussion forum, please.
The types blockcrack_ and blockdust_ are working as I explained. After looking into iconcrack_ again, I realized it does indeed still work with 2 parameters: iconcrack_[id]_[data]
It's fixed in the next version, but all 3 of these particle types are subject to change again in the near future when we get rid of numerical ids for them.
The CustomNameVisible tag does not work on animals and mobs, because they have different rules about showing the name. For the other entities it should work.
Regarding CanPickUpLoot - do you have the mob griefing gamerule set to false? In that case, mobs won't pick up loot.
The internal interpretation of the parameters vary for each particle type. It's possible to specify 0.5 or 0.25 instead of 1 to have the effect cover a smaller area in this case.
Fire is a special block type, like water and lava and maybe some that I forgot to mention. They can't be broken by tools with this tag, because that would require special casing the behavior of these blocks.
Works for me
The operations < and > are actually not "less than" or "greater than", they are min and max and work as follows:
if (operation.equals("<"))
score1.setScore(Math.min(score1.getScore(), score2.getScore()));
if (operation.equals(">"))
score1.setScore(Math.max(score1.getScore(), score2.getScore()));
The /execute command is not meant to be used to redirect messages of query-commands like "seed", "scoreboard * list", etc.
Changing this would redirect the output of ANY command that is issued via /execute to the affected players without any good way of suppressing those messages.
The stats in the game are only working for players, not for other entities. Changing this would cause a huge performance hit.
If certain characters do not work, don't use them in your objective name.
If certain characters do not work, don't use them in your objective name.
The /playsound command uses the command block it is executed in as reference for relative coordinates. To play sounds relative to players, use the /execute command.
Example:
/execute @p ~ ~ ~ playsound fireworks.blast @p ~ ~ ~ 1 1.4 1
Custom names for items is fixed in the next version
You can only teleport to other players
Replacing blocks with tile entities is not supported, this is due to a limitation in the parsing of commands. It may be changed in the future, but not until after 1.8. This issue should be considered a feature request, not a bug.
Running commands in command blocks should not spam players with messages. A tellraw command and the scoreboard can be used to get the described behavior.
Please don't use the bug tracker as a discussion board.
Please use the search function before posting issues.
Works for me, this was fixed some snapshots ago.
The entity selector in the particle command will be removed in future versions.
There is no entity type "Monster". Please do not report problems as bugs if they are caused by using invalid data in NBT
Leaving a world, then immediately deleting it and creating a new one with the same name can, in some cases, cause issues with chunk generation.
Paintings can only be placed where they do not intersect world geometry.
"Mob" and "Monster" are invalid entities to spawn and will be removed from /summon in the next update.
This was already fixed in the most recent snapshots
It can still happen in creative mode, because the creative inventory is handled differently than the survival inventory, but it's fixed for survival and adventure mode.
If it happens in creative mode, the slot will be updated the next time a player tries to put a valid item in the slot. Leaving/re-entering the world also fixes it in this creative mode.
This was already fixed in the most recent snapshots
This should already be fixed in the most recent snapshots
This should already be fixed in the most recent snapshots
This should already be fixed in the most recent snapshots
This should already be fixed in the most recent snapshots
I can't reproduce this in 14w31a, within the witch hut area only witches spawn. It's of course still possible to have other mobs spawn next to the area and then walk into the witch hut area.
To make then unbreakable, use the "Invulnerable" NBT tag.
The setblock and fill commands are working outside of the world border in recent snapshots, other block entities than command blocks will not work outside of the world border for performance reasons.
The item frames are causing this effect, not the armor stands, it's fixed in the next update
Only living entities can be on a team, items are not living entities, only mobs, animals, villagers and players are.
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
Piston extension is an internal technical block and it's not supposed to be used in maps.
Falling sand entities do not have any AI
The syntax for /particle changed, use /execute to spawn particles at an entity position
Armor stands are not affected by potions
Problems caused by changing internal NBT tags during the lifetime of an entity are not considered bugs, they'll always be marked "working as intended".
The NoAI tag does not affect the fact that mobs despawn if no players are nearby.
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs, they will be marked as "working as intended"
This is a bug tracker, not a wishlist.
Problems related to modifying internal NBT tags during the lifetime of an entity are not considered bugs, they will be marked as "working as intended",
In that case it would be easier for us to remove that command again. This is a bug tracker, not a discussion forum.
It's more flexible this way and you can always test if at least one player/entity exists that matches the criteria and not run the command if none are found.
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag. In this case the Invulnerable tag can solve the problem.
A Minecraft world is at most 256 blocks high.
If that's the case, where is the world download and detailed repro instructions?
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
You need to escape quotes within quotes
Please do not report issues related to NBT tags as bugs. If changing NBT via commands does not have the expected effect, that's always considered "working as intended".
On signs, click events can't be in the extra section, they have to be on the highest level.
Rendering transparent items on entities is not supported right now.
Any part of an entities behavior that is not implemented as part of the AI is not affected by the NoAI tag.
This is a bug tracker, not a discussion board. Unless I get a map to reproduce this issue, this won't be reopened.
The bugtracker is not for feature requests
Strings need to be in quotes
Please provide screenshots that describe the issue.
We can't reproduce this issue with the steps you described. Please provide a world download that reproduces this issue.
I don't understand the issue you describe, could you explain it in more detail, ideally providing an example or screenshot.
Please provide a world download that reproduces this issue.
Using /tp commands with high frequency can cause visual glitches on the client. This can't be easily solved at the moment.
Please don't use the bugtracker for feature requests.
Using wither skulls directly is not supported and modifying internal data via NBT during the lifetime of an entity can result in unexpected behavior.
If this still happens in snapshots/versions after 14w34 please reopen this. It should be fixed, but we'd like to have more feedback on this.
Please provide a world download that reproduces this issue.
We can't reproduce this issue with the steps you described. Please provide a world download that reproduces this issue.
We can't reproduce this issue with the steps you described. Please provide a world download that reproduces this issue.
Rendering transparent items for entities is not fully supported right now.
Please provide a world download or a detailed list of commands that reproduce this issue.
The only difference between normal and small armor stands is how they render.
We can't reproduce this issue with the steps you described. Please provide a world download that reproduces this issue.
Like item frames and paintings, armor stands are entities. Ctrl-picking of entities is currently not supported.
Invisible armor stand can't be destroyed by hitting them.
The DisabledSlots tag can be used to modify this behavior
This can't be easily changed without changing how fences work
I'll have to test if this behaves differently from using /fill to replace a single block, in that case it might be a bug that needs fixing
This is how it's supposed to work. If you use a selector to specify a player for the result of a stat command, you have to use a selector that resolves to 1 result (Example: @a[c=1] instead of @a would work). The way to solve what you are trying to do here is to use /stat entity on players, then run the command in their context via a /execute command.
I'm not sure, tbh. But /setblock and /fill should have the same behavior, so I'll compare them and then decide if this needs to be fixed.
The command is meant to be used for achievements. It's only working on other stats because we forgot to restrict it. Easy way to fix it would be to restrict it to achievements, I'd rather keep it as-is, but won't change the behavior when it's used on stats. (at least not right now, maybe later)
The recipe changed recently
Can you attach a world download to reproduce this?
Could you attach a world download to reproduce this issue?
Could you attach a world save to this ticket so we can reproduce the issue?
The order of redstone updates with redstone dust is not deterministic. If you need command blocks to execute in a defined order, there are other ways to make sure that's the case. Google, Reddit and Youtube will be able to help you.
Unfortunately I could not reproduce this issue. This world runs perfectly fine on my testserver.
Please attach a world download that reproduces this behavior
It's possible to get that behavior by using /execute
Command syntax is sensitive to spaces
Slimes can have one of three sizes, everything else is not supported.
We can't fix that right now, the attempt to fix it made armor stands fall through halfslabs in some cases, so a proper fix will come when we rework collision handling on the client.
Mobs don't serialize their orientation
This has been changed some time ago. It is now:
return state.getBlock().getExplosionResistance(this);
Maybe you should use the time it took you to write that rant and look at the code instead.
Text lines on signs are parsing JSON in 1.8, so to get the brackets in this case, the syntax is:
/setblock ~ ~1 ~ standing_sign 8 replace {Text1:"{text:\"[+train]\"}",Text2:"eject",Text3:"0/1/0",Text4:"90/0"}The old behavior (before 1.8) was bugged, due to a general bug fix for bounding boxes the witch hut now works as intended.
To make it a bit easier to build a witch farm, I raised the height of the witch spawn volume by two blocks, so it's now Y 64 to 71.
So you are hanging a chicken and wondering why it stopped moving after some time? Don't be so cruel.
To solve this, we'll have a separate game rule "doEntityDrops" that works similar to "doTileDrops" but applies to entities instead of blocks.
Commands for execute are not auto-completed in general. We might change it eventually, but not right now.
Selectors only work if they resolve to a single entity. That's by design and won't be changed. The solution is almost always using /stats on entities.
This will be updated once I find time to fix the behavior to be consistent for all types of blocks. Right now block entity blocks can't be replaced, while all other blocks can.
Please try to reproduce this when the first pre-release for the 1.8.1 update is available. I might have fixed it, but some more feedback can help to make sure the fix works. Keeping this open until I know it's solved.
This issue is fixed for entities saved in 1.8.1 or newer. Loading older worlds can still have some entities with this issue in the world. Simply closing the world and loading it again should automatically solve the issue for those entities.
Mobs never spawn too close to the player.
The issue will be resolved in the final 1.8.1 release. Please do not reopen it based on feedback on pre-releases, the assets will be updated with the final release of 1.8.1.
EDIT: I want to point out it was broken in pre5, but the final 1.8.1 release will contain a proper fix for it
Setting the marker tag is intended to make them a position marker for a single point in space, the name is positioned relative to this position. The intended use of Armor Stands with Marker:true is to also make them invisible.
Use
/execute @e[name=StandTeleported] ~ ~ ~ spreadplayers ~.5 ~.5 0 1 false @e[name=StandTeleported,c=1]
instead to work around the rounding bias
Using an offset of 0.5 in the spreadplayers coordinates will center it correctly around the block position that the execute command provides to spreadplayers in this case
The new stats are only updated on servers running the new server version. Older server versions will not count these stats, so they will remain 0.
This has been fixed for 1.8.2-pre4, please only re-open this if you can reproduce it in the latest pre-release.
I explicitly designed placing armor stands this way
It's fixed for pressure plates and signs, but I explicitly designed it not to work for cobwebs and open fence gates
The fix makes it possible to test for thrown eggs by using @e[type=ThrownEgg] as selector.
Dead entities are not selectable in general. They should be considered as being removed from the world the moment they die.
Don't use effects together that contradict each other. We'll eventually have a better system for this in the game, until then this will not work properly.
Don't go to to infinity, unless you are Buzz Lightyear, in that case you can go beyond.
Ok, I'm a bit confused by your description. Does "Water level was set to '1'." actually mean you made a customized world and set the sea level to 1? In that case this is working as intended, that's the purpose of the sea level option.
Does deleting the usercache.json file in the server directory solve the problem?
Use NBT in the summon command to provide some air to the mob. e.g. /summon Pig ~3 ~ ~
{Air:300s}Only one team can be specified in an entity selector
While being moved by pistons, blocks do not emit light.
The /stats command works exactly as designed, it won't set scores that are not already set to a value. Set the score to 0 before you use the /stats command and the "problem" is solved.
Unfortunately this feature had to be removed in 1.8.6 for security reasons. It wasn't an easy decision, but there was no other viable option. We usually don't break compatibility and this will be an exception to the rule, hopefully the only one.
The Marker tag is not supposed to make armor stands invisible, the Invisible tag has to be set as well to achieve that. Equipment on armor stands should always render.
We unified the orientation of many items in the inventory