Watch out – your avatar is about to get it in the neck (but in a good way)

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.

However, if you want to try the ne new attachment points out, why not give the SL Development Viewer (3.2.2.244260 or above), Exodus 11.10.31 (b) or Dolphin 3 3.1.1.21151 a go?

Firestorm shifts gear

firestorm-logoI reported on the last Phoenix Hour update recently, in which Jessica made it clear that where new releases of Firestorm are concerned, the team is pretty much waiting on Linden Lab and fixes to the OpenGL issues (for which the team are also providing assistance).

At the time of that broadcast, LL were saying that it could be another couple of weeks before suitable fixes are in place and ready to roll. However, since that time, progress has been made, although there still issues to be resolved. Among these is an issue with Mac systems using nVidia, which can experience black screens when running SL.

While there is still no date for merging the revised code into the main Viewer code, the progress, together with the fact that it has been a little quiet over on the Phoenix blog has prompted Jessica to drop a line or two on what is going on.

In the post, Jessica discusses the OpenGL issue, before going on to state:

“As of yesterday Firestorm development shifted into release mode. This means we are now focused on fixing the significant remaining bugs, polishing up any unfinished features that have been in progress and we’ve started an intense QA program. If all goes well, the next release of Firestorm will be the big one!”

Of course, such an admission is bound to bring cries of when, as Jessica acknowledges. However, she will only say:

“Unfortunately it seems every time we announce a date.. something goes wrong to jinx it, so I won’t go down that path, but I will say.. VERY SOON!”

This is pretty positive news, as the release promises to be pretty amazing, featuring, among a long list of things:

  • Spell checker
  • AO updates
  • Inventory “jump” fix and improved inventory load times
  • Mouselook zoom
  • Notecard text search
  • Chat bar auto-hide
  • More V1-style functionality in the Phoenix mode
  • Radar-in-a-floater
  • Right-click -> reload texture
  • Mesh uploads!

Commenting on the promised mesh-rendering version of Phoenix, Jessica indicated this will be following a couple of weeks behind the Firestorm release.

I’ll be aiming to bring a review of the release as soon as possible after it hits the download page!

Firestorm and Phoenix: updates and support notes

firestorm-logoThis week’s Phoenix Hour saw a couple of guests sharing the sofa with Jessica: Ed Merryman and Lette Ponnier, who would be joining Jessica and Phaylen in a discussion on matters relating to Viewer support. Ed actually heads-up the Viewer support side of the Phoenix / Firestorm group, and both he and Lette provide classes in using Firestorm.

To kick things off, however, Jessica ran though the latest status for both Phoenix and Firestorm before going on to pass comment on the new LL Viewer UI – which, at the time of her comments, was about to be merged with the Development Viewer code but had not actually been released for anyone to see.

The Viewers

Overall, not a lot has changed since my last report on The Phoenix Hour – the team are really waiting on LL to resolve issues their end before making any further releases of either Phoenix or Firestorm.

Phoenix Status

  • The mesh rendering code, supplied by Henri Beauchamp, is in the Phoenix code repository
  • The current graphic issues being experienced with the Firestorm Mesh Beta (and other mesh-capable Viewers) will be in the code for mesh rendering in Phoenix; Jessica estimated that around 50% of people using mesh-enabled Viewers are caught with the issue (basic shaders causing Viewer crashes)
  • This issues are Linden Lab issues, and as such, Phoenix is being held pending a fix or fixes from the Lab
  • The team have been working with LL with these bugs, and a version of Firestorm would be pushed to the Beta group to assist with further testing on the working being undertaken to fix things.

Firestorm Status

  • The next release of Firestorm is good to go, but again awaiting the GPU-related fixes from Linden Lab
  • All blocking issues from with the Firestorm project that might have delayed a release have now been resolved
  • There are still a number of targets the team would like to achieve prior to a release, but these are not blockers to a release; so if a graphics fix comes out of LL before all the targets have been reached, a release may still go ahead
  • Issues and fixes for Firestorm can be tracked via the project JIRA – although people will need to register in order to gain access
  • Focus has been placed on Firestorm locking-up and going into “(not responding)” mode and also inventory load times; Nicky Dasmijn has, in Jessica’s words, “Made a world of difference” to the issues
    • Jessica is convinced even those who didn’t have major inventory load time issues are going to notice a significant performance improvements as a result of this work once the new release can be rolled out
    • As an example of the improvements, she stated her own 72K+ inventory now takes around 20 seconds to load!
  • While the new mesh uploader will be in the next release, as per the last Phoenix Hour, there are some issues around the physics weight calculations for mesh objects (which are presumably being worked on)
  • New feature: Jessica revealed during discussions that a new feature has been added to Firestorm for the next release: right-click -> reload texture. This forces the server to re-send a given texture (worn or on a prim) which has failed to rez.

So to repeat: progress on both Phoenix and Firestorm has been good, but until the graphics issues are resolved by Linden Lab, there will not be any releases. As a side note, Jessica and Ed said the Lab themselves are indicating it will possibly take another two weeks of effort on the Lab’s part to resolve the issues – but this is not guaranteed.

New Official Viewer UI

Jessica expressed disappointment around the way in which Linden Lab has handled the  new Viewer 3.x UI, going so far as to state the view that working “in secret” on the UI was “Wrong. In so many ways”. Given the degree with which TPV developers working on V3-based code have been trying to make the Viewer more accessible and acceptable to die-hard V1.x users, one has to admit it is hard not to agree with her – although not necessarily for the reasons she cites.

Had the Phoenix team, for example, been made aware of LL’s plans, they could have made a choice as to whether to pursue the massive amount of effort they’ve put into creating a V1-style option for the Firestorm UI or whether to direct that effort elsewhere – such as in supplying even more help to LL in trying to resolve the current graphics problems. As it stands, a lot of effort on the part of the team may well have been wasted, and LL have run the risk of alienating TPV developers who might otherwise be well-placed to assist them with future issues.

However, the flip side to this is, of course, that the new UI hasn’t been developed “in secret” in the strictest sense. While the code may have been developed without much in the way of consultation with the user community, Linden Lab nevertheless do have over 18 months of considerable feedback from users on the Viewer 2 UI. They’ve also taken positive steps to better understand its limitations for themselves, as demonstrated at SLCC 2011. Ergo, the redevelopment work isn’t directly comparable to the situation that brought about Viewer 2.0, with the work being carried out in an apparent vacuum.

Support

The core of the show was devoted to support issues – especially in relation to Firestorm, but some of which also applied to Phoenix. This started with a review of the Firestorm courses the team offer, the schedule for which can be found on the Phoenix / Firestorm wiki, before moving on to the most common issues the support team deal with.

Bake Fail

Bake fail is the number one issue for the Phoenix / Firestorm support team, despite the fact it is not actually a Viewer issue per se. Rather it is a server-derived issue involving a communications failure, such as between the server and your computer, or the server and someone else’s computer / a group of computers. Typical examples of each are:

  • Everyone else sees you in an outfit you just changed into, but you still see yourself in the previous outfit = you have suffered bake fail
  • You see yourself wearing the outfit you’ve just changed into, but others see you still in your previous outfit = others have suffered bake fail.

Oz Linden has defined this problem as being the result of a series bugs within the rendering pipe (not all of them directly connected with bake fail itself) that have individually been treated with a band-aid at the time they occurred, with each bug causing the next bug in the chain. This has resulted in an issue that – as much as Oz has stated he’d personally like to see fixed – is next to impossible to sort out without significant time and effort (and risk) being put into the rendering pipe itself – a piece of code LL tend to treat with the utmost caution.

Once again, Phoenix provide a wiki page with information on how to fix a bake fail problem.

Back-up Your Appearance

Ed makes a point of expressing the value in making sure you make a “backup” copy of your appearance as far as you can – skin, hair shape & suitable clothing. If you have severe rendering issues, and REPLACE CURRENT OUTFIT isn’t available as an inventory option because it is grayed-out, drag the folder with the back-up from your inventory and drop it onto your avatar.

Blurry Textures

If your avatar bakes, then the textures go blurry, you rebake & go blurry, try:

  • Reducing your texture memory allotment by around 75% of the current setting
    • Firestorm: PREFERENCES -> GRAPHICS -> HARDWARE SETTINGS
    • Phoenix: PREFERENCES -> GRAPHICS -> HARDWARE OPTIONS
  • Reducing the number of HTTP concurrent requests by around 50% of the current setting
    • Firestorm: PREFERENCE -> GRAPHICS -> RENDERING
    • Phoenix: PREFERENCES -> PHOENIX -> PAGE 2 -> ADVANCED GRAPHICS
  • If both of these fail to resolve the issue, disable the HTTP Get function entirely (uncheck USE HTTP TEXTURES in Firestorm or GET HTTP TEXTURES in Phoenix, which are contained in the respective Viewer Preferences tabs defined in the above steps. If you disable the option, make sure you clear cache to avoid texture corruptions.
HTTP get texture options – possible aid in resolving avatar blurring issues

I See Grey People

An interesting tip from Ed Merryman formed a part of the bake fail discussion: if you see a grey avatar or avatars near you, don’t ask them to rebake – try changing your Group tag.

DNS Issues

Lette offer a number of solutions were offered for those experiencing a DNS related error on trying to log-in to Second Life:

  • Check your anti-virus software, some anti-virus software mistakenly view the Viewer as somehow harmful / trying to make an illegal connection and block it from doing so (some may even throw out a virus infection warning)
  • Try flushing your DNS cache
  • Change your DNS server to Google Public DNS or OpenDNS.

DNS errors appear to be on the increase across all Viewers, although why this should be isn’t clearly understood at this point in time.

The Phoenix / Firestorm Wiki

One of the best places to get help for either Phoenix or Firestorm is through the wiki. This includes details on basic troubleshooting, dealing with issues such as bake fail (as described above) and information on Firestorm classes, etc. The wiki also has a number of pages that cover broader issues and items, including:

Both of these pages are being continually updated, so people are asked to take a peek at them when encouraging issues.

The Phoenix Team Halloween Party

At 14:00 SLT on Saturday 29th October, the Phoenix team will be hosting its second annual Halloween Costume Party. Arrangements are still being made, but details and an LM will be sent out via the support group nearer the date.

See the show in full on Metamix TV.

Viewer 3 new UI: first looks

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 Floater
How 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.

You choose where the buttons go

Continue reading “Viewer 3 new UI: first looks”

Viewer UI: Rhett gives a little more information

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.

Kirstens Viewer: looking to Crowdfunder

Coming on top of yesterday’s tweet, there is good news for those who wish to see Kirsten’s Viewer continue.

Kirstenlee Cinquetti has announced that, following the outpouring of support for the Viewer, the team are going to try and obtain funding by going the Crowdfunder route.

In announcing the approach, Kirstenlee blogs:

Many of you have asked and wondered what the future would hold for the Viewer, well here is the answer..

After lots and lots of thought and quite a bit of behind the scenes activity we are going to go Crowdfunder!

The upshot of the whole deal is this, a target has been set to fund the entire project and it’s continued development for a period of one whole year. What happens remains to be seen, I can however reveal a few details of what does happen if we hit the target, and more critically what can occur if we exceed the funding target. If we seal the deal, almost instantly the binaries will become available for download the project will become active again and an updated and early build of S22 will become live.

If the funding target is achieved, it means that the binaries will be released once more, and work will immediately continue, with a list of juicy enhancements coming down the line over time:

  • Programmable camera positions
  • Enhanced photo making features
  • “Radical changes” to the user interface
  • Enhancements in the area of post processing and 3D vision

If the required funding level is exceeded, then the team will look into other aspects of Viewer development, such has obtaining a KDU licence, funding other developers, etc.

For those helping to fund the project, a special area of the Viewer’s website will be set up, providing preview access to builds and features, and where funders can vote on proposed new features and enhancements, etc. Rewards for funders will be based on their level of funding.

The project’s Crowdfunder page is now open. Using Crowdfunder is pretty much a win/win situation for all involved: if the target is reached, the project will go ahead; if the funding target isn’t reached, then money promised to the project will be refunded. So there’s no reason not to get involved!