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

Someone should write a memo to the pointy hairs that copy-botters frequently sell for very low prices, and sometimes even free. Then, when they blink and maintain their perpetual look of confusion, exaplin that 5% of nothing is nothing. and nothing is less than something... and something is good

For a non-networked vendor, the kind that have the itms inside it, the items need to be copy/trans perms at least. You don't want to sell your entire inventory with copy/trans perms to random people on the marketplace, I promise.

Yes those were tabs. My scripts are lousy with them as I use exclusively tabs for space, but I do 100% of my editing in notepad++ the only thing's my inworld script see is an incldue statement, and maybe a few variables if I want to make several variations. You can do the same thing in reverse if you paste characters notepad++ can't handle in to it from the lsl editor. "●" and "○" for example if I recall correctly.

I have worked with mesh that had this issue before, if you use a script to change any alpha on it, you will also see that rigged mesh "flicker" off in to space beside you before it moves back wher it belongs. -I know that NOT uploading joint positions resolves the issue. You should almost never include joint positions in your upload, that are used for when you are defoming the avatar, like a non humanoid or no human sized creature. I itried recreating the issue myself but have not managed to make it happen, One hing i have not tried however is trying to wear MULTIPLE rigged meshes each with joint positions... Are you uploading each foot seperately? since they are riged they can be One object.

Are you uploading with joint positions and have you moved the origion of your armature from between its' feet?

[disclaimer] I am not a lawyer and thisd is not legal advice [/disclaimer] DMCA take downs are ONLY a mechanism for you to inform a third party (LL) that they are facilitating infringment. The proper response for that third party is to remove the content you report unless the individual you file a claim against files a counter claim. They can at their discression impose further penalties agasint the reported account if they feel it is in the best interest of their service, for example to ban a repeat offender. At most they can try and go after the culprit for breaking TOS. They can not take legal action based on your copyright, only you can do that if you desire. Wilful determined infringers cannot be stopped by technological means, just ask the infamous RIAA / MPAA.

I have no idea why my own searches did not turn up this page, but a friend helpfully clued me in. Here it is for any future hapless searcher. http://blog.machinimatrix.org/avastar/avastar-animation-priorities/

background info: I just started working on animations in qavimator. I made a 2 frame pose that only affects my left arm. bones involved: lCollar, lShldr, lForeArm,lHand. (these bones are posed and should be locked in place) All other bones are unmodified. (limber, should be animateable freely by other anims/poses) I uploaded this animation at priority 4, relaxed hands. looping 100% in and out. When I play the animation alone it works. When I am standing still it works. If I walk, or sit. I can't see the animation anymore. Animation Explorer shows it as "still playing" So it must be getting overriden by my normal AO walk/sit anims? Questions: -Are AO makers really uploading dinky walks and sits as priority 4? -If not why are they overriding my pose.? -If they are, how do over devices overcome this issue? I am aware of many attachments that maintain priority over these same AO animations.?

every time before you rebuild your list you need to start from empty. changed (integer change){ if (change & CHANGED_INVENTORY) { //here before you start adding things to you list Jmenu = []; if (llGetInventoryType("Rooftop") != 0) Jmenu += ["Roof Top"];} if (llGetInventoryType("Front Yard") != 0) { Jmenu += ["Front Yard"];} if (llGetInventoryType("Extra Decor") != 0){ Jmenu += ["Extra Decor"]; } }}

The best you are going to be able to do is request the PRIM_POSITION/PRIM_ROTATION of the link you are replacing. list l = llGetLinkPrimitiveParams(LINK_NUMBER_BEING_REPLACED,[PRIM_POSITION,PRIM_ROTATION]); vector p = llList2Vector(l,0); rotation r = llList2Rot(l,1); llRezObject("Object",p,ZERO_VECTOR,r,0); It will be better than rezzing in your chest, but it will never look 'right' because the information avalible to lsl is Animation Agnostic.