I propose a new sub command for execute. output. This sub command at the end of the execute arguments will not need any more arguments. All this will do is basically test for the target selector conditions and store the success/fail in the command block (for use with a comparator)
The current dilemma with the loss of /testfor is this..
The execute command requires a command to run at the end or else it will fail. for example:
execute as @a[distance=..4]
alone, this will not work.. You need to have something like
execute as @a[distance=..4] run say blahblah
This will work. The problem is, what if you just want to power a redstone signal with a comparator to light up a lamp when a player is close, for example. This could work for that, but the player would also be spamming blahblah.
You could work around this by setting a fire block surrounded by air like so:
execute as @a[distance=..4] run setblock ~ ~-1 ~ fire
setting the fire would always be successful with the setblock (because the fire will disappear as soon as it's placed), would be non intrusive, and just as discrete as /testfor was, but it is not very practical.
Let's face it.. 1.13's command changes are about making the command system more efficient and practical, not creating new challenges to work around. Not to mention excessive use of this could eventually begin to drag the fps down
My proposed output argument could create an official method to power redstone directly based on target selectors, that would work much more efficiently than the work around, and without the risk of accidentally setting something you don't want to on fire. It would simply work like this:
Welp.. Shucks.. Your right! I was under the impression those needed the <chained command> argument on those, but I guess it is optional. It's not all that clear on the 17w45a page (minecraft.net and the wiki)..
Thank you!
I propose a new sub command for execute. output. This sub command at the end of the execute arguments will not need any more arguments. All this will do is basically test for the target selector conditions and store the success/fail in the command block (for use with a comparator)
The current dilemma with the loss of /testfor is this..
The execute command requires a command to run at the end or else it will fail. for example:
alone, this will not work.. You need to have something like
This will work. The problem is, what if you just want to power a redstone signal with a comparator to light up a lamp when a player is close, for example. This could work for that, but the player would also be spamming blahblah.
You could work around this by setting a fire block surrounded by air like so:
setting the fire would always be successful with the setblock (because the fire will disappear as soon as it's placed), would be non intrusive, and just as discrete as /testfor was, but it is not very practical.
Let's face it.. 1.13's command changes are about making the command system more efficient and practical, not creating new challenges to work around. Not to mention excessive use of this could eventually begin to drag the fps down
My proposed output argument could create an official method to power redstone directly based on target selectors, that would work much more efficiently than the work around, and without the risk of accidentally setting something you don't want to on fire. It would simply work like this:
You can do that with:
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/
Welp.. Shucks.. Your right! I was under the impression those needed the <chained command> argument on those, but I guess it is optional. It's not all that clear on the 17w45a page (minecraft.net and the wiki)..
Thank you!