This worked in the past but stopped working for some weird reason:
set {farbenspiel::%{_signloc}%::points} to 5000
set {_stufe1} to 1000
set {_stufe2} to 10000
if {farbenspiel::%{_signloc}%::points} >= {_stufe1} AND {farbenspiel::%{_signloc}%::points} < {_stufe2}:
broadcast "TRUE"
else:
broadcast "FALSE"
RESULT:
false
But it should be true. Can you check this?
When exactly did it stop working? I mean, after which Skript version?
Not 100% sure but I noticed it with the latest skript version.
I'm still able to reproduce this issue in 2.2-dev22g. Turned this code into a simple test command:
command /test:
trigger:
set {_p1} to 5000
set {_p2} to 1000
set {_p3} to 10000
if {_p1} >= {_p2} AND {_p1} < {_p3}:
broadcast "TRUE"
else:
broadcast "FALSE"
It broadcasts false, though it should fire true. Naturally, there are workarounds, but this should be made to work as is.
Still can reproduce?
Skript doesn't support conditions list? It should use SkQurey's Comparison Query expression:
%object% == %object%
%object% === %object%
%object% > %object%
%object% < %object%
%object% >= %object%
%object% <= %object%
that returns boolean.
In this case
if 2 is greater than or equal to 2 AND 1 is smaller than 2:
should work but gives error:
Can't compare an integer with ('or equal to 2' and '1 is smaller than 2')
So it is if true and true: and that is not a correct code,
if {_p1} >= {_p2} AND {_p1} < {_p3} is true:
works because this is if true and true is true:
Interesting, I see what's happening actually. The fact that it's giving you that error (Can't compare an integer with ('or equal to 2' and '1 is smaller than 2')) would indicate it's interpreting the 'or' as an actual or statement, so instead of first trying to match greater than or equal to it matches greater than. AKA it's matching this version of the syntax:
[neither] %objects% ((is|are)[((n't| not| neither)]) ((greater|more|higher|bigger|larger) than|above)|\>) %objects%
instead of this one
[neither] %objects% ((is|are)[((n't| not| neither)]) (greater|more|higher|bigger|larger|above) [than] or (equal to|the same as)|\>=) %objects%
Making it interpret the equal to 2 as the final %objects% value from the expression.
I will say that vanilla Skript DOES support using the >, <, >=, and <= symbols, but supporting == would be nice. It allows you to use = for comparisons which obviously doesn't make sense for most programming languages since that's an assignment operator.
That isn't the case, it's just that he's using skQuery expressions as @Blueyescat pointed out. Vanilla Skript doesn't support what the guy in the original reply tried, which in Skript syntax it would be:
if 2 is greater than or equal to 2 AND 1 is smaller than 2:
This won't work because this is an inexistent condition, skQuery comparison doesn't have any English-like expressions for comparison therefore it won't work.
For who didn't get it yet, Skript comparison is based off conditions, not expressions. That means you can't use and with them as Skript doesn't support multiple conditions at once.
Which part are you saying vanilla Skript doesn't support? The >= and <=? If so, the docs show that as valid vanilla Skript syntax and have for a long time. I may just be misunderstanding, though.
I'm saying Skript doesn't support the following:
%number% is greater than or equal to %number% AND %number% is smaller than %number%
Skript can use either the first or the second comparison but not both in the same if-block because Skript can't parse more than one condition at once. Sure, the following will work:
if 2 >= 1 and 1 < 2:
But it's because this (I don't know why it's marked as condition, look at the source code, it's an expression) expression being parsed like this:
if (%number% >= %number%) and (%number% < %number%):
Ah I see, thanks for the clarification.
Well, that being the case, this should be closed as it isn't a real bug (even if it was, it'd be a bug of skQuery).
I'm still not honestly sure why this is being parsed since the "condition" (expression) you linked doesn't seem to use and as a syntax, but I'm probably just being dumb, and yeah, I don't see any indication that this is a vanilla Skript syntax (nor that it's going to be addressed soon regardless).
Thanks for the help @Snow-Pyon , your extensive Skript knowledge is as useful as ever!