intsuc

Fixed in 25w09a. This is because FloatTag and DoubleTag internally be rewritten using Java's record from this version, and comparison method has changed.

Fixed in 25w09a. With support for heterogeneous list tags, this error no longer occurs.

Fixed in 23w46a. Now the following error message is shown in step 4 and the readonly score is not mutated.

An unexpected error occurred trying to execute that command: Cannot modify read-only score

Fixed in 23w45a. Unhandled {{CommandRuntimeException}}s are now gone.

If MC-265805 is fixed but MC-265772 is not, MC-265772 and integer overflow could be exploited to execute a tail-recursive function indefinitely. As of 23w41a, it is not possible to reproduce this due to out of memory. See MC-265805 for more information.

I have created functions that actually recurse infinitely in 23w44a using MC-265772: 23w44a_infinite_recursion

Yes, indeed, this is just making it non-trailing by guarding the trailing spaces with a \. It doesn't seem right that trailing trim and greedy strings coexist, but when such a purely syntactic workaround emerges, this issue might be considered as a feature request, like MC-264999. I'd like to leave the decision to the moderators and developers.

Fixed in 23w31a. I have just noticed that we can include trailing spaces in a function by writing spaces followed by \ and leaving the next line empty as follows:

advancement grant @s only mc-174587:test criterion with a trailing space \

execute if entity @s[advancements={mc-174587:test=true}] run say granted
execute if entity @s[advancements={mc-174587:test=false}] run say revoked

→ ✔ granted

@unknown

Since /spectate accepts only a single player, I believe the current notation is correct.

Yes, it should fail and keep the storage unmodified because it creates an NBT that exceeds the NBT depth limit.

Partially fixed in 23w31a, thanks to macros. We can now generate commands that start and/or end with spaces as follows:

1. Load the following macro

mc-174587:macro

$advancement grant @s only mc-174587:test $(criterion)
execute if entity @s[advancements={mc-174587:test=true}] run say granted
execute if entity @s[advancements={mc-174587:test=false}] run say revoked

1. Run the following command

   function mc-174587:macro {criterion: "criterion with a trailing space "}

   → ✔ granted

Considering the overhead of macros, I would also like this to be achievable with just a function though.

Just for reference, an impractical workaround is to use /reload to block the server and force it to process the pending tasks.

When you run the following function:

say a
reload
say b

You will likely get the following output:

[Player] a
Executed 3 command(s) from function 'foo:bar'
[Player] b

As a personal opinion, this behavior makes me hesitant to get the return value by /return <value>, which was added in 23w16a, using /execute store result ... run function ....

Tags are merged with the file of the same resource location from the previously loaded datapack by default, so you need to set replace to true to remove thorns.
Anyway, I have created a new report MC-260579.

avoids_guardian_thorns.json

{
  "replace": true,
  "values": [
    "minecraft:magic",
    "#minecraft:is_explosion"
  ]
}

If you overwrite tags/damage_type/avoids_guardian_thorns and remove thorns from its values, this issue still reproduces in 1.19.4 Pre-release 1.

Fixed in 1.19.3 Pre-Release 3. The expected behavior is now observed.

There is a data structure/algorithm called list-mapped trie, which is briefly explained in my blog post. A list-mapped trie can be efficiently indexed by an integer (score or NBT) in O(log²N) time, where N is the max size of the structure. If this ticket is not fixed, the time complexity will drop to O(NlogN), which is impractical for large N.

Based on that data structure, there is a library datapack called OhMyDat, which provides per-entity storage and garbage collector. This library uses a large list mapped-trie with size 4⁸ (arity=4, depth=8), and there will be a tangible performance impact.

As far as I know, two major skyblocks in Japan, The Unusual SkyBlock and The Sky Blessing, both depend on that library. These maps will also be affected by this performance degradation. (Although not directly related to this ticket, this library does not work correctly with 1.19.3 pre-3 due to the size limitation.)

I can provide these benchmark results if needed.

Just for reference, here are the microbenchmark results for /data get storage ..., illustrating an example of how much feedback message creation is involved in command performance:

{0: 0b, 1: 0s, 2: 0, 3: 0L, 4: 0.0f, 5: 0.0d}

Benchmark               Mode  Cnt    Score    Error  Units
data get storage 0 0    avgt   25  181.837 ±  3.506  ns/op
data get storage 0 1    avgt   25  183.749 ±  1.202  ns/op
data get storage 0 2    avgt   25  120.708 ±  1.563  ns/op
data get storage 0 3    avgt   25  181.646 ±  1.464  ns/op
data get storage 0 4    avgt   25  188.979 ±  2.598  ns/op
data get storage 0 5    avgt   25  189.029 ±  2.258  ns/op

/data get storage 0 2 (which returns an IntTag) turns out to be faster than the others because IntTags do not require a numeric suffix and can reduce the cost of appending it when creating a feedback message.

{0: 0b, 1: 0s, 2: 0, 3: 0L, 4: 0.0f, 5: 0.0d}

Benchmark               Mode  Cnt    Score    Error  Units
data get storage 0 0 1  avgt   25  846.095 ± 14.720  ns/op
data get storage 0 1 1  avgt   25  847.678 ± 16.129  ns/op
data get storage 0 2 1  avgt   25  864.702 ± 14.426  ns/op
data get storage 0 3 1  avgt   25  847.377 ± 13.149  ns/op
data get storage 0 4 1  avgt   25  811.640 ±  8.092  ns/op
data get storage 0 5 1  avgt   25  832.317 ± 29.123  ns/op

Adding a <scale> argument makes the situation even worse. The primary cause of the slowdown is String.format(Locale.ROOT, "%.2f", scale), which is used for pretty-printing the scale.

In the case of remove, the parent tags are not created. However, it has a bad effect on performance of /data remove, especially when a long NBT path is used and no parent tags are found in the middle of the process.

For the same reason, [{}][] should also report a syntax error.
MC-208974 can be statically prevented if both {}[] and [{}][] become invalid syntax.

Fixed in 21w16a. Markers' data tags are now copied on serialization.