- The distinction between <testable_variable> and <constant_expression> already is somehow fluent. E.g. "mission_mymission_counter lessthan [mission_mymission_anothercounter]", comparing two variables to one another is valid code, provided the second variable is put in square brackets.
Are you sure about this? It looks to me for all the world as though what the existing code is doing for <constant_expression>s is:
If it ends with _bool, _number or _string, treat it as a query method.
Otherwise, treat it as a literal.
Variables don’t seem to be handled.
Hmmm, seems that you're right on this one. I had a look into my scripts again and actually I found no example that looked like the one I posted.
It seems when I posted my first post I mixed up "mission_mymission_counter lessthan [mission_mymission_anothercounter]" (which I in face never tested) with "set: mission_mymission_counter [mission_mymission_anothercounter]" or "set: legalStatus_number [mission_mymission_anothercounter]", which are valid.
actually
setLegalStatus: <value> ,
which sets the legalStatus_number to <value>
is the correct way IIRC.
in which <value> can be a number or a [string],
My guess is that any strings that are not numerical are ignored (or generate an invalid command) and values below zero or above 255 are reset to those values respectively for legalStatus_number.
As for dajt’s question earlier, one reason to improve the plist scripting is that scripts are used in a variety of contexts, but only one (the “world script”, i.e. script.plist) can currently be replaced with JavaScript. Hopefully I’ll have a fix for that reasonably soon. Another is that the refactoring work is less boring this way.
