Comma or other symbol after @ selector does not work with command blocks
@p and @a won't list usernames
What I expected to happen was...:
Command Block: /say @p, You are not allowed to access this area!
What actually happened was...:
[@] @p, you are not allowed to access this area!
Steps to Reproduce:
1. Get a command block (/give username 137)
2. Type in the command block /say @p, somat here
3. Power with redstone
Result:
[@] @p, somat here
Environment
Windows XP, JRE7
Windows 10, JRE8
Linked Issues
is duplicated by4
MC-9895The command block only says the player name with @p if there is no punctuation or anything after the @pDuplicateMC-9898Comma or other symbol after @ selector does not work with command blocksDuplicateMC-12049Commandblock, Playervariable and punctuation mark not workingDuplicateMC-18653/say and /w command bugDuplicate
Created Issue:
@P and @A doesn't list names. 13w09c
@p and @a won't list usernames
What I expected to happen was...:
Command Block: /say @p, You are not allowed to access this area!
What actually happened was...:
[@] @p, you are not allowed to access this area!Steps to Reproduce:
1. Get a command block (/give username 137)
2. Type in the command block /say @p, somat here
3. Power with redstoneResult:
[@] @p, somat here
Environment
Windows XP, JRE7
- Unresolved
- Open
- Minecraft - Private
- Unconfirmed
- 13w09c @a arguments block command jre7 say
- 13w09a 13w09b 13w09c
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adams@P and @A doesn't list names. 13w09cComma or other symbol after @ selector does not work with command blocks
is duplicated by
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
A comment with security level 'global-moderators' was removed.
[Mojang] Nathan Adams
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Cannot reproduce.
@p is replaced by player name
Please do not mark issues as private, unless your bug report is a security issue containing information that may compromise your server/client.
@p is case sensitive, maybe that's the problem?
I think the problem is caused by the comma after @p. I did a similar thing with an exclamation mark like this:
This will output: "Well done, @p!"
It only worked when I added a space after @p like this:
This will output: "Well done, The.Modificator !"
EDIT: Just tested it with the comma. Same behavior here.
IMO a good resolution for this would be allowing this syntax:
Using such a character sequence pretty much ensures that those characters should be interpreted as a placeholder, not part of a normal chat line.
Just doing a normal search-and-replace for just "@p" won't work as it breaks "normal" chat lines like this:
This would then output: "@carl_d: Please bring some food. The.Modificatoreter_h: Please bring the arrows!" The character sequence "@p[]" shouldn't appear in normal chat though. (Except for very fancy smileys.)
If punctuation is added after the @p or @a without a space between, the function of @p is ignored and it is not recognized as a console action. This is very frequently seen with chat bots and other text-based things that involve changing outputs.
Will have to fix after 1.5 as the player selector should use a token based system, and not regex. Too scary to do too close to 1.5!
Wouldn't the syntax @p[] be easily parsable as tokens? I'm thinking about something like this (in EBNF):
chat_line = { player_selector | other_character }; player_selector = "@" (player_selector_type) "[" [ player_selector_options ] "]"; player_selector_type = "a" | "p" | "r" player_selector_options = player_selector_option [ { "," player_selector_option } ]; player_selector_option = ("r" | "m" | ...) "=" ...other_character would have to be set to some kind of fallback. And what I wrote for player_selector_option is just a sketch.
–
I just edited the EBNF. This is what the EBNF looked like before my edit:
chat_line = { player_selector | other_character }; player_selector = "@" ("a" | "p" | "r") "[" [ player_selector_options ] "]"; player_selector_options = player_selector_option [ { "," player_selector_option } ]; player_selector_option = ("r" | "m" | ...) "=" ...Yes it would, and that's what we will try to do.
Sounds great! So should map makers start using @p[] in their maps instead of only @p from now on? (Just asking to ensure forward-compatibility.)
We'll still allow @p as it does now, where it's the entire word. It would probably need @p[] as you suggested for detection within a word.
So your implementing this as a bugfix? Cool, never thought you'd fix this as it is the comma. @p, hi
Do some tests and you'll see.
Could you not just replace every @p or make it work at least? Because using it like this: /say @p , Hi
Just doesnt look good.
P.S. I didn't mark private. I marked it as public. A mod must of marked private.
Has this been abandoned?
I can confirm this bug for 13w37b. Can somebody please update the Affects Versions tag? It happens whether you use @p or @p[].
Confirmed for 08a
Confirmed for 14w18a but you should be using tellraw now
Confirmed for 14w21b
I guess this might not get fixed now that you can do most of this with /tellraw and JSON
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Well, yeah: /say @p is there. Hello, @p! @p, What's up? will still result in the chat line The.Modificator is there. Hello, @p! @p, what's up?, so the behavior is not changed.
However, since the command /tellraw was introduced a few versions ago, there is a wordaround for this now.
Reopened, thanks,
I'd like to add that /say Test, @p[]! does also not work (as discussed above). However, I'd still vote to close this ticket because whenever someone wants to accomplish something like this, he/she can easily use /tellraw now. So there is no need for changing the current behavior.
This may be fixed later when we use my Brigadier command library, but no promises so I'm going to leave it open until it actually is fixed
Updated this, been 2 years nearly since it was reported, minor issue but would be nice to have fixed.