Aspire Rang

Actually all facial expressions are built in animations. you can write a script that Stops those animations without too much trouble. it will mostly keep them expressions limited but it's a nasty brute force solution, lacking utterly in elegance. \ Look to eliminating the source first of possible.

[Trying to detect avatars 2m in front of me without using a Sensor] If you need to be extremely precise you can always cast a few rays. Alternatively if you want to be extremely simply you can just compare the distance of each avatars positon to a point exactly 2 meters directly in front of you. OffsetTestPosition = mypos+<2,0,0>*myrot; llVecDist(OffsetTestPos,RandomAvatarPos) will tell you how close they are to the designated point.

Innulal: Sitters do not signify for center of mass. Because they can't be sitting onrez when center of mass is calculated. Dorex: As for simulating the link-after-rez solution it's possible but not practicle. The root prim would need to have link permissions and then you could rez the components as a complex object that would then link itself.

It's been some time since I got irritated enough with this particular failure to sit down and work out the issue. As far as I recall it's a dispute over the center if rotation between viewer and sim. One if then is trying to rotate properly around the objects ROOT while the other is rotating around the objects center of mass. Edit: thus the snarkiness happens when the viewers apparent rotation is snapped back to where the server says it should be repeatedly. The issue is further complicated by the fact that center of mass is basically only calculated on rez. So you will not have any trouble with single prim objects as it's ROOT is it's center If mass. But you will almost always have trouble with multi prim objects. But it will APPEAR to work while you are building. It will turn in to a screwed up mess only after you are finished and save it to inventory. When you rez it the center if mass will be recalculated and no longer match the objects ROOT. So your script is unlikely to be the source of your problems.

The state of marketplace is revealing, that and the state of content creation tools. Issues like the mesh uploader Still not properly manageing simple things like origin/root points in models. Forcing creators to waste effort on thousands and thousands of creations to jurry rig around the flaw. Jury Rigs that will be wasting grid and user resources for all of SL's remaining life. The tools are irritating, but the state of Marketplace is disheartening. Not because it sucks, which it does, but because said suckage demonstrates that LL has STILL not realized that Marketplace represents their only real option for monetization going forward. Putting togeather a team and learning to create a first rate marketplace would be an investment in SLNext just as much as SLNow. Instead LL seem stuck treating the world we all love as a Country Club, trying to profit from membership dues, as though that model has not historically been SPECIFFICALLY DESIGNED TO LIMT PARTICIPATION.

I don't think you can maintain sessions (login.) So you would not be able to get your calender data directly in world unless you can make it publicly accessible somehow.

Can't imagine what on earth could possibly posses LL to tell this community ANYTHING. LL could announce a free cure for cancer and we would have one community complaining about reduced revenue from casket sales. Another community screaming in fear of mandatory injections. Despite the announcement specifically mentioning that the cure comes In pill form and will be completely voluntary.

A notification that a particular uuid is no longer in your inventory is not a big deal. At the rate suggested of a sale every few minutes it would be less traffic than keep alive pings. On the same order of magnitude as existing notification to the viewer of lindens being added to the account every time a sale is made. Of course it's possible to impliment poorly.. like redownload your entire inventory sans this one item! But no reason to expect that will be the case.

#1.) You are not multiplying by an ANGLE you are multiplying by a ROTATION 2.) You are not MULTIPLYING at all, this is the root of most of the rotation agitation in SL. you are using the * operator, but it is polymorphic, it does different things based on what arguments you passd it. When you are dealing with rotations read * as Rotated By and / as DeRotated By

No, not automatically. You would have to use a bot to do something like that.

The shooting up thing would just be an issue with the objects using different axis. I'm not sure what could make it miss while the target is motionless as the Velocity would be ZERO_VECTOR I sent you a copy of the object I was playing with in world. If that is still giving you trouble hit me up inworld.

>I have another annoying issue I can't solve so I thought I'd ask here again... I have two potential ways but both seem to arrive to the target location late. You are calculating where they will be at launch, not where they will be when the projectile reaches them. Calculating intercepts is a function of position and time. time is NOT lsl's strong suit. in adition to time dialation and other sorts of sim lag. it's not real time and your function may be interupted at any point. That being said You can still do some fun things. I have a script I was playing with I will post here float speed = 100;float travelTime;float lastTime;//deals with latency so long as it remains consistentfloat cooldown;rotation intercept(vector vTarget,vector vVel) {//GUESTIMATE INTERCEPT llResetTime(); vector vPos = llGetPos(); float travelTimeTemp = llVecDist(vTarget,vPos)/speed+lastTime; vTarget+=vVel*travelTimeTemp;//estimate intercept point float travelTime = llVecDist(vTarget,vPos)/speed+lastTime; vTarget+=vVel*(travelTime-travelTimeTemp);//estimate intercept point with more accurate time float fDistance = llVecDist(<vTarget.x, vTarget.y, 0>, <vPos.x, vPos.y, 0>); return llRotBetween(<1, 0, 0>, llVecNorm( < fDistance, 0, vTarget.z - vPos.z > )) * llRotBetween(<1, 0, 0>, llVecNorm( < vTarget.x - vPos.x, vTarget.y - vPos.y, 0 > ));}default{ state_entry(){ llSensorRepeat("",llGetOwner(),AGENT,25,TWO_PI,1); } sensor(integer num){ rotation r = intercept(llDetectedPos(0),llDetectedVel(0)); llSetRot®; if(cooldown < llGetTime()){ llRezObject("targeting round",llGetPos(),<speed,0,0>*r,r,(integer)(travelTime+2)); lastTime = llGetTime(); } } no_sensor(){ llSetRot(ZERO_ROTATION); }} You can compensate for the inevitable accuracy with the method that was previously mentioned, a self correcting projectile, or using a proximity fuse. You can also use a BIG projectile. including an invisible "hitbox" prim if you are concerned with the visual effects. Or something I am going to try right now... perhaps an array of soft linked projectiles... Anyway that's part of what makes SL so fantastic. Figuring out ways to achieve the effect you want, sometimes in ways you hadn't even considered when you began.

I dunno. What are ya offering?

What an amazing non-issue. If you don't want merchants telling you how to blog, don't ask for or accept free merchandise. It's only a problem when you start trying to work in "How can I get free stuff, and not be a big name, and not deal with demands all at the same time." As a merchant you have no power to make someone not review your product on their blog but if they come to you asking for a freebie, neither are you obligated to provide it. If you are so inclined you can provide frebies with strings attached, but again, you only have power to the extent the bloger wants free stuff. Welcome to modern capitalism, where it's not a bribe as long as you use another word for it.

irhapeti's mapping cuts the calculation time for that section by half, so it would bevery beneficial to apply it to the first section as well. but the spread is very likely to be a float and needs to be adjustable, so bitwise operations are probably not in the cards for that part. compared to that my only suggestion is peanuts, but you should be converting your accuracy to radians when it's set, not inside your action loop. saves one multiplication per iteration. float half_spread = rez_spread*-0.5;vector spreadVector = < llFrand(rez_spread)+half_spread, llFrand(rez_spread)+half_spread, llFrand(rez_spread)+half_spread>;//When accuracy is changed, or stored it should be converted to radians at that time//DEG_TO_RAD*accuracyrotation rotBetween=llRotBetween(<0.01,0.01,0.01>,<0.01,0.01,0.01>+(accuracy*(spreadVector*llGetCameraRot())));integer map = (integer)llFrand(16);rotation modRot = llGetCameraRot() / < rotBetween.x * (-1 + (map << 1 & 2)), rotBetween.y * (-1 + (map & 2)), rotBetween.z * (-1 + (map >> 1 & 2)), rotBetween.s * (-1 + (map >> 2 & 2))>; llRezObject(bullet,llGetCameraPos() + (rez_offset + spreadVector)*llGetCameraRot(), llRot2Fwd(modRot)*velocity, modRot,100);