Posted in Developer Zone, Programming, Second Life, Viewers

Compiling the Firestorm Viewer

Last updated 24-Apr-2021

Extended instructions, tips, and ‘gotchas’ on how to compile and build Firestorm, a third-party Open Source viewer for use with Second Life by Linden Lab.

First published in February 2014, and regularly updated ever since.

NOTE: This article assumes that you are a competent software developer who is comfortable with C++ build environments and command consoles. Most people will have no need to build their own version of Firestorm from the source code.

Back in September 2010 I wrote about the pain of compiling your own Viewer and of the efforts of my friends Mariana and Forestaurora to try to write tutorials on doing it. Fortunately, things have moved on enormously since then and now it is fairly easy to do a private build. A majority of the work is in setting up your build environment.

After encountering and solving a few “gotchas”, I have successfully built Firestorm under Windows 7 64-bit, Windows 10,  and also under Ubuntu 16.04 LTS 64-bit and Ubuntu 17.04 64-bit.

I thought it was worth noting down the “gotchas” I encountered, which is what this article is about.  If it helps just one other person in short-cutting the issues I have had, then this article will have been worth writing.

Although this article is primarily about compiling Firestorm, it could prove useful for other third-party viewers too, although your mileage may vary.

Update: It’s worth noting that I originally wrote this page whilst the Firestorm build instructions were out of date and full of inaccuracies and omissions, and during that time this page was quite useful. However, now that they have been brought up to date my page is possibly a little less useful for Windows builds as the instructions are now very good and straightforward, however there is still some extra useful information here and I go into more detail on some things than the official build instructions do.

Setting up the build environment

Setting up your build environment is something you only need to do once. I will cover Windows and then Linux.


The follow section applies only to Windows builds.

The Firestorm build instructions are currently very accurate and straitforward and it’s unliley that you will need to refer back to the instructions on the official Linden Lab page too.

C++ Compiler

The build system now uses Microsoft Visual Studio 2017 (VC15), and the Firestorm build instructions have been recently updated to reflect this.

Prior to the switch to Visual Studio 2017, it was possible to have multiple versions of Visual Studio installed, and I used to use VS2013 for compilation and VS2019 as the IDE. However, this seems to no longer work and autobuild gets confused if you have more than one version of Visual Studio installed. In the end I had to uninstall all versions of Visual Studio apart from VS2017.


The build instructions say to download from but that link is to a version that requires Python3 and we want the Python2 version.

Instead you should download it from as that is the version for Python 2.7 which is the one we want.


As of Firestorm 5.1.1 (following the merge of Linden Lab’s project Alex Ivy), Firestorm now uses the Linden Lab version of autobuild. Previous to this it used NickyD’s version of autobuild which is incompatible.

If you previously used NickyD’s version, you must force an upgrade with the command

pip install git+ --upgrade

(ie. append --upgrade to the end of the install command).

CAUTION: Once you do this, you will no longer be able to build versions of Firestorm before the merge of Alex Ivy (so v5.0.x and before). However, the build instructions do mention how to get around this.


Do not install the GCC compiler or make / cmake. If you do then I have found that Firestorm won’t compile because it picks up Cygwin’s version of cmake rather than the one it needs, and they are not compatible with each other.

Linux (Ubuntu)

NOTE: These instructions are for building versions of Firestorm prior to the merge of Linden Labs’ project Alex Ivy. As such they are now very out of date and you cannot build the latest development branch of Firestorm with them. The official Firestorm instructions say that it is currently not possible and that they are working on it.
Also, I no longer do Linux builds so it is unlikely that I am going to maintain this section and may even remove it at some point.

The following has been tested with Ubuntu 16.04 LTS (64-bit) and Ubuntu 17.04 (64-bit), using the Firestorm 5.0.11 codebase. As mentioned above, they will not currently work with the latest code.

The only gotcha here is that there are several versions of the build instructions for compiling Firestorm under Linux. They are all subtly different, and look like a bit of a maintenance nightmare – someone isn’t keeping them in step.

I used the build instructions specifically for Ubuntu 16.04 64-bit, and I followed the build instructions to the letter. The only erroneous information in the instructions is occasionally they omit a “sudo” when it is needed.

It’s interesting to note that these instructions currently mandate gcc-4.7, however another version says gcc-4.8 and another says gcc-4.9.

I used a fresh install of Ubuntu 16.04 LTS running as a Virtual Machine (VM) under VirtualBox in order to verify the procedure, and it compiled without a problem with the vanilla build command in the instructions with gcc-4.7, as recommended.

I repeated the procedure with a VM of Ubuntu 17.04 and gcc-4.7, with the same results.

After installing gcc-4.9 and making it the default compiler with Ubuntu 17.04, I was not able to get a successful build. Trying gcc-4.8 was also unsuccessful. Downgrading to gcc-4.7 again then succeeded again.

Therefore I would conclude that you must use gcc-4.7, and not gcc-4.8 or above.

I would also conclude that Ubuntu 17.04 is fine to use and you are not limited to Ubuntu 16.04 LTS.

Update: I also tried this with Ubuntu 17.10 and can report that currently there is no g++-4.7 package available for this release, which means you cannot build Firestorm under 17.10 (or later) and should stick with 17.04 or 16.04 LTS for now.

Building the libraries

This applies to both Windows and Linux.

Most of the libraries that are required by a Viewer are pulled in automatically by autobuild, with the exception of FMod and KDU.

FMod (either FModEx or FModStudio) is the library that the Viewers use to play sounds. If you don’t have this library linked in, your Viewer will behave as if you have muted all sounds. The Windows build instructions detail how to build this library (and are also applicable to Linux builds), but do not tell you how to link it in. I will shortly mention how.

KDU (Kakadu) is a library that is to do with rendering JPEG2000 images. Unlike FMod, the build instructions do not say how to build this, but there is a mention that if you want to use it you must license it yourself and build it yourself. Currently a personal non-commerical license is US$250 which rules it out for me. Fortunately you do not need it as without it the Viewer just uses the OpenJPEG library instead which, although not as fast as KDU, is free.

The trouble is that the predefined build configurations have a bit of an “all or nothing” approach. If you build with ReleaseFS then it tries to link both FMod and KDU, and fails because KDU is missing. If you build with ReleaseFS_open then it uses neither and you are left with a muted Viewer, and also lacking Havok support. I’ll explain how to resolve this issue later on.


As mentioned above, it is not feasible to build KDU but it can be omitted.


FModStudio is the preferred FMod library to use as it is newer. It’s supported in Firestorm v5.1.1 onwards.

To build FModStudio, follow the instructions in the Firestorm build instructions for Windows. This also applies to Linux builds also.

You only need to do this once, as FModStudio rarely changes.

There is a bit of a problem, however; fmodstudio can no longer be downloaded without a login, so the build script instead tries to download it from a local IP address which is not accessible over the internet.
The script will fail to download the package, and then terminate with failure (possibly “curl: (7) Failed to connect to” or “curl: (28) Connection timed out after 300305 milliseconds“, followed by “ERROR: building configuration“). Either way it doesn’t work.

You must therefore get the libraries yourself.

You will need to go to the FMod website and create a login (if you don’t already have one) and then you can download FModStudio from the download area. Be sure to download the FMOD Studio API (aka FMOD Engine), not the FMOD Studio Tool.

Select the appropriate version from the droplist, and download the version appropriate for your operating system. For Windows, download the Windows version (not the Windows 10 UWP version).

You’ll then need to change the value of a variable called URL_BASE in the file

You need to change the value of URL_BASE to "file://" followed by the full path to where you put it, in URL format. So if, under Windows, you put it in C:\projects\3p-fmodstudio\ (which is where I put mine) then you change the value of URL_BASE to "file://C:/projects/3p-fmodstudio/"

Note that for building on Windows, you need to change backslashes to forward slashes, and you must include the trailing slash.

I’ve found that the standard build instructions don’t result in a 64-bit version of FModStudio, and cause a build error when building the 64-bit Windows version of Firestorm, so I would suggest adding the -A 64 build option as follows:

autobuild build -A 64 --all
autobuild package -A 64

As mentioned in the build instructions, note down the “wrote” and “md5” output values as you will need them later.


FModEx is an older FMod library, which was used in Firestorm v5.0.x and earlier. If building that codebase you will need these instructions, otherwise you should skip this section and use FModStudio instead.

You only need to do this once, as FModEx very rarely changes.

To build FModEx you will need to do the following:

Get the source code by executing the following command:

hg clone

There is a bit of an problem, however, just like with FModStudio (see above) – you must download the library yourself, because the script tries to download it from an IP address that is not publicly accessible.

You will need to go to the FMod website and create a login (if you don’t already have one). However, this will not grant you immediate access, as the FMod Ex project is retired and no longer accessible.

You must then send an email to support, stating your username and asking for access and explaining why (saying you want to build the Second Life Firestorm viewer was sufficient for me), and then they will then grant access and allow you to download the pre-built libraries.
[Credit: Many thanks to Zenny3D for telling me about this in the comments section]

You will have access to the current and all previous versions. As of the time of writing, the most recent version is v4.44.64 but the version you require is v4.44.61 so be sure to download that one.

Download the package appropriate for your targeted operating system.

You’ll then need to change the value of a variable called URL_BASE in the file

You need to change the value of URL_BASE to "file://" followed by the full path to where you put it, in URL format. So if you put it in /home/becca/projects/3p-fmodex/ (which is where I put mine) then you change the value of URL_BASE to "file:///home/becca/projects/3p-fmodex/" (note the 3 slashes!)

Now that you have the package, you can build it. The procedure for building is the same for both Windows and Linux.

From the 3p-fmodex source directory, simply execute the following commands.

autobuild build --all
autobuild package

When built, you will get an output similar to the following (although obviously the values will be different).

packing fmodex
wrote /home/becca/src/3p-fmodex/fmodex-44461-linux-201706151710-r24d.tar.bz2
md5 a1ea2bad2489718f49707e245cfc52a1

You will need these values later on.


Build parameters

I mentioned earlier on that the predefined build parameters are rather “all or nothing”. But it’s possible to work round this.

If you look at the file “.\scripts\” (where ‘.’ is the location of your Firestorm source code) you can see the parameters that are available.

Since there is no build parameter for “do not use KDU” we compile with the ReleaseFS_open target (since this does not include KDU) and then use the build parameters to add back in what we want.

First we want to include FMod in order to get sound, so we include the switch --fmodstudio (for FModStudio) or --fmodex (for FModEx). As mentioned earlier, you will want FModStudio unless building a really old version of the code.

Then, because doing an OpenSim build disables the Havok physics engine, we add --no-opensim to fix that.

For 64-bit builds we add -A 64

Finally, the build system lets you enable Advanced Vector Extensions (AVX), an explanation of which is beyond the scope of this article.

To enable AVX you add --avx to the configure command or for AVX2 you add --avx2 instead. The build will barf if you try to use both.

Choose carefully whether or not to enable AVX or AVX2, because if you run the resulting build on a CPU that does not support it then it will crash on startup.

Performing a build


    1. Open a command window in the location of your source folder.(Note: A standard Windows command prompt, not the VS2017 command prompt)
    2. Set up the VC15 build environment for 64-bit compilation, which I do with a batch file that executes the following commands
      pushd "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\"
      call vcvarsall amd64

      Note: This assumes that Visual Studio is installed on your c: drive. If you have it elsewhere then adjust as necessary. Also, the above commands must be executed in a batch file and not from the command line!

    3. Update autobuild.xml (or my_autobuild.xml if you are doing that) with the fmodstudio information.
      Note: You only need to do this the first time you do a build, or if you revert the file.
      (I use a batch file for this, which I show below).

      autobuild installables edit fmodstudio platform=windows64 hash=md5 url=file://wrote

      The values of md5 and wrote are the values output when you built FModStudio.

    4. Ensure that the AUTOBUILD_VSVER and AUTOBUILD_VARIABLES_FILE environment variables are set (this is a new requirement for v5.1.1 onwards)
    5. Execute the following command
      autobuild build -A 64 -c ReleaseFS_open -- --chan MY_CHANNEL --package --fmodstudio --no-opensim -DFS_UPGRADECODES='GUID1,GUID2' -DLL_TESTS:BOOL=FALSE

      (add in any other flags like --avx etc. that you wish, but read my caution on the use of --avx that I mentioned earlier)

      MY_CHANNEL is the name of your private build, eg. AwesomeSauce, which would result in a version of Firestorm that identifies itself as “Firestorm-AwesomeSauce”. If you omit this, it will use the name of your computer, prefixed by “private-“.
      Do not use spaces or punctuation!

      GUID1 and GUID2 are generated by, for example, the Visual Studio GUID Generator. Make sure to always use the same GUIDs per channel. They identify the installation for upgrades and installation.

      GUIDs should be in registry format, but without the curly braces, eg. FC4F6A13-04BF-4613-983A-0E6864FF44B0

      Note: You should use different GUIDs for GUID1 and GUID2

This should then build a 64-bit version of Firestorm for Windows that has sound.

You can either run the resulting executable directly for testing purposes, or else run the installer in order to install it properly.

I actually use a two step process, which is to configure then build, since that is more in keeping with the Firestorm build instructions.
eg. I have a batch file that does the following:

@echo off
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
call autobuild configure -A 64 -v -c ReleaseFS_open -- --chan Beccapet --package --fmodstudio --no-opensim -DFS_UPGRADECODES='********-****-****-****-************,********-****-****-****-************' -DLL_TESTS:BOOL=FALSE
call autobuild build -A 64 -v -c ReleaseFS_open --no-configure --verbose

my_autobuild.xml is a copy of autobuild.xml which I create with the following batch file:

@echo off
echo Copying autobuild.xml to my_autobuild.xml
copy autobuild.xml my_autobuild.xml /Y 
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
echo Updating FModStudio info...
setlocal EnableDelayedExpansion
pushd ..\3p-fmodstudio\
set FMODSTUDIO_HASH=6a9c0a72224e6f332925cb359ecdf898
set FMODSTUDIO_FILE=fmodstudio-2.01.08-windows64-210650145.tar.bz2
echo Hash:     %FMODSTUDIO_HASH%
echo File:     %FMODSTUDIO_FILE%
autobuild installables edit fmodstudio platform=%FMODSTUDIO_PLATFORM% hash=%FMODSTUDIO_HASH% url=file:///%FMODSTUDIO_LOCATION%\%FMODSTUDIO_FILE%

That copies the file, and then updates it with my FModStudio information that I mentioned earlier.



These instructions apply to Firestorm v5.0.x and have not yet been updated for later versions or tested with later versions.
Also, I don’t do Linux builds any more so am probably not going to maintain this section. I may even remove it some day.

  1. Open a terminal window in the location of your source directory.
  2. Update autobuild.xml with the fmodex information.
    Note: You only need to do this the first time you do a build, or if you revert the file.

    autobuild installables edit fmodex platform=linux hash=md5 url=file://wrote

    The values of md5 and wrote are the values output when you built FModEx.
    So in the example I posted earlier, this would be.

    autobuild installables edit fmodex platform=linux hash=a1ea2bad2489718f49707e245cfc52a1 url=file:///home/becca/src/3p-fmodex/fmodex-44461-linux-201706151710-r24d.tar.bz2

    (Note the three slashes! The first two are for file:// and then the third is the start of the path)

    Note: You need to specify an absolute path; relative paths don’t seem to work

  3. Execute the following commands
    autobuild -m64 build -c ReleaseFS_open -- --chan MY_CHANNEL --package --fmodex --avx

    MY_CHANNEL is the name of your private build, eg. AwesomeSauce, which would result in a version of Firestorm that identifies itself as “Firestorm-AwesomeSauce”. If you omit this, it will use the name of your computer, prefixed by “private-“.
    Do not use spaces or punctuation!

This should then build a 64-bit version of Firestorm for Linux that has sound and works in both Second Life and OpenSim.

Note: The above uses NickyD’s version of autobuild which uses -m64 for a 64-bit build and is not compatible with Linden Labs’ autobuild.

I have verified this by installing a resulting build on a bare metal Linux box running Ubuntu 17.04, an nVidia GTX 780, and the latest nVidia proprietary drivers, and it ran absolutely fine and as fast as the official Firestorm build. And, crucially, had sound.


Building the release viewer instead

All of the above instructions are for building the latest “bleeding edge” developer code from the trunk of the repository. However, if you want to play it safe and build the latest release branch, then it is possible to do so.

Under Mercurial, you needed a different URL but since the move to git, the release branch is an actual branch so just switch your local repo to that.

Parallel builds of pre- and post- Alex Ivy

Due to incompatibility issues between NickyD’s autobuild and Linden Lab’s autobuild, it’s not possible to build both pre-merge and post-merge branches on the same PC. The build instructions suggest getting round this by using virtualenv.

However, my aim is to have two different user accounts on Windows, one for pre Alex Ivy code and one for post Alex Ivy, using User environment variables, the User path, and per-user installs.

So far I have not achieved this, as a standard install of Linden Lab’s autobuild affects all users, and doing a per-user install with pip’s --user flag doesn’t yield an autobuild that works.

Now that the release branch is post Alex Ivy, I don’t propose to investigate this further.

However, I have confirmed that you can uninstall autobuild-1.1 again with the command

pip uninstall hg+

and that NickyD’s autobuild can be used again. If you don’t switch between builds that often, it could be a solution.


My build instructions result in an OpenSim-compatible Firestorm that uses OpenJPEG but also links in FModEx or FModStudio, giving a Firestorm that connects fine to Second Life and has sound. Exactly what I want. The lack of KDU doesn’t make it noticeably slower for me, but I do have a powerful PC so your mileage may vary.

Although the above looks a little daunting, most of the work is in setting up your build environment, and it’s not as bad as it looks.

One slightly annoying aspect of switching between the installed Firestorm and the private build one, is that it seems to clear my cache. That means that every time I switch between them, I rezz as a cloud and have to wait ages for my inventory to load. I haven’t found a way round this yet, although I’m sure one exists. In the meantime it’s something to be aware of.

Anyway, I hope that this post has been useful to someone.

Links and Further Reading

Get source and compile – Official Second Life Viewer build instructions
Firestorm Windows build instructions – build instructions tailored for Windows builds.
Firestorm 64-bit Ubuntu 16.04 build instructions – build instructions tailored for Ubuntu 16.04
Compiling Firestorm Viewer – a top-level page for all platforms

32 thoughts on “Compiling the Firestorm Viewer

  1. What advantage would I gain with a personal build? Can I tweak options and remove limits in debug settings if I build my own? Can I completely remove features I don’t use? Will that “break” the build. If I remove features do I gain some performance? How do we make the custom tweaks? Are there tutorials available for Noobs?

    1. The main advantage is being able to apply your own code changes. On my personal build, you don’t slump when you go AFK, don’t go AFK when minimised, and snapshots to disk are named with the date and time in the filename.

      To make changes, you need to be proficient in the C++ programming language. There are many tutorials around, but it is not a beginners programming language and the learning curve would be pretty steep.

      1. Well that’s me out of the loop then unless there are people who do “requests” for a build with the specific features you want. Would that be matter of deleting code rather than “additions” in most cases? Is that easier?

        1. To be honest, there would be no advantage in removing stuff. For a start, it would be hard for you to know what to remove without breaking something. And the end result wouldn’t give you any advantage as it would be compiled without Kakadu.
          Best bet would be to put a Feature Request in to the Firestorm team if there is a specific feature you want.

          1. My request would be to remove features I don’t need actually. I’m guess that would be a performance gain since the V1 UI seems to be faster than V3 UI. If you remove anything to do with features that are using bandwidth would help (chat and any media or audio for example?).

          2. You’d probably need to take that up with one of the Third Party Viewer teams such as Firestorm, Kokua, Niram, etc.

  2. Hello Becca, just wanted to let you know how to go about grabbing FMOD Ex for windows (Or any platform, really). All you have to do is sign up on and contact support at asking for access to the FMOD Ex downloads. They will ask you what you want to use it for, or you can blatantly specify in your request email as I did. They got back to me within a few days. You can then find your downloads at under the “FMOD Ex” tab, category “FMOD Ex API”. Hope this helps!

      1. I have a question myself, now. Maybe you can help place me in the right direction since I’m not entirely a buff in bash files and google it is so ambiguous I can’t help myself. I’m autobuilding fmod right now, and so far I’ve gotten it to work right up to the very last line of , which is “pass”. Cygwin has no installable package named “pass”, there is no “pass.exe” in cygwin’s bin folder, and google has no idea what it is either. Running autobuild package doesn’t work because autobuild-package.xml is missing at this point, so I assume “pass” needs to complete. Any idea what this line accomplishes or how to fix it? Thanks.

        1. I didn’t use Cygwin’s build environment. I suspect you have installed the full development tools of Cygwin and you are picking up the Cygwin version of cmake and autobuild, rather than the Linden Labs’ / Phoenix Firestorm one. I mentioned this as a “gotcha” in the Cygwin section.

          If it’s not that then I’m afraid I don’t know. 🙁

      2. I’m using LL’s autobuild. Are you saying there’s a version of it for firestorm instead? Cygwin is not conflicting as far as I’m aware, just that pass is not a command that exists on my system. Maybe I can just rewrite it to accomplish the same thing without pass. Or rename the files myself.

      3. No, I don’t think there is a specific version of autobuild from Firestorm – I’m pretty sure it uses the LL version. It does sound like it is picking up something it should not though. I didn’t experience the issue that you are having and I don’t know how to resolve it I’m afraid. 🙁

      4. After about 11 hours of hardships and torment, I’ve finally gotten a complete build. I will admit most of my problems came from a minor discrepancy between LL’s guide and Firestorm’s. It seems LL uses their own autobuild here (or where as firestorm (and your guide) works with . Note that only NickyD’s autobuild has -m64 as an argument. The rest have -A 64 which will not compile firestorm correctly. Possibly my fault, but just writing it here in case anyone has similar issues. Thanks to your guide for helping me along the way!

      5. I’ve updated the article with the new info in these comments – specifically on getting the FModEx libraries and also on the caveat about autobuild. Thank you so much for taking the time to share – I really appreciate it. ♥

  3. Hi beccapet, I’ve been following your guide, thanks a lot! I’m having a python issue though after running autobuild configure -c ReleaseFS_open which will configure Firestorm to be built with all defaults and without third party libraries according to the guide, not sure if this text area is appropriate for this python error log format:
    Warning: no –id argument or AUTOBUILD_BUILD_ID environment variable specified;
    using a value from the UTC date and time (183410640), which may not be uniqu
    ‘bash’ ‘../scripts/’ ‘–config’ ‘–version’ ‘–opensim’ ‘
    –version’ ‘–platform win32’ ‘–chan’ ‘MyViewer’ ‘-DLL_TESTS:BOOL=FALSE’
    Traceback (most recent call last):
    File “c:\python27\lib\”, line 174, in _run_module_as_main
    main“, fname, loader, pkg_name)
    File “c:\python27\lib\”, line 72, in _run_code
    exec code in run_globals
    File “C:\Python27\Scripts\”, line 9, in
    File “c:\python27\lib\site-packages\autobuild\”, line 263, in
    File “c:\python27\lib\site-packages\autobuild\”, line 250, in
    File “c:\python27\lib\site-packages\autobuild\”, li
    ne 105, in run
    File “c:\python27\lib\site-packages\autobuild\”, li
    ne 158, in _configure_a_configuration
    return configure_executable(extra_arguments, environment=environment)
    File “c:\python27\lib\site-packages\autobuild\”, line 104, in c

    return, env=environment)
    File “c:\python27\lib\”, line 168, in call
    return Popen(*popenargs, **kwargs).wait()
    File “c:\python27\lib\”, line 390, in __init__
    errread, errwrite)
    File “c:\python27\lib\”, line 640, in _execute_child
    WindowsError: [Error 2] The system cannot find the file specified

    I’m using Windows 7 64 bit, and that free Community edition of VS2013 also I’m using python 2.7.14 and just to make sure I checked python version in Command Prompt by typing: python –version and that shows Python 2.7.14 it’s all fine but why I’m getting python issues?

    1. Updating…. I could fix that by running commands through the Cygwin64 terminal instead of Command Prompt windows, I got same error related to python though but that came up near the end of the process compilation, so if someone is having same issues try to compile on Cygwin64 terminal! Thanks.

    2. Hmmm. That’s odd. I don’t get that issue. Have you set up the build environment correctly as per the FS build instructions?
      Also, have you upgraded your autobuild to the LL version? NickyD’s version is no longer compatible.

  4. Hi beccapet, I figured out that the way to fix all those issues is by running the Cygwin64 terminal from the C:\cygwin64\bin\mintty directory I was running by the C:\cygwin64\Cygwin so I still got that python issues, anyway runnin by the mintty file I could get a successfully build! Everything working fine, no error logs, but when I used the repository I couldn’t run my build after finished I got an error related to settings xml etc,. but using repository instead so that works just fine for me, and my autobuild version is 1.1.7 I guess it’s up to date isn’t it?

    1. I’m afraid I don’t know what you are doing different then. I’ve got this to compile fine on a clean install of Win7 Pro by just following the build instructions, so you must have missed something.

      1. Hi beccapet, I will ask you something which is not related to this topic. I’ve been searching for a chatbot lsl script but I couldn’t find a good one, by searching on google I just find Racter script and others based on notecards which is deprecated. Long time ago I had a chatbot script that was based on machine learning which is pretty good, that was basically 3 scripts, 1 for the main engine and the rest as memory extensions, you know where to find something like that? Perhaps you have something similar to share?

  5. Hi beccapet, third party libraries such as kdu, fmodex, fmodstudio are preset in the autobuild.xml right? So I wonder how to set new ones, either through autobuild.xml or VS2013, is it possible? I tried some c++ external libraries by importing dependencies to VS2013 Firestorm.sln project, but it failed to compile, you have a tutorial for this?

    1. Hi. I have actually done this for my private build, but did it using the CMake files.
      Ultimately I would like to work out how to do it with autobuild.xml which is why I have never blogged about it.

      1. Thank you beccapet, using CMake files it seems a workaround for me, even though I’m not familiar with CMake but I guess it has something to do with CMakeLists.txt, by looking into \firestorm\phoenix-firestorm-lgpl there’re a lot of CMakeLists.txt though, which one should I edit? Is the following commands a proper use for it: INCLUDE_DIRECTORIES for header location and LINK_DIRECTORIES + TARGET_LINK_LIBRARIES for libraries? How did you manage to do such a thing?

  6. Hi. When build fmodstudio show this error: “”cp -dR –preserve=mode,timestamps api/core/lib/x64/fmodL_vc.lib /cygdrive/c/firestorm/3p-fmodstudio/stage/lib/debug
    cp: cannot stat ‘api/core/lib/x64/fmodL_vc.lib’: No such file or directory””. Can you help me?

    1. Hi arturo. Sorry for the slow reply.

      Hmmm, that’s an odd one. It looks like something isn’t configured correctly but I’m afraid I don’t know what. Sorry I can’t be more helpful. 🙁

      1. Do not worry, I already solved the problem. The guide was very useful for me. Thank you!

        I would like that the viewer will not have the name of Firestorm but rather a custom name. How could I do it?

  7. I’ve previously built Firestorm on Ubuntu 16.04 LTS, and made some improvements in the region crossing area. Now I’m on Ubuntu 18.04 LTS, and your comments above suggest that there’s no version of GCC which both works under 18.04 LTS and will compile Firestorm. (The PPA of obsolete toolchains agrees:

    This ( says to use GCC 4.9.

    GCC 4.8, though, is a standard package for Ubuntu 18.04 LTS. That’s what I used to build Firestorm two years ago on 16.04 LTS. Will that work?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.