Closed bi0qaw closed 6 years ago
You can't take a location of a variable because the variable is not parsed as an entity so it will return you "
If you wrote
command /k: trigger: set {_k} to player set {_k} to {_k} parsed as player broadcast "%x-coordinate of {_k}%"
Then it will result 140 if your player is in x coordinate 140.
That is just wrong. The variable is a location and you can get a coordinate from a location. If I don't register the first syntax it works perfectly fine.
That doesn't make sense @ZeTioZ , why would the variable need to be "parsed as an entity" (which is impossible, by the way) to get a coordinate from it? You can actually only get coordinates from locations; whenever you do x-coordinate of player
, the only reason it works is because Skript knows you want the x-coordinate of the player's LOCATION
and does it for you automatically. An entity on its own as a concept doesn't have a coordinate, it's all stored in the location of it.
Also:
set {_k} to player
set {_k} to {_k} parsed as player
Setting something to a type then setting it to itself parsed as that type again is so unnecessary and redundant. I get doing that if the return type is ambiguous or you're parsing into a string to make definite comparisons, but here those two lines of code just look silly. {_k}
is clearly and unambiguously a player object here, no need to parse it again.
I parsed that because if you try to do "if {_k} is online:" it will return you {_k} is not a player or something like that, because I think it look the variable as a String and not as a player it's just for that ^^, and for the location, yes I did a mistake so sorry about that ^^
Skript is ridiculous when parsing user-defined variables as part of expressions. It doesn't remember original type of variable; instead it tries to convert the variable to whatever type one of these expressions could take. In this case, Skript is converting location to vector, which naturally doesn't work.
Not tagging this help wanted, since there is probably no one experienced enough with Skript around.
Last time I tried to fix this, it didn't go very well. It broke everything, so after few days of messing I gave up. I'm not particularly interested to try again...
Just wanted to add that the same thing happens if you have an expression that allows two different types. For example: %number/vector% * %number/vector%
. If you pass a variable containing a vector into this expression it will change it's type to number.
Whelp, this is bad... Very bad.
I wonder if this issue disappears with parser rework :) We'll see it (hopefully) soon...
This might actually be solved since dev26. Took ages, sadly...
Long story short, it was not fully fixed. I have identified to root cause of problem in Skript parser, though. When parsing multiple potential types, they're separately until creating converted expression to some of them succeeds. Too bad that for variables, it always succeeds but results in an expression which does not contain any useful data.
If my memory servers me right, this was fixed in one of the latest updates so I think this can be closed now.
I'm not sure if anyone actually tested the fix, beyond my testing without any addons...
Yeah I know the title is shit...
What I did: registered a new expression:
(0¦x|1¦y|2¦z)(-| )(coord[inate]|pos[ition]|loc[ation])[s] of %vector%
executed the following script:Result:
The problem is that the syntax of the expression is identical to the syntax for the coordinate of a location:
[the] (x|y|z)(-| )(coord[inate]|pos[ition]|loc[ation])[s] of %locations%
Not a major issue but something to be aware of.