mojira.dev

Frank Steffahn

Assigned

No issues.

Reported

MC-87611 Chains of Conditional Command Blocks don't work properly Fixed MC-87524 Repeating Conditional Command Blocks have very strange chaining properties. Fixed MC-55660 Falling Sand with Time!=0 removes matching blocks on the client side. Incomplete MC-55592 The wildcard * fits into wrong commands without error. Fixed MC-55587 Scoreboard players don't reset properly when objective gets removed. Incomplete MC-55343 Pickblock does not recognize NBT data of items in player's inventory Duplicate MC-55253 The new {selector:"@..."} tellraw feature fails on failing selectors! Fixed MC-49844 The @e selector is buggy in "/scoreboard player" if you specify "type=" and "c=". Incomplete MC-49131 Minecarts riding other Minecarts stack downwards Duplicate MC-48285 "/fill ... replace ..." doesn't parse correctly for blocks that support data tags Duplicate MC-40360 Weird rendering glitch for falling sand containing stained glass Invalid

Comments

@unknown, you can test it now 😉

So, MC-87611 was just flagged fixed. We'll find out if that fixed this issue, too, when the next Snapshot gets released.

Idk, I just made a bug report on my own (MC-87611), no idea whether you meant the same thing or something else which I don't understand from your description..

If I make the chain longer with more conditional chain CBs it behaves oddly... I'll try if I can figure out what exactly happens and maybe create a more detailed bug report.

This is actually fixed in the d snapshot.

What do you mean by "however all repeating command chains execute twice"?

EDIT: I think I got you, I didn't see the screenshots.

EDIT2: ..but what do you mean by "and the impulse chain works correctly in a success condition, but not in a failure condition"

This behavior is somewhat useful as you can use command blocks as block update detectors

BTW: This is actually already a bug in 15w34d. (You would use redstone blocks to power the chain command blocks then, because of the Always Active option missing.)

Yep, it is still in 1.8.3 and the most annoying bug in the world. You are forced to restart the game if you want to use a maximized window after full-screen mode.

Yes, still an issue.

You need random ticks for reactivating redstone torches after burnout, because .. it has always been like this.. well by the way I don't even know any use of this feature (exept a really impractical and buggy random number generator I once built), so it should be OK if they don't reactivate with random ticks after they burned out. This change would also turn some compact piston doors I've seen, which use torch burnout mechanics, 100% reliable and less buggy! So I believe it could be great if simply the redstone components don't receive the random ticks at all.

I'm sorry If you feel bad from my comment, I really just wanted to help you with some tips / suggestion.

This is maybe related but in no part a duplicate. As I'm demonstrating the scoreboard in case 4. is neither fully reset nor 0. If it was reset it would behave like in the cases 1. and 2. for "scoreboard players reset * o", if it was 0 the "/scoreboard test p o * *" command wouldn't fail.

Also, I'd recommend you to write more than just "Intended."
Even the Moderators write something like "Works as intended."
Also, you are not Mojang, so all you could argue would be "Probably works as intended.", or "Works as intended, see ..." with a link to some information from Mojang that proofs their intentions.

As of right now, you are able to teleport to yourself. The menu is currently a WIP.

This is exactly what the bug describes. That the menu is WIP would only explain why the bug exists, not that it would be intended.

As for the second "bug", it appears to be a feature request, [...]

Have you even done what the description tells you? You just get an empty menu with just the option to close it after the teleportation. Seems more like a bug to me that like an intended thing and even if it was intended it seems reasonable to report it as a bug without the need for you to tell the reporter that he's doing things wrong and making feature requests.

How do you know?

Confirmed.

I believe you missed the point of my bug report, the command only fails if there are no pigs in the world, otherwise it tells all the players a list of all the pigs without a problem. But why should the whole command fail rather than just displaying the message with no players?

Just to help you out: the "@e[type=Pig]" selector in my command is not a target but part of the contents of the tellraw command! It needn't be a subset of the target or something like that.

I know that, but why should a pig be a player??

With "more specific" I meant, more specific about what I should do not adding some explanation of things I already know! Your comment sounds like you think there is no bug, so you should be able to explain to me what I do wrong, why it is wrong and how exactly I should archive what I want to do, otherwise think about what you want to tell me before you tell nonsense (because this sounds like it makes no sense, hence my "What??")

What??
Please be more specific!