/testfor cannot totally be replaced by execute! Yeah sure, it's almost a replacement, but what if you need to output to a comparator instead of a command to get a redstone signal which will then power a variety of other blocks. As I understand it now, It's not possible to to have
execute as @p[x=100,y=50,z=100,distance=..25]
with nothing else after that. The command needs <run> and <chained command> I cant use execute as a pure detector outputting redstone signal. I just thought of maybe I could potentially work around this by just setting a block in some random place which then the comparator could measure the success of the setblock, though that would be kind of impractical and you would only be able to output to a redstone signal once like that because the setblock would be trying to place the same block down again and would "Couldn't place block".. However most cases I only want it to activate once and only once anyways, so maybe..
We need a way to output to a comparator just like /testfor did. Maybe they could add another sub command onto execute that's like run except it outputs to a comparator instead. for example:
/execute as @p[x=100,y=50,z=100,distance=..25] output
could work just like /testfor @p[x=100,y=50,z=100,distance=..25]
On a side note, anyone know how to target based on scoreboard values? @a[score_objective=..1] will give you "Unknown Option score_objective"@a[scores={myscoreboardscore=1}]
Edit: I figured out a good work around in case nothing is officially added for this..
/execute as @a[distance=..4] run setblock ~ ~-1 ~ minecraft:fire
the blocks around the placed fire is air. Since the fire the command is placing is disappearing instantly, the command will continue to be successful in placing the fire, so therefore, when the execute conditions are met, the connected comparator will also be lit and vise versa, exactly like how it worked with /testfor, just not as clean or practical..
Yeah, I mostly do agree with you but you know, comparators still detect when the execute command successfully runs. So if there's only one command you need to activate from an execute command, it will do nicely for now and if there's multiple commands you want to execute, just add comparators from the command block.
I've got the same problem but this is just headache inducing - I need a steady-on - not just a pulse - and it needs to go 'off' when the player is out of bounds. Water visibility aside, this is really preventing me from the idea of updating (which I'd really like to do since I'm making an underwater city specifically for the aquatic update)
/testfor cannot totally be replaced by execute! Yeah sure, it's almost a replacement, but what if you need to output to a comparator instead of a command to get a redstone signal which will then power a variety of other blocks. As I understand it now, It's not possible to to have
with nothing else after that. The command needs <run> and <chained command> I cant use execute as a pure detector outputting redstone signal. I just thought of maybe I could potentially work around this by just setting a block in some random place which then the comparator could measure the success of the setblock, though that would be kind of impractical and you would only be able to output to a redstone signal once like that because the setblock would be trying to place the same block down again and would "Couldn't place block".. However most cases I only want it to activate once and only once anyways, so maybe..
We need a way to output to a comparator just like /testfor did. Maybe they could add another sub command onto execute that's like run except it outputs to a comparator instead. for example:
could work just like /testfor @p[x=100,y=50,z=100,distance=..25]
On a side note, anyone know how to target based on scoreboard values? @a[score_objective=..1] will give you "Unknown Option score_objective"@a[scores={myscoreboardscore=1}]Edit: I figured out a good work around in case nothing is officially added for this..
the blocks around the placed fire is air. Since the fire the command is placing is disappearing instantly, the command will continue to be successful in placing the fire, so therefore, when the execute conditions are met, the connected comparator will also be lit and vise versa, exactly like how it worked with /testfor, just not as clean or practical..
Yeah, I mostly do agree with you but you know, comparators still detect when the execute command successfully runs. So if there's only one command you need to activate from an execute command, it will do nicely for now and if there's multiple commands you want to execute, just add comparators from the command block.
I've got the same problem but this is just headache inducing - I need a steady-on - not just a pulse - and it needs to go 'off' when the player is out of bounds. Water visibility aside, this is really preventing me from the idea of updating (which I'd really like to do since I'm making an underwater city specifically for the aquatic update)
I agree, but i think they removed it due to performance issues. So i'll stick with the new update, so i can familiarize myself to it.