Minecraft Forums

Quote from TNTQc»

But in my case, it doesn't matter, since my setblock command sets a redstone block that triggers a fill clock to another system.

🎓

Indeed! At the risk of sounding pedantic , in CS we say such operation is idempotent: "[it] can be applied multiple times without changing the result beyond the initial application"

Thank you for having posted the solution!

Amusingly enough, I was bitten myself by the `as`/`at` clause of the execute command yesterday. And despite that, I didn't pinpoint a similar issue in your command. I definitively need a lot more practice with Minecraft commands!

Actually, in your case, I suspect the following commands would do the trick too:

execute as @a[x=-160,y=75,z=164,distance=..1] run setblock -153 75 165 redstone_block
execute if entity @a[x=-160,y=75,z=164,distance=..1] run setblock -153 75 165 redstone_block

According to my (very recent) knowledge in that matter, I would favor the `if entity` version: I think the `as`/`at` versions may be less efficient, since they may potentially run the `setblock` command several times, once for each matching entity. Or am I wrong?

I'm new to Minecraft commands, so take my comment with a grain of salt. However, you are giving a diamond unless the `test` and `house` score values are identical. Since they both hold the value 3 you don't give the diamond. Shouldn't you use `if` instead of `unless`?

/execute if score @p test = @p house run give @p minecraft:diamond

I'm playing with the /data command for a while in MC14.2, but I can't find a way to access items by index when a NBT path selector matches several items.

Let's say for example I want to know which slot of a chest containing pumpkins. I can write that:

/data get block x y z Items[{id:"minecraft:pumpkin"}].Slot

However, it will work only if pumpkins are found in one slot. If the chest has several slots filled with pumpkins, data get produces the error "only one NBT value accepted". So, is there a way to select only the first item (or at least only one item, being the first or not) matching an NBT path?

FWIW, I tried several variations with no luck:

Items[{id:"minecraft:pumpkin"}][0].Slot
Items[{id:"minecraft:pumpkin"}].[0].Slot
Items[{id:"minecraft:pumpkin"},0].Slot

IMO, if you just have a bunch of small isolated cave systems there is no fun in caving; I want to be able to explore entirely underground, not have to look for new caves every hour or so

I agree. An interconnected cave system would be more fun to explore than trying to find isolated caves by digging at random. Especially with the addition of rare/specialized chambers, it could give the impression of a rich underground ecosystem.

Thanks for having clarified that Toakralich.

So your idea would be more like in the second example below:
(in both cases, the "pure white" area is the Limbo--a unique biome generated at the first portal position and holding the world unique the Limbo's fortress)

[...] as though RSDa pointed at the block opposite the RS-torch even though it is shown as turning to make the connection.

I remember having read somewhere the Redstone path display was a client-side thing and wasn't always reflecting the "reality" of powered blocks. It didn't really make sense for me at that time. But the use case displayed in the OP is a perfect example of such behavior.

Thanks a lot, Scots for making that clear!

According to the wiki:

Illager patrols spawn around 200 blocks away from villages in plains, taiga,desert, savanna and snowy tundra biomes, as well as their variants on sand and grass block, or in snow with a block light level of 0–8 and a sky light level of 10–15.

Sorry, @Sharfpang, I've missed your previous comment. Indeed, you're right: by doing a couple more tests, there is something related to slab I can't explain either.

My guess would be in the "slab configuration", the block next to the redstone wire angle is strongly powered. Whereas in the "full block" configuration it is not. But why? And how? That's beyond my knowledge.

Regarding the top-left example, I suspect it has something to do with known quirk in the redstone engine which only update blocks up to a given distance in response to a block change.

When trying to reproduce it, I noticed some block are not deactivated as expected:

Notice how the top-most activated block should be deactivated by the placement of the second redstone torch. But it was not updated because it is at 3 blocks (taxy cab distance) from the torch.

From https://minecraft.gamepedia.com/Redstone_Dust#Placement

When redstone wire is reconfigured after placement, it will not update
other redstone components around it of the change unless that
reconfiguration also includes a change in power level or another
component provides an update. This can create situations where a
mechanism component remains activated when it shouldn't, or vice versa,
until it receives an update from something else – a "feature" of
redstone wire that can be exploited to create a kind of block update detector.

At least, this is how I understand it. But maybe someone more experienced with these things might explain it better.

I did some testing and the game always reverts the value of the OwnerUUID NBT tag to its original value. I also noticed that if you set the value to something random such as "text", the game will revert the value back to the UUID of the player again but the cat won't have a collar anymore, you can't control it and it will follow you around like it is tamed. Maybe there's another tag that has to be reset in order for this to work or maybe it's not even possible because the UUID is stored in memory or something.

Quote from FrostSylvium»

Would it be possible to have mob heads move in a specific direction, for a example is it possible to make a creeper skull fly towards the player and go right by them? Also would it be possible to detect when the creeper skull passed the player?

In 1.14.4 sorry if i didn't I made it hard to understand what i'm trying saying.

You can equip an invisible armor stand with the creeper head and move the armor stand past the player.

To move the armor stand towards the player, you need these:

/execute as @e[tag=creeperStand] at @s run tp @s ~ ~ ~ facing entity @p

^ run only once (when activated) and the armor stand will face the player. Then:

/execute as @e[tag=creeperStand] at @s run tp @s ^ ^ ^0.5

to teleport the armor stand in that direction. To detect when the armor stand past the player, use this:

/execute as @e[tag=creeperStand] at @s if entity @a[distance=..1] run ...

you might need to tweak the distance

Quote from s_leroux»

Thank you for having posted the solution!

Amusingly enough, I was bitten myself by the `as`/`at` clause of the execute command yesterday. And despite that, I didn't pinpoint a similar issue in your command. I definitively need a lot more practice with Minecraft commands!

Actually, in your case, I suspect the following commands would do the trick too:

execute as @a[x=-160,y=75,z=164,distance=..1] run setblock -153 75 165 redstone_block
execute if entity @a[x=-160,y=75,z=164,distance=..1] run setblock -153 75 165 redstone_block

According to my (very recent) knowledge in that matter, I would favor the `if entity` version: I think the `as`/`at` versions may be less efficient, since they may potentially run the `setblock` command several times, once for each matching entity. Or am I wrong?

I don't know about this.
But in my case, it doesn't matter, since my setblock command sets a redstone block that triggers a fill clock to another system.
I will keep that in mind though for other uses. Thanks for sharing this!

Quote from s_leroux»

Thank you for having taken the time to test that.

On my side, I noticed I can have an output signal strength matching the entity count if I use "execute as" and if the execute statement actually runs a command:

--ok--
execute as @e[type=villager,distance=..20] run me ""
execute as @e[type=villager,distance=..20] run execute if entity @s  
 
--not ok--
execute if @e[type=villager,distance=..20]
execute as @e[type=villager,distance=..20]
execute as @e[type=villager,distance=..20] run

I suspect the output value is the sum of the output values of the commands: if you run for 5 entities a command returning 1, the result is 1+1+1+1+1 and that is what reflects the output signal strength. It is somewhat confirmed by the contrived command below:

[/p]
[p]execute as @e[type=villager,distance=..20] run execute if entity @s[tag=T][/p]
[p]

Here, the nested `execute` command is run once for each villager in the range. And that nested command will return either 0 or 1 depending if the villager is tagged. In my tests, the result value of the outer `execute` command is the number of tagged villagers.

It's been a while since I've used a redstone signal as a command block output so I didn't know this worked that way. Thanks for the info

Quote from s_leroux»

... and I suspect you can't detect both water and waterloged blocks in only one command. Or can you?

You can create a "block group" by specifying block ids into a .json file and then you can use the file as a selector. This feature is a part of "data packs" and can save you a lot of time in some projects.

example:

/execute if block ~ ~ ~ #megacrafter10:waterlogged_blocks

"waterlogged_blocks" is the .json file with the ids and "#megacrafter10:" is a data pack namespace where the file is located. This allows you to test for multiple block types at once instead of writing multiple detection commands for each block type.

This is what one of those group files look like:

{
	"values":[
		
		"oak_log",
		"cobblestone",
		"sponge"
	]
}

I have a tutorial on data packs here if you want to learn how to create your own: https://datapackcenter.com/projects/data-pack-basics.71/

the command above will only detect the blocks but you can also add criteria so the command detects those blocks only if they are waterlogged:

/execute if block ~ ~ ~ #megacrafter10:waterlogged_blocks[waterlogged=true]

now the "waterlogged" criteria will apply to every block type inside the file and test if that block type is waterlogged.

I'm not sure if you can add water inside of the file because water doesn't have a "waterlogged" propertie so it might not work when you add the criteria. It's best to use a separate command for water detection.

Quote from s_leroux»

`at` not `as`. That was so simple!

In my particular case, is there any difference in using `execute as ... at @s` (command 1 below) instead of the simpler `execute at ...` (command 2 below)? Or is this simply a good habit?

-1-
/execute as @e[type=minecraft:armor_stand,distance=..20,tag=Labyrinth] at @s run summon minecraft:item ~ ~ ~ {Item:{id:"minecraft:golden_apple",Count:1}}

-2-
/execute at @e[type=minecraft:armor_stand,distance=..20,tag=Labyrinth] run summon minecraft:item ~ ~ ~ {Item:{id:"minecraft:golden_apple",Count:1},Tags:["Labyrinth"]}

I like to use "as ... at @s" because that gives me a reference to that entity if I need it later on in the command but you can use "execute at ..." in this example because you only need to get the position of the armor stand and not the armor stand itself. It's mostly a matter of personal preference.

I don't know the answer to that one as I noticed the redstone signal strength did not match my entity count either.

Quote from s_leroux»

Would that work with waterlogged blocks?

No. You can detect waterlogged blocks like this:

/execute if block ~ ~ ~ oak_slab[watrlogged=true] run ...

I suck at NBT tags and stuff like that. I need to write a command that will teleport me to the closest item entity, and that item needs to be a melon slice. I can't use my world right now until I get that command or else my precious melon will despawn. Help?

Ouf!!!

The previous command that wasn't functioning was:

execute @a[x=-160,y=75,z=164,distance=..1] ~ ~ ~ run setblock -153 75 165 redstone_block

I just find out the correct syntax for this command. Here it is:

execute at @a[x=-160,y=75,z=164,distance=..1] run setblock -153 75 165 redstone_block

The "at" was important due to executing the command at all players that are positioned on the coordinates (-160 75 164).

And also, I removed the ~ ~ ~ position after the target selector and it worked!

Hopefully, the syntax will remain the same in next minecraft versions... All those changes are troubling my commands!