Minecraft Forums

Quote from romanorose76»

BÄÄÄM got my first own datapack ;-) THANK U

now my LAST question..

with that singele command was no problem with your tutorial

but dont understand how if a chain of commands with condition

1 /execute as @e[type=snowball] at @s run tag @e[type=zombie,limit=1,distance=..2] add tagged

repeat unconditon always active

2 /execute as @e[tag=tagged] at @s run summon item ~ ~ ~ {Item:{id:"minecraft:zombie_spawn_egg",Count:1}}

chain condition always active

3 /kill @e[tag=tagged]

chain condition always active

This feature is currently unsupported with data packs (I have suggested to implement them here: https://www.minecraftforum.net/forums/minecraft-java-edition/suggestions/2940648-add-conditional-commands-for-functions). One solution would be to use the execute store success command to store whether a command succeeded in a scoreboard or NBT. You ould then append a condition to your consecutive commands testing if the score (or NBT) matches 1 for success or 0 for failure. A simpler solution (although more confusing depending on the commands you use) would simply be to append the desired condition to each consecutive command using the execute if command.

Command syntax was changed A LOT in 1.13, so most of the commands in 1.12 probably won't work.

If you configure your launcher to open the game log when running minecraft, it may have some command block feedback inside. I can't guarantee it'll be there or that it'll help, but it's worth looking.

Make sure you put the position on the bottom block of the door and not the top.

The command block will automatically do that for you. It responds to any redstone signal you apply to the block.

You should use a "repeating always active needs redstone" command block. It will check for a redstone signal every tick and run the command if it finds that signal. When the redstone block is there, the command will be enabled. When it isn't, the command will be disabled.

/gamerule commandFeedback true

Quote from Ptolemy2002»

You need to use "execute if entity @p[distance=..3]". The key is the "..". Without that, the command will only execute if there is a player that is exactly 3 blocks away, which is virtually impossible. The ".." before the "3" means "less than or equal to", which should fix your problem. If you use, ".." after the "3", it will mean "greater than or equal to".

...

You can also use this to define number ranges. For example "2..3" means "in between 2 and 3", and it is inclusive on both sides.


A range such as "y..x" would mean "in between y and x", instead of "y is greater than x". You are defining a number range, not a condition.


Technically, if you didn't specify a number on both sides, Minecraft would assume the highest or lowest number possible. If we represent the maximum number with "infinity", "..3" would be equal to "-infinity..3" and "3.." would be equal to "3..infinity". Minecraft allows you to omit one side of the range for convenience.

That's from when I helped someone else with the same problem.

Quote from Megacrafter107»

There is just one problem. You can't use commands to edit the ender chest's data (I'm 90% sure but prove me wrong)

I thought you could with the replaceitem command.

It won't be an item, but you could override the ender-chest functionality using a command that replaces a slot.

You could create an item in the ender-chest for every waypoint entity there is in the world, and then teleport the player whenever that item goes away. You could then clear the player of the item and then put it back in the ender-chest afterward.

This will make it so that the player can open the chest and click one of the items to teleport to the waypoint.

The problem is that this would require at least 2 commands per slot of the ender-chest (one to check for the item, and one to put the item back), as well as quite a few extra (some to create the items, some to teleport the entity, and some to clear the player of the items).

/data modify entity @e[type=sheep,sort=nearest,limit=1] Color set value (value)b

Will change the color of the nearest sheep (the "b" is not a typo, and you must have it). As for the value, that is the numerical value of the color you want the sheep to be.

White is 0

Orange is 1

Magenta is 2

Light blue is 3

Yellow is 4

Lime is 5

Pink is 6

Gray is 7

Light Gray is 8

Cyan is 9

Purple is 10

Blue is 11

Brown is 12

Green is 13

Red is 14

Black is 15

I would like to develop an algorithm that can seemingly store an entity and then respawn it at the player's will. The context is that I have a store where one can buy "vehicles" as entities. I want the player to be able to despawn and respawn the vehicle at will using a written book. The entity needs to be unique to each player, as this is on a multiplayer realm.

I thought of storing basic properties of the vehicle inside the NBT of the player, but I cannot edit player NBT data. I thought of storing data for all players inside some shared entity, but I would not knowhow to access the data for any arbitrary player. I thought of storing the NBT inside the book itself, but I'm not sure if one can merge item data with entity data that way. Are there any other ways I could achieve my goal?

Quote from erictom333»

I think raids should be pillager only, as illagers and pillagers should be kept seperate.

The illagers add some level of difficulty to raids, especially with the vexes that the evoker spawns. They also look a lot like pillagers. I can see why they were included in the raids.

Quote from FirEmerald»

Actually, the framework for rotating blocks is already in place, I assume used in the structure block, all they need is a way to use it outside of the structure block. Like some sort of 'rotator' block that rotates a connected block or blocks when powered.

They also do this with the debug stick. It isn't very hard to rotate blocks at all.

This would be a very good thing to do, as bats would be a little more useful than just an annoyance, and potions of blindness would finally be brewable.