uyp
- uyp
- uyp
- Europe/Stockholm
- Yes
- No
Perhaps the server is overloaded and therefore runs slower; if you try to break a block just a single time and wait will it break eventually?
What I expected to happen was:
The subcommand "say ." is executed.What actually happened was:
The subcommand is not executed.Steps to Reproduce:
1./scoreboard objectives add test dummy2.
/execute store success score @r[name=] test run say .What I expected to happen was:
The subcommand "say ." is executed.What actually happened was:
The subcommand is not executed.Steps to Reproduce:
/scoreboard objectives add test dummy /execute store success score @r[name=] test run say .
What I expected to happen was:
The subcommand "say ." is executed.What actually happened was:
The subcommand is not executed.Steps to Reproduce:
/scoreboard objectives add test dummy /execute store success score @r[name=] test run say .What I expected to happen was:
The subcommand "say ." is executed because the execution shouldn't depend on the number of specified entities.What actually happened was:
The subcommand is not executed.Steps to Reproduce:
/scoreboard objectives add test dummy /execute store success score @r[name=] test run say .
Steps to reproduce:
1. Run:
/execute in the_nether run forceload add 0 0 /summon armor_stand ~ ~ ~ {Tags:[foo]} /gamerule commandBlockOutput false2. Place a repeating command block with the command:
execute in the_nether run tp @e[tag=foo] 0 0 03. Place a chain command block with the command:
tp @e[tag=foo] ~ ~ ~4. Wait a little bit.
Notice that the fps decreases and the log gets filled with warnings about duplicate entity UUID's.
Look at the armor stand, and kill it using the kill command.
Notice that there is still a "targeted entity" entry in the f3 menu.This bug did not occur in 1.16.4.
Steps to reproduce:
1. Run:
/execute in the_nether run forceload add 0 0 /summon armor_stand ~ ~ ~ {Tags:[foo]} /gamerule commandBlockOutput false2. Place a repeating command block with the command:
execute in the_nether run tp @e[tag=foo] 0 0 03. Place a chain command block with the command:
tp @e[tag=foo] ~ ~ ~4. Wait a little bit.
Notice that the fps decreases and the log gets filled with warnings about duplicate entity UUID's.
5. Look at the armor stand, and kill it using the kill command.
Notice that there is still a "targeted entity" entry in the f3 menu.
This bug did not occur in 1.16.4.
It only happens on multiplayer servers.
The command:
/particle dust 0 0 0 0 ~ ~ ~ 0 0 0 0 0The kick message is:
Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException: Packet 0/35 (qk) was larger than I expected, found 12 bytes extra whilst reading packet 35
It only happens on multiplayer servers.
The command:
/particle dust 0 0 0 0 ~ ~ ~ 0 0 0 0 0The kick message is:
Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException: Packet 0/35 (qk) was larger than I expected, found 12 bytes extra whilst reading packet 35
Sign commands are intended to work similarly to command blocks instead of chat commands anyway, e.g. the slash at the beginning isn't needed, and the command is executed at the sign's location instead of the player's.
The longer command length limit on signs is a useful feature for e.g. mapmakers. Limiting the abilities of operators like that is feature removal from my point of view.
in my opinion, it's a useful feature instead of a bug
This issue seems to have been introduced in 1.16-pre5 when MC-180867 was fixed. That version added the following code to JukeboxBlock.setPlacedBy (as noted by uyp):
CompoundTag tag = stack.getOrCreateTag(); if (tag.contains("BlockEntityTag")) { CompoundTag tag2 = tag.getCompound("BlockEntityTag"); if (tag.contains("RecordItem")) { // Update has_record state } }
21w37a replaced that code with this:
CompoundTag tag = item.getBlockEntityData(stack); // above is equivalent to stack.getTagElement("BlockEntityTag"), which doesn't create tag if there is no tag if (tag != null && tag.contains("RecordItem")) { // Update has_record state }
I also am able to reproduce the issue in 1.17.1 but not in 21w37a, so I'm marking it as fixed. (MC-180867 also remains fixed.)
Just calculate the motion using scoreboards as the difference of the position now and the position a short time ago.
A workaround for this is to execute a function as the armor stand because "@s" doesn't get lost (like Alluet suggested):
tag @s add teleport2 summon armor_stand ~ ~ ~ {NoGravity:1b,Invulnerable:1b,Tags:["teleport"]} execute as @e[tag=teleport] run function 1:1 tag @s remove teleport2This behavior is suboptimal because in case there is no entity for which the result is stored you have to execute the same subcommands separately from "execute store" again.
This might refer to MC-114104
For me, the kill command worked, are you sure the donkey is loaded?
When I summoned it using
/summon zombie ~ ~ ~ {Attributes:[{Name:generic.maxHealth,Base:25.0}],Health:25.0f}, its health was 25.
you can destroy it using an explosion
run
it's probably set to a value below 2
you need to set it to a high value
sharpness up to 2147483647 is possible too
and the damage of multiple sharpness enchantments adds up
The center of a block is always at the block coordinates shifted 0.5 blocks towards the x/y/z direction. Your observation is caused by the fact that adding 0.5 to a negative integer causes the part on the left of the decimal point to decrease by 1.
seems fixedin the dimension the command is executed in, it searches for a spot to teleport the player to, and changes the coordinates accordingly
but it doesn't change the dimension of the player
that's all there is to it
couldn't reproduce
The result value of commands is always an integer.
You can use this command to store the decimal information:
all those things require the player to be an operator for their data to be copied when placed
@kerran @StrongSand94191
duplicates MC-133579
for some blocks, a workaround is to summon an arrow above the block and get the block id from inBlockState.Name and the block states from inBlockState.Properties of the arrow
duplicates
MC-181832it happens if at least 64 command blocks in the same chunk update their LastOutput every tick
Workaround: set TrackOutput to 0b for all command blocks
duplicates
MC-929confirmed in 1.16.2
duplicates MC-152997
the block to place a sugar cane on requires an adjacent water block
workaround:
Workarounds are to use a sign or a loot table.
/setblock ~ ~ ~ oak_sign{Text1:'{"text":"","clickEvent":{"action":"run_command","value":"give @s writable_book{pages:[\\"line1\\nline2\\"]}"}}'}{ "pools": [ { "rolls": 1, "entries": [ { "type": "minecraft:item", "name": "minecraft:writable_book", "functions": [ { "function": "minecraft:set_nbt", "tag": "{pages:[\"line1\nline2\"]}" } ] } ] } ] }as the function is running, it stores the result/success of every command in the function
Confirmed in 1.16.3.
It's probably the spawn protection that prevents the clickability of signs.
Set spawn-protection=0 in server.properties
Confirmed in 1.16.3.
It only seems to happen if the player is in creative mode and has their inventory open while the function runs.
Confirmed in 1.16.4-pre2.
For me, after filling the area with cave air again, the gold blocks disappear after leaving the world though.
The bug seems to only occur in chunk sections that contain only air-like blocks.
It also affects the execute if blocks command:
setblock 0 99 0 air setblock 0 98 0 cave_air setblock 0 97 0 stone execute if blocks 0 99 0 0 99 0 0 98 0 all→
The command fails.
setblock 0 97 0 air execute if blocks 0 99 0 0 99 0 0 98 0 all→
The command succeeds as the chunk section contains only air-like blocks.
duplicates
MC-117574duplicates
MC-12363duplicates
MC-203568fixed in 20w45a; likely because
MC-108469was fixedduplicates MC-184268
confirmed in 20w45a
fixed in 20w45a
confirmed in 20w45a
fixed in 20w45a
fixed in 20w45a
It seems to happen only in creative mode.
You could make a hidden advancement that doesn't have the count condition.
Let it run a function as the reward.
In the function, run "execute store result score ... run clear @s mushroom_stew 0" to count the items.
If the score is at least 10, grant a visible advancement.
Else, revoke the hidden advancement such that it can be triggered again.
try fn+F3+G
It probably happens because of
MC-207900.Yes, I reproduced it in 20w51a
Does it matter that operators can exceed the chat limit?
Examples 1 and 2 can already be achieved by getting the items from the saved hotbar directly, or using /data modify to construct the items using multiple commands, e.g.
data modify block ~ ~ ~ Items[].tag.Enchantments append value {id:sharpness,lvl:32767}to add an arbitrary amount of nbt tags.
Spamming the chat can be done by /execute as @e as @e run tellraw <...>
If anything, shortening the command limit for signs would just make it annoying for mapmakers to use them.
This issue is rather about the ability to execute op-level-2 commands, after being deopped, or after having access to the world files.
Could MC-197860 have caused this?
Steps to get the dimensions back before this bug is fixed:
I added a comment on the other bug report on how to solve it
The video has been removed, and you forgot .tag in the third and fourth commands.
The commands don't need to run in the same tick.
The first command removes the Potion tag, so the second command finds no entry to modify.
Therefore, it creates a new entry at the end of the list.
At first, its value is {tag:{Potion:"minecraft:water"}}
Then, it is set to {tag:{Value:"bar"}}
The added entry does not contain Slot, so its value defaults to 0.
It overwrites the other item with Slot:0b because the new entry is at the end of the list and therefore loaded after.
The new item is missing id and Count, so it is removed.
May be related to MC-173001.
You can use a resource pack to bypass the Lock.
To open a container with the enabled resource pack, the Lock needs to match the translation, so in this case:
§5Translated Item
To get such a Lock in game, click on this sign:
/setblock ~ ~ ~ oak_sign{Text1:'{"text":"","clickEvent":{"action":"run_command","value":"data modify block 8 4 8 Lock set value \\"\\u00A75Translated Item\\""}}'}To get the stacked items, you can also use
When mining the shulker box in survival mode, all the items unstack, resulting in 64*27 slots.
set the PersistenceRequired nbt tag to 1b to prevent despawning
@crazymoose77756 that bug is fixed
this is a duplicate of
MC-12363data modify does create a new matching list element if it can't find one with the given predicate.
You can test it in storage instead of a container, or modify the predicate to contain a valid id and Count, which will create a new item.
In the title, "Teleport after death" should be changed to "Respawning" because only changing dimensions via respawning is affected.
Also, when entering the end portal in the end, changed_dimension is triggered with the overworld as the destination, regardless of where the respawn position is, so that can just be removed when fixing this bug.
The wither 1 effect applies damage if its remaining duration in ticks is divisible by 40.
If the entity doesn't already have the wither effect with a higher duration, the wither rose sets the wither duration to 40 ticks every tick, so the entity is tried to be damaged constantly.
as a workaround, use @s[type=player]
In 1.16, both tellraw messages are always green, unlike how it says in the reproduction steps.
As a workaround, you can use
[{"text":"","color":"green"},{"selector":"@a"}]It happens because the success of each command in the function is stored.
In the setPlacedBy method of net.minecraft.world.level.block.JukeboxBlock (mojang mappings),
an empty compound tag is created on the item stack that is used to place the jukebox.
Couldn't reproduce. Note that the spawn protection is disabled if noone is OP.
The two links are the same.
When you looked at the signs, I could see that the "Targeted Block" z-coordinates were 1 lower than what you used in the command.
To switch dimensions, non-player entities are entirely recreated, but `@s` still targets the previous entity. (`@e` and the uuid select the new entity)
You accidentally reported this bug for the Java Edition.
Here is the Bedrock Page.
players are added when joining or when their value changes
When the player moves, the server clamps the y position between +-2*10^7, but the client doesn't know that.
When the player moves, the server clamps the y position between +-2*10^7, but the client doesn't know that.
When teleporting to ~ ~-1 ~, the client doesn't receive absolute coordinates, but just the information to teleport 1 block lower.
AgeLocked is a Spigot feature.
put the name between quotes
duplicates
MC-225253This probably happens because the server runs slower than the client, indicated by the ms ticks value on the debug screen being more than 50.
see the comments on
MC-32575corey manlen
[Bot] Arisa made changes - 11/Apr/21 12:31 AM
Upload the crash report.
Could you attach the json file?
You might need to enable the sendCommandFeedback gamerule.