A Way to verify llGiveInventory was received

This has now become a must. WIth the number of vendors out in SL, I have heard many people that have problems with their vendors not giving an item. It is not the specific script because a reset of the scripts fixes it for a while.

As to not break existing scripts, just add another state

 inventory_given(key id, integer received) 
{
 if(received == FALSE) //Did not accept
  {
   llSay(0,"You did not accept.");
 }
}

or something like that.

Please post comments, suggestions.

I think this would be quite useful, as instead of llSaying "didn't accept," you could refund the person.

Or even if its just to check that the user received the dialog box to receive the items.

People are complaining that when they pay the vendor its not giving them the item.

technical mombo jumbo:

integer llGiveInventorty(key agent, string item)
changing the function to return TRUE if the agent gets the dialog box or FALSE if they dont.

If Linden won't/can't put an error return on llGiveMoney() you think they are going to bother with inventory ?

Sad but true.

Errr it's not *easy*. I've spoken to a number of devs and it's not a 5 min fix. Going further, I don't think the llGiveInventory should be an event, just

integer llGiveInventory()

An event makes sense actually, as making it an integer requires the script to stop running until the user gives a response (IF they give a response at all!).

Making it an event means you can confirm the exchange when it actually happens.

Do both, the integer can confirm that the user was given the dialog box, the event can determine if they clicked "yes" or "no."

Umm, no, event only please. I don't think that the function call should be different whether or not the return value is looked at, and I don't want the function to freeze unnecessarily while waiting for a response that I may not care about.

what i would like to see is the function returning an integer. and maybe even have a built in timer, so after say 10-15 seconds it times out and returns at FALSE and he dialog box goes away.

Longer down the road if they could add an event that would be cool.

I understand that it would not be an easy fix - the request would have to coordinate responses from multiple servers - but considering SL is "sold" to the public as a viable place to peform business you would think that the first priority ( above new bells and whistles ) would be to put in a fail-safe infra-structure to make the business of buying and selling content more secure and accountable instead of throwing merchandise and money into a "black hole" and relying on user IM's to tell you when something didn't work.

The reason llGiveMoney() can not return a value is just as stated by LL. The information is simply not available at the time that the script function is performed. Your account balance is not actually part of your avatar. It is strictly part of your account. It is not data that is saved multiple times in every single sim in the game.

When your script calls that function the sim where the script runs has to send the request out to the server that actually does manage account balances. This means that the act of sending the request out has to get queued and wait until previous outbound messages earlier in the queue have been sent. On the far side once recieved the data gets queued waiting in line to process. During times where a whole LOT of requests are backed up, it can take some time before processing and even longer for the messages to be transferred back to the point of original for some confirmation to get recieved. Because this is a non constant time frame there is no logical way to sleep the script while waiting for a response. Its quite feasible the resonse itself gets lost or dropped by other network traffic issues.

The same thing applies to inventory. When you recieve something from a script using llGiveInventory the recieved item is not saved in your avatar in the sim where you purchased the items. Your avatars inventory doesnt exist in the sim where your avatar is honestly. Its on the asset server. The same type of queued messages for money is required in this act and its illogical to sleep a vendor script, preventing further sales, while waiting for a response from an asset server that EVERYONE understands is already over burdened when its NOT responsible for sending confirmations. If we add the requirement to confirm each transfer that would POTENTIALLY double the processing required.

Right now the system works. Its not perfect. It is missing some features that are desperately wanted and needed. But second life is still a startup in its genre. It has been the victim of a double edged sword of blessings and curses with its growth. Its proving its appeal at the same time as the population is growing at a rate that makes certain types of further developement difficult.

Not saying to stop requesting the feature, just please understand the technical aspects involved so that you can accept its something that will take some time to impliment and rather than possibly getting angry waiting just be happy when it finally arrives.

People have been asking LL for this for at least 2 years now. It seems obvious that they do not intend to do anything about it. What I find most odd about the situation is that avatars already receive these notifications so it doesn't appear that doing the same for objects would be a real challenge.

Argent:

Proposal i've seen before and would like implimented too. But it still doesnt address the issue that the asset server would need to send out verification of inventory transfers when not all scripts want it.

OTOH:

If it was implimented STRICTLY as a unique event instead of a generic data server and if requests were ONLY recievable by the same script that calls llGiveInventory(), then on compilation the script could see if a inventory_given() event is defined or not and only if one is defined will the llGiveInventory() call generate a transfer that requests feedback.

Allow the server to handle both 'confirmation needed' and 'confirmation ignored' requests for inventory and it will reduce some of the potential overhead of doing this.