14

I've asked this question towards a developer for Minecraft and I thought I'd ask here too since they might not see the question.

How do I select all but two types of entities in Minecraft?

For example, something like: /say @e[type=![Player,Item],r=50] (to clarify I also tried type=Item,Player, type=Item,type=Player etc)

Should select any entity that does not match players or items, so things like Creepers, Ghasts, XPOrbs, PrimedTNT and so on within a radius of 50 blocks and print them to the chat.

Instead it ignores one of the flags, and works with the other instead.

  • I don't think you can, unfortunately. – MBraedley May 3 '14 at 22:41
  • I've asked Dinnerbone about it however it'll be awhile before he even replies I'm sure if he even does. But if anyone else can find a way to do it please share it thanks. – Codingale May 3 '14 at 23:51
  • @MBraedley it is, idtownie's answer seems as if it'd work but I haven't tested it. – Codingale Aug 4 '14 at 19:19
  • @Codingale The edit the the question you made a few days ago completely changed the nature of the question and invalidated most of the answers. This is not usually a good idea. – pppery Jul 6 at 21:30
  • @pppery I've rolled back the edit as it makes sense for anyone looking for this exact sample, old me was tired and didn't think about it invalidating existing answers and possibly confusing future readers when the previous answers are not working as intended. Thanks for the heads up. – Codingale Sep 3 at 10:02
17

First, create a dummy scoreboard objective:

/scoreboard objectives add selectMe dummy

Then, on a fast redstone clock, give all entities a selectMe score of 1:

/scoreboard players set @e selectMe 1

Give all players and items a selectMe score of 0 with these two command blocks:

/scoreboard players set @e[type=Player] selectMe 0

/scoreboard players set @e[type=Item] selectMe 0

Now, you can select them by targeting all entities within a 50 block radius that have a selectMe score of 1:

/say @e[score_selectMe_min=1,r=50]

Hope this helped! :)

  • 6
    Things like this make me REALLY want to learn more about scoreboards. – TMH Aug 1 '14 at 11:58
  • I didn't think about that. That's amazing, but still I feel as if they should add a way to pump in an array to the selectors. – Codingale Aug 4 '14 at 19:16
  • Or just add a comma Example. /say @e[type=!Player,!Item,r=50] – user97203 Dec 31 '14 at 18:37
  • @user97203 Does this actually work? Have you tested it? – MBraedley Dec 31 '14 at 19:50
  • 1
    @Codingale that is because as written, Minecraft sees that as another target selector argument (because it's comma-separated). Since !Item is obviously not a valid argument, it is ignored completely. – MrLemon Jul 31 '15 at 10:10
4

As of Minecraft 1.9, scoreboard tags are a better fit for this than setting up an objective and assigning a score.

It's as easy as setting up repeat command blocks (or a repeat/chain line) and putting:

/scoreboard players tag @e[type=Player] add playerOrItem
/scoreboard players tag @e[type=Item] add playerOrItem

You can then use @e[tag=playerOrItem] and @e[tag=!playerOrItem] to select every entity that is and is not a player or item, respectively.


The benefits of using tags over scoreboard objectives are:

  1. No need to set up an objective.
  2. They are initialized as empty by default. I.e. @a[tag=!banana] works on every player by default, unlike @a[score_banana=0]. The means you only need to affect the targets you actually want to affect.
  3. Tags are also stored in an entities NBT data, in the Tags tag.
1

As of Minecraft 1.13 (Java Edition) you can now use multiple selectors to target entities.

From the Minecraft Wiki:

tag=foo,tag=bar,tag=!baz matches someone with foo, bar and not baz.

type=!cow,type=!chicken matches something that isn't a cow and isn't a chicken.

type=cow,type=chicken isn't allowed, because something cannot both be a cow and chicken.

For versions prior to 1.13

You can use either idtownie or this from user113642 the latter being untested.

0

The most efficient way to select two specific entities at once with the "type" argument is to put two "type" arguments next to each other.

Ex.

@e[type=Player,type=Villager]

Targets only Players and Villagers.

Ex.

@r[type=Player,type=Villager]

Targets only Players and Villagers. However, this target selector picks a random entity within the specified parameters of the argument, whereas the previous selector picked every entity that met the argument's parameters.

This could go on indefinitely until you have selected every type of entity in Minecraft (However, that would be a complete waste of time because the same action can be done with @e).

Please correct any mistakes I may have made.

For more info on target selector arguments please visit this post from Minecraft Forum.

http://www.minecraftforum.net/forums/minecraft-discussion/redstone-discussion-and/command-blocks/2477949-minecraft-pc-target-selectors-and-their-arguments

  • 1
    It did not work for me, the previous answer selected answer better answers this. I believe I had already tested all (or nearly all) permutations before posting, including [type=Item,Player] [type=Item,type=Player] [type=[Item,Player] and I distinctly remember one crashing me and none of them working. – Codingale Jul 30 '15 at 14:24
  • 1
    This doesn't work. Due to the simple parsing of arguments that Minecraft employs, @e[type=Player,type=Villager] is functionally identical to @e[type=Villager]. The second argument simply overwrites the first. – MrLemon Jun 14 '16 at 15:06
0

In Minecraft 1.9, there is a simple way to do it without scoreboards using Chain Command Blocks. For demonstration, I will kill all entities that are not players or items.

First Command Block: execute @e ~ ~ ~ summon ArmorStand ~ ~ ~ {Invisible:1,NoGravity:1}

This makes an armor stand in the same spot as every entity. The first command block must be facing into the second command block.

Second Command Block: execute @e[type=Player] ~ ~ ~ kill @e[type=ArmorStand,c=1]

This makes all players kill the armor stands that are about to do something.

Third Command Block: execute @e[type=Item] ~ ~ ~ kill @e[type=ArmorStand,c=1]

Same as above except with players. You can do this as many times as you want.

Last Command Block: execute @e[type=ArmorStand] ~ ~ ~ kill @e[c=2] ~ ~ ~

This makes all armor stands kill themselves and the entity they represented.

The advantages:

  • Uses armor stands. Why not?
  • Doesn't require scoreboards

The disadvantages:

  • If an entity dies/teleports to a far location after the armor stand is summoned but before the armor stands run their commands, some entity that isn't meant to be killed will be killed

If you want all of the non-player non-item entities to run a command, just use this:

Last Command Block: execute @e[type=ArmorStand] ~ ~ ~ execute @e[r=1,c=-1] ~ ~ ~ <command>

Disadvantages to this:

  • If an entity dies/teleports/leaves the range in under 1ms, the armor stand will execute the command itself
0

As of 1.12 you can do @e[type=!Player,type=!Sheep,r=10]. This works as it checks for a non player mob first, then it checks for a non sheep mob. The radius checks for both parameters within the radius. The syntax is correct as the comma separates the datatags and just !Player or !Sheep would not work.

  • 1
    Isn't this a 1.13 change? – Fabian Röling Nov 12 '17 at 18:02
  • No, I have used this successfully in my command works. When i call for a mob type check twice it acts as an AND logic operator. It has to be not a player AND not a sheep – ThatGuy124816 Nov 12 '17 at 23:59
  • This does not work in 1.12. You're getting false positives. Prior to 1.13, selector parameters are a basic associative array, where key names have to be unique. The second type completely overwrites the first type. Your command in 1.12 will only target anything that isn't a sheep. – Skylinerw Nov 13 '17 at 0:50
-2

A much easier way to do this is to use this command:

/kill @e[type=!Player,r=20] . The exclamation point means to kill everything except the type of entity targeted. You can put this on a redstone clock and it works great. I hope this helped you! :) P.S. you can put as many entities as you want within the command. Just do this: /kill @e[type=!Player,!Sheep,r=20]

  • 1
    This doesn't really answer the question, and the latter part is just plain wrong. /kill @e[type=!Player,!Sheep,r=20] will kill all the sheep within 20 blocks, because that is definitely not how target selector arguments work. – MrLemon Nov 28 '15 at 20:03
  • Yeah, like they said. It's not correct, and this has been brought up in the original question and comments of other answers. – Codingale Nov 29 '15 at 10:14
-2

As others later explained to me, the real reason is that restrictions of the same kind owerwrite each other. Sorry, I can't keep myself from trying to use logic for answering questions I actually don't know the answer to, losing from sight that things usually are not as logical as I think.


Original answer:

I'm not frequently targeting entities, but going on from mineguy1009's failed answer I figure the following:

The answer most probably fails because this is parsed like [type = Player AND type = Villager], which of course results in nonsense (it's not exactly nonsense itself, actually it's quite a reasonable approach as the comma suggests it would be [type = Player OR type = Villager]).

However, as you are negating, that's exactly what you need: [type=!Player, type=!Item] should be parsed as [type != Player AND type != Item]. If you want entities to be of either category from a group, intuitively it should be [![type=!<type1>,type=!<type2>,...],<otherconditions>]. If that doesn't work, you could still go for inverted groups, which would however get awfully long (as you have to list literally every entitiy which shall be not in your group).

If this answer fails as well, entity targeting is, yeah, wat.

  • 1
    Except that this completely wrong. When parsing [type=Player,type=Villager], the game simply forgets about Player, the type variable is just overwritten. Also, not equals is =! in Minecraft because of argument=value parsing, where the equals sign is fixed, and the value is negated by the !. – MrLemon Jun 14 '16 at 15:05
  • @MrLemon I used the different operator to clarify it's pseudo code. If Villager owerwrites Player, then, of course, wat. – Egor Hans Jun 17 '16 at 9:48
  • It would interest me, by the way, to anyone who clicked the link: Did you observe that level of nonsense in any MineCraft stuff? Because sure, restriction handling is unlogical, but not to the extreme degree of the examples in the video. – Egor Hans Jun 27 '16 at 12:44
  • @EgorHans Selector parameters are mapped as a basic associative array, where key names must be unique. It'd be the same as trying to declare the array ["key1" => "a", "key1" => "b"] in that "key1" has been duplicated and thus overwritten. – Skylinerw Jun 27 '16 at 13:49
  • @Skylinerw It does make sense up to some point. However, it's quite obvious that implementing it like this is not actually a good idea. If you have multiple occurrences of one key, you would expect both to have some impact. – Egor Hans Jul 11 '16 at 8:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.