Basically the issue is that the only way to identify a mob with a certain DataTag is with /testfor, but that doesn't allow you to do anything to that particular mob, which is what the /execute command is supposed to allow you to do.
This would enable mapmakers to do special things with custom enemies, like make standing in the proximity of weaponless Zombie Pigmen poison you, but Zombie Pigmen holding weapons not, and also things like making enemies roar and buff themselves upon seeing you and beginning to run after you.
Rollback Post to RevisionRollBack
Truly he is my rock and my salvation; he is my fortress, I will not be shaken. ~Psalms 62:6
Basically the issue is that the only way to identify a mob with a certain DataTag is with /testfor, but that doesn't allow you to do anything to that particular mob, which is what the /execute command is supposed to allow you to do.
This would enable mapmakers to do special things with custom enemies, like make standing in the proximity of weaponless Zombie Pigmen poison you, but Zombie Pigmen holding weapons not, and also things like making enemies roar and buff themselves upon seeing you and beginning to run after you.
This would, for the most part, solve the extreme overlying issue with this "map maker" update, in which most of the features are not feasible to use in a multiplayer environment. The list of introduced capabilities is phenomenal if this were implemented.
Any command would be usable, and doesn't necessarily have to target the found player, but can easily be set to. For example:
Applying the poison effect to all players around the exact one who happens to be asleep:
(Assuming tag-types will have to be labeled per usual):
Very simple and very effective. You can also use this to apply effects to players wearing specific armor, a highly sought-after feature that found its way into 1.8, but only for singleplayer:
Of course, this isn't limited to just player interaction. But there's a huge number of possibilities for implementing this through the /execute command. It would be the perfect opportunity to, well, perfect this "map maker" update. Hopefully Mojang takes it!
Basically the issue is that the only way to identify a mob with a certain DataTag is with /testfor, but that doesn't allow you to do anything to that particular mob, which is what the /execute command is supposed to allow you to do.
This would enable mapmakers to do special things with custom enemies, like make standing in the proximity of weaponless Zombie Pigmen poison you, but Zombie Pigmen holding weapons not, and also things like making enemies roar and buff themselves upon seeing you and beginning to run after you.
This is exactly what I was trying to convey in my thread! I wholeheartedly support!
Searge has introduced dataTag support into the /scoreboard command, which will essentially be the stepping stone for all commands that don't have dataTag support (excluding entities that aren't the player). Command:
/scoreboard players set <player> <objective> <value> {dataTags}
So essentially the suggested feature has been halfway introduced as a side-effect of adding dataTag support to the /scoreboard command. Hopefully the /scoreboard command can modify non-player scores sometime soon to take full advantage of this.
I agree with this post, ALTHOUGH, you can already select an entity etc by using scoreboard values to identify them. The scoreboard function currently allows for datatags. So you can make them have a specific score and then select them with @e[score_name_min=1,score_name=1] It's an extra step but it'd work ;D
The Meaning of Life, the Universe, and Everything.
Join Date:
7/23/2011
Posts:
44
Minecraft:
dslink2009
Member Details
EVERYBODY
I think I found a way! (Though it's limited quite a bit, but its limits can be fixed by repeating this process with multiple command blocks or using @e without the type tag)
Use /testfor to test for the entity with the data tags
testfor command block = T, C=Comparator facing E, E=Execute Command Block
TCE
The execute command block will execute the entity (of your choice, of course.) that succeeded the /testfor command block and do what you want it to.
EVERYBODY
I think I found a way! (Though it's limited quite a bit, but its limits can be fixed by repeating this process with multiple command blocks or using @e without the type tag)
Use /testfor to test for the entity with the data tags
testfor command block = T, C=Comparator facing E, E=Execute Command Block
TCE
The execute command block will execute the entity (of your choice, of course.) that succeeded the /testfor command block and do what you want it to.
Still wouldn't work well, as the testfor command guarantees that there is a entity with the datatag, but there is no way for the execute command block to target that specific entity with the datatag. Of course, you could assign the execute command block with [c=-1] which targets the newest entity loaded, but if you have an execute chain (/execute @p ~ ~ ~ execute @e[r=2] ~ ~ ~ [command]), which tests if an entity is close to another, and then another entity spawns during the testing, it will fail. However, ArmSwinger's post will work in any situation, if you don't mind having scoreboards.
This is a great feature, my only concern is that by adding a new argument, you are essentially breaking any pre-existing command blocks with fewer arguments. SO, adding {DataTag} after the selector would indeed break any commands that are formatted like so: /execute @e[type=Zombie] ~ ~ ~ <command>. Maybe a way around this would be to have the DataTag within the brackets of the selector (so like /execute @e[type=Zombie,{Health:20s}] ~ ~ ~ <command>. This way, we can add datatags w/o breaking pre-existing command blocks.
I support this, as it allows you to fine tune creations more, and skip the step of using scoreboard.
Rollback Post to RevisionRollBack
Also take a look at this guide if you are requesting builders for a server/project.
Please note, if I deny a suggestion because it is already possible, then I mean it is already possible withing 10 command blocks (That do not spawn other command blocks) or up to 5 creations (Command blocks that spawn other command blocks) to make your suggestion.
If I critique your suggestion I am not hating on you. Learn the difference.
Basically the issue is that the only way to identify a mob with a certain DataTag is with /testfor, but that doesn't allow you to do anything to that particular mob, which is what the /execute command is supposed to allow you to do.
This would enable mapmakers to do special things with custom enemies, like make standing in the proximity of weaponless Zombie Pigmen poison you, but Zombie Pigmen holding weapons not, and also things like making enemies roar and buff themselves upon seeing you and beginning to run after you.
Support!
Support!
Apparently this is also useful for selecting specific items.
This would, for the most part, solve the extreme overlying issue with this "map maker" update, in which most of the features are not feasible to use in a multiplayer environment. The list of introduced capabilities is phenomenal if this were implemented.
Any command would be usable, and doesn't necessarily have to target the found player, but can easily be set to. For example:
Applying the poison effect to all players around the exact one who happens to be asleep:
(Assuming tag-types will have to be labeled per usual):
Or poisoning just the player who is sleeping:
Very simple and very effective. You can also use this to apply effects to players wearing specific armor, a highly sought-after feature that found its way into 1.8, but only for singleplayer:
Essentially any matching tag for players, other entities, and items:
http://minecraft.gamepedia.com/Player.dat_format
http://minecraft.gamepedia.com/Chunk_format
Another example, which will warn players if a chicken jockey is near them:
Using the /playsound command to all players who specifically have no hunger left (well, sounds more like a powerful beast, but just an example):
Of course, this isn't limited to just player interaction. But there's a huge number of possibilities for implementing this through the /execute command. It would be the perfect opportunity to, well, perfect this "map maker" update. Hopefully Mojang takes it!
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Searge has introduced dataTag support into the /scoreboard command, which will essentially be the stepping stone for all commands that don't have dataTag support (excluding entities that aren't the player). Command:
Confirmation tweets:
https://twitter.com/SeargeDP/status/439331703249960960
https://twitter.com/SeargeDP/status/439344370710740993
So essentially the suggested feature has been halfway introduced as a side-effect of adding dataTag support to the /scoreboard command. Hopefully the /scoreboard command can modify non-player scores sometime soon to take full advantage of this.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
And of course I didn't just post to up this thread.
*Edit: In the snapshot version.
This needs to be implemented! Full Support!
I think I found a way! (Though it's limited quite a bit, but its limits can be fixed by repeating this process with multiple command blocks or using @e without the type tag)
Use /testfor to test for the entity with the data tags
testfor command block = T, C=Comparator facing E, E=Execute Command Block
TCE
The execute command block will execute the entity (of your choice, of course.) that succeeded the /testfor command block and do what you want it to.
Still wouldn't work well, as the testfor command guarantees that there is a entity with the datatag, but there is no way for the execute command block to target that specific entity with the datatag. Of course, you could assign the execute command block with [c=-1] which targets the newest entity loaded, but if you have an execute chain (/execute @p ~ ~ ~ execute @e[r=2] ~ ~ ~ [command]), which tests if an entity is close to another, and then another entity spawns during the testing, it will fail. However, ArmSwinger's post will work in any situation, if you don't mind having scoreboards.
Support on the topic!
cheers ~
Hey, this is a way to execute commands for certain items using command blocks! You put this system on a clock for ever repeating command executes.
/scoreboard objectives add ItemExecute dummy
/scoreboard players set @e[type=Item] ItemExecute 1 {Age:0s,Item:{id:minecraft:<ITEM HERE>}}
/execute @e[score_ItemExecute=1,score_ItemExecute_min=1] ~ ~ ~ <COMMAND(S)>
If you want the commands to be ran only once, add a command block to the clock with this command.
/kill @e[score_ItemExecute=1,score_ItemExecute_min=1]
cheers ~
"the datatag does not match for db81b101-cc12-4ecf-9220-ec4b66f37012"
Also take a look at this guide if you are requesting builders for a server/project.
Please note, if I deny a suggestion because it is already possible, then I mean it is already possible withing 10 command blocks (That do not spawn other command blocks) or up to 5 creations (Command blocks that spawn other command blocks) to make your suggestion.
If I critique your suggestion I am not hating on you. Learn the difference.