Firestorm 5.0.7 the RLVa debate continues

•June 23, 2017 • Leave a Comment

As many of the readers of this blog will already know, Firestorm issued an updated viewer on June 21st, FS 5.0.7. Now I won’t attempt a review, I leave such things to others such as Inara Pey: https://modemworld.me/2017/06/21/firestorm-5-0-7-tight-and-tidy/. What I WILL comment on is the outstanding RLVa version reporting issue. https://jira.phoenixviewer.com/browse/FIRE-20597 is seeing a debate, nay an argument, between one of SL’s foremost RLV scripters, Chorazin Allen, and the creator of RLVa Kitty Barnett. To be perfectly honest, Kitty’s attitude astonished me. I knew there was growing disinterest in RLV/RLVa within Firestorm ranks, that has been going on for some time.
What worries me is the suggestion (granted at this stage purely hypothetical and not from Kitty) that Firestorm might abandon RLV/RLVa altogether. That this should even be considered would, in my view be a total betrayal of the roots of Firestorm, via Phoenix and (controversially) Emerald. As Firestorm and Linden Lab appear to be moving ever closer to full co-operation, the FS volunteers are in danger of forgetting their origins and misunderstanding their user-base. In that they are coming to resemble Linden Lab who have made a science of failing to understand their user-base.
Now for me the minor version-reporting glitch is an irritation not a problem, but for folk like Chorazin it is a major bug-bear. It needs to be fixed but from Kitty’s comment that is not going to happen any time soon.
In recent conversation with Marine Kelley (with whom I have always been on good terms) I began to appreciate the yawning chasm that has grown between the inventor of the RLV and FS. I find it sad and not at all comforting to hear some of the comments on this JIRA.

RLV. A clarification

•May 29, 2017 • Leave a Comment

Today, in SL Marine Kelley clarified the turn of events that led to her RLV cache-sharing with the SecondLife viewer, or rather why it had not, until now been modified so as not to do that.
I hope Marine will be content that I quote her in these words:
“It’s not that I did not consider it a problem, it is that I wasn’t even aware of it. I never ever use any other viewer than the RLV, so I never noticed that cache sharing problem. I wasn’t aware that it bothered LL either, but I did get an email from Oz about it, which made me look into it more deeply. Had I known it was such an issue, I would have fixed that years ago.”

Those are the words of a responsible and reactive SecondLife builder and creator and from them it is crystal clear that there was never any intention of flaunting the rules firmly laid down in the Third Party Viewer policy; that nothing should affect the shared experience of users in SecondLife.

In the end we now have an RLV that does what it should and frankly does it well. Marine has been a major part of SL for over ten years and I for one hope she will be so for many years to come.

RLV 2.9.21.3 A Marked Improvement

•May 28, 2017 • 1 Comment

After the unwelcome discovery that the previously thought innocuous cache-sharing between the default Linden SLV and RLV could actually cause significant texture-corruption due to the different graphics decoders that the two viewers use, I am glad to tell you all that the latest RLV has none of those foibles. Marine was kind enough to give me a “heads up” on this yesterday.
At first start-up after installation the settings file will direct the viewer to use the last cache location that SLV used, so before the first log in it is important to go to preferences on the viewer start-up screen and either set the default location or as I do, set your own custom location.

Once that is done and you restart the viewer all proceeds as normal, and while I confess to not liking the Linden viewer UI, it works well. I did notice that in graphics>advanced settings that GPU texture memory can be set, but if the maximum of 2048MB is set with my 6GB NVidia GTX980Ti I got texture thrashing, something which does NOT happen with Firestorm on the same setting.
So all in all the newest RLV is a good piece of code, but I’ll say it again – it ain’t as good as FS! Note: that is a purely PERSONAL opinion and should be considered as such.

Cache Confusion…and corruption…a problem revealed.

•May 22, 2017 • 1 Comment

Following extensive testing in conjunction with Whirly Fizzle, the FS Support JIRA queen, it now seems that not only does Marine Kelley’s RLV share the cache location with the Default Linden SLV, it also shares its settings files.

This wasn’t a problem when RLV was created back in 2007, but it is a serious issue now that SLV uses the Kakadu KDU decoder and RLV uses the Open JPG decoder. As I was informed by Whirly such cache sharing by two very different decoders can result in texture corruption. I can confirm that it does indeed do that. I am not sure that sharing settings files is AS serious a shortcoming but I intend to contact Marine inworld as soon as possible about the matter.

I suspect that this will be of concern to a good many people.

ETA at 19:45hr BST: I have sent a notecard to Marine in SL about this. I await her response.
FETA at 00:30hr BST May 23rd: Marine is aware of the issue and fully accepts that the cache and settings folders are shared, she does not consider this a problem apparently.

PS FETA is Further Edit To Add, not cheese.

EFETA at 20:00hr BST May 23rd: I heard via Whirly that Oz Linden will be contacting Marine about this, it seems that LL are not happy that this might affect anyone using both RLV and SLV. (What HAVE I started?)

Another Fine Mesh again

•May 19, 2017 • 1 Comment

Well my Human Alt finally took the plunge today and got a mesh body. I wasn’t convinced it was that important but having had the courage to try a demo I was soon convinced. It’s nice to have real knees on my avatar again, something, along with the hands and feet, that the default system shapes never got right.

I plumped for the Maitreya Lara having seen many impressive examples in my day-to-day SL. My partner and such SLuminaries as Strawberry Singh showed what could, and could not be done so I was mentally prepared. The bodies are still not cheap but the price seems to be coming down slowly as take-up increases. I know male bodies are certainly far better than their system counterparts and the average SL female certainly looks better in mesh, provided the skin and shape are sensible and I don’t doubt that male users appreciate the finer parts of the mesh female body now (or at least they will until they go blind!). I shall look more into what can and cannot be done in due course and I look forward in trepidation to my first sailing sim crossing where my SL mesh body will end up at the bottom of Blake Sea. The joys of SLailing!

Cache Confusion

•May 15, 2017 • 4 Comments

I have been doing some testing recently which has required me to briefly use both the “default” SL viewer and Marine Kelley’s RLV. I have discovered something which may either be me committing some operation error or a really quite irritating glitch in their operation.
If I use the default location for the viewer cache on SLV (my name for the default viewer) and run a session I have no issues. If I then load up and run the RLV I notice that it attempts to use the same cache location as the default viewer. Since the SLV uses the KDU graphic decoder and RLV uses the open-source J2C OpenJPG decoder this is not a good thing and leads to texture corruption (thanks to Whirly Fizzle for pointing this out to me). If I log in to RLV and change the cache location to the specific location I have set up for it, the next time I run the SLV it uses the RLV cache! Changing the cache location from the preferences on the start up page does not “take” so I have to log in to change this file destination, which is not a good thing.

Now maybe I am doing something wrong but for the Secondlife of me I do not know what! Can anyone out there offer an explanation for this? Oh and it HAS to be these two viewers for the purposes of my tests.

The Numbers Add Up

•May 9, 2017 • 1 Comment

At some point on or around April 12th this year all feeds that relied on concurrent user data (i.e. number online) from Linden Lab went null. There was no explanation from The Lab (nothing particularly unusual in that) and no response to a trouble ticket I raised on the subject. In fact that ticket has never been replied to. Yesterday the feed was re-established and all sites that used that data returned to normal, including the number online “ticker” on the Firestorm Viewer start-up page.

I have a feeling we will never know the true cause of the outage nor what was done to restore it. We can just chalk it up as another of the mysterious occurrences with data from Linden Lab.

It doesn’t do anything to increase my trust in LL.