Possseidon

I can't seem to reproduce it in the latest snapshot either. Before that I could barely do anything because it kept happening pretty much everytime I tried to type an entity selector (which, on a QWERTZ keyboard requires altgr and Q, 8, 9). Everytime it would cause altgr to get stuck, and when I tried to move my cursor back into the selector, to specify parameters, it would go to the beginning of it.

But yeah, seems to have fixed itself, if nobody else proves me wrong. I did not really have any hardware upgrades like you did @Azkunki, so I would assume, that that is not what fixed it for you.

Also just went back to 1.14.4 and checked, took a while to reproduce it, but it did get stuck again in the end.

I'm using windows 10 as well, on both main PC and laptop. Just typing commands that often require me to press alt-gr it's like hit or miss every time with about of a 50% chance of it being stuck afterwards...

Wtf, I just made a new world, and I can't seem to reproduce it in that one either anymore... How is it even possible for the world being the cause...

Nvm now it's happening in the new world again...

I have a decent PC and am typing commands in a flat world with constant 600 FPS and it still occurs... I think it's safe to assume, framerate or lagspikes have nothing to do with this...

Please devs! This is incredibly annoying to randomly get way to much in your command removed by backspace or even your whole command by just pressing "A" because that triggered a ctrl-A thanks to the sticking key and then overwrite all the selected text with an A. I really can't comprehend how something like this isn't fixed yet...

Edit: Also, as I'm typing commands, I'm not moving my mouse at all either... Happens on both my main PC and my Laptop, while trying to type [] or {} for entity selectors and nbt on a german QWERTZ keyboard.

This issue seems to be pretty old, but I just stumbled across the weirdness with playsounds volume.

In the new brigadier system there seems to be an easy way to limit any numbers to ranges and they actually did put ranges to the values, but they don't seem all that correct:

• volume: 0 .. (no upper constraint)

• pitch: 0 .. 2

• minvolume: 0 .. 1

Volume should be changed to the same constraints as minvolume and pitch should actually be a value between 0.5 and 2 as far as I remember it.

Still the case in 1.13-pre7

@Boomber got confirmed already for 50a and is (probably) finally fixed for the next snapshot, which has yet to come out

@ChaosNemisis The statement you talked about was only on the example, where only two sub-commands exist. The new title of the report is correct though:

The first sub command only executes, if the second sub command works for all. But you also have to apply that rule to the second sub command (the title doesn't say, that it is specifically the first sub command), so also the second sub command only executes for each (which in turn also cancels the first sub command) if the third sub command works for all.

Basically the workaround is now, that each and every sub command has to be put in a seperate function, if the previous will every run on multiple entities. As I said, not a great workaround as you need a lot of functions in most cases, but it's the only workaround I can think of right now (and probably, but don't take my word on that, the only one that exists).

Even though you got marked as duplicate, your report made me do some more testing and find out something very important, which I added to MC-121934! 🙂

Also next time you report something, put {code} tags around your commands.

@ChaosNemisis LOL, did you even read the bug report? There is a workaround (even though it is somewhat tedious) using a separate function. 😃

seems to be fixed in 17w46a

Motion values are not integers, but doubles.

Because the minecart gets killed before it has the chance to run again. probably.

Confirmed for 17w45b, and also seems to be specific to the advancement command.

Haven't searched very thoroughly (yet), but for other failing commands like setblock, setting the same block or clearing an already cleared inventory, it does not stop the execution of the rest of the function.

As a work around, use multiple /tag commands and then finally spread all entities with this tag.

Your example would look like this:

Pre-Brigadier Snapshots (Before 17w45a):

/scoreboard players tag Dinnerbone add spread_me
/scoreboard players tag Jeb_ add spread_me
/scoreboard players tag @e[type=villager] add spread_me
/spreadplayers <more arguments> @e[tag=spread_me]
/scoreboard players tag @e[tag=spread_me] remove spread_me

Using the new Brigadier Command-System (From 17w45a):

/tag Dinnerbone add spread_me
/tag Jeb_ add spread_me
/tag @e[type=villager] add spread_me
/spreadplayers <more arguments> @e[tag=spread_me]
/tag @e[tag=spread_me] remove spread_me

@Chase Rose

This bug already got reported and your report, being posted way later is therefore marked as duplicate of the other report.

The bug itself is not fixed, but the report is irrelevant and therefore resolved, as it already exists.

Sorry, I only forgot that in the report, thx for pointing it out. The testing was done with at @s. I added it to the report.

Because the last few comments aren't actually related to the bug report completely, I created a new ticket: MC-121934

This ticket can be marked as closed again, as the bug described in this report is fixed and the comments are actually related to the new bug report.

A small followup:

If you create a function test:test with the content:

execute if block ~ ~-1 ~ stone run setblock ~ ~-1 ~ dirt

and run it via

execute as @e[type=armor_stand] at @s run function test:test

it does work, as the the nested execute doesn't get merged with the parent execute and therefore handle the if for each separate function call.

It seems, like the if gets evaluated for all armor stands first, and only if all conditions are met, the run part of the execute gets called (for each armor stand of course).

So I thought, if you put the block-detection into a separate, nested execute it would work, but it gives the exact same result. There might be either some faulty optimization, where the nested execute got optimized into the first execute or it was never supposed to be like this, and the if was meant to be checked for each selector-list item.

Put into commands, what I mean is, that

execute as @e[type=armor_stand] at @s if block ~ ~-1 ~ stone run setblock ~ ~-1 ~ dirt

does the exact same thing as

execute as @e[type=armor_stand] at @s run execute if block ~ ~-1 ~ stone run setblock ~ ~-1 ~ dirt

and they both only run the final command for each entity if the if was true for each entity.

Dinnerbone should take a look at this, as to how he intended this in the first place. At the moment it seems like the system is somewhat flawed in either of those two ways.

This somehow got fixed in 17w45b... I don't know how it happened, but

execute as @e at @s run tp @s ~ ~1 ~

does indeed work now.

Still don't see a reason, why tp ~ ~1 ~ without a selector requires a player, but I can live with having to write @s