I’m using this expression to script x or y position for image sequences (to put animation on screen or off screen) and it was working ok.
$#WCCI#==10?162:$$#WCCI#==09?162:-300$
Last night I checked again the faces that have this expression in position and stop working (WCCI was 10 and x position remain -300) Extrange thing: in creator and web preview it worked fine, in app preview and watch it doesnt work…
Another extrange thing, in other faces that I use that expression in opacity
$#WCCI#==10?100:$$#WCCI#==09?100:0$
it worked fine everywhere, even my watch.
Originally I used boolean ||
$#WCCI#==10||#WCCI#==09?162:-300$
But it never worked fine in creator or web preview so I changed for the nested one.
Any thoughts?
Hey @carlosfilippa,
I’ve been messing with nested-equals for a long time. Try the expression with single equals signs.
$#WCCI#=10?162:$$#WCCI#=09?162:-300$
…and see if that makes a difference.
-john
I will try it and see what happens. Thanks!
Well, no changes. Works fine in the web preview but in the watch the script returns 0 for x position (I thought remained -300 as false, but its even worst) 
With both == returns 0 too… Thats the problem why I didn’t use || now it happens with nested…
@Facer_Official any hints?
Unbelievable, now i tried with || and works perfect! But I can’t keep updating the faces everytime the expression wanna or don’t wanna work
Lol well glad it works. Hopefully it will stick this time
FYI:
$#WCCI#=10||#WCCI#=09?162:-300$
Same expression, but without extra ‘?’ or long form ‘==’, has always worked for me (on watch or creator).
Yes, boolean is without ?, was a copy-paste mistake haha. I edited the post. Thanks.
I´m talking when scripting position, in opacity works either way (boolean or nested, = or ==).
I’ve also had issue with ‘chained’ IF statement, for last stage.
If expression not TRUE (or also NOT equals), it does not take alternate path. It’s inconsistent, but appears to be a complexity issue. More than three chained generally is more likely to have an issue.
I think (as I have stated elsewhere, on this forum) the multi-stage parser is smart at initial parsing, then stupid (cutting corners, and deleting beyond certain level of complexity), and then smart on what it has left (at runtime).
I’ve seen similar issue on a software project some years ago.
1 Like
Someone can probably explain better than me… but how you use brackets will impact results you see with nested conditions. The nested examples below only work when the answer is a number. No good for text answers
Nest example 1:
(($(#Dm#==1)?1:$$(#Dm#==2)?2:$$(#Dm#==3)?3:99$)/1)
Nest example 2:
($(#Dm#==1)?1:$$(#Dm#==2)?2:$$(#Dm#==3)?3:99$)
Nest example 3:
$#Dm#==1?1:$$#Dm#==2?2:$$#Dm#==3?3:99$
Results
| Set the Minute to | Result Ex 1 | Result Ex 2 | Result Ex 3 |
|---|---|---|---|
| 0 | 99 | 99 | 99 |
| 1 | 1 | 1 | 199 |
| 2 | 2 | 2 | 299 |
| 3 | 3 | 3 | 3 |
| 4 | 99 | 99 | 99 |
Nest example 1 and 2 output 1st matching statement or the False value when enclosed in brackets.
Nest example 3 outputs all matching statements and the False or true value of the last condition when not enclosed in brackets.
I use these expressions a lot and with only a single = as @jmorga106 suggested. I just checked a couple of my faces and no troubles on my watch.
That said I will always use individual layers with ==to avoid possible problems as that’s more fool-proof.
$#WCCI#==09?160:-120$
$#WCCI#==10?160:-120$