1

So my Minecraft name is "JAMES_the_camel" (yeah I know, strange..). So I was trying to make a door that only opened when it was me walking across the tripwire. The first block has the code:

testfor @p[1303,56,518,2,n=JAMES_the_camel]

It is impulse, unconditional and needs redstone.

The others use (repeated for all of the blocks):

setblock 1304 56 515 air

They are chain, unconditional and always active.

However the condition for the name doesn't have any effect. I tested it on 2 accounts and the door opened on both. Am I using the syntax wrong or is there something else I'm missing?

Edit - The problem has been confirmed as the pick block key saving all states correctly other than the conditional.

it used to save the conditional state since it was originally saved as NBT. However, it was changed later on during the 1.9 snapshots to be a blockstate rather than NBT. The reason behind that is because changing the conditional setting via NBT would not prompt the client to render the block anew, making it appear as a regular command block instead of conditional. Changing a blockstate would allow the client to re-render it. Pick-blocking only saves NBT, so that blockstate is lost. – Skylinerw

| improve this question | |
3

There is no n parameter. The correct parameter you're looking for is name. The wiki has a list of all valid parameters here.

testfor @p[1303,56,518,2,name=JAMES_the_camel]

For 1.11-1.12, which removes shorthand coordinates:

testfor @p[x=1303,y=56,z=518,r=2,name=JAMES_the_camel]

And for 1.13+, which overhauled the command system (where /testfor has essentially been merged into /execute):

execute if entity @p[x=1303,y=56,z=518,distance=..2,name=JAMES_the_camel]

As well, because your chain is unconditional, it's going to activate no matter what and open the door. If you set it to conditional, it will only run its command if the command block physically behind it was successful. You will want to set your chain block to conditional or otherwise activate another set of command blocks based on the success of /testfor.

| improve this answer | |
  • I have tried that and it still opens for both players. – user148122 May 22 '16 at 18:21
  • @JamesTompkins While the parameter was a key issue, you had another one concerning the command blocks themselves. I've extended my answer to include it. – Skylinerw May 22 '16 at 18:31
  • I can't believe i missed that... Thanks so much for pointing that out to me! I believe the problem was when I stacked them up to save room. I used the pick block key and i believe it saved everything except for the state of conditional. However it may have just been me completely forgetting. Edit: I have confirmed that the pick block key saves the command but no the conditional state (Strange because it saves active and chain setting) – user148122 May 22 '16 at 18:34
  • @JamesTompkins Aye, it used to save the conditional state since it was originally saved as NBT. However, it was changed later on during the 1.9 snapshots to be a blockstate rather than NBT. The reason behind that is because changing the conditional setting via NBT would not prompt the client to render the block anew, making it appear as a regular command block instead of conditional. Changing a blockstate would allow the client to re-render it. Pick-blocking only saves NBT, so that blockstate is lost. – Skylinerw May 22 '16 at 18:46
  • As of 1.13, don't bother using a chain command block: just combine the two and say /execute if entity <selector> run <command> – pppery Sep 3 '18 at 18:43
-1

If you make a redstone clock connecting to the /testfor command block, it will work. Also, if you do:

/testfor JAMES_the_camel [r=10]

It will test for a player within 10 blocks. Then, if you put a compactor facing away from it going into a command block saying:

/fill ~ ~ ~ ~ ~ ~ air

But instead of having ~, use the coordinates and you can replace air. If you do this, it will test for you and auto open the door. You wont need a tripwire hook at all.

| improve this answer | |
  • This will not work because the syntax in the first command is incorrect. The other answer has the correct syntax for checking a name (though it uses pre-1.11 syntax for shorthand coords). – Skylinerw Jan 1 '18 at 4:19
-2

Set the desired player(s) into a team, and then select that team, using the commands:

/scoreboard teams add TeamName DisplayName

/scoreboard teams join UsernameOrSelector[team=TeamName]

If you are unsure of how to implement selectors, it is done like this:

/command @a[selector=selectorValue]

If you want to target a player within a certain area, use the [r=Number] selector in a loop command block at the center of a lobby or room. The value "Number" is the square block radius on all axes.

If you know the username of who you want to target, use that instead of the values above like this:

/command FungusKing_III

For the function you stated in the description, you can simplify it massively. Hook the tripwire up to a command block (making sure the command block is powered by an adjacent block) with:

/testfor JAMES_the_camel[r=10]

Or use a |repeat|unconditional|always active| command block anywhere in the world with:

/testfor JAMES_the_camel[x=1303,y=56,z=5182]

And hook that command block up to a comparator that powers the door or a command block that opens it in either case.

| improve this answer | |
  • 2
    Could you maybe explain more by adding the commands the OP needs to use? – angussidney Jul 31 '16 at 4:18
  • Also, the coordinate selectors need to be set out like: @p[x=1303,y=56,z=5182] – Chemical Comrade Nov 21 '16 at 7:31
  • You cannot append a player's name with parameters like name[r=10]. You have to use a selector for that, and use the name parameter to specify a name (such as @a[name=JAMES_the_camel,r=10]. – Skylinerw Nov 21 '16 at 10:19

Your Answer

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