Minecraft floor crafting deletes previous results

minecraft-commandsminecraft-java-edition

I want to make a command block system that allow players to craft custom heads using a regular player head and a specific item by throwing these items on the floor. The system works fine, except for one thing. When i craft a custom head and leave it on the ground and craft another head the same way, the first head gets killed by the command blocks. This is ofcourse undesirable, therefore I would like to ask this community for some help.

Before anyone asks: all command blocks are always active, the first command block is in repeat mode and the rest is in chain mode. The last two command blocks are conditional.
These are the commands in the order of the command blocks:

1) scoreboard players tag @e[type=Item,tag=!baseSkull] add baseSkull {Item:{id:"minecraft:skull",Damage:3s,Count:1b}}
2) scoreboard players tag @e[type=Item,tag=!D_InventorItem] add D_InventorItem {Item:{id:"minecraft:red_mushroom",Count:1b}}
3) /execute @e[tag=baseSkull] ~ ~ ~ execute @e[tag=D_InventorItem,r=1] ~ ~ ~ execute @e[type=Arrow,r=1,c=1] ~ ~ ~ summon Item ~ ~ ~ {Item:{id:"minecraft:skull",Damage:3s,Count:1b,tag:{SkullOwner:"D_Inventor"}},Tags:["D_InventorSkull"]}
4) /execute @e[tag=D_InventorSkull] ~ ~ ~ kill @e[tag=baseSkull,r=1]
5) /execute @e[tag=D_InventorSkull] ~ ~ ~ kill @e[tag=D_InventorItem,r=1]

Clarification:

1) Tag all player heads with the baseSkull tag if they don't have it already.

2) Tag all red mushroom items with the D_InventorItem tag if they don't have it already. The red mushroom is therefore the item to get my head.

3) summon a player skull with the D_Inventor skin at the location of the items. This skull spawns with the D_InventorSkull tag already present. Notice that this command only works if there is an Arrow entity in the area, therefore you have to shoot the items with a bow to complete the crafting.

4 + 5) delete all the ingredients around the custom player head.

I know where this goes wrong. The custom player head has the same id and damage value as a regular player head. When a custom player head spawns, it is tagged with the baseSkull tag in the next cycle, so it has both the D_InventorSkull tag and the baseSkull tag. When I craft a new custom head, the fourth command block executes at all the D_InventorSkull items and deletes all the baseSkull items around it. Since the first skull has both the baseSkull and the D_InventorSkull tag, it deletes itself.
When I pick up the custom head and then throw it on the ground, it loses its D_InventorSkull tag and then the custom head doesn't get deleted when I craft a new one.

The question is: How do I solve this?
My first solution was to check for each playerskull if it has no tags and only then tag it with the baseSkull tag. The command would the look like this:

scoreboard players tag @e[type=Item,tag=!baseSkull] add baseSkull {Item:{id:"minecraft:skull",Damage:3s,Count:1b},Tags:[]}

Unfortunately this doesn't seem to work. When I throw a regular player skull on the ground, the command block gives an error saying that the DataTag doesn't match. This error doesn't occur when I don't use the extra Tags:[] DataTag.

so… What would be the correct way to prevent previous skulls from deleting themselves when I craft a new skull?

I play in the latest release(1.12.1).

Best Answer

This took me a while, I even manually went through all the steps (which is my last hope against bugs), but then I got it:

You just need to add ,tag=!D_InventorSkull to the selector in the first command.
That way the skinned head doesn't get the baseSkull tag and the first execute in the third command doesn't trigger a second time.

scoreboard players tag @e[type=Item,tag=!baseSkull,tag=!D_InventorSkull] add baseSkull {Item:{id:"minecraft:skull",Damage:3s,Count:1b}}

Also, are you sure you don't want to kill the arrow, too? In that case you should add a sixth command:

execute @e[tag=D_InventorSkull] ~ ~ ~ kill @e[type=arrow,r=1]

In 1.13:

execute as @e[tag=D_InventorSkull] at @s run kill @e[type=arrow,distance=..1]

Related Solutions

Minecraft – Detect a dropper with items in it without /testfor

The detect function of /execute does not accept NBT data, only an ID and Damage value.

You will instead need to use /testforblock, and if needing multiplayer-friendliness, mixing it with CommandStats.

Prerequisites:

Objective to hold the CommandStats value.

/scoreboard objectives add CraftSuccess dummy

Applying the AffectedBlocks trigger to players, which will set the player's score based on the success of commands that specifically affect blocks, such as /testforblock. This may need to run on a clock in the event new players can join at any time.

/stats entity @a set AffectedBlocks @a[c=1] CraftSuccess

In order for CommandStats to modify a target's score, that target must be tracked on the scoreboard prior. This may also need to run on a clock for the same reason as before.

/scoreboard players add @a CraftSuccess 0

Detection:

The following must be run in numerical order.

Cause players to run the necessary /testforblock command.

/execute @a ~ ~ ~ /testforblock ~ ~-1 ~ minecraft:dropper 1 {Items:[{id:"minecraft:blaze_rod",Slot:1b,Count:1b,Damage:0s},{id:"minecraft:blaze_rod",Slot:4b,Count:1b},{id:"minecraft:stick",Slot:7b,Count:1b}]}

As a result, the executing player will have their own "CraftSuccess" score set equal to the number of blocks found by the /testforblock command. If the command failed, their score is set to 0. If the command succeeded, their score is set to 1. You'd then target players based on their score.
```
/scoreboard players set @a[score_CraftSuccess_min=1] LSC 1
```

As a side-note, you should never mix @a as an executor and @p as the nested command's target if you're intended to target the same player. While @a can target dead players, @p cannot. That means that while the executor can run /execute while they're dead, they will not target themselves and instead target the nearest-living player. This can severely hurt accuracy and possibly break a target-sensitive mechanism.

The solution is to use the same selector when needed. For dead player targeting, you'd use @a as the executor with @a[c=1] as the nested selector:

/execute @a ~ ~ ~ /say @a[c=1]

For living-only players, you'd use @e[type=Player] with @p:

/execute @e[type=Player] ~ ~ ~ /say @p

It is also for this reason that CommandStat targets should use @a[c=1] when working with players, as this ensures there will not be an unintended target having their score modified.

Minecraft – player head detection problem

The SkullOwner string is replaced with a SkullOwner compound. You cannot the string for detection as a result.

You're detecting a root item tag called "damage" declared as an integer, which doesn't exist. The correct tag is "Damage" (as tags are case-sensitive) and the datatype is short.

Enchantment IDs and levels are normally stored as a short, and item data you provide is typically not auto-corrected and will remain integers as you've defined. You should declare them as short instead, so that any detection method you're using to detect enchantments will work for every method of application.

And finally, you have also closed the tag compound, and then opened an unnamed compound after it, breaking syntax.

What you should do instead is assign a custom tag to the item being provided, and then detect that item based solely on the custom tag. That way you don't have to fiddle with detecting every single tag on the item, which will break if you need to change any of that data.

For example, the following provides an item with a custom byte tag called SKULL with a value of 1.

/give @p minecraft:skull 1 3 {SKULL:1b,SkullOwner:"xXElite_PythonXx",Unbreakable:1b,display:{Lore:["_____"]},ench:[{id:0s,lvl:31073s},{id:7s,lvl:31073s},{id:4s,lvl:31073s},{id:3s,lvl:31073s}]}

And the following labels the player if they have it in their inventory:

/scoreboard players tag xXElite_PythonXx add skull {Inventory:[{Slot:103b,tag:{SKULL:1b}}]}

Then you can go back and modify the /give command as you'd like without changing /scoreboard (provided you do not modify SKULL).

Best Answer

Related Solutions

Minecraft – Detect a dropper with items in it without /testfor

Minecraft – player head detection problem

Related Topic