|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 24/Oct/07 09:31 AM
Yes, yes, a billion times yes. We desperately need this. Down with boxed products.
I totally agree! This function should work gridwide and for offline agents too!
And it is very misleading that it's not working in the same manner like llGiveInventory does. I wanted to use it in "buy-as-a-gift vendors". Luckily I noticed that it does not work offline/gridwide. If I wouldn't there would have been some trouble for sure. Also note, it should only work with agents. And return an error, or fail silently, if passed a non agent or invalid key.
Set script as a component since llGiveInventoryList is an LSL function.
This needs to be fixed as soon as possible. I don't know if this is a bug, or a "feature" but wither way it is a horrible thing.
I agree, in fact I created something on this topic a bit ago. It isn't entirely true that it does not work grid-wide, though. It does, but only if the agent has been in the same sim as the running script at some point in the past. Otherwise it returns a "Cannot find destination" error.
Stella. Please don't make changes to an issue like that without justifying your actions. Until we get a statement from a linden otherwise, we cannot assume this is a bug.
Did you intend to post that on this issue? I don't know what you're talking about there.
If you look in the Change history, you can see Stella changed this from a New Feature to a Bug, WarKirby changed it back.
Ugh SO many elegant solutions to common problems would be possible with this. There is simply no way other than libsl bots to deliver dynamically generated collections of objects than with this function as it SHOULD.
LibSL bots carry huge overhead for the simluator and the person developing them. This needs to be made to happen. I'm a bit suprised that such an important feature hasn't been FIXED yet. This is clearly a BUG that needs attention.
One more thing - the description "llGiveInventoryList only works in the same sim" is indeed incorrect. It actually works grid wide as long as you visited the sim before as mentioned by Brandon which CLEARLY indicates this is a BUG and therefore the "Type" should be changed to BUG instead of FEATURE.
Actually, I'm pretty sure that llGiveInventoryList() will only work on an avatar that is either in the sim, in a neighboring sim (and looking into the sim in question), or very recently was in the sim. What that amounts to is whether the avatar's SL client is still connected to the sim in question. Your client connects to any sim you're in and any sim you can see into, and it stays connected for up to a minute or two after you teleport away.
It's working like any other local-only function, such as llKey2Name. I think you'd find that llKey2Name will only return the name of an avatar in those same circumstances. That clearly indicates that llGiveInventoryList works like most other functions of this type and that llGiveInventory is a special-cased exception. That means this is a design decision (not a bug), but it's one I hope they reconsider soon. PLEEEEEEASE fix this. My Kiosk.net networked kiosk system cannot give out folders of items grid-wide which would be MUCH cleaner for users. No one wants a bunch of items showing up in their Objects folder if someone wanted to give out more than a few things at once from a networked kiosk. This would be a BIG boon to users clicking on networked vendors and help them keep things organized.
I could just reproduce this issue with sending inventory to an offline user. llGiveInventoryList seems broken. I checked the key to exist and it fails to deliver with: "Unable to give inventory list: Cannot find destination"
I wonder why this isn't filed as a bug. The two things are related. The reason behind both is that llGiveInventoryList only works if the agent is still connected to the sim. If they are offline, or not in the sim, then they can't receive items via this.
The reason why you can get it to work for people who have recently left the sim is because the Second Life client does not immediately disconnect from a sim you have left, but it eventually will. Over a year now... This issue and a myriad of others that scripters have been sreaming for have not been fixed. At least a Linden could get on here and explain why it is taking so long to address this!!!
Even though you can only drop single items into the IM window.you can drop an entire folder onto an open Profile & have the whole thing sent to the other av, wherever they are, online or off .
So the mechanism already exists. It just needs plumbing in to LSL for us. Just discovered this major bug/feature whilst trying to build a networked vending system. Gets my vote straight away. Internally, those things are quite different.
In the case of dropping inventory via the client onto profiles and IM windows, the client sends a request to the asset servers to check if the items are transferrable, and toss them to the other avatar. There are pretty much no sim-local events involved, technically, aside of the sim routing said request to the asset servers. In the case of llGiveInventoryList, or llGiveInventory, the internal mechanics are different. Much more of what is being done is sim-local. Remember that object contents not necessarily are already saved on the asset servers: If you drop objects/textures/sounds into an object's contents, they are not saved back to the asset cluster yet as new assets, to my knowledge, so sending those contents via LSL to another agent somewhere else on the grid are alot more complex. This is partially just a guess, but from my technical understanding, should be close to the actual system and the root of the problem. With the approaching release of HTTP-IN I think the lindens need to look at this feature as the next big project! a vendor with http in could have externally triggered deliveries in neatly named folders to anyone. it would be a perfect solution.
Just to re-emphasise what others have said, this would be a stunningly useful function for a vendor/warehouse system, if only it worked grid-wide. Instead of packing products into predefined boxes, the warehouse could build a customised folder on the fly when a customer buys something, and then send it to them.
WOOT. This issue has been triaged! THANK YOU LINDENS! Let's hope this gets some speedy development time!
Voted.
Not sure where i read it, but somehow I thought it was added. So I upgraded some of my servers to use it (Non-Public ones, of course)... Then found out it hasn't been added! D: - Darn... I was getting excited. Hopefully this feature can be added soon. It'd make updating products soooo much easier. - As well as more efficient product deliveries and less crowded inventories (Less packages). I'm also surprised that the original author wanted to see it handled as a new feature. I don't want it doing something new, I just want to see it doing what it's supposed to all the time. Things that don't do what they are supposed to "some of the time" are buggy things.
It's triaged. that's a good start. I'm looking for that "assigned" slot filled. I just filed a JIRA earlier today (SVC-4160) outlining a problem with un-rezzable objects and I've been informed by someone that he had the same problem, and it had to do with leaving a laggy sim quickly after a llGiveInventoryList operation. I strongly suspect that the problems with doing llGiveInventoryList grid-wide are connected with the bug in SVC-4160. This entry REALLY needs to be categorized as a bug.
Aargle, this is not a bug; it was designed this way on purpose.
AAAAARRRRRRRRRRRGGGGGGGGHHHHHHHH... is all I can say to this, after spending the last few days wondering why people weren't receiving items from a vendor system I just designed to send out stuff purchased from vendors in several places from a central location, so that it can be updated easily.
I just couldn't figure out what could be going wrong, because it seemed to work fine even from other regions if I went and re-rezzed the object doing the actual giving, but then seemed to break again after a while, and the object was definitely getting the messages telling it to give the stuff to people. At first I thought it was because when it was first all installed in-world, there happened to be a bunch of asset server problems that occured at just the same time, so there might have been some issue left over from that. I didn't even think that llGiveInventoryList might be different from llGiveInventory, and still don't see why it should be :/ I feel your pain, Eddy! I was burned a while back after doing tons of of work based on llGiveInventoryList as well...like I'm sure most of us here were...just seemed so logical...
Glad it's been triaged!! This was reported in 2007 at the latest, and nothing has been done yet?
This is the second basic issue which has ruined some vendor's I've been developing. The other involving paying into child prims. Linden Lab wonder why people are getting progressively more pissed off? Thanks for nothing. And yes, this is a bug. No two ways around it. The only way it should differ from llIGiveInventory is giving a folder of items instead of one item. There's no excuses for this. Mmmm, how refreshing. Finding another old and knackered request from the residents dying alone in a back office with not one comment from a Linden, no assignee and I'll stick my neck out and say no Linden watching either (I'll look after typing).
I would get mad and type all caps and point out the inequities and stomp about but I'm getting too bored to bother. Face the facts people... LL has better things to do than provide a better service to the residents based on the residents ideas and contributions. After all that would just be madness. Eddy, it was imported (to the internal LL jira) several months ago.
Strife, whether it was done by accident or on purpose, the fact that it doesn't work the way users expect – nor they way they desire – makes it a bug. Nobody is asking for anything new, just for the function to work correctly (i.e., as expected).
EddyFragment, I'm going to go out on a limb and say that this is being watched. Having been the lead on a big project where people constantly flooded me with feature requests and bug fixes, I had to set my own priorities. Not everyone is going to like them. (For this llGiveInventoryList bug, I'll confess this includes me. I've needed it for a long time now.) However, at some point you realize that you have X man-hours to devote to programming, and you have 10X hours needed to process all the requests and easily one-third of those requests include something to the effect of "if you don't include my suggestion, your product will go unused by anyone in the world." Anyways, with that being the situation, something has to give. Something a few of you might have missed: At SLCC recently, T Linden had a question & answer session. One exchange went roughly "where are the features we've been asking for?" answer "have you been to the triage sessions where such things are acted on?" I'm paraphrasing, of course, and I had to admit I never attended them. Anyways, something to think about. I'm still keen for this function to be fixed, as I have for years.
Also, what would make it even better though is support for folders in an object's inventory. Doesn't even have to be nested - one level deep would be sufficient for networked vendors and XStreet magic boxes. Then an additional function which returns a list of inventory items when given the folder name. This would be more flexible compared with a separate llGiveInventoryDir() function because there's often things common to each product, like a shop landmark, so these can be added to the inventory list as needed and given using the current llGiveInventoryList() function. You couldn't have an identically named item in two or more folders without breaking the current llGetInventory* functions. Unless introducing new functions like llSetDir() and llGetDir(). In which case the llGetInventoryList() wouldn't be essential - just a luxury. Anyway, I'd find anything like that unbelievably useful. Now that SL own XStreet it would be nice to see Linden Lab take this initiative to make things easier for users. Then networked vendors can benefit from it too. Being forced to give products inside an object instead of a folder should be a thing of the past. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
llGiveInventoryList should be able to work gridwide
