Innula Zenovka

The line is as I posted it -- llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_NAME]); Note the [ square brackets ] round [PARCEL_DETAILS_NAME]. They are there because lsl uses them to enclose lists, and, as you will see if you look more closely at the wiki article, llGetParcelDetails requests a list of details about the parcel -- you're using it to request a list with only one item, but you could just as easily be asking for details of the description, owner, size, and stuff at the same time, so the request has to be presented as a list, and lsl knows something's a list if it's enclosed in square brackets. Since you've asked for a list of details about the parcel, you get a list in reply, albeit one with just one item, so you will need to decode the list, using the format llList2String(my_list,0); That means "find the first item in the list (lsl starts counting at 0, not 1) and turn it into a string so you can say it, or display in hovertext or whatever. Tl;dr -- you need the [ ] round PARCEL_DETAILS_NAME or it won't compile, and you need to turn the results of the call into a string so the script can do something with the parcel name when it knows what it is.

The syntax is llGetParcelDetails(vector pos, list params); So something like this should do the trick. default{ state_entry() { //llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llOwnerSay(llList2String(llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_NAME]),0)); }} ETA -- what this means is that llGetParcelDetails takes two arguments -- the vector location of the parcel whose details you want and a list of the various possible details you want it to tell you. It returns a list of what those details are -- it has to be a list, because you might be asking for the parcel description, or its owner or area or whatever as part of the same call. In this example, you're only asking for the description, which is a string and is the first (and only) item in the list that's returned, so you change it into a usable string with llList2String(list, 0) -- "find the first item in the list and return it as a string".

Another way to do it would be to turn the listener on and off each time you wear it. This way, though, it's only going to listen to you when it's worn: integer g_intListenHandle;default{ state_entry() { updateParticles(); } attach(key attached) { if (attached!=NULL_KEY){ g_intListenHandle=llListen(5,"",attached,""); } else{ llListenRemove(g_intListenHandle); } } listen(integer channel,string name,key id,string message) { if(message=="fall on") updateParticles(); else if(message=="fall off") llParticleSystem([]); else llOwnerSay("usage:\n/5 fall off\nor:\n/5 fall on"); }}

Are you getting this annoying message everywhere, or only on one particular sim? Try TP-ing somewhere else and see if that stops it. Then TP back to where you were before and see if it starts again. You see, one reason you'd get this message is if you rezzed the item rather than wore it as a hud or attachment (and when you say it's not appearing in your inventory, that makes me wonder if you rezzed a no-copy item). The only fix, if that is the case, is to try to find the item, take it back into your inventory and wear it. If you are on a private island, the owner or someone with estate rights should be able to locate it for you, and return it, using the estate management tools. I don't know how it works on the Mainland, though.

As Blackdog suggests, it sounds like you need to update the listener to listen to the new owner (I'm assuming, since it's a dress, only the wearer can talk to it). Try dropping this changed event into your script -- there are more elegant ways of doing it, but without seeing the script, this is all I can suggest that I know will do it. changed(integer change){ if(change & CHANGED_OWNER){ llResetScript(); } }

When I had two adjacent islands, I sometimes used Ezian Ecksol's Camjumper script to get between the two of them. That goes in an attachment, finds your destination by where your camera is, and then calls llMoveToTarget repeatedly to move you there very fast -- so fast that you normally blast through apparently solid objects with ease. I don't know, but I'm wondering if the same method wouldn't get you from sim to sim if you sat on something that used it. I know warppos looks as if it should, but doesn't do it at all reliably, so I'm not sure how well the physical equivalent would do. Though, as I say, when called from an attachment it always worked well for me.

I've just copy-pasted your code into a touch_start event and it works fine. As the others say, it must be some other cause.

Thanks, everyone. Void's method seems ideal, combining the advantages of both. There's one thing I don't understand, though. If I set TEMP to FALSE when I sit down and then back to TRUE when I stand up, does the timeout period always restart or does it depend on whether the initial timeout period has expired while TEMP was FALSE or what?

Why do some people see Ruth, still, and most of us see clouds? I know you can -- or used to be able to in 1.n -- to change a debug setting to get Ruth back, but it's not the sort of thing you'd do without realising it, I would have thought. Sometimes, come to think of it, I see people as Ruth very briefly when they''ve TPd to where I am and are still rezzing (like still in the air), but not very often.

I'm making some items, containing animations, that people can rez from a hud. I want the items to delete themselves after use, but not immediately (so that if the user clicks the wrong button and unseats him- or herself, there's a grace period to get back on). What's safer -- start a timer on rez and start, reset and stop it in the changed event, or do the same with PRIM_TEMP_ON_REZ (or doesn't it matter?)?

What a horrible thing for someone to make. Your friend, I am afraid, doesn't sound like a particularly nice person -- particularly because if he or she knows enough to make something like that, he or she must also know that an experienced RLV-user like me would realise very quickly that something was amiss, possibly as soon as they attached the piercing (if they've got RLV debug messages turned on, which I have a lot of the time), and know to relog without RLV, get rid of the thing and AR him. So his intended victims must be the naive and inexperienced.

As Vania said, the only way that someone can force-tp you somewhere and prevent you from leaving is if you're using a third-party viewer with RLV enabled and if you're also wearing something that's designed to let people force-tp you and and stop you leaving (i.e. just using and RLV viewer and enabling RLV doesn't do much in particular) and (at least with any legitimate RLV product) that you've explicitly told the thing you're wearing that people can use this functionality on you. The simplest way for your daughter to check if she's got RLV turned on or not (and people do get confused sometimes) is for you to send her an IM while she's online, simply saying "@version" (without the quotes -- just @version on a line on its own). If RLV is turned on, she won't receive the message but you will receive an automatic reply with details of the version she's using. Then she can simply turn it off and relog, or use the official LL viewer. If anyone does find themselves in a predicament from which they can't, because they're using RLV, extricate themselves, there's always a very simple solution. Either turn off RLV in the viewer's preferences and relog or simply log out and relog using the official viewer. But, as I said, the only way this can have happened with RLV is if she's wearing something designed for role-play that's let it happen. If she'd like to IM me (here or in-world) I can probably help her identify the item and tell her how to use it safely.

Kenbro Utu wrote: So you have to update the sit target as the child prim moves. That could qualify as a pseudo-trick. :smileywink: Well, sort of. Except you aren't updating the sit target at all (that doesn't have any effect while the avatar is seated, you see). The UpdateSitTarget function by Strife Onizuka and Escort DeFarge (which poseball-free animation systems like nPose and Perfect Sitter use) uses llSetLinkPrimitiveParams to move the avatar about in the way we've all wanted to when we've said, "If only you could update the sit target when someone's sitting". I took their calculations and method and played round with them a bit to get the platform child prim and the avatar sitting on it to move together to the correct end positions without drifting too far apart in transit.

In that case, so long as you're careful about what order you turn things on and off, I think llMove2Target should do what you want. When I'm stopping stuff, I always turn physics off first, before I do anything else, and when I'm starting I always turn it on right at the end of calculating everying, just before I start moving again. And if I'm making the object phantom, then I don't do that, if I can help it, until I'm actually moving. The not_at_target event, which is called constantly while you're moving, is a very good place to check if you're where you think you should be and to take any necessary corrective action. As a general point, I would suggest putting a listener in your moving physical object when you're testing it , though, that either turns physics off and uses posjump to bring the object back home, or simply kills it, and having a simple prim by you, which calls something like llRegionSay(some channel, "where the **** did you go?") when you touch it. I have learned this the hard way.

Drega Riddler wrote: Well, the reason for not being physical is that i am going to have no track, so if it were physical it would just fall correct? I don't really understand. Why should it, unless you set it to phantom while it's physical and not moving? Certainly if you set it to phantom and then stop llMove2Target without turning off physics first it goes through the floor, as I have many times proved without intending to, but so long as you're careful about doing stuff in the right order it should be ok. The main advantage to having tracks, other than the cosmetic ones, is that it's an easy way to place the beacons the train has to look for. But you're going to need to set those somehow in any case.

I looked at Strife's UpdateSitTarget again, and had a play and, rather to my surprise, managed to come up with this -- called from the root prim -- which seems to do it. I'm not competely sure I've done it right, but I tried rotating the "platform" prim on which I sit round on its z axis and ended up in the right direction, which was what worried me a bit. ETA -- it needs resetting before you first use it, I have realised, in order to set prim_pos. It would be nice to reset it when the links change, but that's going to mess stuff up when the avatar gets off. I'm sure there's a simple solution, but if you use it, be aware that the script needs resetting before first use. vector sit_target =<0.0,0.0,0.5>;//same as the sit target set in the platform primrotation sit_rot = ZERO_ROTATION;//same as the sit target set in the platform priminteger platform;integer toggle;key av;vector offset;vector size;vector prim_pos;find_prims(){ integer max=llGetNumberOfPrims()+1; while(max--){ if(llToLower((string)llGetLinkPrimitiveParams(max,[PRIM_NAME]))=="platform"){ platform = max; } }}default{ state_entry() { find_prims(); list prim_details=llGetLinkPrimitiveParams(platform,[PRIM_POSITION]); prim_pos =llList2Vector(prim_details,0)-llGetRootPosition()/llGetRootRotation(); } changed(integer change){ if(change& CHANGED_LINK){ find_prims(); } } touch_start(integer total_number) { list av_details=[]; vector av_offset; vector sit_offset = sit_target; size = llGetAgentSize(llGetLinkKey(llGetNumberOfPrims())); if(size!=ZERO_VECTOR){ av=llGetLinkKey(llGetNumberOfPrims()); av_details= llGetLinkPrimitiveParams(llGetNumberOfPrims(),[PRIM_ROT_LOCAL]); } llOwnerSay(llList2String(av_details,0)); toggle=!toggle; if(toggle){ offset =<prim_pos.x,prim_pos.y,5.0>; } else{ offset =prim_pos; } if(av_details!=[]){ sit_offset.z+=0.4; vector v = llList2Vector(av_details,0)-llGetRootPosition()/llGetRootRotation(); llOwnerSay((string)v); if(toggle){ av_offset =<prim_pos.x,prim_pos.y,5.0>; } else{ av_offset=prim_pos; } av_offset +=sit_offset; av_offset =av_offset+(llRot2Up(sit_rot) * size.z * 0.02638) * llList2Rot(av_details,0); llSetLinkPrimitiveParamsFast(llGetNumberOfPrims(),[PRIM_POSITION,av_offset*llGetRootRotation()]); } llSetLinkPrimitiveParamsFast(platform,[PRIM_POSITION,offset*llGetRootRotation()]); }}

Since you're re-thinking your approach, you might want to consider putting all the sub-menus into one script (which is what I would tend to do). The basic mechanism is something like this: list top_level_menus= [ "Reds", "Blues", "Greens" ];list reds= [ "Dark Red", "Medium Red", "Light Red" ];list blues= [ "Dark Blue", "Medium Blue", "Light Blue" ];list greens = [ "Dark Green", "Medium Green", "Light Green" ];list buttons;integer handle;integer dialog_channel;float timeout =30.0;key toucher = NULL_KEY;string caption;list order_buttons(list buttons)//compact function to put buttons in readable order{ return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4) + llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);}default{ state_entry() { dialog_channel = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF; //quick way to calculate a channel based on the prim's uuid -- almost certain to be unique on the sim } touch_start(integer total_number) { if(llDetectedKey(0)!=toucher){ if(toucher==NULL_KEY){//if I'm not in use by anyone toucher = llDetectedKey(0);//now i am } else{//I am in use llRegionSayTo(llDetectedKey(0),0,"Sorry, but the item is in use right now");//so let's use a new function to say I am return;//and don't do anything else } } llListenRemove(handle);//close any old listeners that might be open still handle=llListen(dialog_channel,"",toucher,"");//listen to the toucher on the dialog channel buttons = ["Finished"]+top_level_menus; caption = "Please choose a colour group"; llDialog(toucher,caption,order_buttons(buttons),dialog_channel); llSetTimerEvent(timeout);//30 seconds to choose } listen(integer channel, string name, key id, string msg) { if("Finished"==msg){//if we've finished llListenRemove(handle);//stop listening llSetTimerEvent(0.0);//turn off the timer toucher=NULL_KEY;//clear the "toucher" variable so we're ready for the next person return; } else if ("Main Menu"==msg){ caption = "Please choose a colour group"; buttons = ["Finished"]+top_level_menus; } else if(~llListFindList(top_level_menus,[msg])){//if the message is one of the items in the list top_level_menu buttons =["Finished"]+["Main Menu"]; if("Reds"==msg){//choose the appropriate choices for the next menu we present buttons+=reds; } else if("Blues"==msg){ buttons+=blues; } else if ("Greens"==msg){ buttons+=greens; } caption = "Please choose a colour shade"; } else if(~llListFindList(reds,[msg])){ llRegionSayTo(id,0,"You chose one of the reds, and your choice was "+msg); //this is where you would do something with the menu choice } else if(~llListFindList(blues,[msg])){ llRegionSayTo(id,0,"You chose one of the blues, and your choice was "+msg); //this is where you would do something } else if(~llListFindList(greens,[msg])){ llRegionSayTo(id,0,"You chose one of the greens, and your choice was "+msg); //this is where you would do something } llDialog(toucher,caption,order_buttons(buttons),dialog_channel); llSetTimerEvent(timeout);//30 seconds to choose } timer()//always do this in dialogs, in case the toucher has hit "ignore" or crashed or wandered off { llListenRemove(handle);//stop listening llSetTimerEvent(0.0);//turn off the timer toucher=NULL_KEY;//clear the "toucher" variable so we're ready for the next person }}

Why don't you want it to be physical? The usual way to make such things is to have them call llMove2Target to move to a series of destinations, which either the script knows beforehand or which are specified by beacons which it detects en route. That makes it far easier to control the speed, since physics functions are for moving objects about the sim. The alternative, for a non-physical object, is repeatedly to call llSetPrimitiveParams to follow a similar course, but it means calling it repeatedly. on a very short timer, if the movement isn't to be very fast and jerky. This is because physical movement actually moves the object between points on a sim, passing through intermediate ones, in the same way an avatar might walk or fly, while non-physical movement actually picks up the object from the sim at point A and replaces it at point B, and the sim tries, more or less successfully, to interpolate the apparent movement between the two points. And unless you're repeatedly moving it very short distances over very short times -- fractions of a metre every fraction of a second -- it never looks right over long distances.

Yes, it is banned. And I find it very difficult to believe that there's any copies on the grid still working -- LL in general and Soft Linden in particular did a pretty thorough job of nuking the scripts for the damn thing. No harm in ARing this person for harassment and disclosure of RL information, but I'm willing to bet he or she is just trying to intimidate your friends. That seems to me far more likely than that LL missed any RZ installations.

One thing an inexperienced scripter may not at first realise, (I didn't and I still remember it driving me almost to tears trying to figure out what was wrong) is that when you pass the link message to the submenu scripts, you have to have something like this in the receiver script: link_message(integer sender_number, integer number, string message, key id) { handle = llListen(dialog_channel,"",id,""); llDialog(id,"Please choose an option",choices,dialog_channel); //llDialog(llDetectedKey(0),...) won't work in link messages!) }

Void, my holovendors calculate a channel based on their uuid, and pass this to the rezzed objects as the start parameter, and the rezzed object listens for its uuid (as a string) to know when to llDie(). In practical terms is there a great advantage to using llRegionSayTo, given that possiblility of there being another listener on the sim using that channel, let alone filtering for a message comprising the uuid of the rezzed object, is utterly remote?

Are you sure about that, Rolig? My reading of the OP is that the coffin and hearse are all part of the same linkset, and when the coffin moves -- using llSetLinkPrimitiveParamsFast, one would imagine -- its occupant, of course, doesn't move with it because the script thinks that the avatar is an extra prim that it's not been told to move. In those circumstances (coffin and hearse are linked together), I either would use something based on Strife's user function UpdateSitTarget, telling it to fire when I tell the coffin to move, or (which would probably be the simpler solution and might look better, too) have two corpse anims, identical save for their offsets, and switch between them for the two coffin positions My caveat for Marcia, though, is that the UpdateSitTarget function is brilliant, and isn't diffcult to use once you understand how to use it, but it's a bit incomprehensible the first time you read it (or I found it so). If you want to have a shot at it, then maybe asking about it Scripting Tips would be an idea. Or I will try to knock together a simple working example over the weekend if I can find the time.

Sitting on anything -- not just the ground -- should solve the issue. So should using a "movelock" device.. there's a simple one here -- just copy the script, drop in in a prim, wear the prim somewhere as a hud or attachment, and forget about it. Where is it happening? You could try asking the parcel owner to turn push off on the parcel. That *should* fix it, too.

Yes, it is. But putting the same conversation on an external website isn't. See https://wiki.secondlife.com/wiki/Linden_Lab_Official:Can_I_be_punished_for_revealing_information_about_another_resident_without_permission%3F

May we ask what you need it for? As Void says, they only work under certain circumstances (and even then, in practice, I've always discovered drawbacks to using them that weren't immediately appararent when I thought I needed one), and it may be that we can suggest an alternative method for whatever it is you want to do.