This procedure is used for building a 64-bit viewer on 64-bit Debian systems and was tested and verified on Debian 9.3. This procedure assumes that your system has been properly updated.

This procedure may not work on older versions of Debian, nor has it been tested on any other version of Debian or any other distribution/variant/derivative.

The build process requires at least 4GB RAM with swap, a modern dual-core CPU and 32GB available HDD space. Recommded 8GB or more RAM, quad-core CPU and 32GB available HDD space.

This is needed for compiling any viewer based on the LL open source code and only needs to be done once.

Firestorm requires version 4.9 or 4.8 of the gcc/g++ compiler. This is not available in Debian 9's default repositories, so we need to add a Jessie repo.

sudo echo "deb http://ftp.us.debian.org/debian/ jessie main" >> /etc/apt/sources.list
sudo apt update

The required tools, some of which may already be installed, are:

sudo apt-get upgrade # to make sure all installed packages are current
sudo apt-get install --install-recommends moreutils bison bzip2 cmake curl doxygen flex g++-4.9 gdb m4 mercurial python python-pip

(the –install-recommends flag tells apt-get to install all packages recommended by each named package.)

The build environment need to know to use gcc 4.9:

sudo update-alternatives --remove-all gcc
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 49 \
--slave /usr/bin/g++ g++ /usr/bin/g++-4.9 \
--slave /usr/bin/gcov gcov /usr/bin/gcov-4.9
sudo update-alternatives --config gcc

Note that this will “hide” the current gcc from the build environment, so you will want to add it as an alternative, then use the “update-alternatives –config gcc” command to switch versions as needed.

These libraries may be included with your distribution, and some may already be installed:

sudo apt-get install --install-recommends libgl1-mesa-dev libglu1-mesa-dev libstdc++6 libx11-dev libxinerama-dev libxml2-dev libxrender-dev

Autobuild is a Linden Lab resource that does all the hard work. The 64-bit version requires a modified autobuild package, which our Nicky Djasmin has provided.

pip install --upgrade pip
pip install llbase
pip install hg+https://bitbucket.org/NickyD/autobuild-1.0#egg=autobuild

This will install autobuild and add a link in the exec path

Plan your directory structure ahead of time. If you are going to be producing changes or patches you will be cloning a copy of an unaltered source code tree for every change or patch you make, so you might want to have all this work stored in its own directory. If you are a casual compiler and won't be producing any changes, you can use one directory. For this document, I will assume ~/src.

cd ~/src

There are several repositories but the one wea re after is the development repository. You can grab all the sources if you wish, but but keep in mind that each FS source requires around 110MB initially and around 4.3GB after the binaries have been built, plus possible compiling overhead.

hg clone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl

It will create a folder called phoenix-firestorm-lgpl. You can optionally add a folder name to the end of the hg clone command and it will use that as the destination directory name:

hg clone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl firestorm-source

The rest of this document will assume the default directory, phoenix-firestorm-lgpl

This can take a bit, it's a rather large download. On a slow network, it may fail, and this script can help mitigate the issue:

pull_in_chunks.sh

#!/bin/bash
 
cd ~/src
hg clone -r 10000 http://hg.phoenixviewer.com/phoenix-firestorm-lgpl
cd phoenix-firestorm-lgpl
for i in {15000..40000..5000}
do
	echo "Grabbing to change $i"
	hg pull -u -r $i
done
echo "Grabbing to tip"
hg pull -u
cd ~/src

cd ~/src/phoenix-firestorm-lgpl
autobuild -m64 configure -c ReleaseFS_open

This will set up to compile with all defaults and without non-default libraries. It will fetch any additional necessary libraries.

There are a number of switches you can use to modify the configuration process. The name of each switch is followed by its type and then by the value you want to set.

• LL_TESTS (bool) controls if the tests are compiled and run. There are quite a lot of them so excluding them is recommended unless you have some reason to need one or
  more of them.
• clean will cause autobuild to remove any previously compiled objects and fetched packages. It can be useful if you need to force a reload of all packages
• package will result in a bzip2 archive of the completed viewer. Enabled by default, you would have to use -DPACKAGE:BOOL=Off to disable it

TIP: OFF and NO are the same as FALSE; anything else is considered to be TRUE

Examples:

autobuild -m64 configure -c ReleaseFS_open -- --clean -DLL_TESTS:BOOL=FALSE
autobuild -m64 configure -c ReleaseFS_open -- --clean

The first time you configure, several additional files will be downloaded from Firestorm and Second Life sources. These are mostly binary packages maintained outisde the viewer development itself. And if you use the –clean switch, you will re-download them all.

autobuild -m64 build -c ReleaseFS_open

Now, sit back, read War and Peace, calculate PI to 50 places, tour the country, whatever you desire. Compiling can take quite a bit of time depending on your computer's processing power.

NOTE: It is possible to use autobuild to do both the configure step (only needed once) and the build step with one command (autobuild -m64 build -c ReleaseFS_open [– switches] . For clarity, they are mentioned separately.</WRAP>

Create the desktop launcher

cd ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/etc
./refresh_desktop_app_entry.sh

Then open your applications menu and look in the Internet or Network branch for the Firestorm launcher.

cd ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged
./firestorm

You can copy or move the contents of ~/src/phoenix-firestorm-lgpl/build-linux-i686/newview/packaged to another location if you choose, and then launch firestorm from there. Example:

mkdir ~/Firestorm
cp -a ~/src/phoenix-firestorm-lgpl/build-linux-x86_64/newview/packaged/* ~/Firestorm
cd ~/Firestorm
./firestorm # or etc/refresh_desktop_app_entry.sh to create a desktop launcher

If you encounter errors or run into problems, please first double check that you followed the steps correctly. One typo can break it. Then, check whether someone else already had the same issue. A solution might be known already.

• IRC: The #phoenixviewer-dev channel is the best place to look for solutions.
  A lot of self-compilers and project developers hang out there and are ready to help you.

• Jira:JIRA may contain resolved tickets.
  Search using the error you encountered.

• Included documentation: In the Firestorm root folder are several “README” documents. You should make yourself familiar with their content, even if they appear to be out of date.

If you found a procedural error in this document, please let us know in as much detail as you can, either contact the author (preferred) or discuss on IRC.

• Missing libraries/applications/packages This may occur if you did not or could not install the listed packages. The packages do exist in the default Ubuntu repositories, so make sure you did not disable those. If you find that a library or application is in a different package for your system, contact the author with the name of the library or application, the name of its package and your Linux OS so that information can be checked and added here.

• Delayed sounds Some users have noted that OpenAL plays sounds from the viewer up to 20 seconds after they are triggered. There is no solution to this via the viewer, but there may be some solutions on the Internet

• No Sounds The viewer will try to use whatever sound service you have running, but might need a little coaxing. Read through the firestorm script inside the program folder, you will find various commended options. Uncommenting one or more may help restore sound.

• Voice Won't Connect It was observed in testing that voice would not connect unless “No Device” was chosen for the Input device (Preferences ⇒ Sound & Media ⇒ Voice ⇒ Audio Device Settings). This was resolved by replacing Firestorm/lib/libvivoxal.so.1 with a copy from release.

A HUD's orientation data (position and rotation) data is stored with the HUD when it's detached. It is relative to the attach point, not to the viewer. (Any attached object has its orientation data saved when it's detached)

There is what appears to be a server-side bug: BUG-41379, which can cause all scripts in the region to switch to the Stop Running state. Unfortunately, this is a rather permanent breakage if you don't have permissions to start/run/reset scripts on the object.

Note: While this issue most commonly affects HUDs, it can also affect any and all other scripted attachments you were wearing when the breakage happened.

There are a few things you can try to get the items working again.

This page describes all necessary steps to build the Firestorm viewer for Windows, using the updated build infrastructure introduced with Linden Lab's project Alex Ivy.

NOTE: This description is NOT valid for building versions of the viewer prior to the Alex Ivy merge ([http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/3affbb06dbac|revision 54609]!

This is needed for compiling any viewer based on the Linden Lab open source code and only needs to be done once.

All installations are done with default settings (unless told specific) if you change that your on your own

• Install Windows 10 Pro 64bit using your own product key
• Alternatively: Install Windows 7 or 8.1 Pro 64bit

• Install Visual Studio 2013 Professional
• Note: If you don't own a copy of Visual Studio 2013 Professional, you might consider installing the Community version (requires creating a Microsoft account if you do not already have one)
  • Run the installer as Administrator (right click, “Run as administrator”)
  • Uncheck all the “Optional features to install:” - they are not required

• Download and install DirectX SDK (June 2010)
  • Run the installer as Administrator (right click, “Run as administrator”)
  • At the Installation Options screen, set everything except the DirectX Headers and Libs to “This feature will not be installed”

• Download and install TortoiseHg 3.2.3 or newer (64bit)
  • Note: No option available to install as Administrator
  • Use default options (path, components etc.)
  • Add the following directory to your path:

    C:\Program Files\TortoiseHG

• Download and install at least CMake 3.4.3 (32bit is only option)
  • Run the installer as Administrator (right click, “Run as administrator”)
  • At the “Install options” screen, select “Add CMake to the system PATH for all users”
  • For everything else, use the default options (path, etc.)
  • Make sure that the following directory was added to your path:

    C:\Program Files (x86)\CMake\bin

• Download and install Cygwin 64 (64bit)
  • Run the installer as Administrator (right click, “Run as administrator”)
  • Use default options (path, components etc.) *until* you get to the “Select Packages” screen
  • Add additional packages:
    • Devel/patch
  • Use default options for everything else
  • Make sure that the following directory was added to your path.:

    C:\Cygwin64\bin

• Download and install the most recent version of Python 2.7 (32bit)
  • Linden Lab advises to use the 32bit version as the VMP requires it. However, Firestorm currently doesn't use VMP, so the 64bit version might work (use at own risk!)
  • Note: No option available to install as Administrator
  • Use default options (path, components etc.) until you get to the “Customize Python” screen
  • Change “Add python.exe to Path” to “Will be installed on local hard drive”
  • Add the Python installation dir to the system path:

    C:\Python27

Confirm things are installed properly so far by opening a Cygwin terminal and enter:

cmake --version
hg --version
python --version

If they all report sensible values and not “Command not found” errors, then you are in good shape.

• Install Boostrip pip
  • Download (Save As) get-pip.py and copy to a temp folder
  • Open Windows Command Prompt
  • Switch to that temp folder and execute it:

    python get-pip.py

  • Pip will be installed
  • Add the following directory to your path:

    C:\Python27\Scripts

• Install Autobuild
  • Open Windows Command Prompt and enter:

    pip install hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild

  • Autobuild will be installed. Earlier versions of Autobuild could be made to work by just putting the source files into your path correctly; this is no longer true - Autobuild must be installed as described here.

• Set environment variable AUTOBUILD_VSVER to 120

• Check Autobuild version to be 1.1.7 or higher:

  autobuild --version

• You must install the Unicode version here and not the one from the NSIS page
• Not required unless you need to build an actual viewer installer for distribution, or change the NSIS installer package logic itself

In order to make it easier to build collections of related packages (such as the viewer and all the library packages that it imports) with the same compilation options, Autobuild expects a file of variable definitions. This can be set using the environmenat variable AUTOBUILD_VARIABLES_FILE.

• Clone the build variables repository:

  hg clone https://bitbucket.org/Ansariel/fs-build-variables <path-to-your-variables-file>

• Set the environment variable AUTOBUILD_VARIABLES_FILE to

  <path-to-your-variables-file>\variables

• Start the IDE
• Navigate to Tools> Options> Projects and Solutions> Build and Run and set maximum number of parallel projects builds to 1.

Plan your directory structure ahead of time. If you are going to be producing changes or patches you will be cloning a copy of an unaltered source code tree for every change or patch you make, so you might want to have all this work stored in its own directory. If you are a casual compiler and won't be producing any changes, you can use one directory. For this document, it is assumed that you created a folder c:\firestorm.

c:
cd \firestorm
hg clone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl

This can take a bit, it's a rather large download.

Most third party libraries needed to build the viewer will be automatically downloaded for you and installed into the build directory within your source tree during compilation. Some need to be manually prepared and are not normally required when using an open source configuration (ReleaseFS_open).

Note: This typically needs to only be done once since FMOD Studio rarely changes. FMOD Studio can be downloaded here (requires creating an account to access the download section). Make sure to download the FMOD Studio API and not the FMOD Studio Tool!

c:
cd \firestorm
hg clone https://bitbucket.org/Ansariel/3p-fmodstudio

• After you have cloned the repository, copy the downloaded FMOD Studio installer file to C:\Firestorm
• If you downloaded a different version of FMOD Studio that is currently used in the viewer, you will have to modify the file build-cmd.sh in the root of the repository. Right at the top, you find the version number of FMOD Studio you want to package (one short version without separator and one long version). Change these values to the version you downloaded:

FMOD_VERSION="11002"
FMOD_VERSION_PRETTY="1.10.02"

Continue on the Windows command line:

c:
cd \firestorm\3p-fmodstudio
autobuild build --all
autobuild package

While running the Autobuild build command, Windows might ask if you want to allow making changes to the computer. This is because of the FMOD Studio installer being executed. Allow these changes to be made.

Near the end of the output you will see the package name written and the md5 hash below it:

wrote C:\firestorm\3p-fmodstudio\fmodstudio-{version#}-windows-{build_id}.tar.bz2
md5 c3f696412ef74f1559c6d023efe3a087

where {version#} is the version of FMOD Studio (like 1.10.02) and {build_id} is an internal build id of the package.

cd \firestorm\phoenix-firestorm-lgpl
cp autobuild.xml my_autobuild.xml
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml

Copy the FMOD Studio path and md5 value from the package process into this command:

autobuild installables edit fmodstudio platform=windows hash=<md5 value> url=file:///<fmodstudio path>

For example:

autobuild installables edit fmodstudio platform=windows hash=c3f696412ef74f1559c6d023efe3a087 url=file:///C:\firestorm\3p-fmodstudio\fmodstudio-1.10.02-windows-180191431.tar.bz2

Note: Having to copy autobuild.xml and modify the copy from within a cloned repository is a lot of work for every repository you make, but this is the only way to guarantee you pick up upstream changes to autobuild.xml and do not send up a modified autobuild.xml when you do an hg push.

Open the Windows command prompt.

If you are building with FMOD Studio and have followed the previous FMOD Studio setup instructions AND you are now using a new terminal you will need to reset the environment variable first by entering

set AUTOBUILD_CONFIG_FILE=my_autobuild.xml

Then enter:

 c:
 cd \firestorm\phoenix-firestorm-lgpl
 autobuild configure -c ReleaseFS_open

This will configure Firestorm to be built with all defaults and without third party libraries.

Note: Configuring the viewer for the first time will take some time to download all the required third-party libraries. As of Autobuild 1.1, the download progress is hidden by default. If you want to watch the download progress, you can use the verbose option to display a more detailed output:

autobuild configure -v -c ReleaseFS_open

There are a number of switches you can use to modify the configuration process. The name of each switch is followed by its type and then by the value you want to set.

• -A <architecture> sets the target architecture, that is if you want to build a 32bit or 64bit viewer (32bit is default if omitted).
• –fmodstudio controls if the FMOD Studio package is incorporated into the viewer. You must have performed the FMOD Studio installation steps in FMOD Studio using Autobuild for this to work.
• –package makes sure all files are copied into viewers output directory. You won't be able to start your compiled viewer if you don't enable package or do 'compile' it in VS.
• –chan <channel name> lets you define a custom channel name for the viewer
• -LL_TESTS:BOOL=<bool> controls if the tests are compiled and run. There are quite a lot of them so excluding them is recommended unless you have some reason to need one or
  more of them.

TIP: OFF and NO are the same as FALSE; anything else is considered to be TRUE

Examples:

• To build a 32bit viewer with FMOD Studio and to create an installer package, run this command in the Windows command window:

  autobuild configure -c ReleaseFS_open -- --fmodstudio --package --chan MyViewer -DLL_TESTS:BOOL=FALSE

• To build a 64bit viewer without FMOD Studio and without installer package, run this command:

  autobuild configure -A 64 -c ReleaseFS_open -- --chan MyViewer -DLL_TESTS:BOOL=FALSE

There are two ways to build the viewer: Via Windows command line or from within Visual Studio.

If you are building with FMOD Studio and have followed the previous FMOD Studio setup instructions AND you are now using a new terminal you will need to reset the environment variable with

set AUTOBUILD_CONFIG_FILE=my_autobuild.xml

Then run the Autobuild build command. Make sure you include the same architecture parameter you used while configuring the viewer:

autobuild build -A 64 -c ReleaseFS_open --no-configure

Now, sit back, read War and Peace, calculate PI to 50 places, tour the country, whatever you desire. Compiling will take quite a bit of time.

Inside the Firestorm source folder, you will find a folder named build-vc120-<architecture>, with <architecture> either being 32 or 64, depending on what you chose during the configuration step. Inside the folder is the Visual Studio solution file for Firestorm, called Firestorm.sln.

• Double-click Firestorm.sln to open the Firestorm solution in Visual Studio.
• From the menu, choose Build → Build Solution
• Wait until the build is finished

Older versions of the viewer before the merge of Linden Lab's project Alex Ivy use Autobuild 1.0 that is incompatible with the build process as it is now. By default it is not possible to install two different versions of Autobuild on the same computer at the same time. Making use of virtualenv will overcome this problem, allowing simultaneous installations of Autobuild 1.0 and Autobuild 1.1 in two distinct “virtual” Python environments.

Install virtualenv by opening a Windows command prompt and enter:

pip install virtualenv

This requires the Boostrip pip already installed. After virtualenv has been installed, you can create virtual Python environments using the command

virtualenv <virtual-environment-name>

This will create the directory <virtual-environment-name> within the Python installation folder and add some required folders and files. Among these files is a batch file called activate.bat in the folder Scripts. To switch to the newly created virtual environment execute the activate.bat batch file. After switching to the virtual environment, your command prompt will be prepended by the name of the virtual environment.

In this example we will create a virtual environment called “Autobuild11”:

virtualenv Autobuild11
c:\Python27\Autobuild11\Scripts\Activate.bat

Your command prompt should look like this now:

(Autobuild11) C:\

After you switched to a particular virtual environment, you can now install as described in Set up Autobuild and Python.

Complete example:

virtualenv Autobuild11
c:\Python27\Autobuild11\Scripts\Activate.bat
pip install hg+http://bitbucket.org/lindenlab/autobuild-1.1#egg=autobuild

Configuring and building the viewer from the Windows command line is basically identical as described in Building from the Windows command line with the difference that you now have to call the activate script first:

c:
\Python27\Autobuild11\Scripts\Activate.bat
cd \firestorm\phoenix-firestorm-lgpl
autobuild configure -c ReleaseFS_open -- --fmodstudio --package --chan MyViewer -DLL_TESTS:BOOL=FALSE
autobuild build -A 64 -c ReleaseFS_open --no-configure

If you plan to build the viewer from within Visual Studio, you will have to configure the viewer the same way as if you were to build from the Windows command line:

c:
\Python27\Autobuild11\Scripts\Activate.bat
cd \firestorm\phoenix-firestorm-lgpl
autobuild configure -c ReleaseFS_open -- --fmodstudio --package --chan MyViewer -DLL_TESTS:BOOL=FALSE

To be able to build from Visual Studio, you will have to set a Windows environment variable called VIRTUAL_ENV pointing at the virtual Python environment to use, in our example “C:\Python27\Autobuild11”. Now open the Firestorm Visual Studio solution to start Visual Studio and build the viewer.

NOTE: Setting the VIRTUAL_ENV environment variable only has an effect if building a version greater or equal than 53671! If you plan to build older versions of Firestorm, it is advised to install Autobuild 1.0 as the default Autobuild version and create a virtual environment for Autobuild 1.1!

In general, Nvidia graphics cards and drivers work very well with Second Life.

This issued occured with nVidia driver 378.49, when Advanced Lighting Model is disabled, on 64-bit viewers only.

Bug is fixed with nVidia driver 378.66 or newer.

Refer to this JIRA issue for more information.

Recent Nvidia updates, including driver version 381.65, may prevent Firestorm from launching. The crash is reported to occur on the “Detecting Hardware” step.

To solve this,

1) Try disabling Shadowplay in your Nvidia settings.

2) If this does not work, roll back to the last driver that worked for you. Be sure to completely uninstall the recent driver before installing the older one.

See also this page.

If you have Nvidia Shadowplay installed, disable it. Google “how to disable nvidia shadowplay” for instructions.

One user reports that on a recent Nvidia Experience version, turning off Share in the Settings menu disables Shadowplay without having to go through Windows controls.

There is a known Nvidia driver crash that occurs for some users on El Capitan and Sierra. See Mac El Capitan Nvidia Driver Crash and Mac Sierra Issues.

So you have the latest viewer and still can't see mesh - what's the deal?

Well, it isn't necessarily automatic. Depending on your specific hardware, certain settings that need to be enabled for mesh, may be set off by default.

Go to Preferences→ Graphics -> General; then enable Basic Shaders.

If this remains greyed out, then increase the level of Render Quality until Basic Shaders becomes enabled and can be checked.

Make sure you have a reasonable draw distance. If you have difficulty rendering mesh, lower it; if your draw distance is over 128, set it to 128, or less. (The optimal value for draw distance is entirely dependent on your own hardware; you will need to experiment to find what works best for you.)

In some cases, worn mesh attachments will not render properly still. Go to Preferences→ Graphics -> Rendering and disable both of the Alpha Mask Rendering options.

There are also rare instances of glitches where mesh that you are wearing appears worn by another avatar (yes, it is bizarre!). In that case, try going to Preferences → Graphics → General, and enable Hardware Skinning.

If you have Webroot SecureAnywhere Antivirus, see Webroot Issues. For other antivirus apps, see our Whitelisting Guide, and be sure to whitelist all parts of the viewer. This may need to be done from scratch each time you upgrade to a new version.

If mesh is simply slow to appear, but does appear eventually, that is not necessarily a problem with mesh itself; please work through this page: Slow Rezzing.

HTTP fetching may be overloading your router; please try the suggestions given here; if they do not help, revert the changes made then return to this page and continue.

If none of the above work - and make sure you try all of them first! - then in the top menu bar, open Advanced → Debug Settings, type in Mesh2MaxConcurrentRequests and gradually decrease (not increase) the value. (If Advanced is not visible on the top menu bar, press Ctrl-Alt-D.) If it does not help, try increasing the value from the default. Under no circumstances should you increase this beyond 64. Please see this comment on a related JIRA ticket for an explanation of the possible drawbacks of increasing this setting. Additionally, we recommend returning it to default once the mesh you're trying to see is visible.

In most cases, this is due to the mesh item being made low LOD so as to reduce its land impact. You should never try to resolve this by increasing LOD above the maximum allowed in Preferences → Graphics → General (4), as that would result in greatly increased memory uses usually leading to a significantly increased rate of crashing. Rather, the issue is inherent in how the mesh item was made. So you either live with it, or replace the item.

This happens more frequently for those using ATI/AMD graphics and drivers, but has been seen occasionally with Nvidia graphics and drivers as well. Visit Graphics Glitches for ways to address this.

If you can see most mesh fine but a specific mesh item fails to render and/or displays a pyramid, triangle, or ducky when it's first worn or rezzed, then read on. This is caused by mesh that fails to load, and in many cases is a result of having too high a draw distance in the presence of a lot of complex mesh.

• Reduce draw distance significantly, then relog. That often clears the problem.
• If that doesn't help, reboot all your network hardware and then your computer.
• (If the problem occurs only on selected regions, it could simply be a symptom of region lag–see http://wiki.phoenixviewer.com/lag for information. In this case, there may be nothing you can do about it.)
• If this still doesn't help, then:

• Make sure you have hidden folders shown; see here. Then browse to:

• On Windows Vista, 7, 8 and 10: C:\Users[USERNAME]\AppData\Roaming\Firestorm or
  C:\Users\[USERNAME]\AppData\Roaming\Firestorm_x64
  (or use the environment variable %APPDATA% then drill down to the folder noted)
• On a Mac: /Users/[YOUR USERNAME]/Library/Application Support/Firestorm
• On Linux: ~/.firestorm
• In this Firestorm folder, open the folder that has the name of your affected account, e.g. whirly_fizzle
• Delete the files named texture_list_last.xml and texture_list_home.xml
• Login and see if the troublesome meshes then load.

• Back up your settings - see http://wiki.phoenixviewer.com/backup_settings
• Wipe your settings manually, as explained in http://wiki.phoenixviewer.com/fs_clearing_settings
• Log back in and see if the mesh renders correctly. If it does…
• Restore your settings (see the backup page above), then check the mesh again.

In Preferences → Graphics → General, make sure Basic Shaders and Hardware Skinning are enabled.

If certain mesh objects are invisible on Firestorm 5.0.11 on OpenSim grids, set the debug setting FSEnforceStrictObjectCheck to False. To change that setting, go to top menu, Advanced (Ctrl-Alt-D to enable Advanced, if it isn't), Show Debug Settings. Type in FSEnforceStrictObjectCheck, set to False, then close the DebugSettings window.
On OpenSim grids, mesh should never be uploaded using “Analyze”. Analyze should only be used on grids that support Havok.
On Firestorm 5.0.11, mesh uploaded with Analyze is likely to render invisible when FSEnforceStrictObjectCheck is set to true.
An in-depth discussion about this problem can be found here.

So you saved an outfit, but when you look in that outfit's folder, it's empty. This can happen now and then, and it's caused either by something you're wearing, or something you aren't wearing. That does tend to cover any and all possibilities, but it will be made clear in the solution below.

If you use RLVa there is a chance that it has restrictions that are interfering with the wearing or removing of items that can cause this empty outfit problem, so it is recommended that, temporarily, RLVa be disabled.

• Open Preferences → Firestorm → Extras
• At the top is Allow Remote Scripted Viewer Controls. If this is enabled (checked), uncheck it.
• If you had to uncheck this setting, click OK at the bottom and relog; otherwise, close Preferences.

In case the problem is caused by something you're wearing, it is recommended that you detach all objects and wear “default” body parts. The easiest and quickest way to accomplish this is to go to the Avatar menu > Avatar Health submenu and click Reset Default (male or female).

This may take a moment or two, depending on the availability of the asset server, your connection quality to the server, and your viewer performance. If it takes a long time, or appears to never happen, try relogging. If you had to relog for step 2 above, try going to a different region, such as Hippo Hollow.

If your avatar still doesn't change, there may be other issues, and the Bake Fail page may help resolve them.

There are two folders, at a minimum, that are involved in your avatar's appearance. The first is the Current Outfit folder. This folder contains links to all the items that you are wearing. If it contains a broken link, or a link not worn, this can cause an outfit save to fail. So, open that folder and delete any broken links, or links that are not shown as worn.

The second folder, in this case, is the outfit's folder itself. Being empty, it is recommended that you delete that folder now.

A third folder may be involved if you are having a particular kind of bake failure: the Lost & Found folder. Normally, Lost & Found contains only objects, linksets and coalesced object sets. If you find any wearables in that folder, delete them. If they are worn, take them off first, then delete. If you cannot detach these wearables, relog, or try going to a different region, such as Hippo Hollow.

At this point, you should be ready to create and save an outfit. For an extra measure of sanity, it is recommended that you relog now. But you don't have to; you can attempt step 5 without relogging. However, if it fails a relog may help.

To ensure that you only wear the items you want in your outfit, manually select and wear each item. Don't try wearing an outfit that you want to modify, as it may contain something causing the problem. Instead, wear one item at a time from that outfit; anything that may cause a problem may then self-identify.

Once you are wearing all you want for that outfit, try to save it again, then check the outfit's folder for content.

If you have identified an item that causes a problem, that item may be corrupt in the SL database. You can try wearing an different copy of that item, if you have a backup of it, or notify the creator of the problem.

This error is followed by a number, which indicates how many textures have been discarded. Once it appears, you'll find that other textures will fail to rez in, and in many cases, shortly after the error message appears, you will crash out.

This error tends to happen much more on the 32-bit versions of Firestorm, but is not totally unknown on 64-bit versions.

The message is fairly self explanatory; it means you have run out of available memory. Now some say, “But I have 16GB of RAM, isn't that enough?” Well, especially with 32 bit viewers, you won't be able to use all of that memory. Depending on your operating system, only 2 GB or 3 GB are available to the viewer.

Some also note that older versions of Firestorm never had this problem, that they never saw this message so it must be a new bug. It is correct that older versions didn't show this, but that doesn't mean that the problem didn't exist. Rather, no message was shown and you would simply crash. The addition of the message at least indicates what the problem is, and thus makes troubleshooting it easier: rather than trying a whole host of fixes which might be irrelevant, it is narrowed down to just a few.

This depends….

If you have been using Firestorm for some time, and only got this once, or rarely, then it probably happened because you were in a very graphics intensive location. The “fix” therefore is to lower draw distance before going to such places, and keep it low till you leave.

Be aware that the message, once it appears, will not simply go away; you will need to relog. This is advisable anyway as new textures will most probably fail to rez.

In that case, Firestorm is trying to use more memory than you have available (remember the 32 bit limitation mentioned above). You need to reduce memory usage. For example:

• If you have a 64-bit system and more than 4 GB of memory (RAM), you can try one of the 64-bit Firestorm versions. These are less subject to this kind of crashing. You can quickly check this information in the viewer by going to the Help Menu - About Firestorm.

• Preferences→ Graphics -> Hardware Settings→ Viewer Texture Memory Buffer - reduce by 128.
  ie, if it is current at 512, reduce to 384; if it is at 384, reduce to 256; if at 256, reduce to 128.
  Do not set below 128.

• Reduce your normal draw distance

• Preferences → Graphics → Hardware Settings → Enable OpenGL Vertex Buffer Objects - Disable this.

• Quick Preferences Reduce Maximum Complexity to 35,000 (default for low settings).

• Quick Preferences Reduce Max Avatars to 3 (default for low settings).

• Reduce your inventory size by boxing up items, clearing your trash and/or deleting old stuff. Also, do not open multiple inventory floaters unless you really have to.

• IMPORTANT: Do NOT do the following if you are using a 64 bit operating system!
  If you don't have the Advanced menu enabled, enable it with Ctrl-Alt-D. Then, Advanced → Debug Settings. Type in FSDestroyGLTexturesImmediately and set to TRUE.
  This is likely to use more bandwidth and mean textures that have previously loaded will go grey quickly when you look away, but it should reduce the frequency of crashes.