Comma or other symbol after @ selector does not work with command blocks

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:

say Well done, @p!

This will output: "Well done, @p!"

It only worked when I added a space after @p like this:

say Well done, @p !

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:

say Well done, @p[]!

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:

say @carl_d: Please bring some food. @peter_h: Please bring the arrows!

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.