Second Life Wiki - User contributions [en]

LlAtan2

2011-05-03T18:14:09Z

Zidan Foxdale:

{{LSL_Function
|func_id=3|func_sleep=0.0|func_energy=10.0
|func=llAtan2|sort=Atan2
|p1_type=float|p1_name=y|p1_desc
|p2_type=float|p2_name=x|p2_desc
|return_type=float
|return_text=that is the {{wikipedia|Atan2|arctangent2}} of '''y''', '''x'''.
|func_footnote=Similar to the <span class="plainlinks">{{wikipedia|Inverse_trigonometric_functions|arctangent}}</span>('''y'''/'''x''') except it utilizes the signs of '''x''' & '''y''' to determine the quadrant and avoids division by zero. Returns zero if '''x''' and '''y''' are zero, returns '''PI/2''' if '''x''' is zero and '''y''' is positive, returns '''-PI/2''' if '''x''' is zero and '''y''' is negative.<br />
The returned value is in the range {{Interval|gte=-[[PI]]|gteh=-PI|lte=PI|center=return}}{{Interval/Footnote}}.
|spec
|caveats
|constants
|examples=<lsl>default
{
state_entry()
{
float num1 = llFrand(100.0);
float num2 = llFrand(100.0);

llOwnerSay("y = " + (string)num1);
llOwnerSay("x = " + (string)num2);

llOwnerSay("The arctangent of y divided by x is " + (string)llAtan2(num1, num2));
}
}</lsl><lsl>//Function with input of a vector determining the position of a target and returning
//a string with the literal compass-direction of that target towards your position
//by Ramana Sweetwater 2009/01, any use allowed license :-)
//corrected by Patrick Muggins

string compass (vector target)
{
vector source = llGetPos();
list DIRS =["W","NW","N","NE","E","SE","S","SW","W"];
integer index = llCeil(3.5 - (4 * llAtan2(target.y - source.y, target.x - source.x) / PI));
return llList2String(DIRS, index);
}</lsl>
[[/Compass QA]]
|helpers
|also_functions=
{{LSL DefineRow|[[llSin]]|[[llAsin]]|sine & inverse Sine}}
{{LSL DefineRow|[[llCos]]|[[llAcos]]|cosine & inverse cosine}}
{{LSL DefineRow|[[llTan]]||tangent}}
|also_articles=
{{LSL DefineRow||{{wikipedia|Atan2}}|}}
{{LSL DefineRow||{{wikipedia|Inverse_trigonometric_function}}|}}
|notes
|cat1=Math/Trigonometry
|cat2
|cat3
|cat4
}}

Microsoft Windows Builds

2010-10-18T19:14:29Z

Zidan Foxdale: /* Fmod */

{{multi-lang}}
{{CompileNav}}

On Windows, there are several options on build (compile) environment of the Second Life.

This page explains how you can compile the Viewer on Microsoft Windows.

Currently, only 32 bit binary is tested. There seems to be several trials to produce 64 bit Windows .EXE of the Viewer. If you did, please write your experience on [[Talk:Microsoft Windows Builds|the discussion page]] (regardless it was successful or not!)

== Choosing and preparing a compiler ==

=== Linden-supported compilers ===

Supported compiler: '''Visual Studio .NET 2005 Professional'''

You need to setup the compiler and Microsoft Development tools as follows:
* Setup [[Microsoft Visual Studio]]

=== Community experimental compilers ===

If you don't have Visual Studio .NET 2005 Professional, you may wish to try one of the following alternatives.

* Visual C++ 2005 Express ([[Microsoft Visual Studio|instructions]], but the screenshots for [[Compiling the Viewer (MSVS2008)|VS2008]] are worth a glance too)
* Visual Studio 2008 ([[Compiling the Viewer (MSVS2008)|instructions]])
* Visual C++ 2008 Express ([[Compiling the Viewer (MSVS2008)|instructions]])

{{Warning|Boost support with Visual Studio 2008 is problematic as of this writing. Check {{jira|VWR-9541}} before continuing on this path.}}

NOTE: Make sure you install to paths without spaces in it.

== Getting other development tools ==

You will need to install the following tools to compile the Viewer:
* '''UniCode NSIS'''([http://www.scratchpaper.com/home/downloads download Unicode NSIS])
** This is the package installer used to build Setup.exe. <b>Note</b>: As of this writing the file is downloaded with an *.exec extension that needs renamed *.exe.--[[User:Nicky Perian|Nicky Perian]] 16:22, 30 March 2010 (UTC)
* '''CMake''' ([http://www.cmake.org/HTML/Download.html download CMake])
** As of this writing, the latest version is 2.6.2. <b>Note</b>: There are many known issues with CMake 2.6.0 and 2.6.1 in conjunction with building the Second Life Viewer. CMake 2.4.8 is supported for compiling the 1.21 version of the Second Life Viewer, but 2.6.2 is likely to become the new minimum requirement in the near future.
* '''Cygwin''' ([http://www.cygwin.com/ download Cygwin])
** When you run the cygwin setup utility make sure you have selected to install '''patchutils''', '''flex''', '''bison''', and '''zlib-devel'''(all located under "devel"), '''openssh''' (located under "Net"), which are not part of the default install. (If you missed one of these, the easiest thing to do is to re-run the entire installation.)
* '''Python''' (download either [http://www.python.org/download/ Python.org Standard Python] or [http://www.activestate.com/Products/ActivePython/?mp=1 ActivePython]
** 2.4.3 is the minimum required version.
** If you are using a version of Python newer than v2.5, you may need to change the Python.cmake file. See the [[Talk:CMake#CMake_and_Python_2.6|CMake discussion]] for details (this change was necessary as of 1.21-r99587 source branch). )
* '''The Windows Platform SDK'''
** Get the latest version (as of 23 March 2010) here: [http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=c17ba869-9671-4330-a63e-1fd44e0e2505&displayLang=en Windows SDK for Windows Server 2008 and .NET Framework 3.5 SP1] (If you use the web installer, you can choose only the "Development Tools" and cut the download size significantly.)
* '''DirectX 9.0 SDK'''
** Get the latest version (as of 29 Oct 2008) here: [http://www.microsoft.com/downloads/details.aspx?FamilyID=ea4894b5-e98d-44f6-842d-e32147237638&DisplayLang=en DirectX 9.0 SDK (August 2008)]

Verify that Cygwin, CMake, and Python are in the windows "PATH".

'''NOTE:''' '''DO NOT''' use the Cygwin version of CMake or Python. The Build will fail. (CMake specifically excludes the Cygwin version of Python, in the <code>'Python.cmake'</code> file)

== Downloading Source Code ==

You can download the Viewer source code on the [[source downloads]] page. You can also use a [[version control repository]]. If you're just starting out, it's probably best to get the latest Release version, rather than a Release Candidate, because the Release Candidates get updated quite often. But if you would rather work with the latest code, go for the [[version control repository]] "trunk". Don't forget to also download the artwork and library bundles relevant to the repository branch you're using as explained in [[Version_control_repository#Artwork_and_Library_Bundles|Artwork and Library Bundles]].

If you're downloading from the [[source downloads]] page, there are three packages to get: the source package, the artwork package, and the library package. In versions 1.20 and earlier, Linden packaged the library binaries in the Libs package. For 1.21 and beyond, the CMake develop.py script now downloads '''most''' of the libraries that were previously in the libs zip file. This saves developers who are tracking trunk from constantly downloading them every update and only downloads updated libraries. As of this writing, there are some pieces packages that still require downloading, so be sure to grab the library and artwork bundles from the [[source downloads]] page.

'''WARNING:'''
* If the directory path you keep the SL source in has a space in it, the batch file that copies message_template.msg will fail. So, if you unzip or checkout the source tree into, e.g., "C:\Projects\Dir with space in name\Etc\linden", it won't work!
* You should also avoid using non-ASCII (national) characters in the paths, although some localized versions of the tool puts some as a default...
* Unzip or checkout your source tree into a directory that has as short full pathname as possible, since long paths cause some unexpected trouble during the build.

In other words, the easiest way to get this working is to get '''source''', '''artwork''', and '''libs''' from the [[source downloads]] page and unpack them all into the same directory/folder, which ideally would be a folder in (or near) the root directory with a short name like '''sl_1_21_6'''.

== Installing libraries ==

SL Viewer depends on some third party libraries. Some of them are open source, some others are not.

=== Open source libraries ===

As of Viewer version 1.21, all open source libraries are automatically downloaded as part of the build script invoked by develop.py, unless you choose to configure a standalone build.

=== Proprietary libraries ===

Linden Lab does not provide proprietary libraries. You will need to follow the instructions here under to acquire and copy them to your source tree.

It's probably a good idea to build an empty directory tree for those files, copy the relevant proprietary files there and, once done, copy the whole to your source tree (like ''XCOPY OLIB SL_1_16_0_5 /S''). The reason is that these steps are cumbersome and will have to be repeated for each new release (at least if you keep the source for each release in its own folder). If you do not want to do this, you can just as well copy the files directly into the linden source paths.

rem OLIBS.CMD to build a folder tree for 3rd party libraries and includes
md olibs
md olibs\linden\
md olibs\linden\libraries
md olibs\linden\libraries\include
md olibs\linden\libraries\i686-win32
md olibs\linden\libraries\i686-win32\lib_release
md olibs\linden\libraries\i686-win32\lib_debug
md olibs\linden\libraries\i686-win32\include
md olibs\linden\libraries\i686-win32\include\GL
md olibs\linden\libraries\i686-win32\include\quicktime
md olibs\linden\indra
md olibs\linden\indra\newview

==== Fmod ====
* Download & extract [http://www.fmod.org/files/fmod3/fmodapi375win.zip FMOD3.75 API for Windows]. (later versions, like FMOD Ex, are incompatible).
* Copy "fmodapi375win\api\inc\fmod.h" to "linden\libraries\include"
* Copy "fmodapi375win\api\inc\fmod_errors.h" to "linden\libraries\include"
* Copy "fmodapi375win\api\inc\fmoddyn.h" to "linden\libraries\include"
* Copy "fmodapi375win\api\lib\fmodvc.lib" to "linden\libraries\i686-win32\lib_release" and to "linden\libraries\i686-win32\lib_debug"
(If using cmake, copy "fmodapi375win\api\lib\fmodvc.lib" to "linden\libraries\i686-win32\lib\release" and to "linden\libraries\i686-win32\lib\debug")
* Copy "fmodapi375win\api\fmod.dll" to "linden\libraries\i686-win32\lib\release" an "linden\libraries\i686-win32\lib\debug"

==== Quicktime ====

Currently - as of version 1.21 - CMake requires Quicktime to be installed.

'''Note:''' This download requires a registration at the Apple Quicktime website and take a bit of time. You can avoid using QuickTime if you want, see [[Compiling_older_Viewers_(1.20_and_earlier_with_MSVS)#QuickTime_removal|this]] for details. Remember that your Viewer '''can't play in-world movies''' if you do so.
* Download & install the [http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/11.1.17.2.1.3.3.1.0.1.1.0.3.11.3.3.1#main Quicktime SDK for Windows]
* Copy "QuicktimeSDK\Libraries\QTMLClient.lib" to "linden\libraries\i686-win32\lib_release" and to "linden\libraries\i686-win32\lib_debug".

(If using CMake, copy "QuicktimeSDK\Libraries\QTMLClient.lib" to "linden\libraries\i686-win32\lib\release" and to "linden\libraries\i686-win32\lib\debug" instead)

* Copy the contents of "QuicktimeSDK\CIncludes" into "linden\libraries\i686-win32\include\quicktime".

== Building the Viewer ==

At this point, you should be ready to use [[CMake]] to build the Visual Studio solution for the project.

'''NOTE''': CMake is only supported for Viewer versions 1.21 and beyond.

Before you first run a build, you'll need to configure things. It is recommended that you use the <code>develop.py</code> script that will create a default configuration for you.

You must make sure that cmake is registered in the Windows environment or you will get strange errors from develop.py. To ensure everything is correct, right click My Computer -> Properties -> Advanced -> Environment Variables -> Inside System Variables, choose PATH (case insensitive) and click Edit. Now in the value field, go to the end of the value and add a semicolon (;), and then the folder containing the CMake binaries (example: C:\Program Files\CMake 2.8\bin). This might already have been set by the CMake installer.

From the command line, navigate to the indra folder of your source tree and run:

python develop.py

CMake will pick the most recent version of Visual Studio we support. If you want to specify the version of Visual Studio to use.

* VisualStudio 2005:

python develop.py -G VC80

* VisualStudio 2008:

python develop.py -G VC90

'''NOTE:''' The above commands will configure a "non-standalone" version of the source code tree. This means that the required third party library packages (as built by Linden Lab) will be downloaded during the CMake process.

=== Finding your build directory ===

In the CMake world, we keep source and object files separate. The <code>develop.py</code> script did create and populate a build directory for you. It is in one of the following locations:
* VS 2005: <code>'indra/build-vc80'</code>
* VS 2008: <code>'indra/build-vc90'</code>

=== Compiling ===

To start a build, do one of the following:
* Run <code>python develop.py build</code> from the indra directory.
** '''NOTE FOR VS 2008 USERS:''' This command will not work, since it will only look for VS 2005. Instead, run the command <code>python develop.py -G VC90 build</code>
* Load the Visual Studio solution into your IDE. For MSVS VC++:
** Use "File -> Open -> Project/Solution", and open the linden/indra/build-VC80/SecondLife.sln solution file
*** '''NOTE FOR VS 2008 USERS:''' Even though a build-VC90 was created in the above steps, developer.py places the VS 2008 solution/project files in the indra directory. Don't move them to build-VC90 - the paths in the project files are relative to the indra directory.
** In the MSVS toolbar, just to the right of the triangular "Start Debugging" arrow, is a text box whose tooltip is "Solution Configurations". Select RelWithDebugInfo.
** If ALL_BUILD is not set as your StartUp Project (the StartUp Project is displayed in bold font), right-click on ALL_BUILD and choose "Set as StartUp Project".
** Right-click on ALL_BUILD and choose "Properties". In "Configuration Properties -> Debugging", find "Working Directory" and navigate to "linden\indra\newview".
** (For Snowglobe 1.x) In the Solution Explorer pane, right-click on the project named "prepare" and select Project Only -> Build Only prepare. This downloads and installs precompiled libraries and only needs to be done when the source tree is clean or if libraries in the list included in the source tree get updated. Running this when not required is brief and causes no harm.
** Build -> Build Solution (F7)
** Debug -> "Start Debugging" or "Start without debugging".
** MSVC might not be able to find the executable. If not, point it to "linden\indra\build-VC80\newview\relwithdebinfo\secondlife-bin.exe", and try again.
** You may see an error due to not being able to find fmod.dll. If so, find a copy (remember, you copied this in a step above) and copy it into "indra\build-VC80\newview\relwithdebinfo". Try again.
** You may see an error due to not finding llkdu.dll. If so, find it in the normal installed version (make sure it's the same version as your source) and copy it into "indra\build-VC80\newview\relwithdebinfo". Try again.
** Good luck!

=== Where's the built Viewer? ===

On Windows, the built Viewer ought to run from VS2005.

To run outside MS VS, see Discussion tab:
[[Talk:Microsoft_Windows_Builds#Running_Viewer_outside_of_MS_VC]]

=== Build instructions for 1.20 and earlier ===

See [[Compiling older Viewers (1.20 and earlier with MSVS)]] if you'd like to compile a version of the Viewer older than 1.20.

== What to do if it doesn't work for you ==

* Ask for help on [[IRC]] (irc.freenode.net #opensl)
* Find someone on the [[OpenSource-Dev|OpenSource-Dev mailing list]]
* Fix it: [[Modifying CMake Files‎]] (and please, submit a patch!)

Please also see the (user contributed) instructions at [[User:Michelle2_Zenovka/cmake]]

[[Category:Compiling viewer]]

Microsoft Windows Builds

2010-10-16T02:23:44Z

Zidan Foxdale:

{{multi-lang}}
{{CompileNav}}

On Windows, there are several options on build (compile) environment of the Second Life.

This page explains how you can compile the Viewer on Microsoft Windows.

Currently, only 32 bit binary is tested. There seems to be several trials to produce 64 bit Windows .EXE of the Viewer. If you did, please write your experience on [[Talk:Microsoft Windows Builds|the discussion page]] (regardless it was successful or not!)

== Choosing and preparing a compiler ==

=== Linden-supported compilers ===

Supported compiler: '''Visual Studio .NET 2005 Professional'''

You need to setup the compiler and Microsoft Development tools as follows:
* Setup [[Microsoft Visual Studio]]

=== Community experimental compilers ===

If you don't have Visual Studio .NET 2005 Professional, you may wish to try one of the following alternatives.

* Visual C++ 2005 Express ([[Microsoft Visual Studio|instructions]], but the screenshots for [[Compiling the Viewer (MSVS2008)|VS2008]] are worth a glance too)
* Visual Studio 2008 ([[Compiling the Viewer (MSVS2008)|instructions]])
* Visual C++ 2008 Express ([[Compiling the Viewer (MSVS2008)|instructions]])

{{Warning|Boost support with Visual Studio 2008 is problematic as of this writing. Check {{jira|VWR-9541}} before continuing on this path.}}

NOTE: Make sure you install to paths without spaces in it.

== Getting other development tools ==

You will need to install the following tools to compile the Viewer:
* '''UniCode NSIS'''([http://www.scratchpaper.com/home/downloads download Unicode NSIS])
** This is the package installer used to build Setup.exe. <b>Note</b>: As of this writing the file is downloaded with an *.exec extension that needs renamed *.exe.--[[User:Nicky Perian|Nicky Perian]] 16:22, 30 March 2010 (UTC)
* '''CMake''' ([http://www.cmake.org/HTML/Download.html download CMake])
** As of this writing, the latest version is 2.6.2. <b>Note</b>: There are many known issues with CMake 2.6.0 and 2.6.1 in conjunction with building the Second Life Viewer. CMake 2.4.8 is supported for compiling the 1.21 version of the Second Life Viewer, but 2.6.2 is likely to become the new minimum requirement in the near future.
* '''Cygwin''' ([http://www.cygwin.com/ download Cygwin])
** When you run the cygwin setup utility make sure you have selected to install '''patchutils''', '''flex''', '''bison''', and '''zlib-devel'''(all located under "devel"), '''openssh''' (located under "Net"), which are not part of the default install. (If you missed one of these, the easiest thing to do is to re-run the entire installation.)
* '''Python''' (download either [http://www.python.org/download/ Python.org Standard Python] or [http://www.activestate.com/Products/ActivePython/?mp=1 ActivePython]
** 2.4.3 is the minimum required version.
** If you are using a version of Python newer than v2.5, you may need to change the Python.cmake file. See the [[Talk:CMake#CMake_and_Python_2.6|CMake discussion]] for details (this change was necessary as of 1.21-r99587 source branch). )
* '''The Windows Platform SDK'''
** Get the latest version (as of 23 March 2010) here: [http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=c17ba869-9671-4330-a63e-1fd44e0e2505&displayLang=en Windows SDK for Windows Server 2008 and .NET Framework 3.5 SP1] (If you use the web installer, you can choose only the "Development Tools" and cut the download size significantly.)
* '''DirectX 9.0 SDK'''
** Get the latest version (as of 29 Oct 2008) here: [http://www.microsoft.com/downloads/details.aspx?FamilyID=ea4894b5-e98d-44f6-842d-e32147237638&DisplayLang=en DirectX 9.0 SDK (August 2008)]

Verify that Cygwin, CMake, and Python are in the windows "PATH".

'''NOTE:''' '''DO NOT''' use the Cygwin version of CMake or Python. The Build will fail. (CMake specifically excludes the Cygwin version of Python, in the <code>'Python.cmake'</code> file)

== Downloading Source Code ==

You can download the Viewer source code on the [[source downloads]] page. You can also use a [[version control repository]]. If you're just starting out, it's probably best to get the latest Release version, rather than a Release Candidate, because the Release Candidates get updated quite often. But if you would rather work with the latest code, go for the [[version control repository]] "trunk". Don't forget to also download the artwork and library bundles relevant to the repository branch you're using as explained in [[Version_control_repository#Artwork_and_Library_Bundles|Artwork and Library Bundles]].

If you're downloading from the [[source downloads]] page, there are three packages to get: the source package, the artwork package, and the library package. In versions 1.20 and earlier, Linden packaged the library binaries in the Libs package. For 1.21 and beyond, the CMake develop.py script now downloads '''most''' of the libraries that were previously in the libs zip file. This saves developers who are tracking trunk from constantly downloading them every update and only downloads updated libraries. As of this writing, there are some pieces packages that still require downloading, so be sure to grab the library and artwork bundles from the [[source downloads]] page.

'''WARNING:'''
* If the directory path you keep the SL source in has a space in it, the batch file that copies message_template.msg will fail. So, if you unzip or checkout the source tree into, e.g., "C:\Projects\Dir with space in name\Etc\linden", it won't work!
* You should also avoid using non-ASCII (national) characters in the paths, although some localized versions of the tool puts some as a default...
* Unzip or checkout your source tree into a directory that has as short full pathname as possible, since long paths cause some unexpected trouble during the build.

In other words, the easiest way to get this working is to get '''source''', '''artwork''', and '''libs''' from the [[source downloads]] page and unpack them all into the same directory/folder, which ideally would be a folder in (or near) the root directory with a short name like '''sl_1_21_6'''.

== Installing libraries ==

SL Viewer depends on some third party libraries. Some of them are open source, some others are not.

=== Open source libraries ===

As of Viewer version 1.21, all open source libraries are automatically downloaded as part of the build script invoked by develop.py, unless you choose to configure a standalone build.

=== Proprietary libraries ===

Linden Lab does not provide proprietary libraries. You will need to follow the instructions here under to acquire and copy them to your source tree.

It's probably a good idea to build an empty directory tree for those files, copy the relevant proprietary files there and, once done, copy the whole to your source tree (like ''XCOPY OLIB SL_1_16_0_5 /S''). The reason is that these steps are cumbersome and will have to be repeated for each new release (at least if you keep the source for each release in its own folder). If you do not want to do this, you can just as well copy the files directly into the linden source paths.

rem OLIBS.CMD to build a folder tree for 3rd party libraries and includes
md olibs
md olibs\linden\
md olibs\linden\libraries
md olibs\linden\libraries\include
md olibs\linden\libraries\i686-win32
md olibs\linden\libraries\i686-win32\lib_release
md olibs\linden\libraries\i686-win32\lib_debug
md olibs\linden\libraries\i686-win32\include
md olibs\linden\libraries\i686-win32\include\GL
md olibs\linden\libraries\i686-win32\include\quicktime
md olibs\linden\indra
md olibs\linden\indra\newview

==== Fmod ====
* Download & extract [http://www.fmod.org/files/fmod3/fmodapi375win.zip FMOD3.75 API for Windows]. (later versions, like FMOD Ex, are incompatible).
* Copy "fmodapi375win\api\inc\fmod.h" to "linden\libraries\include"
* Copy "fmodapi375win\api\inc\fmod_errors.h" to "linden\libraries\include"
* Copy "fmodapi375win\api\inc\fmoddyn.h" to "linden\libraries\include"
* Copy "fmodapi375win\api\lib\fmodvc.lib" to "linden\libraries\i686-win32\lib_release" and to "linden\libraries\i686-win32\lib_debug"
(If using cmake, copy "fmodapi375win\api\lib\fmodvc.lib" to "linden\libraries\i686-win32\lib\release" and to "linden\libraries\i686-win32\lib\debug")
* Copy "fmodapi375win\api\fmod.dll" to "linden\indra\newview"

==== Quicktime ====

Currently - as of version 1.21 - CMake requires Quicktime to be installed.

'''Note:''' This download requires a registration at the Apple Quicktime website and take a bit of time. You can avoid using QuickTime if you want, see [[Compiling_older_Viewers_(1.20_and_earlier_with_MSVS)#QuickTime_removal|this]] for details. Remember that your Viewer '''can't play in-world movies''' if you do so.
* Download & install the [http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/11.1.17.2.1.3.3.1.0.1.1.0.3.11.3.3.1#main Quicktime SDK for Windows]
* Copy "QuicktimeSDK\Libraries\QTMLClient.lib" to "linden\libraries\i686-win32\lib_release" and to "linden\libraries\i686-win32\lib_debug".

(If using CMake, copy "QuicktimeSDK\Libraries\QTMLClient.lib" to "linden\libraries\i686-win32\lib\release" and to "linden\libraries\i686-win32\lib\debug" instead)

* Copy the contents of "QuicktimeSDK\CIncludes" into "linden\libraries\i686-win32\include\quicktime".

== Building the Viewer ==

At this point, you should be ready to use [[CMake]] to build the Visual Studio solution for the project.

'''NOTE''': CMake is only supported for Viewer versions 1.21 and beyond.

Before you first run a build, you'll need to configure things. It is recommended that you use the <code>develop.py</code> script that will create a default configuration for you.

You must make sure that cmake is registered in the Windows environment or you will get strange errors from develop.py. To ensure everything is correct, right click My Computer -> Properties -> Advanced -> Environment Variables -> Inside System Variables, choose PATH (case insensitive) and click Edit. Now in the value field, go to the end of the value and add a semicolon (;), and then the folder containing the CMake binaries (example: C:\Program Files\CMake 2.8\bin). This might already have been set by the CMake installer.

From the command line, navigate to the indra folder of your source tree and run:

python develop.py

CMake will pick the most recent version of Visual Studio we support. If you want to specify the version of Visual Studio to use.

* VisualStudio 2005:

python develop.py -G VC80

* VisualStudio 2008:

python develop.py -G VC90

'''NOTE:''' The above commands will configure a "non-standalone" version of the source code tree. This means that the required third party library packages (as built by Linden Lab) will be downloaded during the CMake process.

=== Finding your build directory ===

In the CMake world, we keep source and object files separate. The <code>develop.py</code> script did create and populate a build directory for you. It is in one of the following locations:
* VS 2005: <code>'indra/build-vc80'</code>
* VS 2008: <code>'indra/build-vc90'</code>

=== Compiling ===

To start a build, do one of the following:
* Run <code>python develop.py build</code> from the indra directory.
** '''NOTE FOR VS 2008 USERS:''' This command will not work, since it will only look for VS 2005. Instead, run the command <code>python develop.py -G VC90 build</code>
* Load the Visual Studio solution into your IDE. For MSVS VC++:
** Use "File -> Open -> Project/Solution", and open the linden/indra/build-VC80/SecondLife.sln solution file
*** '''NOTE FOR VS 2008 USERS:''' Even though a build-VC90 was created in the above steps, developer.py places the VS 2008 solution/project files in the indra directory. Don't move them to build-VC90 - the paths in the project files are relative to the indra directory.
** In the MSVS toolbar, just to the right of the triangular "Start Debugging" arrow, is a text box whose tooltip is "Solution Configurations". Select RelWithDebugInfo.
** If ALL_BUILD is not set as your StartUp Project (the StartUp Project is displayed in bold font), right-click on ALL_BUILD and choose "Set as StartUp Project".
** Right-click on ALL_BUILD and choose "Properties". In "Configuration Properties -> Debugging", find "Working Directory" and navigate to "linden\indra\newview".
** (For Snowglobe 1.x) In the Solution Explorer pane, right-click on the project named "prepare" and select Project Only -> Build Only prepare. This downloads and installs precompiled libraries and only needs to be done when the source tree is clean or if libraries in the list included in the source tree get updated. Running this when not required is brief and causes no harm.
** Build -> Build Solution (F7)
** Debug -> "Start Debugging" or "Start without debugging".
** MSVC might not be able to find the executable. If not, point it to "linden\indra\build-VC80\newview\relwithdebinfo\secondlife-bin.exe", and try again.
** You may see an error due to not being able to find fmod.dll. If so, find a copy (remember, you copied this in a step above) and copy it into "indra\build-VC80\newview\relwithdebinfo". Try again.
** You may see an error due to not finding llkdu.dll. If so, find it in the normal installed version (make sure it's the same version as your source) and copy it into "indra\build-VC80\newview\relwithdebinfo". Try again.
** Good luck!

=== Where's the built Viewer? ===

On Windows, the built Viewer ought to run from VS2005.

To run outside MS VS, see Discussion tab:
[[Talk:Microsoft_Windows_Builds#Running_Viewer_outside_of_MS_VC]]

=== Build instructions for 1.20 and earlier ===

See [[Compiling older Viewers (1.20 and earlier with MSVS)]] if you'd like to compile a version of the Viewer older than 1.20.

== What to do if it doesn't work for you ==

* Ask for help on [[IRC]] (irc.freenode.net #opensl)
* Find someone on the [[OpenSource-Dev|OpenSource-Dev mailing list]]
* Fix it: [[Modifying CMake Files‎]] (and please, submit a patch!)

Please also see the (user contributed) instructions at [[User:Michelle2_Zenovka/cmake]]

[[Category:Compiling viewer]]

If

2010-10-04T22:10:44Z

Zidan Foxdale:

{{#vardefine:p__desc|
}}{{#vardefine:p_condition_desc|If this executes as true then '''branch''' is executed.
}}{{#vardefine:p_condition_d_desc| If this executes as true then '''branch_true''' is executed otherwise '''branch_false''' is executed.
}}{{#vardefine:p_branch_desc|Can be either a single statement, a block statement, or a null statement.
}}{{LSL_Conditional
|statement=if
|p1_name=condition
|p2_name=branch
|statement_header
|statement_desc
|statement_title=if ( {{LSL Param|condition}} ) {{LSL Param|branch}}
|extras=
<div id="box">
== if ( {{LSL Param|condition_d|condition}} ) {{LSL Param|branch|branch_true}} else {{LSL Param|branch|branch_false}} ==
<div style="padding: 0.5em;">
{{{!}}
{{LSL DefineRow||condition|{{#var:p_condition_d_desc}}}}
{{LSL DefineRow||branch_true|{{#var:p_branch_desc}}}}
{{LSL DefineRow||branch_false|{{#var:p_branch_desc}}}}
{{!}}}

There seems to be no limit anymore (or very high > 120) for else-if chains.
</div>
</div>
|spec=Operators in LSL do NOT [http://en.wikipedia.org/wiki/Short-circuit_evaluation short circuit]. For example:
{{{!}} style="border-width: 0px;border-spacing: 0px;"
{{!}}<lsl>// A simple method to say if the method was called.
integer test()
{
llOwnerSay("Test method called!");
return TRUE;
}

default
{
touch_start(integer total_number)
{
if (FALSE && test())
{ // If short-circuit optimized then the test() should never be called.
// Will never get here.
}
}
}</lsl>
{{!}}}
In a short-circuited language if the left-hand side of a logical AND (&&) is FALSE the right-hand side is never tested since the entire test would always return a FALSE output no matter what the value of the right-hand side. Since LSL is not short circuited, both the left and the right-hand sides are tested all the time.
This can be simulated by using a nested if structure:

<lsl>default
{
touch_start(integer total_number)
{
if (FALSE)
{
if (test())
{
// Will never get here.
}
}
}
}</lsl>
|examples=Simple inline if statement:
<lsl>if (a == 1) c = b;</lsl>

Simple block if statement:
<lsl>if (a == 1)
{
// Do something here.
}</lsl>

Complex if/else block (only one line of text will be said by this example)
<lsl>if (a == "Loren") {
llSay(0, "Lorem ipsum sic amet!");
} else if (a == "Bob") {
llSay(0, "Babble dabble rabble rouse.");
} else {
llSay(0, "Gobbledygook? or English?");
}</lsl>

Compounded if statement:
<lsl>if (a == 1 && b == c)
{
// more here.
}</lsl>

Nested if statements:
<lsl>if (a == 1)
{
if (b == c)
{
// more here.
}
}</lsl>

Watch out for misplaced semicolons. They can, and will, cause strange things to happen.
For instance: If you place a semicolon between an if statement and a code block, the if statement will not control the execution of the block.
<lsl>if (a == "Loren");
{
llSay(0, "Lorem ipsum sic amet!");
}</lsl>

This code will execute in the following order:

# The line <code>if (a == "Loren");</code> will execute; the semicolon will tell LSL that this is a simple inline if statement.
# Next it meets the start of the code block and will execute the contents, in this case saying "Lorem ipsum sic amet!", no matter what the outcome of the above if statement.

Another problem happens when someone forgets to use the curly braces.
<lsl>if (a == "Loren")
llSay(0, "Lorem ipsum sic amet!");
llSay(0, "I don't know what it means either...");</lsl>

The assumption is that because the indentation makes it "look" like both llSay commands are controlled by the if statement, that they are. In fact, if <code>a</code> was equal to "Joe" then all that would be said is "I don't know what it means either..."

There is common error to mistake == operator for =, due to ignorance or simply mistyping, e.g.

<lsl>
if (av_id = llGetOwner())
llSay(0,"It's my owner!");</lsl>
will send message regardles what value of va_id was , because it equal to if(llGetOwner()).

There is trick , invented by C programmers ages ago how to avoid this bug - to make habit to put constant or other expression to which you cannot assign value(e.g. function call or result of some operation) in front of comparison - that will save you from mistake. It's very nasty error to make and hard to debug in big code.

<lsl>
if(llGetOwner() == av_id)
llSay(0,"It's my owner!");</lsl>

In this case mistake will result in compile error.

|helpers
|also_header
|also_functions
|also_tests
|also_articles
|also_footer
|notes
|mode
|deprecated
|cat1=Conditional
|cat2
|cat3
|cat4
}}

If

2010-10-04T22:09:09Z

Zidan Foxdale:

{{#vardefine:p__desc|
}}{{#vardefine:p_condition_desc|If this executes as true then '''branch''' is executed.
}}{{#vardefine:p_condition_d_desc| If this executes as true then '''branch_true''' is executed otherwise '''branch_false''' is executed.
}}{{#vardefine:p_branch_desc|Can be either a single statement, a block statement, or a null statement.
}}{{LSL_Conditional
|statement=if
|p1_name=condition
|p2_name=branch
|statement_header
|statement_desc
|statement_title=if ( {{LSL Param|condition}} ) {{LSL Param|branch}}
|extras=
<div id="box">
== if ( {{LSL Param|condition_d|condition}} ) {{LSL Param|branch|branch_true}} else {{LSL Param|branch|branch_false}} ==
<div style="padding: 0.5em;">
{{{!}}
{{LSL DefineRow||condition|{{#var:p_condition_d_desc}}}}
{{LSL DefineRow||branch_true|{{#var:p_branch_desc}}}}
{{LSL DefineRow||branch_false|{{#var:p_branch_desc}}}}
{{!}}}

There seems to be no limit anymore (or very high > 120) for else-if chains.
</div>
</div>
|spec=Operators in LSL do NOT [http://en.wikipedia.org/wiki/Short-circuit_evaluation short circuit]. For example:
{{{!}} style="border-width: 0px;border-spacing: 0px;"
{{!}}<lsl>// A simple method to say if the method was called.
integer test()
{
llOwnerSay("Test method called!");
return TRUE;
}

default
{
touch_start(integer total_number)
{
if (FALSE && test())
{ // If short-circuit optimized then the test() should never be called.
// Will never get here.
}
}
}</lsl>
{{!}}}
In a short-circuited language if the left-hand side of a logical AND (&&) is FALSE the right-hand side is never tested since the entire test would always return a FALSE output no matter what the value of the right-hand side. Since LSL is not short circuited, both the left and the right-hand sides are tested all the time.
This can be simulated by using a nested if structure:

<lsl>default
{
touch_start(integer total_number)
{
if (FALSE)
{
if (test())
{
// Will never get here.
}
}
}
}</lsl>
|examples=Simple inline if statement:
<lsl>if (a == 1) c = b;</lsl>

Simple block if statement:
<lsl>if (a == 1)
{
// Do something here.
}</lsl>

Complex if/else block (only one line of text will be said by this example)
<lsl>if (a == "Loren") {
llSay(0, "Lorem ipsum sic amet!");
} else if (a == "Bob") {
llSay(0, "Babble dabble rabble rouse.");
} else {
llSay(0, "Gobbledygook? or English?");
}</lsl>

Compounded if statement:
<lsl>if (a == 1 && b == c)
{
// more here.
}</lsl>

Nested if statements:
<lsl>if (a == 1)
{
if (b == c)
{
// more here.
}
}</lsl>

Watch out for misplaced semicolons. They can, and will, cause strange things to happen.
For instance: If you place a semicolon between an if statement and a code block, the if statement will not control the execution of the block.
<lsl>if (a == "Loren");
{
llSay(0, "Lorem ipsum sic amet!");
}</lsl>

This code will execute in the following order:

# The line <code>if (a == "Loren");</code> will execute; the semicolon will tell LSL that this is a simple inline if statement.
# Next it meets the start of the code block and will execute the contents, in this case saying "Lorem ipsum sic amet!", no matter what the outcome of the above if statement.

Another problem happens when someone forgets to use the curly braces.
<lsl>if (a == "Loren")
llSay(0, "Lorem ipsum sic amet!");
llSay(0, "I don't know what it means either...");</lsl>

The assumption is that because the indentation makes it "look" like both llSay commands are controlled by the if statement, that they are. In fact, if <code>a</code> was equal to "Joe" then all that would be said is "I don't know what it means either..."

There is common error to mistake == operator for =, due to ignorance or simply mistyping, e.g.

<lsl>
if (av_id = llGetOwner())
llSay("It's my owner!");</lsl>
will send message regardles what value of va_id was , because it equal to if(llGetOwner()).

There is trick , invented by C programmers ages ago how to avoid this bug - to make habit to put constant or other expression to which you cannot assign value(e.g. function call or result of some operation) in front of comparison - that will save you from mistake. It's very nasty error to make and hard to debug in big code.

<lsl>
if(llGetOwner() == av_id)
llSay("It's my owner!");</lsl>

In this case mistake will result in compile error.

|helpers
|also_header
|also_functions
|also_tests
|also_articles
|also_footer
|notes
|mode
|deprecated
|cat1=Conditional
|cat2
|cat3
|cat4
}}

If

2010-10-04T22:08:25Z

Zidan Foxdale:

{{#vardefine:p__desc|
}}{{#vardefine:p_condition_desc|If this executes as true then '''branch''' is executed.
}}{{#vardefine:p_condition_d_desc| If this executes as true then '''branch_true''' is executed otherwise '''branch_false''' is executed.
}}{{#vardefine:p_branch_desc|Can be either a single statement, a block statement, or a null statement.
}}{{LSL_Conditional
|statement=if
|p1_name=condition
|p2_name=branch
|statement_header
|statement_desc
|statement_title=if ( {{LSL Param|condition}} ) {{LSL Param|branch}}
|extras=
<div id="box">
== if ( {{LSL Param|condition_d|condition}} ) {{LSL Param|branch|branch_true}} else {{LSL Param|branch|branch_false}} ==
<div style="padding: 0.5em;">
{{{!}}
{{LSL DefineRow||condition|{{#var:p_condition_d_desc}}}}
{{LSL DefineRow||branch_true|{{#var:p_branch_desc}}}}
{{LSL DefineRow||branch_false|{{#var:p_branch_desc}}}}
{{!}}}

There seems to be no limit anymore (or very high > 120) for else-if chains.
</div>
</div>
|spec=Operators in LSL do NOT [http://en.wikipedia.org/wiki/Short-circuit_evaluation short circuit]. For example:
{{{!}} style="border-width: 0px;border-spacing: 0px;"
{{!}}<lsl>// A simple method to say if the method was called.
integer test()
{
llOwnerSay("Test method called!");
return TRUE;
}

default
{
touch_start(integer total_number)
{
if (FALSE && test())
{ // If short-circuit optimized then the test() should never be called.
// Will never get here.
}
}
}</lsl>
{{!}}}
In a short-circuited language if the left-hand side of a logical AND (&&) is FALSE the right-hand side is never tested since the entire test would always return a FALSE output no matter what the value of the right-hand side. Since LSL is not short circuited, both the left and the right-hand sides are tested all the time.
This can be simulated by using a nested if structure:

<lsl>default
{
touch_start(integer total_number)
{
if (FALSE)
{
if (test())
{
// Will never get here.
}
}
}
}</lsl>
|examples=Simple inline if statement:
<lsl>if (a == 1) c = b;</lsl>

Simple block if statement:
<lsl>if (a == 1)
{
// Do something here.
}</lsl>

Complex if/else block (only one line of text will be said by this example)
<lsl>if (a == "Loren") {
llSay(0, "Lorem ipsum sic amet!");
} else if (a == "Bob") {
llSay(0, "Babble dabble rabble rouse.");
} else {
llSay(0, "Gobbledygook? or English?");
}</lsl>

Compounded if statement:
<lsl>if (a == 1 && b == c)
{
// more here.
}</lsl>

Nested if statements:
<lsl>if (a == 1)
{
if (b == c)
{
// more here.
}
}</lsl>

Watch out for misplaced semicolons. They can, and will, cause strange things to happen.
For instance: If you place a semicolon between an if statement and a code block, the if statement will not control the execution of the block.
<lsl>if (a == "Loren");
{
llSay(0, "Lorem ipsum sic amet!");
}</lsl>

This code will execute in the following order:

# The line <code>if (a == "Loren");</code> will execute; the semicolon will tell LSL that this is a simple inline if statement.
# Next it meets the start of the code block and will execute the contents, in this case saying "Lorem ipsum sic amet!", no matter what the outcome of the above if statement.

Another problem happens when someone forgets to use the curly braces.
<lsl>if (a == "Loren")
llSay(0, "Lorem ipsum sic amet!");
llSay(0, "I don't know what it means either...");</lsl>

The assumption is that because the indentation makes it "look" like both llSay commands are controlled by the if statement, that they are. In fact, if <code>a</code> was equal to "Joe" then all that would be said is "I don't know what it means either..."

There is common error to mistake == operator for =, due to ignorance or simply mistyping, e.g.

<lsl>
if (av_id = llGetOwner())
llSay("It's my owner!");<lsl>
will send message regardles what value of va_id was , because it equal to if(llGetOwner()).

There is trick , invented by C programmers ages ago how to avoid this bug - to make habit to put constant or other expression to which you cannot assign value(e.g. function call or result of some operation) in front of comparison - that will save you from mistake. It's very nasty error to make and hard to debug in big code.

<lsl>
if(llGetOwner() == av_id)
llSay("It's my owner!");<lsl>

In this case mistake will result in compile error.

|helpers
|also_header
|also_functions
|also_tests
|also_articles
|also_footer
|notes
|mode
|deprecated
|cat1=Conditional
|cat2
|cat3
|cat4
}}

LlSetInventoryName

2010-06-20T14:11:12Z

Zidan Foxdale:

{{LSL Function/inventory|old}}{{LSL_Function
|mode=request
|func_id=???
|func_sleep=0.0
|func_energy=10.0
|func=llSetInventoryName
|p1_type=string|p1_name=old|p1_desc
|p2_type=string|p2_name=new|p2_desc=desired inventory name
|func_desc=Tries to renames the inventory object '''old''' to '''new'''. Useful for vendors wishing to hand out customized versions of objects.
|func_footnote
|spec
|caveats
|constants
|examples=
|helpers
|also_events=
|also_functions=
{{LSL DefineRow||[[llGetInventoryName]]|}}
{{LSL DefineRow||[[llGetInventoryDesc]]|}}
{{LSL DefineRow||[[llSetInventoryDesc]]|}}
|also_tests
|also_articles
|notes
|comments=
Possibly should use key, not names source. And it should work as copy/rename/give function. In case of collision - either add number to it's name or return error (should be a flag parameter). --[[User:Zidan Foxdale|Zidan Foxdale]] 14:00, 20 June 2010 (UTC)

A few things that came to mind:
*What happens with a name collision?
*When used in a vendor it would be more useful to change the name of the item when giving, this would avoid the name collision problem (and having to change the name back after giving it).
*A better name for this function would be llRenameInventory (for which there is at least one JIRA).
P.S. I changed the syntax, using inventory numbering to access items is hazardous, names are less prone to change.
-- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 19:03, 21 March 2009 (UTC)
|cat1
|cat2
|cat3
|cat4
}}

LlSetInventoryName

2010-06-20T14:00:24Z

Zidan Foxdale:

{{LSL Function/inventory|old}}{{LSL_Function
|mode=request
|func_id=???
|func_sleep=0.0
|func_energy=10.0
|func=llSetInventoryName
|p1_type=string|p1_name=old|p1_desc
|p2_type=string|p2_name=new|p2_desc=desired inventory name
|func_desc=Tries to renames the inventory object '''old''' to '''new'''. Useful for vendors wishing to hand out customized versions of objects.
|func_footnote
|spec
|caveats
|constants
|examples=
|helpers
|also_events=
|also_functions=
{{LSL DefineRow||[[llGetInventoryName]]|}}
{{LSL DefineRow||[[llGetInventoryDesc]]|}}
{{LSL DefineRow||[[llSetInventoryDesc]]|}}
|also_tests
|also_articles
|notes
|comments=
A few things that came to mind:
*What happens with a name collision?
*When used in a vendor it would be more useful to change the name of the item when giving, this would avoid the name collision problem (and having to change the name back after giving it).
*A better name for this function would be llRenameInventory (for which there is at least one JIRA).
P.S. I changed the syntax, using inventory numbering to access items is hazardous, names are less prone to change.
-- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 19:03, 21 March 2009 (UTC)
Possibly should use key, not names source. And it should work as copy/rename/give function. In case of collision - either add number to it's name or return error (should be a flag parameter). --[[User:Zidan Foxdale|Zidan Foxdale]] 14:00, 20 June 2010 (UTC)
|cat1
|cat2
|cat3
|cat4
}}