Quote from TheMinecraftNerd1»
So it seems that mojang tweaked the Chain Command Blocks and how NBT parsing works. Will this affect any or break current maps using NBT or Chain Command Blocks when the update is released?
For the command block change, it should ideally not break much. It reorders how command blocks are scheduled, fixing an issue where a chain shut off via a Chain block will still fire the next tick (more details here). What might break are any in-game attempts to circumvent that issue, though that depends on the method being used I suppose.
As for NBT changes, if you used quotes for all your strings and did not use list indices, you're good to go. There are a number of changes that were made to the parser though (as it was essentially completely rewritten), so I've got a more detailed post here.
0
You could use the "unless" argument and include the value you don't want the target to have:
0
Since the "ench" tag will not exist unless there are actually enchantments, you'll want to use the "unless" argument instead of "if" and detect the existence of that tag:
(using "ench:[{}]" specifically because "ench:[]" would check if the tag exists but has nothing in it, which will not normally be the case)
EDIT: Actually, this might not be what you want. The above only succeeds if the player has no enchanted swords at all in their inventory. If they have 1 unenchanted sword and 1 enchanted sword, the command will fail.
0
You will need to add an area limiter such as "distance", which is the radius with the coordinates at the center. For example, the following targets players between 0 and 1 block of those coordinates (the .. indicates "between these two numbers"):
2
One reason the command behaves that way (apart from player motion being messed up as was mentioned) is because when you test for data within a list (values surrounded by square brackets), each element within the list you specify is checked within every element on the target.
For example, if you checked for "List:[1]" and the target had a list of "List:[3,2,1]", it would match because your specified value of "1" is compared with the target's values of "3", "2", and "1", and it matched the last value. Therefore your test of "Motion:[0.0,0.0,0.0]" is the exact same as testing "Motion:[0.0]".
But for whatever reason, the player's X and Z motion will be 0 even when moving normally, so the check for Motion:[0.0] will always find at least 1 element. Sprint-jumping causes the values to actually update, and no motion values are 0 at that point, so the check fails.
As for the objectives, you'd create them like so (prepended with "minecraft.custom:minecraft."):
1
It simply means unsorted, such that the order will be whatever it is internally.
Internally the sorting is based on load order, such as which chunks are accessed first. Each chunk has its own array of entities. For example, when a chunk is loaded, it loads entities in the order that they were saved to chunk files. You can manipulate the ordering by killing and summoning entities in a specific order in the same chunk.
However, this is not something you'll want to rely on because it could change in the future. The goal of "arbitrary" is to greatly increase performance by not using expensive sorting methods (which was not avoidable pre-1.13, as it would always sort by distance unless @r was used), so that's all you should really be using it for.
0
The NBT structure itself has not changed ("HandItems" is a list of compounds and "id" is a string), but in 1.13 you can use the "nbt" selector parameter to specify NBT for a target:
0
The "alldata" is the namespace, while "custom" is the name of the pack itself. The namespace is what's used when calling the function:
0
Aye, that's what I mean. But what I'm asking is what you're using the resulting signal for, such as if it's to activate other command blocks (and if so, what the commands might do) or to turn on a set of redstone lamps.
Lamps would be trickier, but if you're just looking to run more commands, you'd use "/execute store" to grab the number of entities found and place it into a score. The "/execute if entity" subcommand, when placed last in /execute without using "run", will return the number of targets found. You'd then use the resulting score to activate other commands.
For example, this stores the number of entities in the scoreboard under a fake player called "entity#" in the objective "counters":
And the following will run a /say command if the "if score" condition succeeds (if there are 3+ loaded entities in the world):
0
Are you talking about output to comparators? If so, what exactly were you using that output for? Command blocks now only output a signal of 1 or 0 for the success of a command block, and no longer based on the number of targets. But there are ways to get the number itself into, for example, a scoreboard score. Just depends on what you were using it for.
0
I will break down the commands presented in the thread by OP and myself. This has nothing to do with somebody "coming in" and breaking something. That situation literally cannot happen because I'm talking about one command, not multiple. And even then, unless you're using redstone (which you absolutely should not be doing since 1.9), commands are going to run in the specified order before any player movement is handled. The only way player movement could break that is if you used a command mixed in with your detection commands to teleport players around. But that would be the map-maker purposefully breaking it, which isn't an argument.
OP's:
Mine:
The first command checks if a player with a score exists. Then, a second time, it checks if that same player exists. Then it clears the emeralds.
The second command checks if a player with a score exists. Then it clears the emeralds.
The second command is the equivalent of the first, without the unnecessary fluff from /execute. They are logically the same, but the second one is much more efficient.
To reiterate, look at both of the selectors in the first command. They are exactly the same. It is therefore redundant and, while normally with /execute, you'd use "as [target]" to remove the redundancy and use "@s" for nested selectors (which is highly efficient). But since you don't need /execute for this operation, it can be removed. The reason you don't need it is because the "if score [target] isEmeraldCount matches 15" is literally the same as "scores={isEmeraldCount=15}" and that same exact player was being targeted in the first command anyways.
0
It's likely because you're targeting the wrong entity. You specify "type=!player" in the first selector but don't do that in the second, meaning it's going to target you instead.
And even so, it's irrelevant. I'm specifically talking about the original command in the thread. I'm not about to go through every hypothetical situation when the specific situation in the original topic doesn't need "if score".
0
For the first it's not the case. "/execute as" marks the player as a 'command sender', which is not reliant on the player being an OP. It primarily means that the target is the one to target with "@s" (though there are some other things, such as who is sent command feedback as controlled by "sendCommandFeedback" gamerule). Prior to 1.13, a 'command sender' also included XYZ location for command execution, though in 1.13 that has been split into "at".
For the second, it still doesn't matter. The "if score" being used is equivalent to the "scores" selector parameter. While "if score" in general does have some extra options, the command that was being used did not use them, thus it could simply be removed in favor of the "scores" parameter.
0
For the first, are you sure? I know this was an issue with the old CommandStats system, but this is much different. I cannot test it myself unfortunately. If this is the case, can you provide a link to the bug report?
For the second, the end result is the same. Using "if entity" followed by performing a command on the exact same target is no different than having a redundant /testfor command pre-1.13.
EDIT: I've conferred with the /r/MinecraftCommands discord server who can confirm that both "execute as" and "execute store" do not require the target to be an OP. Make sure you're not having permission clashes from something like Spigot.
0
"b" stands for "byte" rather than boolean, which holds a numerical value between -128 and 127. There is no true boolean datatype for NBT as it just uses byte instead. This is also the case for "true/false", which are transformed into bytes as "1b/0b".
I have a post here explaining the changes made to the NBT parser in 1.11. In particular for strings, any string that contains a value that is not any of the following will require the use of quotes around the value:
Since minecraft:diamond contains a colon, which is not in the list of acceptable characters above, it will require quotes around the whole string.
0
While it will take extra work to modify the items first, you can greatly reduce the complexity of detection by using custom item tags. For example, the following item has lore as well as a custom tag called "blargh" with a value of 1 and datatype of byte:
And to detect it, you simply look for "blargh:1b":
As a quick example using your current command, where each value of "blargh" represents a unique item as a whole:
Such that you'd only have "blargh:3b" on the item "id:"minecraft:leather_leggings",tag:{blargh:3b,display:{Lore:["Effects with full Draconium set:","+Speed II"]}}", which allows you to detect it based on "blargh:3b" alone.