Month: November 2011

New LSL functionality allows scripts paying out L$ to determine outcome of transfers

Posted on by Inara Pey

A frend in-world pointed me towards the SL forums today, and an interesting post from Kelly Linden on upcoming functionality which will allow scripts that pay out L$ to determine whether or not the transfer is successful, fails or is refused by the recipients.

The new functions are called llTransferLindenDollars and transaction_result.

Kelly Linden provides further information:

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.

Kelly further explains:

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.

This functionality is currently undergoing testing on the Aditi Beta grid on channel DRTSIM-111 in the following regions (SLurls): Bethel, Fortuna and Sandbox Wanderton.

You can follow / join the discussion on these functions in the SL forums.

Going Premium 3: sandboxes

Posted on by Inara Pey

So, another part of the Premium package is the use of exclusive sandboxes. I’m fortunate enough to have a build platform of my own right now – but what would it be like using one of them if I didn’t?

Some twenty sandboxes are available for use by Premium members in five groups of four apiece:

Note that all of the sandbox with the exception of the last four above are rated General. Bricker, Colborne, Goyer and Teagano are all rated Adult. All are subject to the usual rules: no combat, selling, gambling, advertising, boxes cleared-down every four hours, etc.

For those interested in trying the Linden Realms game, you’ll also find a portal on one of the sandboxes in each of the groups of four.

Performance-wise they all seemed pretty good: on Firestorm I was hitting 38-40 fps on average, even when building, lag was minimal ( shared the sandbox I was in with two other large builds).

I spent a happy time re-working my personal version of Fallingwater (yay for 64m prim sizes!), and while I have rarely used sandboxes in the past, I have encountered the odd problem in public sandboxes elsewhere, I found my time passed as quietly and as uninterrupted asit does building at home.

Happy building

The whole idea of Premium sandboxes struck me as “Meh,” before; but as I said, I have the luxury of having space to build, so seeing something like this as a benefit escaped me. Now I’ve tried four out (yup, I actually bounced around trying-out different regions!), I can see why they could well be attractive.

Certainly places to keep in mind should I ever opt to downsize land holdings!

4th Annual Machinima Expo

Posted on by Inara Pey

The 4th annual Machinima Expo will be taking place over the coming weekend, 18th-20th November, in both Second Life and on the web.

Showcasing the winners of this year’s Machinima Expo competition, the event will be presenting a packed schedule of films over the weekend, which you can watch either in-world with friends, or view via the Machinima Expo website. Entries for the competition were not restricted to Second Life, but were open to “footage captured from a real-time 3D engine and includes video games and software designed to create machinima”  (including worlds such as World of Warcraft and games such as The Sims), so should make for interesting viewing (although which environments, etc., the inidividual films were made in is not always clear when reading the programme schedule).

Films will be shown at a number of venues in-world, and will be accompanied by specific in-world only activities as well. The venues are:

  • UCSVille – The Expo Hub – billed as “the trade show floor” of the Expo featuring galleries, vendor booths and teleporters to the other Expo locations, and with help staff on hand, making it a good place to start your Expo explorations
  • UWA Theater  – billed as “the best place to begin if you’re wanting to watch the live programming or screen the selected films in world”, sitting as it does on the corner of 4 regions

Additionally, there are two special venues for the event:

Check the Machinima Expo website for the programme schedule and a list of films being screened.

Viewer 3: further releases

Posted on by Inara Pey

Viewer 3.2 continues with almost weekly releases. The 3.2.1 (244864) release went public of the 15th November brings the release viewer almost up-to-par with things recently seen in the Beta and Development Viewers, namely:

  • Chat translation options – in time for the Google free API end-of-line, although the debate over Bing fees is liable to continue
  • Destination Guide open by default
  • New Neck and Centre attachment points.

However, there is still no revised snapshot floater.

The Viewer also includes a number of crash and performance fixes, together with a bag full of minor bug fixes and corrections.

In the Development branch, the Viewer reaches 3.2.4 (245302). There are no obvious release notes with the Development version (empty wiki page), and no obvious UI updates. I assume the release carries more in the way of bug fixes, etc.

Performance-wise,  the new releases (3.2.1 & 3.2.4) offer something of a performance boost on my usual hardware set-up: Viewer frame rates are constant in the mid-30s when on sims with a handful of others but still falls on its bum when shadows, etc., are enabled (to roughly 1/2 the frame rates of Firestorm, and roughly 1/3 those of Exodus). This gives rise to noticeable “stutter” when panning the camera particularly.

Both the new release and the latest Development versions continue to run significantly better in Linden Home regions than Firestorm (again on my set-up). I’ve yet to encounter a single disconnect in these regions when using the official Viewer, whereas, as I’ve mentioned, disconnects and crashes are a fact-of-life when running Firestorm in many of these regions. Frame rates for the 3.2.1 while in Linden Home regions were also significantly better than with the 3.2.0 release of the viewer – 18-20 fps, rather than single digits sitting around the 3-5 fps mark.

I’m not sure where the OpenGL fixes stand – it is hard to get along to Viewer meetings; there is a “dedicated” development stream for fixes to this issue, but I have no idea if these fixes are making their way back to the main Development -> Beta -> Release flow.

The Viewer installer and executable still have yet to be corrected: as far they are concerned, people are still installing and running “Viewer 2”. Tateru Nino raised this point recently (and tbh, I hadn’t actually noticed until she did). I don’t find it an irritant myself, but it is mildly amusing.

The mouse movement / click-to-move reversal is still there however. For those unfamiliar with the problem: up until now (unless using the Basic Viewer mode), you could steer your avatar using the forward / back keys and by pressing and holding the left mouse button with the pointer over your avatar; moving the mouse left / right would move your avatar in the appropriate direction.

With SINGLE CLICK ON LAND set to MOVE TO CLICKED POINT sees this reversed – move the mouse to the right, and your avatar moves left.  There’s a JIRA out to request a fix to issue.

Beta-wise, no changes have been made, and the release number remains as per last week.

Overall, 3.2.4 (Development) looks pretty stable, fast and comfortable to use. As I’m not affected by the OpenGL issue, I’m completely unable to comment on how it fairs on impacted graphics cards, and will have to leave that up to someone else. Otherwise, and pending the official release of the OpenGL fixes, these releases may indicate the “radical” element of the Viewer UI change is coming to an end, and it’ll be more a case of polishing things in terms of small enhancements and bug fixes.

And on that subject, if anyone from LL is still reading this blog – there are a few JIRAs on the new UI besides the one linked to above. You might want to point your colleagues towards :).

Wait, what? Web Profiles gain a Trending tab?!

Posted on by Inara Pey

I confess I don’t know if this is new, or I’m just blind and a little stupid (don’t answer that!), but my.secondlife.com has gone more Twittery, introducing a TRENDING tab.

The tab is accessed via the HOME tab on your web profile, and like Twitter, pops up anything that is proving popular among those using the Feed function – presumably based on a combination of replies & number of loves received by a message.

I freely admit this may have been around a while and I’ve simply missed it, or it was recently added and I simply missed the news. I’ve been rather absent from active engagement on Twitter lately due to work and things so could have missed the news there; and I do keep forgetting to tend to my own my.secondlife.com feed). As such, I only noticed it today, and did (rather forlornly) ask:

If it *is* new…then it’s an interesting new option that allows greater interaction between SL users (LL, why aren’t you telling us about these things?). If it’s been around a while, feel free to pat me on the head sympathetically before moving on :).

Viewer 3.2 UI JIRA

Posted on by Inara Pey

More people are trying-out the new FUI (apparently “Flexible User Interface”, and not “phooey” as someone jokingly insisted!) in Viewer 3.2, and some interesting JIRA are starting to appear.

If you’ve made the hop, you might want to consider taking a look at some of these and adding your support to any you agree with (remember to WATCH rather than VOTE – or do both to be on the safe side!):

  • VWR-20738: add ability to organise buttons in Customise Toolbars floater
  • VWR-27209: a Navigation bar only option to top bar of UI
  • VWR-27222: add Estate & Statistics Bar buttons and include multi-use separator in Customise Toolbars
  • VWR-27318 / VWR-27330: provide the option to use either the toolbars or the Sidebar
  • VWR-27358: allow the Chat Bar and an “IM Bar” to be docked, as if a button-like element, to the bottom bar area
  • VWR-27388: make any menu option draggable to the button bar
  • VWR-27448: recover the ability to dock windows at the edge of the screen and have them behave like tabs
  • VWR-27455: make the button bars on Viewer 3.2 dockable to top/bottom or right/left (depending on the edge) and not only on the middle
  • VWR-27457: create a “Quick Preferences” button for rapid access to frequently used preferences
  • VWR-27463: add Picks, Places, and Destinations to menus
  • VWR-27599: some floater window sizes and positions are sometimes reset to default after a crash, and all are on viewer update

While the following are not strictly Viewer 3.2 related, some may feel they still apply:

  • VWR-26688: allow notifications to be positioned to a different area of the screen

Note that I don’t pretend that this is an exhaustive list, nor have I included any JIRA for 3.2.0 through 3.2.2 marked as “fix pending”. Finally, JIRA listed above should not in any way be taken as a personal endorsement on my part – they’re simply what came up in search & while perusing the results!

Update 17th November

  • Adding EXP-1449 left click drag to control avatar not working, when “single click on land” action set to “move to clicked point”.