llGiveInventoryRemoteSim - Give Inventory objects, even cross-sims

I took a look through the past postings in this group for this, but didn't see one...so am assuming this isn't an original idea.

It's possible to give inventory items from one person to another in the system, even if they're not in the same sim. If that's the case, why not give scripts the ability to do the same?

Possible versions:

llGiveInventoryRemoteSim(key InventoryKey, key Destination)

Or if that's too resource intensive because of having to determine the sim the destination object is in:

llGiveInventoryRemoteSim(key InventoryKey, key Destination, string SimName)

...which would check only the sim specified, and return an error if the object is not found.

Scripts already can giveInventory to any agent, anywhere in SL.
Giving to objects is a little bit more tenuous, since there is no centralised record of each and every object outside the asset server (and I'm still not confident it holds them, unless it's in someone's inventory.)

-Adam

and, this is one of those features that would facilitate scripting development but might also be used as a griefing tool that would damage the community. it's a great suggestion, in fact, it's another good indicator.

Please explain. I dont see the implementation of this feature being any more harmful then how llGiveInventory works today, This function simply expands scriptable worldwide inventory transfer ability to include transfer between two objects.



This is a good point. Due to the decoupled nature of the world, no simulator knows about any others except the ones bordering it. The asset server might not even know what simulators it is talking to. In a completely decopupled, scalable implementation (which is what I think LL has) the asset server will never know what simulators compose the world, since the world is infinitely expandable. In other words, the asset server can never push data to a particular server given only a name or a key; it can only respond to requests.

Then again, if the asset server was passed the information needed to push data to the simulator, such as the simulator's URL (llGetSimulatorHostname()) instead of just the simulator's UUID or name, *then* it might be able to fuffil the request.

Then again, if you have the destination's URL, then there really isnt a need for the asset server to act as a middle man, is there? You could just have the simulator hosting the script talk directly to the simulator referenced to by the URL.

==Chris

Wouldn't it be easer to ask that llGiveInventory be modified to include giving object to object transfer between sims. Of corse you can always have the designated object tell the other object what sim it is in, and then move the giving object to that sim.

Khamon wants me to explain how this could be used to grief and hurt the game, or how the Lindens might think this could be used to greif or hurt the game. Frankly, I'm with you. I think this would be a marvelous feature. If we could move notecards between prims, we could start building in-world networks. By passing certain bits at certain times, using llSetText, we could create news kiosks to keep people apprised of news all over the sims. It would be a wonderful means of expanding in-world communications.

However, I'm supposed to be thinking like a Linden, not a developer. Let me put on my paranoid ass-hat... Okay. I am Cory Linden. I am Cory Linden.

*poof*

This is a wonderful feature, and I think it is something we'll look at for 1.Omega, scheduled for release sometime after Godzilla burns down Tokyo. LOL!!!1! The problem with this is that it would hurt the community and allow greifers to ruin your immersion as a user by creating denial of service attacks. Oh, sure, it would be nice to have news kiosks, but really, we have telehubs for news. People are suppopsed to gather around telehubs and discuss news and events.

News kiosks, by way of your feature, would destroy communication in Second Life because maliscious greifers -- not that there are any, Second Life is mother, Second Life is Father -- could send an infinite number of objects to an infinite number of rezzing prims, causing lag between sims, lag on the asset server, and lag in general.

So, while this is a good idea, and we are looking into it as a viable feature -- right up there with llWrite2Notecard -- there needs to be a committee formed to discuss the negative impact this might have in Second Life. Until then, use the telehubs.

They're good for everything!

well

yes

thank you jarod

oh my look at the time

Isn't this already possible via llEmail?
If so, then why is it that no one is ruining our immersion by creating denial of service attacks with that? The same steps that have been taken to secure email can be used to secure this system.

I believe automated worldwide content transfer is the next step after implementing XML-RPC, remember, a texture is worth a thousand strings.

Sure, we have telehubs for news, but isnt the point of a free market the fact that I can put my newspaper vendor next to yours, and perhaps have mine receive more customers then yours?



My previous post answers this question, but basically, its because simulators dont know how to get an object from one arbitrary object in the world to another arbitrary object in the world given just a key. Simulator A may contain object 192c-912a-81283 but Simulator X, on the other side of the world, has no idea where 192c-912a-81283 is. Without giving Simulator X some hints, like Simulator A's URL, it cant transfer the inventory.

llGiveInventory only accepts the inventory's name and the destinations key, so right now its literally impossible to "magically retrofit" it for worldwide object-to-object inventory transfer.

==Chris

I never said it made sense. I was just saying that's what I thought Khamon was saying the Lindens thought. I'm 100% certain he thinks it's a good idea too -- mind you, being 100% certain doesn't mean 100% right.

My own opinion... XML-RPC has been sitting around, not fully implememted for almost six months now. We've been waiting for llWrite2Notecard for almost a year. I don't ever hold my breath for Linden Lab to ever get around to implementing anything interesting for people who want to build Information Services in-world. Sorry, I just don't.

As for llEmail, don't try to convince me that it's proof people won't fuck with the system. Convince Philip and Cory.

Perhaps I'm missing something here, but....if we can already have:

1. Avatar -> Avatar transfers (SL-wide)
   
2. Object -> Avatar Transfers (SL-wide)
   
3. Avatar -> Object Transfers (same sim)
   

...what is the difference technically that would prevent one object from transferring to another object in a different sim? We can clearly do so between objects and avatars (which both are identified by a key #) SL-wide, so there's already some sort of cross-sim logic going on there already. Shouldn't that be able to be extended to allow (with maybe a 'hint' parameter like the sim name for performance reasons) object-to-object transfers?

As for griefing, nearly all calls in LSL can be corrupted to serve a griefing purpose in the right hands. To me that doesn't make for much of a reason not to add a certain feature, especially when the benefit to the SL community would far outweigh the drawbacks.

If this feature gets added - I figure it'll be sometime after llWriteToNotecard

Objects are able to transfer inventory SL-wide when dealing with an avatar because a central server (the asset server) stores all information pertaining to avatars logged on to the grid. Its easy for the assetserver to transfer inventory to an avatar since avatar inventory is stored on the asset server.

The data concerning rezzed objects, however, resides on the server where the object is rezzed. The system was implemented this way to allow for the maximum amount of flexibility in terms of object creation and maintenance; if the asset server were to go down/die for some reason, rezzed objects aren't affected. Also, it would be impossible for one central server to handle the massive number of updates objects in each sim require, the system would be completely unscaleabale.

The "hint" parameter can't simply be a sim name. Its impossible to know what sim you are referring to, without keeping a table of sim names and their corresponding sim URLs on some central server. This system won't be scalable once the grid grows large enough.

==Chris

(deleting because I don't want to encourage script kiddies..)

I dont quite see how this would be considered impossible or pose a scaleability problem. This type of central list is already in place - it's easily shown by clicking the 'Regions' dropdown in the map window. So looks to me like this central tracking of what sims are where is already in place, would just need to tap into it.

The problem isnt one of 'cannot be done', but rather that this server is overloaded already.

-Adam