Triton365
- Triton365
- triton365
- Europe/Stockholm
- Yes
- No
Important
MCPE-179363
MC-276702
NormalMC-279766
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0#
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 0 0
- Summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Pause the game about 5 seconds.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}→
Two 0-0-0-0-0 entities summoned
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 0 0
- Summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Pause the game
about 5 seconds.- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}→
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 0 0
- Summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Pause the game two times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}→
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 000
Summon entity with UUID 0-0-0-0-0/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Pause the game two times.
Summon another entity with UUID 0-0-0-0-0/summon marker 0 0 0 {UUID:[I;0,0,0,0]}→
Two 0-0-0-0-0 entities summoned
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
- summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game two times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
- summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game two times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
- summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game two times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
summon entity with UUID 0-0-0-0-0/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game
twotimes.- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
- Summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game about three times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
- Summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game about three times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
Two 0-0-0-0-0 entities summoned
- Create a new world.
- Load only chunks around (0,0)
/tp @s 0 ~ 0 /setworldspawn 0 ~ 0
- Summon entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Unload 0-0-0-0-0 entity
/tp 0-0-0-0-0 99999 0 0
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
- Pause the game about three times.
- Summon another entity with UUID 0-0-0-0-0
/summon marker 0 0 0 {UUID:[I;0,0,0,0]}
This bug appears probabilistically. (I don't know the exact cause.)
Put a repeating command block at the border of one chunk, power the command block (with a lever) in the other chunk, save the game and exit. This sometimes saves the unpowered state of the command block.
The same thing happens in the opposite case. After unpowering the command block, save the game and exit. Then, the powered state of the command block is sometimes saved.
In versions 1.20.4 or before, an item's AttributeModifiers tag was accepted correctly even if the Operation or Name fields were omitted. However, if you open a world in snapshot 24w09a with a custom item that has an attribute with one of these fields omitted, the
itemwill simply disappear.Steps to reproduce
- Create a world with version 1.20.4 with cheats enabled
- Run these commands to obtain the items.
// without Name give @p stone{AttributeModifiers:[{AttributeName:"minecraft:generic.movement_speed",Amount:1d,Operation:0,UUID:[I;1,1,1,1]}]} // without Operation give @p stone{AttributeModifiers:[{AttributeName:"minecraft:generic.movement_speed",Name:"",Amount:1d,UUID:[I;1,1,1,1]}]}- When you hold these items in your hands, you will notice that your movement speed increases correctly, even though the fields are missing.
- Now, enter the same world in 24w09a
Expected behaviour
The items should be transferred correctly, along with their attributes, which should still increase the player's movement speed.
Observed behaviour
The items are not upgraded correctly and completely disappear.
In versions 1.20.4 or before, an item's AttributeModifiers tag was accepted correctly even if the Operation or Name fields were omitted. However, if you open a world in snapshot 24w09a with a custom item that has an attribute with one of these fields omitted, the tag will simply disappear.
Steps to reproduce
- Create a world with version 1.20.4 with cheats enabled
- Run these commands to obtain the items.
// without Name give @p stone{AttributeModifiers:[{AttributeName:"minecraft:generic.movement_speed",Amount:1d,Operation:0,UUID:[I;1,1,1,1]}]} // without Operation give @p stone{AttributeModifiers:[{AttributeName:"minecraft:generic.movement_speed",Name:"",Amount:1d,UUID:[I;1,1,1,1]}]}- When you hold these items in your hands, you will notice that your movement speed increases correctly, even though the fields are missing.
- Now, enter the same world in 24w09a
Expected behaviour
The items should be transferred correctly, along with their attributes, which should still increase the player's movement speed.
Observed behaviour
The items are not upgraded correctly and and their AttributeModifiers tag disappears completely.
AttributeModifiers NBT with missing fields is not upgraded correctly to components, leading to item loss
When a mob converts to another mob, it loses all of its scores.
Exactly same issue as MC-270842 but it doesn't seem to have been fixed properly in this snapshot. (24w36a)
/scoreboard objectives add test dummy /scoreboard objectives setdisplay sidebar test /execute summon zombie run scoreboard players set @s test 1/give @s water_bucketWhen a mob converts to another mob, it loses all of its scores.
Exactly same issue as MC-270842 but it doesn't seem to have been fixed properly in this snapshot. (24w36a)
/scoreboard objectives add test dummy /scoreboard objectives setdisplay sidebar test /execute summon zombie run scoreboard players set @s test 1Run the commands above and then convert the zombie to a drowned. You will notice that the score in the sidebar disappears.
/give @s water_bucket
Summoning an entity with roughly
400+ passengers, or loading a chunk with that entity, causes extreme lag.Try running the following command with a command block. It would summon
400armor stands. (You may want to adjust the number of entities accordingly, as the lagvarieson different devices.)summon armor_stand ~ ~3 ~ {NoGravity:1b,Passengers:[{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand},{id:armor_stand}]}On my PC, it freezes for about
5seconds.This doesn't happen with a normal
400 summon commands, it only happens with passengers. I'm guessing this is caused by the server side sending too many duplicate SetPassengers packets. I once analyzed it with a packet sniffer and saw that SetPassengers packets with the exact same content are being sent as many times as the number of passengers, and every packet contained the ID of every passenger, resulting a O(n^2) time/space complexity.Summoning an entity with roughly 500+ passengers, or loading a chunk with that entity, causes extreme lag.
Try running the following command with a command block. It would summon 1000 item displays. (You may want to adjust the number of entities accordingly, as the lag may vary on different devices.)
summon item_display ~ ~1 ~ {item:{id:pufferfish},Passengers:[{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display},{id:item_display}]}On my PC, it freezes for about 90 seconds.
This doesn't happen with a normal 1000 summon commands, it only happens with passengers. I'm guessing this is caused by the server side sending too many duplicate SetPassengers packets. I once analyzed it with a packet sniffer and saw that SetPassengers packets with the exact same content are being sent as many times as the number of passengers, and every packet contained the ID of every passenger, resulting a O(n^2) time/space complexity.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
- /give @s netherite_helmet[enchantments=\{"test:test":1}]
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
- {{/give @s netherite_helmet[enchantments= {"test:test":1}
]}}
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
{{/give @s netherite_helmet[enchantments= {"test:test":1}]
}}
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
- /give @s netherite_helmet
[enchantments= {"test:test":1}]
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
- /give @s netherite_helmet[enchantments= \{"test:test":1}]
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
- /give @s netherite_helmet[enchantments= \{"test:test":1}]
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/value_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.
- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
When a command triggers an advancement/enchantment, the function calls of its reward/value_effect gets delayedWhen a command triggers an advancement/enchantment, the function calls of its reward/entity_effect gets delayed
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/
value_effects seem to be delayed.For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.
- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
There are things that can be triggered while a command is running, like advancements and custom enchantments, and the functions they call as a reward/entity_effects seem to be delayed.
For example, in advancements, one of the ways to trigger the item_durability_changed criteria is to get hit by a mob while wearing armor, and its reward function is usually called before health is updated. If you have your reward function output the player's health, and you get hit by a mob while wearing armor, you can see that the output is the health before taking damage. However, if you use the /damage @s 3 arrow command instead of taking damage from the mob, you will see that the output is the health after taking damage. This is inconsistent.
In custom enchantments, the problem is even worse (and more visible). For example, the location_changed effect component is triggered when the wearer's integer coordinates change, and its list of effects are applied in order. This is perfectly normal. But there is also a way to trigger this with a command, such as switching from spectator to survival with the /gamemode command, in this case, this will delay the function call to the last in the list of effects. This causes a problem if the order between effects is really important.
Here are the steps to reproduce this behavior.
- Apply the attached datapack to your world. (you'll need to rejoin the world)
This enchantment has a location_changed effect component, with the effects that call the first function, give a luck status effect of 0.05 seconds, and call the last function. These two functions are supposed to print the wearer's current status effect, so the first function should not output any effects, and the last function should output luck.
- Try moving around. As mentioned above, only the last function will print luck, which is normal behavior.
- Change the gamemode to spectator and then back to survival. This time, both first and last functions output luck, which is abnormal behavior.
/execute if items command can specify multiple targets and multiple slots, and returns the sum of all detected items as a result. However, if this result exceeds the int maximum (2147483647), it will overflow to a negative number and cause other unusual behaviors.
- /execute if items ...
- Fails when sum > 2147483647, which is
- /execute if items ... run ...
- Fails when sum > 2147483647, which is
- /execute unless items ...
- Fails when sum > 2147483647, which is
- /execute unless items ... run ...
- Succeeds when sum > 2147483647, which is
Due to the massive number of entities, you'll need at least 4GB of memory to reproduce this.
- In the attached world file, run the command blocks.
- (Wait about ~3 minutes...)
- See the output message or SuccessCount value of the /execute if|unless items commands.
/execute if items command can specify multiple targets and multiple slots, and returns the sum of all detected items as a result. However, if this result exceeds the int maximum (2147483647), it will overflow to a negative number and cause other unusual behaviors.
- /execute if items ...
- Fails when sum > 2147483647, which is
- /execute if items ... run ...
- Fails when sum > 2147483647, which is
- /execute unless items ...
- Fails when sum > 2147483647, which is
- /execute unless items ... run ...
- Succeeds when sum > 2147483647, which is
Due to the massive number of entities, you'll need at least 4GB of memory to reproduce this.
- In the attached world file, run the command blocks.
- (Wait about ~3 minutes...)
- See the output message or SuccessCount value of the /execute if|unless items commands.
Try running the commands below with
command blocksin a lag-free world. The commands are supposed to summon a display entity, and interpolate it from the default scale of [1,1,1] to [1,100,1] for 10 minutes, but when you run the commands no interpolation occurs and the scale immediately becomes [1,100,1]./kill @e[tag=test,type=item_display] /summon item_display ~ ~1 ~ {item:{id:stone},Tags:[test],Glowing:1b} /data merge entity @n[tag=test,type=item_display] {transformation:{scale:[1,100,1]},start_interpolation:0,interpolation_duration:12000}To get around this, display entities need to be summoned about 1-20 ticks earlier (which can be problematic for some fairly large animations because it increases the number of entities that need to be maintained and the amount of time they need to be kept). And even then, it's not a perfect solution since even with a longer delay on the server side, if the client freezes during that time it will be ignored anyway.
In the attached video, the commands are same as above, but instead there's 20 tick delay between each commands. You can see that I hold down F3+A to cause the lag for a few seconds, and then the game skips the interpolation that would normally take 10 minutes.
Try running the commands below within the same tick in a lag-free world. The commands are supposed to summon a display entity, and interpolate it from the default scale of [1,1,1] to [1,100,1] for 10 minutes, but when you run the commands no interpolation occurs and the scale immediately becomes [1,100,1].
/kill @e[tag=test,type=item_display] /summon item_display ~ ~1 ~ {item:{id:stone},Tags:[test],Glowing:1b} /data merge entity @n[tag=test,type=item_display] {transformation:{scale:[1,100,1]},start_interpolation:0,interpolation_duration:12000}To get around this, display entities need to be summoned about 1-20 ticks earlier (which can be problematic for some fairly large animations because it increases the number of entities that need to be maintained and the amount of time they need to be kept). And even then, it's not a perfect solution since even with a longer delay on the server side, if the client freezes during that time it will be ignored anyway.
In the attached video, the commands are same as above, but instead there's 20 tick delay between each commands. You can see that I hold down F3+A to cause the lag for a few seconds, and then the game skips the interpolation that would normally take 10 minutes.
Try running the commands below within the same tick in a lag-free world. The commands are supposed to summon a display entity, and interpolate it from the default scale of [1,1,1] to [1,100,1] for 10 minutes, but when you run the commands no interpolation occurs and the scale immediately becomes [1,100,1].
/kill @e[tag=test,type=item_display] /summon item_display ~ ~1 ~ {item:{id:stone},Tags:[test],Glowing:1b} /data merge entity @n[tag=test,type=item_display] {transformation:{scale:[1,100,1]},start_interpolation:0,interpolation_duration:12000}To get around this, display entities need to be summoned about 1-20 ticks earlier (which can be problematic for some fairly large animations because it increases the number of entities that need to be maintained and the amount of time they need to be kept). And even then, it's not a perfect solution since even with a longer delay on the server side, if the client freezes during that time it will be ignored anyway.
In the attached video,
the commands are same as above, but instead there's20 tick delay between each commands. You can see that I hold down F3+Atocausethelag fora few seconds,and then the gameskips the interpolation thatwouldnormally take 10 minutes.
Try running the commands below within the same tick in a lag-free world. The commands are supposed to summon a display entity, and interpolate it from the default scale of [1,1,1] to [1,100,1] for 10 minutes, but when you run the commands no interpolation occurs and the scale immediately becomes [1,100,1].
/kill @e[tag=test,type=item_display] /summon item_display ~ ~1 ~ {item:{id:stone},Tags:[test],Glowing:1b} /data merge entity @n[tag=test,type=item_display] {transformation:{scale:[1,100,1]},start_interpolation:0,interpolation_duration:12000}To get around this, display entities need to be summoned about 1-20 ticks earlier (which can be problematic for some fairly large animations because it increases the number of entities that need to be maintained and the amount of time they need to be kept). And even then, it's not a perfect solution since even with a longer delay on the server side, if the client freezes during that time it will be ignored anyway.
In the attached video, you can see the above commands being executed. Additionally I also did an experiment with a 20 tick delay between each commands. You can see that it works normally at first, but when I hold down F3+A which causes a lag of a few seconds, it skips the interpolation that normally takes 10 minutes.
Try running the commands below within the same tick in a lag-free world. The commands are supposed to summon a display entity, and interpolate it from the default scale of [1,1,1] to [1,100,1] for 10 minutes, but when you run the commands no interpolation occurs and the scale immediately becomes [1,100,1].
/kill @e[tag=test,type=item_display] /summon item_display ~ ~1 ~ {item:{id:stone},Tags:[test],Glowing:1b} /data merge entity @n[tag=test,type=item_display] {transformation:{scale:[1,100,1]},start_interpolation:0,interpolation_duration:12000}To get around this, display entities need to be summoned about 1-20 ticks earlier (which can be problematic for some fairly large animations because it increases the number of entities that need to be maintained and the amount of time they need to be kept). And even then, it's not a perfect solution since even with a longer delay on the server side, if the client freezes during that time it will be ignored anyway.
In the attached video, you can see the above commands being executed. Additionally I also did an experiment with a 20 tick delay between each commands. You can see that it works normally at first, but when I hold down F3+A
whichcausesa lagof a few seconds, it skips the interpolation that normally takes 10 minutes.
Try running the commands below within the same tick with command blocks in a lag-free world. The commands are supposed to summon a display entity, and interpolate it from the default scale of [1,1,1] to [1,100,1] for 10 minutes, but when you run the commands no interpolation occurs and the scale immediately becomes [1,100,1].
/kill @e[tag=test,type=item_display] /summon item_display ~ ~1 ~ {item:{id:stone},Tags:[test],Glowing:1b} /data merge entity @n[tag=test,type=item_display] {transformation:{scale:[1,100,1]},start_interpolation:0,interpolation_duration:12000}To get around this, display entities need to be summoned about 1-20 ticks earlier (which can be problematic for some fairly large animations because it increases the number of entities that need to be maintained and the amount of time they need to be kept). And even then, it's not a perfect solution since even with a longer delay on the server side, if the client freezes during that time it will be ignored anyway.
In the attached video, you can see the above commands being executed. Additionally I also did an experiment with a 20 tick delay between each commands. You can see that it works normally at first, but when I hold down F3+A to cause a lag for a few seconds, it skips the interpolation that normally takes 10 minutes.
/rotate with relative coordinates is not relative to the client rotation.
Run the following command every tick (with a repeating command block)
execute as @a at @s run rotate @s ~ ~Notice that the camera movement is not smooth, and it is hard to move.
This does not happen when you use /tp instead.
execute as @a at @s run tp @s ~ ~ ~ ~ ~The problem gets worse if you're in an environment with high ping.
Run the following command every tick (with a repeating command block)
execute as @a at @s run rotate @s ~ ~Notice that the camera movement is not smooth, and it is hard to move.
This does not happen when you use
/tp instead.execute as @a at @s run tp @s ~ ~ ~ ~ ~The problem gets worse if you're in an environment with high ping.
The /tp command, when used with relative coordinates, changes the position or rotation relative to the client, but the /rotate command always seems to set the rotation of the client to the result pre-calculated on the server.
The problem is that, when repeated every tick, it makes the client's camera movement jittery. Try running the following command with a repeating command block.
execute as @a at @s run rotate @s ~ ~Then try moving your camera around. You can notice that the movement is not smooth, and it is hard to move. This does not happen when you use /tp instead.
execute as @a at @s run tp @s ~ ~ ~ ~ ~The problem gets worse if you're in an environment with high ping.
/rotate with relative coordinates is not relative to the client's rotation
The /tp command, when used with relative coordinates, changes the position or rotation relative to the client, but the /rotate command
alwaysseems to set the rotation of the client to the result pre-calculated on the server.The problem is that, when repeated every tick, it makes the client's camera movement jittery. Try running the following command with a repeating command block.
execute as @a at @s run rotate @s ~ ~Then try moving your camera around. You can notice that the movement is not smooth, and it is hard to move. This does not happen when you use /tp instead.
execute as @a at @s run tp @s ~ ~ ~ ~ ~The problem gets worse if you're in an environment with high ping.
The /tp command, when used with relative coordinates, changes the position or rotation relative to the client, but the /rotate command seems to set the rotation of the client to the result pre-calculated on the server.
The problem is that, when /rotate is runned every tick, it makes the client's camera movement jittery. Try running the following command with a repeating command block.
execute as @a at @s run rotate @s ~ ~Then try moving your camera around. You can notice that the movement is not smooth, and it is hard to move. This does not happen when you use /tp instead.
execute as @a at @s run tp @s ~ ~ ~ ~ ~The problem gets worse if you're in an environment with high ping.
The item stacks used internally in the loot-tables allow users to specify their count greater than their max_stack_size. This is actually normal, because at the end of the loot-table execution, these "overstacked" items will be split into multiple item stacks to fit their max_stack_size. This behavior can be tested with th
ecommandbelow./loot give @s loot {pools:[{rolls:1,entries:[{type:item,name:snowball,functions:[{function:set_count,count:64}]}]}]}You specified 64 as the number of snowballs, which is greater than the max_stack_size of 16 for snowballs, but it works fine, and you get 4 stacks of 16 snowballs.
The problem is, this "overstacking" behavior does not seem to be supported when changing max_stack_size with set_components item modifier, and it fails to change its max_stack_size. Compared to the above, this seems uninten
ded./loot give @s loot {pools:[{rolls:1,entries:[{type:item,name:snowball,functions:[{function:set_count,count:64},{function:set_components,components:{max_stack_size:32}}]}]}]}You tried to change the max_stack_size to 32, but it didn't work, and you get 4 stacks of 16 snowballs again.
Here's the error message from the log.
Failed to apply component patch '{minecraft:max_stack_size=>32}' to item: 'Item stack with stack size of 64 was larger than maximum: 32'The item stacks used internally in the loot-tables allow users to specify their count greater than their max_stack_size. This is actually normal, because at the end of the loot-table execution, these "overstacked" items will be split into multiple item stacks to fit their max_stack_size. This behavior can be tested with this command.
/loot give @s loot {pools:[{rolls:1,entries:[{type:item,name:snowball,functions:[{function:set_count,count:64}]}]}]}You specified 64 as the number of snowballs, which is greater than the max_stack_size of 16 for snowballs, but it works fine, and you get 4 stacks of 16 snowballs.
The problem is, this "overstacking" behavior does not seem to be supported when changing max_stack_size with set_components item modifier, and it fails to change its max_stack_size. Compared to the above, this seems unintentional.
/loot give @s loot {pools:[{rolls:1,entries:[{type:item,name:snowball,functions:[{function:set_count,count:64},{function:set_components,components:{max_stack_size:32}}]}]}]}You tried to change the max_stack_size to 32, but it didn't work, and you get 4 stacks of 16 snowballs again.
Here's the error message from the log.
Failed to apply component patch '{minecraft:max_stack_size=>32}' to item: 'Item stack with stack size of 64 was larger than maximum: 32'
Summon a boat with a rotation of [1.4f,0f], leave and re-join the game, wait 1200 ticks, and focus on the boat's rotation. You will see the boat rotate on its own.
/summon oak_boat ~ ~ ~ {Rotation:[1.4f,0f]} /tick sprint 1200(See the attached video.)
This issue can be observed not only with boats, but also with the following entities.
- minecarts
- display entities
- interaction (with F3+B)
- item (with F3+B)
- armor_stand (with F3+Shift+I)
- etc.
The exact condition this issue occurs is when a certain amount of time has passed (different entities require different amounts of time), or the OnGround value has changed. Entities usually pass their rotation values to the client side in 360/256 increments (to fit in a byte), but when the condition is met, the rotation values with exact precision are sent to the client, causing the entity's rotation on the client side to change.
For me, the impact of this issue is most severe on displays, for example, imagine you're entering a world decorated with many display entities. Exactly 400 ticks after joining, all of a sudden, all of the display entities will start rotating at the same time, which is never the behavior you want as a mapmaker.
Summon a boat with a rotation of [1.4f,0f], leave and re-join the game, wait 1200 ticks, and focus on the boat's rotation. You will see the boat rotate on its own.
/summon oak_boat ~ ~ ~ {Rotation:[1.4f,0f]} /tick sprint 1200(See the attached video.)
This issue can be observed not only with boats, but also with the following entities.
- minecarts
- display entities
- interaction (with F3+B)
- item (with F3+B)
- armor_stand (with F3+Shift+I)
- etc. (possibly all entities?)
The exact condition this issue occurs is when a certain amount of time has passed (different entities require different amounts of time), or the OnGround value has changed. Entities usually pass their rotation values to the client side in 360/256 increments (to fit in a byte), but when the condition is met, the rotation values with exact precision are sent to the client, causing the entity's rotation on the client side to change.
For me, the impact of this issue is most severe on displays, for example, imagine you're entering a world decorated with many display entities. Exactly 400 ticks after joining, all of a sudden, all of the display entities will start rotating at the same time, which is never the behavior you want as a mapmaker.
When teleporting an entity with /tp with relative coordinates, the accuracy of the destination seems to vary depending on the entity's previous coordinates. Sometimes it is slightly negative, sometimes it is slightly positive.
This may seem like a well-known floating point error, but it differs in that the coordinates of the destination are always the same double value. i.e. Running two commands with exactly the same destination coordinates(double) teleports to different coordinates(double).
This only occurs in relative and local coordinates. Absolute coordinates seem safe.
/forceload add 0 0 /summon marker 0.0 0.0 0.0 {UUID:[I;0,0,0,0]}
Case 1 : from 4.0 to 1.1 → 1.1
/tp 0-0-0-0-0 4.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 Pos
Case 2 : from 16.0 to 1.1 → 1.0999999999999996
/tp 0-0-0-0-0 16.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 Pos
Case 3 : from 32.0 to 1.1 → 1.1000000000000014
/tp 0-0-0-0-0 32.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 Pos
When teleporting an entity with /tp with relative coordinates, the accuracy of the destination seems to vary depending on the entity's previous coordinates. Sometimes it is slightly negative, sometimes it is slightly positive.
This may seem like a well-known floating point error, but it differs in that the coordinates of the destination are always the same double value. i.e. Running two commands with exactly the same destination
coordinates(double) teleports to different coordinates(double).This only occurs in relative and local coordinates. Absolute coordinates seem safe.
/forceload add 0 0 /summon marker 0.0 0.0 0.0 {UUID:[I;0,0,0,0]}
Case 1 : from 4.0 to 1.1 → 1.1
/tp 0-0-0-0-0 4.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 Pos
Case
2: from16.0 to 1.1 → 1.0999999999999996coordinates/tp 0-0-0-0-016.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 Pos
Case
3: from32.0 to 1.1 → 1.1000000000000014coordinates/tp 0-0-0-0-032.0 0.0 0.0 /executepositioned 1.1 0.00.0run tp 0-0-0-0-0~0.0 0.0 /data get entity 0-0-0-0-0PosWhen teleporting an entity with /tp with relative coordinates, the accuracy of the destination seems to vary depending on the entity's previous coordinates. Sometimes it is slightly negative, sometimes it is slightly positive.
This may seem like a well-known floating point error, but it differs in that the coordinates of the destination are always the same double/float value. i.e. Running two commands with exactly the same destination position coordinates(double) teleports to different position coordinates(double).
This only occurs in relative and local coordinates. Absolute coordinates seem safe.
/forceload add 0 0 /summon marker 0.0 0.0 0.0 {UUID:[I;0,0,0,0]}
Case 1 : teleport from 4.0 to 1.1 → 1.1
/tp 0-0-0-0-0 4.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 PosCase 2 : teleport from 16.0 to 1.1 → 1.0999999999999996
/tp 0-0-0-0-0 16.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 PosCase 3 : teleport from 32.0 to 1.1 → 1.1000000000000014
/tp 0-0-0-0-0 32.0 0.0 0.0 /execute positioned 1.1 0.0 0.0 run tp 0-0-0-0-0 ~ 0.0 0.0 /data get entity 0-0-0-0-0 Pos
The same problem occurs with the rotation argument of /tp. (Not in /rotate.)
Case 4 : rotate from 2.0 to 1.1 → 1.1
/tp 0-0-0-0-0 0.0 0.0 0.0 2.0 0.0 /execute rotated 1.1 0.0 run tp 0-0-0-0-0 0.0 0.0 0.0 ~ 0.0 /data get entity 0-0-0-0-0 RotationCase 5 : rotate from 8.0 to 1.1 → 1.0999999
/tp 0-0-0-0-0 0.0 0.0 0.0 8.0 0.0 /execute rotated 1.1 0.0 run tp 0-0-0-0-0 0.0 0.0 0.0 ~ 0.0 /data get entity 0-0-0-0-0 RotationCase 6 : rotate from 16.0 to 1.1 → 1.1000004
/tp 0-0-0-0-0 0.0 0.0 0.0 16.0 0.0 /execute rotated 1.1 0.0 run tp 0-0-0-0-0 0.0 0.0 0.0 ~ 0.0 /data get entity 0-0-0-0-0 Rotation
Accuracy of /tp with relative coordinates depends on entity's previouslocationAccuracy of /tp with relative coordinates depends on entity's previous position/rotation
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
It's simmilar.
When I press [Enter] in this moment, "empty text field" is saved.
and it becomes default command block.
You also interpreted the command after omitting "run execute". I already know why such results come out. What I want to say is that "run execute" should mean something.
The execute-execute command must behave the same as the execute-function-execute command.
Just like the execute-something command works the same as execute-function-something.
(Workaround)
This does not occur in predicate's distance detection. Use that instead.
Still happens in 1.19.4. Player now teleports to the correct dimension, but still does not "/spectate" the specified entity. (Also F3+N doesn't work after this teleport. I had to run the /gamemode command myself.)
Uh wait... I apologize, it appears that only the AttributeModifier tag is lost, not the entire item. I wrote them incorrectly at first.
It seems that this bug has been fixed. I can't reproduce it in 1.20.5
This issue is different from MCPE-165278. I know that depth-first/breadth-first order can change the logic of a command, but that doesn't explain how the forked branches are changing their execution position even though there is no position-related subcommands. You can see that the commands in my report don't have `at @p`, which means that there is no means to re-capture the player's position.
Additionally, I would like to mention that this does not happen when running from a command block.
Scores still get lost on zombie-drowned conversion. Still not fixed in 24w36a
MC-276312Changed the command from 400 armor stands to 1000 item displays, to make the lag more visible.
Also attached a video of reproducing the bug.
Does not occur in 1.21.1. It seems it was fixed somewhere between 1.20.4 and 1.21.1
Also here are the commands for recent versions.
/give @s shield[custom_data={Cap:1b}] /execute if predicate {condition:entity_properties,entity:this,predicate:{equipment:{mainhand:{predicates:{custom_data:{Cap:1b}}}}}}/rotate command also seems to have this issue. If you run /rotate @s ~30 ~ while riding something, the horizontal rotation is interpolated.
I think this issue should be considered more important than before, especially since the main reason /rotate was added to the game was to rotate while riding.
You can reproduce it with just the commands in the description, the loot tables are defined inline.
Open a singleplayer world with cheats allowed and run the commands in chat. When you run the latter command, you'll see the set_components function fail to apply (expected to get 2 stacks of 32 snowballs, but instead got 4 stacks of 16 snowballs) and the error in the log.
I was a bit confused after reading that report, but I think I understand the difference between these bugs, so let me clarify.
It seems like
MC-270134is describing that set_count function does not allow overstacked items, and my report (MC-277803) is describing that set_components function does not allow overstacked items. The commands inMC-270134are actually working fine in current release (1.21.3), so the set_count issue is fixed now, but the same issue is still present in set_components function.I see that changing the order of the functions fixes this as well, but there are cases where you can't change the order, like this command.
/loot give @s loot {pools:[{rolls:1,entries:[{type:loot_table,value:"blocks/redstone_ore",functions:[{function:set_components,components:{max_stack_size:1}}]}]}]}So I think this could be considered a valid bug.