|
|
|
[
Permlink
| « Hide
]
Torley Linden added a comment - 18/Apr/07 12:22 PM
Linked to internal JIRA; previous history: http://forums.secondlife.com/showthread.php?p=1220916
 This is very important by what i think. No, really, if you are a Linden watching this, implement it please!
 .I actually transfer stuff to my alt regularly, and this would be GREAT to make it ALOT more secure. Mmm, Too often I have been scripting collaboratively using sell for $0 to hand over permissions quickly when I am "griefed" by a third party who steals the work with full perm scripts by buying the object when they shouldn't.
Likewise I have seen a business handover where the previous owner goes through the store setting everything to sell to $0 while the buy buys it all, and others come in and steal objects. Having a method to only sell to a specific person (for $x or $0) is a simple solution to both of these. You can use a parcel of land as the container to perform this function. Put the objects on the parcel, and set it forsale to specific avatar with the sale to include all objects... Your mileage may vary if you do not trust the other account.
I think this is a good idea, but the implementation needs to be changed to a script, not a prim property.
As a prim property the lindens have to add new information to every prim in SL. This option would require every prim in SL to be changed to allow for the storage of a UUID for the person who can buy the object. And I am not just talking about the objects in world, the ones in your inventory too! However, as a script command it does not require any prim structures to be altered. All it requires is for you to have transfer permision on the object. The regular transfer permisions must be open for this script command to work. So no-trans items can not be stole using the script command. llChangeOwner(key id); Darling Brody Hmm, shame they don't have versioned prim structures or structures with bitmasks for particular features reserved, so old prim data and prim data including this feature could coexist without rewriting the entire database everywhere.
Or do they? ... or would prims even need to have this data saved? Seems like a pretty temporary thing that could be limited to in-world objects (ignored on transfer to avatar inventory). Possibly I'm mistaken, but it seems to me the same thing could be accomplished much more simply by means of a script. Especially when one considers the magnitude of change that darling brody suggests would be required to make this a feature of all applicable object types.
A very necessary and desirable function, but not one that should be addressed at such a basic level (though an LSL library function might be a worthwhile addition) – still, the various permutations on this limited sales method that might be desired suggests it would be just as simple to implement with existing library calls. Somewhat relates to
@Chance
That of course assumes you have land to spare to do it Darling, that's not a bad idea, but what about the griefing potential?
Someone could make a malicious object and then have it reassign its owner to me. Then Gigs Taggart is doing a grid-wide attack. Not good. Providing this feature as a prim property and surfacing it to UI makes it non-scripters friendly. Providing a utility function as darling suggested would also be a good option for scripters. Currently , one can use a change event handler to intercept the transfer of ownership and validate the next owner with the authorized list of avatars. I think it will be good if we consider the ease of both scripter and non-scripters in availing this feature.
When you call the llChangeOwner(key id) function the object changes owners. It does not go into inventory, it just gets owned by a new person and continues to sit on the ground where it originaly was. The new owner would get a popup telling them they own a new object complete with it's location.
Sure somone could give you hundreds of objects to spam you, but they can already do that with llGiveInventory. So the same protection should apply. You can mute the person giving the object and it will fail to transfer. Gigs, that problem you suggested can be solved by requiring you to be in the same region as the object being transfered. There is no reason why you would want an object to transfer to you when your not there to take it anyway. Darling well, there could be reasons for wanting to transfer ownership of an object without the new owner being near by, but I thikn it probably wouldn't have to do with the main topic of this jira entry, so I'll not try to imagine them right now
 I'm a builder, not a scripter, so I guess it's possible that I just missed the point where this issue changed from being about providing the option to set an object for sale to one individual avatar to apparently being about enabling the owner of a rezzed object in-world to transfer ownership of the object to another person willy-nilly (that is, without the seemingly simple enough workaround of dropping it into their profile) as Darling's comments seem to imply. The former is a feature I for one would find overwhelmingly useful, as I do much of my building in collaboration with others and thus frequently need to share or exchange objects with individual co-builders, and I have experienced the stalk-and-steal behavior Jayden mentioned. The latter is something I can't readily imagine a use for that is not already covered by existing features (such as giving inventory) and I would not have voted for it if this were the form in which it would be implemented.
I see no particular technical problems with accommodating existing objects in the course of implementing this feature: if the objects are in inventory, the question does not apply (the inventory belonging to the owner of the object, and the object belonging to the owner of the inventory, duh). If the object is rezzed in world but not for sale, there is no reason to adjust its properties, so I don't see how it would put a strain on the asset system to implement the new option. The only temporary strain of choosing a specific avatar to sell the object to would be when the object is set for sale (at which point the option can be chosen, the default of "anyone" being the current condition of any object for sale in world). It seems exceedingly unlikely to me that once this feature is implemented, every single one of the 50K agents online concurrently are all going to start using the new option that same millisecond I've voted for this, and like Veronica I did so to express support for the original form of the proposal, not for the "llChangeOwner" alternative.
@darling, llChangeOwner() is way too dangerous; how would the recipient prevent a griefing object to be set to their UUID? Even if the suggestion included popping up a dialogue box to warn the "victim", what would happen if they were off-world at the time?
The example you give about llGiveInventory() being used for griefing is true, but if you're in-world, you can click "no" on the pop-up that appears; and you can always set yourself to Busy, get all those objects in the Trash, and walk away unblemished So, why can't this feature of "selling just to an avatar" be accomplished by dropping the very same object inside a prim and set it for sale with a script that checks that only a specific avatar is allowed to buy it? It's a handful of lines of code and almost zero-lag. (I understand that selling a very large object with thousands of prims and hundreds of linksets, the above approach doesn't work; then again, @Chance's suggestion would work well in that case — if the object is SO big and so valuable, you'll probably be building it on your own land anyway) With due respect, I don't see any interest in this feature (just a lot of problems), but sadly we can't vote against features, so I'm just dropping a comment... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Allow residents the ability to sell an object to a single avatar
