Scott
- nigathan
- nigathan
- Europe/Stockholm
- Yes
- No
MC-68541![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
I don't see the point in being able to make your own gamerules if you can't disable them. A custom gamerule should not output a signal from a command block if the gamerule is set to false or 0.
The screenshot demonstrates that even though my custom gamerule is set to false a signal is still being output.I don't see the point in being able to make your own gamerules if you can't disable them. A custom gamerule should not output a signal from a command block if the gamerule is set to false or 0.
I am aware on the wiki this is proper behaviour, I just find it extremely useless. And if this feature was added then we could really make some cool multiplayer maps and ops could enable/disable certain aspects via a command.
The screenshot demonstrates that even though my custom gamerule is set to false a signal is still being output.
I don't see the point in being able to make your own gamerules if you can't disable them. A custom gamerule should not output a signal from a command block if the gamerule is set to false or 0.
I am aware on the wiki this is proper behaviour, I just find it extremely useless. And if this feature was added then we could really make some cool multiplayer maps and ops could enable/disable certain aspects via a command.
The screenshot demonstrates that even though my custom gamerule is set to false a signal is still being output.
Edit: Thanks to the /stats command, I have found use for this feature!
When running certain commands in the server console at an entity's position some errors are not printed, but if the command succeeds it will print the output properly.
Example:
All of the following commands are to be run from the server console:
execute at @p run data get block ~ ~ ~Unless the player is standing inside a block entity, this message should print the error "The target block is not a block entity", instead nothing prints at all. If the player is standing in a block entity, it will print the data of the block as expected.
data get block ~ ~ ~Prints the proper error:
[16:42:24] [Server thread/INFO]: The target block is not a block entityexecute positioned as @p run data get entity @e[limit=1,name=non_existant]Unless an entity named "non_existant" exists, nothing will print.
data get entity @e[limit=1,name=non_existant]Prints the proper error:
[16:45:44] [Server thread/INFO]: No entity was found
Considering this is the console running these commands, these error messages should always be displayed, regardless of nature of how they are ran.When running certain commands in the server console at an entity's position some errors are not printed, but if the command succeeds it will print the output properly.
Example:
All of the following commands are to be run from the server console:
execute at @p run data get block ~ ~ ~Unless the player is standing inside a block entity, this message should print the error "The target block is not a block entity", instead nothing prints at all. If the player is standing in a block entity, it will print the data of the block as expected.
data get block ~ ~ ~Prints the proper error:
[16:42:24] [Server thread/INFO]: The target block is not a block entityexecute positioned as @p run data get entity @e[limit=1,name=non_existant]Unless an entity named "non_existant" exists, nothing will print.
data get entity @e[limit=1,name=non_existant]Prints the proper error:
[16:45:44] [Server thread/INFO]: No entity was foundHowever, if the position is not tied to an entity, the output seems to be unaffected:
execute in the_nether positioned 8 75 -15 run data get block ~ ~ ~ [16:46:29] [Server thread/INFO]: The target block is not a block entity
Considering this is the console running these commands, these error messages should always be displayed, regardless of nature of how they are ran.
Not sure exactly which prior snapshots I'm referring to, but in earlier 1.13 snapshots, this behavior did not exist. The errors would print correctly regardless of position.
The bug
When copying nbt data from one source to another, using either execute store or data modify ... set from ..., the data is copied as reference for the duration of that tick. This means if that source nbt is later modified or deleted within the same tick as the copy, the destination nbt will also reflect those changes. In the case that data remove or data modify ... set value ... is used to erase data, the destination nbt will be reinitialized and the tag(s) will persist, just with their initial values (for example: 0 for type int).
Example function showing this:
summon minecraft:pig ~ ~5 ~ {CustomName:"\"Oinkster\"",NoAI:1b} summon minecraft:pig ~ ~ ~ {CustomName:"\"Oink's Twin\""} data modify entity @e[name="Oink's Twin",limit=1] Silent set from entity @e[name="Oinkster",limit=1] Silent data remove entity @e[name="Oinkster",limit=1] NoAIExpected behavior: "Oink's Twin" should have NoAI:1b and "Oinkster" should not have the NoAI tag at all.
Actual behavior: Neither entity has the NoAI tag at all.
And just to prove this isn't because the entity hasn't ticked yet, if you split the function into two separateones,with the summons in the first and the datasin the second, then run them on separate ticks, the same result is observed.You can also simply change the values of the source nbt and observe the value changes on both entities.
Side notes: I, personally, like the idea of reference for things like this in terms of optimizations, however this will make it impossible to perform several operations on temporary lists during the same tick; which is less than desirable.The bug
When copying nbt data from one source to another, using either execute store or data modify ... set from ..., the data is copied as reference for the duration of that tick. This means if that source nbt is later modified or deleted within the same tick as the copy, the destination nbt will also reflect those changes. In the case that data remove or data modify ... set value ... is used to erase data, the destination nbt will be reinitialized and the tag(s) will persist, just with their initial values (for example: 0 for type int).
Side notes: I, personally, like the idea of reference for things like this in terms of optimizations, however this will make it impossible to perform several operations on temporary lists during the same tick; which is less than desirable.
I used to have an example here, but realized it wasn't correct. This seems to only happen with custom nbt tags like minecraft:item's tag tags.
The bug
When copying nbt data from one source to another, using either execute store or data modify ... set from ..., the data is copied as reference for the duration of that tick. This means if that source nbt is later modified or deleted within the same tick as the copy, the destination nbt will also reflect those changes. In the case that data remove or data modify ... set value ... is used to erase data, the destination nbt will be reinitialized and the tag(s) will persist, just with their initial values (for example: 0 for type int).
Side notes: I, personally, like the idea of reference for things like this in terms of optimizations, however this will make it impossible to perform several operations on temporary lists during the same tick; which is less than desirable.
I used to have an example here, but realized it wasn't correct.This seems to only happen with custom nbt tags like minecraft:item's tag tags.The bug
When copying nbt data from one source to another, using either execute store or data modify ... set from ..., the data is copied as reference for the duration of that tick. This means if that source nbt is later modified or deleted within the same tick as the copy, the destination nbt will also reflect those changes. In the case that data remove or data modify ... set value ... is used to erase data, the destination nbt will be reinitialized and the tag(s) will persist, just with their initial values (for example: 0 for type int).
Side notes: I, personally, like the idea of reference for things like this in terms of optimizations, however this will make it impossible to perform several operations on temporary lists during the same tick; which is less than desirable.
This seems to only happen with custom nbt tags like minecraft:item's tag tags.
Attached is a datapack that uses a jukebox to store a list of data and a command block used to compare two strings. Using a temporary list, the object that contains the matching string within the jukebox's RecordItem tag also contains an ID tag which is type int. After finding the correct object, the item's Item.tag.ID is set from here, then to show the bug the ID of the source is changed to 42 (from 6).
Expected behavior: The item's ID tag is set to 6.
Actual behavior: The item's ID tag is set to 42.
To test, start a new world and go to 0,0 before loading the datapack. Then run /function lookup:test
The bug
/data modify seem
sto copy NBT by reference. For most NBT this has no effect, but for NBT in the tag tag of items, it results in a link between the two, where later modifying one affects the other (other examples in MC-114104).How to reproduce
Get an item with NBT, summon a mob, and data modify your item into its hand:
/replaceitem entity @p weapon.mainhand diamond_sword{Damage:5} /summon husk /data modify entity @e[type=husk,sort=nearest,limit=1] HandItems[0] set from entity @p SelectedItem /enchant @p sharpness→
The husk's sword is enchanted as well.
This link will persist until either the destination or source is reloaded for any reason.
Additional test
Attached is a datapack that uses a jukebox to store a list of data, and a command block used to compare two strings. Using a temporary list, the object that contains the matching string within the jukebox's RecordItem tag also contains an ID tag which is type int. After finding the correct object, the item's Item.tag.ID is set from here, then to show the bug the ID of the source is changed to 42 (from 6).
Expected behavior: The item's ID tag is set to 6.
Actual behavior: The item's ID tag is set to 42.
To test, start a new world and go to 0,0 before loading the datapack. Then run /function lookup:test
The bug
/data modify and /execute store seem to copy NBT by reference. For most NBT this has no effect, but for NBT in the tag tag of items, it results in a link between the two, where later modifying one affects the other (other examples in MC-114104).
How to reproduce
Get an item with NBT, summon a mob, and data modify your item into its hand:
/replaceitem entity @p weapon.mainhand diamond_sword{Damage:5} /summon husk /data modify entity @e[type=husk,sort=nearest,limit=1] HandItems[0] set from entity @p SelectedItem /enchant @p sharpness→
This link will persist until either the destination or source is reloaded for any reason.
Additional test
Attached is a datapack that uses a jukebox to store a list of data, and a command block used to compare two strings. Using a temporary list, the object that contains the matching string within the jukebox's RecordItem tag also contains an ID tag which is type int. After finding the correct object, the item's Item.tag.ID is set from here, then to show the bug the ID of the source is changed to 42 (from 6).
Expected behavior: The item's ID tag is set to 6.
Actual behavior: The item's ID tag is set to 42.
To test, start a new world and go to 0,0 before loading the datapack. Then run /function lookup:test
Right, I saw that post first. I'm not saying this is exactly a bug, I just feel like this needs to change, or there needs to be a way to delete a gamerule to remove the positive output. Otherwise what is this feature even in the game for?
Ah ha! Thank you for your response Mlakuss, at first when I set it up, the scoreboard wasn't updating the objective for me at all. Then I decided to define the objective to myself to see if it just couldn't update because that objective is undefined to me and it worked after that! So now I used the following commands on a clock to ensure each player will always have the objective corresponding to my gamerule:
/stats block ~-1 ~ ~-1 set QueryResult #ServerScore toxicOn
/gamerule doToxicDmg
/scoreboard players operation @a toxicOn = #ServerScore toxicOn
Confirmed for 18w45a happens in both singleplayer and multiplayer servers. Almost every time entities near where you died will be invisible after respawn. Relogging very rarely fixes it.