llSleep( ) seems to slow down llTargetOmega( ) - huh?

[Domitan Redenblack]

llSleep( ) seems to slow down llTargetOmega( ) - huh?

I thought targetOmega ran in the local client machine, so should not be affected by llSleep( ) - yes?

 

[Madelaine McMasters]

---

Domitan Redenblack wrote:

llSleep( ) seems to slow down llTargetOmega( ) - huh?

I thought targetOmega ran in the local client machine, so should not be affected by llSleep( ) - yes?

 

---

Yep, llTargetOmega() is executed in the viewer. Is it being called repeatedly by something involving llSleep()? If so, you may be seeing stutter as the viewer restarts the rotation. Can you give a more detailed description of what's happening?

[Rolig Loon]

Is your object physical?  If so, the llTargetOmega motion is server-side, which means that it can be detected and altered by scripted commands to the servers, like llSleep.

[Madelaine McMasters]

Oooh, I like this explanation.

[Domitan Redenblack]

Object is not Physical...

I also have another timer running already, so chose llSleep( ) here.

I want a titler to fade in, hold text title, then fade out:

 

myFadeTitler(string lsMessage, float lfFullyVisibleTime) {    //    integer i = 0;    while ( i++ <= 10 )         llSetText( lsMessage, gvColor, i/10.0 ); llSleep(0.05);        llSleep( lfFullyVisibleTime );        while ( i-- >= 0 )         llSetText( lsMessage, gvColor, i/10.0 ); llSleep(0.05);    }

 

[Madelaine McMasters]

I'll guess that the rotation update to the prim gets stalled by each prim update. At 20/second you notice it. Maybe you can put the title on an invisible prim that's linked into the set?

[Domitan Redenblack]

More info...

It's not the lfFullyVisibleTime that causes the TargetOmega to spin slowly, it's the fade in and fade out.

Any ideas about how to do a fade-in-out that will not hit the spin so hard?

Each time I change the floating title, even without fade, the spin jerks some...

Thanks

 

[Void Singer]

that up to your viewer.... it's not the call causing it, it's the update to the hovertext (which is also a client side effect)

[Domitan Redenblack]

---

Void Singer wrote: that up to your viewer.... it's not the call causing it, it's the update to the hovertext (which is also a client side effect)

---

Do you all see a glitch when hovertext is updated in your viewers?

I am using the latest Phoenix viewer which is running around 40 fps, so I would think that hovertext could be updated in a few milliseconds - not enough to cause a glitch...

[PeterCanessa Oh]

while ( i-- >= 0 )         llSetText( lsMessage, gvColor, i/10.0 ); llSleep(0.05);

 

Not what you meant, surely?

If you do not include braces around a statement-block then only the FIRST statement is executed in it - so this is equivalent to:

 

while ( i-- >= 0 ) {        llSetText( lsMessage, gvColor, i/10.0 );}llSleep(0.05);

 You need to include the sleep in the braces if you want to slow down the fade-effect

[Domitan Redenblack]

Yes, I copied down the code wrong. Of course there were braces around the two statements for each loop.

[Void Singer]

I can't test at the moment =/