Clocks, Clocks, Clocks: 3 Questions

I think I've read all of the forum posts on clock-making. Requisite "I am not a programmer and I am just learning LSL" statement. I still have a few questions:

1. I understand that most clocks are made using llSetTextureAnim for the hands. How is it possible that separate avatars will see the correct time, upon arrival, i.e. when the texture loads, short of incessantly resetting the animation w/ a timer event, or using some sort of llSensorRepeat to account for a nearby avatar, since texture animations are handled by the client? Anyone care to share their method?

2. How do you get around the z-clipping (disappearing textures) when using transparent prims for the hour, minute, and seconds? I tried offsetting the prim rotation by 0.01 (that was the least I could offset, it seems.) Do I need to offset more or move the prims further apart?

3. When resetting a llSetTextureAnim rotation, is the texture's start position now based on wherever it was positioned in the client?

Any help would be appreciated, and to preempt Rex Tardis who seems to show up in every clock scripting thread I want to make it myself, but I'd love to chat about your scripting technique or any other opinions, ideas, etc. Still, feel free to pitch your clocks here for others who might be looking for just such a thing. It's a convenient idea for any builder who wants to incorporate one

i use llSetRot() for my analog clock ..... the big one has prim hands that work fine (a box cut to .375 and .875 so its effectivly cut in half then rotated around the center of it) .... but for the smaller clocks i would use llSetTextureAnim() to make it smoothly rotate between rotations but every min or every half a min do a call to llSetRot() then another llSetTextureAnim() (just so it lines up right) so its set right to the client.

for #2 my prim hands have no problems .... but for smaller clocks i dont think there is one surefire way to get the textures to work right together .... sorry heh ...

and for #3 ... no ... when you call llSetTextureAnim again it will reset the rotation of the texture to the begining

Actually, that's not true. When making multiple calls to llSetTextureAnim, the texture's perceived rotation will not reset (unlike llTargetOmega). There are some objects in-world that use this technique to make a scrolling or rotating texture appear to speed up or slow down smoothly. If you wanted to reset the texture's rotation, I'm thinking you would need to stop the animation, call llRotateTexture, and start the animation again... though I'm not in-world to test it, so I could be wrong about that.

Have you talked to Francis Chung at all, Claudius? She could probably give you some helpful pointers if she's not too busy.

See, that's what I thought about question #3. I actually included a touch_start to reset the animation, just to test it, and it was giving me results that seemed as if it were consistent w/ not resetting to the original rotation. (Although last night, it seemed completely inconsistent and random, but maybe I was just tired and not thinking straight.) I figured I would have to write in a reset myself.

I haven't talked to Francis Chung, but I've got a short list growing of people to bug. I'll add Francis now and blame it on you.

Hey, she's the one who scripted all those watches and got famous for it. She brought it on herself!

Pfft... stupid people, having fun creating stuff and showing/giving/selling it to others. When will they learn?

With regard to using llRotateTexture, would I call llRotateTexture(0.0, 0); ???

I am rotating the texture on side 0, but would 0.0 return the texture to it's original position, or am I still stuck in client land here? Would that just cause it to not rotate at all?

EDIT: llRotateTexture(0.0, 0) does put it back to the original rotation. Now if I can just kick this disappearing texture problem.