As most know, changes to the Google translation services are coming. The v1 service was depreciated in May of this year while free access to v2 service was discontinued for “new” application requests on the 24th August (access switching over to their paid service), with all existing access to the free service started prior to the 24th August due to be discontinued from December 1st.
The Lag – via Oz Linden mulled over alternatives for a time, via JIRA, and this has resulted in two options for continuing to use an in-built translator in the future, by using either the paid-for Google Translate API, or by using the Microsoft Bing translation API.
The new translation options are not live as yet, but can be seen in the latest Development Viewer (3.2.2 (224260) or above or the latest Beta Viewer (3.2.1 244227 or above and which also has the new Viewer UI incorporated in it).
Accessing the Translate Options
To access the translation options, go to PREFERENCES -> CHAT and click on CHAT TRANSLATION SETTINGS. This will open a further floater:
New translation service options
As can be seen, the Google translate option is retained – but you’ll have to sign-up and pay for the service yourself.
The Bing option provides a means to continue with a free translation service, but will require you register for a WindowsLive ID, if you don’t already have one.
Using the Bing Translator Service
To obtain a Bing AppID:
Click on the Bing AppID link in the floater. If you have a WindowsLive account and are logged in, you’ll be taken to the application registration page
If you don’t have a WindowsLive account or are not logged in, you’ll be taken to the sign-in registration page
Once you are signed-in or have gone through the registration / verification process, you’ll be taken to the application registration page. This isn’t a terribly helpful page, but essentially:
In Application Name type “bing” or “bing translator” (although I get the impression just about anything will work)
Fill-out the rest of the required fields and accept the terms & conditions
Clicking SAVE takes you to your Applications page – this may take a while to load, (and may even time-out – did on me the first time) – but it should eventually display the application name you gave, and an ID – highlight and COPY this
In the Viewer Chat Translations Settings floater:
Check ENABLE MACHINE TRANSLATION WHEN CHATTING
Click the Bing Translator API radio button
Paste your copied AppID into the Bing AppID field.
Click OK
Close the floaters and away you go!
Note that as this is a Development Viewer, as such details on the Chat Translation floater may change between now and it reaching a formal release (work was still on-going last week).
I actually missed this at the start of the month (blame it on my birthday and work…). The new Viewer UI has taken a step closer – it’s now at Beta (3.2.1 244227), and includes all the latest revisions, including:
Interestingly, the Direct Delivery Received Items section of Inventory, that was present in the Development Viewer is not present in the Beta release (nor is it visible in the latest Development Viewer release (3.2.2 (224260)). Is this an indication that LL are heed calls from merchants not to release DD before the New Year, or that the code slipped into the earlier Development releases in error?
I’ve taken it for a quick spin, and found performance to be equitable to earlier releases, and other than the translation and Destination Guide tweaks, I’ve not come across any significant changes – but it was a quick spin.
Given the UI is now in Beta and caveating the DD situation and – more importantly – the progression of the OpenGL fixes, this could be taken to mean the UI will be in a release update sooner rather than later – although admittedly not as soon as part of me thought LL might shunt it out.
There have been a couple of recent Viewer updates in the last 24 hours. Yesterday I reviewed the latest Exodus Viewer release; it wasn’t alone – Dolphin 3 also saw a new release – 3.1.1.21151.
Both of these are interesting as they include support for two new avatar attachment points: Neck and Avatar Centre.
Neck will allow the wearing of items at the neck point (such as necklaces, collars, etc.), which will move with normal avatar body movement
Centre is a “fixed” attachment point which is static – so it does not move with your avatar’s movements (i.e. in response to an animation such as a dance, etc). This allows attachments that do not need to be seen to be attached to the body, or can be used with reference to vehicles, etc.
New attachment points
Both attachment points are also available in the latest SL Development Viewer (3.2.2.244260 or above) and in any self-compiled builds from the latest Firestorm code release.
There are a few things to remember when using these new attachment points:
As one might expect, items will require a degree of adjustment to fit correctly – especially on the Neck attach point
Don’t use the Avatar Centre point for anything you wish to be visible and needs to move with your avatars movements – it won’t. Avatar Centre isn’t the place for skirts and belts, unless you want them standing on their own on the dance floor while you gyrate!
Until the code is fully supported across all Viewers, to anyone not using a Viewer supporting these attachment points it will appear as if you’re wearing items incorrectly (as with the old Emerald multi-attach issue). Once the code is absorbed into all Viewers, this issue should go away.
If I’m totally honest, there is perhaps too much movement encountered with the neck attachment point – if your AO causes a lot of natural head movement, you may find necklaces, etc, vanishing into your collar bones or into your chest rather a lot. Those familiar with wearing collars may find that rather than the collar remaining relatively static compared to head movements (as when attached to the Spine or Chest points), the collar moves rather disconcertingly.
The first phase of the new UI has arrived as a Development Viewer release (3.2.1 (243328)). So what do we have in store?
No Modes
Well, actually, quite a lot, and it’s obvious right from the login screen, where the absence of the BASIC and ADVANCED modes is clear.
No mode options!
Once logged-in, more differences make themselves immediately felt:
The top of the UI has been revised so that the Navigation and Favourites bars have been combined, with a slider between the two allowing you to adjust their sizes relative to one another
There is a new button up on the Menu Bar I’ll return to shortly
There are no Sidebar tabs visible on the right of the screen
There is no chat bar at the bottom of the screen
There are two sets of buttons visible: one on the left, featuring icons only (by default), and one at the centre bottom of the screen, featuring text and icons (by default).
The default UI on logging-in
If you want to type, you can either click the CHAT button on the bottom toolbar, select NEARBY CHAT from the COMMUNICATE menu (as per previous versions of the Viewer) or, in a move that follows V1 behaviour, tap ENTER. All three options will display the chat bar in its own repositionable floater.
Buttons, Buttons, Buttons
As there are a lot of them, let’s start with the buttons – most of which should be perfectly obvious.
On the left of the screen, we have by default, seven buttons. These are: Avatar, Appearance, Inventory, Search, Places Map, Nearby Voice and Mini-map. All of these will be familiar to V2/V3 users. They perform the same functions as in earlier releases of the Viewer; although in the case of Appearance, Inventory and Places, rather than opening them in the Sidebar, the buttons open the Appearance (outfit), Inventory and Places panels in their own floaters.
I have to admit, Mini-map had me fooled for a moment – the button’s icon suggests it is something to do with Voice.
Only Avatar is a new button here, lifted directly out of the BASIC mode. Clicking it opens up floater than enables you to pick an entire avatar look – shape, skin, clothes, etc. Four types of avatar are provided with the development release: human, animal, robot and vehicle. One suspects further choices (such as other races) will be added in time.
At the bottom of the UI is the more familiar toolbar with the following options: Chat, Speak, Destinations, People, Profile, View, Move and How To.
Of these, Chat enables the chat floater, as described above, while Speak, View and Move do exactly what they did in previous releases of the Viewer. People and Profile display the People and Profile panels from the Sidebar, now in their own floaters, leaving Destinations and How To.
Both of these will be familiar to those who have tried the BASIC mode: Destinations displays a mini Destination Guide floater, with destinations split into categories: What’s Hot Now, Chat, Newcomer, popular Places, and so on.
Destinations FloaterHow To
How To is something I’d speculated / hoped would be carried over from the BASIC mode as a part of the merge. I was a big fan of How To when it made its debut in the BASIC mode, as it is a simple, easy to use “cue-card” system for obtaining help, especially for those new to SL. If I’m honest, it is something I banged on at Rodvik about back when it first appeared, I was that enthusiastic about it, so I’m really pleased it has come up into the revised UI.
True, I’d personally like to see the range of topics it covers increased (without going completely overboard), but perhaps further topics will be added over time.
Within How To, the GET LIVE HELP option is new – it wasn’t in the BASIC mode. At first my oldbie heart soared on seeing it, as it seemed to herald the return of the long-gone and sadly lamented Live Help as used to be in Viewer 1.x.
Sadly, this is not the case. Selecting the option displays this message:
“Need help?
“Click the button below to teleport to a Help location where a Second Life guide is available to assist you between the hours of 10am – 6pm PST.”
Beneath it is a TELEPORT button, which in turn opens the Places floater, from which you should, in theory, be able to teleport to a suitable help location. Quite what or where this help location is and who staffs it (one assumes resident volunteers) is unknown. I’m not sure if it is because I tried the option after 18:00 SLT or simply that the function isn’t working as yet – but Places came up a blank, leaving me nowhere to teleport.
So, back to the buttons…
Looking at the layout, one might end up thinking that all LL have actually done is swapped a set of ugly tabs and screen-hogging slidey Sidebar and replaced them with a set of buttons on the left of the screen.
And one would be entirely wrong. Why? Because these buttons are movable buttons. Not only that, they are customisable (to a degree). For example, right-click on any of the sets of buttons and a prop-up displays a menu with the options CHOOSE BUTTONS, ICONS AND LABELS and ICONS ONLY.
The latter two options allow you to switch between displaying the buttons with icons only (as is the case by default with the buttons on the left side of the screen) or with an icon and text (as is the case with the buttons on the bottom of the screen). But it is when you select CHOOSE BUTTONS that things start to get interesting, because this displays a Button Toolbox floater (which can also be accessed via CTRL-T or the TOOLBARS option of the ME menu).
Button Toolbox
This contains all the buttons available to you within the UI. Any buttons that you haven’t yet used are highlighted for easy identification. Note here, as well, that there are a few new buttons to play with, notably ABOUT LAND, PICKS AND PREFERENCES (yes, you can now have one-click access to the Viewer Preferences!).
To add a button to your UI simply position the mouse pointer over it, click and hold the LEFT mouse button and drag the button from the toolbox.
As you do this, you’ll notice the border on three sides of the Viewer turns blue, indicating you can position the button either on the left, bottom or right side of the screen. Nor does it end there.
You can also move buttons between locations (left side, right side and bottom of the screen) using the same method: simply left-click and hold over each button you wish to move in turn, and drag it to your preferred location. Thus, it is perfectly possible to have all your buttons placed at the bottom of the screen a-la V1, or you can split your buttons between the bottom and right of the screen, a-la a “traditional” V2 style.
Tateru Nino carries some news relating to the initial changes to the official Viewer UI, obtained courtesy of Rhett Linden.
Rhett’s revelations, while interesting reading, are not entirely earth-shattering, and don’t actually go that much beyond what Rod Humble himself has already said concerning the Viewer, and what some of us were speculating as a result.
In a nutshell, Rhett has confirmed:
The Sidebar is to go. This is something that wasn’t hard to guess at, given Rod himself said as much at SLCC 2011
There is to be a more flexible approach to the UI in general, that will allow users to, “Arrange the UI to fit the way they use Second Life. This is important because it moves us toward a model more like most creative software“
This latter point more than likely refers to things like the “Customise Toolbars” and the “FUI” (which people have taken to mean “Flexible User Interface”), both of which are mentioned in passing / hinted at in the SL Helpfile wiki pages (although no specific information is available on either right now). Certainly, the release notes for the merge (see below) point in this direction as well.
What is worthy of note is that Rhett confirms that the initial code for the UI changes, which should also see the arrival of things like click-to-move and the new camera palette (again as revealed by Rod Humble, this time talking on the SL Universe forum), was merged into the Development Viewer code today – although TPV developers had been expecting as much, going on comments passed elsewhere during the day.
For those planning on trying out the latest development Viewer, be aware that the release notes state:
The Viewer floater camera views and presets do not work
The Nearby Voice panel does not update to a new call or from nearby voice info once opened
Viewer crashes when updating UI size in preferences
The Speak button is activated when dragging and dropping between toolbars and/or moving back to the toolbox
Viewer crash when moving the speak button from one toolbar to another when there is an active call request
Teleport history doesn’t display visited locations
Viewer crash when double-clicking the mini-map in People > Nearby
Notification and conversation chiclets overlap
WASD controls don’t move avatar while move floater is in focus
Closing voice controls while a group or p2p call also closes the group call / IM window
Viewer crash after teleport
Hitting back in the ‘Create Group’ panel or ‘Blocked’ panel requires multiple clicks for action to occur.
In the wake of the arrival of mesh, and in the hope of alleviating confusion / making things a little more understandable, there are changes coming down the road for Viewer 3. Some of these will undoubtedly make their way into TPVs as well, so here’s a quick overview.
The changes described below can be seen in the latest Mesh Development Viewer from Linden Lab (3.0.5 (240741)+), which can be obtained from the alternate viewer wiki download page. note that as this is a development Viewer, some elements may change in relation to descriptions provided here.
Prim Equivalence and Land Impact
For a general user perspective, this is probably going to be the most obvious change.
Prim Equivalence, or PE has been an issue on many levels, not the least of which, for consumers, is that it tends to be bracketed with a prim count value – and is frequently greater than the associated prim count (although there are items where the reverse is true). People therefore get confused as to which is the key value: prim count (which everyone is familiar with) or PE.
In order to try to solve these issues, the terms “Prim Equivalence” and “prim count” are set to be replaced by a single value: “Land Impact”. How this will work takes a little explaining on two fronts, as it relates to a couple of changes within the Viewer and how we need to view things. So bear with me while I attempt to explain.
The first of these changes is that land will no longer be referred to in terms of prim counts and usage, but rather in terms of its “capacity”. Essentially, this means that:
Full sims have a “capacity” of 15,000
Homestead sims have a “capacity” of 3,750
OpenSpace sims have a “capacity” of 1,875.
Land parcels will also be referred to in terms of their “capacity”:
About Land today: prim counts (l); As it will be: capacity (r) (click to enlarge)
This might all sound like unnecessary semantics – but it does have a point in that it allows everything to be thought of equally, regardless of its origin – as we’ll see below.
Note as well, that nothing is physically being “lost” from your land. A 4096 sq m parcel that had a prim count of 937 prims before the arrival of the new Viewer will simply have a “capacity” of 937 after the new Viewer has entered general use, as shown by the figures highlighted in green in the above images.
To align with this, objects need no longer be through of in terms of their prim count or their PE – but simply in terms of their Land Impact – that is, how much of the available “capacity” on a sim / parcel they take up. This is reflected in changes being made to the Build menu floater:
Build floater: As it is with Prim count & PE (l); The new Land Impact values (r)
As can be seen, the prim count / PE values are being replaced with two simple figures:
The impact the rezzed object has on the land
The remaining capacity that is available for rezzing further objects.
So if an object has a Land Impact of 15, it will reduce the land capacity by 15; if it has an impact of 150, it will reduce the land capacity by 150, regardless as to whether the object itself is made of prims or is a mesh object.
For people who want more detail on individual objects, the new Build menu also includes a MORE INFO link. This opens an additional floater which provides:
Information on the object itself (including the prim count for those missing it!)
If the object is a mesh creation, the “weights” applied to it in terms of the bandwidth required to download it, the server resources it uses, its physics weight, etc.
The overall land impact: impact of the object itself, impact of all objects rezzed, remaining free capacity and total capacity for the land itself.
MORE INFO: for a prim object (l) and mesh object (r) – note the weights for th mesh object
There will also be a WHAT IS ALL THIS? link which will open a Help page that explains the various figures.
Replacing both prim count and PE with a single, easily understood value (Land Impact) makes sense, and at a stroke makes the impact of rezzing any object in-world easy to understand, removing any confusion between prim count and PE.
Of course, there are going to be voices that proclaim the change is about further “hiding” the “real” cost of mesh objects from the user, with the underlying implication that the users are somehow being hoodwinked by Linden Lab. But, c’est la vie. People are wont to make waves come what may.
It will be interesting to see how merchants react to the change – given that all vendors, etc., refer to prim counts right now, and getting wording changed to “Land Impact” (or simply dropping the word “prim” from displays) is a nontrivial issue for many. Some may even opt to retain the use of “prim count” in their vendors for this reason.
And when considering merchants – one hopes that Linden Lab will actually remember to update the Marketplace so that listings also reflect the use of “Land Impact” (i.e rename Prim Count!).
Avatar Rendering Cost and Avatar Draw Weight
Alongside the changes around PE and Land Impact, the Viewer will also be losing another measure that has always caused controversy and angst: Avatar Rendering Cost, or ARC.
Always intended to be an indicative figure for the amount of potential Viewer-side lag avatars create, ARC quickly became viewed by some as the figure for determining whether or not an avatar was “creating lag”, which in turn lead to a lot of drama in some quarters – up to and including people being banned from venues / sims on the basis of their ARC count.
DWA: 197,484 – but don’t panic!
From 3.0.5, things will be totally revamped. ARC as a term is vanishing from the Viewer to be replaced by Draw Weight for Avatars (DWA). Furthermore, how DWA is calculated is radically different to how ARC has been calculated, as Nyx Linden explains.
DWA should be far more accurate than the old ARC system; and therein, one cannot help but feel, lies the rub.
If the figure is indeed more accurate, it is likely to be pounced upon within even greater zeal by those already obsessed with ARC. As such, I can’t help but hope this is one value that Linden Lab don’t make a song-and-dance about when these changes to the Viewer are formally released for general use.
Mesh Uploader
Another source of irritation for content creators has been the mesh upload floater. At SLCC 2011, Charlar Linden himself admitted the current floater is isn’t overly user-friendly. As such, it is also being overhauled, as can again be seen in the current Mesh Development Viewer.
The current upload floater presents a basic set of modifiers that can be applied to a mesh object prior to uploading in order to optimise it. These tend to encourage a lot of trial and error / guesswork on the part of the creator in order to arrive at a desired result.
The current mesh object upload floater
The new upload floater offers a greater range of modifiers and the ability to better define the model itself in terms of what it represents (avatar shape, avatar attachment, moving vehicle, etc – see the drop down in the image below), which presumably apply suitable algorithms that help optimise the object and calculate its overall weight.
The new mesh upload floater as it appears in the Mesh Development Viewer
I understand that several of the changes in the new upload floater are as a result of consultations with / requests from mesh content creators, so hopefully they will go some way to easing the process of importing objects into Second Life.
More to Come
These are by no means the only changes coming to Second Life and the Viewer as a result of the arrival of mesh object support. For one thing, more needs to be done in the area of mesh clothing in order to make it easier to adjust clothing to fit the avatar, rather than the other way around as is currently largely the case. Therefore we can expect to see further changes in relation to this in the future (indeed, those interested in the issue should check Maxwell Graf’s JIRA relating to a parametric deformer).
In the meantime, the above should hopefully give insight into what is waiting just around the corner.
Inara Pey: Living in a Modemworld 