Face blocked in draft. Why?

Support
1

Hi, another face was put back in draft status for conversion failures with platform WFF.

I like to know why and the forum perhaps can enlighten me.

What i already checked

  • the compatablity checks inside F Creator page, checked for WEAROS WFF and TIZEN. All green. You can check that too if you want.
  • i checked that ALL tags used have status OK in the F C reference documentation.
  • all properties have as a result a value.
  • ticket is made
  • i know from another face, that perhaps some checks made at the stadium of publishing, are not included inside Facer Creator, leaving the door wide open for … many things, but i dont know what exactly.

Inspection is on.

ps : for now this face will be published excluded WFF platform, but of course i want it on WFF.

Thanks.
BC

3 Likes
2

And another…

2 Likes
3

The only thing I see in the first one is your colors with the #DOW# tags with an opacity expression in the Text Box. Facer doesn’t allow that now and you have to put all opacity type expressions in the opacity box. I had WFF failures for having a Metric or Imperial choice in the text box. When I moved it to opacity WFF would publish just fine.

2 Likes
4

On the second one you have the same issue with the minute and both hour layers. You have to make all show or no show in opacity not in the text box now.

2 Likes
5

Hi Rusty.

Thanks for your engagement.

Did as you advised, transfer all DOW formulas to opacity. Still put in draft.
Elimated all images with DOW, still in draft.

Elimated date elements, sequence rotation based on BLN, sequence rotation based on seconds.
Killed even my animated logo. Changed duration of sequences to 1 sec. Still draft. I give up and it is becoming seriously ridiculous, to me. I await the oracle.

All tests were done with a copy, stripped down to what it is now.
BC

image
image1920Ă—1080 83.6 KB

2 Likes
6

@pbervoets
One other thing I noticed was you had the one date text as $#Dd#<10?0#Dd#:#Dd#$ That will kill it also. I was doing distance in miles or KM with this expression: $#UNITSYS#==IMPERIAL?((round((#ZSC#*0.0476)))/100) ML:((round((#ZSC#*0.00762)))/10) KM$. That causes Facer to fail the conversion also. I had to split it into two elements one for miles and the other for KM and use opacity to switch between the two. Facer calls that a string expression and those are now blacklisted.

4 Likes
7

I received the explanation “String Concatenation is not available in WFF” from Facer support, even though my formulas contain no strings at all.

In this context, it does not mean text is being concatenated. It is a generic explanation shown when the WFF engine fails to interpret a formula because it has become too complex for the parser.

The real issue is not strings, but formula structure and complexity.
What typically triggers this in WFF:

  • Nested ternary operators
  • Repeating the same calculation many times
  • Very long chained expressions
  • Multiple comparisons in one statement

When expressions reach a certain complexity level, WFF can no longer parse them correctly.

This also explains many unexplained failures in complex WFF animations: the formulas are valid in legacy Facer, but too complex for WFF.

4 Likes
8

I would rather say for the automated Facer=>WFF translator

4 Likes
9

yes that is how it works, The Creator doesn’t send your formulas straight to the watch. It first processes them depending on the platform you’re targeting.

Each platform has its own engine:

  • Tizen uses its own parser
  • Wear OS legacy uses the old Facer engine
  • Wear OS 6 uses the new WFF parser, which is much more strict

So a formula that works fine in legacy Facer can fail in WFF.
Most of the time the issue isn’t the logic itself, but that the WFF parser can’t handle more complex formulas.

4 Likes
10

I think there is missing the condition where if in the text field in Facer is like
$#DOW#==0?SU:$$#DOW#==1?MO:$$#DOW#==2?TU:$$#DOW#==3?WE:$$#DOW#==4?TH:$$#DOW#==5?FR:$$#DOW#==6?SA:$
would translate in something still working in text field in WFS like this
(([DAY_WEEK]-1)==0?"SU":"")(([DAY_WEEK]-1)==1?"MO":"")(([DAY_WEEK]-1)==2?"TU":"")(([DAY_WEEK]-1)==3?"WE":"")(([DAY_WEEK]-1)==4?"TH":"")(([DAY_WEEK]-1)==5?"FR":"")(([DAY_WEEK]-1)==6?"SA":"")
maybe because there is no sign whether the missing option behind : is intentional or error?

1 Like
11

Well, indeed there is a special area of problems being the consequence of interfacing, mapping, translating codes, tags, expressions, strings etc. That consumes a lot of energy, waste of time, error prone processing, miscommunication, misinterpretation, disappointment etc. And we all participate somehow in this cycle. Like someone talking Chinese to a Japanese. The world is full of it. Perhaps we all should talk Japanese. Agreeing on something and living by it, is hard for human. The bigger fish will call the shots.

So, indeed, in another draft issue, i got the same non explaining response and like Jives i found it alien to the underlying problem, cause. This data has no info for me. Leaves a lot to interpretation, which is unwanted. Nor does it suggest a … solution.

Amber (Facer)

Nov 22, 2025, 07:20 PST

The issue is related to unsupported string concatenation. See below:

String Concatenation is not available in WFF. Expression affected: ((1601.0)±160.0+((-39.264)*cos(3.141592653589793)+(((((floor((([SECOND_MILLISECOND]*6)/6.0)))%6.0)<=2.0)?(([HOUR_1_12_MINUTE]*30)):(([MINUTE_SECOND]6))))))

Future iterations of the Creator will fix the fact that you are not given clear info about the reason for the failure.

So indeed, there is some translation going on. I figured out this writes in one string, the x pos value, y position value and the rotation value. Looks like it does the concatenation itself… By the way it looks lot alike tags used in WFS…

I feel there is a lot done, because we want to uphold Chinese and Japanese…till it ends. And there is a lot still to do, if ever done.

The consequences are still, we dont know what is causing the draft issue in my case. The stripped down version only contains some seq with simple tags like #DWFKS# and variations on that. It is so stripped down, it lost all value to me in that way. So translation can destroy also a face. At least, till i hear why, if ever. And than remains to be seen, if there is a solution, or just avoid sequences for example. I am guessing here, but that is the only thing left, till now.

Perhaps i will later try on, creating this face in WFF, which is probably my destination, and perhaps import it in Facer, just to build further on experiences of every kind.

2 Likes
12

In my innocence and lack of knowledge AND I have no idea what is the intention with the above code but I can imagine tht using +/- and normal parentheses together with square brackets could confuse facer.
I can understand your frustration with things but you DO get a response from Facer and you DO get information as to what is wrong - perhaps not as much as you would like, but still you do get something and of course you get the people here trying to help. Having said all that I do agree that Facer are not the best at communicating but things ARE getting better - at least i believe so.

1 Like
13

Yes I agree with you, the only down side is that those faces are not compatible with the older watches.

2 Likes
14

@pbervoets . This looks to me like a formula that AI came up with . I wonder if it ever worked in Facer Creator at all . Some of it looks like a WFS Formula but I see a lot that will not work there either . I find PI to 4 decimal is fine for what we are doing .
.
((160* 1.0)±160.0+((-39.264)*cos(3.141592653589793)+(((((floor((([SECOND_MILLISECOND]*6)/6.0)))%6.0)<=2.0)?(([HOUR_1_12_MINUTE]*30)):(([MINUTE_SECOND]*6))))))

2 Likes
15

Facer’s WFF conversion is totally broken right now. I had a face that failed conversion and was saved as draft but the WOS and Tizen versions were published. I made a new face just like it only with stock Facer time and battery levels with a picture. It failed WFF conversion and there is nothing in it that could fail. Here’s the watchface and it’s inspectable in case anyone smarter than me can find a problem in it.

Capture
Capture772Ă—631 131 KB

3 Likes
16

This is what I was saying in another post I put up the other day. “Someone screwed something up somewhere”

3 Likes
17

@pinbal24
I suspect that the time itself is what is causing the failure. I think the WFF conversion is seeing the #Db#:#DmZ# as a string expression and not as a time expression. I think the : is what is confusing the conversion process.

2 Likes
18

I don’t believe that because I made this face 2 days ago, it’s not published yet, but I it saves just fine with all 3 formats.

1 Like
19

Everything created two days ago or earlier still seems to work fine here. Anything new or updated since yesterday is not working/syncing for me at the moment. Not even a new blank face with only the time on it.

2 Likes
20

@jivestaroso That’s what I’m seeing also.

1 Like