Tag: SL News

HTTP updates: the what, why, who

Posted on by Inara Pey

Update March 27th: Commenting on the open-source development mailing list, Monty Linden states: “It looks like Beta (Aditi test regions) will be wrapped up shortly. If you’ve wanted to try these out but haven’t yet, now would be a good time to jump in there.” 

Linden Lab is in the process of making a number of improvements to Second Life which should benefit both the platform and users. Once deployed, some of these updates will be clearly visible as they gain widespread use in-world, such as the upcoming materials processing capabilities. Others will be perhaps more noticeable because they require a viewer update – as is the case with server-side baking, rather than being obviously visible in everyday use. Some will have more of a “background” impact, rather than anything which is clearly visible in-world (although they may make their presence felt for the more keen-eyed).

Monty Linden
Monty Linden

Among the latter category of changes are the HTTP updates currently being tested on Aditi and which will soon be popping-up on a Release Candidate channel. This work is being spearheaded by Monty Linden, and has been under development as a part of the Shining Project initiative kicked-off by Linden Lab in 2012.

Several of my SL projects update reports have covered Monty’s work, and will continue to do so in the future. The aim of this article is to bring the various threads together in a single post, in order to provide a  broad overview of what it all means without getting caught-up in the technical minutiae.

Communications between the viewer and the SL servers are subject to many vagaries. Network issues can occur locally (i.e. with a user’s own network), or at the ISP level, for example, long before they actually involve the SL servers. There is little LL – or the support team for whatever viewer is used to connection to SL  – can do in these instances.

However, network issues aside, there is much work that can be done to improve viewer / server communications and make connectivity between the two more robust – and this is the focus of Monty’s work. Some of this has to do with gradually switching aspects of the service away from the older UDP services within SL to HTTP-based services, and some of it has to do with improving the existing HTTP services employed by SL and making them both more robust and (hopefully) a little easier on older models of routers.

Initial Work

As mentioned above, Monty’s work is encapsulated within the Shining Project, and is being carried out in a number of phases. The first phase of this work was actually completed during the second half of 2012, and focused on improving the HTTP texture fetch mechanism both server-side and within the viewer by which textures are obtained for rendering. This work started to go into widespread use around  November 2012, when the viewer code was made available and Linden Lab announced the new capability thus:

A new scheme for performing HTTP operations is introduced with this release. It is intended to reduce crashes and stalls while performing HTTP operations and generally enable performance and reliability improvements in the future. In this release, it is being used by the viewer’s texture retrieval code. Our expectation is that it will provide consistent and predictable downloading of textures.

The initial HTTP updates being driven by Monty Linden started to appear in around November 2012
The initial HTTP updates being driven by Monty Linden started to appear in around November 2012, with improvements to the texture fetching code in both the viewer and on the server end of things

Following the release of the viewer code, many reported they were seeing significant improvements in texture downloads, and a resultant improvement in texture rendering.

As a part of this initial work, Monty also started examining connectivity between the server and the viewer (number of actual connections opened, etc), and found that it can cause significant hardships for older classes of router, many of which incorporate a firmware-controlled “lock-out” which can be triggered when too many connections are opened when using HTTP, and so can cause users issues (hence the recommendation which some support teams give to disable HTTP textures within the viewer if connection issues are being experienced).

Second Phase

At the start of 2013, Monty commenced work on the second phase of the project, which is currently focused on the server-side of things (that is, there are currently no viewer-side code changes). In particular he is looking at further improving texture and mesh asset-fetching from the server and at implementing HTTP persistent / keepalive connections capabilities, which should enhance the overall robustness of such communications (some of which may hopefully see some connectivity improvements for those people using older model routers, as noted above).

Continue reading “HTTP updates: the what, why, who” →

LL announce new server-side AO capabilities

Posted on by Inara Pey

Update March 26th: This article now includes the links to the relevant wiki pages for the new capabilities, as released on March 25th. Also, permissions to animate an avatar are only auto-granted when a prim using the new capabilities is attached to the avatar (PERMISSION_OVERRIDE_ANIMATIONS), otherwise explicit permission required.

Note: article title revised to better reflect contents

At the Beta Server meeting on Thursday 21st March, the Lab informally announced the forthcoming arrival of a server-side Animation Override (AO) system utilising LSL commands.

Coded by Kelly Linden, this new capability is not seen as a replacement to existing AO systems, but rather as a means of making them, in Kelly’s words, “Do a significant portion of their work easier and smoother.”

Overview

The new system utilises a series of new LSL commands, which can be placed in a script located in a prim which has permission to animate your avatar, much like current AOs (granted automatically if the prim is attached to your avatar).  However, the advantage with the new calls is that they are keyed directly into the server’s animation states, unlike current AOs, which operate somewhat in conflict with the server’s animations states.

For example, with current AO systems, moving your avatar (i.e. walking) causes an update to be sent to the server, which initially tries to run the default animation required (i.e. the infamous “duck walk”). However, the AO script also detects the state change for your avatar, and then instructs the server to replace the default animation information with the required animation.

With the new system, rather than trying to run the default animation and then have an AO tell it what it should be doing, the server simply replaces the default animation with the required animation, thus vastly simplifying the process.

The new capability is currently available for testing on a number of regions on Aditi (CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26, and CCMTEST29, all on project channel DRTSIM-201), and it should be deployed to a Release Candidate channel during week 13 (week commencing Monday, March 25th).

Additional Notes

  • The new calls should be compatible with existing AOs, assuming appropriate priorities are used
  • Items such as idle animations and swimming animations are handled separately by the viewer, and so are not covered by the new calls
  • This capability does not require an viewer-side changes at present, although it is likely that a future update will be made to the viewer to allow the Stop Animating Me menu option to reset animation states set using the new calls
  • Seats and poseballs should continue to use trigger animations
  • Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to work smoothly with the new calls.

Animation States

New server-side AO capabilities coming soon
New server-side AO capabilities coming soon

The animation states specifically covered by the new LSL calls comprise:

  • Standing
  • Sitting
  • Ground sit
  • Standing up
  • Crouching
  • Walking
  • Crouch walking
  • Striding
  • Running
  • Turning right
  • Turning left
  • Jumping
  • Pre-jumping
  • Taking Off
  • Hovering
  • Hovering Up
  • Hovering Down
  • Flying
  • Flying Slow
  • Falling Down
  • Landing
  • Soft Landing

LSL AO Calls

The following LSL calls have been defined for use with the above animations.

llSetAnimationOverride(string anim_state, string anim);

  • Sets the animation that will play for a given AO state, where:  string anim_state is the name of the animation state being overridden (e.g. Walking), and string anim is the animation to be used
  • Requires a new runtime permission – PERMISSION_OVERRIDE_ANIMATIONS
  • Once an animation override is set for a given state, it is preserved for the rest of the session, unless reset (see below)
  • As the animation states are purely server-side, they get cleared on a relog.

llGetAnimationOverride(string anim_state)

llResetAnimationOverride(string anim_state);

  • Will reset the animation for the given state to the default
  • Includes a special “ALL” state, which will reset all animation overrides to their defaults
  • Requires new runtime permissions PERMISSION_OVERRIDE_ANIMATIONS.

[New addition, March 26th]. Note that PERMISSION_OVERRIDE_ANIMATIONS Only be auto-granted for attachments, otherwise explicit permission required.

Testing and RC Deployment

As mentioned above, there are a number of test regions available on Aditi where the new AO calls can be tired out by scripters and TPVs, and the new capabilities should be arriving on an RC channel in week 13. Any issues found with the capability should be reported via a JIRA, and, if deemed appropriate, raised at the Simulator User Group meeting on Tuesday, March 26th.

LL offer discounted regions to educational and non-profit organisations on the QT

Posted on by Inara Pey

secondlifeFollowing my piece on the general status of Second Life, some of the comments revolved around educational discounts for regions – or rather, the ending of them in 2010. Many credit the abolishment of the discounts with the loss of hundreds (I’m not entirely convinced on the “thousands” element) of regions from the grid since that time.

It now appears that the Lab is quietly trying to reverse matters by extending a 50% discount to selected educational and non-profit organisations.

The news comes via Hamlet Au, with a natty little scoop on the offer he gained after being e-mailed on the matter. The originator of the e-mail informed Hamlet that he’d been offered a full region for $1,770 USD for a year or $3,540 USD for two years, for use by his organisation. The new prompted Hamlet to drop Peter Gray, LL’s spokesman, an e-mail on the matter. Hamlet comments:

“I’m not able to share numbers,” Gray e-mailed me, “but can confirm that we’ve extended this special offer to a targeted number of educational and non-profit institutions that have recently left Second Life.” The next question is how many institutions they’re offering this to, but there, he is mum. Furthermore, there’s no way for former sim owners of this variety to request this discount:

“There isn’t currently a way to apply for this; it’s a special offer we’re extending directly to some nonprofit and educational institutions as part of our customer win-back efforts,” as Gray puts it.

Deep Think East - one of the regions operated by the UK's Open University, one of the educational organisations which still operates within Second Life
Deep Think East – one of the regions operated by the UK’s Open University, one of the educational organisations which still operates within Second Life

While not privy to the exact arrangements specified in the offer, I assume that as one or two-year discounts are specified, the caveat to it is that the discount only applies to a full up-front payment of said fees.

Like Hamlet, I’m also a little dubious that the offer will be taken-up by everyone who has departed Second Life – although it is interesting to now that LL are apparently targeting organisations which have “recently left” SL, and therefore have yet to put down roots elsewhere. As Hamlet rightly points out, a lot of people got somewhat burnt when the Lab announced they were discontinuing discounts for educational bodies and non-profits, and there has been a good degree of bad feeling since. There’s also the fact that over the past couple of years OpenSim has become a more than credible – and potentially a lower-cost – solution for educational needs.

It is probable that the move might be seen is some quarters of one of “desperation” on LL’s part in order to reverse the decline in the number of privately-held regions. However, given the limited and closed nature of the offer, such views may not be entirely valid – Second Life isn’t anywhere close to balancing on the edge of disaster just yet – although it would be interesting to know what did prompt the move.

In the meantime Hamlet has requested the any organisations or individuals who have been in receipt of the offer drop an comment onto his post on the news.

With thanks to Hamlet Au.

Linden Lab comments on new advertising moves

Posted on by Inara Pey

LL logoAdvertising on SL has been something of a minor theme on this blog of late. Most recently, I returned to the idea of LL using machinima collaboratively with users (via a competition) to help promote Second Life to the world at large. Prior to that, and paralleling Ciaran Laval, I’ve touched on the topic of the SL websites being perhaps a means for the Lab to leverage revenue through advertising as a means of helping to offset falling tier revenue  – something which the Lab actually embarked upon recently.

The move has been met with mixed feedback from users, with many objections being raised (unsurprisingly) and some mistakenly believing they were somehow “milking” their own userbase – as if the revenue generated from the ads was coming directly out of their own pockets. Some of this negative feedback may have been driven by the initial ads displayed on things like people’s dashboards to start with, although it is evident now that LL are seeking to more robustly curate the nature of the ads with show up – not always successfully, but the improvements are there to be seen.

Advertising on the SL dashboard has raised mixed responses
Advertising on the SL dashboard has raised mixed responses

Some of the backlash against the new move appears to be on the grounds that advertising somehow devalues the SL brand. However, as Gywneth Llewelyn points out, the SL web properties potentially offer a rich vein of revenue flow which could significantly assist LL (with a potential beyond anything I admit to imagining).

Obviously, given my own stance on the matter, I’m supportive of the move – and have actually suggested it should be broadened to incorporate other SL web properties such as both our profile feeds (which already advertise SL in a case of “preaching to the converted”) and  the Marketplace. The latter is something some have drawn the line at, alongside the use of people’s SL dashboard. Although objections to the use of former have been given with caveats, the idea of excluding either would appear to be counter-productive to the aim of helping to generate revenue for LL – simply because of the amount of traffic they generate.

Possibly in response to the wider negative reaction to the move, and in confirmation that LL very clearly see their web properties as a valuable source of revenue generation, the Lab has issued a Featured News blog post on the matter, covering both the current advertising and the moves to expand it, confirming that as of the 12th March, advertising will encompass the SL marketplace. The post reads in full:

As you may have noticed, we recently added some banner ads to SecondLife.com. Today, we’ve also added them to the Marketplace, and we’ll soon expand the program to other Second Life web properties as well. The placement of these ads is designed to be unobtrusive, as we don’t want them to interfere with your Second Life experience on the web, and we’re taking care to keep the content appropriate.

These ads are a great opportunity for advertisers to reach the large, global audience that visits the Second Life web properties every day, and we want to extend that opportunity to Second Life merchants as soon as we can. For Merchants, advertising on the Second Life web properties will be a new way to get their offerings in front of potential customers, while at the same time making the ads extremely relevant to every Second Life user who sees them.

We have some work to do before we can make the ads purchasable by Second Life business owners, and it’s too soon to say precisely when we’ll be able to, but we wanted to let you all in on this plan early on. We’ll blog again when we have more info to share, so keep an eye on this space!

Ads now on the SL Marketplace - although initial offering suggest some refinement of the filters might be in order
Ads now on the SL Marketplace – although initial offerings suggest some refinement of the filters might be in order

That the ad spaces will be expanded to include user-run business should amount to good news, and help mitigate objections relating to ads appearing on the various SL web properties. Allowing SL businesses to use the capability (assuming they are in a position to do so) brings both added relevance to the ads and helps SL businesses promotion themselves to SL consumers across an even broader front.

Obviously, with regards to the Marketplace in particular, some careful consideration needs to be given to how advertising for SL business will sit alongside existing aspects of Marketplace promotion, such as listing enhancements. If merchants using the latter feel that the advertising option is undermining the listing enhancement options, then it is likely that there could be a wider withdrawal from the latter than has been experienced in the past when the scheme has hit problems.

Some have called for those with Premium accounts to escape the advertising. There’s actually some merit in this – other websites offer “advertising opt-outs” on payment of a fee, so given that Premium members have already paid out, then automatically opting them out from any advertising campaign of this nature is liable to go down very well (and potentially make Premium accounts a little more attractive than offering-up cars, boats, planes and other trinkets). Certainly, I wouldn’t be against seeing the ads vanish from my views of the various SL website – although I don’t actually see them as actually impinging on my SL experience as it is.

Whether such an “opt out” could actually be easily achieved, however, is perhaps a matter of debate. As we’ve seen in matters of logging-in etc., the various SL web properties are perhaps not as well-integrated as they first appear, making any attempts to “ring-fence” Premium accounts from the advertising, even were LL so minded (which I actually doubt) potentially harder than may first appear.

Given the initial reaction to the advertising move, it’ll be interesting to see what the response to the news that the programme is being expanding is liable to be.

Related Links

LL offer Merchant Outbox project viewer

Posted on by Inara Pey

As recently reported, Linden Lab have announced the first step in the retirement of Magic Boxes in order to encourage remaining merchants who have not done so to swap over to Direct Delivery.

At the time I posted that piece, I noted that a major stumbling block in the adoption of Direct Delivery was the fact that while it tended to work flawlessly for some (myself included), for others it has been at least as problematic as using Magic Boxes, and that Marketplace issues with DD were potentially as widespread as those for Magic Boxes.

To help overcome both reservations on the part of merchants who have not yet swapped over to Direct Delivery, and to help resolve any remaining issues with DD migration, the Lab has moved to do two things:

  • Launch a fresh Direct Delivery FAQ which attempts to answer some of the most common basic questions around Direct Delivery and also point towards other resources
  • Launch an updated Merchant Outbox project viewer. This viewer, built on 3.4.4 code, and so pre-CHUI, is designed to overcome all Merchant Outbox issues recorded in JIRA WEB-4600, and the advice for anyone still encountering migration problems is to give this viewer a run.

If you’ve been using a more recent (3.4.5 or 3.5.0 code base) LL viewer, note that you might find your toolbar buttons vanishing when you run this project viewer – it’s a known issue, and buttons can be restored from the Button Toolbar.

An update Merchant Outbox project viewer has been issued to assit those encounter problems migrating to Direct Delivery
An updated Merchant Outbox project viewer has been issued to assist those encounter problems migrating to Direct Delivery

In addition, Dakota Linden has been responding to requests and questions regarding migration posted to the Merchant’s forum, and her responses may also be of assistance to those encountering problems.

Related Links

Linden Lab offer z-offset fix for Server-side Baking

Posted on by Inara Pey

Update March 4th: The main viewer download links on the Sunshine wiki page now all reference the updated viewer  version (3.4.5.271118).

Update March 2nd: Just as a point of clarification, the update discussed here is not currently linked-to from the Sunshine wiki page. To obtain a version of the viewer with the updates, you will need to download version 3.4.5.271118 of the viewer (link repeated here for ease-of-refernce).

As I recently covered, a problem has emerged with Server-side Baking in that it “breaks” the Z-offset capability found in the majority of third-party viewers.

The Z-offset allows the vertical height of an avatar above the ground to be adjusted, such that sits and kneels don’t leave the avatar apparently floating in the air, and which allow those with very tall / giant avatars or very small / petite avatars and those wearing full body mesh to similarly adjust their vertical placement relative to the ground / floor.

The problem was reported to Nyx in week 8, and SUN-38 was subsequently raised by Henri Beauchamp on February 24th to officially log the matter.

On March 1st, Linden Lab issued an update to the Server-side Baking project viewer (release 3.4.5.271118) which is an attempt to address the issue.

The new capability is referred to as SH-3909 Support avatar height offset and is described as, “Adding a new visual param that allows users to manually adjust an offset for how far off the ground (+ or -) their avatar’s root bone is.Supports the +-2m range people are used to adjusting in their viewers, but new implementation should support server-generated appearances.”

It appears within the viewer as a new slider in the Body section of the Edit Shape floater, called “Hover”.

The new "Hover" floater
The new “Hover” option in the Edit Shape floater’s Body tab

Moving the slider to the right or increasing the displayed value will move your avatar upwards, much as increasing the Z-offset value in a TPV will. Moving the slider to the left or decreasing the displayed value will move your avatar down. As with all the shape sliders, any changes must be saved prior to exiting the editor, in order to be persistent beyond editing.

The slider offers a huge range of height adjustment compared to the z-offset slider in the likes of Firestorm, and is somewhat less accurate – with most TPV Z-offset options, height above ground can be precisely adjusted to 2 decimal points, whereas the Edit Shape floater only allows whole numbers in the range 0-99.

The "Hover" option presents a huge range of vertical motion when adjusting
The “Hover” option presents a huge range of vertical motion when adjusting, which should accommodate the both the tallest avatars …

The vertical range of movement can be considerable, and lead to some interesting results when saved – your avatar can currently disappear entirely underground, for example. Also, adjustment made using the slider are not apparent in viewers which do not have the SSB code – something which shouldn’t be a major problem, given the need for people to be using SSB-enabled viewers once the server-side code starting deploying to the main grid anyway.

What might be of greater concern, however, is the fact that the control has been incorporated into the Edit Shape options means that it cannot be used on No Modify shapes, which could leave those using such shapes still feeling aggrieved if they are impacted by the height offset problems resulting from SSB.

...and the shortest.
…and the shortest.

It’s an interesting approach to solving the problem – and it would appear that LL consider the matter now resolved, Nyx Linden having issued an e-mail to the opensource dev list which reads in part:

Added a new parameter to shapes to replace the viewer-side height offset. Since it is stored in a wearable, the new back-end can read and use the value. Will send an email to third-party devs later today to let them know to pick up the patch.

Marking SUN-38 as resolved.

Given that earlier in the week – at the Content Creation User Group meeting on Monday February 25th, where the subject of SUN-38 was raised, Nyx commented, “It hasn’t escaped our notice. We’re considering a couple different approaches … we’re considering a few different options. Suggestions appreciated, but we haven’t officially settled on an approach we’re going to commit to publicly just yet”, it will be interesting to see the response is to this particular fix.

With thanks to Latif Khalifa, who both provided me with news of the arrival of this update, and provided the necessary links for me to have a play.