#DWFSS# is unreliable in creator

Depending on when you load the face #DWFSS# for 0 seconds can be anything between 0.0000000000000000 and 7.99999999999999999 and so on through the rotation.

This leads to discrepancies when creating expressions based on this value as the visual representation cannot be trusted.

It needs the to be the proper value, not an arbitrary fraction of the second at which the face was loaded into the creator.

I realy hope the same bug is not present about the time a face is loaded to a watch.

This face demonstrates perfectly. Not sure if it translates to the hour and munute faces just now. but it’ pretty bad from a design perspective byt als from a whole watch perspective if you can be nearly 8 degrees out on your time calculation depending on load time.

Just set it to second 00, 01 etc on the time machine and see. Close, re-open and try again. Different #DWFSS# for same #DWFS# each time.

Try using floor if you want to even out to the nearest whole number. Example is replace text on your screen with: (floor(#DWFSS#))

This will keep it smooth transition between the whole numbers. It will evenly divide your minute into 360 degrees.

1 Like

You can use #Ds# or #Dsm# for your expressions. I normally use #Ds#, but I’ve used #Dsm# for a couple when I wanted it to do something at 59.5 seconds. It seemed to work fine for me.

In this example, I used the #Dsm# tag to turn on the 59th second LED for a split second before all the seconds LED go out at 0 seconds. Inspection is open if you care to take a look.


The suggestions give a ticked, rather than smooth progression.
Sorry but the problem is that the #DWFSS# tag is broken in at least the creator as it does not accuratelty display the second rotation but instead displays the second rotation plus the fraction of a second in which the face was loaded.

It is a bug, I am not asking for advice but votes to fix this, but thanks anyway.

1 Like

That’s a nice design there @mrantisocialguy
Well done Sir :+1:


Open my bug test example multiple times ans tell me that #DWFSS# is ever anywhere near #DWFS# or the same fraction every time and the second hand actually lines up with the correct tick mark when setting the second via the time machine.

It makes testing visual representations of rotation using #DWFSS# very difficult.

Basically the current functionality is 0=rand(0,8)

1 Like

I am sorry, tried to reproduce what you describe, but could not see any difference between #DWFSS# and #DWFS# higher than 6 degrees, which is logical as they are equal each whole second and hand rotates 6 degree per second, so #DWFSS#=#Dsm#*6 and #DWFS#=#Ds#*6.
Only one unexpected thing that I observed was, when I let the time machine run and stop, (the #DWFSS# stops somewhere between #DWFS# and #DWFS#+6) and then set the timemachine to some round number, the decimal fraction of second is not reset to 0, but keeps where it stopped last time. Only way to reset it, is to drag the slider to start of the time line and only then after set the numbers for timepoint.

1 Like

Yes, sorry, 5.99999999999999999.
You can see here that visually the second hand is nearly a second in advance of where it should be. Trying to align an element with the greater ticks would then look all wrong when just using the popup to set the seconds.

Your suggestion of using the slider to reset to exactly zero does work nicely though. Thankyou very much for that.

It would be much nicer if #DWFSS# was set to the exact second with no fractions on load though.