On Tuesday, March 24th, the Lab promoted the Avatar Hover Height release candidate viewer to the de facto release viewer, meaning it is now available to everyone receiving official viewer updates / downloading the official viewer directly.
As I reported back towards the start of the year, prior to the arrival of server-side appearance (SSA), many TPVs included a capability commonly referred to as “z-axis height adjustment”. Simply put, this allowed the height of an avatar to be adjusted up or down, relative to the ground or to an object they were sitting on, which allowed for a wide range of adjustments to be made (such as when sitting or kneeling on the ground, to prevent the appearance of hovering over it or to more finely tune the avatar’s pose on the ground, or to re-adjust an avatar’s height relative to the ground when using things like dancing posballs, etc, and so on).
However, with the introduction of SSA, the viewer / server messaging that made this kind of adjustment possible was removed. While the Lab attempted to offer an alternative capability – the Hover slider, available when editing your avatar’s appearance, its effectiveness has always been limited. You can’t for example, use it to adjust your avatar’s height when seated, for example, to prevent any appearance of sitting “inside” a chair or hovering above it; nor can you adjust your position above the ground when using poseballs, etc.
Avatar Hover Height, developed as a direct request of a proposal put to the Lab by members of the Firestorm team, addresses these shortfalls.
It allows “on-the-fly” adjustments to be made to your avatar’s height with the minimum of fuss and without having to use the Edit Appearance Hover slider.
It does this by providing a new right-click avatar context menu option called, oddly enough, Avatar Hover Height. Right clicking on this displays a slider. Moving the slider to the right increases your graphical height above the ground, and to the left decreases it (you can also input values via the slider for additional control).
Overall, the slider allows for adjustments of +/- 2 metres relative to the default graphical position of your avatar. Note that this is a graphical (/visual) change – the option does not make any associated change the avatar’s height in terms of platform physics.
Avatar Hover Height has been extensively tested while the viewer was both in a project status and was available as a release candidate viewer, and no significant issues or breakages were noted in that time.
Note that this capability does not replace the Edit appearance Hover option – than can still be accessed and used in circumstances where it might be more appropriate to use; rather it present a further, more convenient, means of adjusting your avatar’s height.
Inara Pey: Living in a Modemworld 
Hurrah!
LikeLike
Alas, the adopted protocol makes this feature incompatible with viewers not supporting AHH (i.e. in those viewers, you’ll not even see others’ avatar with the proper Z offset, while the pre-SSB protocol allowed any viewer to render avatars using a Z offset at the proper height).
This means AHH use will be pretty pointless till a significant amount of users have updated to a viewer supporting it… It could take months for this to happen, if it ever happens…
Also, the adopted protocol does not solve the rest of the issue (which was an avatar bounding box issue, involving not only Z but also X and Y dimensions) as described in the SUN-38 JIRA issue.
The full story is here: http://sldev.free.fr/forum/viewtopic.php?f=5&t=1494
LikeLike
Yes, the code requires adoption. UKanDo already has it, as does RLV, and Firestorm will have it in their next release scheduled (hopefully) for April. Should this happen, “months” will more likely be “weeks” for the majority of TPV users to be able to make use of the feature 😉 . As to the bounding box issues, the Lab always made it clear this was a graphical solution, rather than anything more extensive, and it seems to fit the bill for the use cases supplied to them.
LikeLike
The Cool VL Viewer also got AHH support since 2015-01-31 and AHH-compatible @adjustheight RLV command as well since 2015-02-07…
But the time it will take for *everyone* (and not just the small crowd of SL power users) to update their viewer to an AHH compatible version will be (at the very best) counted in months… In the mean time, if you are using AHH to set your avatar’s Z offset, people without an AHH-compatible viewer will not see your avatar properly leveled… So, for now, I myself keep using the (much slower and mod-ok-only-shapes) “Hover” visual parameter to adjust the Z-offset (it’s a choice the Cool VL Viewer offers you) because it’s the only “universally” compatible solution…
Also, the bounding box issue got NOTHING to do with graphical issues, and neither did the Z offset in the first place (please, do read fully the SUN-38 issue on the JIRA as well as the thread on my forum I posted the link for in my last message): pre-SSB sims used to set the avatar bounding box based on the dimensions sent by the viewer (those were clamped however, so the leeway was not enormous) and feed the Physics engine with those dimensions, the latter taking them into account both for collisions (thus, by adjusting your avatar’s Y offset, you could make it bump into obstacles accordingly to its actual shoulders width) and position (the Z offset could therefore be used to adjust the avatar center and thus its position above the floor/ground).
Instead, AHH has indeed been implemented as a cosmetic/graphical tweak that applies only viewer-side and, as such, can’t account for the rest of the issues described in the SUN-38 use cases which AHH was supposed to address.
LikeLike
“The Cool VL Viewer also got AHH support since 2015-01-31”
That’s great! one more group of users already served.
“But the time it will take for *everyone* (and not just the small crowd of SL power users) to update their viewer to an AHH compatible version will be (at the very best) counted in months… ”
When people choose to update their viewer is obviously up to them; but the fact remains, Firestorm will likely have AHH support in weeks, which means it will be available for the majority of users to adopt, and Firestorm’s stats tend to support the fact that the larger share of their users update when a new version is released.
Sure, those not updating (whatever viewer they use) won’t see things the same as others in their own world view, as you say. They’ll continue to so see things as they’ve been seeing them pre-AHH; it’s not like anything is actually being broken in their view as a result of AHH, so again the point as who who can / can’t see AHH-specific changes would seem to be somewhat mooted. More so when one considers that there are people out their running viewers with assorted features and capabilities (including some running without SSA, and so only seeing grey avatars around them) which can affect their view of the world when compared to others – but it hardly spoils their enjoyment of the platform, and doesn’t cause them any particular upset.
LikeLike
“When people choose to update their viewer is obviously up to them”
Precisely… The whole point I’m making is that if AHH had been properly implemented, we won’t even have to care about when or whether everyone will update (or not) their viewer… The solution I proposed almost 2 years ago to solve the Z offset issue (together with the avatar bounding box) would have been 100% compatible with even the oldest SL viewer… LL simply screwed it up, sorry…
“They’ll continue to so see things as they’ve been seeing them pre-AHH”
Not quite… For example, the Cool VL Viewer and Marine’s RLV have been using the avatar shape Hover visual parameter to emulate the Z offset feature (and support the @adjustheight Restrained Love command); the avatar shape Hover also renders properly on any SSB-viewer. You now can use AHH instead, but then you loose the retro-compatibility with non-AHH viewers (including SSB-enabled ones)…
LikeLike
With respect, you seem to me to be making the update time to be a bigger issue than it will perhaps prove to be. That’s my point pure and simple, so we’ll have to agree to differ on that score. As to what the Lab coulda / shoulda done – the point is really moot, as they didn’t. As to whether or not the AHH solution is sufficient to meet the majority of people’s needs, time alone will tell on that.
LikeLike