Ruthven Ravenhurst

I had thought about that approach, but while this example would be a small scale use. I also have another project that would need the function to work this way. I haven't tested it yet, but I have an idea that might work for it. In the state entry, I would store a global owner key. In the changed event I would check the stored key against the current LlGetOwner. If it is the same, then I'll know it was the above scenario that triggered it,and not the new owner rezzing it. If it is the new owner rezzing it, I would update the stored key, and still allow the changed event to trigger again when the user buys the object ETA: Yep. Tried that idea, and it worked as I'd hoped. Now I wonder if the changed owner event triggering the way mentioned above is supposed to happen that way, or just a happy accident?

I'm having trouble using the changed owner event in a script that is intended to die when the event is triggered. I have a bowl of jelly beans. a use touches the bowl. It rezzes out a bean. communicates to the bean a random flavor and color. user touches to buy a copy of the bean. the user gets a copy in their inventory, the changed owner event is triggered in the still rezzed copy. The still rezzed copy dies, and the bowl of beans waits for another touch to rez a new one the problem I'm having is, if I send the bowl of beans to someone. and it rezzes out a bean, the changed owner event is automatically triggered I could set a default state to listen for the flavor/color, changed to a buyable state, and put the change event there. but then how would I prevent it from triggering again when the end user eats (attaches) it?

Qie Niangao wrote: vector pos = llList2Vector(ray,1)+<0,0,-bottom.z>; That was the first thing I tried, but it was putting the object under the surface. Qie Niangao wrote: may be closer to what you have in mind, but this is ignoring everything about the actual shape, its rotation, and the slope of the surface, which could make this arbitrarily complicated to figure out precisely. Incidentally, about precision, it seems llCastRay may be less precise the larger the surface it's casting towards. I'm not sure why or how that can even be true, but it's what I'm seeing (very informally). I thought about that too. I ticked the option to show bounding boxes in my viewer to make sure it was where it was supposed to be. The bounding box is where it should be (it's a mesh object), but it's not moving the object where I want I did a work around by attaching a flat square mesh with a LI of 0.5 (it didn't add anything to the LI of the object), as one would add a prim shadow to something. I made that the root prim, and just used the detected surface position to set the position

Dora Gustafson wrote: The conditions for llAxes2Rot() are not fullfilled: "All three vectors must be mutually orthogonal unit vectors." :smileysurprised::smileyvery-happy: I don't know what that means, I don't know much about 3D math, expecially rotations, but I do know it works for me

here's a script I came across in this forum (or the old forum?) years ago. I even tested on sculpties at the time, and it works wonderfully. As you the attachment reference, I wonder if you could attach a number of nails that would be hidden, and move them to the local position ETA: here's the link to the post. Wow, that was a while ago! http://forums-archive.secondlife.com/54/89/334263/1.html vector offset = <0,0,0.1>;default{ touch_start(integer total_number) { vector tchnorm = llDetectedTouchNormal(0); vector tchpos = llDetectedTouchPos(0); vector rezpos = tchpos + offset*llAxes2Rot(<0,0,0>,<0,0,0>,tchnorm); rotation rezrot = llAxes2Rot(ZERO_VECTOR,ZERO_VECTOR,-tchnorm); llOwnerSay("Touched."); llRezObject("Object",rezpos,ZERO_VECTOR,rezrot,0); }}

the script is in the root, I just can't seem to figure out the right math formula to figure out the offset I should apply to the position. I've added, subtracted, divided the different vectors a bunch of different ways trying to figure out the right offset, and I can't seem to get it. i'm sure there's just one little step i'm missing, or something i have backwards somewhere. the current script I have is a mess, so don't mind that, but currently it ends up moving it some distance below the desired position. some way I had it calculated earler was close to where I wanted, but still slightly above, and I can't remember what I did to get it default{ state_entry() { list ray = llCastRay(llGetPos(),llGetPos()+<0,0,-3>,[RC_DETECT_PHANTOM,TRUE]); llOwnerSay(llDumpList2String(ray,"|")); list bb = llGetBoundingBox(llGetKey()); llOwnerSay(llDumpList2String(bb,",")); vector top = llList2Vector(bb,1); vector bottom = llList2Vector(bb,0); vector center = (top+bottom)/2; vector mypos = llGetPos(); vector pos = llList2Vector(ray,1)+<0,0,center.z>; llSetPos(pos); }}

I have an object that, when rezzed (from my inventory), floats some distance above the surface it's being rezzed on. I'm using llCastRay to find the surface height. I got that position just fine, the problem is, the root of the object being moved isn't centered within the bounding box, and the biggest prim is a child prim. I can't seem to figure out the right formula to use the bounding box info and the root's position to determine the offset to move the object to sit on the surface

Was thinking like a "Marco"-"Polo" type game llGetAttachedList could work too if the object is no mod to where the name/description can't/won't be changed. In that case I would put some identifying name/number to look for in the description field You could use llGetObjectDetails and run through the list of attachments and get their descriptions. If one or more has the same identifying string, then it's a match and they already have the attachment attached

Sure, but what if they're both attached to the skull using Add instead of Wear

I would decide on a specific word, outside of any other commands you might use for it, and have it say it on attach/rez. It would also listen for the same word. If one is attached, and hears the word from a second one, it can respond with another word to let it know it was there first

That shouldn't be too hard for an experienced scripter. Are you looking to write your own script, or looking for someone to do it for you? I imagine it would work like any other vehicle/non-physical vehicle. The question would be, who do you want to control it? The rider, or one of the walkers? Also for it it look right, the walkers would need to be the same height, otherwise you might have someone with a pole imbedded in them, or floating above them

to cut off only the trailing zeros without specifiying the number of decimal places, you could use a while loop, starting at the end of the float cast to a string, find the first non-0, the capture the string to that place. if it doesn't have any trailing zeros, it will never cut any off and still return the whole string string fltstr(float num){string numstr = (string)num;integer len = llStringLength(numstr);integer i;while(len){len--;if(llGetSubString(numstr,len,len) != "0")//when we come to the first trailing number (or decimal point) that is not a 0{numstr = llGetSubString(numstr,0,len);//capture the string to the index we found the first non-zerolen = 0;//exit the loop by changing the len to zero(FALSE)}}return numstr;} Edit: Fixed the line to capture the string length, had llStringLength(num); It is now llStrengLength(numstr); as it should be

written off the top of my head, not in world to test it string flrstr(float num, integer places)//the number to be cut, and how many decimal places you want{ string numstr = (string)num;//converts the float to a string integer idx = llSubStringIndex(numstr, ".");//finds the decimal place numstr = llGetSubString(numstr, 0, idx+places);//captures the string from the beginning to the the number of decimal places specified return numstr;}

yeah, i see that I made it a little confusing say object one is using a health/stamina/strength stats system and object2 is using a clan/age/security level stats system. it wouldn't make sense to me to create a whole list of all the stats for each avatar, cast it to a string, update the value, then query their stats, desconstruct, update the individual stat as necessary, resconstruct, and update the value 3 ways I can see to structure it is avatar kvp = avUUID, [healthm, stamina, strength, clan, age, security level] then each script would have to break down the key value, list replace the appropriate index with the stat update. recast the list to a string, and update the value or. as you suggested, stat kvp = "Health", [av1uuid, av1healthvalue, av2uuid, av2healthvalue, etc...]then the script would query the health for everyone, break down the value to a list, llListFindList the avuuid, get/update their stat in that list, recast to a list, and update the whole list of healthvalues or, the way I did it is string id = (string)llDetectedKey(n);key healthupdate = llUpdateKeyValue(id+"health", "5.0", FALSE, "");key staminaupdate = llUpdateKeyValue(id+"stamina", "3.5", FALSE, ""); and so on this way it creates a key for each stat for each avatar, and only needs to look it up with key healthquery = llReadKeyValue(id+"health");

I'm finding a lack in experience script example and not sure what is a typical way to structure key values. I see that it is fed a string or a uuid cast as a string, rather than a key. For one script's use of the experience keys, I can see how that would be just fine to create a key value for the avatar uuid alone, but for multiple scripts that will look for varying type of info, i don't think it would be practical to update the key value for all the scripts in order to update one piece of a comma separated value. For example in a health/stamina/power meter. Would it make sense to append the specific type of value to the uuid and create/update the value for that? for example for avatar1 it would be string keystr1 = (string)avatar1key; string av1health = keystr1+"health"; and so on for each other type you're looking for and then define a different global dataserver key for each value being looked up like: key avhealthquery; key avstaminaquery; key avstrengthquery; etc. I can see that being ok in a hud where it's only looking for the wearer/owner's stats, but what about a sim object that needs to look up the stats of multiple avatars?

And of course, after rotating the model to the right orientation, the offset to the head will be different

I basically just want the reference prim to spit out a position and rotation offset, which I can then copy and paste to the appropriate settings on the u-poser hud

Hi, I'm using U-Poser to create an animation. Since animations use the hip as the root, I'm trying to figure out how to simulate using the head as a root. I have rezzed a prim, and made it the same size//shape/rot/pos as the head on the model. I want to set a timer to check the orientate of the head on the model, and tell me how I should move/rotate the root so that the model head matches the reference prim. I hope that makes sense. I think it's probably a math formula, but I'm not great at 3D math, so I'm not sure which order to calculate the different values to get the result I need. The problem is, the root of the model is actually the platform on which it is standing. The hip joint is what rotates the avatar, and the Root (not the object root, but avatar Root) is what sets the position

copied from one of my threads https://community.secondlife.com/t5/LSL-Scripting/Listener-or-flow-issue/td-p/3061744 Rolig Loon wrote: Heh... You're right. I should have decrimented num at the end of the loop, not at the start. You should reach num = 0 then. Sorry about that. Oh, and I'm following a common practice of identifying glocal variables with the "g" prefix. When I am more careful, I also use a prefix of "i", "s", "f", "k", "v", "r", or "l" to identify the variable type. It can be easy to get confused about what your variables are when they are scattered over several hundred lines of code, so a helpful label can be important.

in the on_rez event you're opeing a listen, but in the changed event, if it's a new owner the script is being reset, basically removing that listen. in the touch event you have it open the same listen, so until the new owner touches the rezzer, it won't be able to listen for anything. the thing is, there's nothing here that seems to rely on the owner, so the changed event seems un-necessary. I would move the llListen to a state_entry, or use a llListenRemove, which also seems un-necessary as it's still going to listen on the same channel, otherwise it will continue to stack listens, and you'll get a too many listens error.

Right, the OP was trying to avoid that. And though the script will shout an error, it won't know it in the case of triggering an event. I like Nova's suggestion above, you'll still get the error shouted if it can't rez, but setting a timer for 5 seconds or something, and then turning that off if the object_rez event does get triggered: rez an object - if the object_rez event doesnt trigger within a few seconds you can not rez (or you didnt wait long enough for the delayed rez due to the heavy lag)

Another thing I hadn't considered, is I think you can set group roles to allow/disallow rezzing depending on the role. I'm not sure that can be checked

Within the script, where you would want to rez something, you would put: if(is_rezzable(llGetPosition()) { //Code for rezzing something } else//we can't rez, do something else { //Code for doing something else. This part is optional, I use it to do a particle effect in place of rezzing for some of my scripts }

Right, that's what this is for. It checks for various rez abilities before actually trying to rez. First if the land allows rezzing, if not, checks to see if the owner of the rezzed is the same owner of the land. If not, it then checks if the rezzer is set to the same group as the land. If they all fail, it doesn't attempt to rez

If the land is set that way, yes. But the first test checks to see if ANYONE has rez perms, if yes, then it doesn't move on to the other tests. This doesn't take into consideration if they have it set to auto-return after some time, but I assume if you're not in the group, the object being rezzed would just be temporary anyways, either by llSetStatus, or with a timed llDie