Firestorm 6.4.12 the EEP and more release

On Wednesday, December 9th, 2020, Firestorm issued a release version of their viewer – 6.4.12.62831. This is the formal release of Firestorm supporting the Lab’s Environment Enhancement Project (EEP); it also includes a number of other Lab-specific updates to the viewer, such as the Camera Presets capability.

Note: while there has been an EEP beta release – 6.4.5.60799 (July 2020) – this summary has been written for those who may still be running the 6.3.9.58205 release from May 2020.

Also, given limitations of my own time (coupled with an inability to run 6.3.9.58205 in direct comparison with 6.4.12.62831), this is a much briefer overview of changes for a Firestorm release in comparison to past overviews in these pages.

Table of Contents

Installation

  • There is no need to perform a clean install with this release if you do not wish to.
  • Do, however, make sure you back-up all your settings safely so you can restore them after installing 6.4.12.
  • Again, please refer to the Firestorm 6.4.12 generic release notes for additional details of all changes and updates in this release.

Register Firestorm as Default Hander

Starting with this release, towards the end of the installation process, Firestorm will display a prompt:

Do you want to register Firestorm as default handler for virtual world protocols?

A response of Yes to this prompt will set the viewer to open map SLurls for example.

Linden Lab Derived Updates Overview

Firestorm 6.4.12 brings the viewer to parity with the Lab’s 6.4.11 viewer code base. As such, it incorporates updates from Linden Lab previously included in the 6.4.5 Beta release and from the following Lab viewer releases:

  • The Chrome Embedded Framework (CEF) Update 2020, viewer 6.4.4.543157, providing better support for media playback options win the viewer, including the ability to live stream into Second Life.
  • The FMOD Studio update, viewer 6.4.3.542964, updating the viewer’s audio playback support to use FMOD Studio.
  • The Camera Presets viewer, 6.4.2.541639, – see Camera Presets, below, for more.
  • The Zirbenz Maintenance viewer, 6.4.1.540593.
  • The Environment Enhancement Project (EEP) viewer 6.4.0.540188 – see below for more.

New to the 6.4.12 Firestorm release are updates and improvements from the following Linden Lab viewers:

  • ToolsUpdate2 viewer, 6.4.6.545962, viewer build tools update to Visual Studio 2017, a more recent version of XCode and Boost.Fiber, dated August 10th, 2020.
  • Love Me Render #4 viewer, 6.4.9.549455 – rendering updates with a focus on EEP bug fixes, dated September 24th, 2020.
  • Mesh uploader viewer, 6.4.10.549686 – Linden Lab’s implementation of the uploader improvements previously found in Firestorm, with additional changes from the Lab. Dated October 14th, 2020.
  • The following Maintenance releases with assorted fixes and updates:
    • Maintenance Arrack, version 6.4.7.546539, dated August 19th, 2020.
    • Maintenance Bormotukha, 6.4.8.548890, dated September 18th, 2020.
    • Maintenance Cachaça, version 6.4.11.551711, November 6th, 2020.

Camera Presets

Camera Presets provides the ability for users to create one or more custom camera positions to define where and how the viewer camera is placed relative to your avatar, More than one set of presets can be created and saved, so that you can, for example have a camera position for general exploring, another suitable for combat games, another for building, etc., all of which can easily be accessed and used at any time via the Camera Presets drop-down.

For a general introduction to Camera Presets, please refer to: Tutorial: Viewer Camera Presets. However, when doing so, please note that the Firestorm Camera Floater is laid out differently to the official viewer, being more compact, as shown in the image below.

Camera Presets: options and floaters, as seen in Firestorm 6.4.12.
  1. Presets can quickly be selected from the Camera Presets button in the top right of the viewer, which will open a drop-down menu. By default, this drop-down will display the standard viewer camera positions of Front, Rear, and Side. Additional presets will be displayed as you create them.
  2. A button on the drop-down will open the Camera floater, if not already open. As well as controlling the camera position, this floater now contains the options for creating and saving camera presets.
  3. The most accurate way to establish new camera defaults is to use the Camera Position spinners and slider that can be accessed by clicking on the Position button in the Camera floater – again, see my Camera Presets tutorial for more on this approach.
  4. When you have created your desired preset, use the Save as Preset button to save it as a viewer setting. This opens the Save Camera Preset floater, which allows you to save the preset settings under a unique name or to overwrite an existing setting.
  5. Alternatively you can manually adjust the camera position relative to your avatar using the camera controls then click on the current settings button to open the Save Camera Preset floater and save the settings as described in (4.).
  6. You can also select any defined Camera Preset by clicking on the gear icon in the Camera floater to display a list of available presets – default and your own – and then clicking on the desired one.
  7. If you only wish to select a preset you have created, click the Use Preset button on the Camera floater to display a drop-down of available presets that excludes the viewer defaults of Front, Rear and Side. If you have not created any defaults yourself, the drop-down will be empty.

Environment Enhancement Project (EEP)

It  is unlikely that many people have not heard of the environment Enhancement Project (EEP). But in short:

  • EEP Replaces the use of Windlight .XML files to control the water and sky environments seen in Second Life.
  • Environment settings are saved within environment assets that you can keep in your inventory and / or share with and sell to others.
  • These environment settings can be applied to a region or to a parcel (subject to region permissions) and / or to your avatar (thus allowing those travelling in vehicles to maintain a consistent environment across multiple region crossings).
  • EEP allows:
    • For up to four different, independently controlled sky layers.
    • The Sun, Moon and Cloud textures to be replaced with custom textures uploaded to the viewer.
  • EEP also provides:
    • An extended day cycle of up to 168 hours, thus allowing a 7-day, 24-hour day / night cycle to be defined, for example.
    • A Personal Lighting floater that allows you to make viewer-side adjustments to the local environment for the purposes of photography.
    • New LSL functions to allow scripts to interact with parcel environments and that can be used with experiences.

EEP Resources

EEP is a large and complex overhaul of environment settings for Second Life, and there are numerous resources available for it. If you have not used EEP before, and as the Firestorm implementation is more-or-less as per the official viewer, I recommend reading some of the following:

EEP and Phototools

One of the popular elements within Firestorm is the Phototools floater. This has been updated to work with EEP, with the most noticeable changes being to the WL tab, now renamed Env, with the changes within it outlined in the image and notes below.

EEP and Phototools
  1. Environment drop-downs for Fixed Sky, Linden Water and Day Cycles. These display the currently-used environment settings for their respective environment types as seen in your viewer.
    • Click the down arrow for a list of all available environment asset types available to you in your inventory and via the Library → Environments folder.
    • Click on the required asset name to apply to your viewer only.
  2. Accesses the EEP Personal Lighting floater, which you can use to modify the current environment settings as seen in your viewer only.
    • The X button to the right of Personal Lighting will cancel any changes you have made to the current environment, and revert your viewer to displaying the settings for the selected asset.
  3. Quick Quick Environment buttons for setting the time of day to the SL default Sunrise, Noon, Sunset and Midnight settings.
  4. Shared Environment: presumably intended to re-apply the shared environment as set by the region / parcel holder. However, in testing, this did not appear to work.

Notes:

  • The drop-downs in (1) can also be found in the Quick Prefs panel, as can a button to open the EEP Personal Lighting panel.
  • As these options are applied to your viewer, note that the selected Day Cycle will not necessarily reflect the expected time of day – as Day Length / Offset can only be set at the parcel / region level.

Firestorm EEP Preferences

Firestorm provides two EEP-specific Preferences options. Both can be found in Preferences → Firestorm, and comprise:

  • A slider that allows you to set the interval in seconds over which manual environment changes will blend, with 0.0 being instantaneous. In previous versions of Firestorm, this was known as crossfade.
  • A checkbox to allow any personally applied EEP setting to persist between log-in sessions.
Firestorm 6.4.12 EEP Preferences

Additional EEP Notes

  • There are around 200+ EEP environment settings to be found in the Library → Environments folder. These have been provided to Linden Lab by Whirly Fizzle of the Firestorm team, and are available to all EEP-capable viewers.
  • As noted in the image above, these can be accessed via the WL tab in Phototools and via the drop-downs in Quick Prefs.
  • If you want to edit these any of the environment settings in the Environments folder, you must first copy them to a folder in your inventory (e.g. your Settings folder, or a sub-folder within it).
  • As per my tutorial, you can import the Windlight settings you have on your local drive and convert them to EEP settings – see Importing Windlight Settings as EEP Assets.

Preferences Updates

  • Preferences → Graphics → Hardware Settings → Dynamic Texture Memory:
    • These options will only be enabled / user-adjustable if your system in 64-bit with at least 512 Mb VRAM and GPUs supporting either the either atimeminfo (AMD) or nxmeminfo (NVIDIA) vendor-specific OpenGL extensions.
    • When available these options will allow you to a) specify the minimum amount of VRAM to be allocated to textures, even if the amount of video memory is exceeded; b) set the amount of physical video memory reserved for caching loaded textures that are not currently being displayed; c) define the percentage of video memory reserve for other uses.
    • Hover the mouse over settings to display tool tips with additional information on these settings.
    • When enabled via the check box, these options will set the Viewer Texture Memory Buffer slider to be greyed-out (see below).
The new Graphics Hardware options (outlined in red). Note these will only by enabled for you are running a 64-bit system with a GPU that supports either the atimeminfo or nxmeminfo vendor-specific OpenGL extensions
  • Preferences → Graphics → Rendering → Occlude objects for water distortion map:
    • When enabled, this option will restore object occlusion when generating the water distortion maps. Visuals are more correct with occlusion, however, it may result in objects reflected in the water flashing, and can be particularly bad with avatars & animesh under water when you view them from above water – see BUG-226670.
    • When disabled, will prevent the object / reflection flashing, but can result in a performance impact.
  • Preferences → Move & View → Movement: a check box that will allow the Double-Click on Land option to either walk or teleport your avatar to a scripted object.
Preferences Move & View Movement includes a new option for the double-click walk / teleport selection to work with scripted objects
  • Preferences → Backup tab now renamed Backup / Restore.

Build Updates – Mesh Uploader

The Mesh Uploader panel has been further updated in line with Linden Lab’s changes to the uploader seen in SL viewer release 6.4.10.549686, which in turn is based on contributions from Beq Janus of the Firestorm team, and which were first seen in Firestorm 6.0.2.56680 (February 2019), together with additional updates from the Lab.

These updates include:

  • UI changes include: an upgrade to preview resolution to 1024×1024; a scalable preview; a fixed display of colours in a preview; adjustment of colours to better correlate to in world (yellow frame of mesh, blue tint physics); rearranged UI elements to give more space for the preview even when not scaled up.
  • Informational changes include: two new boxes: cost breakdown and physics breakdown. These provide access to information that has always been available to the viewer from the upload costs update message but were not shown to the user.

Group Chat Access from Notices

With Firestorm 6.4.12, it is now possible to access group chat directly from Group Notices via a button within the notice floater.

Accessing Group Chat from Group Notices

Note: the button will only work where group chat is permitted.

RLV / RLVa Updates

Firestorm 6.4.12 contains the following RLV 3.3.3 and RLVa 2.3.0.62831 updates and fixes:

  • Add @buy and @pay restrictions to block object purchases and avatar payments respectively (because of baguettes).
  • Indicate user typing status with @redirchat=n with an optional toggle (RLVa menu / Show Redirected Chat Typing).
  • Fixes for:
    • The viewer crashing when accepting a give-to-#RLV task offer since the EEP merge.
    • Assertion failure on LLApp::isQuitting() in RlvHandler::cleanup() when disconnecting.
    • Assertion failure on m_Object.empty() in RlvHandler::cleanup() when an object only issues unknown commands.

Other Updates and Improvements of Note

  • FMOD Studio updated to 2.01.05 (updated Windows, Linux, Mac).
  • KDU updated to v8.0.6 (Windows, Linux, Mac).
  • Voice Server updated to Vivox Version 4.10.0000.32327.
  • LibVLC updated to version 2.2.8.
  • Chromium Embedded Framework (CEF) Dullahan updates:
    • Dullahan: 1.8.0.202007261348 (Windows) / 1.7.0.202008031101 (Mac).
    • Page of test URLs for Dullahan. With the Developer Menu enabled (CTRL-ALT-Q), press CTRL-SHIFT-Z followed by the Home Page button.
    • Chromium: 81.0.4044.138.
  • Notecards: saving a note card does not return the cursor to the top of the card, but retains it at the edit point – see FIRE-24306.
  • Bakes on Mesh: Bake textures can be applied to non-attached editable items – see FIRE-24333 / BUG-227553.
  • Movelock: feedback not given if users attempts to move avatar with movelock or other locks engaged – see  FIRE-29880.
  • Pose Stand (Avatar → Pose Stand …): update so pose stand animations work with Bento bones – see FIRE-29333.
  • Bulk uploads: option added to deactivate the confirmation dialogue for bulk uploads – see FIRE-29935.
  • Appearance → Wearing: now show attachment points for attachments – see FIRE-30096.
  • The French language translation has been added back.

As always, refer to the release notes for a full list of bug fixes and additional improvements.

For OpenSim

Note that these updates were actually in the 6.4.5 Beta release, but are included here for those who did not update to that version of Firestorm. For OpenSim users:

  • The viewer incorporates Windlight ↔ EEP interoperability, allowing EEP viewer users to visit legacy Windlight regions.
  • The viewer supports the new OpenSim 0.9.2 with EEP, code-named “Ugly Sky.”
  • There is now a fast-entry grid feature on the login screen; simply paste a URI to add a new grid.

In addition, the last Firestorm OpenSim Release had a bug that caused crashes when rezzing items. This bug was responsible for 70% of all reported FS OpenSim crashes on the 6.3.9 version, and it has been fixed.

New to 6.4.12 for OpenSim are:

  • The viewer now forces the grid list to be available on every start-up of the OpenSim build, and avoids the issue of the grid list being disabled if the OpenSim version is running alongside the Second Life version. There is also an option to disable this for grids that really need/want to restrict external grid access (though frankly, firewalls are a far better choice)
  • Object caching for OpenSim is now “fixed” so that when editing an object with large numbers of items inside, the viewer will not refresh every time you close and reopen the edit.
    • Note, however, this does not change the fact that the object contents fetch protocol is extremely poor, whenever the contents update, you will still have to endure the long wait. There may be some news on that in the future but it requires server changes as well as viewer.
  • My Suitcase should no longer go missing from inventory.

General Observations

I don’t have a lot to comment on with this release.  As with the EEP Beta, I have found it to be stable and with acceptable performance. The updates to the Camera floater to incorporate Camera Presets are a marked improvement on the Beta release and present a more logical flow. I’m not sure if my whining on this with the Beta had any influence, but I appreciate the changes made.

As this release will effectively make EEP a fact of life for everybody, it’s good that the Firestorm team have integrated the Love Me Render #4 viewer fixes for EEP into the release. Whilst the LMR fixes do not address all issues with EEP, they go a long way to smoothing out some of the more noticeable issues with the capability, even if there are others that still need / are awaiting some TLC from the Lab.

For my own part, I have to admit to liking EEP and have had a certain amount of fun playing with it, particularly where Day Cycles are concerned. So, if you’ve not tried it,  I’d urge you to give it a try (just stick with some of its more arcane aspects using the resources listed above), as the results can really be worth it – and they can automatically be enjoyed by everyone by default, rather than just those who happen to be running Firestorm,  as has been the case with Firestorm parcel Windlight settings.

Other than that, I’ve really not much else to say, so here endeth the article.

Related Links

41 thoughts on “Firestorm 6.4.12 the EEP and more release

  1. 6.4.12 have some big issues
    1st. textures take forever to load
    2nd. the FPS is decreased like a lot

    and a few other minor ones, so for me is not worth the update until at least the texture issue is fixed

    Like

    1. Slower loading may not be Firestorm-specific; there have been reports of similar by users in general (not just FS users) following the AWS transition, so texture locating times, etc., may be related to that & the need for messaging tweaks may be required between simulators / CDN service / viewer.

      The FPS drop might be EEP related – there is a noticeable drop in EEP viewers as a result of Linden Water plane rendering problems (themselves apparently the result of a “fix” by linden Lab for water reflection flashing issues). As noted in the article, there is a means to “correct” this (Preferences → Graphics → Rendering → Occlude objects for water distortion map); however, while this can eliminate the performance drop, it can re-introduce a the flashing reflections issues.

      Like

      1. Hm, the fps-drop is dramatic. Besides the typical 2, 3 trolls, the main topic in the comments on http://www.firestormviewer.org relates to the negative effect on fps since the full implementation of EEP. Guess I’ll switch to Black Dragon, therefore.

        Like

        1. I can only speak from my personal experience in that I saw around at 12-15% drop between the EEP beta and 6.3.9, and the EEP release is offering roughly the same FPS as the beta (I admittedly cannot do a direct comparison between the EEP release and 6.3.9, as for some reason the latter simply will not run on my system any more (even after removing the EEP release and performing a clean install). I’m running a 16Gb Haswell i5 system with a 4 Gb GTX 970 with ALM enabled (and usually with shadows on as well for photography, unless a region is loaded with avatars) + an average DD of 250m.

          That said, I’ve always found FS to be generally below other viewers in FPS, and would actually happily switch to something like Catznip bar a couple of tools FS offers that I have a preference for using (and EEP now sees one of those diminish in the amount I use it, so a swap may yet be forthcoming).

          Liked by 1 person

  2. i think the phrase “providing better support for media playback options win the viewer, including the ability to live stream into Second Life” can be misunderstood; is possible playback in sl also live streams from youtube, not direct video streaming.

    Like

  3. Most of the updates are good and are welcome. Finally the stars in the night sky look good.

    A pity that the Clearwater Water preset has been removed. Or is it the same as Lassies Clearwater? Maybe its just been renamed.

    My issue is the implementation of the camera presets. I have used these settings for years: https://i.imgur.com/T3GCXyf.png
    Up to now, I’ve used the debug settings to adjust this using CameraOffsetRearView, CameraOffsetScale and FocusOffsetRearView. What this did was to change the default rear view, so when you hit that rear view button, it set the camera to this adjusted view. Now with presets, the rear view button goes back to the SL default of an unrealistically high rear cam. Getting the cam to my preferred over-the-shoulder setting, is now 2 extra clicks and is kinda irritating if you use vehicles.

    Like

      1. Yes, as per the article: “When you have created your desired preset, use the Save as Preset button to save it as a viewer setting. This opens the Save Camera Preset floater, which allows you to save the preset settings under a unique name or to overwrite an existing setting” (emphasis added).

        Like

        1. Yes! Note: After I wrote it I found that resetting the camera with Shift+Esc still puts the camera back on the SL default high position (i.e. deactivates the active preset), while just pressing Esc puts the camera back to the active presets position (e.g. after camming around). So if you accidentally Shift-Esc’d just have to go into camera controls and select your preset again.

          Like

          1. That’s one I hadn’t noticed, TBH. Possibly because I flycam a lot with Space Navigator, so instinctively only use ESC to reset.

            Like

        2. As there seems to be confusion, and as referenced in the Firestorm overview here,there is a complete guide to Camera presets (which is a Lab-added capability and not something that is Firstorm-specific), I (again) refer people to my Camera Presets tutorial. Just note that the Firestorm Camera floater lays things out slightly differently.

          Like

  4. I’m noticing a 50-70% reduction in FPS. I tried the thing with “Occlude objects for water distortion map” but that didn’t make any difference at all. Others on my home sim are saying they’re usually suffering the same issue, and a switch back to FS 6.3.9 seems to fix it. Weird, I’m guessing EEP required drastic changes underneath to the rendering engine, but I’m surprised nobody noticed these issues before release. Here’s hoping they fix it.

    I wish they’d coordinate more with Marina about RLV version numbers, the lack of spheres in RLVa means current version numbers are confusing, not just to end users, but to scripts too.

    Like

    1. For those having problems, you can “downgrade” to 6.3.9 by downloading the installer here: https://wiki.firestormviewer.org/fs_older_downloads

      I’m noticing OS incompatibilities too (for some reason the new version treats the “gridnick” as a hostname which is causing error messages to appear.) At least the FPS rate seems OK on my OS grid though!

      (Also I misspelt “Marine” above, apologies)

      Like

  5. No more daytime slider?????? At least I can’t find it on the quick pref menu or in the environment settings.

    Some of these changes are REALLY complex. Maybe they are all for the better, but I’m afraid you are adding a big learning curve for new users. I’m an old user and some of this is confusing me.

    Like

    1. In theory, new users won’t encounter any of the “old” Windlight options, as EEP is a Lab-derived capability and so common to all up-to-date viewers; ergo confusion there should in theory be minimal.

      However, EEP is a complex capability with which to get to grips if you’re familiar with Windlight settings and controls, hence why I’ve included links in the article to my EEP Primer – which provides a general overview of EEP and its associated floaters / panels menu items, and a far more in-depth tutorial that covers all aspects of EEP and how to use it.

      For photographers who wish to change the time of day in *their own view* of a scene, the EEP tool to use now is the Personal Lighting floater, which is explained in this part of my tutorial. Again I agree that if you’re familiar with using the “old” Quick Prefs and Phototools sliders, this is initially more confusing to look at, takes up a lot of screen real estate and and the “trackball” approach to positioning the Sun and / or Moon does take some getting used to – but is is what we now have, and with practice (and re-training of muscle memory) I can say from experience, it does become easier to use over time.

      Like

      1. But now I don’t even know what the default is, so I can be on the same page with other people. Under windlight sky, if I choose “shared environment” then other people report they see a different sky than I do. If I choose “day cycle based” it jumps to the first custom setting on the list for some reason. And strangely, “default” is no longer at the top but down among the custom settings.

        I don’t know which of these changes are Firestorm specific, or driven by LL. But any chance we could at least get the slider back?

        Like

        1. John,

          Firestorm is admittedly confusing in how EEP is handled, as it appears (to me at least) that incorrect terminology has been used in places. I’ll attempt to explain:

          • Under EEP as provided by LL, Environment settings can be applied in three ways: to a region, to a parcel (subject to permissions), and to your avatar (so technically, applied so only your viewer can see them)
          • In order to see the region / parcel environment settings, you need to go to World > Environment > and check Use Shared Environment. This will display whatever sky, etc., settings have been established for the region / parcel (managed by the simulator), and everyone else using this option will also see the same sky, etc.
          • if you later attach EEP settings to yourself or use the Personal Lighting floater, the sky settings, etc., that you see will only apply to *your* viewer, until such time as you re-log*, or you go to World > Environment > and check the Used Shared Environment option once more.

          * Note: Firestorm has a Preference option, as per the article, that forces personally applied EEP settings to persist across log-ins. So if this is set, re-logging will not revert you to seeing the region / parcel sky, etc., settings, you must use the menu option.

          Firestorm appears to introduce confusion into things because:

          • Phototools has a button labelled “Shared Environment” However, this does not appear to make the viewer request the region / parcel environment from the simulator, and so when clicked, does not switch the viewer to using the region / parcel settings – you need to use World > Environment > and check Use Shared Environment for this to happen.
          • Similarly, the Fixed Sky and Water drop-downs in both Phototools and Quick Preferences also have options labelled “Shared Environment” – but again, these options do not appear in any way related to reading the region / parcel EEP settings, and so do not switch you over to using them – again you need to use World > Environment > and check Use Shared Environment for this to happen.
          • As far as I’ve been able to tell, all the “Shared Environment” options in the drop downs do, is to select the first available EEP setting in the list of those available to you, and apply it – again, in your viewer only.

          In terms of setting the time of day, the old Phototools / Quick Preferences slider is incompatible with EEP, which offers a far wider freedom of movement for both Sun and Moon through the (admittedly less intuitive) “trackball” controllers. For photographers, these controls are available through the Personal Lighting floater, which can be accessed through the appropriate buttons on both Phototools and Quick Prefs. For more information on Personal Lighting, please refer to the following sections of my EEP tutorials:

          I hope this helps.

          Like

  6. I can confirm MASSIVE fps drop, 10900k/rtx3090 and at for 4k with most settings maxed, it goes from 20-40+fps in the non EPP viewer, down to 8-10fps when in a populated sim. I notice 1 core maxed out, and the 3090 idling most of the time in this case.

    Like

  7. Usually a change provides benefit(s). A few people want to sell a cloud package? We are in this snarled over detailed mess so some person can sell 6 puffy cloud kits a year?

    This is a mess, thanks Linden, and so well timed- really needed it in the busy holiday season. Hopefully the FS people over time can rework it so it becomes as transparent as possible .

    I know LL worked for years on EEP, and still had stuff to do before they released their version but somewhere along the way someone should have said– if it is this messy and we’re still tweaking it maybe it is time to put it down and move on to better brighter simpler improvements that all can see and desire.

    They could have fixed group chat with all these hours of engineering.

    Like

    1. In fairness, EEP is is more than “a few people want to sell a cloud package” (Windlights could actually be sold prior to EEP, but in a very roundabout way – ask Stevie Davros).

      While it does have issues, EEP offers an lot more in the way of capabilities that Windlight – including several that users have been asking for for a long time – a more flexible day length, the ability to have environments set server-side by altitude or at the parcel level without reliance of a viewer-specific hack, the ability to (somewhat) reflect real-time time-of-day passage; the ability to replace the Sun and Moon textures, etc. As such, and like all viewer features, how “valuable” it might be seen to be is pretty subjective & down to what you prefer doing in SL; while I find some of the issues with EEP niggling, and don’t like the way in which some of the floaters gobble screen space, as a Second Life photographer, I’ve long since adapted to using the Personal Lighting Floater, and as a land holder, I appreciate and enjoy the capabilities EEP brings to my land parcels.

      Like

  8. Sorry but this new release is a nightmare:
    1) FPS dramaticallt low: with SL standard viewer last release is 40FPS while in the same moment and the same parcel with Firestorm last release is 12FPS
    2) screen freezes for several seconds every 3 or 4 seconds: it’s impossible to use it!
    I’m sorry but I’m going to use SL viewer till Firestorm will releases some thing usefull. It’s a so big big deception!! And I will suggest to everyone to avoid Firestorm till these issues will be fixed.

    Like

  9. Connie.. you were referring in an earlier comment to 6.4.12 treating the GridNick as a hostname. Its meant to use the GridURI send in Simulator Features OpenSimulator extras I believe, but has a number of fallbacks if that is not supplied by the grid/region. It should work fine on any OpenSim version right back as far as 0.8.9.1 (over 5 year old), but some branched off code variants might not be providing a GridURI, hence the fallbacks. Can you give an example of the grid and region you were on that seems to use the Grid nickname versus the correct grid hostname:port?

    Like

    1. Thank you I will try that. It was my private grid, but I’ll double check it is sending the same information as, say, one of the big public grids (maybe Mobius, I may switch to their fork of the software anyway)

      It is odd, the right URIs appeared in earlier Firestorms, and when I reverted to 6.3.9 because of the slowness it picked up the URI again properly.

      Like

    2. Alas I looked and I can’t find anything to set. “GridURI” isn’t in the example configs, the code itself doesn’t define what’s supposed to be there, and I set it anyway but it didn’t change anything. In the grids.user.xml file in my profile (the thing Firestorm sets up) it correctly sets a property called slurl_base, and the slurl_base is what I’d expect (hop://:/”) but Firestorm ignores it and continues to try to resolve my gridnick and complain when it can’t do it.

      So… giving up for now. Hopefully someone else with influence will notice, as I doubt anyone cares what I have to say at this point and I’ve no desire to submit bug reports with private information (it’s a private simulator at this point, I don’t want hackers finding it.)

      Firestorm 6.4 seems to be a bust anyway. It’s too slow to be usable in Second Life. Hopefully the next release will fix these issues.

      Like

      1. Hi Connie. Sorry I may have confused this by talking about the “GridURL”. GridURL is an internal value sent by the OpenSim servers to viewers. Firestorm now tries to set a GridURL to use in addresses, hops, etc using various bits of information coming from the OpenSim servers. It can be set clearly and non-ambiguously in some “OpenSimExtras” capabilities/settings sent by OpenSim servers. GridURL as sent is set in the OpenSim server software via the Grid core services (usually ROBUST via Robust.exe) or can be overridden on a region by region basis in the region supporting OpenSim.exe. The various things used do come from places in the (admittedly quite complicated) config files that you can set up by OpenSim grid owners. GridURL basically is set to the GatekeeperURI from Robust.HG.ini unless overridden on a region by region basis.

        This OpenSim wiki page gives the gory details…

        http://opensimulator.org/wiki/SimulatorFeatures#Robust.HG.ini.2C_GridURL_and_GridURLAlias

        I hope this is accurate, to the best of my knowledge it is. But hopefully someone in the community will correct this if it is inaccurate.

        Like

        1. Should have said GridURL normally comes from the GatekeeperURI in the [Hypergrid] section of Robust.HG.ini as described in the OpenSim wiki page link I gave.

          Like

        2. Thanks Ai, especially for the link, that gives me a better idea of what’s supposed to be in that file. I will add the GatekeeperURI and see if that solves it, but I do note that someone else has apparently noticed the bug:

          https://jira.firestormviewer.org/browse/FIRE-30700?jql=text%20~%20%22gridnick%22%20ORDER%20BY%20created%20DESC

          Fingers crossed it’ll work out with GatekeeperURI, and I’m somewhat surprised that this is an issue given it’s putting what’s apparently the right value in the grids.user.xml file where I assume it’s meant to be, but at least I know they are aware of it.

          Like

  10. “More higher you go,more alone you will be”
    Making SL too complicated can alienate the usual players and make it unlikely that new players will join.In a world where new games and diverse experiences never stop appearing,turning a game into an annoying experience can be a death sentence for IT SELF.Perhaps those who think they are too smart should review their concepts of what is nice and playable .Firestorm team should be more modest and try to “take it easy”with in the SL is already complicated,not making it harder.For ex., why change the camera controls,EEP is not enough hard to handle? They need to put more rocks on the path? Yes, I know, they will say: “learn it or leave it, dumb user”and I will say:”More higher you go,more alone you will be”…see ya..

    Like

    1. Nah. Neither EEP nor Camera Presets are a barrier to new users simply because incoming usersy do not have to understand either from the get-go, and can in fact user SL without ever being aware of them. As such, both capabilities can be picked-up at any time, be it days, weeks, months or even years after joining SL and / or how their knowledge and understanding of the platform, and the viewer’s capabilities grow.

      Of course, it’s a different matter with something like EEP for existing users who have been used to manipulating Windlight settings in certain ways, simply because it represents something “new” to learn (thus inconveniencing those who just want to “get on with things”).But looked at logically, EEP can be broken down into elements, not all of which have to be learned by everyone (many people – photographers included – could get by only learning about the Personal Lighting folder & how to copy / attach EEP asset). Yes, some of the new controls (e.g. the Sun / Moon trackballs) can be frustrating to understand, but once grasped cane be used with ease (and I speak as one who uses them daily, both as a photographer and / or as creator of Day Cycles). Similarly, while there are performance issues associated with EEP (which seem to hit some harder than others), LL’s graphics team are continuing to work on the viewer’s rendering engine, so hopefully we’ll see improvements in these areas in the coming year.

      As to Camera Presets, I’d just point out that they are something many users have been requesting for years, in order to be able to stop buggering about with debug settings.

      Like

  11. I don’t like the new buttons on my camera controls. I try to keep my screen as HUD free as i can, but camera controls are something i use constantly.
    There is already a toolbar button called “phototools camera” that has EVERYTHING the “new” feature has and can be added to the toolbar is someone wants it. Adding the button to the camera controls just make them bigger and protruding more into my field of vision….and it’s something i don’t need or want.

    Like

    1. While the Phototools Camera floater includes the ability to use Camera Presets, its footprint is actually larger than the default camera floater, and it can be more cumbersome to use (nor is it selected by default when using the Presets option in the top right of the viewer). Ergo, I’d say that just toggling the default camera floater on / off (or leaving only) is far more preferable if screen real estate use is your primary concern (unless you’re constantly changing things like camera smoothing, zoom speed and the like).

      Like

Comments are closed.