Monica Balut

I just saw your teaser video. I'm excited. I'm just learining Blender and animating with it. The blend file you just posted produces a bvh I can actually upload to SL from Blender 2.61. I have yet to find any otther product that can do that. I'm eager to see your finished product. Can I bug you about a time line for release?

Nice work Optimo. This is the only Blender ready made rig that I have been able to find that works with 2.61. I can get a bvh file that I actually can upload to SL without any problems. Any chance of making a female avatar version? ;-))))

Found it! It was in AppData\Local\VirtualStore\Program Files (x86)\Phoenix Viewer\character. I'm using a Win 7 64 bit system. It doesn't show up just in Program Files (x86). It's in the user's VirtualStore version of that folder instead.

You're suppose to be able to create a file called "new archetype.xml" by using Develop->Avatar->Character Tests-> Appearance to XML. My understanding is this file is created in the Character folder under that viewer in Program Files (Windows). You're suppose to be able to use this to import your shaped into a 3D editing program like Blender as the basis for your animations. I understand this only works with a shape you have created. I've tried doing this with all my viewers: SL, Firestorm, Phoenix, Imprudence and Kirsten. The file never seems to get created. What may I be doing wrong?

Thanks. I was able to delete it. Must be a griefer put it there. It was named Laced bra and panties LOL. When I selected it and deleted it, it went away.

Recently patches of tall grass have begun growing out of the surface patch on my property. These are not objects that have been placed there since I can't select them. More importantly how can I get rid of them. (no jokes about a weed whacker)

I also posted this as a JIRA. Thanks to Maestro Linden who suggested it could be a hardware problem. It turns out that the problem originated from my Space Navigator. I upgraded the driver, unplugged and replugged it, and the problem went away. I would have never thought of this in a million years.

Thanks folks. Fact is I haven't used Phoenix regularly in close to a year. That option is not available is most of the viewers I have. It has nothing to do with being in a no fly zone. It happens everywhere. And the fact that it happens with 4 different viewers and 3 diff alts tells me it's not the viewer. This is really puzzling. Others can't seem to reproduce it though.

1) I don't remember ever seeing a preference setting to fly after teleporting. Where would that be? 2) Void I tried your suggestion but it doesn't seem to make any difference in this case. I just end up hovering a bit higher up. I've never encountered this before in the over 4 years I've been in SL. It does behave like a server side problem but it doesn't seem to happen to everyone. I posted a JIRA about it. SVC-7376

Perhaps someone here knows the answer to this. For the last few weeks, whenever I log in or just TP to another region, I always end up in a hovering state and must explicity click on Stop Flying to get back on the ground. I don't think it's viewer related since it doesn't matter what viewer I'm using. It also happens with my alts. And it doesn't depend on what region I'm in. So I suspect it's a server side issue. Has anyone else had the same problem and, more to the point, has anyone found how to fix it?

Yeah I guess. I'm rotating a 8m disc at about 20 degrees per second and it looks choppy with llSetRot. If the prim is much smaller it's not as noticeable. I had always assumed that the 0.2 sec script delay would delay the triggering of the timer event as well. From Void's code, I assume I was wrong about that.

I just had a chance to test out your version, Void, using llSetRot. I find the rotation to be very choppy. My version using LLSLPP is a lot smoother, although untested in lag.

Nice work Void. I was trying to avoid using the llSetRot because of its 0.2 sec delay. Whenever I used that, the rotation was rather jerky. Why not use llSetLinkPrimitiveParamsFast as I did which makes it a lot more smooth.

//This is set up so touching the target causes it to say its position //It ain't pretty but it works. //I'd appreciate any rotational gurus who could clean this up and perhaps post it in the library //I also cross posted this on the other thread I created related to this project //Monica Balut integer CHANNEL = -45; float SPEED = 0.4; //degrees per sec float TIMERPERIOD = 0.1; integer lc; float radianSlice; integer nSteps; rotation incRot; rotation remainderRot; integer index; MyRotLookAtConstantRotSpeed(vector targetPos) { vector discPos = llGetPos(); // postition of the object to be rotated, in this case an object whose root prim is a disc vector relativePos = targetPos - discPos; //-- make the target position relative to us relativePos = llVecNorm( <relativePos.x, relativePos.y,0.0> ); //in world coordinates-- remove the height difference and convert to unit vector rotation desiredRot = llRotBetween( <1.0, 0.0, 0.0>, relativePos); //-- get the rotation that faces our target vector eulerDiscRot = llRot2Euler(llGetRot()); // get the disc's current world rotation in a vector form vector eulerDesiredRot = llRot2Euler(desiredRot); // the target's world rotation in vector form float radiansBetween = eulerDesiredRot.z - eulerDiscRot.z; //-- signed angle between current rotation and target rotation. if (radiansBetween > PI ) radiansBetween = radiansBetween - 2*PI; else if (radiansBetween < -PI) radiansBetween = 2*PI + radiansBetween; // this keeps the rotation angle < PI and gets the correct sign radianSlice = ((SPEED / TIMERPERIOD) * DEG_TO_RAD); // absolute value of radians to be turned at every inc. Rotation direction will be handled below; if (radiansBetween < 0.0) radianSlice = - radianSlice; nSteps = (integer) (radiansBetween / radianSlice); incRot = llAxisAngle2Rot(<0.0,0.0,1.0> , radianSlice); // the rotation to be done at each timer step float remainderAngle = radiansBetween - nSteps*radianSlice; // the last angle to be done when it's almost there remainderRot = llAxisAngle2Rot(<0.0,0.0,1.0> , remainderAngle); // convert to a rotation around z nSteps = llAbs(nSteps); index = 1; llSetTimerEvent(TIMERPERIOD); } default { state_entry() { lc = llListen(CHANNEL,"","",""); } listen(integer channel, string name, key id, string msg) { vector targetPos = (vector) msg; MyRotLookAtConstantRotSpeed(targetPos); } timer() { if (index <= nSteps) { llSetLinkPrimitiveParamsFast(1, [PRIM_ROTATION, llGetRot()*incRot]); index ++; } else { llSetLinkPrimitiveParamsFast(1, [PRIM_ROTATION, llGetRot()*remainderRot]); llSetTimerEvent(0.0); } } }

Thanks for your input. Here's what I was able to come up with. The idea is a llRotLookAt clone that rotates the object at a constant speed thru the smallest angle. It's not pretty but it works. I would welcome any rotation gurus to have a shot at simplifying it and cleaning it up and perhaps post it to the library. //This is set up so touching the target causes the target to say its position on channel -45 integer CHANNEL = -45; float SPEED = 0.4; //degrees per sec float TIMERPERIOD = 0.1; integer lc; float radianSlice; integer nSteps; rotation incRot; rotation remainderRot; integer index; MyRotLookAtConstantRotSpeed(vector targetPos) { vector discPos = llGetPos(); // postition of the object to be rotated, in this case an object whose root prim is a disc vector relativePos = targetPos - discPos; //-- make the target position relative to us relativePos = llVecNorm( <relativePos.x, relativePos.y,0.0> ); //in world coordinates-- remove the height difference and convert to unit vector rotation desiredRot = llRotBetween( <1.0, 0.0, 0.0>, relativePos); //-- get the rotation that faces our target vector eulerDiscRot = llRot2Euler(llGetRot()); // get the disc's current world rotation in a vector form vector eulerDesiredRot = llRot2Euler(desiredRot); // the target's world rotation in vector form float radiansBetween = eulerDesiredRot.z - eulerDiscRot.z; //-- signed angle between current rotation and target rotation. if (radiansBetween > PI ) radiansBetween = radiansBetween - 2*PI; else if (radiansBetween < -PI) radiansBetween = 2*PI + radiansBetween; // this keeps the rotation angle < PI and gets the correct sign radianSlice = ((SPEED / TIMERPERIOD) * DEG_TO_RAD); // absolute value of radians to be turned at every inc. Rotation direction will be handled below; if (radiansBetween < 0.0) radianSlice = - radianSlice; nSteps = (integer) (radiansBetween / radianSlice); incRot = llAxisAngle2Rot(<0.0,0.0,1.0> , radianSlice); // the rotation to be done at each timer step float remainderAngle = radiansBetween - nSteps*radianSlice; // the last angle to be done when it's almost there remainderRot = llAxisAngle2Rot(<0.0,0.0,1.0> , remainderAngle); // convert to a rotation around z nSteps = llAbs(nSteps); index = 1; llSetTimerEvent(TIMERPERIOD); } default { state_entry() { lc = llListen(CHANNEL,"","",""); } listen(integer channel, string name, key id, string msg) { vector targetPos = (vector) msg; MyRotLookAtConstantRotSpeed(targetPos); } timer() { if (index <= nSteps) { llSetLinkPrimitiveParamsFast(1, [PRIM_ROTATION, llGetRot()*incRot]); index ++; } else { llSetLinkPrimitiveParamsFast(1, [PRIM_ROTATION, llGetRot()*remainderRot]); llSetTimerEvent(0.0); } } }

Since I'm abandoning using llRotLookAt, I've started another thread trying to do this iteratively, but I'm stuck there too. I'd appreciate some help with the Finding the Signed angle post subsequent to this. Thanks I really do hate rotations!!!!

Object A is the reference object. It views the world in the direction of its local positive x axis. Object B will be in its periphery. I eventually want to rotate object A so it points to object B amd I'm trying to do this at a constant speed of rotation For a variety of reasons llRotLookAt won't work so I'm looking for a work around (see my previous post: llRotLookAt while controlling rotation speed.. The algorithm I created almost works. At one point I use llAngleBetween to calculate the angle between them. However llAngleBetween does not provide the sign of the rotation. I'm stuck trying to find a way that wil give me the sign of the angle that I must use to rotate object A so that it rotates clockwise or counter clockwise. BTW thanks to Void Singer for pointing me in the right direction to start this. Let me try to show you the code so far. It does produce a nice smooth rotation float SLICESIZE = 2.0; //degrees to be rotated at each step float TIMERPERIOD = 0.1;  //globals float radianSlice; integer nSteps; rotation remainderRot; float rotSign; rotation incRot; integer index; RotateObject(vector targetPos) { vector discPos = llGetPos(); vector relativePos = targetPos - discPos; //-- make the target position relative to us relativePos = llVecNorm( <relativePos.x, relativePos.y,0.0> ); //in world coordinates-- remove the height difference and convert to unit vector. This constrains the rotation to be around the z axis //********This is where I'm stuck. Since relativePos gives a vector in world coordinates, this give wrong results for rotSign below. What I need here is to find the sign of the angle betweewn the local forward (x) facing vector of object A and the target. With that, the code would work find. I just can't wrap my head around how to do this. if ((relativePos.y) >= 0.0) rotSign = 1.0; // do rotation clockwise if (vectorAngle >= 0.0) rotSign = 1; // do rotation clockwise else rotSign = -1.0; rotation desiredRot = llRotBetween( <1.0, 0.0, 0.0>, relativePos); //-- get the rotation that faces our target float radiansBetween = rotSign * llAngleBetween( llGetRot(), desiredRot ); //-- angle between current rotation and target rotation float degreesBetween = radiansBetween * RAD_TO_DEG; nSteps = llAbs((integer) (radiansBetween / radianSlice)); float remainderAngle = radiansBetween - nSteps*rotSign*radianSlice; incRot = llAxisAngle2Rot(<0.0,0.0,1.0> , radianSlice*rotSign); remainderRot = llAxisAngle2Rot(<0.0,0.0,1.0> , remainderAngle*rotSign); index = 1; llSetTimerEvent(TIMERPERIOD); } default { state_entry() { lc = llListen(CHANNEL,"","",""); radianSlice = (SLICESIZE * DEG_TO_RAD); RotateObject(SOME TARGET VECTOR); } timer() { if (index <= nSteps) { llSetLinkPrimitiveParamsFast(1, [PRIM_ROTATION, llGetRot()*incRot]); index ++; } else { llSetLinkPrimitiveParamsFast(1, [PRIM_ROTATION, llGetRot()*remainderRot]); llSetTimerEvent(0.0); } } }

Thanks for the attempt Void. The function I had posted does indeed rotate the object correctly, as does yours. However, the strength and damping factors don't work as expected for non physical objects. Any value for damping and any value for strength > 0.001 produce the same effect: the rotation just snaps into postion. Any absolute value for Strength < 0.001 fails to rotate it at all. If the object is physical however, the parameters do work fine. I'm thinking there is something wrong with the function or it's not meant to be used on non-physical objects although that is not documented. I think I'm going to have to roll my own on this one. I'm gonna try an iterative approach, rotating a few degrees at each step of the iteration, probably from within a timer event.

Take a look at this. It will move an object from it's present location to a target in a straight line at a constant speed. The series of target points are hard coded in a list called path. It will also rotate the object so its local x axis faces its direction of motion. In this case motion is activated by /111 goto x where x is the index of a path vector. float EVENTTIME = 0.1; float SPEED = 5.0; integer lastStop; vector currPos; vector targetPos; vector pathVector; integer currTargetIndex = 0; vector incrementVect; integer nSlices; list path = [ <89.58290, 41.27910, 2010.63500>, <89.5829, 6.2823, 2010.63500>, <119.58150, 6.2823, 2010.63500>, <119.58150, 21.28410, 2010.63500>, //room 1 <119.58150, 51.28470, 2010.63500>, //room 2 <119.58150, 81.28490, 2010.63500>, //room 3 <119.58150, 106.28520, 2010.63500>, <104.59000, 106.28520, 2010.63500>, // room 6 <74.58280, 106.28520, 2010.63500>, //room 7 <44.57620, 106.28520, 2010.63500>, //room 8 <29.6, 106.30, 2010.63500>, <29.60000, 106.28520, 2000.64200>, <29.60000, 81.28430, 2000.64200>, // room 9 <29.60000, 51.27620, 2000.64200>, //room 10 <29.60000, 21.26800, 2000.64200>, //room 9 <29.60001, 0.00000, 2000.64100> // unload area ]; MoveToPos(integer pathIndex) { currPos = llGetPos(); targetPos = llList2Vector(path, pathIndex); pathVector = targetPos - currPos; float pathDistance = llVecMag(pathVector); float thisPathTime = pathDistance / SPEED; nSlices = llRound(thisPathTime / EVENTTIME); incrementVect = pathVector / nSlices; llRotLookAt(llRotBetween(<1.0,0.0,0.0>, llVecNorm(<targetPos.x,targetPos.y,currPos.z> - currPos)),1.0,1.0); llSetTimerEvent(EVENTTIME); } listen(integer channel, string name, key id, string msg) { if (msg == "gotostart") { MoveToPos(0); } else if (llGetSubString(msg,0,3) == "goto") { string strNum = llStringTrim(llDeleteSubString(msg,0,3),STRING_TRIM); if (IsInteger(strNum)) { integer index = (integer) strNum; if (index != currTargetIndex) { currTargetIndex = index; if (currTargetIndex >=0 && currTargetIndex <= lastStop) MoveToPos(currTargetIndex); else llSay(0,"Invalid position."); } else llSay(0,"Already at that position."); } } else llSay(0, "Invalid command"); } timer() { if (nSlices > 0) { currPos = llGetPos(); llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION, currPos + incrementVect]); nSlices --; } else { llSetTimerEvent(0.0); } }

Ok I'm pulling out all my hair trying to figure this out. Damn I hate rotations! I want to rotate a cylindrical platform with about 45 prims, whose root prim is just a disc at it's center, so it's local forward x axis points to another object in its periphery. The following works perfectly fine to accomplish the rotation. vector objPos = <IN WORLD VECTOR COORDINATES OF THE OBJECT); vector discPos = llGetPos(); llRotLookAt(llRotBetween(<1.0,0.0,0.0>, llVecNorm(<objPos.x,objPos.y,discPos.z> - discPos)),1.0,1.0); Since the platform has many prims, I cannot make it physical. Unfortunately, the strength and damping parameters do not seem to have any effect controlling the rotation speed of a non-physical object. It just snaps to the new direction no matter what values I use. I'd like to control the speed of rotation so it looks more natural. Can anyone point me to some function or algorithm that would accomplish that? I did a search of this forum and the scripting library and nothing jumped out at me as being useful.

Thanks for the info folks. I've sent out notices to warn my customers. At least I know it's not me.

Do you have a JIRA reference? When was this introduced?

I had built installer system last spring where a rezzed installer would give animations from its inventory to a HUD worn by the owner of the installer. The relevant code in the installer looked like this: if (nAnimations > 0) { for (i=0; i<nAnimations; i++) { animName = llGetInventoryName(INVENTORY_ANIMATION,i); llGiveInventory(HUDid,animName); } } (nAnimations and HUDid are obviously defined elsewhere) It all worked fine. Simialr code later gives notecards to the HUD. All of a sudden in the last couple weeks. The code stopped working. I get script error messages saying the HUD has refused the animations. The notecards are still being transferred ok though. If I rez the HUD on the ground, it all works fine again and animations get transferred. So something has obviously changed, most likely in server code since this happens no matter what viewer I'm using. So before I post a JIRA on this, I'd like to ask if anyone has ever used similar code to have a rezzed object give animations to a worn HUD. This was the first time I had used llGiveInventory in this manner and wonder if there was just a loophole in the function during the time I happen to be developing this that allowed it to work for a time. There is no mention of not being able to transfer animations in this way in the WIKI nor mention of any problems in the JIRA. I know you could never just manually load animmations to a worn HUD and was happy to see I could do it via llGiveInventory. Now it has all blown up.

Thanks Void. Unfortunately, what I am after here is for the new name to appear in the personal inventory so the user can distiguish it from other copies. It seems that there are only two solutions. One is to have the user make a copy of the original boxed version before it is rezzed and rename that one in the inventory. Otherwise s/he has to rez it to rename it. I was hoping to make this easier for the user.

By using llSetPrimitiveParams([PRIM_NAME, "new name"]) I can change the name of worn HUD via script. If I look at the Name field in the Content window, can clearly see the name has been changed. The only problem is the name change does not persist when the HUD is detached. It reverts to the old name. I haven't tried llSetObjectName but I suspect it will behave the same way. Is there any way to get a name change to persist if done on a worn object? Changing the name in the inventory does not work on no modify objects. I suspect that the only way to do it is to actually rez the object on the ground. :((((