llGiveInventory() Reliability

[agentronin]

I have scripted a tool of convenience to send notecarded class transcripts to students who have attended. The script is centered around the function:

llGiveInventory()

I find this function is not reliable in spite of all due precautions to prevent throttling.  I thought at first it was due to that throttling, but there have been tests where the first, and last, avatars in the list got the notecard, but an avatar in the middle of it did not. It is as if the notecards were dropped by the server into a bit bucket never to be seen again.

I know it is not a bug in the script, because there have also been successful sends to all in the list. The odds of success seem to correlate positively with how quiet a region has been, and also whether the sends were done after a recent rolling Tuesday region resets.

Please suggest reasons for this happening, and possible solutions.

[Rolig Loon]

These cautionary notes in the wiki may be helpful:

• If destination is an avatar the script sleeps for 2.0 seconds. (Giving to objects or attachments has no delay)
• If destination is an avatar that refuses to accept it (by manual decline or muting), is in busy mode, or is offline with instant messages capped, it is not returned to the prim's inventory; it is deleted.
  • It is not returned to the owner. It does not show up in their lost and found or any other inventory folder.
  • It is not put in the target's trash folder.
• As of 31th January 2012, llGiveInventory now has similar throttle to instant messages. A throttle of 5k per hour per owner per region; with a maximum burst of 2.5k. This throttle only affects gives to agents, not to non-agents.
  • "With 3k subscribers you will want to send slow enough that it takes ~45 minutes to send 1 item to each subscriber. A general safe way would be to send ~2k as fast as you can, then wait 31 minutes and send another 2k." Kelly Linden on SVC-7631
  • Be aware that while you script a system to handle the top of these limits that other busy scripted objects can be adding up to the throttle as well, such as vendors.

I have never run into a throttling problem myself, and you say that you have taken precautions against it too, so that's not likely to be the issue.  However (bullet #1), I have had a problem with the built-in delay. If you are planning to send assets to a long list of people, it can help to give them in a timer event, delaying deliberately for a couple of seconds between each one so they don't stack up in the event queue.  It is also good to remind people (bullet #2)  that items sent by llGiveInventory will be refused automatically if the receiving avatar is in busy mode.  That's probably the single most common reason why sent items go missing.

[agentronin]

The avatar list is never more than 10 avatars long. Distributed throughout the list there are three test avatars who are offline. I know there is a reliability problem when one or more of these three do not get the notecard.

When the first, and last, test avatar in the list gets the notecard, and the one in the middle does not, I know for sure the delivery failure was not due to throttling.

The notecards are not sent in a burst. They are sent at a rate that does not exceed 5k per hour. Just before the next notecard is sent, the last send's timestamp, and the current time stamp, is used to calculate how long to sleep so as not to exceed this. In addition there is 1 second added to the  sleep time for a margin of safety. Whats more, there is the two second sleep time that llGiveInventory() does when sending to an avatar. The sends were done in a region that has hardly any traffic.

[Rolig Loon]

Good, so it really does sound unlikely to be a throttling issue, and you shouldn't run into a problem with the two-second delay since your list is pretty short.  When I have encountered it, I have been sending several hundred items.  That means the most likely reason you're having trouble is that some of your students are in busy (or away) mode (or are refusing delivery manually and don't realize what they are doing).  That really is the most common reason why deliveries fail, and it's insidious because most people don't understand why they shouldn't use busy mode.

[agentronin]

The three test avatars that indicate to me there is a problem are no students. They are alts of mine, they are offline during the send, and so cannot possibly be in busy mode. Also, they did not reject the send. I know this because they are me.

[Mollymews]

13 minutes ago, agentronin said:

The three test avatars that indicate to me there is a problem are no students. They are alts of mine, they are offline during the send, and so cannot possibly be in busy mode. Also, they did not reject the send. I know this because they are me.

best to test this on other regions as well in the first instance. If is happening everywhere then raise a JIRA explaining all regions.  If is only happening on your/one region then raise the JIRA explaining your/one region

[agentronin]

This was notices in several regions. Two were chosen for their low traffic. I am not sure if I should list them here.

It appears the best odds of successful sends are right after Tuesday's rolling resets.

Should the JIRA include source code for the script I am using to do the sends?

[Mollymews]

39 minutes ago, agentronin said:

Should the JIRA include source code for the script I am using to do the sends?

yes.  Is always best to be able to JIRA a way to reproduce the problem

[Jenna Huntsman]

FWIW, you should also post a copy of the source code here - It's possible that someone here might find something that you missed, or can test and reproduce the problem on their end (thus confirming the idea that there's a bug).

[agentronin]

I will provided source code to individuals who request it with the intent to help with this problem. I am reluctant to post it for the world to see.

[Jenna Huntsman]

If you want bespoke help, you can pay someone (You'd need to post in the Wanted forum).

Alternately, you can post the source (you don't always need to post the entire thing, just the section that doesn't work right) here and we can try to debug. The Lindens also won't comment for items which are closed-source, so if you've genuinely found a bug, it'll take longer to get fixed.

(As an aside, I don't see why you're so hesitant to post the source in the first place. The kind of thing you're describing is simple, and anyone who knows LSL could create something similar in about half an hour).

Edited July 17, 2022 by Jenna Huntsman

[Qie Niangao]

It seems that every simple explanation has been exhausted, so the only way to progress is to find the minimal script that causes the problem, then post that here and/or to a jira. There's really no point posting the whole script, just a distilled version that exhibits the error with as little additional code as possible.

Originally I'd expected this to be the throttle kicking in, especially because the threshold is combined with any other script with the same owner in the same region, but if this is happening on several regions that seems unlikely unless  all those regions also have vendor scripts doing inventory distribution for the same owner(s).

I would just mention that notecards may not be the best distribution medium for (purely text) class transcripts. If it were me, I'd probably just post the transcript text to a favorite blog platform—e.g. WordPress—and distribute links to those posts by IM, group notice, or just as part of the tutorial background info, syllabus or whatever. Or, still assuming they're strictly text notecards, you could distribute the UUIDs of those notecards for use by a simple reader script that dumps each line to chat. Or a link to an in-world http server that sends the text to the user's browser of choice where they'd be easy to search, cut-and-paste, etc.

If, on the other hand, the transcripts are not pure text but rather include embedded scripts, images, etc., such items will need to be embedded full-perm in a notecard.

[Love Zhaoying]

6 hours ago, agentronin said:

I will provided source code to individuals who request it with the intent to help with this problem. I am reluctant to post it for the world to see.

We are here to help. That's why we are here.

[agentronin]

I made its source code available for download at: https://www.mediafire.com/file/vyshysb3igwh5r4/give2List.lslp/file .

[Jenna Huntsman]

14 minutes ago, agentronin said:

I made its source code available for download at: https://www.mediafire.com/file/vyshysb3igwh5r4/give2List.lslp/file .

Just put it in the forum thread, it's a security nightmare downloading files from unknown sources.

[agentronin]

I have done testing that shows the send failures are related to how long the avatar sent to has been offline. The longer the avatar has been offline, the fewer sends succeed, until no sends do. There appears to be a limit in effect regarding how many objects an avatar can receive by means of llGiveInventory(). And I think the number of additional objects that can be received while offline is dependent open how many have already been received during that time.

I have been aware of such limits for types other than notecards, but I did not expect notecards would be subject to them. Mostly because many times I have seen in the profiles of vendor customer service instructions to communicate by notecard because IMs get capped, and also because the recipient avatar used for my tests has AutoAcceptNewInventory set True.

Now I think I understand why Caspervend, when an object has been gifted, has to wait for the gift recipient to be online before it does delivery.

[Love Zhaoying]

28 minutes ago, agentronin said:

I have done testing that shows the send failures are related to how long the avatar sent to has been offline. The longer the avatar has been offline, the fewer sends succeed, until no sends do. There appears to be a limit in effect regarding how many objects an avatar can receive by means of llGiveInventory(). And I think the number of additional objects that can be received while offline is dependent open how many have already been received during that time.

I have been aware of such limits for types other than notecards, but I did not expect notecards would be subject to them. Mostly because many times I have seen in the profiles of vendor customer service instructions to communicate by notecard because IMs get capped, and also because the recipient avatar used for my tests has AutoAcceptNewInventory set True.

Now I think I understand why Caspervend, when an object has been gifted, has to wait for the gift recipient to be online before it does delivery.

This makes sense, as it aligns with what is called "message caps" for offline messages.