Before I do that, I need to give an example to contrast with the title and prove that this is a bug: For the attribute "attack_damage": If I want to increase my attack damage by 32768:
/attribute @s minecraft:attack_damage base set 32768
Or: /give @s minecraft:netherite_sword[minecraft:attribute_modifiers={modifiers:[{slot:"mainhand",type:"attack_damage",id:"base_attack_damage",operation:"add_value",amount:32760}]}]
They can all work.
But if the attribute is "entity_interaction_range": If I want to increase my entity interaction range by 32768:
/attribute @s minecraft:entity_interaction_range base set 32768
It worked.
/give @s minecraft:netherite_sword[minecraft:attribute_modifiers={modifiers:[{slot:"mainhand",type:"entity_interaction_range",id:"creative_mode_entity_range",operation:"add_value",amount:32765}]}]
It does not work.
The problem is that some attributes work only with the "/attribute" command, but not in the data component format.
Attachments
Comments 4
@Dhranios I knew that, but the game would fix it automatically, so I didn't think too much about it.
The thing is, as MrMuskle pointed out, using modifier IDs of built-in modifiers is creating a risk for you to create clashes, or get the modifer changed/removed by the code for another reason. The reason here is simple: creative_mode_entity_range is set/removed to the player based on game mode. You're in creative, so the (applied) modifer gets overwritten.
This is not a bug.
creative_mode_entity_rangeis the ID of a built-in attribute modifier. If you specify any other ID, the attribute modifier is functioning as expected. This is unrelated to the data component format.