[MCPE-19897] Command type "string" only allows strings that start with letters Created: 01/Feb/17  Updated: 07/Jan/25

Status: Reopened
Project: Minecraft (Bedrock codebase)
Component/s: None
Affects Version/s: 1.0.3, 1.0.4.11, 1.0.5.3, 1.21.51 Hotfix
Fix Version/s: None

Type: Bug
Reporter: Mark White
Resolution: Unresolved Votes: 9
Labels: None

Attachments: PNG File Screenshot_20170201-190941.png     PNG File Screenshot_20170201-190949.png    
Confirmation Status: Confirmed
Platform: Tablet - Android - Other (Specify in description)
CHK:
ADO: 1086824, 1086992

 Description   

For example, using command "transferserver", which arguments are server of type string and port of type int, you can write the address as "example.com" but you can't write it as a numeric address, like "192.168.5.1".

In the first screen the argument is valid, in the second is not.



 Comments   
Comment by user-f2760 (Inactive) [ 27/Jul/23 ]

For clarify, the following character set doesn't require quotes in java, anything else included and quotes are needes: a-zA-Z0-9._-

Comment by [Mojang] Mega_Spud (Jay Wells) [ 27/Jul/23 ]

Reopened for review.

Comment by user-f2760 (Inactive) [ 14/Mar/23 ]

Agreed with Sprunkles Java allows string arguments to start with numbers in all those cases, whereas bedrock throws an exception (for seemingly no reason).
This should absolutely be reviewed. If not for ease of use, for parity.

Comment by Sprunkles [ 27/Mar/20 ]

Could this be reopened? This affects more than just the /transferserver command, including but not limited to scoreboard entries ('#hidden' is invalid, and requires quotation marks to work), tag names ('1' is invalid) and even target selector arguments ('tag=1' is invalid). This can also be contrasted to Java Edition where quotation marks are not required for these entries.

Comment by [Mojang] Adrian Östergård [ 06/Apr/17 ]

You can solve this by putting the IP address in quotation marks.

Comment by Mark White [ 15/Mar/17 ]

Not fixed in 1.0.5

Comment by inxomnyaa [ 03/Feb/17 ]

I confirm. We tried with some modified packets, ips (x.x.x.x) work fine for the packet.

Generated at Sat Jan 11 15:24:59 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.