This means that the Firestorm team are juggling with two potentially conflicting requirements (trying to fix merge issues and bugs arising there from, and trying to implement SSB), with the expectation that at some point LL will start pushing for the latter to be completed so that SSB can be deployed to the grid. As a result, they are sounding a note of caution concerning any upcoming release, while also acknowledging that precise or anticipated dates for the deployment of SSB aren’t clear. Speaking on this, Jessica said:
I can give you my word that we’re going to do everything in our power to try to stabilise Firestorm and get bugs and kinks out before we release it, as much as we humanly can. But like I say, there is a timeline on this, and we don’t quite know when that is going to be. Linden Lab gave us a two-month warning, [but] it looks like that’s going to be a little bit longer now … but the bottom line is [that] it’s going to go out, and probably we’re going to have to release Firestorm before we’re satisfied with it.
CHUI – Communications Hub User Interface
The second major viewer-impacting project coming out of Linden Lab (and the one most likely to reach formal merger with LL’s own development and beta viewers first), is the new Communications Hub User Interface (CHUI), a redesign of the entire Communications floater, together with the implementation of a new Chat History floater, both of which have extensive code refactoring and changes underpinning them.
CHUI will also have a considerable impact for TPVs – potentially moreso than SSB. How much an impact can be measured by the fact I’ve been informed that there are some 274 changesets involved in SSB, and almost 1,000 in the case of CHUI). For Firestorm, the changes are potentially more complex in terms of integration, because the viewer has already provides functionality which is both similar / equal to the front-end changes seen in CHUI, and which are extremely popular with users. Thus, the team not only have to integrate the CHUI code, they have to evaluate the changes both in terms of their impact on the viewer as a whole (the potential to introduce bugs, etc.), and how they might positively enhance or adversely impact the communications capabilities already within Firestorm.
Materials Processing and Viewer Graphics Defaults
Firestorm will obviously be implementing support for materials processing. when this will be is unclear (the full viewer code has yet to be released by the Lab for integration into TPVs, and as there are currently issues still to be resolved with the (private) materials viewer code, the recommendation is that TPVs do not merge the code at present.
However, various elements of the work connected to materials and graphics defaults are being implemented:
- The Performance slider on the Preferences Graphics tab will include the new intermediary settings between Low and Medium, Medium and High, and High and Ultra (increasing the number of settings from 4 to 7). This is in line with LL’s ongoing work in updating the GPU tables for the viewer and making the graphics settings more amenable to the wide range of graphics cards in use
- The Lighting and Shadows check box on the Preferences Graphics tab is renamed Advanced Lighting Model in line with the upcoming materials processing changes.
The latter option name change is an attempt to overcome the confusion felt by some users that to run the viewer in deferred mode, shadow options must also be enabled from the Shadows drop-down (which can lead to a substantial reduction in frame rates / performance).
There is some disagreement between the Firestorm team and LL as to default settings for the viewer’s graphics. Given the preponderance of graphics cards able to run in deferred mode (i.e. with Advanced Lighting Model active), and the fact that materials processing requires the viewer to run in deferred mode in order for effects to be seen, LL is pushing for deferred mode to be active by default for GPUs which are detected as being able to run in deferred.
However, the Firestorm team are looking at graphics more conservatively (a card may well be able to run SL in deferred mode, but it may not necessarily run SL very well when in deferred mode), so by default, the Advanced Lighting Model option within Firestorm is liable to remain off as a default in all but the Ultra setting, and will not default any graphics card to a setting above High.
Upcoming Features
Despite the heaviness of some of the news regarding Firestorm and code merges, members of the team have been hard at work in enhancing and developing Firestorm’s own capabilities. Not all of these capabilities may be available within the very next release, but they are on the cards.
Settings Back-up
It is frequently recommended that a new installation of a viewer is completed as a “clean install” – that is, all user settings from an existing installation are removed prior to installing a new version of a viewer. It is also possible that user settings can become corrupted following a viewer crash. While it is possible to manually “back-up” your user settings, doing so manually isn’t really that elegant.
With Firestorm 4.4.0, it will be possible to set a back-up location for all your user settings and automatically back them up / restore them from that location.
This option will even allow settings to be saved to a USB stick, so that they might be more easily used across several computers.
Import / Export
A new content import / export feature will be coming to Firestorm for prim-based items you create. This is being specifically written for the viewer, although it is hoped that it may be adopted as a “standard” by other TPVs, and it is being aimed towards OpenSim support as well as enabling import / export of content (with full respect to permissions to avoid, as far as possible, any risk of abuse or “illegal” export of content) with SL. This feature will not initially support avatar shape import / export, but may do so in a future release (although there may be some licensing issues to overcome).
Quick Preferences
The Quick Preference floater is perhaps one of the most popular options within Firestorm, offering as it does rapid access to a range of user-configurable settings (draw distance, particles, object LOD, windlight settings, etc.).
In response to user requests for Quick Preferences to support even more options, the floater is being revised so that in upcoming releases, it will be somewhat customisable and allow anything which is a debug setting within the viewer to be added to the floater. The settings applied to the Quick Preferences panel will also be backed-up as a part of the user setting back-up capability mentioned above.
Legacy Search Enhancements
The last release of Firestorm saw the return of basic legacy (“v1”) search capability. This sees the legacy and “v3” style searches folded into the same floater, with legacy search options having their own tabbed space alongside that of the web-based search.
The caveat here is that the legacy search will only remain available in the SL version of Firestorm so long as LL do not fully disable the server-side support for the functionality. Once this does finally happen, then the legacy search options will be removed from the SL (Havok-enabled) version of Firestorm, but will be maintained in the Opensim (non-Havok) version.
Other Options
Again, these may not all be available in the very next release or Firestorm, but are currently in development.
Hide Chiclets: Firestorm will be incorporating an option to disable / hide the majority of chiclets for those who do not like them, and display notifications in a v1-style (lower left of screen / in chat). The exceptions to this will be inventory offers and group notices, as there is no means by which these can be reverted to a v1 functionality with any ease.
Partially related to this is the hope that at some point the issue of script dialogue boxes cascading off the screen to the right when multiple dialogues are open will also be fixed – but this is very much on the “still to do” list at present.
New floater panels: Upcoming releases will also see the introduction of new stand-alone floater panels for a range of options, including: teleport history, landmarks, place details, block / mute list, etc. Those using the v1-style skin will have the option of removing the volume controls from the top right of the menu bar (as the same controls are displayed v1-style in the bottom right of the viewer UI).
New windlight options: Vincent Nacon has contributed his cloud normal maps (i.e. overlaying the sky with a preset texture to give greater definition) and a host of windlight settings he’s designed to take advantage of this.
New UI skin theme: There will be a new theme – ectoplasma – for the Ansastorm UI skin. At some point in the future, it is planned to have UI skins set so they can be downloaded by the user (as has been the case with Phoenix in the past), rather than all of them being installed by default.
Media treaming fix: The next release of Firestorm should include a fix whereby it is possible to have the media stream being played at one region to continuing playing when you have teleported to another region.
Other Bits – from the Q&A Session
64-bit Viewer Options
There are long-term plans for 64-bit versions of Firestorm for Linux and Mac OSx, while Windows is “a whole other story,” according to Jessica. However, both are such long-term plans, there was nothing major to say in this area in terms of official releases.
Running the SL and OpenSim versions of Firestorm
Is it possible to run both versions of Firestorm (SL / Havok libraries-enabled and OpenSim / non-Havok libraries-enabled) on the same computer? Yes. Install one version, change the desktop icon and start menu option names, then install the second version into a unique folder.
Will SSB Require Two Versions of the Viewer – One for SL, One for OpenSim
the short answer to this is “no”; if the viewer detects the region it is connected to is using SSB, then it will use the SSB service. If the region is using the “old” baking system, then the viewer will use that service. Within SL, there will be some caveats around this, but it means that with OpenSim, little or no difference should be noted. It’s worth noting that the avatar baking code will still be used in SL when editing an avatars appearance; it is only when editing is completed that the update is sent to the new baking service.
Group Notice Attachment Failures
There is a viewer-wide issue of attachments to Group notices going “stale” (e.g. they cannot be opened). Tis is a widespread issue, resulting from the server “dropping” the attachment after around an hour. A workaround is to open the attachment through Contacts->Groups.
Rez to Last Position
A popular feature with buildiers, which allows an object taken back to inventory in error to be re-rezzed at its last known co-ordinates, this was initially developed by LL but never really exposed for general use until TPVs started using it. However, there have always been issues with the capability (objects could end up being rezzed off-sim in error, leading to content loss, and the feature could be exploited by griefers, for example). The capability was broken in 2012 as part of a server-side update (although can still be used where a user has rez rights at 0,0,0), and is reported as “even more broken” as a result of SSB changes to the server code. Ergo, the capability will be going away.
V1-style Elements
The Firestorm team have worked as hard as they can to get as much v1-style functionality into the viewer as possible, and are trying enable even more. However, there are changes which cannot be reasonably undertaken, or which the v3 code simply won’t allow. An example of the latter is some of the chiclet notifications, as explained earlier in this report. In the case of the former, the menus are a good example. While the Firestorm team could implement v1-style menus (either entirely or as an alternative when using the v1-style UI layout), they would then have to face two core issues:
- They would have to maintain code which is entirely different to the LL code, so that every code update coming out of LL would have to be checked for a potential impact on the menus as presented and then perform additional code updates to keep things working / in sync
- They would add considerably to their support issues – support volunteers would need to learn two entirely different menu systems.
As such, every request to change the UI into something more v1-like has to be carefully examined to determine whether it is technically feasible and / or functionally desirable from both a development and a support perspective. Regrettably, some will fail to pass either / both of these criteria and as a result, will not be implemented.
Related Links
- Avatar Baking: “and the clock has started”
- Materials processing: the what, why and where
- Materials processing: more sneak peeks
Inara Pey: Living in a Modemworld 
Starting to sound like the FS team is working on things they said were impossible to do, funny how things turn out like that, but all in all, glad to see that they realized their (for lack of a better word) bluff wasn’t working and they’re now going to start working on fiddling with things to bring about V1 again.
If nothing else, they could collaborate or get some help from the Singularity team, who’s brought in almost every main V3 feature into the V1 viewer with no stability issues at all. I dunno if it works in reverse, but hey, these “miracles” are happening across the board and SL is benefiting greatly. I wouldn’t even want to imagine how small SL would be without TPV’s~
LikeLike
No, they’ve not changed their tune and no, they’ll not be “bringing about v1 again”.
The Firstorm team has always maintained they’d strive for as much v-1 like functionality as possible. However, as noted here and during the meeting, as as endlessly mentioned in past blog posts, some things are simply not possible either because the v3 code won’t support the changes being demanded, or the changes are simply too much of an overhead technically to implement and then support or because the changes represent support issues for the FS support volunteers – or because of a mixture of all three.
This has always been their stance, and remains their stance.
LikeLike
They have changed their tune a few times, you of all people should know, but I’m not terribly worried about that. They’ve worked quite hard to bring v1 back, so it doesn’t make sense to deny it when you’re writing about how they are current planning on or currently in the works of doing it.
LikeLike
*YAWN* – You’re beginning to sound like a broken record. So thank you, please drive through.
LikeLike
This is actually a related topic, but wholly different from the last few discussions, aside from that – Why don’t you mind your own business?
On a personal side note; wouldn’t this someone count as public interfering, and the attempted start of internet drama? Your top 2 dislikes, right?
Non-deadpan passive-aggressive comments are on my dislikes, so good day to you.
LikeLike
You still sound like a broken record. Other than repeat yet again how much you dislike Firestorm, do you have something to say?
LikeLike
Now you’re sounding like a broken record. And I don’t dislike Firestorm, if you are actually following what I’ve said in recent weeks, then you’d know that.
Do some research before posting, or you could simply not post at all and both our time would not be wasted.
LikeLike
All these changes and updates are good and all but I see nothing in regards to the voice component being fixed with the new MAC OS X Mountain Lion. We still have absolutely no voice abilities at all with this most recent release. When will this be addressed and fixed?
LikeLike
Did you miss the part where Linden Labs is going to change the basic architecture of the way things are going to be done?
LikeLike
Open the gates and set loose the Wackadoodles! “Conspiracy”, “The end of SL”, “Everyone will leave / no one will come”, “I know a better way”.
sigh – – – – – . . .
LikeLike
Aren’t they already here? 🙂
LikeLike
When do they actually stop handholding their users and start arriving in 2013?
LikeLike
Some of us actually practice good software engineering practices and don’t suck up every changeset that shows up on the radar from every source. Some of us also care about more than just the bleeding edge.
LikeLike
I can only say that, on a platform where the operator is routinely (and rightly, in many cases) at the receiving end of calls for better communications and frustration that they don’t reach out to their user community consistently through all the channels available to them, the Firestorm team’s attempts to actually do so is actually to be applauded, particularly given the sheer weight of numbers users their viewer(s).
LikeLike
There’s a pattern I see with the LL Viewer which sits uneasily with the Open Source idea.
How many of the bugfixes which TPV developers implement get into the Linden code? The successful Open Source projects don’t use every third-party bugfix, but at least they talk to the people submitting them. The Lindens often seem unduly reticent about bugs, and the current JIRA system is no help.
LikeLike
I think this rings a few bells that resemble what Oracle did with OpenOffice. There are, of course, differences here, but some similarities regarding the mindset seem to be present…
LikeLike
Actually, many TPV bugfixes *do* get into the LL viewer. In particular, a lot of the crash fixes in Firestorm got into the LL viewer pretty quickly. The main thing is that the fix needs to be submitted to LL by the author if it’s more than a very few lines; LL does that to avoid any questions about ownership of their code.
I do agree that the current JIRA is a serious mistake on LL’s part.
LikeLike
If you don’t like it there’s plenty of other viewers you can be using.
LikeLike
Angelita, Niran is very aware of the number of viewers available – he actually develops his own viewer, also on the TPV directoy – Niran’s Viewer…
LikeLike
Firestorm’s communications tools/floaters are probably the number one reason I use Firestorm so frequently. Having said that, I also have come to really like CHUI. This is a project out of LL that’s gone really well. I can’t help but feel that LL must have looked at how TPVs handled communications, decided that there were great ideas there that could be polished up, and did exactly that.
Materials… awesome. 🙂 I got my greedy hands on a binary of the (currently crashtastic) code in the materials repo, and created some normal maps for some of my meshes. Mmmm… that was a nice taste of things to come.
Settings backup… nice! I do clean installs of a variety of viewers frequently, and make sure to manually clear out any cruft left behind. So this will be handy, and hopefully adopted on a wide scale. I am curious how well this will hold up if settings are moved or removed, as sometimes happens. One little thing I find irksome is that the last thing FS needs is something else in it’s preference floater. But other than dedicating a floater and menu item to it, I guess I’m not sure where else they’d put it.
Import/export is something people will love to have again. I’m wondering if their implementation will support content within objects. Support for Kitely’s export permission would be nice to have as well.
LikeLike
Ack. Ignore the link in my comment… it’s wrong. I meant instead the export permission mentioned on Kitely’s blog here.
LikeLike
From the description, it looks like the export flag will be a purely server-side thing, but I will be in contact with Kitely just in case. We try to support as many OpenSim-specific features as possible.
The problem with this sits with closed-source grids who keep their incompatible changes proprietary and secret, essentially biting the hand that feeds them. This has not, however, been the case with Kitely.
LikeLike
You may definitely be 100% correct. I’m not actually a user at Kitely, and I haven’t paid super close attention to their activities.
My reading of the blog post was that the export flag would be marketplace only in that that would be the only place merchants would have the ability to set an item as exportable. Since viewers don’t currently know about and can’t respect an export permission, that’s how I interpreted things. That they implemented it as much as they could, but without viewer developers on board, it only goes so far. But as you say, Kitely would know about that much better than I do.
There’s actually been fairly wide interest among the OpenSimulator community for the last few years in an export permission. Because this feature would require strong TPV participation, I presume that’s why it’s not gone anywhere. With it’s popularity, the participation of Firestorm developers would be a valuable step in making it a reality. Not that you guys don’t already have enough to do. 😉
LikeLike
Hi Cinder,
Lacking viewer-side support for setting/viewing an Export permission, we plan on implementing this flag only for items sold via the upcoming Kitely Market, where merchants will be able to set/view their items’ permissions.
If there were viewer-side support for this permission we would gladly use it for all items on the Kitely grid.
LikeLike
I agree on FS’s presentation with communications. The approach they use is not unique – other TPVs offer IM doking / undocking, vertical tabs, etc., but I still find FS’s apprach the most “comfortable”. I think it is fair to say that CHUI is more than a nod towards TPVs (and users) and an attempt by LL to move things in a direction that should enhance not only the usability of their viewer, but also (at least in terms of those who do routinely use TPVs, but may need to swap over to an “official” viewer at times) reasonably familiar, to be a very positive move.
Settings back-up & Preferences: perhaps this will be one of the options which people can add to their Quick Prefs for ease of access? No idea on the export / import functionality. Maybe someone from Firestorm can comment :).
Materials: I’ve had the opportunity to play with the recent private dev viewers being used to test this, and am really looking forward to seeing not only the deployment of the capability, but how it it will enhance the in-world look to SL over time – and how it will (hopefully) be enhanced itself.
LikeLike
I think I’ll be sticking with Singularity…..FS crashes like crazy on my machine. I love Niran’s viewer, but would need a much better computer in order to run it in such a way as to do it justice. In fact, Nirans was the first viewer I could ever get to work on my computer, as the original LL viewer simply wouldn’t run. Singularity seems to be the happy medium for me at the present moment.
LikeLike
That’s the beauty of having so much choice, the ability to mull over viewers and use the one which best meets our needs and hardware, be it the official viewer, FS, Singu, Cool VW, Radegast, Lumiya, etc. We’re really quite spoiled for choice!
LikeLike
The one thing that I think we all can agree on Linden Labs doing right was allowing 3d party viewers.
LikeLike
Firestorm only entered my computer for open sim, same with singularity.
No doubt i prefer Firestorm over sing, just for the fact that it allows a v3 xui (Yes, I still think if one lesson should be taken is Niran’s xui, but frirestorm is enough modulable to make the xui almost as logical and good as niran’s one!).
The only thing i was missing is the export/import and that will be amazing!
To firestorm team i can only say,. make your viewer the best for open sims, you will not regret it.
Check and think about allowing a xui choice like Niran’s.
If possible make a graphic sett that can be as good as Niran’s (It seems easy,. according to Gainz).
LikeLike
Import and Export is liable to provoke some very vocal merchants. There are already things which Firestorm can export which it cannot import. William Tare Fox and similar expressions of startled bewilderment.
I would like to see a rigged mesh come with a full-permissions shape, which I could export, and pass through an external utility, to gave me the correct shape with my unique head and face, which I can then import and use.
(I suppose that could be done within the viewer, but I prefer keeping that sort of tool safely outside.)
I now wait for a merchant drama-queen to bemoan the encouragement of content theft. But what, I ask, when I can get a word in, is the valuable property to me? The rigged-mesh, or the shape with a face that looks nothing like the identity I use?
The Mesh Deformer might short circuit this, but I have experience of the weaknesses of such tools.
LikeLike
There’s also another issue with importing and exporting stuff, especially from one virtual world platform to the other – and this is not only about the whole intellectual property issue that will certainly upset some extremely vocal content creators, but also because several things (sculpts, mesh, scripts) are implemented in a significantly different way between platforms – that way, chances of a successful import/export are slim.
LikeLike
Of course, it has to be pointed out that this import/export facility is (a) intended only for prim-based objects, (b) intended (if I’m not mistaken) only for content someone has created (and not content from others), (c) mesh and sculpt maps won’t really need to be imported/exported, because a creator will already have them stored on their hard discs, independently of their SL (or other virtual world) inventory. Also, it would be useful to point out that mesh is implemented differently across virtual worlds – while sculpts are pretty much universal.
LikeLike
We have been in SL for a longtime, used all browsers available, and have settled on Firestorm, as the best. New server software, and development problems with other browsers is not my concern. The concern is, with the viewers perception of the land I have built. I pay a lot of money to do what I do. It’s the Browsers Dev teams Mission to bring it to the viewing experience, in a consistant manner. What I don’t need now, is to be told it’s going to be a rough couple of months. Please explain why the Communication between Lindens and the Third Party Browsers can’t solve this?
LikeLike
I’m not sure what you mean by the “viewer’s perception of the land I have built”. All viewers – third-party or LL’s should effectively treat land the same way in terms of general management, the tools at your disposal for managing that land (recognising the parcel size and boundaries, tools for access control and terraforming, and so on).
Communications between the Lab and third-party viewer developers are, for the most part, relatively open. There is a mailing list where issues can be raised and responded to openly by both LL and third-party developers, and there is also a twice-weekly open-source development meeting held in-world between LL and developers and a viewer-focused meeting held every other week as well to help ensure a good level of information exchange and to assist in keeping TPVs informed (as much as possible) as to what is going on on LL’s side of things with regards to the development and enhancement of SL (there are also meeting sin which the server side of things are discussed, and which some TPV developers also attend).
However, even with these channels of communication and ongoing echanges between LL and third-party developers, and while there is perhaps greater sensitivity from LL towards TPVs in complex matter such as Server-side Baking, there can still be conflicts when it comes to the actual deployment of new functionality and capabilities to SL which impact the viewer.
This means that – and while it has not happened yet – there is a risk that the Lab might, despite their sensitivity to date, end up drawing a line in the sand and saying, “We will be rolling-out the new Server-side Baking on this date” – simply because they, and the majority of TPVs are reasonably confident they can support the service.
Because of this, the Firestorm team are sounding a note of caution, simply because they are undertaking so much and have a viewer which does offer considerably more capabilities than perhaps other viewers (which is itself an added overhead in terms of maintaining and enhancing Firestorm), that were LL to announce they were satisfied with their own progress on SSB, they are going to deploy it in (say) “3 weeks time”, the Firestorm team would likely have to freeze all other work on the viewer (bug fixes, etc.), and simply focus on making sure they can offer users a version of the viewer which supports SSB even if it is “broken” in terms of stability, etc.) – simply because if they don’t, every Firestorm user’s in-world experience will be broken.
This is hopefully a somewhat rare situation in this regard, as SSB is a hugely significant change to the way SL works, and it has come at a time when, unfortunately, several major viewer projects are all converging towards release (which also adds to the pressure). But in sounding a note of caution, the Firestorm team are simply being transparent and honet with their users s to their current state-of-play. Hopefully, the resasons for being so cautious will remain a “worst case scenario”, and not actually come to pass.
LikeLike
I am curious as to the status of the fix to the now well known bug of sound cutoff for media streams, requiring a relog to fix the issue. I was told Phoenix/Firestorm were aware of this bug and would fix it in the next release. Does this mean this rather annoying problem will still be around while you guys fix other problems with the next release?
LikeLike
There is a media fix which will be in an upcoming release of Firestorm. I gather it is to do with the issue of streams continuing to play once you’ve left a region. However, it may address other issues as well.
The best place to get a direct answer to your question is through the Firestorm support groups, as I and this blog are not not directly involved in Firestorm development nor affiliated with the Firestorm viewer in any way.
Sorry I can’t offer a more detailed response than this.
LikeLike
I understand. I was curious with the new host of problems the code integration was bringing if that meant already known bugs would have a delay in being fixed.
LikeLike
I think that will come down to a) whether or not the team is forced into a position of having to focus purely on SSB and get a release out (if a deployment date for SSB suddenly pops up), and b) The status of any given fix should that happen. So if the fix is ready and tested, it could well go in with the SSB release, if it is still being worked upon or yet to pass QA testing, it might be put to one side while the effort goes into SSB.
LikeLike
Bottom Line: I don’t want to know why a viewer does or does not work. I just want to know which one will work the best when the “Fit hits the shan”.
Suggestions appreciated. Thank you.
LikeLike
That’s a big question in terms of Server-side Baking.
Clearly, the Firestorm team have a lot on their collective plate, and it may well be that, as Jessica warns, the next release may well have significant issues.
However, it is fair to say (for the moment) that as there is no release date for the new SSB service, and LL have a fair few things to sort out for themselves, viewer-wise and with the project, it may well be that it is going to be a little while yet before SSB emerges – and that might be long enough for the Firestorm team to get a somewhat more robust build of the viewer ready for the SSB deployment than might otherwise be the case.
That said, all TPVs are pretty much in the same boat to some degree or another. Currently, only two viewers which are available and include SSB support are the official SSB project viewer and an experimental version of the v1-style Cool VL Viewer, although obviously the majority of TPVs will be working on implementing the required code. And the fact that the Server-side baking code has yet to reach the main ciewer code repositories at LL is also a sign that we have a little way to go yet before SSB is rolled-out.
As such, I’d suggest that right now there is no reason for undue worry. Keep an eye on this blog and other like it which regularly carry news on LL’s various projects and on the development / release of third-party viewers as well as on the official SL and Firestorm blogs, and see what news is forthcoming nearer the time.
LikeLike
This whole thing is sick. I can’t even run the labs viewer anymore .. it is totally broke on Ubuntu 12.04, and server side baking has no purpose whatsoever, unless it is just to lock down DRM for the benefit of vendors. The whole world is sacrificing everything for the benefit of sellers. Customers don’t mean anything anymore. I love Second Life and I hate to be pushed out this way by the Labs hatred of its most loyal customers.
LikeLike
Have you tried reaching out to Firestorm support vis. your Linux issues? They should be able to provide some guidance.
Server-side baking does service a purpose, as it is aimed specifically at ending issues of avatar bake fail which are, and have been for years, prevalent across the grid and which is something everyone has encountered at least once in their in-world times, if not on numerous occasions. It’s the situation where you log-in or teleport, and avatars around fail to render properly and appear blurred. Or when you change from one outfit to another, and you appear OK to yourself – but to everyone else you appear to still be wearing the original outfit (or you can’t see the outfit you’ve just changed into, but everyone else around you can). It’s when you think you’ve changed outfits, go out, and someone tells you that you appeat to be wearing two different outfits simultaneously where you see only one – or worse, they tell you you are naked, when you appear in your world view to be dressed.
SSB should, hopefully, solve all of these issues for us as far as avatar skins and system-layer clothes are concerned, and lead to a much improved in-world experience.
LikeLike
I have heard of some cases where Firestorm support people had suggested Linux users to “install windows” to resolve their issues.
Just as well then, the overwhelming majority of Linux users use Singularity now.
LikeLike
Seriously? Do you believe everything you hear?
LikeLike
You do realize that windows OSes are the majority right?
LikeLike
Yes server side baking is some that is needed and if well done it will make Sl way better!
LikeLike
Well, I have been trying out the new Firestorm…and I’m pleasantly surprised. I’m a bit lost wiht some of the differences between it and Singularity, but overall I’d have to say I like Firestorm. It’s certainly less crash-prone than the previous version, and although I often have issues with the sound not connecting properly (which never seems to happen with Singularity), it’s not a bad viewer.
LikeLike