The DarkMod Wiki - User contributions [en]

Debugging Your Speakers

2013-02-07T06:52:34Z

Plasticman: Changed "s_drawSpeakers" (which does not exist) to "s_drawSounds" (which was meant in the first place).

This is some sort of a follow-up, please read first [[Setting Up Speakers]].

== Don't forget your ears ==

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player. 
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

== Make Speakers visible with s_drawSounds ==

===The Basics===

Sound emitting entities can be made visible using the ''s_drawSounds'' command in the console:

<code>s_drawSounds 1</code>

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

<code>s_drawSounds 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

and means:

::''<name>'': the name of the shader or sound
::''O'': relative distance to the player (with occlusion)
::''D'': real distance to the player
::''min'': the ''minDistance''
::''max'': the ''maxDistance''
::''n'': the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

<code>r_showportals 1</code>

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account ([[Setting Up Speakers#no_occlusion/ s_occlusion|occlusion]]). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

[[Image:Drawsounds_shot03.png]]

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled, i.e. only for debugging). 
You can not see the difference between ''O'' and ''D'' in this shot due to rounding. 

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of Doom's crude sound units -- ''edit: source code hints they were originally meant to resemble Meters. Since TDM geos big compared to Doom, they turn out to be very short Meters.''):

[[Image:Drawsounds_shot02.png]]

''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 14, but gets capped equivalent to maxDistance.

===Propagation through multiple Portals===

When a sound is propagated through more than one portal it has to be bended around many corners. You would expect the drawSounds tool to show an appropriate bended line, but it doesn't.

A basic setup with multiple portals, one speaker and one "Listener" (the player), may look like this:

[[Image:DrawSounds_Portals_1.png]]

Sound propagation and it's visualisation differ:

[[Image:DrawSounds_Portals_2.png]]

The lines drawn by drawSounds only show you
* where the sound is originating from while you hear it (that is the active portal nearest to the actual source speaker).
* where the originating speaker is.
The ralative dastance, the amount of occlusion, is not affected by this visualisation. The yellow line shows the distance that really is taken into account by the sound engine. The value of ''O'', the relative distance shown on the drawn Speaker itself, is correct and differs from the length of the red line.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read. :)

===Issues===
* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
* Sometimes the red lines can go to weird places. Esp. with ''s_drawSounds 2'' all inactive entitites seem to point at a common origin. -- ''edit: looks like they point to the last known position played from. When propagated through a portal it points there. At map start sounds are not played yet, so they point to 0,0,0.''
* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

== Getting the Volume right ==

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use [[Setting Up Speakers#volume/ s_volume|the ''s_volume'' property]].

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

<code>s_clipvolumes 0</code>

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

<code>s_showLevelMeter 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (''bind n toggle s_useOcclusion'').

<code>com_showdecoders 1</code>: Will draw a few lines on your screen, showing the sounds currently playing.

[[Category:Sound]]
[[Category:Editing]]

Debugging Your Speakers

2013-02-06T06:00:37Z

Plasticman:

This is some sort of a follow-up, please read first [[Setting Up Speakers]].

== Don't forget your ears ==

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player. 
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

== Make Speakers visible with s_drawSpeakers ==

===The Basics===

Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:

<code>s_drawSpeakers 1</code>

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

<code>s_drawSpeakers 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

and means:

::''<name>'': the name of the shader or sound
::''O'': relative distance to the player (with occlusion)
::''D'': real distance to the player
::''min'': the ''minDistance''
::''max'': the ''maxDistance''
::''n'': the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

<code>r_showportals 1</code>

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account ([[Setting Up Speakers#no_occlusion/ s_occlusion|occlusion]]). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

[[Image:Drawsounds_shot03.png]]

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled, i.e. only for debugging). 
You can not see the difference between ''O'' and ''D'' in this shot due to rounding. 

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of Doom's crude sound units -- ''edit: source code hints they were originally meant to resemble Meters. Since TDM geos big compared to Doom, they turn out to be very short Meters.''):

[[Image:Drawsounds_shot02.png]]

''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 14, but gets capped equivalent to maxDistance.

===Propagation through multiple Portals===

When a sound is propagated through more than one portal it has to be bended around many corners. You would expect the drawSpeakers tool to show an appropriate bended line, but it doesn't.

A basic setup with multiple portals, one speaker and one "Listener" (the player), may look like this:

[[Image:DrawSounds_Portals_1.png]]

Sound propagation and it's visualisation differ:

[[Image:DrawSounds_Portals_2.png]]

The lines drawn by drawSpeakers only show you
* where the sound is originating from while you hear it (that is the active portal nearest to the actual source speaker).
* where the originating speaker is.
The ralative dastance, the amount of occlusion, is not affected by this visualisation. The yellow line shows the distance that really is taken into account by the sound engine. The value of ''O'', the relative distance shown on the drawn Speaker itself, is correct and differs from the length of the red line.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read. :)

===Issues===
* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
* Sometimes the red lines can go to weird places. Esp. with ''s_drawSounds 2'' all inactive entitites seem to point at a common origin. -- ''edit: looks like they point to the last known position played from. When propagated through a portal it points there. At map start sounds are not played yet, so they point to 0,0,0.''
* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

== Getting the Volume right ==

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use [[Setting Up Speakers#volume/ s_volume|the ''s_volume'' property]].

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

<code>s_clipvolumes 0</code>

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

<code>s_showLevelMeter 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (''bind n toggle s_useOcclusion'').

<code>com_showdecoders 1</code>: Will draw a few lines on your screen, showing the sounds currently playing.

[[Category:Sound]]
[[Category:Editing]]

Debugging Your Speakers

2013-02-06T05:54:09Z

Plasticman:

This is some sort of a follow-up, please read first [[Setting Up Speakers]].

== Don't forget your ears ==

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player. 
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

== Make Speakers visible with s_drawSpeakers ==

===The Basics===

Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:

<code>s_drawSpeakers 1</code>

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

<code>s_drawSpeakers 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

and means:

::''<name>'': the name of the shader or sound
::''O'': relative distance to the player (with occlusion)
::''D'': real distance to the player
::''min'': the ''minDistance''
::''max'': the ''maxDistance''
::''n'': the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

<code>r_showportals 1</code>

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account ([[Setting Up Speakers#no_occlusion/ s_occlusion|occlusion]]). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

[[Image:Drawsounds_shot03.png]]

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled, i.e. only for debugging). 
You can not see the difference between ''O'' and ''D'' in this shot due to rounding. 

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of Doom's crude sound units -- ''edit: source code hints they were originally meant to resemble Meters. Since TDM geos big compared to Doom, they turn out to be very short Meters.''):

[[Image:Drawsounds_shot02.png]]

''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 14, but gets capped equivalent to maxDistance.

===Propagation through multiple Portals===

When a sound is propagated through more than one portal it has to be bended around many corners. You would expect the drawSpeakers tool to show an appropriate bended line, but it doesn't.

A basic setup with multiple portals, one speaker and one "Listener" (the player), may look like this:

[[Image:DrawSounds_Portals_1.png]]

Sound propagation and it's visualisation differ:

[[Image:DrawSounds_Portals_2.png]]

The lines drawn by drawSpeakers only show you
* where the sound is originating from while you hear it (that is the active portal nearest to the actual source speaker).
* where the originating speaker is.
The ralative dastance, the amount of occlusion, is not affected by this visualisation. The yellow line shows the distance that really is taken into account by the sound engine. The value of ''O'', the relative distance shown on the drawn Speaker itself, is correct and differs from the length of the red line.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read. :)

===Issues===
* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
* Sometimes the red lines can go to weird places. Esp. with ''s_drawSounds 2'' all inactive entitites seem to point at a common origin. -- ''edit: looks like they point to the last known position played from. When propagated through a portal it points there. At map start sounds are not played yet, so they point to 0,0,0.''
* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

== Getting the Volume right ==

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use [[Setting Up Speakers#volume/ s_volume|the ''s_volume'' property]].

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

<code>s_clipvolumes 0</code>

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

<code>s_showLevelMeters 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (''bind n toggle s_useOcclusion'').

<code>com_showdecoders 1</code>: Will draw a few lines on your screen, showing the sounds currently playing.

[[Category:Sound]]
[[Category:Editing]]

File:DrawSounds Portals 2.png

2013-02-06T05:18:52Z

Plasticman: Sound propagation through multiple portals, pic 2/2.

Sound propagation through multiple portals, pic 2/2.

File:DrawSounds Portals 1.png

2013-02-06T05:18:10Z

Plasticman: Sound propagation through multiple portals, pic 1/2.

Sound propagation through multiple portals, pic 1/2.

Installation

2013-02-03T06:29:44Z

Plasticman: /* Install on Linux */ - removed "installed and patched" since there is no patch, only an installer.

{{important|headline=Important|text=This article tells you how to install the full version of [[The Dark Mod]]. If you are installing one of the demos: ''Thief's Den'' or ''Saint Lucia'', then you can ignore this page. Instead, follow the instructions here: [[Thief%27s_Den#Installation|Thief's Den Installation]] or [[Saint_Lucia|Saint Lucia Installation]].}}

__TOC__

{{important|headline=Important|text=You'll need to install the [http://www.dramthethief.com/darkmod/files/DOOM3-1.3.1.exe Doom 3 patch 1.3.1] otherwise the Mod won't run. Furthermore, the new BFG edition of Doom 3 does not offer mod support, so this is a no go.}}

== Prerequisites ==
==== General ====
:At a minimum, you'll need a machine which is capable of running the Doom 3 game on comfortably high settings. The team recommends adding more RAM and a bit more CPU to the basic requirements, however, otherwise running the larger maps will be difficult.

==== Operating System ====
:*Windows (2000/XP/Vista/Win7)
:*Linux
:*MacOSX

==== Doom 3 Patch 1.3.1 ====
:In order to run The Dark Mod, you need to have the v1.3.1 patch for Doom 3 installed. See the [[#Weblinks|download section below]] for links, please use these links as there are some bad versions of this patch floating around some sites. Steam copies of Doom3 will already have the correct version and do not need to worry about this.

:*Linux users: make sure that the install path for Doom 3 is all lowercase (e.g. <code>/usr/local/lib/doom3</code>).
:*Non-English Windows users: Some combinations of Doom 3 English and a non-English version of Windows can result in the patch installer having trouble or not offering an English option, please see [http://modetwo.net/darkmod/index.php?/topic/11815-trouble-patching-and-launching| this forum thread].

==== Hard Disk Space ====
:A rough estimate of how disk space required is '''3-4gb'''. As TDM is under continual development this is likely to increase slowly over time.

:Breakdown of the estimate:
::* Doom 3 installation : 1.5 GB.
::* For the base TDM package you need another 2 GB.
::* Plus a variable amount of space you need for downloaded FM packages.
::* Plus a variable amount of space for screenshots, savegames, etc.

:*FM's (Fan Mission) sizes vary as they depends on the amount of custom content(models, textures etc) the FM author is packing in. Usually FMs are very small, if they're using the stock TDM content (1 to 10 MB). FM's with large amounts of custom content can be quite large (20-60mb+), all content however is pre-compressed. For more information please see [[Fan Missions for The_ Dark Mod]].
:*Savegames vary in size, they can be a few MB per save depending on the size of the FM.
:*Screenshots depend on the screen resolution you're using (~2 MB per shot).

==== References ====
:See the article [[Known System Configurations]] for a (hopefully growing) collection of system configurations and the corresponding user feedback.

== Installing The Dark Mod ==
=== Install on Windows ===
You need a working and patched Doom 3 installation (non BFG edition) on your hard drive. These steps will assume that you installed Doom 3 in the folder <tt>C:\Games\Doom3</tt>. If you are using a Steam version of Doom3 please read [[FAQ#Does_it_run_with_the_Steam_version_of_Doom_3.3F |this FAQ note]].

# Create a '''darkmod''' folder in your Doom 3 directory, like this: '''C:\Games\Doom3\darkmod\'''
# Download the [http://www.bloodgate.com/mirrors/tdm/pub/pk4/tdm_update_win.zip TDM Updater] from one of our mirrors.
# Extract '''tdm_update.exe''' from the downloaded ZIP and copy it into your '''C:\Games\Doom3\darkmod\''' folder.
# Run tdm_update.exe. The installer will connect to our download mirrors and start the download process.
# Be patient and wait. The download weighs about '''1.7 GB''' will take a while.
# If you see error messages about corrupt files, please try to run the updater again, these massive downloads are sometimes failing.
# After installation, you'll find an executable <tt>tdmlauncher.exe</tt> in your darkmod folder, i.e. <tt>C:\Games\Doom3\darkmod\tdmlauncher.exe</tt>. Use this to start The Dark Mod.

Note for Windows 2000 users: please install the GDI+ redistributable package, as described here: [[TDM in Windows 2000]]

=== Install on Linux ===
# You need the native version of Doom 3 (non BFG edition). Installation on Linux is explained on Id's Doom 3 Linux FAQ([[#Weblinks|see below]]), where you will find download links and install instructions. Be sure to download the 1.3.1.1304-version (not the demo).
# Since there is no 64 bit version of either Doom 3 or The DarkMod, on 64 bit systems you also need the 32 bit compatibility libraries installed. On some distributions like SuSE, these are included in the default installation, but on Kubuntu/Ubuntu you need to install the package called <code>ia32-lib</code> and all its dependencies. Otherwise, even the installer for Doom 3 will fail to run.
# Create a folder <tt>~/.doom3/darkmod</tt> in your home directory. Mind the dot in the path.
# Download the Linux version of the [http://www.bloodgate.com/mirrors/tdm/pub/pk4/tdm_update_linux.zip TDM Updater] and save it to <tt>~/.doom3/darkmod/</tt>
# Extract ''tdm_update.linux'': <tt>unzip tdm_update_linux.zip</tt>
# Make ''tdm_update.linux'' executable: <tt>chmod +x tdm_update.linux</tt>
# Run the updater: <tt>./tdm_update.linux</tt> It will connect to our mirrors and download the packages for you.

# If you get an error about GLIBCXX_3.4.9, delete or rename the files <tt>/usr/local/games/doom3/libstdc++.so.6</tt> and <tt>/usr/local/games/doom3/libgcc_s.so.1</tt>.

=== Install on Mac OSX ===
# Ensure that Doom 3 (non BFG edition) is patched to v1.3.1 RevA (which provides native support for Intel processors), see below for links.
# It is recommended that the "Doom 3" program folder is installed into the Application Support folder (i.e. <tt>~/Library/Application Support/Doom 3/</tt>). If Doom 3 is installed into a different location then additional steps will need to be followed.
# Download [http://www.bloodgate.com/mirrors/tdm/pub/pk4/mac/darkmod.zip darkmod.zip].
# Move the resulting "darkmod" folder to the "Doom 3" folder (alongside "Doom 3.app" and the "base" folder).
# Within the darkmod folder, double-click the tdm_update_helper.command file to begin downloading the latest release of TDM (approx 2GB).
# Start The Dark Mod using the <tt>tdmlauncher_helper.command</tt> script in your <tt>~/Library/Application Support/Doom 3/darkmod</tt> folder.

==== Using a custom Doom 3 location ====
Until idTech4 is open sourced, there is some dependency on the Application Support folder, where FMs are currently downloaded to. If the Doom 3 folder is not located within Application Support, you'll need to do the following to allow TDM to function as intended:

# Open up a terminal window (if you don't know how to do this, type 'terminal' into the SpotLight search bar and press 'Enter' to run the terminal application).
# Type the command <tt>cd ~/Library/Application\ Support/Doom\ 3/</tt> and press the 'Enter' key.
# Enter the command 'mkdir darkmod' and then 'cd darkmod' to change to the new darkmod directory.
# Create a symbolic link with the command <tt>ln /folder/darkmod/tdmlauncher.macosx tdmlauncher.macosx</tt> where /folder/ is the path to your "Doom 3" program folder.
# You should now be able to launch TDM by double clicking the tdmlauncher_helper.command script in your "Doom 3" program folder where TDM has downloaded.

==== tdmlauncher_helper.command ====
#!/bin/sh
export TDMDIR=`dirname "$0"`
exec "$TDMDIR/tdmlauncher.macosx" "$TDMDIR/../Doom 3.app/Contents/MacOS/Doom 3"

==== tdm_update_helper.command ====
#!/bin/sh
export TDMDIR=`dirname "$0"`
cd "$TDMDIR"
chmod +x tdm_update.macosx
exec ./tdm_update.macosx

==== Known issues ====
The automatic restart (when installing a FM, or restarting from the Graphics screen) currently fails to relaunch TDM v1.06 occasionally. If this happens, TDM will need to be launched manually by running the launcher program or script.

== Alternative Download Methods ==
If you have troubles running tdm_update, you can see if [[tdm_update|this page]] helps you. Otherwise, you can also use other download methods to get a initial copy of the mod. Visit [http://www.mindplaces.com/darkmod/downloads.php TDM Downloads].

== Launching The Dark Mod ==
Use the '''thedarkmod''' application to run The Dark Mod. This small application will take care of launching the Doom 3 process with the correct command line arguments. The application is available for all supported platforms.

* '''Windows:''' <tt>C:\Games\Doom3\darkmod\thedarkmod.exe</tt>
* '''Linux:''' <tt>~/.doom3/darkmod/thedarkmod.x86</tt>
** Before it can be run the first time, you must make '''tdmlauncher.linux''' executable: <tt>chmod +x ~/.doom3/darkmod/thedarkmod.x86</tt>
* '''Mac OSX:''' <tt>~/Library/Application Support/Doom 3/darkmod/thedarkmod.macosx</tt>
** Before it can be run the first time, you must make '''thedarkmod.macosx''' executable: <tt>chmod +x ~/Library/Application Support/Doom 3/darkmod/thedarkmod.macosx</tt>

'''Note:''' The application will also be used by the game itself when installing/re-installing/un-installing FM packages, so '''please don't delete tdmlauncher'''.
* See also [[Creating Desktop Shortcuts for TDM]].
* See also [[tdmlauncher in Gentoo Linux]]

==== Troubleshooting the application ====
The '''thedarkmod''' executable will generate a small logfile <tt>tdmlauncher.log</tt> each time it is invoked. The log file is located right next to the executable and might give some useful insight if the game fails to load.

==== Passing custom command line arguments ====
Some people like to have custom command line arguments to the game, which is supported by the executable. Open the <tt>dmargs.txt</tt> in your darkmod folder and add any arguments you'd like the application to pass to the Doom3 command line.
* See also [[Doom3 command line arguments]].

== First Startup ==
* Please take your time to read through [[The Dark Mod Gameplay]] article to get familiar with the game.
* TDM ships with a Training Mission which is designed to introduce you to TDM gameplay. You should start this mission first even if you've played stealth games before.
* Adjust the settings in the menus, like screen resolution and gameplay settings.
* See also the [[Performance Tweaks]] article to make TDM run a little bit faster if you're on a lower end machine.
* If you encounter a problem please check the [[FAQ]] and failing that leave a post in the TDM Support forum.

== Installing and Running Fan Missions ==

Fan Missions can be downloaded from inside the TDM menu. Go to "New Mission" and click on "Get new missions".

Alternatively, you can go to [http://www.thedarkmod.com/missions/ www.thedarkmod.com] to get hold of mission packages available for The Dark Mod. Each FM is contained in a PK4 file, which contains all the files necessary to run the mission. Sometimes missions also have an optional _l10n.pk4 file, this contains the content for all other languages than English.

# Download the mission PK4 file - (IE7 may rename PK4s to zip, dont worry TDM looks for both pk4's and zip's).
# Drop the file into the fms/ folder, e.g. <tt>C:\Games\doom3\darkmod\fms\</tt> or <tt>~/.doom3/darkmod/fms</tt>
# Launch The Dark Mod.
# The mission should now be listed in your ''New Mission'' menu.
# Highlight the mission and select ''Install'' to install. TDM will automatically restart.
# Select ''New Mission'' and then ''Start this Mission'' on the upper left.

See the full article [[Installing and Running Fan Missions]] for a detailed explanation.

== DoomConfig.cfg Howto ==
Game configuration settings are stored in the file DoomConfig.cfg but there is one in every FM folder as well as base and darkmod folders. Normally you just use the Settings menu but if you want to manually change or add any settings you should read [[DoomConfig.cfg]] to see how they all integrate together or you may lose some settings if you edit the wrong way.

== Weblinks ==
* Doom [http://www.dramthethief.com/darkmod/files/DOOM3-1.3.1.exe v1.3.1 patch for Windows]
* Doom v1.3.1 for Linux: [ftp://ftp.idsoftware.com/idstuff/doom3/ FTP] [http://zerowing.idsoftware.com:6969/ BitTorrent]
* Doom v1.3.1 RevA for Mac OSX (which provides native support for Intel processors): [http://support.aspyr.com/index.php/kb/article/000579 Doom v1.3.1 RevA] ([http://www.dramthethief.com/darkmod/files/Doom3Mac1.3.1RevA.dmg mirror])

== See also ==
* [[tdm_update]] - If you have trouble with running the installer/updater.
* [[FAQ]] - Frequently Asked Questions and their answers.
* [[Hosting The Dark Mod]]

{{installation}}

FAQ

2011-08-17T01:33:26Z

Plasticman: /* The sound lags behind the picture */ basically rewrote this section, ways to bypass PA without purging it, etc.

{{important|headline=Important|text=This FAQ relates to the full TDM release version only. For players of the pre-release demos such as '''[[Thief's Den]]''' and '''[[Saint_Lucia|Tears of Saint Lucia]]''' please refer to the '''[[FAQ (Demo Releases)|Demo FAQ]]'''.'''}}

== What Doom versions are supported? ==

=== Can I use the Demo version of Doom 3? ===

No, sorry.

=== Can I use it with the Doom 3 expansion Resurrection of Evil? ===
The Doom 3 RoE expansion is designed to run as modification to the base Doom 3 game. Hence it's not a problem to have it installed on your system, but only one mod can be run at a time of course. As long as you didn't move or extract files manually all over your Doom 3 folder, the Resurrection of Evil expansion should not interfere with The Dark Mod. Just to be clear, '''you'll still need to have the base Doom 3 game, the expansion alone won't suffice as it's just a mod'''.

=== Does it run with the Steam version of Doom 3? ===

Yes :) You need to install the mod into the directory where Steam put Doom3, this might be under:

C:\Program Files\Steam\steamapps\common\doom 3

or a similiar folder.

'''Important:''' Create a shortcut on your desktop and set it to the following:

steam.exe -applaunch 9050 +set fs_game_base darkmod

This ensures that when you start Steam, it will launch TDM and not Doom 3 without TDM.

== Patching Doom 3 to verson 1.3.1.1304 ==

=== How can I check whether my Doom 3 is correctly patched? ===

Open Doom 3 and hit {{key|Ctrl}}+{{key|Alt}}+{{key|~}} (tilde, {{key|^}} on German keyboards) to open the console. You'll see the version printed in the lower left corner of the console. It should read '''1.3.1.1304'''. If your version is ending on 1302, you've got the wrong patch installed.

=== Where can I get the right patch? ===

We have the patch hosted on our FTP. See the [[Installation]] article to find a link to it.

If you have version 1.3.1.1302, you may need to uninstall and reinstall before patch 1.3.1.1304 will let you apply it.

=== What's that issue with the 1.3.1 patch? ===

When the 1.3.1 patch was released by Id, they released it a bit too early. Some download sites picked it up quite fast though and started to distribute it. The problem is, that Id replaced that patch with a different one, and, probably thinking that it hadn't spread yet, didn't bother to change the version number. However, you can still find "wrong" 1.3.1 patches and these will not work with the mod. That's why it is important to check the version number in the console to make sure that the right 1.3.1 patch is installed if the mod doesn't work. The link provided here on our own page points to the correct patch, so if you downloaded it from here you don't need to worry about it.

== Supported Operating Systems ==

=== Which Windows versions can I use? ===

The following versions of windows have been tested and are known to work : Windows 2000, Windows XP, Windows Vista, Windows 7, Windows Server 2008, Windows Server 2003 in both 32bit and 64bit flavours.

==== PAE Enabled ====

One user with Windows XP Pro SP3 and an AMD Phenom processor reported problems starting Doom 3 due to having PAE enabled.

[http://modetwo.net/darkmod/index.php?/topic/12471-error-doom-3/ Thread]

=== Does it run in Linux? ===
Yes, Linux is supported.

=== Does it run in 64 Bit Linux? ===
Yes, Linux 64 bit is supported. In addition to the steps above, you need 32 bit compatibility libraries, since Doom3 is 32 bit only:
* On '''SuSE''', they should be included.
* On Ubuntu/Kubuntu, install the package '''ia32'''.

For TDM after 1.0, this step should be '''no''' longer neccessary:

* Since you cannot install 32 bit libraries on a 64 bit system with the normal package manager, you should use [http://ubuntuforums.org/showthread.php?t=474790 getlibs] to install '''libmng''' and the boost filesystem lib:
:<code>getlibs libmng.so.1</code>
:<code>getlibs -l libboost-filesystem1.34.1</code>

=== What about Gentoo? ===
Yes. It's not "officially" supported (the team doesn't test it specifically), however several users have reported success running TDM under Gentoo.

=== What about Ubuntu 8.10? ===
Yes. As of this writing you will need to install the '''libboost-filesystem''' package.

=== GLIBCXX_3.4.9 errors ===

If you receive an error about <tt>GLIBCXX_3.4.9</tt>, delete or rename the files <code>/usr/local/games/doom3/libstdc++.so.6</code> and <code>/usr/local/games/doom3/libgcc_s.so.1.</code>

If this doesn't resolve the error and you have an old version of GCC, then you may have to upgrade. It has been [http://modetwo.net/darkmod/index.php?/topic/9982-the-dark-mod-doom3-in-linux/ confirmed] that, at least under Gentoo, GCC 4.1 does not work with TDM but GCC 4.3 and GCC 4.4 are compatible.

=== Does it run on Mac OS X?===
Yes. See [[Installation]].

== Graphics ==

=== Does TDM support widescreen resolutions? ===

Yes. Choose "16:9" or "16:10" in the in-game ''Settings'' menu, and select the appropriate resolution. Note that you need to restart the game to have the new setting in effect.

If the native resolution of your wide screen monitor is not listed, you can enter it into '''DoomConfig.cfg''' by changing the following entries like so:

set r_mode "-1"
set r_customwidth "1280"
set r_customheight "800"
seta r_aspectratio "2" // means 16:10, "1" is 16:9, other ratios are not yet supporred

{{infobox|If you get performance problems, please consider using a lower resolution and taking a look at [[Performance Tweaks]].}}

==== What about TV resolutions like 1360x768? ====

If you have a wide-screen TV which uses any non-standard resolution, like 1360x768 (instead of 1366x768), then please use the following:

seta r_customWidth "1360"
seta r_customHeight "768"
seta r_mode "-1"
seta r_aspectratio 2
seta g_fov "100" // or any other suitable value

Alternatively, see the manual of your TV on the possibility to switch it to a "1:1" pixel mapping, or "monitor mode" or "computer mode".

Here is some background information: http://hd.engadget.com/2006/04/21/whats-the-deal-with-1366-x-768/

{{infobox|If you get performance problems, please consider using a lower resolution and taking a look at [[Performance Tweaks]].}}

== Troubleshooting ==

It is hard to answer questions on why something fails, because wildly different systems cause wildly different symptoms. If the following section does not help you, please ask at our [http://www.modetwo.net/darkmod forums].

For any solutions below that refer to "disabling Catalyst AI", if you discover you can not use ATI's tools to do so, alternate methods are discussed in [[#Disable Catalyst AI in recent AMD ATI drivers|Disable Catalyst AI in recent AMD ATI drivers]] below.

=== Updater (tdm_update.exe) closes almost as soon as it's started ===

See the [[Tdm_update#Updater_closes_almost_as_soon_as_it.27s_started|main article on tdm_update]].

=== Windows 2000: freeaddrinfo cannot be found in WS2_32.DLL ===
Please refer to the main article [[TDM in Windows 2000]] to work around this problem.

===FM won't install manually===

If you are running Dark Mod under Linux and have edited the file darkmod/currentfm.txt this might prevent the FM from installing. This may be fixed in an update but apparently editing using notepad under Wine works OK.

=== FMs downloaded but don't show in menu list===

You have downloaded some FMs but they don't show on Dark Mod's New Missions list. Possible causes:

* You must not extract the pk4s or zip files but put them into the darkmod/fms folder (or alternatively you can create the FM folder in there eg, darkmod/fms/chalice for chalice.pk4 or chalice.zip.
* Early versions of Dark Mod cannot handle zip suffixes. Solution: rename to .pk4 or run tdm_update to get the latest version of Dark Mod.
* If you are running Linux then Doom 3 MUST be installed in a .doom3 folder. Note the dot before .doom3.

=== FM downloaded but won't play ===

If you have downloaded an FM you might see it in the New Missions List but can't get it to play. These are almost always an install problem. These are some of the causes and cures:

FMs (fan missions) are archives and in early versions of Dark Mod MUST be suffixed .pk4 not zip. Apparently Internet Explorer 8 may change it from pk4 to zip during download without telling you. You need to rename it back if running an early version of Dark Mod else run tdm_update to update and then zip files are OK.

You MUST use doom3\darkmod\tdmlauncher.exe to run Dark Mod in Windows and NOT Doom3.exe.

You do NOT need to extract the pk4 archives to install or play. Just download into or move the pk4 into the darkmod\fms folder. Optionally you can create a folder of the same name as the map and put it in there, eg, darkmod\fms\chalice but there is no need because Dark Mod will create that automatically. Just make sure your pk4 goes, unopened, into the fms folder, then run tdmlauncher.exe

If you have done the above but see for example, a blank objectives screen and no briefing then it is still almost certainly an install error. I recommend you do a clean sweep if in doubt:
* Exit Dark Mod
* Delete doom3\darkmod\currentfm.txt (this just uninstalls any FM)
* Delete the map game folder (if any). This is NOT the folder in fms but the folder in doom3 of the same name as the FM, eg, doom3\chalice. Note: this has savegames and screenshots in it so check and move them out if you want to preserve them. However, if you can't get the game to play it's likely you don't have any yet. If you can't see the folder don't worry. The folder name is normally the same as the pk4 but it might not be. Strictly speaking it must be the same as the name in startingmap.txt inside the pk4 archive. You might see this file in fms.
* Move the pk4 into the darkmod\fms folder if it is not already there.
* Delete the darkmod\fms\FMname folder if any, eg, darkmod\fms\chalice. Don't worry if there isn't one; it will be created automatically later.

So all that is left is the pk4 in the fms folder. Now run tdmlauncher.exe. The FM should be in the list in the New Missions menu. Re-install it and you should now be able to play it.

=== The game crashes on load ===
Make sure that:
* You installed [[#Patching_Doom_3_to_verson_1.3.1.1304|the correct version]] of the Doom 3 1.3.1 patch.
* Your system meets at least the minimum system specs.
* You have enough free main memory. Try closing a few running programs like Outlook, Anti-Virus or torrent clients.
* Nvidia "Threaded Optimizations" are causing Doom 3 Mod stability issues (see: [[#Disable Nvidia "Threaded Optimizations"|Disable Nvidia "Threaded Optimizations"]] )

If that doesn't fix it, you probably receive an error message referencing an "Unknown event" at startup, like the screenshot below illustrates.

[[Image:ErrorSetEntityRelation.jpg]]

Here are a couple of known problems and their solutions:
<ul>
<li>'''tdmlauncher.exe fails to copy''' the necessary game binaries. The log file should read something like this:
<pre>found DLL in pak file: C:\Program Files\Doom 3\darkmod\tdm_game01.pk4/gamex86.dll
copy gamex86.dll to C:\Program Files\Doom 3\darkmod\gamex86.dll
could not create destination file</pre>
<ul>
<li>Sometimes, the procedure fails due to '''spaces in the installation path'''. Try extracting the gamex86.dll manually using Winzip or similar or install Doom 3 in a different directory.</li>
<li>You have a '''firewall''' installed that prevents the copy procedure, because since version 1.03, TDM has a built-in mission downloader. This misbehavior has been reported for the '''COMODO Firewall'''.</li>
</ul>
<li>It is also possible that an '''old version of gamex86.dll''' (or gamex86.so) is lying around in your Doom 3 folder. Delete it and try again.</li>
</ul>

=== Textures are missing, screen mostly black ===

[[Image:Tdm missing textures.jpg|right|240px|Black textures]]

Look into your '''DoomConfig.cfg''' inside your <tt>darkmod</tt> folder and check that the following settings are like shown below:

<pre style="max-width:35em">
seta image_usePrecompressedTextures "1"
seta image_useNormalCompression "2"
seta image_useAllFormats "1"
seta image_useCompression "0"
seta image_preload "1"
</pre>

=== Textures are missing, shadows are pitch black ===

Try disabling the AGP surface accelerator in DXDIAG.

=== Graphic Corruption ===

One report we had was for a Radeon ATI HD 4650, catalyst 10.9. This screen corruption as I understand it was heavy pixelation even on the menus. Closing down Xfire fixed it. "I fiddled with the xfire Doom 3 configuration through the xfire_games.ini, and determined it has to do with InGameFlags portion. For some reason the settings in that were interfering with doom 3, and after I removed some things from there, I was still able to run xfire, and doom 3 was still able to look proper."

(For more recent Catalyst versions see: [[#Disable Catalyst AI in recent AMD ATI drivers|Disable Catalyst AI in recent AMD ATI drivers]] )

=== The briefing is very fuzzy ===

Look into your '''DoomConfig.cfg''' inside your <tt>darkmod</tt> folder and check that the following settings are like shown below:

seta image_roundDown "1"
seta image_forceDownSize "0"
seta image_downSize "0"

=== The sky is corrupted ===

You either see black sky, or fragments of other textures. This seems only to happen on Geforce 6800 cards.

There are two fixes for this:

As a quick fix you can rename the following folder:

env/skyboxes/skybox_darkland_ne

to a different name. That will result in black sky.

Alternatively, edit the file <tt>materials/tdm_sky.mtr</tt> with '''Wordpad''' or a different editor and
find the sky material named '''textures/darkmod/nature/skybox/skybox_darkland_NE''':

<pre>
//Author: Dram
//skybox_ocean with ocean replaced with dark land
//Moon moved to north east by Fidcal
textures/darkmod/nature/skybox/skybox_darkland_NE
{
qer_editorimage env/skyboxes/skybox_ocean/ocean_ed
noFragment
noshadows
noimpact
nooverlays
forceOpaque
{
forceHighQuality
blend add
cameraCubeMap env/skyboxes/skybox_darkland_ne/darkland_NE
texgen skybox
texgen wobblesky .0 .0 .0
}
}
</pre>

In this declaration, comment out the line that reads '''forceHighQuality''' by adding <tt>//</tt> in front of it:

// forceHighQuality

That should fix the sky and make it render correctly.

=== The Sky rotates ===

This problem only affects FMs with a dynamic sky (eg, moving clouds etc.).

If you see the sky spinning it may be an ATI graphics card problem. One report says this was cured by turning off Catalyst AI. Also gives better loading times and cures [[#HDR-Lite Post-Processing problems|HDR-Lite Post-Processing Problems]].

If that doesn't fix it then try this. Note that it replaces dynamic sky with a static clear one so it might look odd in a stormy FM for example, but better than a spinning sky:

<pre>

* Create a new folder in your darkmod folder called materials.
* Within it create a plain text file named no_skybox.mtr.
* Paste in the following:

textures/smf/portal_sky
{
qer_editorimage env/skyboxes/skybox_ocean/ocean_ed
noFragment

noimpact
nooverlays
forceOpaque
noShadows
{
forceHighQuality
blend add
cameraCubeMap env/skyboxes/skybox_darkland_ne/darkland_NE
texgen skybox
texgen wobblesky .0 .0 .0
}
}

</pre>

(For more recent Catalyst versions see: [[#Disable Catalyst AI in recent AMD ATI drivers|Disable Catalyst AI in recent AMD ATI drivers]] )

=== HDR-Lite Post-Processing problems ===

Some owners of ATI graphics cards reported various artifacts when HDR-Lite Post-Processing was enabled. Among these artifacts are a distorted or upside-down screen and spinning sky. These can usually be fixed by disabling Catalyst AI, which also gives better loading times.

To turn off Catalyst AI, open your Catalyst control panel, go to 'graphics' at the top left, select '3d' from the dropdown list and on the new menu below, select 'AI'. Now select the 'Disable Catalyst A.I.' checkbox.

(For more recent Catalyst versions see: [[#Disable Catalyst AI in recent AMD ATI drivers|Disable Catalyst AI in recent AMD ATI drivers]] )

It has also been suspected that HDR-Lite Post-Processing may lead to [[#Underwater performance poor|poor performance underwater]], see next point:

===Underwater performance poor===

Some people suffer from very low framerates underwater with HDR-Lite Post-Processing enabled. Currently, the only known fix to this problem is to set '''g_doubleVision''' to 0 in the console. This however disables the doubleVision effect completely, so that there is no underwater-blur any more. The murkiness still remains though.

===Upside-down screen===

If you get an upside-down screen, you can either turn off Catalyst AI if you have an ATI card or try turning off HDR-Lite Post-Processing in the advanced video options.

To turn off Catalyst AI, open your Catalyst control panel, go to 'graphics' at the top left, select '3d' from the dropdown list and on the new menu below, select 'AI'. Now select the 'Disable Catalyst A.I.' checkbox.

(For more recent Catalyst versions see: [[#Disable Catalyst AI in recent AMD ATI drivers|Disable Catalyst AI in recent AMD ATI drivers]] )

=== The game is '''very''' slow! ===

If you get less than 10 FPS, or the game even stutters, please try this:

Look into your '''DoomConfig.cfg''' inside your <tt>darkmod</tt> folder and check that the
following settings are like shown below:

<pre style="max-width:35em">
seta image_usePrecompressedTextures "1"
seta image_useNormalCompression "2"
seta image_useAllFormats "1"
seta image_useCompression "1"
seta image_preload "1"
</pre>

If that doesn't help, your system might run out of memory. Either upgrade to more than 1 Gbyte memory,
or try to close other applications before playing.

Please see also the article about [[Performance Tweaks]] to improve the performance.

=== Slow loading times ===

If you find an FM is very slow to load it may be an ATI graphics card problem. One report says this was cured by turning off Catalyst AI. Also cures [[#HDR-Lite Post-Processing problems|HDR-Lite Post-Processing Problems]].

Changing the following settings to 0 will also reduce loading time, but be warned: if you have a lower-end system, poor graphics card, or low ram, you will likely notice a performance hit ingame since you will now be using uncompressed textures.
<pre style="max-width:35em">
seta image_useNormalCompression "0"
seta image_useCompression "0"
</pre>

===Game freezes for several seconds when opening doors===
The following problems :

A) "game freezes and loads some data from hard drive while opening doors"
B) "while loading mission you are returned to the menu and need to restart loading"

are often resolved by disabling EAX 4.0 HD in the Audio Settings menu.

===Game exits to menu after mission load, with renderpipe error in console===

* {{Red|Version 1.06 does not use named pipes. This is a depreciated issue.}}

'''Symptoms:''' Missions are installed properly and will load, but after they reach 100% you are returned to the main menu or objectives screen. If you open the console (Ctrl-Alt-~ on US keyboards), you see one/both of these errors:

ERROR: Failed to open \\.\pipe\dm_renderpipe

or

ERROR: idRenderSystemLocal::uncrop currentcrop <1

'''Solution:''' Some firewalls, notably ''Sunbelt Firewall'' (aka ''Kerio Firewall'') are known to interfere with TDM's lightgem, ''even when "disabled"''. To fix this problem, completely uninstall the firewall and get a different one instead.

Related [http://bugs.angua.at/view.php?id=543 #543]: Consider using glReadPixels for lightgem instead of named pipes.

==="COULD NOT FIND TDMLAUNCHER" when installing an FM===

If you receive this error message you should check the start-arguments of DOOM3.exe / tdmlauncher.exe. Arguments are stored in darkmod/dmargs.txt and a faulty syntax e.g. a missing "+" before a "set"-command, will lead to this error message. Steam users are advised to remove any launch-options from Doom.

===The sound lags behind the picture===

This seems to happen on some Linux Distributions with PulseAudio. Doom's sound engine defaults to ALSA, you can try to use OSS instead:

Add the following to your ''dmargs.txt'' (it is in ''~/.doom/darkmod/''):

+set s_driver oss

If your system does not provide OSS or a working OSS-emulation (try ''padsp ./tmdlauncher-linux''), reset this to ''best'' which means ALSA.

While OSS or ALSA deal directly with the sound hardware, PulseAudio is a soundserver that puts itself between the application (doom3) and ALSA. Your goal is to bypass the PA-part while playing TDM.

You can either disable the PulseAudio daemon temporarily or connect Doom directly to ALSA.

To disable PA, create a file named ''client.conf'' in ''~/.pulse'' which contains:

autospawn=no

Then open a terminal and type:

pulseaudio -k

When sound playback fails, make sure you have ''s_driver'' set to ''best'', and ''s_alsa_pcm'' to ''default''. When it works, you propably want to adjust volume settings outside TDM. Try ''alsamixer'' (in a terminal).

When you're finished playing, turn PA back on:

pulseaudio -D

starts the daemon. Changing ''autospawn'' to ''yes'' should prevent you from doing this manually after every reboot. :)

The other way, just bypassing PA, requires some knowledge about your sound hardware. Type

aplay -L

This gives you a long list of your ALSA playback devices, three lines for each, first line is ''<name>''. Choose the one with PCM Playback that your speakers are connected to and add

+set s_alsa_pcm <name>

to ''dmargs.txt''. If ''<name>'' is not convenient for you just try something like hw:1,0 if you know what you are doing, but be aware abstract designations like ''default'' will get "hijacked" by PA.

=== Changing the screen resolution/aspect ratio does nothing!? ===

These changes require a restart of Doom to work. Alternatively the command vid_restart can be issued at the console. It can take quite some time to execute this command, depending on whether or not you're already ingame. It will still be a lot faster than restarting and reloading the game though.

=== Steam launches D3, not TDM ===

Whenever you start Steam and it launches vanilla Doom instead of TDM, make sure you follow this advice:

'''Important:''' Create a shortcut on your desktop and set it to the following:

steam.exe -applaunch 9050 +set fs_game_base darkmod

This ensures that when you start Steam, it will launch TDM and not Doom 3 without TDM.

=== Disable Catalyst AI in recent AMD ATI drivers ===

From (at least) Catalyst versions 10.12 and beyond, the ability to disable Catalyst AI properly
has been changed or removed.

----

Rage3d and Guru3d have advised using "Radeon Pro" to address this.

Steps

* 1) Remove Catalyst Control Center (removing all ATI drivers recommended then re-install just the Display driver)
* 2) Download and install "Radeon Pro" [http://forums.guru3d.com/showthread.php?t=322031 Radeon Pro Thread at Guru3D]
* 3) Create a profile as follows:

<pre>
If you're using RadeonPro, create a profile for the game you want to disable Catalyst AI.
Right-click the newly created profile, keep left shift key pressed and choose
Open Location on context-menu, this will open the profile's XML definition.
Append a new line and add entry like this

<Property name="CatalystAI" value="0" />

Save the file and start the game. CatalystAI should be disabled.

I also recommend to open ___GlobalProfile.xml
(found on same directory where your profile is saved)
and look for "CatalystAI" entry, it must be equal to "1"
otherwise CatalystAI will be kept disabled after you exit your game.

CFX disabled by setting CatalystAI to 0
</pre>

Here's another alternate method for Windows users:

* 1) Obtain a copy of the free "ATI Tray Tools" by Ray Adams from [http://downloads.guru3d.com/download.php?det=733 Guru3d].

* 2) Install it into your Windows tray.

* 3) Right-click it.

* 4) Select Direct 3d -> Catalyst AI -> Off.

=== Disable Nvidia "Threaded Optimizations" ===

Many random crash behaviors seen by Nvidia users can be resolve by the following steps:

<pre>

Open Nvidia Control Panel ->

Manage 3D Settings ->

Bottom half of list locate "Threaded Optimization" <-- Set to NO / Off

Also set "Multi-display/Mixed GPU acceleration" to "Single display performance mode"

</pre>

== See also ==

* [[Known Bugs]]
* [[Gameplay]]

{{installation}} {{general}}

Debugging Your Speakers

2010-11-28T17:14:40Z

Plasticman:

This is some sort of a follow-up, please read first [[Setting Up Speakers]].

== Don't forget your ears ==

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player. 
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

== Make Speakers visible with s_drawSpeakers ==

Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:

<code>s_drawSpeakers 1</code>

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

<code>s_drawSpeakers 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

and means:

::''<name>'': the name of the shader or sound
::''O'': relative distance to the player (with occlusion)
::''D'': real distance to the player
::''min'': the ''minDistance''
::''max'': the ''maxDistance''
::''n'': the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

<code>r_showportals 1</code>

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account ([[Setting Up Speakers#no_occlusion/ s_occlusion|occlusion]]). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

[[Image:Drawsounds_shot03.png]]

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled). 
You can not see the difference between ''O'' and ''D'' in this shot due to rounding. 

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of doom's crude sound units):

[[Image:Drawsounds_shot02.png]]

''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 14, but gets capped equivalent to maxDistance.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read. :)

Issues: 
* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
* Sometimes the red lines can go to weird places. Esp. with ''s_drawSounds 2'' all inactive entitites seem to point at a common origin.
* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

== Getting the Volume right ==

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use [[Setting Up Speakers#volume/ s_volume|the ''s_volume'' property]].

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

<code>s_clipvolumes 0</code>

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

<code>s_showLevelMeters 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (''bind n toggle s_useOcclusion'').

<code>com_showdecoders 1</code>: Will draw a few lines on your screen, showing the sounds currently playing.

[[Category:Sound]]
[[Category:Editing]]

Setting Up Speakers

2010-11-28T17:12:30Z

Plasticman:

This article shows how a mapper can drop a speaker entity in the map and set it up correctly in DarkRadiant. The focus is on shoundshader keywords and how to override them.

== Create A Speaker Entity ==

To create a speaker you can simply click {{RMB}} in DarkRadiant and select "Create speaker...". This will:
* create a speaker entity
* open a window that lets you choose a sound
After choosing a sound you can alter the sound's properties in the entity inspector.

To do that it is handy to know how sounds in our game basically work. Via sound shaders, that is:

== Sound Shaders And Spawnargs ==

A sound shader is a text file that resides in darkmod/sounds and comes with the .sndshd extension. These shaders tell the engine where the .waves or .oggs can be found along with some common parameters.

As an example we look at the shader for "footsteps on stone materials while walking" (you would not put these in game via a speaker normally, but you ''could'' do it since all sounds work technically the same):

<pre>
tdm_footstep_stone_walk
{
description "Made by GoldChocobo"
no_dups
minDistance 1
maxDistance 30
volume -12

sound/sfx/movement/footsteps/player/stone_walk01.ogg
sound/sfx/movement/footsteps/player/stone_walk02.ogg
sound/sfx/movement/footsteps/player/stone_walk03.ogg
sound/sfx/movement/footsteps/player/stone_walk04.ogg
}
</pre>

It starts with the shader name "tdm_footstep_stone_walk". This will show up in DarkRadiant's "Choose sound" dialog. Then we have some keywords followed by the actual sound files and their relative path.

There are four sounds (not only one) to allow variety. They get played in a random order, one each time the sound is triggered. (In most cases, see [[Problem Hearing Varied Sounds]].)

Picking the ''volume'' keyword you can see it is followed by a negative value. These are meant to be decibel (dB), so we can expect 0 to be the maximum while a reduction by 10 approximately is half the volume.

If you created your speaker and wanted to change it's volume in DarkRadiant you would go to the entity inspector (default shortcut: n) and add the spawnarg ''s_volume''. Whatever number you enter here is meant to override the shader setting.

This is what it looks like:

[[Image:Entity-inspector-speaker.png]]

The icons left to the keyword indicate Radiant knows them -- you will get a tooltip on mouseover. If you mistype anything you will see nothing there, which is a good indicator.

So what we have is a system where our shaders provide the default values. We can override these values in the map file using the appropriate spawnargs. Note that not defining anything in the shader as well as in your map file won't crash the game -- there are still fallback values (propably hardcoded in the engine).

In the following list the keywords are presented as a pair, where possible. The soundshader keyword is followed by the corresponding counterpart you would use in DR.

=== volume/ s_volume ===

:The ''volume'' is set in dB. Usually this means there is a maximum of ''0'' dB. The minimum is ''-60'' dB which results in absoulute silence.

:Up to a certain point the game allows the use of positive values as well, but be aware, as this is sensitive:

:To prevent clipping the engine has a mechanism that does not allow the ''volume'' to overdrive your sound hardware. For testing, it can be disabled via the ''s_clipVolumes'' cvar, but if it is active it will clip the ''volume'' for every output sound channel after all the other calculations are done -- this includes stereo panning, so once the volume setting is too high all the speakers (in your headphones, on your stereo) will play the sound at the same maximum volume. It gets virtually monofied, the player no longer is able to locate the sound.

:In general it is a good idea to stay close within the ''0'' dB range for positive values.

=== unclamped/ s_unclamped ===

:Possible values are ''0'' and ''1''. This overrides the global ''volume'' clipping and will make your sound bypass the ''s_clipVolumes'' setting.

:Should be used with extra care, can trigger hardware clipping. This will not damage your hardware, but sound real crappy -- keep in mind this is a game and not your favourite tube amp.

=== minDistance/ s_mindistance ===

:This works together with ''maxDistance'' like this:

:[[Image:Mindistance-maxdistance-falloff.png]]

:Around the speaker there is a spherical volume, defined by ''minDistance''. Inside that, the sound plays at the specified full ''volume''. The (hopefully) larger ''maxDistance'' defines a bigger sphere. Outside of it the ''volume'' will be ''0'', inside of it there is a falloff from max. to min.

:Note: '''Do not set ''s_mindistance'' to ''0''!'''

:While a real sound does not have a "mindistance" it will not work to set ''s_mindistance'' to ''0''. A quick test revealed the following behavior:

:[[Image:Mindistance-overrides.png]]

:This shows we can overide the shader values with our spawnarg in DR, but when we set it to ''0'' it counts not as a number but as a toggle that simply disables our intended input. This is as good as deleting the property.

:The value will fall back to the shader default (lucky case is purple, bad cases are red). In the right column (red and yellow field) you can see what happens when no values are provided by the shader nor the spawnarg: doom simply sets the ''minDistance'' to ''1''.

:As a resort mappers can always use ''s_mindistance 1'', that's close enaugh for rock'n'roll.

=== maxDistance/ s_maxdistance ===

:See above. The outlines of ''maxDistance'' can be drag-resized in DarkRadiant. This does not show you the real dispersion of the sound in most cases (due to occlusion, see below).

:Not setting the ''maxDistance'' or at the same time setting ''s_maxdistance'' to ''0'' (which is insane anyway) will cause doom to use ''10'' instead.

=== looping/ s_looping ===

:Turns on and off looping. The sound will repeat endlessly in a forward loop.

=== omnidirectional/ s_omni ===

:The sound will have the same ''volume'' on all speakers, so it sounds like not having a specific origin. Normally used for ambience music (when not using the preferred method via [[Location Settings]]). Works with falloff as provided by ''minDistance'' and ''maxDistance''.

=== global/ s_global ===

:Plays the sound at full ''volume'' everywhere in the map.

=== no_occlusion/ s_occlusion ===

:The shader keyword turns occlusion off, ''s_occlusion'' must be set to ''1'' for the same effect (this is counterintuitive).

:'''What is occlusion?''' -- To resemble a realistic falloff for sounds, the game traces the route to the speaker from the player position through vis_portals instead of line of sight. Even closed doors or windows are taken into account for that calculation.

:If you want your specific sound to be not affected by this, you can turn it off this way.

:Note: it is highly recommended to turn occlusion off for ambient music, or it will fade when you close a door etc.

=== shakes/ s_shakes ===

:A special effect, that shakes the screen when the sound plays. Possible values are fractions between ''0'' and ''1''. This is multiplied with the ''volume'' to determine the intensity of the effect.

:Note: ''s_shakes 0'' will disable itself and fall back to the ''shakes'' value in the shader.

:Note2: Iddevnet says it should not be used with .ogg files.

=== n. a./ s_waitfortrigger ===

:If set to ''1'' the speaker will wait for a trigger to activate it.

=== n. a./ s_shader ===

:Points to the sound shader the speaker uses. Can as well be used to reference audio files directly, when not present in any shader.

=== leadin/ n. a. ===

:Specifies a file that is played as a lead-in to a looped part of the sound.

=== leadinVolume/ n. a. ===

:''Volume'' of the lead-in part in a looped sound.

=== no_dups/ n. a. ===

:This prevents the same audio file out of the multiple ones in a shader to be played twice in a row when randomly playing them.

:Not of any use when your shader references only one file.

=== private/ n. a. ===

:The sound is only present to the player.

=== description/ n. a. ===

:A short discription in the shader. In DarkMod it usually names the creator of the sound.

== See Also ==

When you set up a few sounds, you propably like to check them out in game. Learn about additional tools for [[Debugging Your Speakers]].

Unfortunately I missed [[Sounds: Background and Local]], before creating a bit of an overlap with this article.

Further information can be found at [http://www.modwiki.net/wiki/Sound_(keywords) modwiki.net] or [http://www.iddevnet.com/doom3/sounds.php iddevnet].

[[Category:Sound]]
[[Category:Editing]]

Debugging Your Speakers

2010-11-28T16:56:32Z

Plasticman:

This is some sort of a follow-up, please read first [[Setting Up Speakers]].

== Don't forget your ears ==

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player. 
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

== Make Speakers visible with s_drawSpeakers ==

Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:

<code>s_drawSpeakers 1</code>

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

<code>s_drawSpeakers 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

and means:

::''<name>'': the name of the shader or sound
::''O'': relative distance to the player (with occlusion)
::''D'': real distance to the player
::''min'': the ''minDistance''
::''max'': the ''maxDistance''
::''n'': the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

<code>r_showportals 1</code>

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account ([[Setting Up Speakers#no_occlusion/ s_occlusion|occlusion]]). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

[[Image:Drawsounds_shot03.png]]

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled). 
You can not see the difference between ''O'' and ''D'' in this shot due to rounding. 

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of doom's crude sound units):

[[Image:Drawsounds_shot02.png]]

''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 8, but gets capped equivalent to maxDistance.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read. :)

Issues: 
* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
* Sometimes the red lines can go to weird places. Esp. with ''s_drawSounds 2'' all inactive entitites seem to point at a common origin.
* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

== Getting the Volume right ==

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use [[Setting Up Speakers#volume/ s_volume|the ''s_volume'' property]].

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

<code>s_clipvolumes 0</code>

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

<code>s_showLevelMeters 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (''bind n toggle s_useOcclusion'').

<code>com_showdecoders 1</code>: Will draw a few lines on your screen, showing the sounds currently playing.

[[Category:Sound]]
[[Category:Editing]]

Debugging Your Speakers

2010-11-28T16:43:54Z

Plasticman: New page: This is some sort of a follow-up, please read first Setting Up Speakers. == Don't forget your ears == There are ways to visualize what's going on with the audio in game, and it can b...

This is some sort of a follow-up, please read first [[Setting Up Speakers]].

== Don't forget your ears ==

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player. 
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

== Make Speakers visible with s_drawSpeakers ==

Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:

<code>s_drawSpeakers 1</code>

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

<code>s_drawSpeakers 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

and means:

::''<name>'': the name of the shader or sound
::''O'': relative distance to the player (with occlusion)
::''D'': real distance to the player
::''min'': the ''minDistance''
::''max'': the ''maxDistance''
::''n'': the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

<code>r_showportals 1</code>

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account (occlusion). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

[[Image:Drawsounds_shot03.png]]

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled). 
You can not see the difference between ''O'' and ''D'' in this shot due to rounding. 

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of doom's crude sound units):

[[Image:Drawsounds_shot02.png]]

''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 8, but gets capped equivalent to maxDistance.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read. :)

Issues: 
* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
* Sometimes the red lines can go to weird places. Esp. with ''s_drawSounds 2'' all inactive entitites seem to point at a common origin.
* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

== Getting the Volume right ==

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use the ''s_volume'' property.

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

<code>s_clipvolumes 0</code>

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

<code>s_showLevelMeters 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (''bind n toggle s_useOcclusion'').

<code>com_showdecoders 1</code>: Will draw a few lines on your screen, showing the sounds currently playing.

File:Drawsounds shot03.png

2010-11-28T15:45:27Z

Plasticman: shows s_drawsounds in action.

shows s_drawsounds in action.

File:Drawsounds shot02.png

2010-11-28T15:45:08Z

Plasticman: shows s_drawsounds in action.

shows s_drawsounds in action.

File:Drawsounds shot01.png

2010-11-28T15:44:17Z

Plasticman: shows s_drawsounds in action.

shows s_drawsounds in action.

Sounds: Background and Local

2010-11-26T22:23:19Z

Plasticman: added link: Setting up Speakers

''written by Fidcal''

== Introduction ==

All that is assumed is you know the essentials described in [[Dark Radiant Must Know Basic Intro]]

If you want a global ambient sound heard throughout your mission then also read [[Adding ambient Sounds to your Map]].

This tutorial covers general background sounds, local ambience, environmental, or sounds related to specific objects in the game such as a machine or a drain.

== Sound File Types ==

OGG and WAV files are used in Dark Mod. For details see [[Sound File Formats]]

OGG files are compressed whereas WAV files do not compress well even in zip files (so I'm told!)

You can create your own sounds but there is already a large range provided in Dark Mod ready to use.

Those sound files can be referenced either directly (with full path and name) or via a definition file called a sound shader which can include various controls as well as the name of the sound file and path. Multiple sound file definitions can be included in one sound shader file. Other controls are available as properties in the speaker entity in the map file. These properties will override the equivalent definition in the sound shader.

== Speaker Entity ==

The speaker entity is like a loudspeaker that you place in your mission.

To include a sound in your mission...

* create a speaker entity and position it where you want the sound to be centred.
* Add the property s_shader
* In Dark Radiant you can select a sound shader from the button below the entity properties.

== Properties of the Speaker Entity ==

The following are properties to add to the speaker entity to adjust the way it plays sounds. There is no need to dmap between adjustments of these properties. Assuming you have dmapped once you can just use map to test changes.

Before proceeding, it's worth quoting Orbweaver:

# If a speaker is looping, it will play all the time, but will obviously only be audible when the player is within range.
# If a speaker is non-looping but waits for trigger, then it will do nothing until triggered. Once triggered it will play but will only be audible if the player is within range.
# If a speaker is non-looping and untriggered, it will play once at startup, irrespective of whether the player is near enough to hear it.

== Loudness, Volume ==

The '''s_volume''' property allows you to change the volume of a sound. It specifies the change to the volume of the audio file, in decibels, and may be positive or negative.

Be careful about making sounds too loud with this keyvalue, decibels are fairly "small" units and setting a volume increase of +20dB may well make the sound too loud for players. Ambient sounds should be at a similar volume throughout the map, and should not be so loud as to obliterate important gameplay sounds such as footsteps, or cause the player to reach for their volume control every time they enter a new area.

== Control of volume by 'Ambient Volume' menu setting ==
If you want to give the player user-friendly control over the sound volume (as with ambient music, which some players prefer off), include the keypair "s_music" "1" on the speaker entity.

== Direction of Source, Propogation through Doorways==

s_occlusion 1 makes the sound go in a straight line and not through visportalled gaps like doorways etc. If set to 0 then it follows a natural route through openings.

s_omni 1 makes the sound come from no particular direction so this is ideal for ambience like rainfall or mood music (unless that music is meant to come from something in the game.) Set s_omni to 0 if you want your sound to sound like it is coming from the speaker entity.

== Range, Radius, Distance covered by Sound ==

The units used for the distance reached by the speaker entity are in ''metres'' not Doom units so these approximate 40 normal units. In DoomEd the radius is shown in the grid view and this feature is also being added to Dark Radiant.

* s_mindistance N = distance in metres from speaker at which sound starts to fade. Within that radius it is at full volume.

* s_maxdistance N = distance in metres from speaker beyond which it cannot be heard at all.

==Triggering a Sound==

Speakers by default will start to play at mission start even if the player is not in range to hear them. But speakers can be set to wait for a trigger - so any switch, button or other trigger can start and stop them. To do this, set the property s_waitfortrigger to 1 then the speaker is disabled until triggered by a switch of some sort. Default is 0.

== Playing a Sound Once ==

By default, if no looping or repeat is set up then a speaker will play once at mission start then stop. But unless the player is within range it will not be heard.

So to play a sound once when the player approaches you need a separate vicinity trigger (see also [[#Triggering a Sound]]) that triggers only once. This is how...

* Create and place your speaker and give it the property ''s_waitfortrigger'' with a value of 1
* At the place where you want the player to trigger the sound create a brush with a volume suitable for the trap so the player will pass into it.
* With the brush selected, assign it (create) an entity ''trigger_once''
* The brush automatically gets a ''trigger'' texture which is invisible in-game.
* Add the property ''target'' with the value being the name of your speaker.

When the player moves into that invisible brush it should trigger the speaker to play its sound once only.

== Repeating a Sound Continuously ==

=== s_looping ===

s_looping repeats a sound seamlessly and is the one to use for continuous sound like rain, continuous machinery, etc. (compare also [[#wait (repeat)|wait]] before using this.

s_looping set to 1 means...

# Play sound immediately the player is within range (set by s_maxdistance)
# Wait until the sound has finished playing
# Repeat endlessly unless the player moves out of range (set by s_maxdistance)

Set s_looping to 0 to disable (default)

=== wait (repeat) ===

wait n means repeat every n seconds endlessly so is the one to use to repeat with a gap between plays of the sound. Do NOT use it with s_looping set to 1 because 'wait' repeats on its own and s_looping will override it and repeat immediately and endlessly.

wait n means...

# Play sound immediately the player is within range (set by s_maxdistance)
# Wait n seconds from START of playing sound
# Repeat endlessly unless the player moves out of range (set by s_maxdistance)

What if n is shorter than the length of the wav or ogg file? If there is only a single sound in the sound shader file then it cuts the sound short and starts again. Here's an example of what happens If, eg, you play a bell sound that is 6 seconds long (the original ogg or wav file) and if you set wait 1 then it will...

# start to play the sound
# plays it for 1 second
# will not complete that but...
# begin again at the start every 1 second.

However, if there are multiple sounds in the sound shader file which are selected randomly then they one will be played every N seconds and they will overlap unless it happens to call the same one twice in a row (which can be prevented with nodupes in the sound shader file.)

Use with random to vary the wait time...

=== random ===

Use with the wait property to vary the repeat time. random n varies the wait time randomly by plus or minus n seconds. So for example...

* wait 30
* random 10

...will play the sound repeatedly between 20 to 40 seconds from the start of playing the sound.

If random is greater than wait then it works the same but with a minimum of zero, so....

* wait 10
* random 15

... will play the sound repeatedly between 0 and 25 seconds from the start of playing the sound.

he sound no directional source, ie, it will not seem to come from the direction of the speaker but from all directions.

== Screen Shaking, Explosions, etc. ==

s_shakes set to 1 makes the screen shake when the sound is loud. Suitable for explosions, earthquakes.

==Sound Shader Definition Files==

This to be written. It might need a separate article in which case adjust the link above. Meanwhile here is an external link...

http://www.iddevnet.com/doom3/sounds.php

[[Setting Up Speakers]] aims to cover shaders as well. 
(apologies for the overlap btw., plasticman)

[[Category:Sound]]
[[Category:Editing]]

Adding ambient Sounds to your Map

2010-11-25T04:10:21Z

Plasticman: /* See also */ added link to Setting Up Speakers

''written by greebo''

Ok, I will try to explain how to get a nice ambient sound into your map. Note that this ambient sound can be heard everywhere in your level. If you want to have certain areas playing certain ambients, this won't do the trick for you. For that there are two different options, a speaker approach which builds off this tutorial (described at the bottom of this tutorial, [[Adding_ambient_Sounds_to_your_Map#Ambient_Sounds_in_one_Area]]), and a zone approach described at [[Ambient Sounds, a zone approach]], with the zone approach being the most powerful way to do it.

== Choose your Ambient Sound ==
All the Dark Mod ambient sounds are saved in the '''/sound/ambient/ambience''' folder. Fire up your preferred Media Player and pick one that's suitable for your map. We will use the sound '''darknessfalls.ogg''' for this tutorial.

The according sound shaders are stored in the '''/sound/tdm_ambient_ambience.sndshd''' file. Open it with the text editor of your choice and find the name of the sound shader. Our chosen sound is defined in this block:

darknessfalls
{
description "Made by Darkness_Falls"
sound/ambient/ambience/darknessfalls.ogg
}

The string outside of the curly braces is the name of the sound shader. We will need it for accessing it later via [[DarkRadiant]].

== Create a Speaker ==
Open up your map in [[DarkRadiant]] and right-click somewhere in the orthogonal view and choose "Create Entity...":

http://img124.imageshack.us/img124/9261/createentityss3.jpg

Select speaker.
And voilà, the newly created green box is your speaker. You can drag it anywhere you want in your map, the actual place is irrelevant to the ambient.

http://img133.imageshack.us/img133/1650/createdspeakerib9.jpg

== Set the correct Key/Values ==
The following key/values have to be set:
s_shader <Name of the sound shader to be played>
s_looping 1
s_global 1
s_omni 1
s_volume -5

In the Entity Inspector it should look like this:

http://img301.imageshack.us/img301/8067/entityinspectoreo1.jpg

A short explanation what these values do:
* '''s_shader''' is the name of the sound shader being played. Nothing special here, just beware of typos.
* '''s_looping''' should be set if you want to repeat your sound over and over. If this is set to 0, your sound will stop after one playback.
* '''s_global''' this the key that makes the sound ambient, so it can be heard everywhere. There is no need for '''s_min''' or '''s_max''' as the sound plays with the same volume everywhere.
* '''s_omni''' this makes the sound play from every direction, as it is supposed to do for an ambient.
* '''s_volume''' negative values to be subtracted from the volume of your sound 0(max) to -60(silent.) Note that the right volume heavily depends on the loudness of the actual ogg file and the nature of the ambient being played. Typical values might be -2 or --6, -8 etc. whereas -20 is barely heard. Just experiment a bit with the value until you're satisfied...

== Save the Map and test it ==
This is all there is to say, I believe. If you have problems with hearing your chosen ambient, be sure to check for typos in both the entity keys as well as in the sound shaders.

== Ambient Sounds in one Area ==
''added by demagogue''

To localize an ambient sound in a particular area, the easiest method is to place the speaker in the area where you want the sound. (As explained at the top of this tutorial, an alternative method is a "location" approach, described at [[Ambient Sounds, a zone approach]]. The following only discusses the speaker method).

Set up a speaker just as described above, with a few important property changes.

* First, change '''s_global 0'''

* Second, place the speaker in the center of where you want your sound to be localized, or anyway where you want the center of the radius to be for the source of your sound (e.g., if you're using multiple speakers).

* Third, now you need to add a radius in which the sound will play. Add the following two properties to the speaker: '''s_maxdistance''' and '''s_mindistance'''.

:Set '''s_maxdistance''' with a value to fill the area you want to hear it. This is the radius at which the volume tapers to zero. For some reason the distance is not in Doom Units but roughly 1:39.3 Doom Units, that is, 1 s_maxdistance unit = about 40 Doom units. So keep that in mind.

:Set''' s_mindistance''' with a value only slightly smaller. This is the radius inside of which the volume is at its maximum (defined by s_volume). Between the max and min distance, the volume will increase from zero to s_volume with a nice fade in, or fade out if you go in the opposite direction.

:To visually see the radius in Dark Radiant, there is an icon at the top of the Dark Radiant window that looks like a speaker with an X over it. Press it and you can see the maxdistance and mindistance radius. Adjust the placement of the speaker and max and min distances so that it fills the space you want covered by the ambient. Because of the "omni"/1 property, it still sounds like the ambient is coming from all directions (not the speaker), but there is still the nice fade in/fade out effect between the max and mindistances.

You should check for intrusion of the radius into other areas where they are not wanted, and you can control that to some extent with falloff at visportals and doors.

It is possible to have ambient speakers with overlapping radiuses (radii?). If the sound is the same, e.g., if the area requires more than one speaker to fill out, then the sound will be duplicated, but if you watch placement and radius, and pay attention to how the ambient sound works, it won't be too noticable. (Note: if you're having problems with either intrusion into other areas or don't like how the speaker-overlap is working to fill an area, consider using the alternative trigger method mentioned above.)

It is also possible to have ambient speakers with different sounds with slightly overlapping radiuses, and in fact that is often a good thing. As the old ambient fades out, the new one fades in, making for a nice transition.

Here is an example of three ambient sounds set up:

http://i43.tinypic.com/dpiqzm.jpg

And that's it. Once the speaker is placed, it turns itself on and off by itself when you are in the radius. Very simple. Save, dmap and run the map, then walk in and out of the area to test how the ambient works in-game.

== Using Custom Ambients ==

:A more detailed explanation for adding custom ambients to your map is here: [[Ambient_Sounds_-_Zone_%28using_triggers%29#Tips_and_Issues]], under the heading's "Custom Soundshaders" and "Custom Ambients".

:When using normal speakers, the set up is basically the same, but there's a possible shortcut. Here's the set up in a nutshell, which should be enough information to do it without referring to that other wiki page, though it's there for reference:

:First, to package your custom ambient, create a folder inside your .pk4 file (a .zip file renamed .pk4) named "sound", and inside that folder create a new folder with your FM's name or an abbreviated form, i.e., "your_mission's_name.pk4/sound/your_mission's_name". Put your sound file in that second folder. Remember it has to be in .ogg or .wav format.

:E.g., my mission is named "Patently Dangerous" and I placed a custom ambient named "ambient_frozen.ogg" in "patently_dangerous.pk4/sound/patent/ambient_frozen.ogg". (Note, during testing, when you run the game through the console, you need to temporarily put the sound file in "darkmod/sound/your_missions_name" to hear it.)

:Now to get the custom ambient playing in your speaker, you can EITHER:

::1. Use a custom soundshader, which you put in the "sound" folder in your .pk4 (or "darkmod/sound" when running the game through the console). Use the name of the entry in that soundshader for your ambient in the speaker's "s_shader" spawnarg key. In my case, I could have used "s_shader"/"ambient_frozen".

::The other wiki page I mentioned goes into more detail on creating a custom soundshader. But basically just remember it's a text file, renamed to have a .sndshd extension, a custom file name like your_mission_name.sndshd, the proper syntax for the soundshader's entries, and most important that there is a line to the address of your ambient. In my case, that would be a line that says "sound/patent/ambient_frozen.ogg".

::So I had a soundshader named "patently_dangerous.sndshd", inside "patently_dangerous.pk4/sound/patently_dangerous.sndshd" that had this entry:

<code>
ambient_frozen
{
description "Made by alacazam"
global
omnidirectional
looping
volume -10
sound/patent/ambient_frozen.ogg
}
</code>

:OR

::2. As a shortcut, you can directly enter the address of the custom ambient as the value for the "s_shader" spawnarg. So for my custom ambient, I could have just had a speaker with a spawnarg key/value of "s_shader" / "patently_dangerous.pk4/sound/patent/ambient_frozen.ogg".

::Then you can add all the other details like "s_volume"/xx, "s_looping"/1, "s_omni"/1, "s_global"/1 (or s_global/0, s_maxdistance/xx, s_mindistance/xx) directly into the speaker as spawnargs, and not have a custom soundshader at all. Very convenient. In fact so convenient that I recommend you do it this easier way rather than messing with creating a custom soundshader unless you have a special reason to, if only to keep your custom additions tidy and not spread across multiple places.

== See also ==
* [[Ambient Sounds, a zone approach]]
* [[Setting Up Speakers]]
* [[Sound File Formats]]
* [[Sounds: Background and Local]]

[[Category:Tutorial]]
[[Category:Sound]]
[[Category:Editing]]

Setting Up Speakers

2010-11-25T03:43:49Z

Plasticman: changed intro, added screenshot, fixed typos

This article shows how a mapper can drop a speaker entity in the map and set it up correctly in DarkRadiant. The focus is on shoundshader keywords and how to override them.

== Create A Speaker Entity ==

To create a speaker you can simply click {{RMB}} in DarkRadiant and select "Create speaker...". This will:
* create a speaker entity
* open a window that lets you choose a sound
After choosing a sound you can alter the sound's properties in the entity inspector.

To do that it is handy to know how sounds in our game basically work. Via sound shaders, that is:

== Sound Shaders And Spawnargs ==

A sound shader is a text file that resides in darkmod/sounds and comes with the .sndshd extension. These shaders tell the engine where the .waves or .oggs can be found along with some common parameters.

As an example we look at the shader for "footsteps on stone materials while walking" (you would not put these in game via a speaker normally, but you ''could'' do it since all sounds work technically the same):

<pre>
tdm_footstep_stone_walk
{
description "Made by GoldChocobo"
no_dups
minDistance 1
maxDistance 30
volume -12

sound/sfx/movement/footsteps/player/stone_walk01.ogg
sound/sfx/movement/footsteps/player/stone_walk02.ogg
sound/sfx/movement/footsteps/player/stone_walk03.ogg
sound/sfx/movement/footsteps/player/stone_walk04.ogg
}
</pre>

It starts with the shader name "tdm_footstep_stone_walk". This will show up in DarkRadiant's "Choose sound" dialog. Then we have some keywords followed by the actual sound files and their relative path.

There are four sounds (not only one) to allow variety. They get played in a random order, one each time the sound is triggered. (In most cases, see [[Problem Hearing Varied Sounds]].)

Picking the ''volume'' keyword you can see it is followed by a negative value. These are meant to be decibel (dB), so we can expect 0 to be the maximum while a reduction by 10 approximately is half the volume.

If you created your speaker and wanted to change it's volume in DarkRadiant you would go to the entity inspector (default shortcut: n) and add the spawnarg ''s_volume''. Whatever number you enter here is meant to override the shader setting.

This is what it looks like:

[[Image:Entity-inspector-speaker.png]]

The icons left to the keyword indicate Radiant knows them -- you will get a tooltip on mouseover. If you mistype anything you will see nothing there, which is a good indicator.

So what we have is a system where our shaders provide the default values. We can override these values in the map file using the appropriate spawnargs. Note that not defining anything in the shader as well as in your map file won't crash the game -- there are still fallback values (propably hardcoded in the engine).

In the following list the keywords are presented as a pair, where possible. The soundshader keyword is followed by the corresponding counterpart you would use in DR.

=== volume/ s_volume ===

:The ''volume'' is set in dB. Usually this means there is a maximum of ''0'' dB. The minimum is ''-60'' dB which results in absoulute silence.

:Up to a certain point the game allows the use of positive values as well, but be aware this is sensitive:

:To prevent clipping the engine has a mechanism that does not allow the ''volume'' to overdrive your sound hardware. For testing, it can be disabled via the ''s_clipVolumes'' cvar, but if it is active it will clip the ''volume'' for every output sound channel after all the other calculations are done -- this includes stereo panning, so once the volume setting is too high all the speakers (in your headphones, on your stereo) will play the sound the same maximum volume. It gets virtually monofied, the player no longer is able to locate the sound.

:In general it is a good idea to stay close within the ''0'' dB range for positive values.

=== unclamped/ s_unclamped ===

:Possible values are ''0'' and ''1''. This overrides the global ''volume'' clipping and will make your sound bypass the ''s_clipVolumes'' setting.

:Should be used with extra care, can trigger hardware clipping. This will not damage your hardware, but sound real crappy -- keep in mind this is a game and not your favourite tube amp.

:(The usual doom way to deal with this is debugging your map with ''s_levelmeters 1'', I think. It is supposed to draw a nice level meter for every channel in the upper left corner -- sadly this is broken in TDM atm.)

=== minDistance/ s_mindistance ===

:This works together with ''maxDistance'' like this:

:[[Image:Mindistance-maxdistance-falloff.png]]

:Around the speaker there is a spherical volume, defined by ''minDistance''. Inside that, the sound plays at the specified full ''volume''. The (hopefully) larger ''maxDistance'' defines a bigger sphere. Outside of it the ''volume'' will be ''0'', inside of it there is a falloff from max. to min.

:Note: '''Do not set ''s_mindistance'' to ''0''!'''

:While a real sound does not have a "mindistance" it will not work to set ''s_mindistance'' to ''0''. A quick test revealed the following behavior:

:[[Image:Mindistance-overrides.png]]

:This shows we can overide the shader values with our spawnarg in DR, but when we set it to ''0'' it counts not as a number but as a toggle that simply disables our intended input. This is as good as deleting the property.

:The value will fall back to the shader default (lucky case is purple, bad cases are red). In the right column (red and yellow field) you can see what happens when no values are provided by the shader nor the spawnarg: doom simply sets the ''minDistance'' to ''1''.

:As a resort mappers can always use ''s_mindistance 1'', that's close enaugh for rock'n'roll.

=== maxDistance/ s_maxdistance ===

:See above. The outlines of ''maxDistance'' can be drag-resized in DarkRadiant. This does not show you the real dispersion of the sound in most cases (due to occlusion, see below).

:Not setting the ''maxDistance'' or at the same time setting ''s_maxdistance'' to ''0'' (which is insane anyway) will cause doom to use ''10'' instead.

=== looping/ s_looping ===

:Turns on and off looping. The sound will repeat endlessly in a forward loop.

=== omnidirectional/ s_omni ===

:The sound will have the same ''volume'' on all speakers, so it sounds like not having a specific origin. Normally used for ambience music (when not using the preferred method via [[Location Settings]]). Works with falloff as provided by ''minDistance'' and ''maxDistance''.

=== global/ s_global ===

:Plays the sound at full ''volume'' everywhere in the map.

=== no_occlusion/ s_occlusion ===

:The shader keyword turns occlusion off, ''s_occlusion'' must be set to ''1'' for the same effect (this is counterintuitive).

:'''What is occlusion?''' -- To resemble a realistic falloff for sounds, the game traces the route to the speaker from the player position through vis_portals instead of line of sight. Even closed doors or windows are taken into account for that calculation.

:If you want your specific sound to be not affected by this, you can turn it off this way.

:Note: it is highly recommended to turn occlusion off for ambient music, or it will fade when you close a door etc.

=== shakes/ s_shakes ===

:A special effect, that shakes the screen when the sound plays. Possible values are fractions between ''0'' and ''1''. This is multiplied with the ''volume'' to determine the intensity of the effect.

:Note: ''s_shakes 0'' will disable itself and fall back to the ''shakes'' value in the shader.

:Note2: Iddevnet says it should not be used with .ogg files.

=== n. a./ s_waitfortrigger ===

:If set to ''1'' the speaker will wait for a trigger to activate it.

=== n. a./ s_shader ===

:Points to the sound shader the speaker uses. Can as well be used to reference audio files directly, when not present in any shader.

=== leadin/ n. a. ===

:Specifies a file that is played as a lead-in to a looped part of the sound.

=== leadinVolume/ n. a. ===

:''Volume'' of the lead-in part in a looped sound.

=== no_dups/ n. a. ===

:This prevents the same audio file out of the multiple ones in a shader to be played twice in a row when randomly playing them.

:Not of any use when your shader references only one file.

=== private/ n. a. ===

:The sound is only present to the player.

=== description/ n. a. ===

:A short discription in the shader. In DarkMod it usually names the creator of the sound.

== See Also ==

When you set up a few sounds, you propably like to check them out in game. Learn about additional tools for [[Debugging Your Speakers]].

Further information can be found at [http://www.modwiki.net/wiki/Sound_(keywords) modwiki.net] or [http://www.iddevnet.com/doom3/sounds.php iddevnet].

[[Category:Sound]]
[[Category:Editing]]

File:Entity-inspector-speaker.png

2010-11-25T03:24:06Z

Plasticman: DR entity inspector with a speaker entity and spawnargs.

DR entity inspector with a speaker entity and spawnargs.

Volume Issues

2010-11-25T02:50:30Z

Plasticman: links added to "proper" articles

::The following is qouted from the forum.
::Compare "proper" articles in the making: [[Setting Up Speakers]] and [[Debugging Your Speakers]]

''by Plasticman''

I did some reading on iddevnet and checked a few things in game.

I think Orb is right: the volume gets capped on both channels so the sound virtually moves to the center. I consider this a bug in doom, though it only appears once the assets are produced "wrong". Still it should not break the left vs. right balance.

The mechanism can be controlled globally via the s_clipVolumes cvar (works instantly without restarting anything) and locally (overriding the cvar) via the unclamped keyword in the soundshader (always wondered what this bes). Any sound that comes with this declaration will not be clipped in doom no matter what the cvar is -- this means it will be clipped by the hardware if it is too loud. :D

So, the purpose of dooms clipping is to prevent overdriving your audio hardware, some sort of "fuse" that normally should not get triggered by the assets.

Although volume refers to a decibel value (and thus defaults to 0) there seems to be a little headroom. There are roundabout 3400 shader declarations in vanilla doom that use the volume keyword. Positive values distribute like this:

volume / number of shader declarations

> 0 : 1441
> 5 : 430
> 10 : 83
> 15 : 54
> 20 : 8

The maximum is 30 (used 2 times). I guess the few with real high values are only rarely used in situations where it doesn't matter, like cutscenes etc.; some of the others are important for gameplay and this is what I think the headroom is meant for, so you can "lift" some of the more important sounds over the usual ambience buzz.

How much space there is I don't know. But I assume it does not work like a limiter in an audio app -- they wouldn't waste any CPU resources for audio processing when those are needed for calculating shadow volumes. So it likely does not matter how much dB your sound really is, the audio data gets treated like 0 dB plus what the shader says.

If I am right with that assumption the Pro needs some dynamic processing besides fixing in the shader. Here is a comparison shot:

== s_drawsounds ==
There is a cvar to make sounds visible: s_drawsounds. "0" disables it, "1" shows sounds that can be heard at the moment, "2" seems to draw all sounds. This will show a box where the speaker is and label it something like this:

rock_door_loop (3/3 2/26)
9
That translates to
<shader> (a/b c/d)
e

Where a is the calculated distance (through doors and portals), b is the real distance (line of sight), c is minDistance, d maxDistance and e seems to be the number of the speaker.

This little tool showed me there are quite a few sounds in game that seem to work with a minDistance of 0. But when I set up a speaker in Radiant with s_minDistance 0 it shows up in game with minDistance 20, independent of the other factors (vol., maxdist.).

My map file looks fine in a text editor, so it must be (again) doom's fault: minDistance 0 works, s_minDistance 0 gets "converted" to 20.

Sound

2010-11-25T02:39:21Z

Plasticman: linked "Setting Up Speakers"

{{index-page|category=Sound|topic=sounds}}
Here you will find information about the sounds and how you add them to your level.

* [[Adding ambient Sounds to your Map]]
* [[Estimating Volume for New Sounds]]
* [[Faked lipsync]], and how to turn it off for specific sounds
* [[Moveables: Surface Type-dependent Bounce Sound]]
* [[Problem Hearing Varied Sounds]]
* [[Reaction to Material Types]]
* [[Setting up Individual Propagated Sounds and Estimating Volume]]
* [[Setting Up Speakers]] -- Soundshader keywords and how mappers can override them
* [[Setting Reverb Data of Rooms (EAX)]]
* [[Sound Folderstructure]]
* [[Sound File Formats]]
* [[Sound Propagation: Part 1]]
* [[Sound Propagation: Part 2]]
* [[Volume Issues]] -- info from the board about a D3 bug with volume; as well as good developer cvar to make sounds visible

{{sound}}

Setting Up Speakers

2010-11-24T09:42:20Z

Plasticman: /* omnidirectional/ s_omni */ -- fixed broken link.

To bring your mission to life it needs more than just geometry. While players may not know it consciously, they want your DarkMod mission to be an excellent aural experience.

== Create A Speaker Entity ==

To create a speaker you can simply click {{RMB}} in DarkRadiant and select "Create speaker...". This will:
* create a speaker entity
* open a window that lets you choose a sound
After choosing a sound you can alter the sound's properties in the entity inspector.

To do that it is handy to know how sounds in our game basically work. Via sound shaders, that is:

== Sound Shaders And Spawnargs ==

A sound shader is text file that resides in darkmod/sounds and comes with the *.sndshd extension. These shaders tell the engine where the .waves or .oggs can be found along with some common parameters.

As an example we look at the shader for "footsteps on stone materials while walking" (you would not put these in game via a speaker normally, but you ''could'' do it since all sounds work technically the same):

<pre>
tdm_footstep_stone_walk
{
description "Made by GoldChocobo"
no_dups
minDistance 1
maxDistance 30
volume -12

sound/sfx/movement/footsteps/player/stone_walk01.ogg
sound/sfx/movement/footsteps/player/stone_walk02.ogg
sound/sfx/movement/footsteps/player/stone_walk03.ogg
sound/sfx/movement/footsteps/player/stone_walk04.ogg
}
</pre>

It starts with the shader name "tdm_footstep_stone_walk". This will show up in DarkRadiant's "Choose sound" dialog. Then we have some keywords followed by the actual sound files and their relative path.

There are four sounds (not only one) to allow variety, they get played in a random order when the sound is triggered. (In most cases, see [[Problem Hearing Varied Sounds]].)

Picking the ''volume'' keyword you can see it is followed by a negative value. These are meant to be decibel (dB), so we can expect 0 to be the maximum while a reduction by 10 approximately is half the volume.

If you created your speaker and wanted to change it's volume in dark radiant you would go to the entity inspector and add the spawnarg ''s_volume''. Whatever number you enter here is meant to override the shader setting.

So what we have is a system where our shaders provide the default values. We can override these values in the map file using the appropriate spawnargs. Note that not defining anything in the shader as well as in your map file won't crash the game -- there are still fallback values (propably hardcoded in the engine).

In the following list the keywords are presented as a pair, where possible. The soundshader keyword is followed by the corresponding counterpart you would use in DR.

=== volume/ s_volume ===

:The ''volume'' is set in dB. Usually this means there is a maximum of ''0'' dB. The minimum is ''-60'' dB which results in absoulute silence.

:Up to a certain point the game allows the use of positive values as well, but be aware this is sensitive:

:To prevent clipping the engine has a mechanism that does not allow the ''volume'' to overdrive your sound hardware. For testing, it can be disabled via the ''s_clipVolumes'' cvar, but if it is active it will clip the ''volume'' for every output sound channel after all the other calculations are done -- this includes stereo panning, so once the volume setting is too high all the speakers (in your headphones, on your stereo) will play the sound the same maximum volume. It gets virtually monofied, the player no longer is able to locate the sound.

:In general it is a good idea to stay close within the ''0'' dB range for positive values.

=== unclamped/ s_unclamped ===

:Possible values are ''0'' and ''1''. This overrides the global ''volume'' clipping and will make your sound bypass the ''s_clipVolumes'' setting.

:Should be used with extra care, can trigger hardware clipping. This will not damage your hardware, but sound real crappy -- keep in mind this is a game and not your favourite tube amp.

:(The usual doom way to deal with this is debugging your map with ''s_levelmeters 1'', I think. It is supposed to draw a nice level meter for every channel in the upper left corner -- sadly this is broken in TDM atm.)

=== minDistance/ s_mindistance ===

:This works together with ''maxDistance'' like this:

:[[Image:Mindistance-maxdistance-falloff.png]]

:Around the speaker there is a spherical volume, defined by ''minDistance''. Inside that, the sound plays at the specified full ''volume''. The (hopefully) larger ''maxDistance'' defines a bigger sphere. Outside of it the ''volume'' will be ''0'', inside of it there is a falloff from max. to min.

:Note: '''Do not set ''s_mindistance'' to ''0''!'''

:While a real sound does not have a "mindistance" it will not work to set ''s_mindistance'' to ''0''. A quick test revealed the following behavior:

:[[Image:Mindistance-overrides.png]]

:This shows we can overide the shader values with our spawnarg in DR, but when we set it to ''0'' it counts not as a number but as a toggle that simply disables our intended input. This is as good as deleting the property.

:The value will fall back to the shader default (lucky case is purple, bad cases are red). In the right column (red and yellow field) you can see what happens when no values are provided by the shader nor the spawnarg: doom simply sets the ''minDistance'' to ''1''.

:As a resort mappers can always use ''s_mindistance 1'', that's close enaugh for rock'n'roll.

=== maxDistance/ s_maxdistance ===

:See above. The outlines of ''maxDistance'' can be drag-resized in DarkRadiant. This does not show you the real dispersion of the sound in most cases (due to occlusion, see below).

:Not setting the ''maxDistance'' or at the same time setting ''s_maxdistance'' to ''0'' (which is insane anyway) will cause doom to use ''10'' instead.

=== looping/ s_looping ===

:Turns on and off looping. The sound will repeat endlessly in a forward loop.

=== omnidirectional/ s_omni ===

:The sound will have the same ''volume'' on all speakers, so it sounds like not having a specific origin. Normally used for ambience music (when not using the preferred method via [[Location Settings]]). Works with falloff as provided by ''minDistance'' and ''maxDistance''.

=== global/ s_global ===

:Plays the sound at full ''volume'' everywhere in the map.

=== no_occlusion/ s_occlusion ===

:The shader keyword turns occlusion off, ''s_occlusion'' must be set to ''1'' for the same effect (this is counterintuitive).

:'''What is occlusion?''' -- To resemble a realistic falloff for sounds, the game traces the route to the speaker from the player position through vis_portals instead of line of sight. Even closed doors or windows are taken into account for that calculation.

:If you want your specific sound to be not affected by this, you can turn it off this way.

:Note: it is highly recommended to turn occlusion off for ambient music, or it will fade when you close a door etc.

=== shakes/ s_shakes ===

:A special effect, that shakes the screen when the sound plays. Possible values are fractions between ''0'' and ''1''. This is multiplied with the ''volume'' to determine the intensity of the effect.

:Note: ''s_shakes 0'' will disable itself and fall back to the ''shakes'' value in the shader.

:Note2: Iddevnet says it should not be used with .ogg files.

=== ------/ s_waitfortrigger ===

:If set to ''1'' the speaker will wait for a trigger to activate it.

=== ------/ s_shader ===

:Points to the sound shader the speaker uses. Can as well be used to reference audio files directly, when not present in any shader.

=== leadin/ ------ ===

:Specifies a file that is played as a lead-in to a looped part of the sound.

=== leadinVolume/ ------ ===

:''Volume'' of the lead-in part in a looped sound.

=== no_dups/ ------ ===

:This prevents the same audio file out of the multiple ones in a shader to be played twice in a row when randomly playing them.

:Not of any use when your shader references only one file.

=== private/ ------ ===

:The sound is only present to the player.

=== description/ ------ ===

:A short discription in the shader. In DarkMod it usually names the creator of the sound.

== See Also ==

When you set up a few sounds, you propably like to check them out in game. Learn about additional tools for [[Debugging Your Speakers]].

Further information can be found at [http://www.modwiki.net/wiki/Sound_(keywords) modwiki.net] od [http://www.iddevnet.com/doom3/sounds.php iddevnet].

[[Category:Sound]]

Setting Up Speakers

2010-11-24T09:17:34Z

Plasticman: Speaker setups focusing on shader keywords and spawnargs

To bring your mission to life it needs more than just geometry. While players may not know it consciously, they want your DarkMod mission to be an excellent aural experience.

== Create A Speaker Entity ==

To create a speaker you can simply click {{RMB}} in DarkRadiant and select "Create speaker...". This will:
* create a speaker entity
* open a window that lets you choose a sound
After choosing a sound you can alter the sound's properties in the entity inspector.

To do that it is handy to know how sounds in our game basically work. Via sound shaders, that is:

== Sound Shaders And Spawnargs ==

A sound shader is text file that resides in darkmod/sounds and comes with the *.sndshd extension. These shaders tell the engine where the .waves or .oggs can be found along with some common parameters.

As an example we look at the shader for "footsteps on stone materials while walking" (you would not put these in game via a speaker normally, but you ''could'' do it since all sounds work technically the same):

<pre>
tdm_footstep_stone_walk
{
description "Made by GoldChocobo"
no_dups
minDistance 1
maxDistance 30
volume -12

sound/sfx/movement/footsteps/player/stone_walk01.ogg
sound/sfx/movement/footsteps/player/stone_walk02.ogg
sound/sfx/movement/footsteps/player/stone_walk03.ogg
sound/sfx/movement/footsteps/player/stone_walk04.ogg
}
</pre>

It starts with the shader name "tdm_footstep_stone_walk". This will show up in DarkRadiant's "Choose sound" dialog. Then we have some keywords followed by the actual sound files and their relative path.

There are four sounds (not only one) to allow variety, they get played in a random order when the sound is triggered. (In most cases, see [[Problem Hearing Varied Sounds]].)

Picking the ''volume'' keyword you can see it is followed by a negative value. These are meant to be decibel (dB), so we can expect 0 to be the maximum while a reduction by 10 approximately is half the volume.

If you created your speaker and wanted to change it's volume in dark radiant you would go to the entity inspector and add the spawnarg ''s_volume''. Whatever number you enter here is meant to override the shader setting.

So what we have is a system where our shaders provide the default values. We can override these values in the map file using the appropriate spawnargs. Note that not defining anything in the shader as well as in your map file won't crash the game -- there are still fallback values (propably hardcoded in the engine).

In the following list the keywords are presented as a pair, where possible. The soundshader keyword is followed by the corresponding counterpart you would use in DR.

=== volume/ s_volume ===

:The ''volume'' is set in dB. Usually this means there is a maximum of ''0'' dB. The minimum is ''-60'' dB which results in absoulute silence.

:Up to a certain point the game allows the use of positive values as well, but be aware this is sensitive:

:To prevent clipping the engine has a mechanism that does not allow the ''volume'' to overdrive your sound hardware. For testing, it can be disabled via the ''s_clipVolumes'' cvar, but if it is active it will clip the ''volume'' for every output sound channel after all the other calculations are done -- this includes stereo panning, so once the volume setting is too high all the speakers (in your headphones, on your stereo) will play the sound the same maximum volume. It gets virtually monofied, the player no longer is able to locate the sound.

:In general it is a good idea to stay close within the ''0'' dB range for positive values.

=== unclamped/ s_unclamped ===

:Possible values are ''0'' and ''1''. This overrides the global ''volume'' clipping and will make your sound bypass the ''s_clipVolumes'' setting.

:Should be used with extra care, can trigger hardware clipping. This will not damage your hardware, but sound real crappy -- keep in mind this is a game and not your favourite tube amp.

:(The usual doom way to deal with this is debugging your map with ''s_levelmeters 1'', I think. It is supposed to draw a nice level meter for every channel in the upper left corner -- sadly this is broken in TDM atm.)

=== minDistance/ s_mindistance ===

:This works together with ''maxDistance'' like this:

:[[Image:Mindistance-maxdistance-falloff.png]]

:Around the speaker there is a spherical volume, defined by ''minDistance''. Inside that, the sound plays at the specified full ''volume''. The (hopefully) larger ''maxDistance'' defines a bigger sphere. Outside of it the ''volume'' will be ''0'', inside of it there is a falloff from max. to min.

:Note: '''Do not set ''s_mindistance'' to ''0''!'''

:While a real sound does not have a "mindistance" it will not work to set ''s_mindistance'' to ''0''. A quick test revealed the following behavior:

:[[Image:Mindistance-overrides.png]]

:This shows we can overide the shader values with our spawnarg in DR, but when we set it to ''0'' it counts not as a number but as a toggle that simply disables our intended input. This is as good as deleting the property.

:The value will fall back to the shader default (lucky case is purple, bad cases are red). In the right column (red and yellow field) you can see what happens when no values are provided by the shader nor the spawnarg: doom simply sets the ''minDistance'' to ''1''.

:As a resort mappers can always use ''s_mindistance 1'', that's close enaugh for rock'n'roll.

=== maxDistance/ s_maxdistance ===

:See above. The outlines of ''maxDistance'' can be drag-resized in DarkRadiant. This does not show you the real dispersion of the sound in most cases (due to occlusion, see below).

:Not setting the ''maxDistance'' or at the same time setting ''s_maxdistance'' to ''0'' (which is insane anyway) will cause doom to use ''10'' instead.

=== looping/ s_looping ===

:Turns on and off looping. The sound will repeat endlessly in a forward loop.

=== omnidirectional/ s_omni ===

:The sound will have the same ''volume'' on all speakers, so it sounds like not having a specific origin. Normally used for ambience music (when not using the preferred method via [[location settings]]). Works with falloff as provided by ''minDistance'' and ''maxDistance''.

=== global/ s_global ===

:Plays the sound at full ''volume'' everywhere in the map.

=== no_occlusion/ s_occlusion ===

:The shader keyword turns occlusion off, ''s_occlusion'' must be set to ''1'' for the same effect (this is counterintuitive).

:'''What is occlusion?''' -- To resemble a realistic falloff for sounds, the game traces the route to the speaker from the player position through vis_portals instead of line of sight. Even closed doors or windows are taken into account for that calculation.

:If you want your specific sound to be not affected by this, you can turn it off this way.

:Note: it is highly recommended to turn occlusion off for ambient music, or it will fade when you close a door etc.

=== shakes/ s_shakes ===

:A special effect, that shakes the screen when the sound plays. Possible values are fractions between ''0'' and ''1''. This is multiplied with the ''volume'' to determine the intensity of the effect.

:Note: ''s_shakes 0'' will disable itself and fall back to the ''shakes'' value in the shader.

:Note2: Iddevnet says it should not be used with .ogg files.

=== ------/ s_waitfortrigger ===

:If set to ''1'' the speaker will wait for a trigger to activate it.

=== ------/ s_shader ===

:Points to the sound shader the speaker uses. Can as well be used to reference audio files directly, when not present in any shader.

=== leadin/ ------ ===

:Specifies a file that is played as a lead-in to a looped part of the sound.

=== leadinVolume/ ------ ===

:''Volume'' of the lead-in part in a looped sound.

=== no_dups/ ------ ===

:This prevents the same audio file out of the multiple ones in a shader to be played twice in a row when randomly playing them.

:Not of any use when your shader references only one file.

=== private/ ------ ===

:The sound is only present to the player.

=== description/ ------ ===

:A short discription in the shader. In DarkMod it usually names the creator of the sound.

== See Also ==

When you set up a few sounds, you propably like to check them out in game. Learn about additional tools for [[Debugging Your Speakers]].

Further information can be found at [http://www.modwiki.net/wiki/Sound_(keywords) modwiki.net] od [http://www.iddevnet.com/doom3/sounds.php iddevnet].

[[Category:Sound]]

File:Mindistance-overrides.png

2010-11-24T08:06:52Z

Plasticman: Overriding behavior of the s_mindistance spawnarg.

Overriding behavior of the s_mindistance spawnarg.

File:Mindistance-maxdistance-falloff.png

2010-11-24T08:02:48Z

Plasticman: Illustrates the minDistance/maxDistance model for sound propagation.

Illustrates the minDistance/maxDistance model for sound propagation.