Ruthven Ravenhurst

and if you were to make it no copy, you would want to make sure the script is copyable, or place it in a child prim. if the script was made no copy and placed in the root, they could easily "open" the object, and the script would be moved (not copied) to their inventory. and for the child prim routine, if they set their land so that only group members can run scripts, they could turn off their group tag, rez the object, and the script wouldn't be able to run unless they set it to the same group, (or move it above a certain height; does that still work? I'm not in world to check)

Right, like Rolig says, it depends on the script. You could have the home llDie after so much time, but if you make it copyable, I thought of 2 potential ways to get around that with a rezzer, the same way temp_on_rez was gotten around

So the object_rez get's the key of the root prim of the object being rezzed, but I'm wondering how I can get the key of a child prim of the object without using a listen event. I want to target it with particles, but with the root prim using llTargetOmega so that it makes the child prim orbit it. My theory is that when the object rezzes, I can set the root prim's description with the key of the link I intend to target using llGetLinkKey, and then in the rezzing script, in the object_rez event use llGetObjectDetails to get the object's description. Which is faster? The llSetObjectDescription(llGetLinkKey)), or llGetObjectDetails(id, [OBJECT_DESC]);? I want to make sure the description is set with the key before llGetObjectDetails tries to capture it for the particle target. I guess I could use llSleep. Can anyone suggest another way other than a listen or sensor (will the sensor even pick up a child prim?)

one other thing, I can't seem to find the other place that I read, but this page says: LSL list has a limitation in length, in the sense that a programer cannot start with a list with more than 72 items. In order for programer to have a list of more than 72 items, she must create 2 or more lists and join them. I realize that's an old article, but was wondering if that still applies. I also read on the page that I can't find again, that the compiler can only have the 72 limit, but the script operations can grow the list larger with enough free memory, so basically in order to compile a larger list, it would need to be split into multiple lists when typed into the compiler, then added together in say, state_entry by doing: list ListAll;list List1 = [things, more things, etc];list List2 = [things, more things, etc];default{state_entry(){ListAll = List1 + List2;}}

I read some of the hexidecimal page on the lsl wiki, and kind of understand it, but not sure if I have it correct in how to add them together, like your second example resulting in 0x10C. I did try: default{ state_entry() { llOwnerSay((string)[PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK]); }} which spits out an integer, so could I potentially drop the flags for each particle effect into this script and copy the integer it spits out to the list in the mass script?

that is very helpful, thanks!

hmm, so I went to test how that handled things separated by pipes (the particle masks), it basically ignores them. also the only way I could get it to compile was to put the list inside a custom function. it doesn't like lists with pipes as a global. i suppose I could construct the list the same way by making a separate list of masks and using the unequal method you mentioned, but I'm not sure how to construct the list using llList2List using pipes instead of commas

I would use a swing script that uses alternating llTargetOmega to make the "rocking" motion. And if you want it to spin at random like a bull ride, you would apply a random rotation to the z axis as well.

No problem. Another thing is, depending on what you're using it for. The way you have the for-loop set up, it will only find the first link with the same name. If you have multiple links with the same name that you intend to hide/show at the same time, you would want to move llSetLinkAlpha(link_num(hud_prim_name), 1.0, ALL_SIDES); Into the loop

there are 2 things wrong that I can spot right away. first. llListen is set to listen only to the owner, it will not hear objects, even if they are owned by the same owner. you would filter the listen (in case objects from other owners just happen to use the same channel) for objects owned by the owner. Another alternative would be to use a dialog rather than a hud, then it would only need to listen to the owner. for the hud button method, you would leave the listen open by leaving all but the channel field blank: state_entry() { llListen(-75260, "", "", ""); //listen for anything on that channel } then in the listen event you would filter out using llGetOwnerKey and llGetOwner: listen(integer channel, string name, key id, string hud_prim_name){if(llGetOwner() == llGetOwnerKey(id))//checks to makes sure the speaking object (or avatar) is owned by the same owner{insert other code.............}} the second thing is in llSetLinkAlpha(link_num.... in integer link_num(string hud_prim_name) it wants you to feed it a string in the parantheses, but in llSetLinkAlpha(link_num, you're not doing that. it should be: llSetLinkAlpha(link_num(hud_prim_name), 1.0, ALL_SIDES);

you added a period to your link, which "broke" it :-p http://wiki.secondlife.com/wiki/User:Rolig_Loon/High-Capacity_Greeter-Counter

wherorangi wrote: particles are a property of the prim, not the script(s). A script is used to apply the particle property parameters to the prim. Once the properties are applied then the script is no longer needed. So if use multiple scripts then is kinda overkill, when the parameters can be stored in another form i take your point about notecards in a sale object tho. In this case then I probably go with a struct in a list I know that particles are a prim property. I will have a hud/dialog menu for the user to choose from options, and each option chosen will produce a different effect. It's not a one-off thing where they choose an option once and that's the particles that the object will have forever. Some of the choices will target objects or avatars with particles, some of them will rez objects as well. I suppose I could write it something like: list effect1 = [particle params]; list effect2 = [particle params]; etc., but that won't take the rezzing into account which is why I would need to do it like: option1(key target, string object){llParticleSystem([blah blah,PSYS_TARGET, target]);llRezObject(blah blah);llSetTimerEvent(xtime);//to stop the particles after certain amount of time}option2(key target){llParticleSystem([blah blah,PSYS_TARGET, target]);llSetTimerEvent(xtime);//to stop the particles after certain amount of time}bits of events:::timer(){llSay(some channel, "Die");llParticleSystem([]);}

wherorangi wrote: my preference is to go with the least number of scripts. So if can achieve the goal with 1 then go with 1 if have 10s/100s of different effects then could think about putting all the effects parameters and texture uuids in a struct contained in notecard(s) in the object contents. Then only need 1 script to read and execute them all. When create a new effect then is just a matter of adding (or amending) a notecard But then it would need to read the notecare each time, or possibly overload the script to read and store the parameters, which runs into the original problem of "How many can I contain in one script?" It's an object I plan to sell, so putting texture uuids in a notecard is a no-go. I thought about lists, but that would get complicated too, as not all the effects would have the same colors, sizes, push, wind, etc besides the textures

Ah that, yes, I believe there is some php involved there. I haven't tried those myself, but I think it involves a bot avatar

I do have a second question unrelated but don't want to post another thread, I'm looking to send announcements or messages to a group I own on a event, do you by chance know what I'm looking for in documentation. Are you saying you want to send an announcement through a second life group from an object? I don't think that's possible

I'm making a script/scripts for an object that based on the users choice of the options will produce a different particle effect. I will have each set of parameters in separate user-defined functions. My question is, should/could I have several (up to 100) of those UDFs in one script, or should I make multiple scripts for the different effects, and communicate the intended particle effect via link message? Of course if I go the separate scripts route, I would break the effects into groups of say 10 per script instead of a separate script for each effect.

There were a couple of things, but still not sure what's wrong with it, as it's not doing anything to the doors I'm testing it on: integer gIntSwing = 90;rotation gRotSwing;list gDoors;default{ state_entry(){ integer i; while (i < llGetNumberOfPrims() ){ ++i; if (llGetLinkName(i) == "DOOR"){ gDoors += []; } } gRotSwing = llEuler2Rot( <0.0, 0.0, (float)gIntSwing * DEG_TO_RAD> ); } touch_end( integer vIntNul ){ if (llGetLinkName( == "DOOR"){ gRotSwing = (ZERO_ROTATION / gRotSwing); integer i; while (i < llGetListLength(gDoors) ){ integer link = llList2Integer(gDoors,i); rotation LRot = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL]),0); ++i; } } }}

I wonder if I could use llNavigateTo with llCastRay, then update the target position if the previously set one would land inside an object. I'm not looking to detect the position of an object, but make sure the targeted position isn't inside an object

I didn't even know that was a function. I'm not wanting a constant movement though, well maybe. I'll think about that. But It would definitely be useful for another project I have in mind.

I have an idea for a game. Objects are placed around a sim/area for avatars to find. Simple enough hunt right? Except these objects will be "alive" and I want them to move around on a timed interval until someone clicks it, which would then tell it to move to a specific location, and be recorded that said clicker found n many of the objects. I've got most of the logic in my head with an idea of how to script it. But I want to make sure the objects won't land inside of another object, making it "impossible" for an avatar to see it. Maybe with llCastRay?

I don't understand where the problem is then. Are you expecting the dialog to take the money after the user makes a choice? Dialogs can't do that.

I only put the test for a valid amount because, as it's scripted the official viewer would only show the scripted choices, but a third-party viewer may allow someone to enter a different amount. I put the permission debit in case that were to happen, they would be refunded.

Any money paid to an object goes to the owner of the object.

You've given 2 completely different descriptions of what you want the script to do. Are you wanting the object to pay the player after they make a choice, or do you want the player to lay the object?

I don't understand what you're wanting.