ALL THE TIME IN THE WORLD

Because he's a lovable guy, SignpostMarv Martin scripted up a working clock, and put it in my office in Waterhead.  (Direct portal here.) Because he's a mad man scripter, he made it a battery of six clocks, all set to major cities around the world, and made them analog.  Unless I've missed a previous version, it's the first of its kind, with a working second hand that makes it round in real time.

I asked Martin how he made it, and though I asked for the non-scripter version upfront, he unleashed the geek on me anyway.

"You know how llTargetOmega() is a client-side effect that the effects of which aren't displayed equally to everyone viewing it ?"

"No, I don't know how.  Non-geek!  Pretend you're explaining to a 12 year old how this works!"

"To do smooth rotation of an object in Second Life," he begins patiently, "you have to use the Linden Script Language function 'llTargetOmega'.  This is a client side effect, which isn't triggered until your client downloads the prim which has had that function applied to it.  Which is why people see different things.   Recalling it while everyone's client can see it, however, lets everyone see the same effect synced at once.

"So using a timer, I tell the hands on the clock to rotate server side so they point to the right place on the clock.  Then I recall the llTargetOmega() function.  Put this all together, and what happens is every minute all the hands are pointed in the right direction, and then told to rotate smoothly at the right speed, giving the effect of a true analogue clock in a virtual world."

"How do you manage to get it to work in real time so well?  Doesn't seem to be any server lag."

"If you go into edit mode and select the clock, you'll see what the server 'sees.' If you set it away going and disabled scripts and kept watching it, it'd still keep near-perfect time.  The timer to point the hand in the right direction and recall the llTargetOmega() is there to compensate for server side time dilation and to sync up client side display."  He grins.  "Hope that helps explain things a bit."

"Sort of!" I say, more or less fibbing.

Comments

[SignpostMarv Martin]

If you get really bored, you'll notice that the hour and minute hands move with smooth motion as well.

Zooming in with [Ctrl] + [ 0 ] will help. ([Ctrl] + [ 9 ] to reset view)

[Dolus Naumova]

Oh, now -that- is slick.

[SignpostMarv Martin]

The most complicated thing about this clock (well, to me anyway) was figuring out the PHP code-fu to mash up to make Hamlet's clock work.

I've had more time to play with the server side code now so the protocol should be more flexible (analogue calendars as well as analogue clocks for example)

Apologies for the geek talk Hamlet, but I invite you to find someone who can explain that in a none-geeky way without over-simplifying it or sounding patronising.

Other clocks I've done/am working on:

SecondCast Novelty Desktop Clock
Tiniest Watch EVARRRRR (SecondCast Edition) (that's my hand btw)

[Icon Serpentine]

If I'm not mistaken, this isn't the first in-world analog clock as I've seen a number of them since 1.1 -- however, it may be the first world clock. :)

Pretty nifty. Liked the extra articles explaining some of how it works.

[SignpostMarv Martin]

I did make it clear to Hamlet that I was aware I wasn't the first person to make a clock that looked analogue, but that as far as I am aware I am the first person to make an analogue clock that isn't texture based- other clocks I looked at after I made mine seemed to be using solely llSetRot(), or llSetTextureAnim()- the first method not being analogue at all, the latter not syncing to actual time.

I do have my doubts that I am the first person to have ever made a prim-based rolex-style (e.g. smooth hand motion vs 'ticking' hands) analogue motion clock in SL, and I invite clock makers to come forth and claim the title of the grid's first analogue clock maker- a title which Hamlet seems to have given to me but I'm sure I'm not deserving of.

[SignpostMarv Martin]

Btw, I would like to thank Luna Thereian and Keywe Magpie for asking me to help them with their clocks, as I probably wouldn't have thought to write the script without being requested to by them :-D

[Anonymous]

The first analog clock I am aware of is part of the Linden Waterhead Telehub. Although it doesn't have a smoothly rotating second-hand.

[SignpostMarv Martin]

@ Anonymous: If it ticks, it doesn't count.

[Joannah Cramer]

"If it ticks, it doesn't count."

Since regular RL analog clocks quite definitely 'tick' I don't quite see where you get off deciding how such approach "doesn't count" as analog clock... it's a little like claim one is the world's first man to run 100 m in under a minute and everyone else who did it before doesn't count, because they haven't done it with their toenails painted purple? o.O;

Add to that, llSetTextureAnim() is more or less equivalent of llTargetOmega for textures, so i wouldn't automatically discard every clock based on it as "not syncing with actual time" since they can operate on the same syncing paradigm omega-based can clocks utilize...

integer face_side = 0;

sync() {

integer seconds = (llGetUnixTime() % 60);
float offset = ((float)seconds / 60.0) * -TWO_PI;

llSetTextureAnim( LOOP | SMOOTH | ROTATE, face_side, 1, 1, 0.0, 0.0, 0.0 ); // kill rotation
llRotateTexture( offset, face_side );
llSetTextureAnim( ANIM_ON | LOOP | SMOOTH | ROTATE,face_side, 1, 1, offset, -TWO_PI, -TWO_PI / 60.0 );
llSetTimerEvent( 60.0 ); // or whatever
}

default {

state_entry() { sync(); }

on_rez( integer Parameter ) { llResetScript(); }

timer() { sync(); }
}

... there you go, duplicate and adjust the code for minute and hour hands, supply them with world time and you have texture based syncing clock live and (not) ticking...

[SignpostMarv Martin]

If a clock ticks, then it is technically a digital clock, not an analogue one. It's not enough that it has to look analogue, it has to move in an analogue fashion.

With regards to my comments on texture animation clocks, I was under the impression that llSetTextureAnim() ignored the static texture rotation as it does the static texture repeats and offsets.

I did explain to Hamlet that I was already aware of the texture based clocks, but the disadvantage with those is that problems with asset server lag, slow connections, packet loss, will leave you with a fuzzy/grey clock which won't tell you the time, or a pixelated clock which looks a bit icky.

So on one hand you have prim-based clocks (analogue and near-analogue) which will be able to tell you the time when everything is all grey, and on the other you have texture based clocks which have the distinct advantage of having a highly intricate design with much less prims than you'd need.

HOWEVER. textures are limited to 1024 by 10244 pixels, and with a llSetTextureAnim() option your texture will be mostly empty transparent space, meaning the appearence of the clock hand won't be in as high fidelity as possible. Texturing a llTargetOmega() based hand would allow you to get the best looking clock possible.

So.... basically we're still waiting to find out who the first person to make a true analogue clock was, NOT the first person to make a clock that hands and ticked.

[Jackson Widget]

I believe that the linden telehubs had clocks that worked, but no secondhand, just minute and hour.

[SignpostMarv Martin]

Hmm. Now who wants to zoom in real close and check if they tick or rotate :-P

[Jamie David]

They are nice but not the first with moving second hands. many makers have created propper clocks with working hands. Second ones as well. :-)

But to get around the troubles of the modern world I present you with an interesting idea. One clock for all. One hand for each time zone. :-0 Works well. 24 hour clock. with once glance you have an idea of what time is is for all.

Would put one on your wall but can na find it so sent it to you. Enjoy.

[SignpostMarv Martin]

@Jamie David

They are nice but not the first with moving second hands. many makers have created propper clocks with working hands. Second ones as well. :-)

Myself, Hamlet, and everyone else is quite aware of this- we'd like to find out who was the first though.

[Jamie David]

Long before me. I made the clock a year ago and there were 2 others that had made their versions. One was not exactly a moving hand but a turning dial.

For me the troubles were that they were set to SL time which was not a lot of use to me as there is a clock in the top right hand corner of the screen. I wanted the time on the beach in Bora bora. :-)

So sorry I can not give you more info. I might still have the others clocks in archived inventory. Will have a gander laters.

:-)

[SignpostMarv Martin]

Heh. Good luck with that Jamie, I know how hard it is to find long forgotten inventory items :-)

[Vi Paravane]

I think there's a misunderstanding about what an "analogue" device is. "If it ticks, it's digital" is not correct.

Back before digital wristwatches and radio alarms with LCD digit displays, all clocks and watches were analogue. The display with pointers and numbers around a dial is inherently an analogue display. The driver for these displays was a mechanism of springs, gear wheels and cog wheels. These pieces do not count anything, they just move in a rhythmic fashion. They are analogue, even if the movement of the second hand appears discrete.

These days, you buy quartz-crystal clock movements and quart-crystal wristwatches, which have ditigal counters that accumulate microseconds and then set off a solenoid that moves a pointer (or changes a digital display element). The only mechanical parts of this are the solenoid and the dial; everything else is digital.

When a quartz wristwatch clicks off a second, that is the result of a digital operation. When a mechanical wristwatch does it, that is still an analogue process.

Keyword: 17 jewels.

[SignpostMarv Martin]

Let me rephrase:

If the quantification of motion of a device has a finitely predictable Nyquist frequency, then the *motion* is digital.

Meaning:

If it jumps from point to point it is digital

If it moves really quickly from point to point, then pauses and so on, it is analogue

If it is in a constant state of motion, it is analogue

I was making an over-generalisation that those devices that tick are those that jump from point to point ala llSetRot(). Getting a clock hand to move from point to point would require either physical motion (llApplyRotationalImpulse() or some really freaky use of llTargetOmega()), which is why I made the generalisation.

Show me a clock that moves and ticks as opposed to jumps and ticks. (in-world of course :-P )

[David Seikel]

SL is a digital medium, your analogue clock still moves in discrete steps, they are just shorter than one second. You are splitting hairs with your definition of analogue.

Try this - digital clocks show time using digits, analogue clocks show time using angles. Works for the rest of the computer industry.

[SignpostMarv Martin]

While that is true, llTargetOmega() is for client-side smooth action, so the number of steps taken will increase with the frame-rate, mean the number of steps taken is not finitely predictable.