Kelly Linden

Honza Noyes wrote: Since it is going to have same limitations as llGiveMoney, I suppose it means: "Use is limited to 30 payments in a 30 second interval for all scripts owned by that resident on a region. Sustained overage will produce a script error and halt payments while the rate remains excessive. Historically, faster payments have failed intermittently." This is correct. Additionally it should be noted that llGiveMoney and llTransferLindenDollars share the same throttle count. 20 of one and 15 of another under 30 seconds will trigger the throttle.

llTransferLindenDollars has all the exact same limitations and restrictions as llGiveMoney - no more and no less. The only difference is that the result of that transaction is routed back to the script when llTransferLindenDollars is used. Technical details: L$ transactions in Second Life are managed by a service internally termed "L$ API". This includes llGiveMoney and direct agent to agent transfers - and anything else that transfers L$. The new function doesn't actually "pull the transaction data from the LL servers", it just passes back the results from using the L$ API. It is true that this service operates on HTTPS hence the possibility of it giving an "HTTP status code other than 200". This is expected to be extremely rare. As for the incident today on the beta regions: in order to reproduce this error (and ensure it works as expected) QA forced a configuration change such that this particular region host believed the L$ API existed at a nonsense address. Resetting the configuration to default fixed it of course. To be extra clear: There are no cases where llTransferLindenDollars could succeed when llGiveMoney would fail. There are no cases where llTransferLindenDollars could fail when llGiveMoney would succeed. There are some rare edge cases, mostly relating to LSL limitations: LSL scripts do not process more than one event at a time. If the script gets reset, the object taken, or the region restarted while the transaction_result is pending in a queue (because the script is busy in another event) then the result may get lost. This risk can be mitigated by using scripts that are mostly idle while waiting for the transaction_result event. This is not unique to the new features but applies to all events in LSL. LSL scripts have a max event queue size of 64. If the event queue is full new transaction_result events will get dropped. This risk can be mitigated by ensuring the script handling the transaction_result does not build up a queue of events. This is not unique to the new features but applies to all events in LSL. The only script in an object which will get a transaction_result event is the script that called llTransferLindenDollars. This is similar to how the http_request event works. Hopefully that helps clarify things a little.

Sorry about that Honza. This was a result of internal testing verifying some of the error codes. I have fixed the host and it should now be working for me. One more note: we are planning on deploying a new version this afternoon sometime to pick up a fix unrelated to this feature. Thanks for jumping in and trying it out!

An upcoming server maintenance project is going to include some new functionality for LSL. This functionality is designed to allow scripts which pay out L$ to determine the success of that transfer. key llTransferLindenDollars(key id, integer amount) Attempts to transfer amount of L$ from the owner of the object to id. Requires PERMISSION_DEBIT. Returns a key used in a matching transaction_result event for the success or failure of the transfer. transaction_result(key transaction_id, integer success, string data) LSL event triggered from an llTransfer* call (currently only llTransferLindenDollars). transaction_id matches the return value of the llTransfer call. If the transaction was successful the id will match the transaction id shown in the transaction history on secondlife.com. success is TRUE if the transfer succeeded otherwise FALSE.  data will contain a CSV of destination id and amount transferred on success and an error tag on failure.  Error Tags: This is not an exhaustive list and it is possible these will change over time. LINDENDOLLAR_ENTITYDOESNOTEXIST - The destination UUID is not a valid agent. LINDENDOLLAR_INSUFFICIENTFUNDS - The source agent does not have enough L$ for the transfer INVALID_AGENT - Destination agent is not a valid UUID INVALID_AMOUNT - Amount is <= 0 THROTTLED - The scripted L$ throttle was hit for this object owner. MISSING_PERMISSION_DEBIT - The script does not have debit permission GROUP_OWNED - The object is group owned and can't give money TRANSFERS_DISABLED - L$ transfers are disabled in the region SERVICE_ERROR - Received a non-200 http result from L$ API. If you would like to try this feature out it is currently active on the channel DRTSIM-111 on regions Bethel, Fortuna and Sandbox Wanderton on Aditi.

Hey Jo Yardley, I'm curious how your region is performing since the update yesterday (2011-07-27)?

The simulator only runs at 45 frames per second. It is going to be rare that a script runs more than 1 event per frame and even the theoretical max is 2 per frame. At this rate you are only going to process 1 timer event every 1 / 45 or 0.022s, or in a very empty sim maybe 1 every 0.011s. In other words, there isn't much point in a timer resolution any smaller than 0.02s and that is an ideal. In practice 0.1s (or about every 5 frames) is probably about the highest practical resolution you will get. I doubt you will notice much difference in feel between 0.02s and 0.1s timers.

It is a beautiful ugly little hack.

As long as the 7 channels are not very active, having the 7 listens isn't going to be a very big deal. In general the overall message rate on the observed channels is a bigger factor than the number of listens, that and how much work is done on each received message. It is possible that the number of listens would have a noticable impact in some more excessive case. At this scale the best thing you can probably do is to make the code as simple and clear as possible for you (the developer). Simple and clear code will be easier to follow, improve and debug and thus lead to better sim performance overall. Shockwave's suggestion is still a good one - and in many cases maybe easier to follow than lots of listens.

It is ever so slightly more efficient to check first. Probably by a completely unobservable amount.

In this case neither of the other posts explained why to make the changes they suggested, so I'm not sure how they are any better at teaching than just giving the fixed script - especially for a script of this small size. So, in my opinion for something this size: The reason it only works for the owner is because of the check that llDetectedKey == llGetOwner. Try this script: <full script> Is probably more teaching than: Try removing these lines <code snip> Which is I think no more or less teaching than just: Try this script <full script> In a large script it is possible that pointing out the specific line that needed changing would be more informative even without any explanation. But in this case it hardly seems to matter, and in either case the explanation would surely help.

In other words use this: default{ // Triggered when objects (including avatars) collide with the object containing this script collision_start(integer nd) { llSetStatus(STATUS_PHANTOM, TRUE); // Become un-solid } collision_end(integer nd) { if(llGetStatus(STATUS_PHANTOM)) // If the object is un-solid llSetStatus(STATUS_PHANTOM, FALSE); // Set the object solid. }}

This is really great. Any ideas on enabling the syntax highlighting for code from the LSL script editor or any other non-formatted source?