Nuclearinferno
- Nuclearinferno
- JIRAUSER740388
- Europe/Stockholm
- Yes
- No
MC-270389
It is no
wpossible to run commands at the end of a tick. The load and tick function tags allow only to run commands at the start of a tick. This really limits the possibilities of commands and has caused some serious issues with my data pack projects. Please add a new tag to run commands at the end of a tick. Between Block entities are processed and game saving might be the best option. Thank you in advance.It is not possible to run commands at the end of a tick. The load and tick function tags allow only to run commands at the start of a tick. This really limits the possibilities of commands and has caused some serious issues with my data pack projects. Please add a new tag to run commands at the end of a tick. Between Block entities are processed and game saving might be the best option. Thank you in advance.
It is not possible to run commands at the end of a tick. The "load" and "tick" function tags allow only to run commands at the start of a tick. This really limits the possibilities of commands and has caused some serious issues with my data pack projects. Please add a new tag to run commands at the end of a tick. Between Block entities are processed and game saving might be the best option. Thank you in advance.
It is not possible to run commands at the end of a tick. The "load" and "tick" function tags allow only to run commands at the start of a tick. This really limits the possibilities of commands
andhas caused some serious issues with my data pack projects. Please add a new tag to run commands at the end of a tick. Between Block entities are processed and game saving might be the best option. Thank you in advance.It is not possible to run commands at the end of a tick. The "load" and "tick" function tags allow only to run commands at the start of a tick. This really limits the possibilities of commands since you might want to wait for the game to process certain events in a tick before running a function in the same tick. It has caused some serious issues with my data pack projects. Please add a new tag to run commands at the end of a tick. Between Block entities are processed and game saving might be the best option. Thank you in advance.
The stopsound command stops the sound with a delay on the client side which causes sounds to start playing and than stopping even if the command is run directly after the sound is played.
Example: the xp command is used to increase the players xp in a function. The level increases from 4 to 5 which causes the level up sound to play. Directly after the stopsound command is run but the sound is not correctly stopped and can be heard for a short period of time.
I suggest a feature which prevents a certain sound from playing the next time it tries to play the sound.
Area effect clouds that have the "HiddenEffect" nbt tag in there Effects data don't apply the effect correctly. Instead they sometimes only apply the hidden effect or the actual effect but not both. The player should be able to receive effect from the area effect cloud that also have the "HiddenEffect" nbt tag included. If the players does not have the specific effect the area effect cloud applies. The nbt tag should just be copied over together with the "HiddenEffect" nbt tag.
I recorded a reverence video but it is larger then 10MB and therefore can't be attached to the references. I uploaded it to drop box though and allacted some pictures of the video. Here is the download link for the video: https://www.dropbox.com/s/znf5krhz2vlssd9/reference_video.mkv?dl=1
Area effect clouds that have the "HiddenEffect" nbt tag in there Effects data don't apply the effect correctly. Instead they sometimes only apply the hidden effect or the actual effect but not both. The player should be able to receive effects from the area effect cloud that also have the "HiddenEffect" nbt tag included. If the players does not have the specific effect the area effect cloud applies. The nbt tag should just be copied over together with the "HiddenEffect" nbt tag.
I recorded a reverence video but it is larger then 10MB and therefore can't be attached to the references. I uploaded it to drop box though and allacted some pictures of the video. Here is the download link for the video: https://www.dropbox.com/s/znf5krhz2vlssd9/reference_video.mkv?dl=1
Area effect clouds that have the "HiddenEffect" nbt tag in there Effects data don't apply the effect correctly. Instead they sometimes only apply the hidden effect or the actual effect but not both. The player should be able to receive effects from the area effect cloud that also have the "HiddenEffect" nbt tag included. If the players does not have the specific effect the area effect cloud applies. The nbt tag should just be copied over together with the "HiddenEffect" nbt tag.
I recorded a reverence video but it is larger then 10MB and therefore can't be attached to the references. I uploaded it to drop box though and a
llacted some pictures of the video. Here is the download link for the video: https://www.dropbox.com/s/znf5krhz2vlssd9/reference_video.mkv?dl=1Area effect clouds that have the "HiddenEffect" nbt tag in there Effects data don't apply the effect correctly. Instead they sometimes only apply the hidden effect or the actual effect but not both. The player should be able to receive effects from the area effect cloud that also have the "HiddenEffect" nbt tag included. If the players does not have the specific effect the area effect cloud applies. The nbt tag should just be copied over together with the "HiddenEffect" nbt tag.
I recorded a reverence video but it is larger then 10MB and therefore can't be attached to the references. I uploaded it to drop box though and attached some pictures of the video. Here is the download link for the video: https://www.dropbox.com/s/znf5krhz2vlssd9/reference_video.mkv?dl=1
Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName are shown for non living entities since this version.
Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName
areshown for non living entities since this version.Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName is shown for non living entities since this version.
Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName is shown for non living entities since
this version.Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName is shown for non living entities since 1.20.3.
CustomName visibility does not work correctly for non living entitiesCustomName is visible for non living entities in a team with nameTagVisibility set to never
Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName is
shownfor non living entities since 1.20.3.Non Living entities still display there CustomName when in a team with nameTagVisibility set to never. This is inconsistent with the behaviour of living entities which hide there CustomName in this case. Especialy problematic since CustomName is displayed for non living entities since 1.20.3.
In snapshot 24w09a item components where added. There is states that the attribute modifier operation type add_multiplied_total uses the calculated value of all previous modifiers for its operation. This is currently not testable since bug MC-277324 exists but if this behavior works as it is described by the update log of 24w09a the actual value of attributes depends on the order in which the modifiers are evaluated. This is a problem since it causes unexpected behavior in datapacks.
When adding attribute modifiers to entities using commands the order in which these modifiers are added can v
ery based on the situation. Since this order is kept by the game, the calculation of the attribute value might appear to be random.How to fix:
In my opinion it would be better if the game first evaluates all the modifiers using the operation type add_value. After that all modifiers of the type add_multiplied_base should be evaluated and last the game should evaluate all modifiers of the add_multiplied_total type. This change would ensure that the attribute value is always the same and the order doesn't matter. For optimization the modifiers could be grouped by there types in the NBT of entities and players instead of specifying the type individually for each modifier.In snapshot 24w09a item components where added. There is states that the attribute modifier operation type add_multiplied_total uses the calculated value of all previous modifiers for its operation. This is currently not testable since bug MC-277324 exists but if this behavior works as it is described by the update log of 24w09a the actual value of attributes depends on the order in which the modifiers are evaluated. This is a problem since it causes unexpected behavior in datapacks.
When adding attribute modifiers to entities using commands the order in which these modifiers are added can vary based on the situation. Since this order is kept by the game, the calculation of the attribute value might appear to be random.
How to fix:
In my opinion it would be better if the game first evaluates all the modifiers using the operation type add_value. After that all modifiers of the type add_multiplied_base should be evaluated and last the game should evaluate all modifiers of the add_multiplied_total type. This change would ensure that the attribute value is always the same and the order doesn't matter. For optimization the modifiers could be grouped by there types in the NBT of entities and players instead of specifying the type individually for each modifier.
In snapshot 24w09a item components where added. There is states that the attribute modifier operation type add_multiplied_total uses the calculated value of all previous modifiers for its operation. This is currently not testable since bug MC-277324 exists but if this behavior works as it is described by the update log of 24w09a the actual value of attributes depends on the order in which the modifiers are evaluated. This is a problem since it causes unexpected behavior in datapacks.
When adding attribute modifiers to entities using commands the order in which these modifiers are added can vary based on the situation. Since this order is kept by the game, the calculation of the attribute value might appear to be random.
How to fix:
In my opinion it would be better if the game first evaluates all the modifiers using the operation type add_value. After that all modifiers of the type add_multiplied_base should be evaluated and last the game should evaluate all modifiers of the add_multiplied_total type. This change would ensure that the attribute value is always the same and the order doesn't matter. For optimization the modifiers could be grouped by there types in the NBT of entities and players instead of specifying the type individually for each modifier.In snapshot 24w09a item components where added. There is states that the attribute modifier operation type add_multiplied_total uses the calculated value of all previous modifiers for its operation. This means that the actual value of attributes depends on the order in which the modifiers are evaluated. This is a problem since it causes unexpected behavior in datapacks.
When adding attribute modifiers to entities using commands the order in which these modifiers are added can vary based on the situation. Since this order is kept by the game, the calculation of the attribute value might appear to be random.
How to fix:
In my opinion it would be better if the game first evaluates all the modifiers using the operation type add_value. After that all modifiers of the type add_multiplied_base should be evaluated and last the game should evaluate all modifiers of the add_multiplied_total type. This change would ensure that the attribute value is always the same and the order doesn't matter. For optimization the modifiers could be grouped by there types in the NBT of entities and players instead of specifying the type individually for each modifier.
In snapshot 24w09a item components where added. There is states that the attribute modifier operation type add_multiplied_total uses the calculated value of all previous modifiers for its operation. This means that the actual value of attributes depends on the order in which the modifiers are evaluated. This is a problem since it causes unexpected behavior in datapacks.
When adding attribute modifiers to entities using commands the order in which these modifiers are added can vary based on the situation. Since this order is kept by the game, the calculation of the attribute value might appear to be random.
How to fix:
In my opinion it would be better if the game first evaluates all the modifiers using the operation type add_value. After that all modifiers of the type add_multiplied_base should be evaluated and last the game should evaluate all modifiers of the add_multiplied_total type. This change would ensure that the attribute value is always the same and the order doesn't matter. For optimization the modifiers could be grouped by there types in the NBT of entities and players instead of specifying the type individually for each modifier.Reloved in 1.21.2-pre3
When having two items with attribute modifiers that have the same id and apply to the same attribute but require different slots to activate, the game starts behaving in unexpected ways.
Equipping both items in there respective slots only applies the modifier once (as expected.)
Removing only one of these items also removes the modifier despite the other item still being equipped in the correct slot and theoretically applying the modifier (unexpected).
I know that it is not intended to have two modifiers with the same id but it could actually be useful if this bug was fixed since it would then be possible to use an "or gate" for modifiers.
You either have to wear this equipment in this slot or this equipment in this other slot to get the modifier but wearing both at the same time doesn't add to your attribute value again. This has good implications for datapack creation in my opinion.@Greymagic27
How to reproduce:1. Use this command to give your self an item that applies a modifier when held in the mainhand:
/give @p turtle_scute[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"mainhand"}]] 12. Use this command to give your self an item that applies a modifier with the same type and id but when on the players head:
/give @p golden_helmet[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"head"}]] 13. Go into survival or adventure mode
4. Take the turtle scute in your mainhand. You should now see that you get one armor point.
5. Place the golden helmet on your head. You should now still have one armor point as expected.
6. Scroll your hotbar so you are no longer holding the turtle scute.
What should happen: You should still have 1 armor point since the helmet is still on your head and should apply the modifier.
What actually happens: You will have 0 armor points since unselecting the turtle scute from your mainhand removed the modifier without checking for other items that should still apply it.
@Greymagic27
How to reproduce:1. Use this command to give your self an item that applies a modifier when held in the mainhand:
/give @p turtle_scute[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"mainhand"}]] 12. Use this command to give your self an item that applies a modifier with the same type and id but when on the players head:
/give @p golden_helmet[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"head"}]] 13. Go into survival or adventure mode
4. Take the turtle scute in your mainhand. You should now see that you get one armor point.
5. Place the golden helmet on your head. You should now still have one armor point as expected.
6. Scroll your hotbar so you are no longer holding the turtle scute.
What should happen: You should still have 1 armor point since the helmet is still on your head and should apply the modifier.
What actually happens: You will have 0 armor points since unselecting the turtle scute from your mainhand removed the modifier without checking for other items that should still apply it.
When having two items with attribute modifiers that have the same id and apply to the same attribute but require different slots to activate, the game starts behaving in unexpected ways.
Equipping both items in there respective slots only applies the modifier once (as expected.)
Removing only one of these items also removes the modifier despite the other item still being equipped in the correct slot and theoretically applying the modifier (unexpected).
I know that it is not intended to have two modifiers with the same id but it could actually be useful if this bug was fixed since it would then be possible to use an "or gate" for modifiers.
You either have to wear this equipment in this slot or this equipment in this other slot to get the modifier but wearing both at the same time doesn't add to your attribute value again. This has good implications for datapack creation in my opinion.@Greymagic27
How to reproduce:1. Use this command to give your self an item that applies a modifier when held in the mainhand:
/give @p turtle_scute[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"mainhand"}]] 12. Use this command to give your self an item that applies a modifier with the same type and id but when on the players head:
/give @p golden_helmet[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"head"}]] 13. Go into survival or adventure mode
4.
Take the turtle scute in your mainhand. You should now see that you get one armor point.5. Place the golden helmet on your head. You should now
stillhave one armor pointas expected.6.
Scroll your hotbar so you are no longer holding the turtle scute.
What should happen: You should still have 1 armor point since the helmet is still on your head and should apply the modifier.What
actuallyhappens: Youwill have0armor pointssinceunselecting the turtle scute from your mainhand removed the modifier without checking for other items that should still apply it.When having two items with attribute modifiers that have the same id and apply to the same attribute but require different slots to activate, the game starts behaving in unexpected ways.
Equipping both items in there respective slots only applies the modifier once (as expected.)
Removing only one of these items also removes the modifier despite the other item still being equipped in the correct slot and theoretically applying the modifier (unexpected).
I know that it is not intended to have two modifiers with the same id but it could actually be useful if this bug was fixed since it would then be possible to use an "or gate" for modifiers.
You either have to wear this equipment in this slot or this equipment in this other slot to get the modifier but wearing both at the same time doesn't add to your attribute value again. This has good implications for datapack creation in my opinion.@Greymagic27
How to reproduce:1. Use this command to give your self an item that applies a modifier when held in the mainhand:
/give @p turtle_scute[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"mainhand"}]] 12. Use this command to give your self an item that applies a modifier with the same type and id but when on the players head:
/give @p golden_helmet[attribute_modifiers=[{id:"armor_id",type:"minecraft:armor",amount:1,operation:"add_value",slot:"head"}]] 13. Go into survival or adventure mode
4. Make sure you are not holding the turtle scute in your mainhand
5. Place the golden helmet on your head. You should now have one armor point.
6. Take the turtle scute in your mainhand. You should still have one armor point as excpected.
7. Scroll your hotbar so you are no longer holding the turtle scute.
What should happen: You should still have 1 armor point since the helmet is still on your head and should apply the modifier.
What actually happens: You will have 0 armor points since unselecting the turtle scute from your mainhand removed the modifier without checking for other items that should still apply it.
The operation type add_multiplied_base behaves as if it was add_multiplied_total.
How to recreate:
1. create a new world in the specified version and add yourself an attribute modifier like this:
"/attribute @s minecraft:armor modifier add armor1 1 add_value"
This will create a new attribute modifier and add it to you. Use the command
"/attribute @s minecraft:armor get" to retrive the calculated attribute value. It should be 1.2. add your self a second attribute modifier like this:
"/attribute @s minecraft:armor modifier add armor2 1 add_multiplied_base"What should happen:
The base of the minecraft:armor attribute is 0.0d by default. This means that when adding a value that was multiplied by this base it should always add 0. Therefore the total value of the attribute should now be 1.0d.What actually happens:
The modifier uses the total value of the attribute which is 1.0d and multiplies it by 1. It then adds the value to the attribute resulting in a total value of 2.0dUse the "/attribute @s minecraft:armor get" command to verify that the attribute value is indeed 2.0d.
The operation type add_multiplied_base behaves as if it was add_multiplied_total.
How to recreate:
1. create a new world in the specified version and add yourself an attribute modifier like this:/attribute @s minecraft:armor modifier add armor1 1 add_valueThis will create a new attribute modifier and add it to you. Use the command
/attribute @s minecraft:armor getto retrive the calculated attribute value. It should be 1.
2. add your self a second attribute modifier like this:
/attribute @s minecraft:armor modifier add armor2 1 add_multiplied_baseWhat should happen:
The base of the minecraft:armor attribute is 0.0d by default. This means that when adding a value that was multiplied by this base it should always add 0. Therefore the total value of the attribute should now be 1.0d.What actually happens:
The modifier uses the total value of the attribute which is 1.0d and multiplies it by 1. It then adds the value to the attribute resulting in a total value of 2.0dUse the "/attribute @s minecraft:armor get" command to verify that the attribute value is indeed 2.0d.
The operation type add_multiplied_base behaves as if it was add_multiplied_total.
How to recreate:
1. create a new world in the specified version and add yourself an attribute modifier like this:/attribute @s minecraft:armor modifier add armor1 1 add_valueThis will create a new attribute modifier and add it to you. Use the command
/attribute @s minecraft:armor getto retrive the calculated attribute value. It should be 1.
2. add your self a second attribute modifier like this:
/attribute @s minecraft:armor modifier add armor2 1 add_multiplied_baseWhat should happen:
The base of the minecraft:armor attribute is 0.0d by default. This means that when adding a value that was multiplied by this base it should always add 0. Thereforethe total value of the attributeshouldnowbe 1.0d.What actually happens:
The modifier uses the total value of the attribute which is 1.0d and multiplies it by 1. It then adds the value to the attribute resulting in a total value of 2.0dUse the "/attribute @s minecraft:armor get" command to verify that the attribute value is indeed 2.0d.
The operation type add_multiplied_base behaves as if it was add_multiplied_total.
How to recreate:
1. create a new world in the specified version and add yourself an attribute modifier like this:/attribute @s minecraft:armor modifier add armor1 1 add_valueThis will create a new attribute modifier and add it to you. Use the command
/attribute @s minecraft:armor getto retrive the calculated attribute value. It should be 1.
2. add your self a second attribute modifier like this:
/attribute @s minecraft:armor modifier add armor2 1 add_multiplied_baseUse the command
/attribute @s minecraft:armor getto retrive the calculated attribute value.
What should happen:
The base of the minecraft:armor attribute is 0.0d by default. This means that when adding a value that was multiplied by this base it should always add 0. Therefore result should be 1.What actually happens:
The modifier uses the total value of the attribute which is 1.0d and multiplies it by 1. It then adds the value to the attribute resulting in a total value of 2.0d. Therefore the result is 2.
this is a bug
@Dhranios
Sorry, i selected the wrong version. Its in Snapshot 23w/33a
@Brain81505
Sorry, i selected the wrong version. Its in Snapshot 23w/33a
Thats intended I guess.
I feel like this should have a higher priority since it is inconsistent with other team related behaviour, confuses new datapack developers, limits datapack capabilities unnessesarily and seems not to hard to fix (people have already proposed solutions).