Domitan Redenblack

Void Singer wrote: ...and on the note of representation.... a (3 number) vector can describe a point, a direction (and distance or speed) from zero, or even the facing of a flat plane (and size or speed), but you need another number to tell you what way a particular edge of the plane is facing... In this case, we always assume the face is perpendicular to the vector <a, b, c> from the origin.

Domitan Redenblack wrote: So will this do it then? // This DOES work: llSetPrimitiveParams( [ PRIM_ROTATION, ZERO_ROTATION, PRIM_ROTATION, llEuler2Rot( x, y, z ) ] ); I'll tell you what is "hard" - you have a spining square. It is tilted at a weird angle, but not too far from vertical. You want to show a texture with english text on it, "right side up". For humans, it's easy to adjust the rotation of the face to be "mostly upright" while leaving the square tilted as it was. In LSL, I think that would take some thought and some careful coding.

So will this do it then? llSetRot( ZERO_ROTATION ); llSetRot( llEuler2Rot( x, y, z ) );// How about this? llSetPrimitiveParams( [ PRIM_ROTATION, ZERO_ROTATION, PRIM_ROTATION, llEuler2Rot( x, y, z ) ] ); :matte-motes-agape: Got it! This is what we do in RL, but all in one motion, object in hand, reaching to set it on the table. For us though, we do not worry about the order of rotations, do we? The end result we get, is the Same as the end result in this animation, but we do it in hidden steps. In fact, I have a nice little Swarovsky crystal which I played with when thinking about this thread. I afixed an X label on the positive-X side of the crystal, and a Y label on the positive Y-side. The point at the top of the crystal serves as the positive-Z direction. In our minds we see the desired end result, with 0 steps involved. Just a final position relative to the world (or desktop). Does this final position require a process of steps? No. To place the crystal into that position does require a set of steps, but ONLY due to the fact that the crystal is in a different position when we start. And it may be in any position at all when we start, makes no difference to us. Only the end position matters, and it is an absolute, and unique as well. Running z-angle, then y-angle, then x-angle as a process minimizes those steps, but from the ZERO_ROTATION, which we do not require in placing the actual crystal on the desk. The end position in our minds is not dependent on the starting position of the crystal, so in our minds has a fixed set of pitch, yaw, and roll which we can present to LSL, yes? We cannot do this since rezzing the object from inventory remembers some other position, and LL only provide us with a process to turn the object AFTER we rezz it. Thus, in SL we need a two-step process (zero then rotate) to move the object into the single final position we desire, which is in our minds with 0 steps.

So, what you are saying is there is no way to Set a pitch, yaw and roll polar coordinate, but instead I must MOVE to a polar coordinate relative to the current pitch yaw and roll? "Gimble lock" does not matter if you are SETTING an absolute polar coordinate, but DOES matter if you have to do a rotate motion from where I am now to a given polar coord? --> In SL brain-damage world, there is no way to set a polar coordinate for an object, you can only issue a relative rotation order from your current position. If that is the case, then you must llSetRot(ZERO_ROTATION), then llSetRot(rotation_I_Want) ? Is there a way to set absolute SL world pitch, yaw and roll in One Step?

Hmmm... "With standard 3-axis (Euler) rotations, you run into situations where the math blows up." I don't use math when I lay a dinner table, or put out the trash, and my head has never blown up. I don't think yours has, either. Actually, I don't actually want to Rotate anything, which implies motion. What I want is to set pitch, roll and yaw, easily and simply, JUST like the Edit window. What LSL function would do this, equivalent to the edit window?

I did a bunch of tests, and if you use a linked prim which is centered on the main spinning prim, then both prims spin, and Hovertext can be faded in and out of one without the other one stuttering its spin. I think.

"You can think of a quaternion as four numbers, three of which represent the direction an object is facing and a fourth that represents the object's banking left or right around that direction." Huh? "Left" or "Right"? You mean clockwise or anticlockwise? I read the pages in the Wiki, and honestly, I still cannot fathom Rotation. There are no pictures at all in the Wiki explanations, like sex using semaphore really. I fully understand the Edit window's X, Y, Z angles as absolutes, they make sense, so why use Rotations? Is there a way to just set X, Y, and Z angles as absolutes, like in the edit window, in LSL? Honestly, in RL and SL, human beings (and even some animals) set out a thing in a direction, period. Everyone in the world gets this. Why make it difficult?

Revised question (llSleep was not the problem): Is there any way to fade in/out Hovertext without slowing spinning objects? I find that even displaying Hovertext on and off, without fading, still causes spinning objects to jerk a bit sometimes.

Rufus, that is great work, but you must wear a HUD, yes? If so, then it is not of interest to me at this time, thanks.

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

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...

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

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); }

llSleep( ) seems to slow down llTargetOmega( ) - huh? I thought targetOmega ran in the local client machine, so should not be affected by llSleep( ) - yes?

Nope, was look for a way to truncate notecards' names to 24 chars for a Menu dialog. I will have to warn those wishing to create notecards for the item to limit the names to 24 chars.

Is there any way to Rename an item in inventory via LSL script?

Rolig Loon wrote: "Trick" is maybe a loaded word. :smileywink: Void's suggesting a perfectly honest strategy. llSetRot doesn't work well if you are making tiny adjustments, but it handles large adjustments just fine. All she's saying is to make an easy large adjustment and then undo it, instead of making a small one that will probably fail. "Exactly!"

Void Singer wrote: <0.0, 0.0, 1.0, 0.0> is a rotation that is 180deg around the z axis (since you are spining on Z it's the axis that's least noticeable)... what that does is takes the current physical rotation (myRot) and flips it 180deg on Z then sets it back... this combats both the effect of not being able to set the same rotation, and the effect of a rotation not being large enough to show as an update to the viewer. Pardon me, but are you saying this is a "hack" to trick the viewer into doing what we want?

Void Singer wrote: you said upright... (which would be zero rotation, unless you specify a different one) if you want same direction the grab the rotation first and use that like so... myRot = llGetRot(); llSetRot( <0.0, 0.0, 1.0, 0.0> * myRot ); llSetRot( myRot ); if you want to be really sneaky you can call the first two right after you start target omega, and the last line after you turn omega off. what turning physics on and off was doing was making the viewer see the physical position (the rot wasn't doing anything) but the problem with that is that making it physical will slowly corrupt it's position and rotation. Ah, I see. Thanks. Explain if you will, the "<0, 0, 1, 0> * myRot" rotation... It keeps the current Z but zeros everything else? How do you know to use <0, 0, 1, 0> ? What if the rotation of the disk is not aligned with X, Y or Z world axes? Thanks!

Nope, Void, sorry. This works: llTargetOmega(ZERO_VECTOR, 0.0, 0.0); //resets Omega to pure zero. llSetStatus(STATUS_PHYSICS, TRUE); //turns it physical (if it wasn't already) so it can rotate llSetRot( ZERO_ROTATION ); //resets disk rotation to pure zero. llSetStatus(STATUS_PHYSICS, FALSE); //turns physics off again if required and this does not: llTargetOmega(ZERO_VECTOR, 0.0, 0.0); //resets Omega to pure zero. llSetRot( <0.0, 0.0, 1.0, 0.0> ); llSetRot( ZERO_ROTATION ); * Without the Physics, the disk goes flat face up, not facing same direction as before change.

WADE1 Jya wrote: llTargetOmega(ZERO_VECTOR,0.0,0.0); //resets Omega to pure zero. llSetStatus(STATUS_PHYSICS,TRUE); //turns it physical (if it wasn't already) so it can rotate llSetRot(llEuler2Rot(DEG_TO_RAD * ZERO_VECTOR)); //resets your rotation to pure zero. llSetStatus(STATUS_PHYSICS,FALSE); //turns physics off again if required This works great, except the image is upside down. Can I rotate it 180° ? Editted: Hmmm..... Sometimes it goes upside down, sometimes correctly upright... Seems indeterminate?

I have a prim spinning around its Z-axis via llTargetOmega( ) I want to stop it spinning, and have it end up "upright" I have fiddled with llSetRot( ) and llSetPrimitiveParams( ), but these don't see to do what I want. Help please! ty

Void, as I stated earlier: I have friends who own parcels which are "full" and want an easy way to find the names and prim counts of objects on their land. It's not always obvious or remembered, exactly which are the prim-fat objects they have out. Area Search in viewers does not list the prim counts for objects, so I thought I would cobble up a way to get a list of "What's on my Land and how Fat is is?"

Rolig Loon wrote: That's a separate problem. You either move your scanner from point to point until you have sampled every part of your sim or you set up a network of scanners. Either way, you need a way to gather all the information the individual scans, remove any redundancies, and then compile the summary list. As Void says, that's a real pain if your sim has a lot of objects in it, especially if the number of objects keeps changing all the time or if they are sometimes crammed into subregions with more than 16 objects in them. I have to agree with her that it's probably not worth the trouble to do on a sim-wide basis. Terminal fail. Thanks for your help.

Rolig Loon wrote: Ummm.... Your script scans for all objects in scan range...... llDetectedKey(i) gives you the UUID of each object .... llGetObjectPrimCount(llDetectedKey(i)) gives you the number of prims in the object. ..... llDetectedName(i) gives you the name of the object. How hard is that? default{ touch_start(integer total_number) { llSensor("","",PASSIVE|ACTIVE,10.0,PI); } sensor(integer num) { integer i; for (i=0;i<num;++i) { llSay(0,llDetectedName(i) + " " +(string)llGetObjectPrimCount(llDetectedKey(i))); } }} Awesome, Rolig. But how do you get around: llSensor: "Only 16 objects will be scanned each time."