|
|
|
I'd like to offer an entirely alternate reason to create this function. As a sim owner who rents spaces, it would assist in helping maintain property. A rental cube could automatically return items at the end of a lease for example. Perhaps require the objects to be within a certain distance from the object requesting the return as a control mechanism?
Elbereth. IT would not be countering each rez qwith a return. The idea behingd my system is that it would automatically ban the offender to prevent worsening the problem, then mass return all of his objects at once.
Shadow has another good reason .We need this function That anyone might responsibly use it doesn't help on the script-assumed-hostile consideration that LSL was built under. People abuse every other function out there that can be abused, which seems particularly bad in cases of "defending my land with magical orbs and stuff".
I appreciate the use for it, I'm just typically wary and trying to keep the user viewpoint and the linden viewpoint in balance. Ultimately, residents have a right to do what they want with their land. This function, as stated would require you to own the land, or be part of the landowning group.
I can't see ANY potential for abuse here. You can't grief people by returning their stuff. It's your right to do so on your land. If they don;'t like it, they can go somewhere else. Please explain how there's a problem with this? Voted.
In addition to this function, one for returning single objects would be most useful too. Something like: llReturnObject( key id); where id is the asset UUID of the object in question. Both returning all objects, and a single object would be MOST helpful for parcel owners, and sandbox admins! I agree with WarKirby, too. I'm not seeing how there's much room for griefing, unless you give someone untrustworthy access to your land. In which case they could just return all the objects through the conventional means, anyway. I would love to see a feature like this, especially if it could return single objects as well as mass return all objects created by a user.
Another potential use for this is automated grief object clean up for when admins are not around. I have already designed a security system that notifies admins when a single user has created a sudden spike of objects on their property, and I have been looking for a function like this for ages to allow it to automatically clean up the mess as well. This function would have enumerable uses for security. Also, I agree with previous posters, as long as the object was rezzed by someone who has permission to return objects on the property anyway, this function would have very little potential for griefing. Voted This would be incredibly convenient at our sandbox. I could script an object to return all of a user's things when they click it. It would let people clean up who might not otherwise know how, or might miss things.
This combined with the http://jira.secondlife.com/browse/SVC-58
 feature request would make it easy to return all objects when a user leaves an area. This could be used with sandboxes, and any other place that allows some building but wants people to clean up after themselves. I do think this could be very useful.
I think being able to return your own objects could be useful as well, say if you're in someone else's sandbox.. if you manage to lose track of some prims or just want to use an "emergency return all my own objects" button. I also like the single object llReturnObject(key id) idea. If that's implemented, I think the other function should be renamed to llReturnAllObjects(key avatar).. that or make llReturnObjects() NOT work when used on an object id instead of avatar id. Just in case of script-writing typos. It should be clarified, how this function will work: Only per-parcel, or sim-wide, or nearby objects only. Maybe have a switch in it? Like llReturnObjects(1234-1234-1234,SIM_WIDE) or llReturnObjects(1234-1234-1234,PARCEL_ONLY) (I know, I know, those are bad example variable names.) However, I can think of some potential griefing usage, depending on how this works. I think having some sort of permission check with a popup Yes/No window could be very good. Just once at the start of the script, then it will remember the permission for so long as the script runs.. like with the money permission, etc. Someone could make an object that has llReturnObjects(llGetOwner()) in a no (mod/copy/trans) script, then give the object to the owner of a sim or someone else with return power, the owner or officer-person rezzes/wears this object, and suddenly all their work (or the sim-owner's work) is returned which they'd have to re-rez and reposition. Or it could seek out other objects nearby and return them, returning others' building work unexpectedly. That would be bad if the builds are part of the sim's usual buildings and whatnot. Even if it can't return your own objects, there are sims with things built by others that should never be returned.. I could just easily imagine someone creating something that when rezzed or worn, detects objects and tries to return all objects owned by the owner of the detected object. It could be very bad if it's not expected. I definitely see the usefulness of this for ANTI-griefing, though! Any functions that would return objects should require owner's permissions to run. In addition, the return message to the owner of the objects should include name and location of the object that returned them, as well as the owner (pretty much identical to the one you get on the bottom of IMs sent from objects):
= <Object> is owned by <Owner> = http://slurl.com/secondlife/ <region>/<x>/<y>/<z> I would like to suggest a more robust version of this very desirable command. You might like to permit an agent to rez some objects and not others.
llReturnObject(list avatar_key_list, list object_key_list); // assume list of keys. You can pass a list of agent keys and/or a list of object keys to have the item returned. The two lists are seperate so the objects listed do not have to belong to the agents listed. ------- Alernativly you could have : llReturnObject(list Avatar_or_object_keys); When passed an agent key it will return all objects from that agent. When passed an object key it returns only that object. Because it is a list you can return objects detected by sensors, or objects belonging to agents that are no longer detected by sensors. (see USE below) Use A retail shop might let a customer rez an object when the shop owner is the creator, so the customer can unpack a product they just bought. While returning any other undesirable objects! Then once the person leaves your shop you might like to return anything they have left behind. A command like this has some very usefull applications in basic land management. Security It would need to ask for permission just like taking money to negate any griefer use for it. A function like this in a land security tool would also negate all those cleaver tricks people use to avoid the parcel auto return. Darling. I too am strongly in favour of any function that could return a single object by key on a parcel with owner permissions.
I would suggest fashioning a "llReturnFromLand( key object );" to work similar to "llEjectFromLand( key agent );". I actually expected that function to work for objects too when I first encountered it ... Apart from returning objects owned by an agent (as for security reasons explained in the other comments it could also be used (with a sensor/compare loop) to return all objects with keys not included in a list, which could be very usefull if you have a more or less permanent structure you want to keep but want to change the decorations every few weeks. It could also be used to establish more specific filter capabilities as returning all objects that are invisible, all objects above or below a certain height/in a certain area, all objects with a certain naming pattern ... all objects created by a certain person ( { if(llList2String(llGetObjectDetails(key id, [OBJECT_CREATOR]),0))=="adfacb56-390b-4fdc-9216-3494f1c59862")}if you would want to get rid of all the mega-prims for example... ). I know it would take a lot of script-runtime but I don't think you would want those scripts to run every 5 seconds ... those would be specificly tailored scripts with a very specific application. A few of the mentioned uses would also adress other suggested issues in a workaround way Improved syntax for the function to give maximum flexability
Function Operation Security This can be scripted into a more selective auto return. For example it might not return a physical object that an avatar is sitting on. Thus avoiding returning a jet someone is flying over your land. Actually, as much as I like this, it needs another failsafe. As a landlord, I do not want anyone deeding such an object to group and returning my stuff. You need to be more than a member of the group, it should only respond to the group OWNER or OFFICERS. Without the ability to make that distinction, it is a dangerous tool. How many complex (expensive) builds could go up in smoke because of it?
@Cristalle Karami
The secuity features are already in place. 1) group members can only DEED objects to the group if they are in a (trusted) roll with the deed ability. This issue was raised and resolved long ago. There are already a number of functions that can ban, eject, and even alter the land height using scripts. That is why deeding an object to a group is not given to all group rolls. Darling Brody. @darling brody
The dual functionality (key agent vs. key objects) seems a great idea, though it should be cnsidered with care for safety issues (someone returning a full sim of objects by the sim owner for example. I am more in favour of a single item return as opposed to a list though, since it's more intuitive to have function(key); than function([key]); . It is also more in line with existing functions, and would be an extra safeguard against someone returning a massload of objects (sleeptimer per object/linkset instead of per 72 objects/linksets). @Bayru Jiagu
I disagree. The oldest functions like llSetColor() and llSetAlpha() etc do take only one param. However newer functions like llSetPrimitiveParams() set many things at once using a list. Other new functions like llGetObjectDetails() take a list and give a list as a result too. Clearly LSL is moving towards the use of lists due to their flexability. It is far more efficiant to build a list of objects to return and then send that list ONCE into the function, rather than looping around the function. Using a list also gives greater flexibility for change in the future as a list can have all kinds of differnt constants fed into it without effecting the existing scripts using the fucntion. look at llGetObjectDetails() as a wonderfull example of how lists can be used for function flexability. I see the greatest potencial for such a function in the ability to manage a private sandbox. One can record the UUID of ariving avatars and then return all of their objects using their UUID once they have left the region for 5-10 minutes. In this way there is no need for an auto return that may return things that are still being worked on, while at the same time people who leave the sandbox will have a 5-10 minute auto return. This gets around all the tricks people use to avoid auto-return, and breaks all the self replicating griefer junk too. It also opens up the ability to return objects if the owner has rezzed too much stuff, thus solving the sandbox hog issues. You can even return objects by their name, so anything called BULLET could be returned instantly from a non-combat sandbox! Shops can leave their land open to REZ for unpacking your new purchase without the need to leave your shop. A script can return any object that is not a retail box from yoru shop to prevent scammers from placing invisible skins on your vending machines to steal money. This function could be the most usefull land management tool we have if it is done right. Darling. This would be great for if you want to make sure something stays in a certain area or region. It could be programmed to automatically return itself if it doesn't check in with another object, if it goes into another sim than the one it was assigned to, or fulfills or fails to fulfill some other condition. Currently it's possible to do that, if you're ok with destroying it forever. However, some objects contain settings that you would not want to have to duplicate, so it would be better to just have it return itself and redeploy it later from lost and found.
Seems crazy that in script I can eject an avatar from my land and also ban them but I have no way of returning their objects. Anyone with any kind of rental scenario would find this functionality hugely useful IMHO
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Script function to return objects
"Objects" is not far from "Object" and someone might use the wrong one and.. wham, all objects owned by the object's owner returned instead of just one.
It would be a really awesome feature though. (might also want stronger permission checks here)