Today sees the first phase in rolling-out the new User Experience tools to the Main grid. As noted in the official release notes, the tools have been rolled-out to the Magnum Release Channel.
The new tools were previewed back in March in a rare SL blog post, which I covered at the time it was released. Today’s Magnum release adds three new LSL functions for User Experience:
llAttachToAvatarTemp (integer attach_point) — Follows the same convention as llAttachToAvatar, with the exception that the object will not create inventory for the user, and will disappear on detach, or disconnect. It should be noted that when an object is attached temporarily, a user cannot ‘take’ or ‘drop’ the object that is attached to them. Additionally, if this function is used with experience permissions, the user is ‘automatically’ made the owner of the object. If you use this function without the experience permission, the target MUST be the owner of the object for it to attach properly
llTeleportAgent (key agent_uuid, string lm_name, vector landing_point, vector look_at_point) — Teleport Agent allows the script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark. If the destination is local, the lm_name argument is a blank string. The landing point and look at point are respected for this call. If the destination is remote, the object must have a landmark in its inventory with the teleport agent script. lm_name refers to the name of the landmark in inventory
llTeleportAgentGlobalCoords (key avatar, vector global_coordinates, vector region_coordinates, vector look_at) — Teleports an agent to region_coordinates within a region at the specified global_coordinates. The agent lands facing the position defined by look_at local coordinates. A region’s global coordinates can be retrieved using llRequestSimulatorData(region_name, DATA_SIM_POS).
This initial roll-out does not include the expanded Experience Permissions System, as Oskar Linden points out in a forum post on this week’s server releases. Instead, the new functions work with the current runtime permissions system (specifically PERMISSION_TELEPORT), although plans are in-hand to roll-out the new permissions systme at some point in the future.
No details have yet been released on theProfessional Creators Programme that was mentioned in the original preview blog post, but if you are interested in learning more about the tools, the Advanced Creator Tools Notification Group is still open to membership, and you are encouraged to join the Group.
Oskar notes that LL will be actively monitoring the forum thread announcing the roll-out, and anyone encountering issues with the new functions is encouraged to post feedback in the thread, cross-referencing any relevant JIRA they raise.
Given the functions are now on the Magnum RC, and people are being encouraged to provide feedback, this roll-out would appear to move the User Experience tools outside of the associated Closed Beta programme.
For ease of reference, here’s the video LL released with the original preview announcement:
Alina has been beavering with Lumiya, the Android client for Second Life. Earlier this month I reported on the release of the 3D world view in the client; since then she’s been working on both extending the capabilities of the world view and making a couple of them more robust, as well as adding some additional new features. This has resulted in a couple of rapid-fire releases : 2.0.2 and 2.0.3, both of which are reviewed here.
My review system is a Samsung Galaxy S2 i9100 running Android Gingerbread. Draw Distance on Lumiya is set to 96m, sounds are enabled, but media is off.
“Long Touch”
In reviewing the 3D world view last time, I made mention of issues I experienced with the “long touch” feature: touching the screen over an in-world object & maintaining pressure for a second or two to display information on the object. This didn’t work well with my Galaxy S2 i9100, and Alina reported it was a little unstable on other ‘phones as well. She’s now improved the functionality, and it should work on all devices.
Touch-to-sit
The biggest world-view addition with this release is the ability to sit on poseballs and chairs. This again uses a a long touch approach – press a finger over the item you wish to sit upon and hold for a second or two in order to display a menu.
Sit option
Simply tap the SIT ON button to sit. Note that if the item has an associated menu, you might get an additional TOUCH button, which will display the associated menu in the Chat window, if tapped.
Additional menu button
The camera angle can be a little awkward once seated, although you’ll appear perfectly seated through other people’s Viewers. As you’ll likely be chatting or IMing when seated, the Lumiya camera angle shouldn’t be too much of a problem, and you can still orbit the around yourself to see what is going on.
Seated view in Lumiya……and as seen in other Viewers
Standing once more is obviously a case of tapping the STAND button in the lower right corner of the screen.
Minimap Options
Lumiya now has Minimap / radar functionality. You can access the map by tapping the Menu button on your device from any Lumiya screen except the in-world view. The results are impressive, with the local sim shown complete with any parcel boundaries. The display is split-screen, with (in portrait mode) the map displayed to the top, and a list of nearby people below. Rotating the screen (if your device supports it), displays the panels side-by-side – useful if there are a lot of people around you. In both views, the list of people is scrollable if it extends beyond the panel boundary.
Minimap and radar display (in landscape mode)
A nice touch with the map panel are two zoom buttons, allowing you to zoom in / out of the map (useful if there are a lot of people close to you). Tapping any of the familiar green avatar dots will highlight the avatar’s name in the radar list; conversely, tapping a name on the list will draw a circle around the appropriate avatar dot. Pressing on the name of someone in the radar list will display a pop-up menu, from which you can (with version 2.0.2):
Open an IM conversation with them
View their profile
Pay them Linden dollars.
Note that there is a slight limitation with the radar, in that avatars beyond 1024m metres distance from you will not have their range accurately reported. This is due to a protocol issue within the SL code rather than a bug within Lumiya (and is why you will sometimes see distances in Viewer radar displays given as “>XXX” (where XXX is a value) on entering a region before the radar settles down properly). Alina hopes to have a workaround for the issue in a future release.
People Search
A People Search option is now available from within the Contacts screen. This allows you – as the name suggests – to search for a specific avatar using all or part of their user name. Search results are displayed as a list, and tapping a name automatically opens an IM screen with the option to open their profile provided by a button in the top right corner.
Chat Logs
You can now opt to save all chat and IM conversations to an SD card. This option is available via the SETTINGS menu (tap your device’s Menu button and then tap settings – note that because of the additional features in some windows, you may have to additional tap MORE to see the SETTINGS option).
Other Nips and Tucks
These releases also see:
Offline IMs now include date and time when they were actually sent
Chat windows now scroll to last message when on-screen keyboard pops up
Issue with Group chat issue with messages not always being delivered is fixed
Issue with some regions failing to render in the 3D world view fixed
Numerous bug fixes and crash issue fixes.
Performance
Alina has been working on overall performance with the 3D rendering, which should benefit those using dual/quad-core systems. Certainly, when running on my Galaxy S2 over my local wifi connection, rendering did seem to be a lot faster – barely a 2-second wait from hitting the button to having prims and sculpts fully rendered. Running on 3G, there was still additional lag (unsurprisingly), but again, in terms of rendering, it was somewhat faster and smoother than version 2.0.0. Avatar movement was still prone to some delay, although I didn’t find my Crash Test Avatar bouncing off walls when seen in a regular Viewer to anywhere near the same extent, as the overall response time from 2.0.3 encouraged quick, light taps of the arrow keys, rather than pressing and holding, which tended to be the case with 2.0.0.
Overall bandwidth use while on 3G worked out roughly the same between version 2.0.0 and 2.0.3: 5 minutes (with in-world rendering of my home and moving around) accounting for some 2 Mb of bandwidth (UK O2 network).
In-world view
Opinion
Lumiya continues to grow, and the new additions with these releases make it an even more attractive option for those on the go who have an Android device and need to access SL. With options such as inventory access and improved avatar rendering coming in future releases, as well as other goodies, Lumiya is fast becoming the mobile client of choice for those on Android.
Today sees Niran’s Viewer release 1.39 hit the grid, the latest in NiranV Dean’s weekly roll-outs which started shortly after the latest time I ran a major review of the Viewer (version 1.33). Given the Viewer is now on a weekly release cycle that sees smaller, more incremental changes made to it that may not easily lend themselves to in-depth reviews, I thought I’d provide a summary of the major features that have been rolling-out with the last few releases (1.34 through 1.39).
Start-up Options
Version 1.35 introduced a new start-up splash screen, displayed automatically when running the Viewer for the first time. This screen builds on the “classic” and “shooter/RPG” keyboard layout options introduced in Version 1.33.
Keyboard layout options introduced in ver 1.33
With Version 1.35, those using Niran’s Viewer for the first time are offered the choice of keyboard layouts via an initial splash screen. Note that as Shooter / RPG is the default layout, selecting Classic requires the Viewer is restarted before logging-in.
New initial splash screen displayed on starting Niran’s Viewer (Version 1.35+) for the first time
Once selected, the splash screen changes to display the usual login-in screen with background movie. Once logged-in, the keyboard layout can still be changed via Preferences->User Options ->Advanced once the Viewer was started, although a Viewer restart is required to completed the swap.
Version 1.37 further enhanced this capability by adding a LAYOUT SELECTION option to display the log-in splash screen choices, making it easier to switch between layouts prior to logging-in to SL (Viewer restart still required).
Version 1.39 also adds audio to the log-in screen, so that the video, called “Sad World”, displayed on the log-in splash screen now has an audible soundtrack. If you’ve not watched the video with sound before, it’s really worth stopping on your way into Niran’s Viewer and doing so – the soundtrack adds significant depth to the video.
Return of the Sidebar!
Machinima Sidebar
When Viewer 2 came out, the Sidebar was – frankly – a royal mess. The intent was good, but given it came from a company that self-proclaims itself to be “interface design specialists” (80/20.com), the actual implementation was potentially the biggest pile of fetid dingo’s kidneys ever to obliterate people’s in-world experience of Second Life.
It may have provided an “unforgettable experience” (again an 80/20.com boast) – but one that could hardly be more negative in terms of user reactions to it. Whoever at Linden Lab was responsible for accepting it should have been taken outside – and never allowed back in to the Lab’s offices.
However, over time (and largely thanks to TPVs showing the way), the Sidebar evolved and actually became something pretty usable – and it is fair to say that since it’s demise, it has been sorely missed by a lot of people. I freely admit that there are elements of it I miss…
Now, Version 1.39 of Niran’s Viewer sees the Sidebar make something of a return, in the form of the Machinima Options.
Activated using the F1 key, the new Sidebar takes the form of a full-height panel that gracefully slides out from the right side of the screen. With this release, it gently moves chiclets and buttons to the left as well, but Niran plans to make the panel an overlay with the next release, so it will slide OVER chiclets and button, rather than moving them.
The panel is admittedly a bit of a monster, but for those into photography and machinima, provides a fast way of accessing and adjusting options on-the-fly. Looking at it, I’d personally like to see the capability extended to include other options – perhaps via tabbed access built-in to the panel at the top, or down the side, a-la Viewer 2 (but with the tabs themselves completely hidden as a part of the panel, rather than sitting on the right of the of your in-world view, a-la Viewer 2).
NiranV has provided a video demonstrating how the panel will look when it is working as an overlay:
Achievements
Version 1.36 introduced “Achievements” to the Viewer. This is a light-hearted means of emulating RPG-type “achievements” gained through the use of the Viewer. As you perform certain tasks, etc., so they are highlighted in a list you can view via NV->View->Earned Achievements, and colour awards are given.
The system isn’t intended to offer anything substantial – just some light-hearted fun.
Other Nips and Tucks
Version 1.34: corrected a double-click to teleport on the minimap so that double-click does teleport you to the point on the map you click, rather than opening the world map
Version 1.35: introduced split-line titles on notifiers, etc., to enable easier reading (continued in some of the later releases as well)
Version 1.36:
Tweaked the UI so that when the Navigation Bar, etc., at the top of the screen is set to auto-hide, any UI buttons located at the top of the screen will automatically re-align against the upper limit of the window, and then drop back down below the Navigation Bar when that latter is displayed
Introduced a dynamically re-sizing Group Notice panel within the Group floater, making the composition of longer Notices easier
Re-added the Restore to Last Position option to the menu when right-clicking on items in inventory.
Version 1.37: stabilised mesh rendering
Version 1.38:
Added spinners to Windlight floater settings
Re-working of the Picks and Classified floaters
Version 1.39: revised teleport progress to render the UI while teleporting – further updates coming on this.
In addition, each release has seen a range of additional small updates and bug fixes, and I recommend those that haven’t kept pace with updates take a look at Niran’s blog and the change logs provided there.
Performance
I did not update to versions 1.34 through 1.36. However, versions 1.37 through 1.39 continue to run well on my older-spec PC (see the home page on this blog for details & for my usual test parameters). Frame rates easily matched version 1.33, so it is now only my personal preferences vis-a-vis UI and layout that keep me from using Niran’s Viewer full-time.
The fact that the Viewer is now on a weekly release cycle means the changes being made are now more incremental than radical, but this is no bad thing, NiranV is clearly enhancing and refining what works and focusing on those areas his users are giving solid feedback on. This doesn’t mean that new features aren’t being developed – the Sidebar approach shows that – but it does mean that the Viewer’s development path is liable to be more of a gentle curve, again as one would expect from any maturing product.
Of all the recent updates, 1.35-1.39 inclusive, it is the Sidebar that fascinates me the most. This offers significant opportunities in providing access to a lot of Viewer functionality and of addressing the wants and needs of those who lament the passing of the later iterations of the Sidebar (oddly enough, and while I hated the Sidebar initially, I’m one of the latter, having come to find it exceptionally handy as implemented in TPVs such at Kirsten’s and Firestorm). My only complaint with recent releases is that the version numbering is somewhat out-of-sequence between the blog and the Viewer itself; for example: the latest release outlined here is referred to as release “1.39 (1277)” in the blog, however, HELP in the Viewer refers to it as release 3.3.5 (1277). The last two or three releases have been the same. While this is a minor niggle, it would be nice to see consistency in version numbering.
As I recently reported, the Exodus team have been hard at work on the Viewer, obtaining TPV Directory listing status as well as working on a wide range of new features and options within their Viewer.
This is now nearing completion, and as the team work towards their next formal release, they’ve implemented a new nightly build programme for the Viewer. As the name suggests, this will feature daily builds of the Viewer featuring the very latest options, functions and updates, ready for wider testing. In contacting me about the builds, Geenz Spad explained their purpose thus: “We want to get more people testing our nightly builds of Exodus as we near another stable release; those builds are updated almost on a daily basis … to get new features we’re experimenting with out to the public faster for feedback before they make it into a stable release.”
As daily builds there are a few points worth mentioning:
No support is provided – so please do not use them as your primary viewer
There will be issues both in terms of functionality and stability
Please do give constructive feedback to the team on any problems you have, crashes you experience etc.
If you’d like to help the team work towards future releases of Exodus, you can find out more by reading their blog post on the builds and by following the links below:
This is a weekly summary of changes to all SL Viewers / clients of which I’m aware and which are in popular use across the grid / listed in the TPVD. Detailed links to said Viewers / clients can be found in my Viewer Round-up Page. The links supplied in this summary are either to change logs or to reviews within this blog.
Another relatively quiet week. Zen rolled a released close enough to the preparation of this update that it gets included here. SL pushed out Beta and Dev viewers, Lumiya rolled a new release – 2.0.2 – and Henri made his usual Cool VL release.
Updates for week ending: 27 May, 2012
SL Viewer updates:
Release version: no change
Beta: rolled to version 3.3.2.257717 (May 22) – release notes
Development: rolled to 3.3.3.258002 on May 24, then to 3.3.3.258100 on May 26
Exodus has introduced nightly builds ahead of the next release
Niran’s Viewer rolled to 1.38 (21st May, reported last week)
Zen Viewer released version 3.3.3.5 on May 22nd and 3.3.3.6 on May 28th (close enough for this update) – release notes
Cool VL Viewer rolled to 1.26.4.14 and then to 1.26.4.15 on 25th May, with the change log here
Lumiya rolled out version 2.0.2 (release notes) on May 27th; a few bugs were noted, so expect an update soon (and review to follow in this blog)
Group Tools made a further release on May 23. Due to issues with the trial licence, still unable to test / review.
There has been much in the way of heated debate on the subject of the mesh parametric deformer and standard sizes for avatars of late. So much so that in this week’s Metareality podcast, Kimberly Winnington (Gianna Borgnine in SL), deformer coder Karl Stiefvater (Qarl Fizz in SL) and in-world content creator Cathy Foil discussed the debate at some length and touched on other aspects of the deformer project.
The following is a summary of the core aspects of the discussion, presented in the panelist’s own words. My thanks to Kimberly for allowing me to produce this piece.
[2:10] Kimberly Winnington (KW): As it stands now, mesh items have to be built to the default avatars like the Ruth Avatar and then be deformed.
[2:32] Karl Stiefvater (KS): There’s a slight difference between Ruth, the actual Ruth – a lot of people call different shapes “Ruth”, so that’s a bad term to use – and the important shape, the one that you get when you say, “Hey, I want to do a shape!” and you don’t touch any of the other dials … and I call that the “default shape”.
[2:58] KW: So as it is now, clothing has to be built to that default shape before it can be deformed.
[3:04] KS: Right.
[3:05] KW: And it’s been suggested it should … that group of things like the default avatar should include some sort of standard size as well, even though that’s not officially a feature at this time.
[3:22] KS: That is correct. The rationale there is the deformer isn’t perfect and if you start with a shape that’s closer to your end shape before you actually tweak it, you can get superior results … Even if the deformer worked perfectly, when you design a shirt with a floral print … and you put it on someone with their body weight turned all the way up … the floral print is going to be distorted … So with the new system, the artist could say, “I’m going to repaint that floral print so it doesn’t get stretched out.”
[4:19] KW: There’s this fight going on. Emma Gilmore, also known as Elie Spot – she is of course on the standard sizing side, she was one of the people who worked with a bunch of other designers and came up with the standard sizes. And then I guess on the other side of the argument is Maxwell Graf … he’s on the side that the standard sizing is a marketing ploy and is awful and we shouldn’t even tolerate its existence. And I guess I’m somewhere in the middle of those two arguments on the basis I kind of agree with the standard sizing – not as the official solution because I don’t want to change my avatar … so I’m all for the deformer and do not want to have standard sizing as the only solution. However, I would have a much better chance of fitting into something without a lot of stretching if I stretched from a size that was closer to my avatar than the default avatar … But I still think that it’s at least a solution that should be discussed; where the starting-off point for the deformer should maybe be closer to a standard size.
[6:56] KS: It sounds like you and I are in agreement …
[7:15] KW: The other thing that came up was … Emma was talking to you about possibly having a way they could convert current meshes without having to re-upload, and you had suggested to her that she post on the JIRA and get some feedback from some other people. So the problem became she posted on the JIRA and she posted a Plurk about both these issues. like let’s discuss where we should start from and lets talk about whether we should be re-uploading or converting and how should we do that … So it started this huge fiasco where everybody kind-of attacked her both on the JIRA and totally all over Plurk, and were like, “you’re wrong, you shouldn’t be posting here…” … I actually agree with her and think she has a good point; but whether you agree with her or not, the topics she brought up are important for us to discuss as a community, especially designers and people who want to wear mesh. Because once the thing is final – you know how things go in Second Life; it will come out and everyone will be unhappy with it but it will be too late to do anything about it. So you have to do it now …
[9:59] KS: The deformer isn’t perfect. There are problems and what she’s proposing … is an extension … so it doesn’t take anything away from what you had before; it’s just adding new features. So how can you hate something that has everything you want but has this extra thing that somebody else wants? How does that engender white-hot hatred? I don’t understand.
[10:36] KW: I think there’s two things. I think the first on is not understanding that it works in collaboration with the deformer. So I think there’s a lot of people…they hear “standard sizing” and they are automatically like, “No”, without understanding that it’s not going to work like standard sizing is now … that you have to fit to that standard size. This is just in collaboration with the deformer, and I almost want to name it something else….
[11:03] KS: How about “alternate bases”? … Alternate bases, everyone.
[11:14] KW: The other thing that comes up is that a lot of people feel like that if we make a solution that fits … then Linden Lab will stop trying to think about trying to create a new overall avatar mesh.
Karl Stiefvater (Qarl Fizz)
[11:47] KS: I don’t thing that we’ve forced them to do anything ever … They’ve never given in, ever! So I don’t see that as a smart strategy … One thing I want to add to this, tho, is this other aspect that I don’t think anybody knows about. And that is, Linden Lab, internally, is … struggling with a question that is probably going to delay the deformer even more. And that is, they don’t know if they like the default avatar as the base. They think there might be a better base. … Then the question is, so how do you pick a better base? Some of them are suggesting … that adding curves is easier than removing curves, so if the base was something that had no boobs, that had no curves or shapes whatsoever, that might perform better … But they have no system in mind for making this call. So this is like one of those objections that can never be necessarily resolved, which is very dangerous for the project. So one of the things I like about this alternate bases idea is it neutralises this potential problem, because if they think there is a better base avatar, we can just add it later. As soon as they decide what that perfect base is, we’ll just add it to the list. So it’s beneficial for reasons completely unrelated to the whole fight right now, so that’s something to keep in mind. That’s mainly why I’m sort-of leaning this way … because it kills two birds, and one of these birds is otherwise potentially project destroying.
[14:23] Cathy Foil (CF): Is it possible to have the content creators load-up their own custom bases for their mesh? Would that be possible? Or would they have to create their own blend shapes so they work with the sliders?
[14:40] KS: No … they would have to use the existing shapes, the existing parameters. But they could specify their own set of parameters; that’s doable, but I’m a little bit afraid that that’s over-designed … so I think that maybe down the road that’s a good option, but I think for right now just a set … just six or seven different bases….
[15:16] CF: I did have a wackadoodle idea I wanted to put forward. I know it’s probably way too late in the development … right now you have the avatar mesh is driving the deformer of the mesh clothing, and I thought of the idea of having “deformer underwear” so to speak, an invisible mesh that you wear so that the avatar’s mesh deforms the underwear but then the underwear deforms the clothing mesh … so that the designers could create custom underwear that would only fit over certain parts of the avatar if they wanted or they could have more vertices in the underwear that would spread out the deformer so that they would deform the clothing mesh maybe a little bit more evenly.
[16:08] KS: That’s a clever idea … but no it’s too late for that! [laughs] But that’s interesting and that could definitely be in version 2 … Then clothing could work on avatars that are completely alien, you know, something you couldn’t dial around … like an elephant .. you could create an elephant avatar and then your hoodie or your dress would fit…
From here, the discussion moved out to talk about design techniques before moving on to the remaining topics of the podcast. For those interested in the mesh deformer and the ongoing debate, I thoroughly recommend listing to the podcast in its entirety, which also includes issues such as DMCA, copyrights and a discussion about the use and impact of the SL Marketplace.
Inara Pey: Living in a Modemworld 