Kenn Nilsson

Thanks for the reply. I agree that the services are relatively cheap, it's more that I always enjoy the process of learning how to accomplish something new. I'm also concerned that existing bot services may not be able to eject users from a group ... they all mention group invite, none mention group ejection.

I have a need to manage members of a private group by automatically inviting new members after they perform an action AND automatically ejecting old members after a certain amount of time has passed. My initial thought has been to look into bot scripting and host a bot on one of my linux servers. I could then relay commands to the bot through objects that receive information from a website. Unfortunately, searching around the interwebs has led me to find only one "bot library", and that was in C# ... which I'm not keen to try to install on my server. I was hoping more for a Java or Python run bot. Because my searches have turned up nothing ... I figured I'd ask the community. I don't necessarily have to use a bot, but I don't see any other way of automatically managing a group roster. Any ideas?

The best way to check each 4 x 4 land square is to start at position <2, 2, 0> as that would place your prim in the center of the square that exists from 0 - 4 x and 0 - 4 y. You would then iterate by 4 as you had mentioned ... so <6, 2, 0>, <10, 2, 0>, etc. Something along the lines of ... list ldetailsvector vpos = <2, 2, 0>;vector vend = <254, 254, 0>;while (llGetPos() != vend) { while (llGetPos() != vpos) { llSetPos(vpos); } ldetails = llGetParcelDetails(vpos, [PARCEL_DETAILS_ID])); //do something with the id to store it/etc. if (vpos.x < 254) { vpos = <vpos.x + 4, vpos.y, vpos.z>; } else { vpos = <2, vpos.y + 4, vpos.z>; }} *CAUTION: The code above was written spur of the moment right now as an example of how to work the process, it has not been tested in SL and there may very well be either a) issues or b) a better way to do it.

An avatar cannot set a location as home unless a) they are the land owner or b) they are a member of the land owning group that has been granted that specific permission. In other words ... unless you actually allow that person to set your home as their home, you don't have to worry about that second issue.

While isolating channels based on an avatars UUID would make for fewer "junk" messages processed by listen(), you're essentially duplicating the effort by then adding a sensor ... and then complicating it by forcing the wristband to figure channels for each avatar it is near. Remember that this bracelet wants to glow only while others are around and stop glowing when they're not ... so a sensor() repeated every 30 seconds to find unique channels coupled with then llSay() to each of those unique channels results in A LOT more script work when the other option is to simply llSay() on a channel based on your type of wristband every 30 seconds.

Because this type of wristband is going to require a sort constant scan of nearby individuals anyway, my personal preference would be to go with a listen(). You could put each type of wristband on a unique channel and have them llSay() every 30 seconds or so ... if they hear another wristband of the same type, they start to glow. If ~45 seconds go by without hearing anything, they stop glowing. Going with the listen() route will help multiple bracelets of the same type all light up with the least amount of lag. Sure, there will be a lot of noise on your channels, but IMHO, it beats a sensor.

I have been actively using llHTTPRequest() since it was released as an option in SL and have never had an incident where using a timer() to check for timeout was necessary.

True Ela ... and so long as your sensor had a super-short range it would not have a large land impact. Still, I prefer the system-timer approach.

You can only have one active timer per script, BUT there are several ways around that limitation. For instance: 1 - If you have a texture change, say, every 5 seconds ... and you want to run the whole system for 120 seconds before turning off ... timer(){ if(isOn && itotalTime < 120) { //change texture itotalTime += 5; } else { //turn off system if(isOn) { itotalTime = 0; isOn = FALSE; llSetTimerEvent(1800.0); } else { isOn = TRUE; llSetTimerEvent(5.0); } }} You'll note that in the timer event, I use a "flag" (isOn) that is either true/false to determine exactly what happens. I also iterate an integer (itotalTime) to act as sort of a second counter. So long as your larger time-period is divisible by your shorter time period, this method works out rather well. You just have to run through some if-statements. 2 - You can send link messages from different scripts, each running a timer. In that sense, your link-message simply becomes the trigger and all of your action is in the link_message() event. So ... if you have a texture-change and you want to change it every 5 seconds ... set up another script with a 5 second timer that, on each timer() event sends an llMessageLinked() saying something like "Change texture". Receive that in your link_message() event and call llSetTexture() - or however you're doing it. You could make yet another script for turning particles on and off on a 120 second timer, etc. Personally, I suggest option #1 :-) And hey ... all of us were green once and all got help from others. It's just passing things forward.

To further on the MD5 / SHA1 / etc conversation ... not even a straight SHA1 hash is really secure. You should additionally "salt" your hashes with a dynamic string and consider hashing multiple times. From your question, however, I imagine you are looking for an efficient way to pass large chunks of data from one place to another? How big is the data? And is it object->object or object->web->object? There are potentially other solutions.

The only issue with all of the above solutions ( and I would recommend the llRegionSay() solution mentioned above ), is that if the user of the scripted object is smart ... and doesn't care about the scripts of an object, but only the object (such as, say, a tree that has a script only for this security purpose and not for base functionality), they can delete the script within the first object before rezzing the second. In that case, no solution will work.

It does not matter that the script was written on touch, no. You would simply move the functionality from the touch_start() event to the link_message() event. Or, you could allow it to trigger both ways. Remember that an event is just a 'hook', allowing you to trigger actions based on certain input or ... 'events'. You can set your script to respond to whatever events you wish -- limited by those available to LSL of course.

The function you're looking for is llMessageLinked(); -- which you will send from whichever other prim in the linkset that you want to spur the event. In the current script you have, you'll want to add a link_message() event. This event will receive the llMessageLinked() that you send and be able to process it just like the touch event you have now. For instance ... if script #1 sends the link message: llMessageLinked(-1, 0, "Start", NULL_KEY); I will receive those variables into my link_message() event ... link_message(integer sender, integer int, string str, key id) { if(str == "Start") //start your particle script; } Hope that helps!

The short answer is ... no. Media on a prim essentially just loads the external/3rd party site ... so to activate controls of a 3rd party site (such as YouTube) through a prim in SL, you would need to have a live-socket communication protocol open with YouTube ... something I'm close to 200% certain they wouldn't give out.

Playing with your script in-world gave me a syntax error as copy-pasted from here. You're missing a } on line 59 right before else if (change & CHANGED_INVENTORY) After that, your animations iterate correctly ( I stuck an llOwnerSay() in there to ensure) ... but once all of them are loaded, no animation overrides another ... so ... on line 30, before setting CurrAnim ... if(NumAnims != 0) llStopAnimation(CurrAnim); <--ADD THIS BIT RIGHT HERE CurrAnim = llGetInventoryName(INVENTORY_ANIMATION, ThisAnim%NumAnims);