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