random touch to rotate wheel

[cykablyaidinarhui]

Hey all! i'm in need of some assistance. So i've built a Mesh "Musical Impressions" wheel for a Karaoke scenario in SL, and what i'm looking for is a script that can rotate two separate wheels on touch, that will then slowly come to a stop after a random amount of seconds between 1 and maybe 10. 

  I'm not a scripter and so don't have the first clue about how to do this. I'll link a picture to give an idea of what it looks like. There is an outer wheel and an inner wheel, that as i said, need to rotate in opposite directions.

If anyone can help it would be greatly appreciated  

[Xiija]

If you will need to get the specific section each wheel has landed on,

mebbe change the number of sections from 32 to 36... so your movement can be in

10 degree intervals?.. if it's all visual, you could just use llTargetOmega ? ... http://wiki.secondlife.com/wiki/LlTargetOmega

and change the spinrate in a timer event?

a pretty ambitious project for someone who is not a scripter

[Berksey]

I'm seconding the ten-degree thing, it could really make it a lot easier if it isn't crucial to have exactly that many sections to each wheel.

And I think the project is really cool, too. I wanna see it when it's finished.

[Qie Niangao]

I don't know that it matters a great deal whether the intervals are integer (10) multiples of degrees because the rotation will be specified in radians, so converting to / from degrees seems like just another step.

As for the spinning itself, it may turn out to be easier to push frequent PRIM_ROT_LOCAL updates with llSetLinkPrimitiveParamsFast() on the PRIM_LINK_TARGETs corresponding to each wheel. To make that smooth will take a lot more script time and network traffic than llTargetOmega, certainly, but unless there's something I'm missing, llTargetOmega doesn't make it obvious how far the spinning has progressed. If the object is non-physical, the spin doesn't even affect server-side rotation, and if it's physical (in my very limited experience) the spin "unwinds" itself at the end, reverting to the original rotation. Maybe there's a way to avoid that.

[ETA: For whatever it's worth, out of desperation in the past I've kept careful track of how far the object should have spun in the time it was spinning, and pushed a single corresponding PRIM_ROT_LOCAL update when turning off PRIM_OMEGA. But there may be a tidier, less compute-intensive solution.]

Edited April 25, 2018 by Qie Niangao

[cykablyaidinarhui]

First of all thank you SO much for replying with your advice so far, all of you...

To reply to Xiija, i think your understanding of what i'm looking for is a script that would land on the very specific centre of a colour on the wheel. But i'm not.   Just like in real life if someone was to spin the wheel, there would be no telling where it would stop at all. It would be completely random, and may even land of the line between two of the colours. (By the way the coloured sections will soon have the names of singers and songs) I'm simply just looking for a script that will rotate for X amount of seconds and then eventually come to a halt. I suppose the main part of that is I want it to be completely random in what amount of seconds is chosen so that it would be rare to land on the same two that have been chosen previously. To make it even less likely to land on the same 2 (just like a Roulette wheel) i chose to have them spin in opposite directions (i'm not sure if Mathematically that makes a difference, but for visuals it would look kinda trippy and cool)  

To Berksey, I think perhaps the same as above might apply to the 10-degree idea. Since really all I want it a simplistic random wheel spin. And for sure! i'll update the post with a gif image if possible, or you may even come over and take a look yourself if you like. The sim name is Cloud Sixx and i'll link a SLurl too. http://maps.secondlife.com/secondlife/Rainbow Dream/199/165/21

To Qie, i have not a single clue how to respond to that but I thank you for your response on this.  

 

 

Edited April 25, 2018 by cykablyaidinarhui

[Ruthven Ravenhurst]

What about doing  texture animation? You wouldn't need to figure out which spot it lands on after. You could get a random number and random amount of time, then do the math to figure out on how fast it should turn based on how many rotations you want it to go through before landing on the pre-determined spot. Then after doing the visuals, then announce the spot it's landed on. My brain is a little fried as I just got back from work a little bit ago, but I got as far as.....

Say you're starting on spot #5, and want it to land on spot #13. You want it to spin at least 5 times before landing on the pre-determined spot. So it needs to spin 5.25 times to get to the spot. Then you have it determine a random amount of time, say 10 seconds. so it needs to spin at 1.904 seconds per rotation. Not sure at the moment how to turn that into the spin rate for llTargetOmega and I've never really messed with the rotation of llTextureAnim to determine the rate for that either (maybe it's the same?)

Edited April 25, 2018 by Ruthven Willenov

[Rolig Loon]

5 hours ago, Qie Niangao said:

and if it's physical (in my very limited experience) the spin "unwinds" itself at the end, reverting to the original rotation.

I'm not sure that's right.  I believe it's exactly the opposite.  Since the servers are aware of what's happening to a physical prim, they ought to know where it ends up when it stops spinning and not "unwind" at all, unless I am misunderstanding your use of the word.  I'm away from home now, so I can't even pop in world to do a quick experiment.  I suspect, though, that if you could make a spinning disk that is physical, animate it with llTargetOmega for a random number of seconds, and then stop it, the servers would be able to figure out exactly which segment was pointed up, or whatever direction your pointer is aimed at..

That said, I'm intrigued by Ruthven's idea.  Rotating the texture instead of the wheel sounds a lot less chancy.  Just use llSetTextureAnim in ROTATE mode and make the texture rotate for a random time. When it stops, translate the total number of rotations into an angular measure to figure out which segment is "up".

[Qie Niangao]

5 hours ago, Rolig Loon said:

I suspect, though, that if you could make a spinning disk that is physical, animate it with llTargetOmega for a random number of seconds, and then stop it, the servers would be able to figure out exactly which segment was pointed up, or whatever direction your pointer is aimed at..

With further testing -- and a closer reading of the wiki -- this is correct for the root physical prim. I'd been testing child prims in a physical assembly, however, and I now realize those behave more or less as if they were non-physical, with only viewer-side changes to rotation.

For non-physical prims, the viewer doesn't show that snapping back ("unwinding") effect if the spin is halted using a "spinrate of 0 with a nonzero gain" as the wiki says. A physical root prim also stops that way, but (oddly enough?) a spinning child prim in a physical assembly does seem to snap back to its original local rotation despite the omega being halted with a nonzero gain.

All of which is pretty deep in the weeds here. I too am drawn to the texture animation approach, although like non-physical omega, it requires keeping track of how far the "spin" should have progressed during the time the viewer-side effect is shown, so they're kind of similar, with omega showing the whole prim spinning, not only one texture-animated face.

[Xiija]

Here is a small omega snippet for the OP to test with, mebbe see if Omega is what they are lookin for?

( this assumes a cylinder, flattened and rotated onto its  edge)

integer k;
float rate = 5.0; // initial spin speed
float adj = 0.5;  // how much to slow down each timer pulse
float rand;
default
{
    state_entry()
    {      
    }
    touch_start(integer total_number)
    {
       if( k = !k)
       {   rand = llFrand(3.0) + 1.0; // random time each spin
           llSetTimerEvent(0.2); 
       }
       else                         // turn off / reset
       { llSetTimerEvent(0.0);
         llTargetOmega(ZERO_VECTOR, 0, 0); 
         rate = 5.0;
       }
    }
    timer()
    {  llTargetOmega(<0,0,1>*llGetRot(), rate, 0.5);
       rate -= adj;                                  // slow down each timer pulse
       if ( rate <= 0.5)
       {  llSetTimerEvent(0.0);
          llTargetOmega(ZERO_VECTOR, 0, 0); 
          rate = 5.0;    
          return;             
       }
       llSetTimerEvent(rand);
    }
}

 

Edited April 26, 2018 by Xiija
added return in timer

[cykablyaidinarhui]

Once again thanks everyone for responding further!  I've been at work so it's taken a while to reply sorry about that. Xiija I have tested out the script that you provided on the wheel and it works very well! i did notice however that unless i click it after it has completed it's random revolutions, it will continue to re-spin. BUT!, i actually really like this!! it means that everyone who is involved can try to select their OWN artist dependant on the colour they know it is on. The chances of them clicking at the exact right time, i would imagine is pretty hard to do, so thank you very much!!! <3

I have just realised something that might possibly be considered a bug?? im not sure... but after screen sharing with my girlfriend in SL, it seems that the texture is not appearing in the same place as we are seeing on our own screens  Any ideas on this?? 

We took a screnshot at the same time and this is what we see...

http://prntscr.com/jakkac <--- Mine

http://prntscr.com/jakkbc <--- Hers

Very strange.. i've never noticed this before.

 

And just one other thing, what part of the script would i need to edit Xiija, to have the wheel spin in the opposite direction?

Ignore this part, i just turned the wheel 180 degrees and it works

Thanks so much for your help so far!!

 

Edited April 26, 2018 by cykablyaidinarhui

[Ruthven Ravenhurst]

1 hour ago, cykablyaidinarhui said:

I have just realised something that might possibly be considered a bug?? im not sure... but after screen sharing with my girlfriend in SL, it seems that the texture is not appearing in the same place as we are seeing on our own screens  Any ideas on this?? 

We took a screnshot at the same time and this is what we see...

http://prntscr.com/jakkac <--- Mine

http://prntscr.com/jakkbc <--- Hers

Very strange.. i've never noticed this before.

This is because, as mentioned above. On a non-physical prim, llTargetOmega is client side, not serverside. You could though, after it stops it's spinning, set it to a random rotation with llSetLinkPrimitiveParamsFast, and then it should update to look the same on both screens

[animats]

Oh, you want to make one of these.

See it here.

They did a nice job on this. It moves the way you want, and the script knows where the wheel ends up. 

If you do this with llTargetOmega, the rotation is client side, and scripts have no idea of the position of the object. "Physical" is a property of the entire link set, so you can't have the base be non-physical and the wheel be physical. Nor does SL do rotational joints. So the easy way to do this won't work.

You probably have to set angular position with llSetLinkPrimitiveParamsFast and PRIM_ROT_LOCAL. That means running a timer and explicitly setting the rotation for each time tick. This is a pain, but it gives you full control of the wheel, so you can rig the game. 

Edited April 27, 2018 by animats
Remove bogus link