Are you Busy/AFK?

With my little delivery system project, I’m starting to work on an additional module to form a pipeline. In the way that I designed my queue system, individual worker threads can easily create new tasks that other threads can handle once they complete their task. In this instance, I’m working on a task to determine if an avatar can receive an object.

The highest potential of a delivery failure occurs when an avatar is busy or AFK. After that, people could end up having IM caps preventing them from receiving inventory when they are offline. I’m making an object in-world that will be able to detect and report if an avatar is currently online. This is done through the method call to llRequestAgentData. That is simple and easy. The problem comes in with detecting the status of an avatar. Another method is exposed to developers that handles this is called llGetAgentInfo. It lets me know if someone is flying, away, busy, crouching, running, typing, walking and more. This method has a flaw though, which hinders my progress. Once an avatar leaves the region, it fails to work.

I looked on JIRA, but I couldn’t find any exact issues that demonstrated my dilema. I opened a new feature request. [SVC-5266] Expose results of llGetAgentInfo grid-wide using llRequestAgentData(id, AGENT_INFO). Soon afterwards, I found a similar feature request, [SVC-1618] Exapanding capabilities of llRequestAgentData(). It appeared that at one time, someone suggested “DATA_STATUS” as a subtask, but had been removed since llGetAgentInfo was available. I added a comment about the need for grid- wide capabilities and added a subtask for DATA_INFO.

For now, my queue can wait until an avatar is online before it delivers a product. If the avatar is in the same sim, then it can also detect if they are AFK or Busy. When a better way to handle AFK/Busy status becomes available, I can switch it without much work. I am hoping that Linden Lab may provide a richer set of methods for delivery systems since they now own and promote XStreetSL.

posted by Dedric Mauriac on Applewood using a blogHUD : [blogHUD permalink]

4 Responses to Are you Busy/AFK?

  1. Three ideas:

    1) I assume your system will hand out dropboxes to the individual merchants. Each dropbox could work as remote sensor to detect avatars in their sim. With growing coverage, you will have many sensors out there to detect them.

    2) If an avatar is detected as online but not in range of a sensor, the box could sent them an instant message, asking them to click a weblink. Instant message from objects appear in open chat, so the avatar really needs to be “awake” and observant. This could be repeated three times before giving up for this cycle.

    3) If #2 fails, the box could send the avatar a notecard with instructions of how to start the delivery. Of course this notecard might get lost too – I would only do this once per cycle.

    • Lewis Moten says:

      1) it only works if the owner is in the sim. Not good enough for what I need.

      2) interesting idea. I did have an instant message service in mind as well to notify the seller after delivery, or both seller/buyer on a failed delivery after a two hour attempt.

      3) seems problematic and could lead to note card spam. Imagine how many times an individual would receive a note card.

      One alternative is to have someone wearing a HUD all the time, so it would work in any location that has scripts enabled. I could have an option on the website, asking if the user wants their status to be checked before delivery. if it’s not checked, this step is skipped, otherwise a message is sent to their HUD asking if they are online and available.

      The use of a HUD could serve other purposes as well such as checking balance on site or number of pending orders and such. However, I would prefer a solution that doesn’t involve the avatar wearing stuff in order to get a delivery.

      • The idea behind #1 was that in a years time you might have 3000 dropboxes out there, which could scan 3000 sims for potential recipients.

        The HUD idea is interesting, but I would also suggest a “HUD light”, consisting only of a script that the (more advanced) residents can drop into one of their already existing HUD’s.

    • Lewis Moten says:

      Having 3000+ dropboxes to detect an avatar is a problem as well. Imagine that I’m working with 10 transactions per second. It would be crazy to send out an http request to 3000+ drop boxes for each delivery to determine if someone was online, 10 times per second. Sending the request to just one box, 10 times, would be preferable and scales up better.

%d bloggers like this: