Ferdinand B.
Assigned
Reported
Comments
confirming that commands /tp and /tell do NOT work with @ statements that make use of the x,y,z or r arguments in Minecraft 1.7.2
Other arguments work fine though.
Examples:
/tell @p[score_lolz=1] Whisper
works/tell @p[x=102,y=65,z=-364] Whisper
doesn't work (claims to not be able to find player)
Zach, this is a feature, it's confirmed (look at the version history, the feature is called repeater locking)
/give <player> <amount> <id> [data] where data is the damage value
in your case it would be /give yourname 64 35 5
also, you didn't really give us a real clue what you put into the command block.
Once you said testfor x=<number> y=<number> z=<number>
and once you said testfor @px=<number>,y=<number>,z=<number> and in your pic you said @p[x=<number>,y=<number>,z=<number>]
The way it works is this:
testfor <playername>
The @-Notations are treated as playernames
If you do an @-notation with arguments [x,y,z] then it will search from that location but the radius will still be infinite.
So @p[3,4,5] will still be on as long as at least one player is online (he is the nearest to 3,4,5)
In your case, I would either do @p[x,y,z,r], @a[x,y,z,r] or @r[x,y,z,r] to get the disired effect (only triggering if you are in a certain area)
Example: testfor @a[x=27,y=65,z=-1226,r=3]
Will test for a player within 3 blocks spherical radius of x=27, y=65 and z=-1226
confirming that this is a feature
Not a bug, expected behaviour.
If feeding input to the side of a repeater with a repeater, the repeater gets Locked in its current State.
So in your case, you locked the repeater in the OFF position (will not turn on until delocked)
It can also be locked in the ON position by powering the repeater and then locking it the way you did. (The repeater will stay on until delocked)
once delocked, a repeater will behave "normally"
This mechanic of repeaters is intended and was introduced in Snapshot 12w42a or Minecraft 1.4.2
See http://www.minecraftwiki.net/wiki/Redstone_Repeater for more details
I migrated my Account myself and I am not having such problems. I have no problems with setting up servers and/or joining them.
Check these things:
Can you log in to mojang.com with your mojang account (email & password)?
if not, check if your mojang account is set up correctly
Can you log into minecraft/minecraft.net with your mojang account?
if not, check if your minecraft account was migrated to your mojang account correctly
Have you bought minecraft yet?
if not, you may not be able to join some servers and play the full game (only demo-mode without buying)
As this is about changing name tags or name tag colors, this should be added as a MCAPI Feature Request under the respective JIRA.
Just make a new Issue there with "Change Player tag without modifying skin or player name" or something like that. Be sure to check the post MCAPI-4 first.
deleting the META-INF folder is considered modifying the jar. This Bug Tracker is for vanilla bugs only.
(Although the META-INF folder should only contain a manifest file and shouldn't have an impact on the game itself)
The [name] thing is clearly showing that a renamed command block is saying it...
...wait... If you say something with /say as a player it does this too?
Looks like google translate
This is because the name of a Command Block is not matched with Player names. A command block can't be on any teams. A player can.
okay, I don't know the exact syntax. I just thought it might have been like that.
Learning by doing. Know we know that it doesn't work like that
add, [-brackets around it. Mojira made a link out of my brackets
I think it's [2001:41d0:4f96::1]
IPv6 Ips contain brackets to distinguish between the :s from the Ip adress (e.g.: 1337:21db:6:9000::e) and the Port identifier (:<enter-port-here>)
I suggest you to change the title into something similar to "[Command Block] testfor, tell, tellraw and tp don't accept coordinate-@ arguments", but that's only my thought, so if you think the existing title suits this topic better, go leave it.
I sure notice this as I receive email-notifications about it, so I thought I re-confirm the issue with 1.7.2
And there we are, with a (in my thoughts) really important bug that should be fixed, because it really makes adventure-maps suffer.