Dragon Age Toolset Wiki - User contributions [en]

2DA

2009-11-21T15:14:38Z

Imgettingpissedoff: /* Extending the game via M2DAs */

Many of the properties of objects in the toolset make reference to 2DAs (two-dimensional arrays). These are read-only arrays containing various data used by scripting and the game engine. For example, the set of local variables that an object supports is defined in a 2DA.

The source files for 2DAs are Microsoft Excel worksheets. This allows a wide variety of sophisticated techniques to be used to generate the values of the 2DA fields, such as macros and formulas. It also makes editing much easier since the columns can be annotated and formatted in helpful ways, and multiple related worksheets can be grouped into one file.

Data in a 2DA is identified by a row number, with the first row (row zero) usually being reserved for internal use (undefined value, etc.) by convention. Each row has an arbitrary number of columns identified by strings.

Before they can be used by the toolset or the game, 2DAs must be converted from Excel files into a more efficient form. Processed 2DAs are stored in files with the .[[GDA]] extension.

== Excel file formatting ==

Cell A1 will contain "ID". This is checked by the processor and the worksheet will fail if this is not the case.

Column A starting at line 3 will contain an integer row ID number that is unique to that row across all files (unless creating an M2DA override). Row IDs will be listed from smallest to highest within the same file and do not need to be consecutive.

A blank row or column will determine the dimension of the spreadsheet in that direction. Everything past that point is ignored by the binarizer.

Column names are case sensitive. This is because of the CRC32 algorithm used to generate the hash key. Changing the case of a column name after it is in use will break the game. White space before and after a column name will be removed before hashing.

Row 2 will be a "types" row. Each is a single word: [[int]], [[string]] (single chars as well), [[resource]], [[float]] or [[bool]]. A special type "[[comment]]" can be used to exclude a column from export.

Any column with string data that refers to files should have a type of "resource" and not "string". This is because the "resource" type is used to determine dependencies for the 2DA file.

'bool' type may be one of: a zero or non-zero number, Yes or No (case insensitive), or words beginning with T or F (such as True! and False!). NOTE: You cannot use TRUE and FALSE because Excel converts those to a special keyword the binarizer can't parse properly at this time. '''Note:''' the scripting language doesn't have a function for retrieving boolean values from a 2DA, and the behavior of Get2DAInt when retrieving a boolean is untested. It is probably safer to just use an integer for scripting purposes.

If you wish to leave a cell unfilled, the string "****" (four asterisks) can be inserted instead of a value.

Any worksheets that are not exportable 2DA data will have an underscore prepended to their name - the resource builder will subsequently ignore them.

Worksheets need to have unique names among all excel files, duplicates will overwrite each other as each worksheet is exported as a file

You cannot have the workbook open in Excel at the same time as running the binarizer on it.

Strings have a maximum length of 768 characters. Anything longer will be truncated.

== Extending the game via M2DAs ==

An "M2DA" is a "Multiple 2DA" that stacks a number of 2DA files into one larger table. They work much like single 2DA files except they can be patched or expanded later by adding more resources. These are useful for any table that lists other resources, such as appearance tables, so that new resources can be added later without having to modify a monolithic table.

This is especially important for third-party modders, since BioWare might release an update to a core table at a later date that would overwrite any changes third parties had made to it. By using an M2DA with a unique name, and by using a range of ID numbers significantly separated from those already in use, you can ensure that your additions won't conflict with other portions of the M2DA.

A list of all M2DAs used by the game can be found in [[2DA_base.xls]]. Every 2da listed in M2DA_base is treated as a M2DA, except for those with an ID between 10000 and 10999 which are handled as regular 2DAs. Each M2DA has a label that describes the subject covered by the M2DA and a worksheet prefix that all components of that M2DA must use.

Every worksheet listed in M2DA_base is actually a prefix. The system reads this prefix and then searches through all the 2DAs for the ones starting with this prefix and merges them together as one 2DA. For example: M2DA Id 0 is "ANIM_". The system looks through its list of 2das and finds "ANIM_base", "ANIM_combat" and "ANIM_walk". It will read and merge all 3 2DAs into an M2DA called "ANIM_".

Not all of the prefixes end in an underscore. For example, longsword variations are in worksheets prefixed with "longsword_variation", so both "longsword_variation_candyland" and "longsword_variationcandyland" would work as M2DA worksheet names.

2DAs are merged row by row, keyed on the ID column. If two rows in two different 2DAs to be merged have the same ID, the row in the 2da with the highest priority wins.

== Adding 2DA export to the Windows XP file explorer ==

Here's an easy way to add a context menu item that quickly converts new or updated Dragon Age Excel files into GDA format:

Setup:

# Open Windows Explorer and click Tools | Folder Options.
# In the File Types tab, select the XLS extension from the list and click the Advanced button.
# Click the New button and put 'Binarize 2DA' in the Action field.
# Paste the following in the Application field and click OK (update the drive and folder names to match your client): <tt>C:\DA\tag\main\ResourceBuild\Processors\ExcelProcessor.exe "%l" -outdir=C:\DA\tag\main\build\packages\core\override</tt>

Note that paths with spaces in them can cause Windows trouble, if your paths have spaces in them remember to wrap them in quotation marks.

Usage:

# Using Windows Explorer, navigate to your 2DA folder (in my case C:\DA\tag\main\data\Source\2DA) and select the Excel file(s) to process. Right click and select 'Binarize 2DA' from the context menu.
# Confirm a corresponding GDA file is created in your override folder (in my case C:\DA\tag\main\build\packages\core\override) for each Excel file processed.

== Step-by-Step ==

If you have problems using the 2daExporter.xls spreadsheet to generate 2DAs the following method may work instead:

*Create two folders called C:\2DA\ and C:\2DA\Override\
*Copy ExcelProcessor.exe to C:\2DA\
*Copy the Excel spreadsheets containing the 2DA you want to use in the game to C:\2DA\
*Create a batch file with the following line in it (change "placeables.xls" to whatever Excel file you're working with):
C:\2DA\ExcelProcessor.exe placeables.xls -outdir=C:\2DA\override\
*Run your batch file
*Find the GDA file from the C:\2DA\Override\ directory and copy it to the game's override directory. Remember to take into account the naming conventions of M2DAs; you may need to rename your 2DA files with a new suffix unique to your module to allow it to add to the core 2DAs without conflict.

== 2DA XLS files used in Dragon Age ==

''Note: This list is very incomplete right now''

Bear in mind that 2DAs names are actually based on the names of the worksheets inside these Excel files, not the names of the files themselves. Some of these files contain a large number of individual 2DAs within them. They are bundled together into Excel files based on the nature of the 2DAs for convenience.

=== Creatures ===

*[[APR_base.xls]] - appearance types for creatures
*[[ABI_base.xls]] - integrates all talents and spells into the game
*[[ANIM_base.xls]]
*[[ANIM_combat.xls]]
*[[ANIM placeables.xls]]
*[[SyncAnimations.xls]]
*[[CLA_base.xls]] - Defines the character classes used throughout the game
*[[background.xls]] - defines the various origin stories available to each race and class.

=== Objects ===
*[[placeables.xls]] - interactive object types
*[[BITM base.xls]] - item types
*[[ItemVariations.xls]] - item appearance variations (eg, all the different ways a longsword can look)
*[[PRJ_base.xls]] - how various projectiles look and behave
*[[VFX_base.xls]] - Visual effects

=== Areas and plots ===

*[[worldmaps.xls]] - world maps for open-ended travel between areas
*[[plottypes.xls]] - how plots are grouped at the highest level in the game GUI (codex entry types, story, etc.)
*[[areadata.xls]] - sets various properties for specific areas
*[[rewards.xls]] - rewards for plot completion

== Adding Strings ==

When adding strings to a 2DA, you have two options. The simplest is to enter **** for the StringID column. In that case, the name column will be used in the game.

The other approach is to use the toolset's string editor to create a new string. When that happens, you'll get a new StringID. Next enter that number into the StringID column in the 2DA.

The second approach works better when translating your module, at the cost of portability. If someone else wanted to reuse your 2DA, they'd have to generate their own strings, then update the StringID number based on these IDs.

'''Attention:'''

The current version of the "Exelprocessor"-App is buggy as it can't hanlde INT values above 8388607! Many thx to elys for figuring that out.
Also note that the current toolset core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory.

'''Workaround:'''

* Create and export your talktable, delete the core-talktable override.
* Create your M2DA File that you want to refer to your talk-table strings. Never Mind using the real IDs at this stage.
* Use the "Exelprocessor" to create the GDA file.
* Open the GDA-File with the toolset or elys's GDA-Editor App (http://social.bioware.com/project/755/)
[[File:Edit-GDA-Values.jpg]]
* Change the StringIDs to the StringIDs in your talktable.

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong.

[[Category:2DAs]]

Template:Generated with joins

2009-11-21T10:11:42Z

Imgettingpissedoff:

<div align="center" style="background-color:#FFF7F0; border:2px #FF7f00 solid; padding:4px; margin:4px;">
This page was generated by '''Sunjammer's Dragon Age Script Parser'''.

The parser was able to extract and/or match all the information required, however it has flagged this page as containing one or more joins. A join occurs when the parser encounters a single line entry (such as ''parameter'' descriptions or ''remarks'') which has been split over multiple lines. The parser joins these lines together to prevent the information being omitted, however any original formatting will have been lost.

This page must be reviewed by a knowledgeable scripter as it will probably require updating. If the join occurred in a parameter description it will probably be necessary to move the additional information to the '''Description''' section below. Once identified, the issue in the source file should be reported to '''BioWare'''.

Please remove the '''<nowiki>{{Generated with joins}}</nowiki>''' tag once the page has been corrected.
</div>
[[Category: Generated with joins]]<noinclude></noinclude>

Template:Generated with errors

2009-11-21T10:06:30Z

Imgettingpissedoff:

<div align="center" style="background-color:#FFF7F7; border:2px #F70000 solid; padding:4px; margin:4px;">
This page was generated by '''Sunjammer's Dragon Age Script Parser'''.

The parser was unable to extract and/or match all the information required and has flagged this page as containing one or more errors. The source file was not formatted correctly and the information presented is incomplete or incorrect.

This page must be reviewed by a knowledgeable scripter as it will need to be updated. Once identified, the issue in the source file should be reported to '''BioWare'''.

Please remove the '''<nowiki>{{Generated with errors}}</nowiki>''' tag once the page has been corrected.
</div>
[[Category: Generated with errors]]<noinclude></noinclude>

Template:Generated

2009-11-17T01:53:40Z

Imgettingpissedoff:

<div align="center" style="background-color:#F7FFF7; border:2px #00AA00 solid; padding:4px; margin:4px;">
This page was generated by '''Sunjammer's Dragon Age Script Parser'''.

The parser extracted and matched all the information required to the best of its ability however the parser relies on the source file, and especially a function's comments, to be correctly formatted. If the source file was not correctly formatted the information presented may be incomplete.

This page should be reviewed by a knowledgeable scripter as it may require updating. If an issue with the source file is identified it should be reported to '''BioWare'''.

Please remove the '''<nowiki>{{Generated}}</nowiki>''' tag once the page has been confirmed or corrected.
</div>
[[Category: Generated]]<noinclude></noinclude>

Scripting tutorial

2009-11-17T01:32:02Z

Imgettingpissedoff: /* Event type constants */

The final piece of the puzzle in our little tutorial game is getting the <code>MONSTERS_SLAIN</code> flag set on our plot so that when the hero succeeds in his quest, the quest giver will know about it. This is done via scripting.

Scripting is a programming language with a syntax similar to C. This tutorial assumes a small amount of programming knowlege but hopefully it will be possible even for one with no experience to pick up the basics here.

== Dragon Age's event-driven model ==

In Dragon Age scripts are primarily event-driven. An "event" is a package of information in a special format that gets passed around in the game to trigger behaviour. They are generated by other scripts or the game engine and are passed to an object's event-handling script.

Events have a type, a target object, a time delay and a package of parameters (arbitrary number of ints, objects, floats and strings).

As an example, the "<code>[[EVENT_TYPE_ATTACK_IMPACT]]</code>" event is sent by the game engine whenever an attack hits a target. It contains the identities of the attacker and the target, whether the attack was a critical hit, and the amount of damage that the attack did. It is sent to an event-handling script attached to the attacker, which takes the information it contains and handles it in whatever way is appropriate (reducing the target's hit points, usually).

For our purposes right now we're not going to need to generate any events of our own. We have set all of the hut monsters to be members of team 1, and the game has a built-in feature that will generate an event when all of the members of a particular team of creatures has been killed. Our new script will respond to that event by setting the plot flag so that when the hut monsters are all defeated, the plot will change to indicate the quest objective has been accomplished.

An enormous list of events for all occasions can be found at the [[event]] page. The one we're going to want our script to look for is <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code>, which is sent when the last member of a team of creatures is destroyed. The event contains the team number within it.

== Creating a basic event-handling script ==

Start by creating a new script resource. We'll call our script "<code>hut_monsters_slain</code>".

In most cases when a script is run the scripting engine will start with a function named "<code>main</code>". So for most scripts you'll want to start with this very basic beginning:

<pre>
void main()
{

}
</pre>

The code that will perform our tasks will be inserted between the { and } brackets. <code>main</code> doesn't return any results directly, so the function's return type is "<code>[[void]]</code>", and it takes no parameters, so the parameter list is an empty ().

=== Event type constants ===

Next we're going to need to make sure the script will know what we're talking about when we make references to events. The tag that tells us the type of each event is actually represented internally by a number, but since it would be impossible for a programmer to keep track of all the different event numbers without making hard-to-find mistakes Dragon Age has instead used named constants to represent them in a more human-readable name.

Those constants are defined in the script <code>events_h</code>. The "<code>_h</code>" suffix stands for "header", which is a special class of script that contains only various definitions meant to be included in other scripts and doesn't do anything on its own.

To include the header file, add this line to the top of our script:

<pre>#include "events_h"</pre>

All <code>#include</code> commands should be at the top of your script before anything else, but if there's more than one it shouldn't matter what order they are in.

To see whether our script now knows what <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> means you can use the constant browser on the right edge of the script editor to check if it's listed. The browser defaults to showing a list of all defined functions (the "f()" button), to set it to show all defined constants click on the "C" button.

[[Image:Scripting constant browser.png]]

Even without any included files the list of defined constants is going to be quite long, and for scripts with many include files it can be very difficult to find any particular constant - especially if you aren't sure exactly what its name is. To find constants more easily, type any part of its name into the filter field at the top.

[[Image:Scripting constant browser filtered.png]]

To insert the constant into the script at the location where the cursor is currently located, simply double-click on the constant in the constant browser. This avoids any risk of making a typo.

=== Extracting information about the current event ===

When an event is sent to a script the script's <code>main</code> function will be run, but it won't know anything about the event that caused it to be run without some explicit instructions.

First, you will need to retrieve the package of data that is the event. We'll define a variable named <code>ev</code> that will hold this package, and set it to the "<code>event</code>" data type. To retrieve the current event and stick it into that variable, we'll use the engine-defined function <code>[[GetCurrentEvent]]</code>.

The first line of the main function will therefore be:
<code>event ev = GetCurrentEvent();</code>

Every event will have an event type. As described above, this event type is represented internally by an integer. We'll create an integer variable named <code>nEventType</code> to hold it, and use the <code>GetEventType</code> function to extract it from <code>ev</code>. The next line will be:

<code>int nEventType = [[GetEventType]](ev);</code>

The rest of the information packaged with the event depends on exactly what kind of event it is, so the rest of the code we write will be event-specific. To make sure only the correct code is run we'll use a <code>switch</code> statement. We're only looking for one particular event so we could just as easily have used an <code>if</code> statement but a <code>switch</code> is more extendable for future use.

<pre>
switch(nEventType)
{
case EVENT_TYPE_TEAM_DESTROYED:
{
//our event-specific code goes here
break;
}
}
</pre>

We know from the documentation for the <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> event, that it comes with a single piece of information; the team number. It's an integer, so we can extract it with the <code>[[GetEventInteger]]</code> function. <code>[[GetEventInteger]]</code> takes two parameters, the event object (which we've stored in the variable <code>ev</code>) and the index of the integer we want, in this case 0 (this is listed in the documentation).

We also know that the team number we gave the hut monsters is 1, so we want to update the plot only when we receive an event indicating that team number 1 has been destroyed. We can do this with an <code>if</code> statement:

<pre>
if (GetEventInteger(ev,0) == 1)
{
//code to update the plot here
}
</pre>

== Interacting with plots ==

To interact with a plot's flags you'll need to have some way for the script to know where the plot flags are and what they're named. This is done in a similar manner to how we told the script what the event types were named; by including the plot file in the script.

Plots are not the same as regular scripts, though, so when including them they are distinguished from regular scripts through the use of a <code>plt_</code> prefix in their name. The plot we wish to interact with is called <code>clear_the_hut</code>, so at the top of the script file you'll need to put the line:

<code>#include "plt_clear_the_hut"</code>

Now your script will have access to the plot's flags and will be able to read or change them. You'll find that several new constants have been defined; <code>PLT_CLEAR_THE_HUT</code> contains the plot object, and the integer constants <code>MONSTERS_SLAIN</code>, <code>QUEST_ACCEPTED</code> and <code>REWARD_RECEIVED</code> identify the flags within the plot.

Changing the state of the flags is done with the <code>WR_SetPlotFlag</code> function that is defined in the include file <code>wrappers_h</code> (<code>wrappers_h</code> contains a variety of utility functions that handle operations requiring low-level access to the game. Add <code>#include "wrappers_h"</code> to the top of your script). In our case, we want to set the plot flag <code>MONSTERS_SLAIN</code>. The <code>WR_SetPlotFlag</code> function takes three parameters; the plot identifier, the flag identifier, and the state we want to set it to:

<pre>
WR_SetPlotFlag(PLT_CLEAR_THE_HUT, MONSTERS_SLAIN, TRUE);
</pre>

== Associating an event script with an object ==

The script is almost complete now, but until we've linked it up to some object in the game that can receive events it will never actually be run.

Most objects in the game will have a field named "Script" shown in the object inspector. According to the documentation for the <code>EVENT_TYPE_TEAM_DESTROYED</code> event it is sent to the area object the team is in, so we'll want to open the hut_interior area now and go to its Script entry. The default event script for areas is <code>area_core</code>, which handles basic area events in a default way.

This is where you'll want to put the <code>hut_monsters_slain</code> script. Click on the ellipsis ([[Image:ellipsis.png]]) button and select the new script. It will replace <code>area_core</code>, and now when there are events sent to this area our new script will be triggered and handle them.

=== Passing execution to other event handlers ===

There is just one problem remaining to be resolved now. As mentioned above, the <code>area_core</code> script normally handles a variety of events that are sent to areas. Now that we've replaced the default event handler with our custom script, and our script only responds to one specific event, there's nothing responding to the rest of the events coming into the area any more. Our custom script has preempted and therefore effectively disabled all the default area event processing by not responding to every possible area event.

We don't want to re-implement all that default event handling in our own script, for a variety of reasons; it's a lot of work, we could make mistakes, and it would be difficult to update the default event handling across all of our areas in the future. Fortunately there's an easy way to tell Dragon Age to use another script to handle events; namely, the <code>[[HandleEvent]]</code> function. It takes two parameters, the event object to be handled and an identifier for the script that should handle it.

A set of constants defining identifiers for the common default scripts is in the <code>global_objects_h</code> header file, but we won't need to include that because <code>wrappers_h</code> includes it already. So all we need to do is insert the following line after our switch statement:

<pre>
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);
</pre>

(The RESOURCE_SCRIPT_AREA_CORE constant is defined in global_objects_h, which we don't need to include explicitly in this case because it's already included in wrappers_h.)

With this addition, whenever any event is sent to the hut_interior area, first our script will run and process the event, and then it will send it on to <code>area_core</code> to handle the default area processing normally done when no custom event handling script is being used.

The final text of our script, then, is:

<pre>
#include "events_h"
#include "plt_clear_The_hut"
#include "wrappers_h"

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);

switch(nEventType)
{
case EVENT_TYPE_TEAM_DESTROYED:
{
if(GetEventInteger(ev,0) == 1)
{
WR_SetPlotFlag(PLT_CLEAR_THE_HUT, MONSTERS_SLAIN, TRUE);
}
break;
}
}
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);
}
</pre>

[[Category:Scripts]]
[[Category:Tutorials]]

Template:Generated

2009-11-16T06:31:50Z

Imgettingpissedoff:

<div align="center" style="background-color:#F7FFF7; border:2px #00AA00 solid; padding:4px; margin:4px;">
This page was generated by '''Sunjammer's Dragon Age Script Parser'''.

The parser extracted and matched all the information required to the best of its ability however the parser relies on the source file, and especially a function's comments, to be correctly formatted. If the source file was not correctly formatted the information presented may be incomplete.

This page should be reviewed by a knowledgeable scripter as it may require updating. If an issue with the source file is identified it should be reported to '''BioWare'''.

Please removed the '''<nowiki>{{Generated}}</nowiki>''' tag once the page has been confirmed or corrected.
</div>
[[Category: Generated]]<noinclude></noinclude>

Template:Generated

2009-11-16T06:30:22Z

Imgettingpissedoff:

<div align="center" style="background-color:#F7FFF7; border:2px #00AA00 solid; padding:4px; margin:4px;">
This page was generated by '''Sunjammer's Dragon Age Script Parser'''.

The parser extracted and matched all the information required to the best of its ability however the parser relies on the source file, and especially a function's comments, to be correctly formatted. If the source file was not correctly formatted the information presented may be incomplete.

This page should be reviewed by a knowledgeable scripter as it may require updating. If an issue with the source file is identified it should be reported to '''BioWare'''.

Please removed the '''<nowiki>{{Generated}}</nowiki>''' once the page has been confirmed or corrected.
</div>
[[Category: Generated]]<noinclude></noinclude>

Guitype.xls

2009-11-16T06:27:59Z

Imgettingpissedoff:

{{2da start|GUI Types}}
{{2da column|Label|string|Quick, one or two word, description of what gui type this falls under.}}
{{2da column|StringID|int|Reference to which entry in the talk table is used when displayed.}}
{{2da column|Ability|int|Ability that needs to be present on the character for this uitype to be rendered.}}
{{2da column|ProgressBar|int|0-1. Whether or not to show the progress bar on the UI.}}
{{2da column|CombatTraining|int|0-1. Whether or not this ability requires combat training.}}
{{2da column|SpecialGraphic|int|0-1. Does this ability type use a special graphic for display purposes?}}
{{2da column|TintColor|string|Hexidecimal formated string representing the tint color to use.}}
{{2da column|Orphanage|bool|0-1. {{undocumented}}}}
{{2da column|Flags|int|0-1. A 1 means it is a humanoid ability so something like a wolf cannot use it. Archery, Dual Wield, Weapon and Shield and Two Handed use this.}}
{{2da column|BlendTree|string|{{undocumented}}}}
{{2da end}}

Template:2da start

2009-11-16T06:26:16Z

Imgettingpissedoff:

<includeonly>{| border="1" cellspacing="0" cellpadding="2"
|+ style="font-weight:bold; font-size:120%;" | {{{1|{{{name}}}}}}
|-
! Column name !! Type !! Description
|-
! ID
| align="center" | [[int]]
| An integer row ID number that is unique to that row across all files (unless creating an M2DA override). Row IDs will be listed from smallest to highest within the same file and do not need to be consecutive.
</includeonly><noinclude>
{{2da documentation}}
</noinclude>

Guitype.xls

2009-11-16T06:23:49Z

Imgettingpissedoff: Created page with '{{2da start|GUI Types}} {{2da column|Label|string|Quick, one or two word, description of what gui type this falls under.}} {{2da column|StringID|int|Reference to which entry in t...'

{{2da start|GUI Types}}
{{2da column|Label|string|Quick, one or two word, description of what gui type this falls under.}}
{{2da column|StringID|int|Reference to which entry in the talk table is used when displayed.}}
{{2da column|Ability|int|Ability that needs to be present on the character for this uitype to be rendered.}}
{{2da column|ProgressBar|int|0-1. Whether or not to show the progress bar on the UI.}}
{{2da column|CombatTraining|int|0-1. Whether or not this ability requires combat training.}}
{{2da column|SpecialGraphic|int|0-1. Does this ability type use a special graphic for display purposes?}}
{{2da column|TintColor|string|Hexidecimal formated string representing the tint color to use.}}
{{2da column|Orphanage|bool|0-1. ???}}
{{2da column|Flags|int|0-1. A 1 means it is a humanoid ability so something like a wolf cannot use it. Archery, Dual Wield, Weapon and Shield and Two Handed use this.}}
{{2da column|BlendTree|string|????}}
{{2da end}}

Creature Properties

2009-11-16T05:44:22Z

Imgettingpissedoff: /* PROPERTY_TYPE_ATTRIBUTE */

=== Overview ===

The creature property system is the heart of the rules engine and defines all the numerical values that make up a character in Dragon Age.

=== Detailed Description ===

Properties are 32-bit floating point values associated with every combat capable creature in the game (Creature Type field in the toolset). They are used by engine, scripting and UI to make up and display the RPG ruleset of the game.

==== Property Types ====

There are 3 types of properties that abstract the most common types of statistics found in an RPG:

===== PROPERTY_TYPE_SIMPLE =====

Simple properties are 32 bit floats that can hold a single value and that generally are not modified or influenced by other properties. Examples include Experience, Level or the number of unspent talent points a character has.

===== PROPERTY_TYPE_ATTRIBUTE =====

[[Attribute]]s are a moderately complex set of values encapsulating a single character stat. They have three fields that are independently tracked in the engine and are accessible from scripting:

* Base - A character's unmodified base value, usually only modified during level up and character creation. This number is displayed as a white number on the character sheet.

* Modifier - A float32 that holds the sum of all effect based modifications to the property. This number is shown as a red (if negative) or green (if positive) number on the character sheet.

* Total - The sum of the base and modifier fields along with any in engine modifications done to the property in C++ (for speed reasons) as defined by the engine link field. When reading this field, the engine will always clamp the return values between Min and Max, even though it stores the full, unmodified number internally.

{| style="margin:0; background:#f5fffa; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em; height:100%"
|-
|'''Example:'''
A level 1 warrior with 15 strength, a buff that grants +2 strength and a shield that has a +1 strength enhancement would be stored as as:
* Base: 15
* Modifiers: 3
* Total 18
|}

===== PROPERTY_TYPE_DEPLETABLE =====
Depletables represent the most complex type of stats usually found in an RPG, used for Health and Mana. In addition to all fields present on an Attribute, they have an additional 'Current' field.

* Current - This is the character's current value in this stat, which can be between Min and Max and can exceed Total.

Additionally, just like attributes, the EngineLink field defines some hardcoded behavior in the engine such as creating the link between the 'rengeration rate' properties.

{| style="margin:0; background:#f5fffa; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em; height:100%"
|-
|'''Example:'''
A level 1 warrior with 14 Con and 100 base health and a +5 health ring would store health who was at full health before getting hit for 20 points of damage:
* Base: 100
* Modifiers: +5
* Hidden Engine Modifiers: +20 (5 points for each point in CON after 10).
* Total: 125
* Current: 105

Hidden Engine modifiers can not be modified (obviously, they're in C++), but can be disabled by setting the EngineLink field to 0. They exist purely to speed up stats accessed with high frequency (DAScript has a 7-15x overhead per instruction compared to native code).
|}

==== Property Definitions ====

The two dimensional data array defined in [[Properties.xls]] defines numerical values that exist on every creature in the game. All properties are float32 and all rules logic of the game is based on floating point math. This dynamic data driven approach to rules relevant stats is new to Dragon Age: Origins and makes the engine extremely flexible for Designers. It enables the game to have a rules logic that is almost completely softcoded in script and data.

The following is an excerpt from the 2da that lists all rows present in the initial ship version of Dragon Age: Origins but only shows the most important columns. Note that DLC or expansion content may be overriding individual lines in the 2da.

{| valign="top" border="1" width="100%"
|-|
| '''ID''' || '''Stat''' || '''Type''' || '''Min''' || '''Max''' || '''Comment'''
|-|
| ''int'' || ''string'' || ''string'' || ''float'' || ''float'' || ''comment''
|-|
| 0 || INVALID || INVALID || 0 || 0 ||
|-|
| 1 || Strength || ATTRIBUTE || 0 || 1000 || STR [[Attribute]]
|-|
| 2 || Dexterity || ATTRIBUTE || 0 || 1000 || DEX [[Attribute]]
|-|
| 3 || Willpower || ATTRIBUTE || 0 || 1000 || WIL [[Attribute]]
|-|
| 4 || Magic || ATTRIBUTE || 0 || 1000 || MAG [[Attribute]]
|-|
| 5 || Cunning || ATTRIBUTE || 0 || 1000 || CUN [[Attribute]]
|-|
| 6 || Constitution || ATTRIBUTE || 0 || 1000 || CON [[Attribute]]
|-|
| 7 || Health || DEPLETABLE || 1 || 9999 || Hit Points
|-|
| 8 || Mana_Stamina || DEPLETABLE || 0 || 9999 || Mana or Stamina, based on class
|-|
| 9 || Attack || ATTRIBUTE || 0 || 1000 || Attack Power
|-|
| 10 || Defense || ATTRIBUTE || 0 || 1000 || Defense
|-|
| 11 || Armor || ATTRIBUTE || 0 || 1000 || Armor Mitigation Potential
|-|
| 12 || DamageScale || ATTRIBUTE || 1 || 10 || Based Damage Scaling (for difficulty settings and ranks)
|-|
| 13 || SpellPower || ATTRIBUTE || 0 || 1000 || Spellpower (Max(MAG-10,0)+Effects)
|-|
| 14 || Regeneration_Health || ATTRIBUTE || 0 || 50 || Health Regeneration Rate (Explore Mode) per tick.
|-|
| 15 || Level || SIMPLE || 0 || 99 || Current Character Level.
|-|
| 16 || Displacement || ATTRIBUTE || 0 || 100 || Chance to outright evade any physical attach attempt (aka Dodge)
|-|
| 17 || Inventory_Size || SIMPLE || 0 || 1000 || Inventory Slot size (on party)
|-|
| 18 || AI_BEHAVIOR || SIMPLE || 0 || 1000 || Selected AI Behavior
|-|
| 19 || Experience || SIMPLE || 0 || 186001 || Experience Points
|-|
| 20 || Flanking_Angle || ATTRIBUTE || 0 || 180 || The angle at which this creature is able to flank an enemy (default is 90)
|-|
| 21 || Melee_Crit_Modifier || ATTRIBUTE || -100 || 200 || The +melee crit modifier
|-|
| 22 || Missile_Shield || ATTRIBUTE || 0 || 100 || Chance to avoid missiles (shields and some spells increase this)
|-|
| 23 || Ranged_Crit_Modifier || ATTRIBUTE || -100 || 200 || The +ranged crit modifier
|-|
| 24 || Ranged_Aim_Speed || ATTRIBUTE || -3 || 6 || The character's speed bonus or penality when aiming with ranged weapons
|-|
| 25 || BaseAttackRating || SIMPLE || 0 || 1000 || The creature's cached base attack rating
|-|
| 26 || BaseDefenseRating || SIMPLE || 0 || 1000 || The creature's cached base defense rating
|-|
| 27 || CurrentClass || SIMPLE || 0 || 31 || The creature class (index into cla_base.xls)
|-|
| 28 || Regeneration_Health_Combat || ATTRIBUTE || 0 || 20 || The creature's health regeneration rate (per tick) in combat.
|-|
| 29 || Regeneration_Stamina || ATTRIBUTE || -20 || 50 || The creature's stamina regeneration rate (per tick) in explore mode.
|-|
| 30 || Regeneration_Stamina_Combat || ATTRIBUTE || -20 || 20 || The creature's stamina regeneration rate (per tick) in combat mode.
|-|
| 31 || AttackSpeedModifier || ATTRIBUTE || 0 || 1.5 || The creature's universal melee attack speed modifiers (used by haste, momentum, etc.)
|-|
| 32 || Resistance_Mind || ATTRIBUTE || -100 || 100 || Mental Resistance.
|-|
| 33 || Resistance_Physical || ATTRIBUTE || -100 || 100 || Physical Resistance.
|-|
| 34 || Attribute_points || SIMPLE || 0 || 100 || Holds any unspent attribute points the creature has. If this is != 0, the UI shows the levelup button.
|-|
| 35 || Skill_points || SIMPLE || 0 || 100 || Holds any unspent skill points the creature has. If this is != 0, the UI shows the levelup button.
|-|
| 36 || talent_spell_points || SIMPLE || 0 || 100 ||Holds any unspent talent points the creature has. If this is != 0, the UI shows the levelup button.
|-|
| 37 || Background || SIMPLE || 0 || 10 || The character's origin (index into backgrounds.xls).
|-|
| 38 || specialization_points || SIMPLE || 0 || 2 || Holds any unspent specialization points the creature has.
|-|
| 39 || DamageBonus || ATTRIBUTE || -100 || 100 || Universal physical attack damage bonus on the creature.
|-|
| 40 || Threat_Decrease_Rate || SIMPLE || -1000 || 1000 || The rate at which the creature's threat rating decays.
|-|
| 41 || Fatique || ATTRIBUTE || -25 || 250 || The creature's current [[Fatigue]] (% increase of ability cost).
|-|
| 42 || Damage_Resistance_Fire || ATTRIBUTE || -100 || 75 || The creature's damage resistance to fire. All fire damage is reduce by %.
|-|
| 43 || Damage_Resistance_Cold || ATTRIBUTE || -100 || 75 || The creature's damage resistance to cold. All cold damage is reduce by %.
|-|
| 44 || Damage_Resistance_Electricity || ATTRIBUTE || -100 || 75 || The creature's damage resistance to lightning. All lightning damage is reduce by %.
|-|
| 45 || Damage_Resistance_Nature || ATTRIBUTE || -100 || 75|| The creature's damage resistance to nature. All nature damage is reduce by %.
|-|
| 46 || Damage_Resistance_Spirit || ATTRIBUTE || -100 || 75 || The creature's damage resistance to spirit. All spirit damage is reduce by %.
|-|
| 47 || Damage_Shield_points || ATTRIBUTE || 0 || 9999 || Magical, damage mitigating shield (all damage types) on the creature. Creature immune to damage until the shield is depleted.
|-|
| 48 || Damage_Shield_strength || ATTRIBUTE || 0 || 100 || The maximum amount of damage the creature's magical shields can absorb (not used yet.)
|-|
| 49 || Damage_OffHand || ATTRIBUTE || 0 || 9999 || Display only cache of creature's weapon damage potential. This value is only used to marshal data into the UI, it does not have any rules implications.
|-|
| 50 || Damage_MainHand || ATTRIBUTE || 0 || 9999 || Display only cache of creature's weapon damage potential. This value is only used to marshal data into the UI, it does not have any rules implications.
|-|
| 51 || Healing_Effect_Factor || ATTRIBUTE || 100 || 200 || Percentage modifier of how effective healing is on the creature. Blood magic does NOT use this field, it is coded in effect_heal_h instead.
|-|
| 52 || Spell_resistance || ATTRIBUTE || 0 || 100 || Creature 'hostile magic resistance'. % Chance to avoid any hostile magic.
|-|
| 53 || AP_BONUS || ATTRIBUTE || -100 || 100 || Armor Penetration bonuses are stored her.
|-|
| 54 || CriticalRange || ATTRIBUTE || 0 || 200 || The 'range' which critical hits use. 150 would mean up to 150% of normal damage.
|-|
| 55 || Fire_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all fire damage dealt by the user (spells, staves, etc.)
|-|
| 56 || Spirit_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all spirit damage dealt by the user (spells, staves, etc.)
|-|
| 57 || Cold_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all cold damage dealt by the user (spells, staves, etc.)
|-|
| 58 || Nature_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all nature damage dealt by the user (spells, staves, etc.)
|-|
| 59 || Electricity_Damage_Bonus || ATTRIBUTE || 0 || 30 || Percentage bonus to all lightning damage dealt by the user (spells, staves, etc.)
|}

{| style="margin:0; background:#f5fffa; border:1px solid #a3bfb1; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
| valign="top"|
<h2 style="margin:0; background:red; font-size:150%; font-weight:bold; border:1px solid #a3bfb1; text-align:left; color:#fff; padding:0.2em 0.4em;">Words of Caution</h2>

Properties.xls is the most integral and powerful 2da in the game. Any changes to it have profound implications on the game and the chance of breaking existing savegames and introducing unwanted behavior.

'''Removing Rows'''
It is referenced from many other rules and UI related 2das and removing existing data can have severe consequences, including the invalidation of existing characters. You can NEVER remove rows from this 2da!

'''Changing Rows'''
Changing rows is not as dangerous as removing them, but still can have severe implications. The m2da system should be utilized to modify individual rows instead of overwriting the entire 2da. Especially the Min, Max and EngineLink columns hold a lot of rules relevant data that might not be obvious on the first glance (e.g. the Max value on 'Experience' defines the maximum XP the game will allow on a character. Any attempt to award more XP from script will silently fail.)

'''Adding rows''':
Every row added to this file will reserve several Float32 data fields on every combat capable creature in the game. While a few floats might not sound like a lot, the impact on runtime area memory, savegame size and associated load times can not be overstated. While these issues are more pressing for the console versions of the game, they still do affect the PC version and I strongly advise not to add to this file unless absolutely necessary.

|}

== Q&A ==

=== Q: Why use Floats instead of integers? ===

We had initially investigated a structure that would allow creation of typed properties but found the associated overhead and complexity in such a frequently accessed system to be too high to be worth it.

Since much of our system requires floating point values and floats can be easily rounded for display purposes, we decided to use floating point across the board.

=== Q: Won't floating point math lead to imprecision? ===

Yes, it can. Certain mathematical operations promote imprecision in floating point values. DA script, like NWScript is only precise for a limited number of digits and any existing imprecision can be magnified by consecutive divisions and other operations.

However, there are mitigating circumstances that make this much less of a problem than it might appear on paper (or fresh from university :)

* Most frequent calculations retrieve an existing floating point value cached in a property, run a bunch of calculations and then execute the result (e.g. calculating damage). The resulting values are rarely stored so imprecision has little opportunity to build up over time.

* When writing to values that are displayed as integers on the UI or used as integers in the combat math, we are casting back to integer before storing or computation (e.g. to avoid health from going into the gray realm between 0 and 1).

* Some engine commands have added security to prevent rounding errors from propagating from script into engine stored values.

* If you happen to do .004 points damage more during an attack, the gameplay impact is virtually zero, so even if imprecision manages to propagate up to the 3rd decimal, it is still not visible in the game.

=== Q: Is there anything absolutely hardcoded? ===

Yes. While nearly all C++ implemented aspects of the rules system can be turned off by removing the associated EngineLink from properties.xls, a few behaviors are not easy to modify or replace by script:

* Regeneration. While it is technically possible to turn off regeneration by setting all rates to 0, the system can not be modified. One would have to replace it with a scripted, heartbeat like construct to make changes. The reason for this is simple: Regeneration ticks at a high frequency on all combat capable creatures and the cpu time consumed by running this entirely in script is completely unacceptable.

* Some UI rules are currently hardcoded and although it is possible to control some of the UI through various 2das, replacing the entire UI with a new framework is impossible at this point.

Rewards.xls

2009-11-14T08:33:58Z

Imgettingpissedoff: /* Plot Completion Rewards */

Rewards.xls is used to set up rewards given to players upon the completion of a plot.

{{2da start|plot rewards}}
{{2da column| Label|string| The name you see when you are setting a reward for completing a plot.}}
{{2da column| Copper|int| The amount of copper to reward the player with.}}
{{2da column| Silver|int| The amount of silver to reward the player with.}}
{{2da column| Gold|int| The amount of gold to reward the player with.}}
{{2da column| XP|int| The amount of experience to reward the player with.}}
{{2da column| Item1|string| The resource name of an item to reward the player with, e.g. nw_ring01.uti.}}
{{2da column| Item2|string| ""}}
{{2da column| Item3|string| ""}}
{{2da column| Item4|string| ""}}
{{2da column| Item5|string| ""}}
{{2da column| Item6|string| ""}}
{{2da column| Bonus Ability|int| Reference ID number of a bonus ability to grant to the player. A list can be found in 2da_constants_h in the toolset and [[ABI_base]].}}
{{2da end}}

Rewards.xls

2009-11-13T13:28:55Z

Imgettingpissedoff: Created page with '{{2da start|plot rewards}} {{2da column| Label|string| The name you see when you are setting a reward for completing a plot.}} {{2da column| Copper|int| The amount of copper to r...'

{{2da start|plot rewards}}
{{2da column| Label|string| The name you see when you are setting a reward for completing a plot.}}
{{2da column| Copper|int| The amount of copper to reward the player with.}}
{{2da column| Silver|int| The amount of silver to reward the player with.}}
{{2da column| Gold|int| The amount of gold to reward the player with.}}
{{2da column| XP|int| The amount of experience to reward the player with.}}
{{2da column| Item1|string| The resource name of an item to reward the player with, e.g. nw_ring01.uti.}}
{{2da column| Item2|string| ""}}
{{2da column| Item3|string| ""}}
{{2da column| Item4|string| ""}}
{{2da column| Item5|string| ""}}
{{2da column| Item6|string| ""}}
{{2da column| Bonus Ability|int| Reference ID number of a bonus ability to grant to the player. A list can be found in 2da_constants_h in the toolset and [[ABI_base]].}}
{{2da end}}

User talk:Imgettingpissedoff

2009-11-13T12:55:21Z

Imgettingpissedoff:

== Huh? ==

Something has been bothering me and I'm hoping that someone can help me. Reading through the 2DA page, under the part dealing with the formating of the Excel spreadsheets. This line, specifically the part I put in bold, ''Column A starting at line 3 will contain an integer row ID number that is '''unique to that row across all files''' (unless creating an M2DA override).'', seems to be implying that there can only be one item, throughout all of the 2DA's, that has a row ID of, for example, 1. This is obviously not the case so, if possible, can someone explain exactly what that means?

:It means across all files that are part of the same M2DA. So for example, you could have rows 1-100 in CLA_Base and rows 2000-2010 in CLA_My_Awesome_Extra_Classes, and they'll all be added into the CLA_ M2DA. But if you have rows 1-100 in CLA_Base and rows 1-10 in CLA_My_Awesome_Extra_Classes, the first ten rows of CLA_Base get overridden. [[User:BryanDerksen|BryanDerksen]] 02:49, 13 November 2009 (UTC)

Ah. That makes a lot more sense. Thanks for the clarification.
One more question then. Looking through 2DA_base and M2DA_base I see that, using the CLA_ prefix as per your example, the various .xls' using that are listed in 2DA_base, while just the prefix itself is listed in M2DA_base. Does this mean that a new spreadsheet using the CLA_ prefix needs to be added to 2DA_base so that the converter can find it? Or does it automatically run through all the files in Source\2DA\, and all subdirectories, looking for files using that prefix? Thanks.
[[User:Imgettingpissedoff|Imgettingpissedoff]] 12:55, 13 November 2009 (UTC)

User talk:Imgettingpissedoff

2009-11-12T22:55:03Z

Imgettingpissedoff: /* Huh? */ new section

FMOD

2009-11-11T15:42:15Z

Imgettingpissedoff: /* General techniques - starting up. */

A generic PDF manual for FMOD can be found in the Dragon Age\tools\FMOD Designer\documentation directory. This documentation is tailored more specifically to FMOD's use in Dragon Age. See [[sound]] for how to use the designer toolkit to place sounds within Dragon Age areas.

== Project setup and convention ==

=== Definitions and vocabulary - FMOD particulars ===

<B>FMOD pages:</B>

In FMOD there are certain terms and descriptions for functions that may be different audio middleware to audio middleware. There are 7 pages in FMOD that define different functions that the middleware performs. Listed here is an overview, the details of each will be explained fully later on in this document.

1. [[Image:FMOD events label.png]] this page contains all the audio events that the game engine will call. Within these events you will have the sound designed asset(s) and control parameters such as volume, reverb send and 2D-3D panning automation.

2. [[Image:FMOD event editor label.png]] on this page you will edit the event itself. In here you assign sound definitions, create layers and assign control parameters to the event, as seen below.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4084754f.png|thumb|none|600px]]

3. [[Image:FMOD sound definitions label.png]] this is the directory for all of the audio files that will be called in events. They can be single audio files that play once or loop, or multiple files that you want to behave in a certain way based on the parameters for the sound definition. Within the sound definition you can define behavior parameters, as seen below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_47ac008a.png|thumb|none|600px]]

These parameters will define the behavior of the audio file in the event you assign it too. When creating audio assets for the game and updating existing ones, the sound designer will usually start here.

4. [[Image:FMOD wave banks label.png]] this is the function of FMOD that controls the data portion of the audio assets in the project. In here you will create a bank that contains audio files that you want treated a certain way, mainly for optimization and data compression schemes. All audio files in the project will be contained in a bank and these are what are built when you build the project for use in the game. This bank build creates a .fev (event information) and .fsb (sample bank (audio) information) files that you will copy to your override folder and is read by the game, as seen below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_600b0549.png|thumb|none|600px]]

Wave banks are automatically created when you import audio into FMOD. They need to be manually conformed to naming standards and what properties they will contain.

5. [[Image:FMOD reverb label.png]] on this page you can define and audition reverbs to be used in the game. This function is not a necessary part of DA level design FMOD projects as the reverbs are handled by a master reverb project. In order to hear reverb on an event you must assign the “Reverb Level“ effect to the event and assign a value to the automation in the event.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1496d22e.png|frame|center|Assigning reverb level effect to the event.]]

6. [[Image:FMOD profiler label.png]] view stats and performance.

7. [[Image:FMOD music label.png]] music system editor.

=== General techniques - starting up. ===

When you begin to create an FMOD project there are certain steps to follow in order to get your project up and running.

<U>Step 1-</U> create a new project on your local DA directory.

<U>Step 2-</U> Create a new folder in the area_master folder named for what plot you are working on, or if there is a plot folder already made, create a subfolder to contain your new FMOD project.

All plot folders are named for the corresponding plot in the DA area editor, all FMOD projects are named from the area list name in the object inspector in the area editor, minus the area list prefix. Therefore the plot folder is named arl_eamon and the FMOD project is named redcliffe_castle. In this example you would create your FMOD project in the redcliffe_castle folder and name it the same as the folder that contains it.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m65209995.png|frame|center|Plot name and area in the area editor]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_1c7cef4.png|frame|center|Area list name in the object inspector.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m55feabec.png|frame|center|Folder naming structure as per plot name and area name.]]

Please note that all folder names are lower case and have spaces represented by underscores.

<U>Step 3-</U> open your new FMOD project and delete the untitled event that FMOD creates by default and save the project.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_1a3044b1.png|frame|center|Erase this.]]

<U>Step 4-</U> click on the Sound Definitions page and you are ready to bring audio into FMOD.

=== Folders and subfolders - setting up audio for FMOD. ===

All audio files to be used in an FMOD project must be contained in the same folder as the .fdp, or project file in order for the DA resource builder to build them properly. This set-up requires a bit of file management from the sound designer.

When arranging audio for use by FMOD, you will typically want to define folders and subfolders for audio files that are used in a particular way. For example, a folder called “exterior_ambience” will contain all of the audio files that would be assigned to volumes in the level and played as 4.0 audio events, whereas a folder called “3d_placeables” will contain all audio files being called as one shots and specialized events.

A typical folder layout could be as follows:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m164f59bd.png]]

This process is recommended to keep everything consistent project to project, as well as neat and tidy. You should be able to clearly see, at a glance, what is going on in any FMOD project that follows this structure. You will then use this file structure to order and group your sound definitions within FMOD, as indicated below.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3e9e6706.png]]

=== Setting up sound definitions and bringing audio into FMOD. ===

In order to bring audio into FMOD you must first set up a sound definition, which will allow FMOD to see and play the audio, based on parameters that you define. To begin, you must first create a folder structure that reflects the folder structure in the .fdp folder, as stated in “iii) folders and subfolders- setting up audio for FMOD.” First you must create a sound definition folder as it is in here that you will organize your sound definitions themselves.

There are 4 main sound definition folders currently established for DA level design using FMOD, exterior_ambiences, interior_ambiences, 3D_Placeables and scripted_sounds.

Right click on the empty grey space, or on the sound definition folder you want to add the sound definition to:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3bd8b026.png]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_7d3135bd.png]]

Next, within the sound definition folder, called “exterior_ambiences” in this example, you will create a sound definition folder, by right clicking on the exterior_ambiences folder and choosing “add empty sound definition”.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m619d00a5.png]]

You will have then created a sound definition that will contain your audio. You will be prompted to name the sound definition upon creation and you should name this sound definition to represent what the audio is inside it. An easy way to do this is to use the file name that the sound definition will contain.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4b15d23b.png|frame|center|The file the sound definition will contain.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m14969ad0.png|frame|center|The named sound definition.]]

To get audio into the sound definition, right click on the sound definition folder and select “add wavetable”, you will then be able to browse to the directory that contains your audio.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4745c964.png]]

Upon selection, the audio file or files will now show up in your sound definition folder, ready to be used.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_3b54791e.png]]

=== 4.0 ambiences and 3D placeable level emitter events. ===

Two main types of event can be created to design sound for the levels in DA. These main types are 4.0 ambiences or 3D placeable events. The 4.0 ambiences are used for expressing sounds like air tones, winds or any other sounds that you will assign to play in an audio volume in the area editor. These sounds will play in 4 speakers, the Left and Right front speakers and the Left and Right rear speakers. These sounds will not specialize but can be either constant loops or spawned sounds that spawn over time or used as loops.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m78db5ae3.png|thumb|center|600px|A typical 4.0 event]]

These events will need to be created as 3D events, as they have elements of 3D positional sounds. Although these sounds play as 4.0 within a defined space, their edges can be made to be 3D positional. The event above defines an example the volume and 2D-3D roll-off at the edge of the volume. If desired, the event will now be increasingly 3D to 2 meters and totally 3D after that. This is a typical exterior event with a roll-off of 5 meters, interior event roll-offs will usually be no more than 2 meters as the sounds will bleed room to room if it’s any bigger.

3D placeable events are sounds that are placed as emitters in the level and can be directional, like fires or other VFX, as seen below:

or created as an area effect wherein the sounds will randomize position and volume, such as birds, dogs or distant thunder, as seen as the second example below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4084754f.png|thumb|center|600px|A typical directional 3D event]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_5d15187.png|thumb|center|600px|A typical 3D area effect event]]

There are certain ways to set up sound definitions and events both 4.0 and 3D placeable sounds. This will be explained in detail in the “c) Event setup and convention” chapter of this document.

=== building projects and the .fev/.fsb. ===

In order to see sounds that we have created in the area editor, as well as hear them in the game, the project must be “built”. This is FMOD’s term for creating the data needed for the area editor and the game to call FMOD to play the sounds as we have created them. Upon building a project and .fev and .fsb file are created that we then copy to our override folder. The area editor and the game access them from there to be used by each.

==== The override folder ====

This will be in a different location for each sound designer, depending on how you are set up with the DA client but it is typically found in the following pathway:

<B>\packages\core\override</B>

Your .fev and .fsb files must be placed in this folder in order for the area editor, the game and the DA resource builder to use them. There are two ways to get them there, the first being to physically copy them there and the second being to direct FMOD to build them there, as shown below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_mabf4054.png]]

The latter can be tricky, especially when there are multiple people working on the project and not everybody’s file pathways are the same. Choose the method that works for you and exercise caution and consideration if you choose to have FMOD send your .fev and .fdp files to the override for you.

==== Building a project ====

In order to build a project, select “Build project” from the Build menu in FMOD:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m336ad9af.png]]

You will then be shown a pop-up window. Ensure that the target platform (PC) is selected and that the bank is checked off. Some projects will have multiple banks, make sure they are checked or they won’t be built. Press the “Build” button and wait for the build to complete, this can take several minutes. When the build is completed the .fev and .fsb files can be copied to your override or they will be there already, depending on how you have your project set up.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_3a994796.png|frame|center|The build window.]]

== Sound definition setup and convention ==

=== Use and parameters ===

The sound definition is the function of FMOD by which audio is imported into FMOD and playback behavior is defined. Once we have created a sound definition, as stated earlier in this document, we can then define certain parameters that will enable FMOD to provide a playback behavior that is desirable for how we choose to sound design for the level. You must have audio and sound definitions created in order to use these functions. The behaviors defined by sound definition parameters are as follows:

1. <U>Spawn time-</U> this is the max. and min. time in milliseconds that the sound definition will repeat. There are 2 number values that represent this. A value of both being 0 here will mean no repeat. Values of 1500 and 20000, for example mean that the sound definition will repeat between 1.5 seconds and 20 seconds. The behavior of this repetition is defined by the Play mode.

2. <U>Maximum spawned sounds- </U>this is the maximum number of simultaneous sounds that this sound definition will spawn at any given time, based on randomization parameters like Spawn time and Play mode.

3. <U>Play mode-</U> this is how individual sounds are chosen from the sound definition. There are 6 to choose from, Sequential, SequentialEventRestart, Random, RandomNoRepeat, Shuffle and ProgrammerSelected. This is how the sound definition will play, and can be chosen based on whether you have one or multiple files in the sound definition.

4. <U>Volume-</U> volume in decibels at which the sound will be played. You can pre-mix your sound definition here, but there are other places to control volume, usually this is left at 0.

5. <U>Volume randomization-</U> the maximum random negative gain that will be applied to the sound.

6. <U>Pitch-</U> the relative pitch <U>in octaves</U> at which the sound will be played. Note that this value is in octaves, so a calculation is needed to enter a percentage value here.

The formula is X (semitones desired) / 12 (semitones in an octave) = % value, for example:

3 semitones / 12 semitones = 0.25 octaves.

If you want a negative pitch here, you must put in a – sign before the value, otherwise it will be a positive pitch.

7. <U>Pitch randomization-</U> this is the random deviation from the relative pitch, in octaves. This will add a +/- pitch randomization of whatever value you put in here, once again, in octaves. For example:

If I want a pitch randomization of + or – 2 semitones, I will enter 0.17 here, which will randomize my sound in pitch over 4 semitones in total.

8. <U>3D position randomization-</U> this is a random deviation from the event’s parent position, in game units (meters). This is useful for events that are used as and area effect or in VFX to randomize the position of sounds. This value is a percentage 0 being no randomization and 100 being total randomization.

Once you have imported audio into FMOD and have created an event, you can edit the sound definition parameters to make the event play the way you desire. Note that all of our randomization is handled on the sound definition, not on the event, even though there are parameters there.

=== Spawned sounds, spawn times and sound definition behavior ===

Sound definitions can be spawned in several different ways, with several different results and can be used with 4.0 and 3D events. This parameter works in tandem with the Spawn time, Maximum spawned sounds and Play mode parameters.

The first and most basic way to play a sound definition is with no spawn time, as in a single audio file you just want to loop, like an air tone. These loops must be perfect and sample rate conversion friendly.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4cf8ab61.png|frame|center|Unspawned, sequential loop.]]

The second way is to spawn the sounds over time, to randomize when they play and how often. In the 4.0 example below, the wind gust sound definition is spawned between 500 milliseconds and 5 seconds, with a maximum of 4 playing at once and a play mode of RandomNoRepeat that randomly plays a sound definition that has 8 sounds in it.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2f6a1763.png|frame|center|Spawned “one shot loop”]]

This sound will then play as a randomized wind gust that will spawn randomly and provide the desired effect. This technique is also useful for spawning 3D area effect events, like birds, to randomize when they play over an area in 3D, as seen below.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3d9a150.png|frame|center|Spawned one shot birds.]]

This crow sound will spawn randomly between 2.5 seconds and 15 seconds, choosing randomly between 8 crow audio files.

The above sound definition behavior can also be used with volume, pitch and 3D position randomization to create a great 3D effect. 3D position randomization will only work with 3D emitter style events and will not randomize position in 4.0.

The third and trickiest technique is to use one shot audio files and play them while closely spawning over each other in a randomized “looping style” effect. This technique requires some time and energy to get working properly and doesn’t always work right away. When it does work it is very useful for sounds like wind, where the randomizing sounds are spawned over top of each other while randomizing volume and pitch to create a wonderfully varied effect. For example:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1d1c503d.png|frame|center|Spawned, randomized “one shot loop”.]]

In the example above there are 8 wind sounds that are approximately 10 seconds in length. They are spawned randomly between 1 and 5 milliseconds to a maximum of 4 at once, while randomizing -2 dB in volume and +/- 2 semitones in pitch. Although these audio files do not have to be perfect loops they do need to have matching zero crossings to avoid pops. The particular audio files in the above example have a fade in of 500 milliseconds to smooth over the transitions when spawned. There is no real definitive method to apply here, just do what sounds good!

== Event setup and convention. ==

=== FMOD events ===

As stated above in the overview, there are 3 main types of audio events being used for DA level sound design in FMOD. 4.0 ambiences, 3D placeable emitters and 3D area effect emitters. These 3 types are all used in conjunction with each other to create a total sound design for an area. Sound designers are by no means limited to using these types of events when designing the sound for a level, but for the sake of simplicity and consistency, these are the only events that will be available in the generic_ambience project. Sound designers are encouraged to create new events in their additional projects per level if need be.

FMOD events contain several parameters that will concern the sound designer. It is on the event itself that we define the volume, priority, max playbacks and behavior, 3D mode and roll-off type, 3d cone, 3D pan level, 2D speaker levels and any user properties that may be applicable.

==== Creating Events ====

On the events page, right click in the grey space and select “add event group”. These event groups should reflect your sound definition file structure and be named similarly.

There are 4 main event groups currently established for DA level design using FMOD, exterior_ambiences, interior_ambiences, 3D_Placeables and scripted_sounds, which follow sound definition folders named in the same fashion.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m63d38db3.png]]

If there is already an event group created in the project and you are adding an event, or creating a new event in the event group, right click and select “add event”.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_52c264fd.png]]

In this example these event group “exterior_ambiences” was created, and will contain sounds that we will assign to audio volumes. Note that the words are lower case and spaces are represented with underscores.

Upon selecting “add event”, you will be prompted to name the event and select a template if desired. We are not using templates in DA level design projects as they have proved to be too problematic and confusing. All sound designers must learn how to create events from scratch, although you can copy and paste similar existing events that suit your needs. If you do use a template to create you event, the sound designer must remember to deselect the template used in the “Use template” field, otherwise you will not be able to edit the event.

{|
|-
| rowspan="2"| [[Image:New FMOD event dialogue.png]]
| align="center" | [[Image:FMOD sound definition for new event dialogue.png]]
|-
| align="center" | [[Image:FMOD event.png]]
|-
| colspan="2" align="center" | <I><B>New event named for same sound definition.</B></I>
|}

All events should be named the same as the sound definition they contain. If the events are using multiple sound definitions then name them appropriately.

==== Creating the 3 main event types ====

===== 4.0 ambience event =====

These events are meant to be used as assigned sounds to an audio volume, they will play in 4.0 and will either just cross-fade at the edges of the volume or cross-fade in volume and change from 2D to 3D, which will be explained more fully in part ii) of this chapter.

Upon creating the event itself, we are ready to make it into a 4.0 ambience looping event, as follows:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3a459b67.png]]

We start with a default volume for ambience events at -18 dB, this can be adjusted later at the mix stage. It is not uncommon for event volumes to range from -24 dB to +12 dB, depending on the content and desired mix levels.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m597a3988.png]]

Priority defaults to “128” and max playbacks should be set to “4” to start off. More on this later in this document.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7066cacc.png]]

Mode is set to “3D”, all FMOD events for ambiences are set to 3D to take advantage of certain parameters available only to 3D events. This event will play as 4.0, so it is essentially 3D.

3D roll-off is set to “custom”, as we will create our own for the event.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_7153f459.png]]

3D position defaults to “World relative” and should be left there. Note that you can set the 3D position Randomization here, but it only works when the event is refired. We do this randomization on the sound definition so that it will randomize while the event is still playing.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_ccd1067.png]]

Here is where we set our 4.0 ambience parameters and make this event play in that fashion. 3D pan level is set to 0, meaning that the sound pans according to speaker levels. We set our speaker levels at -3 dB per L, R, LR, and RR speaker in order to compensate for stereo fold-down. If we wanted to we could set the 3D Pan Level to 1 and add the 3D pan level effect to the event and this event would specialize at the edges of the volume it is assigned to, more on that in the next section.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m74a9c141.png]]

We have one user property called UseMaxPlaybacksFix, which we have to add to all events that will be used in multiples in the level. This user property controls how many sounds FMOD is playing at once and works in conjunction with the Max playbacks parameter. This will allow us to use these events more than 1 time in a level and not use too much CPU. This property is not optional and must be used on events that fit the multiple playback criteria. To set it up, right click on the “User property” parameter and select “Add/Edit user properties”:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3d72555b.png]]

Select this and you will see a window pop-up:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_32b642c7.png]]

Click the “Add” button and type in “UseMaxPlaybacksFix” into the window and hit “OK”

You must now enter the integer “1” into the parameter space provided under the “+” tab beside “User properties”:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m356936c6.png]]

The event is now created, all you need to do now is assign a sound definition to the event, create volume, reverb and other effect roll-offs.

In the event editor page we should see a blank event layer similar to this:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3bd5a12a.png]]

In order to get started and get audio playing in here we need to first define an event parameter, in this case a 3D distance parameter, by right clicking on the bar as prompted:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2098a91a.png]]

We then have a 3D distance parameter that allows us to control the event over distance and add effects, like volume and reverb.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m287aa268.png]]

We set the 3D distance parameter’s properties by right clicking again where you clicked to create the parameter and select “Parameter properties”:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_7adb416b.png]]

We now see a pop-up window that allows us to edit the properties for the 3D distance parameter:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_35d79738.png]]

And the result to our event layer, below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_5c20101.png]]

We have created an event layer with a 3D distance of 5 meters, when we set our roll-off volume this will be the resultant radius of the roll-off around the edges of the audio volume this sound is assigned to.

We can now add our sound to the event, we do this by right clicking in the middle of the layer and selecting the “Add sound” option:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m3e52ad06.png]]

You will then be prompted to choose a sound from your sound definitions:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_32f1eb96.png]]

Note that you can choose how the sound is played, as a loop or one shot, but you can change that in the properties of the sound as well. We have “looping” selected in this example as we want this to be a looping ambience. Below are screenshots of the sound instance properties window where you can select the playback behavior of the sound as well.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_257ba5d2.png|frame|center|Sound instance properties selected.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_3c697c0a.png|frame|center|Sound instance properties window.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_715c522a.png|frame|center|Loop mode choices.]]

You will now have an event layer with a sound in it, as seen below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_49dfd3d2.png]]

Too add an effect like, volume or reverb, right click on the grey space under where is says “layer00” and choose “Add effect”:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1db548c9.png]]

You will then see a window with choices for effects:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1ee1266d.png]]

In this example, we chose “Volume”, just double click it or select it an hit “OK” and the effect will show up on the event layer:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_31a643e7.png]]

You can then manipulate the line to form the curve you want, add a point by right clicking on the line and drag it to where you want it:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m125fde6e.png]]

There are also choices for curve shape:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4f9bd95.png]]

The event with a volume curve:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6e5739fc.png]]

This curve represents the usual 5 meter volume roll-off for the 4.0 ambience. You can add other effects as desired in the same fashion. The event can be monitored by pressing the “play” button and the effect of your parameters over distance can be monitored by grabbing the red cursor and dragging it left to right.

===== 3D Placeable event =====

These events are designed to be placed as directional emitters in the level and serve the purpose of enabling the sound design for point source ambient sounds or environmental VFX in the level such as fires, waterfalls and other similar sound effects. They are designed to be completely directional or can become more or less 4.0 over distance.

The events are created in this fashion, we’ve already discussed the basics in the previous chapter and all events start out the same way, it’s just what parameters you assign to them that determine how they behave.

Starting from an event create from scratch, having already gone through the steps mentioned in the previous chapter, the only differences are as follows:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1eda4eb1.png]]

The 3D pan level is set to “1”, but we still have speaker levels on the event, as this event is a 2D_3D sound. If I wanted this event to be purely directional I would have the 3D pan level stay as “1” but I would have no speaker levels at all, as below.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m64757d3b.png]]

In the event editor page we create the event layer, bring in sounds, set our distance parameters and add effects as mentioned before, however this event will be place as an emitter and will be directional, as seen below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1a3844af.png]]

In this example, we have a fire sound that has a 3D distance radius of 25 meters, with effects added, such as 3D panning, Volume, Reverb and Low Pass filter to complete the event.

A purely 3D event will have no 3D panning and be purely directional, as below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_1b9ac367.png]]

===== 3D area effect event =====

These events are purely 3D events that are placed as emitters on the map to provide an area, or “umbrella” effect for one shot sounds such as birds, dogs or ambient thunder. These events are set up in the sound definition to randomize in volume, pitch and 3D position and when placed will play the one shot sounds in this fashion.

The event creation, as before is similar to all events except for two factors, the first being the 3D pan level value and the event layer parameters itself, as follows:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m64757d3b.png]]

The 3D pan level for this event is set to “1” and there are no speaker volume levels set.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_60d10943.png]]

The event layer is set up as before, only with one shot crows in this example. The event has been given a 3D distance parameter of 150 meters with a roll-off of 20 meters, to smooth out any transitions if the emitter is placed on the map to only cover one area and the player can walk in and out of it. Ideally, this event is created to cover an entire area, so the roll of at the end is “just-in-case”

The sound definition set-up, as below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m376eb2e4.png]]

These 3 event types are suggested as a place to start or a guideline by which to do the sound design for a level in DA. The sound designer is expected to create events and assign parameters that suit his or her needs, should the opportunity arise, but these 3 event types should fit 95% of all situations.

=== 4.0 ambiences and the 2D-3D event- when and where. ===

As mentioned in previous chapters, there is a technique to create events for 4.0 ambiences and 3D placeable events that utilizes a 2D_3D transition scheme. This technique can be used in one of two main ways, as a 2D_3D event assigned to a volume or as a 2D_3D emitter placed in the level. The evnt properties for these 2 events are identical, they are just played differently.

==== 2D_3D 4.0 ambiences ====

4.0 ambience events can be made to transition from 2D to 3D at the edges of the audio volume they are assigned to by using the 3D pan level, 2D speaker and 3D panning effect parameters. The event set up is as follows:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1eda4eb1.png]]

3D pan level is set to “1” and there are L, R, LR and RR speaker levels of -3 dB, to compensate for stereo fold-down and to define how the event will react volume-wise when the listener is within the radius of the 3D panning automation.

We have a 3D pan level effect on the event layer that is completely 2D at 0 meters and fully 3D at 4 meters, as below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m68cc205a.png]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m497e93b9.png]]

This event will now transition from 2D to 3D over 4 meters from the edge of the audio volume this event is assigned to. It will be fully 3D at 4 meters and will spacialize along the edge of the volume.

This type of event is useful for defining the course of a river where you may walk along the edge or cross it at any time, or for transitioning into a windy area from a calm one where you may want to perceive the wind in 3D before you are surrounded by it. The possibilities are endless!

The only caveat is that this type of event should only be used where transitioning in and out of the 2D to 3D space is appropriate. Using this event type on all events is unnecessary and should be used with discretion. It is really only useful on special effects or transitional spaces when you are moving from a quiet area to a louder one. This really doesn’t work within interiors where the roll-off is very short or between audio volumes that have the same sounds assigned to them, area to area, or in open areas where the transition isn’t noticeable. Use your discretion.

=== Max playbacks ===

Max playbacks describes the behavior in FMOD wherein the value represents the maximum times an event can play simultaneously in an area. Historically, this value used to represent exactly how many instances you had present in the area, if you had 22 audio volumes using 22 airtones, then the max playbacks value had to be 22, or they wouldn’t all play when you transitioned from volume to volume. Needless to say, even though we had our max playbacks set for playing all of the instances, FMOD would play them all, whether the player was in the volume or not. This wastes CPU and necessitated a programmatic fix to limit how many FMOD plays at one, depending on where the player is. The UseMaxPlaybackFix is now the user property we have to assign to all events that will have more than 1 playback, or be reused, in the area. We have selected a default value of 4 to represent that maximum number of simultaneous events firing at once.

Most events will need this user property as it is very rarely that we only use one event per area.

Max playbacks value of “4” for events that will be used in multiples per area:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m597a3988.png]]

UseMaxPlaybacksFix entered into the user properties field:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m356936c6.png]]

=== Priority. ===

Priority for ambiences is as follows:

Ambience Loops - 61-70

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m24ae0d4e.png]]

Ambient 3D - 221-230

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_764beda5.png]]

=== Event categories ===

There are currently 3 event categories that apply to DA level sound design FMOD projects. They are ambient, ambientvfx and amb_oneshots. They are primarily used for ducking events and master control slider assignments. All events must be assigned to a category.

To create a category, go to the Categories tab in the Events page in FMOD and right click on the “master” category and select “Add event category”:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m29634646.png]]

You must then name the category the <U>same name</U> as laid out in the categories FMOD project in the global projects folder.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m1fdb66d.png]]

ambient- most sounds that have to do with the ambience for a level go in here.

ambientvfx- environmental VFX such as fires, torches or water will go in here.

amb_oneshots- one shot sounds that you may find invasive and want to duck during conversations or cutscenes will go in here, used mainly for one shot birds currently.

== Global projects and level specific projects. ==

There is a 20 MB size limit per FMOD ambience project, per load. This size limit is set up as a buffer and we are encouraged to come in well below it. All sound designers must optimize their projects accordingly.

== Optimization ==

=== FMOD’s process- ADPCM (unlimited) and MP3 (max 6 sound definitions) ===

All sound designers are responsible for optimizing any FMOD project they create or maintain. Currently there are two compression schemes available to use. ADPCM and MP3.

ADPCM wave bank set up.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4b5cad3f.png]]

MP3 wave bank set up.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_315c2e97.png]]

We may use the ADPCM wave bank compression infinitely, but there is a limit of 6 sound definitions that can be optimized using MP3 per project.

Audio files can also be optimized within the wave bank manually, provided that the “optimize sample rate” parameter is set to “yes”. When this is selected FMOD will attempt to optimize the audio itself, but further optimization can be performed manually. It is as simple as right clicking on the audio file in the “Waveforms” window in the wave bank and selecting “Adjust sample rate optimization”. You will then be presented with a slider and a play and stop button which will allow you to manually adjust the sample rate of each file. Sound designers are greatly encouraged to perform this process on all audio assets within their FMOD projects.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2a35c007.png]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_527a93.png]]

The optimization slider operates within a range of sample rate frequencies from 100%, which is the sample rate that the audio file is brought in at, in this example 48 kHz, to 4 kHz. Sound designers are encouraged to only use sample rates that are even numbers, i.e. 44 kHz, 32 kHz, 24 kHz, 16 kHz, etc. you will then be able to monitor the change in sample rate by clicking the play button and selecting the best result.

[[Category:Sounds]]

User talk:Imgettingpissedoff

2009-11-11T15:34:14Z

Imgettingpissedoff: Blanked the page

User talk:Imgettingpissedoff

2009-11-11T15:34:00Z

Imgettingpissedoff: Created page with 'Something has been bothering me and I'm hoping that someone can help me. Reading through the 2DA page, under the part dealing with the formating of the Excel spreadsheets. This l...'

Something has been bothering me and I'm hoping that someone can help me. Reading through the 2DA page, under the part dealing with the formating of the Excel spreadsheets. This line, specifically the part I put in bold, ''Column A starting at line 3 will contain an integer row ID number that is '''unique to that row across all files''' (unless creating an M2DA override).'', seems to be implying that there can only be one item, throughout all of the 2DA's, that has a row ID of, for example, 1. This is obviously not the case so, if possible, can someone explain exactly what that means?

Combat Rules

2009-11-11T12:29:51Z

Imgettingpissedoff: /* Critical Hit Determination */

'''This page is work in progress'''

=== Overview ===

This page describes the technical implementation and flow of combat logic in the game scripts.
It deals mostly with weapon based combat, for spells and abilities, please see [[Ability|Abilities]].

Note: The term 'property' used on this page refers to [[Creature Properties]].

=== Detailed Description ===

Combat in Dragon Age: Origin is handled mainly through scripts - the game engine itself has little knowledge of rule concepts such as 'Strength', 'Damage Modifier' or 'Armor Penetration'.

==== Hit Resolution ====

Hit resolution is implemented in the function [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] in the script library [[combat_h.nss]], which is invoked from the [[creature_core.nss]] script whenever an attack event is received. The function returns one of several [[COMBAT_RESULT|COMBAT_RESULT_*]] constants and handles messaging to the game engine which animation to play.

Overall, Dragon Age: Origin's combat system is 'hit heavy' as a target's armor does not modify its chance of getting hit.

The simplified decision tree for to hit resolution is as follows:

<dascript>

if Target Is Placeable Object
return COMBAT_RESULT_HIT

if Target Displacement/Dodge < RandomF(100.0)
return COMBAT_RESULT_MISS

if Attacker Is Using BASE_ITEM_TYPE_STAFF
return COMBAT_RESULT_HIT

bHit = RandomF(100.0) < AttackRating - DefenseRating
bCrit = CheckCricital()
bBackstab = CheckBackstab()

if bHit
if HasEffect(attacker, EFFECT_TYPE_MISDIRECTION_HEX)
if bCrit
return COMBAT_RESULT_HIT
else
return COMBAT_RESULT_MISS

if bBackstab
return COMBAT_RESULT_BACKSTAB
else
if bCrit
return COMBAT_RESULT_CRITICAL_HIT
else
return COMBAT_RESULT_HIT

else
return COMBAT_RESULT_MISS

</dascript>

===== Attack Rating =====

Attack rating includes:

* Base attack value (54.0f)
* + [[#Flanking Bonus Determination|Flanking Bonus]] (position based, modified by attacker and enemy talents and effects as well as shields. Rogues have a bonus here).
* + Distance based penalties (for ranged attacks)
* + Attacker's attack property value (this includes modifiers from buffs, etc.)
* + Any +attack item bonuses on the weapon that performs the attack.
* + Any external bonuses or penalties passed into the function (from talent scripts, etc.)
* + Difficulty setting based modifications

===== Defense Rating =====

Defense rating includes:

* Defender defense value (and missile deflection if attack was ranged). This includes items, effects and magical bonus.
* Difficulty setting based modifications

===== Flanking Bonus Determination =====

* Flanking bonus is a floating point value that applies to both AttackRating and to the chance to score a critical hit.
* It is essentially a representation of how close the character is to the best position when attacking the enemy (directly in the back)
* Various shield abilities on the target reduce or prevent the attacker from getting the bonus.
* The further away the character is from that position, the more the bonus is diluted.
* The magnitude of the bonus ranges from +0 to +15 (+20 with combat_movement) and is applied to AttackRating and partially (1+(FlankingBonus/5)) to critical hit chance.
* Most characters only flank 60 degrees in each direction, combat movement allows an increase to 90 degrees (the full back 180).
* Only rogues get the full flanking bonus, everyone else still gets half.
* The full logic is implemented in the function [[combat_h.nss#Combat_GetFlankingBonus|Combat_GetFlankingBonus]] in [[combat_h.nss]].

===== Backstab Determination =====

* Backstab is determined for each melee attack only.
* Backstab requires the attacker to have a flanking bonus > 0 (some talents waive this restriction)
* Only creatures with the Rogue [[Classes|Character Class]] may backstab. This is a class benefit.
* Only humanoid attackers can backstab (this includes darkspawn)
* The full logic is implemented in the function [[combat_h.nss#Combat_CheckBackstab|Combat_CheckBackstab]] in [[combat_h.nss]].
* The damage logic is implemented in [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]].

===== Critical Hit Determination =====

* Critical Hit Chance uses the attackers Melee or Ranged critical hit modifier based on attack type.
* + the attacking weapon's critical hit modifier stat.
* + 1.20x (1.1x for non rogues) the attacker's [[#Flanking Bonus Determination|Flanking Bonus]] in the current situation.
* + 3.5 for each enemy past the 2nd that is fighting a warrior with the bravery talent.
* A critical hit occurs when the resulting CriticalHitChance is smaller than RandomFloat()*100.0f.
* Certain effects and spells (e.g. Death Hex) can always override the result, as will attacking from stealth (always hits critical).
* The logic is implemented in the function [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] in the script library [[combat_h.nss]]

==== Damage Resolution ====

Damage resolution logic is implemented in the script [[combat_damage_h.nss]].

===== Critical Hit Damage Modification =====

* Critical hits increase the amount of damage done by an attack by a fixed multiplier.
* The magnitude of the multiplier can be affected by items and effects, but is not affected by any of the character's attributes.
* Historical Note: Critical damage used to be variable 'up to...', but was changed to constant to provide a more predictable flow of damage.
* The logic for critical damage is implemented in [[combat_damage_h.nss#GetCriticalDamageModifier]].

===== Backstab Damage Modification =====

* Backstab damage is essentially identical to critical damage, but modified by certain rogue talents.
* The full logic is implemented [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]] in [[combat_damage_h.nss]].

[[Category: Scripts]]

Combat Rules

2009-11-11T12:28:56Z

Imgettingpissedoff: /* Critical Hit Damage Modification */

'''This page is work in progress'''

=== Overview ===

This page describes the technical implementation and flow of combat logic in the game scripts.
It deals mostly with weapon based combat, for spells and abilities, please see [[Ability|Abilities]].

Note: The term 'property' used on this page refers to [[Creature Properties]].

=== Detailed Description ===

Combat in Dragon Age: Origin is handled mainly through scripts - the game engine itself has little knowledge of rule concepts such as 'Strength', 'Damage Modifier' or 'Armor Penetration'.

==== Hit Resolution ====

Hit resolution is implemented in the function [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] in the script library [[combat_h.nss]], which is invoked from the [[creature_core.nss]] script whenever an attack event is received. The function returns one of several [[COMBAT_RESULT|COMBAT_RESULT_*]] constants and handles messaging to the game engine which animation to play.

Overall, Dragon Age: Origin's combat system is 'hit heavy' as a target's armor does not modify its chance of getting hit.

The simplified decision tree for to hit resolution is as follows:

<dascript>

if Target Is Placeable Object
return COMBAT_RESULT_HIT

if Target Displacement/Dodge < RandomF(100.0)
return COMBAT_RESULT_MISS

if Attacker Is Using BASE_ITEM_TYPE_STAFF
return COMBAT_RESULT_HIT

bHit = RandomF(100.0) < AttackRating - DefenseRating
bCrit = CheckCricital()
bBackstab = CheckBackstab()

if bHit
if HasEffect(attacker, EFFECT_TYPE_MISDIRECTION_HEX)
if bCrit
return COMBAT_RESULT_HIT
else
return COMBAT_RESULT_MISS

if bBackstab
return COMBAT_RESULT_BACKSTAB
else
if bCrit
return COMBAT_RESULT_CRITICAL_HIT
else
return COMBAT_RESULT_HIT

else
return COMBAT_RESULT_MISS

</dascript>

===== Attack Rating =====

Attack rating includes:

* Base attack value (54.0f)
* + [[#Flanking Bonus Determination|Flanking Bonus]] (position based, modified by attacker and enemy talents and effects as well as shields. Rogues have a bonus here).
* + Distance based penalties (for ranged attacks)
* + Attacker's attack property value (this includes modifiers from buffs, etc.)
* + Any +attack item bonuses on the weapon that performs the attack.
* + Any external bonuses or penalties passed into the function (from talent scripts, etc.)
* + Difficulty setting based modifications

===== Defense Rating =====

Defense rating includes:

* Defender defense value (and missile deflection if attack was ranged). This includes items, effects and magical bonus.
* Difficulty setting based modifications

===== Flanking Bonus Determination =====

* Flanking bonus is a floating point value that applies to both AttackRating and to the chance to score a critical hit.
* It is essentially a representation of how close the character is to the best position when attacking the enemy (directly in the back)
* Various shield abilities on the target reduce or prevent the attacker from getting the bonus.
* The further away the character is from that position, the more the bonus is diluted.
* The magnitude of the bonus ranges from +0 to +15 (+20 with combat_movement) and is applied to AttackRating and partially (1+(FlankingBonus/5)) to critical hit chance.
* Most characters only flank 60 degrees in each direction, combat movement allows an increase to 90 degrees (the full back 180).
* Only rogues get the full flanking bonus, everyone else still gets half.
* The full logic is implemented in the function [[combat_h.nss#Combat_GetFlankingBonus|Combat_GetFlankingBonus]] in [[combat_h.nss]].

===== Backstab Determination =====

* Backstab is determined for each melee attack only.
* Backstab requires the attacker to have a flanking bonus > 0 (some talents waive this restriction)
* Only creatures with the Rogue [[Classes|Character Class]] may backstab. This is a class benefit.
* Only humanoid attackers can backstab (this includes darkspawn)
* The full logic is implemented in the function [[combat_h.nss#Combat_CheckBackstab|Combat_CheckBackstab]] in [[combat_h.nss]].
* The damage logic is implemented in [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]].

===== Critical Hit Determination =====

* Critical Hit Chance uses the attackers Melee or Ranged critical hit modifier based on attack type.
* + the attacking weapon's critical hit modifier stat.
* + 1.20x (1.1x for non rogues) the attacker's [[#Flanking Bonus Determination|Flanking Bonus]] in the current situation.
* + 3.5 for each enemy past the 2nd that is fighting a warriors with the bravery talent.
* A critical hit occurs when the resulting CriticalHitChance is smaller than RandomFloat()*100.0f.
* Certain effects and spells (e.g. Death Hex) can always override the result, as will attacking from stealth (always hits critical).
* The logic is implemented in the function [[combat_h.nss#Combat_GetAttackResult|Combat_GetAttackResult]] in the script library [[combat_h.nss]]

==== Damage Resolution ====

Damage resolution logic is implemented in the script [[combat_damage_h.nss]].

===== Critical Hit Damage Modification =====

* Critical hits increase the amount of damage done by an attack by a fixed multiplier.
* The magnitude of the multiplier can be affected by items and effects, but is not affected by any of the character's attributes.
* Historical Note: Critical damage used to be variable 'up to...', but was changed to constant to provide a more predictable flow of damage.
* The logic for critical damage is implemented in [[combat_damage_h.nss#GetCriticalDamageModifier]].

===== Backstab Damage Modification =====

* Backstab damage is essentially identical to critical damage, but modified by certain rogue talents.
* The full logic is implemented [[combat_damage_h.nss#Combat_Damage_GetBackstabDamage|Combat_Damage_GetBackstabDamage]] in [[combat_damage_h.nss]].

[[Category: Scripts]]

2DA

2009-11-10T10:29:29Z

Imgettingpissedoff: /* Areas and plots */

Many of the properties of objects in the toolset make reference to 2DAs (two-dimensional arrays). These are read-only arrays containing various data used by scripting and the game engine. For example, the set of local variables that an object supports is defined in a 2DA.

The source files for 2DAs are Microsoft Excel worksheets. This allows a wide variety of sophisticated techniques to be used to generate the values of the 2DA fields, such as macros and formulas. It also makes editing much easier since the columns can be annotated and formatted in helpful ways, and multiple related worksheets can be grouped into one file.

Data in a 2DA is identified by a row number, with the first row (row zero) usually being reserved for internal use (undefined value, etc.) by convention. Each row has an arbitrary number of columns identified by strings.

Before they can be used by the toolset or the game, 2DAs must be converted from Excel files into a more efficient form. Processed 2DAs are stored in files with the .[[GDA]] extension.

== Excel file formatting ==

Cell A1 will contain "ID". This is checked by the processor and the worksheet will fail if this is not the case.

Column A starting at line 3 will contain an integer row ID number that is unique to that row across all files (unless creating an M2DA override). Row IDs will be listed from smallest to highest within the same file and do not need to be consecutive.

A blank row or column will determine the dimension of the spreadsheet in that direction. Everything past that point is ignored by the binarizer.

Column names are case sensitive. This is because of the CRC32 algorithm used to generate the hash key. Changing the case of a column name after it is in use will break the game. White space before and after a column name will be removed before hashing.

Row 2 will be a "types" row. Each is a single word: [[int]], [[string]] (single chars as well), [[resource]], [[float]] or [[bool]]. A special type "[[comment]]" can be used to exclude a column from export.

Any column with string data that refers to files should have a type of "resource" and not "string". This is because the "resource" type is used to determine dependencies for the 2DA file.

'bool' type may be one of: a zero or non-zero number, Yes or No (case insensitive), or words beginning with T or F (such as True! and False!). NOTE: You cannot use TRUE and FALSE because Excel converts those to a special keyword the binarizer can't parse properly at this time. '''Note:''' the scripting language doesn't have a function for retrieving boolean values from a 2DA, and the behavior of Get2DAInt when retrieving a boolean is untested. It is probably safer to just use an integer for scripting purposes.

If you wish to leave a cell unfilled, the string "****" (four asterisks) can be inserted instead of a value.

Any worksheets that are not exportable 2DA data will have an underscore prepended to their name - the resource builder will subsequently ignore them.

Worksheets need to have unique names among all excel files, duplicates will overwrite each other as each worksheet is exported as a file

You cannot have the workbook open in Excel at the same time as running the binarizer on it.

Strings have a maximum length of 768 characters. Anything longer will be truncated.

== Extending the game via M2DAs ==

An "M2DA" is a "Multiple 2DA" that stacks a number of 2DA files into one larger table. They work much like single 2DA files except they can be patched or expanded later by adding more resources. These are useful for any table that lists other resources, such as appearance tables, so that new resources can be added later without having to modify a monolithic table.

This is especially important for third-party modders, since BioWare might release an update to a core table at a later date that would overwrite any changes third parties had made to it. By using an M2DA with a unique name, and by using a range of ID numbers significantly separated from those already in use, you can ensure that your additions won't conflict with other portions of the M2DA.

A list of all M2DAs used by the game can be found in [[2DA_base.xls]]. Every 2da listed in M2DA_base is treated as a M2DA, except for those with an ID between 10000 and 10999 which are handled as regular 2DAs. Each M2DA has a label that describes the subject covered by the M2DA and a worksheet prefix that all components of that M2DA must use.

Every worksheet listed in M2DA_base is actually a prefix. The system reads this prefix and then searches through all the 2DAs for the ones starting with this prefix and merges them together as one 2DA. For example: M2DA Id 0 is "ANIM_". The system looks through its list of 2das and finds "ANIM_base", "ANIM_combat" and "ANIM_walk". It will read and merge all 3 2DAs into an M2DA called "ANIM_".

Not all of the prefixes end in an underscore. For example, longsword variations are in worksheets prefixed with "longsword_variation", so both "longsword_variation_candyland" and "longsword_variationcandyland" would work as M2DA worksheet names.

2DAs are merged row by row, keyed on the ID column. If two rows in two different 2DAs to be merged have the same ID, the row in the2da with the highest priority wins.

== 2daExporter.xls ==

To convert an XLS file into a 2DA usable by the game, another Excel file is used; <code>2daExporter.xls</code>.

[[Image:2DA exporter.png]]

It has the following settings:
*ResourceBuild Path: The path to ResourceBuild.exe, which is installed by default in your Dragon Age directory under tools\ResourceBuild
*2DA Path: The source path of the XLS files to be exported. This is the root directory, you can specify subdirectories for each individual XLS file.
*Override Path: The path to the override directory that the completed 2DAs should be exported to.
*Debug Mode:

Simply list the xls files you wish to convert, one to a line, and then click on the "Export Selected" button. The converted 2DAs will be exported to the specified override path. Remember that the 2DAs are generated from worksheets inside the xls files so converting one xls file can produce a number of different GDA files in the output directory.

2daExporter.xls has been tested with Microsoft Excel, it has not been tested with other compatible spreadsheet programs. It may have trouble with paths that have spaces in their names (eg, "C:\My Documents"); if your export attempt fails try moving your working directories to a directory path with no spaces.

== Adding 2DA export to the Windows XP file explorer ==

Here's an easy way to add a context menu item that quickly converts new or updated Dragon Age Excel files into GDA format:

Setup:

# Open Windows Explorer and click Tools | Folder Options.
# In the File Types tab, select the XLS extension from the list and click the Advanced button.
# Click the New button and put 'Binarize 2DA' in the Action field.
# Paste the following in the Application field and click OK (update the drive and folder names to match your client): <tt>C:\DA\tag\main\ResourceBuild\Processors\ExcelProcessor.exe "%l" -outdir=C:\DA\tag\main\build\packages\core\override</tt>

Note that paths with spaces in them can cause Windows trouble, if your paths have spaces in them remember to wrap them in quotation marks.

Usage:

# Using Windows Explorer, navigate to your 2DA folder (in my case C:\DA\tag\main\data\Source\2DA) and select the Excel file(s) to process. Right click and select 'Binarize 2DA' from the context menu.
# Confirm a corresponding GDA file is created in your override folder (in my case C:\DA\tag\main\build\packages\core\override) for each Excel file processed.

== Step-by-Step ==

If you have problems using the 2daExporter.xls spreadsheet to generate 2DAs the following method may work instead:

*Create two folders called C:\2DA\ and C:\2DA\Override\
*Copy ExcelProcessor.exe to C:\2DA\
*Copy the Excel spreadsheets containing the 2DA you want to use in the game to C:\2DA\
*Create a batch file with the following line in it (change "placeables.xls" to whatever Excel file you're working with):
C:\2DA\ExcelProcessor.exe placeables.xls -outdir=C:\2DA\override\
*Run your batch file
*Find the GDA file from the C:\2DA\Override\ directory and copy it to the game's override directory. Remember to take into account the naming conventions of M2DAs; you may need to rename your 2DA files with a new suffix unique to your module to allow it to add to the core 2DAs without conflict.

== 2DA XLS files used in Dragon Age ==

''Note: This list is very incomplete right now''

Bear in mind that 2DAs names are actually based on the names of the worksheets inside these Excel files, not the names of the files themselves. Some of these files contain a large number of individual 2DAs within them. They are bundled together into Excel files based on the nature of the 2DAs for convenience.

=== Creatures ===

*[[APR_base.xls]] - appearance types for creatures
*[[ABI_base.xls]] - integrates all talents and spells into the game
*[[ANIM_base.xls]]
*[[ANIM_combat.xls]]
*[[ANIM placeables.xls]]
*[[SyncAnimations.xls]]
*[[CLA_base.xls]] - Defines the character classes used throughout the game
*[[background.xls]] - defines the various origin stories available to each race and class.

=== Objects ===
*[[placeables.xls]] - interactive object types
*[[BITM base.xls]] - item types
*[[ItemVariations.xls]] - item appearance variations (eg, all the different ways a longsword can look)
*[[PRJ_base.xls]] - how various projectiles look and behave
*[[VFX_base.xls]] - Visual effects

=== Areas and plots ===

*[[worldmaps.xls]] - world maps for open-ended travel between areas
*[[plottypes.xls]] - how plots are grouped at the highest level in the game GUI (codex entry types, story, etc.)
*[[areadata.xls]] - sets various properties for specific areas
*[[rewards.xls]] - rewards for plot completion

== Adding Strings ==

When adding strings to a 2DA, you have two options. The simplest is to enter **** for the StringID column. In that case, the name column will be used in the game.

The other approach is to use the toolset's string editor to create a new string. When that happens, you'll get a new StringID. Take that StringID and add 16777216 to the number. Next enter that number into the StringID column in the 2DA.

The second approach works better when translating your module, at the cost of portability. If someone else wanted to reuse your 2DA, they'd have to generate their own strings, then update the StringID number based on these IDs.

[[Category:2DAs]]

Character Save Values

2009-11-10T04:20:27Z

Imgettingpissedoff: /* Player Character Stats */

=== Overview ===
This page details character save game values.

=== File Locations ===
For savegame locations under Vista they are, by default under "<user's document directory>\\Bioware\\Dragon Age\\Characters\\<Name of the Character the save is for>\\<save slot>\\<savename>.das". As the save name is part of the save file name (though not the folders) it should be pretty easy to find the proper folder name provided one named one's save something distinguishable.

=== Player Character Stats ===
Found under SAVEGAME_PLAYERCHAR->SAVEGAME_PLAYERCHAR_CHAR->SAVEGAME_CREATURE_STATS->SAVEGAME_STATLIST

For party members the same values should hold. Navigate to:
SAVEGAME_PARTYLIST->SAVEGAME_PARTYPOOLMEMBERS-><number>->SAVEGAME_CREATURE_STATS->SAVEGAME_STATLIST

{| border="1"
|-
|'''STAT_PROPERTY_INDEX''' || '''Effect''' || '''Maximum Displayed Value'''
|-
| 1 || Strength || N/A
|-
| 2 || Dexterity || N/A
|-
| 3 || Willpower || N/A
|-
| 4 || Magic || N/A
|-
| 5 || Cunning || N/A
|-
| 6 || Constitution || N/A
|-
| 7 || Health || N/A
|-
| 8 || Mana || N/A
|-
| 34 || Attribute points || 100
|-
| 35 || Skill points || Unknown (likely 100)
|-
| 36 || Spell and Talent points || 100
|-
| 38 || Specialization points || 2
|-
| 41 || Fatigue || N/A, Negative values possible
|}

Values here can go above their displayed values, they simply are just not shown. Editing specialization points allows one to have more than 2 specializations. Having all 4 specializations seems to work, one can get all the spells/talents and all the icons display properly, however it is unknown if there are long term game effects.

Note: Available stat points max out at 100. Once you've spent all of them you'll need to enter the level up screen again in order to spend any left over.

Typically the structure of the stat properties are:
* STRUCT value of ATTR
* SAVEGAME_STATPROPERTY_BASE, FLOAT32, ''value''
* SAVEGAME_STATPROPERTY_MODIFIER, FLOAT32, ''value''
* SAVEGAME_STATPROPERTY_INDEX, UNIT16, ''value''

For health/mana has an additional properties of:
* SAVEGAME_STATPROPERTY_CURRENT, FLOAT32, ''value''
** Current health of the PC/NPC
* SAVEGAME_STATPROPERTY_COMEGEN, INT32, ''value''
** ???
* SAVEGAME_STATPROPERTY_REGEN, INT32, ''value''
** Regen rate?

Attribute, Skill, Spell/Talent, Specialization Points have a structure of:
* STRUCT value of SMPL
* SAVEGAME_STATPROPERTY_BASE, FLOAT32, ''value''
* SAVEGAME_STATPROPERTY_INDEX, UNIT16, ''value''

=== Player Character Talents ===
{| border="1"
|-
|'''Talent/Skill''' || '''Value'''
|-
| colspan="2" align="center" | ''Champion''
|-
| Main || 4013
|-
| War Cry || 3037
|-
| Rally || 3038
|-
| Motivate || 32
|-
| Superiority || 3039
|-
| colspan="2" align="center" | ''Templar''
|-
| Main || 4021
|-
| Righteous Strike || 23
|-
| Cleanse Area || 3017
|-
| Mental Fortress || 52
|-
| Holy Smite || 25
|-
| colspan="2" align="center" | ''Berserker''
|-
| Main || 4016
|-
| Berserk || 700
|-
| Resilience || 48
|-
| Constraint || 3006
|-
| Final Blow || 3009
|-
| colspan="2" align="center" | ''Reaver''
|-
| Main || 4019
|-
| Devour || 3065
|-
| Frightening Appearance || 3065
|-
| Aura of Pain || 3067
|-
| Blood Frenzy || 713
|}
{| border="1"
|-
|'''Talent/Skill''' || '''Value'''
|-
| colspan="2" align="center" | ''Assassin''
|-
| Main || 4014
|-
| Mark of Death || 3060
|-
| Exploit Weakness || 56
|-
| Lacerate || 3059
|-
| Feast of the Fallen || 3058
|-
| colspan="2" align="center" | ''Bard''
|-
| Main || 4015
|-
| Song of Valor || 3045
|-
| Distraction || 701
|-
| Song of Courage || 705
|-
| Captivating Song || 1000
|-
| colspan="2" align="center" | ''Ranger''
|-
| Main || 4029
|-
| Summon Wolf || 1004
|-
| Summon Bear || 91
|-
| Summon Spider || 93
|-
| Master Ranger || 92
|-
| colspan="2" align="center" | ''Duelist''
|-
| Main || 4030
|-
| Dueling || 709
|-
| Upset Balance || 3060
|-
| Keen Defense || 3049
|-
| Pinpoint Strike || 3051
|}

Character Save Values

2009-11-10T04:15:49Z

Imgettingpissedoff: /* Player Character Stats */

=== Overview ===
This page details character save game values.

=== File Locations ===
For savegame locations under Vista they are, by default under "<user's document directory>\\Bioware\\Dragon Age\\Characters\\<Name of the Character the save is for>\\<save slot>\\<savename>.das". As the save name is part of the save file name (though not the folders) it should be pretty easy to find the proper folder name provided one named one's save something distinguishable.

=== Player Character Stats ===
Found under SAVEGAME_PLAYERCHAR->SAVEGAME_PLAYERCHAR_CHAR->SAVEGAME_CREATURE_STATS->SAVEGAME_STATLIST

For party members the same values should hold. Navigate to:
SAVEGAME_PARTYLIST->SAVEGAME_PARTYPOOLMEMBERS-><number>->SAVEGAME_CREATURE_STATS->SAVEGAME_STATLIST

{| border="1"
|-
|'''STAT_PROPERTY_INDEX''' || '''Effect''' || '''Maximum Displayed Value'''
|-
| 1 || Strength || N/A
|-
| 2 || Dexterity || N/A
|-
| 3 || Willpower || N/A
|-
| 4 || Magic || N/A
|-
| 5 || Cunning || N/A
|-
| 6 || Constitution || N/A
|-
| 7 || Health || N/A
|-
| 8 || Mana || N/A
|-
| 34 || Attribute points || 100
|-
| 35 || Skill points || Unknown (likely 100)
|-
| 36 || Spell and Talent points || 100
|-
| 38 || Specialization points || 2
|-
| 41 || Fatigue || N/A, Negative values possible
|}

Values here can go above their displayed values, they simply are just not shown. Editing specialization points allows one to have more than 2 specializations. Having all 4 specializations seems to work, one can get all the spells/talents and all the icons display properly, however it is unknown if there are long term game effects.

Note: Available stat points max out at 100. Once you've spent all of them you'll need to level again in order to get access to the remainder. If you still have more than 100 left over you'll be limited to 100 spendable points until the next level again.

Typically the structure of the stat properties are:
* STRUCT value of ATTR
* SAVEGAME_STATPROPERTY_BASE, FLOAT32, ''value''
* SAVEGAME_STATPROPERTY_MODIFIER, FLOAT32, ''value''
* SAVEGAME_STATPROPERTY_INDEX, UNIT16, ''value''

For health/mana has an additional properties of:
* SAVEGAME_STATPROPERTY_CURRENT, FLOAT32, ''value''
** Current health of the PC/NPC
* SAVEGAME_STATPROPERTY_COMEGEN, INT32, ''value''
** ???
* SAVEGAME_STATPROPERTY_REGEN, INT32, ''value''
** Regen rate?

Attribute, Skill, Spell/Talent, Specialization Points have a structure of:
* STRUCT value of SMPL
* SAVEGAME_STATPROPERTY_BASE, FLOAT32, ''value''
* SAVEGAME_STATPROPERTY_INDEX, UNIT16, ''value''

=== Player Character Talents ===
{| border="1"
|-
|'''Talent/Skill''' || '''Value'''
|-
| colspan="2" align="center" | ''Champion''
|-
| Main || 4013
|-
| War Cry || 3037
|-
| Rally || 3038
|-
| Motivate || 32
|-
| Superiority || 3039
|-
| colspan="2" align="center" | ''Templar''
|-
| Main || 4021
|-
| Righteous Strike || 23
|-
| Cleanse Area || 3017
|-
| Mental Fortress || 52
|-
| Holy Smite || 25
|-
| colspan="2" align="center" | ''Berserker''
|-
| Main || 4016
|-
| Berserk || 700
|-
| Resilience || 48
|-
| Constraint || 3006
|-
| Final Blow || 3009
|-
| colspan="2" align="center" | ''Reaver''
|-
| Main || 4019
|-
| Devour || 3065
|-
| Frightening Appearance || 3065
|-
| Aura of Pain || 3067
|-
| Blood Frenzy || 713
|}
{| border="1"
|-
|'''Talent/Skill''' || '''Value'''
|-
| colspan="2" align="center" | ''Assassin''
|-
| Main || 4014
|-
| Mark of Death || 3060
|-
| Exploit Weakness || 56
|-
| Lacerate || 3059
|-
| Feast of the Fallen || 3058
|-
| colspan="2" align="center" | ''Bard''
|-
| Main || 4015
|-
| Song of Valor || 3045
|-
| Distraction || 701
|-
| Song of Courage || 705
|-
| Captivating Song || 1000
|-
| colspan="2" align="center" | ''Ranger''
|-
| Main || 4029
|-
| Summon Wolf || 1004
|-
| Summon Bear || 91
|-
| Summon Spider || 93
|-
| Master Ranger || 92
|-
| colspan="2" align="center" | ''Duelist''
|-
| Main || 4030
|-
| Dueling || 709
|-
| Upset Balance || 3060
|-
| Keen Defense || 3049
|-
| Pinpoint Strike || 3051
|}

Model

2009-11-09T14:16:12Z

Imgettingpissedoff: /* Moving and placing objects */

{{Infobox level editor}}
Models are 3D textured meshes that are the basic building block of most things that the player will see in-game. The only editor that makes direct use of them is the [[level editor]], which this page focuses on, but things like creatures and placeables will make use of them indirectly via 2DA definitions.

Unlike the database resource palette, the model palette doesn't have a heirarchy of folders and subfolders. Since there are usually a vast number of models available this can make the palette cluttered and difficult to work with. To make it more manageable you should set the toolset's configuration to "fake" a folder structure. The toolset will divide models up based on their names, using underscores as dividers; for example the models dwe_face and dwe_orzent would both be placed inside a "dwe" folder. The option for setting this can be found under the palette options menu:

[[Image:Options menu use fake model folders.png|frame|center|Use fake model folders]]

== Models in the Level Editor ==

[[Model]]s are used to create any other objects that may be used as part of the level art - walls, floors, ceilings, non-interactive furnishings, visual effects, etc. To place them click on the [[Image:IconModelPlacement.png]] icon in the toolbar to go into model placement mode.

Trees are added using the "scatter object" mode ([[Image:IconScatterObject.png]]).

== Model palette ==

The model palette contains all the basic building blocks that you'll have available to build a level layout with. These building blocks are created using third-party 3D studio programs such as 3DSMax, a process that we won't go into here.

Unlike the database resource palette, the model palette doesn't have a heirarchy of folders and subfolders. Since there are usually a vast number of models available this can make the palette cluttered and difficult to work with. To make it more manageable you should set the toolset's configuration to "fake" a folder structure. The toolset will divide models up based on their names, using underscores as dividers; for example the models dwe_face and dwe_orzent would both be placed inside a "dwe" folder. The option for setting this can be found under the palette options menu:

[[Image:Options menu use fake model folders.png|center]]

Models are grouped into "tilesets" with pieces that share common structural themes. For example, there might be a "dwarven fortress" tileset that contains a variety of structural pieces and furniture of dwarven manufacture, and a "Tevinter" tileset that contains a variety of pieces with Tevinter architectural motifs.

Since the names of these models can often be a bit inscrutable, a more convenient way of working with models that you're frequently using on a level (such as wall segments) is to bring them into the level's "scratch space" and copy them as needed. Objects in the scratch space can be positioned within the level just like ordinary objects but will not be exported when the level is exported for use as an area layout.

[[Image:Level editor scratch space.png|center|thumb|600px|These three fence pieces are in the scratch space, and so will not be exported with the rest of the objects in this level.]]

Also, see [[level models]] for a list of available models with screenshots depicting them.

== Selecting objects ==

When clicking on models in the layout there will often be other foreground objects that are in the way, preventing the immediate selection of the object you wanted. Simply keep clicking on the same spot to cycle through all of the objects that are underneath the mouse pointer.

== Moving and placing objects ==

Clicking on the "snap options" button [[Image:IconSnapOptions.png]] on the toolbar brings up the following options:

[[Image:Level editor snap options.png]]

*"snap to grid" causes the position of objects you place or move to be constrained to specific points in an imaginary three-dimensional grid. This is very useful when placing things such as floor tiles, which must be arranged in a precise grid in order for their edges to match up correctly.
*"Snap Z Size Independent" is only available when the Enable Snap To Grid is checked. It allows for the user to specify a different snap setting solely for use in the z-axis.
*"snap rotation" similarly constrains the rotation of objects to specific angles.
*"snap to surface" This is only used in terrain levels, and will snap all objects when they are placed AND moved to the surface of the terrain. is useful when placing furniture and other objects on an existing surface (terrain, floor, etc.).

== Model properties ==

When selected, the following common properties are shown for models in the object inspector.

{{inspector start}}
{{inspector section|General}}
{{inspector row|Model Instance ID|}}
{{inspector row|Name| This is the user-friendly name that shows up in the hierarchy window. There is no restriction on the name.}}
{{inspector row|Selection Lock| This controls whether this object is selectable or not. This could prevent someone or the artist him/herself from moving or selecting something accidentally. }}
{{inspector row|Visible| Sets the visibility of the model. Hidden models are displayed with a grayed-out box in the hierarchy window.}}

{{inspector section|Export}}
{{inspector row|Export to Game| Flag to export this model to the game. Default is true. This can be used in conjunction with the Lightmap Export flag to create objects that cast baked light shadows but not display.}}
{{inspector row|Lightmap| Flag to send this model to the lightmapper. Default is true. This can be used in conjunction with the Export to Game flag to create objects that cast baked light shadows but not display. You can also set both to false in order to create guide-geometry.}}

{{inspector section|Graphics}}
{{inspector row|Cut Away Override|}}
{{inspector row|DefaultAnimation|}}
{{inspector row|High-LOD| This displays the full model file name that will be used for high LOD.}}
{{inspector row|Low-LOD| This displays the full model file name that will be used for low LOD.}}
{{inspector row|ModelFile| This is the base name of the model file (mmh) that the user specifies. For LODed models, only the root is needed.}}
{{inspector row|Scale|}}
{{inspector row|Show High LOD| Controls the viewport display. If set to true, the high LOD version is displayed if available.}}

{{inspector section|Lighting}}
{{inspector row|Texture Size Multiplier| This multiplies the base texture size of the original model. Default value is 1.0.}}

{{inspector section|Location}}
{{inspector row|Location|This is the location of the model in world coordinates.}}
{{inspector section|Location Relative}}
{{inspector row|Location Relative|This is the location of the model in its parent coordinates.}}

{{inspector section|Pathfinding}}
{{inspector row|Normal|This property is no longer required}}
{{inspector row|Overlapped| This property is no longer required}}

{{inspector section|Statistics|The statistics is based on the currently displayed model LOD.}}
{{inspector row|GPU Memory| The number of bytes this model’s meshes and textures take up in memory. (This feature is no longer supported)}}
{{inspector row|Part Count| The number of parts this model is comprised of.}}
{{inspector row|System Memory| The number of bytes this model takes in memory, including animation blend trees, physics objects, animation controllers, and triggers. Does not include textures and materials.}}
{{inspector end}}

== Model file format ==

Models are stored in the [[MMH]] and [[MSH]] formats. MSH ("mesh") files consist of fairly simple lists of vertexes and triangles, the "raw data" that describes physical shapes. MMH stands for "model mesh hierarchy" and contains information on how to make a usable model out of meshes. MMH files contain a variety of other information in addition to the meshes, such as visual effects.

Area tutorial

2009-11-09T08:12:26Z

Imgettingpissedoff: /* Area transitions via doors */

Once you have created a new module (see [[creating a module]]), the first thing you will likely want to do is create one or more areas where your adventure is going to be set.

== Creating the area ==

[[Image:New resource.png|thumb|New resource menu]]

There are several ways to reach the "new area" command; you can right-click on the resource palette window, or select "new" from the file menu.

<br clear="all" />

Areas are represented with the [[Image:IconArea.png]] icon. When you select it you'll be presented with a "Create New Resource" window:

[[Image:Create new resource.png|center|]]

{{sidebox|
* Resref names should be useful to the designer
* Set the "area layout" property to assign terrain to an area
* "Resource Name" and "Tag" are only seen by developers
* "Name" may be seen by players
}}

Most of the fields are already filled in with good defaults for the module you're working with. You'll need to supply a "ResRef Name", which is the name by which the resource will be known internally to the toolset. (This is the "Name" field on the "Create New Resource" dialog box.) You'll probably want to use a name that will remind you, the module designer, of the purpose or important features of the area. Changing a resource's name is difficult to do later. We're going to call the first area of the tutorial "hut_exterior".

After creating the area you'll be presented with a completely blank area editor. There will be no environment or objects of any kind. To specify what environment you'll be placing objects into, open the object inspector and select the "Area Layout" property. There will be an ellipsis button ([[Image:ellipsis.png]]) in the property's data field that will bring up a resource selection window where you can select an environment to use for this area. The environment we wish to select is in the area layout file "ost101d.arl". Once we select it, the area layout appears in the main area window.

The resource's internal resource name is hut_exterior but the player will not see this when he's playing the game. To give the area a name meaningful to the player we'll set the "Name" field to "Deep in the Swamp". All of the other defaults are fine for now, we will leave them as is.

[[Image:Area tutorial 1.png|thumb|600px|center]]

== Area Basics ==
{{sidebox|
* See [[3D control]] for camera and movement controls
* You can double-click on an object in the area's object list to zoom in to it.
}}

Moving the view around inside the area layout can be somewhat non-intuitive and frustrating at first. The toolset has a number of different control schemes it can be set to; see [[3D control]] for a summary of the various options. By default, you can:

* zoom in and out by using the mouse wheel
* rotate the camera around the target it's focused on by holding the middle button down or by holding down the Ctrl key and the right mouse button while moving the mouse
* translate the camera by holding down the Ctrl key and the left mouse button while moving the mouse

To see where you are a bit better, it is helpful to deactivate real lighting or turn on full brightness. Above the area viewer, the sun-like button should be toggled so that it isn't highlighted; see [[Area]] for a more complete summary of various options within the Area Editor.

Before we move along to placing a starting location, it is important to touch upon Pathfinding points. All BioWare areas include walkmesh or pathfinding information. To view pathfinding information for your area, goto View, then Environment, and then toggle Pathfinding Points on. The green dots represent areas where characters can walk. Note, in this map, the area that is walkable is quite small compared to the entire area. When placing your starting location, you should ensure it is in a walkable portion of the area.

== Setting the start point ==

{{sidebox|
* Create a waypoint to mark where the player starts the game
}}

This is going to be the starting area for the adventure, so we're going to want to define a spot within the area where the player will first appear. This is done by setting a [[waypoint]]. Waypoints are very simple objects that mark locations in an area that other objects in the game can refer to; they are not normally visible to the player. To create a waypoint, right-click somewhere in the area and select "Insert Waypoint" from the resulting menu. A waypoint will appear at the location of your mouse pointer and follow it around along the area's floor; move it to the approximate place you want to have the player appear and left-click to place it. By default the waypoint is named "Waypoint".

The waypoint will be automatically selected, indicated by a yellow wireframe box surrounding it. You'll also see the waypoint listed in the area's object list, to the left of the display window. If you lose track of the waypoint later a good way to find it again is to right-click on the waypoint in the list and select "Zoom to Object" in the resulting menu or double click on its tag to center the object in the display window. The waypoint's properties will be shown in the object inspector. We want to change the waypoint's name to something more informative, in this case to "start". More importantly for the game itself, though, we'll also want to change the waypoint's tag to "start" (it defaults to blank). An object's tag is how scripts and other resources will refer to the waypoint. Since this particular waypoint is never going to be visible to the player it's likely that the waypoint's name will never be seen at all.

The player will also start out facing in the same direction that the waypoint is facing (indicated by the arrow-shaped base of the waypoint object). If we don't want the player to start out facing in the default direction, we'll want to rotate the waypoint to point in a new direction. To rotate an object, use the toolbar to switch from standard selection mode ([[Image:Standard selection mode.png]]) to 3-axis rotation mode ([[Image:3 axis rotation mode.png]]).
When you select the waypoint in this mode you'll see a set of circles around the waypoint's base with various orientations; clicking and holding the mouse button on one of them will allow you to rotate the waypoint around its center.

[[Image:Waypoint rotation.png|center]]

Now that we have an area and a waypoint to start at, we can now tell the module that this is where the player is to appear. Reopen the "Manage Modules" window (available via a command under the File menu), select your module, and click the "Properties" button. This opens the module's properties. For the "Starting Area" property, click on the ellipsis button ([[Image:ellipsis.png]]) and select the starting area from the areas available in the module; since we've only put one area in so far "hut_exterior" will be the only available option. Once the area has been selected we can then select the starting waypoint from the waypoints currently placed in the area. Again, we've only put in one so this will be easy. You can also set the player to appear at the origin of the map (coordinates 0,0,0), but this is generally a poor choice and available only as a default in case there are no waypoints defined yet.

== Area transitions via doors ==

Adventures almost always have more than one area in them, so we'll create a second area to demonstrate travel between the two. The area "hut_interior" will use area layout ost102d, which is a cosy little room that represents the interior of the small hut present in the hut_exterior area.

{{sidebox|
* [[Door]]s are special placeables
* Doors can attach to "hooks" pre-built into the area layout
* Area transition doors use a different "appearance" than within-area doors
}}

Next we will need to create some doors. We'll create a default door placeable using the "New Placable" command, reached in a similar way as the "New Area" command explained earlier (placeables will be covered in the [[Placeable tutorial]], but the core game resources will come with a variety of default doors usable in many situations like this) and place it in the area near the empty doorframe built into the hut's exterior. For an area transition, use one of the "Area Transition" appearances for the door. To place the door, click on it in the palette; the mouse cursor will turn into a crosshair; then click in the area viewer near the doorframe.

As a side note, if you accidentally use one of the standard door appearances it won't work as an area transition: the door will simply swing open when clicked on instead. Each standard door appearance has a matching area transition door appearance in the resource database so this can be an easy mistake to make, but it's also easily correctable - just go back to the door's placeable resource and swap in the correct appearance, and all copies of that door in use throughout your game will be updated. The "Area Transition" doors are at the top under the Appearance list, e.g. "Area Transition, Ferelden Small" as apposed to "Door, Ferelden, Small".

You may notice that when the door you placed in the area is selected a small blue sphere will appear at one edge in addition to the yellow wireframe bounding box. This is the door's "hook". Area layouts come with hidden "hooks" pre-installed to place doors on, and doors have matching hooks of their own. If you click on the blue sphere it will turn red, and all of the compatible door hooks built into the area's layout will appear. The following image illustrates this:

[[Image:Door with door hook selected.png|400px|center|thumb|Drag the red sphere near to the blue sphere to automatically position the door]]

To hook a door up with its frame, simply click and drag the door's hook to a location very close to the matching frame hook. You don't need to get the positioning exact; if the two hooks are close enough together when you release the mouse button they'll automatically snap together. The door will be positioned and reoriented to fit correctly into the frame. Make sure you're still in the 'Standard Selection' mode ([[Image:IconStandardSelection.png]]) for the snap to occur, if you're in the more advanced 3 Axis Movement tool, the snap will not happen.

Note that door hooks are only there to make it easy to get exact matches on frames and walls that need a snug fit, to ensure that Artists and Designers don't have to spend a lot of time putting it in place. Doors will function just as well off of hooks as on them.

{{sidebox|
* Area transition effect is defined in the door's "Variables" property
}}

Next, we'll tell the game engine that the door is an area transition door and that when the player clicks on it he will be transported to another area of the game. This is done by setting two of the door's [[variable]]s. Select the door (either in the area's object palette or directly in the main display window) and right-click on it, selecting "properties" from the resulting menu. This will open the door's properties in the Object Inspector window. Select the "Variables" property and click on the ellipsis ([[Image:ellipsis.png]]) button. This will open up the variable browser for that particular instance of the door object.

There are two key variables in this list that we'll need to set:

*PLC_AT_DEST_AREA_TAG - tag of the destination area
*PLC_AT_DEST_TAG - tag of the destination waypoint within the destination area

Once we've set these the door will become an area transition door, and when the player interacts with it they'll be transported to the target area.

The destination area is "hut_interior". We'll create a waypoint just inside the hut's interior door, tagged "hut_door_interior", to serve as the place where the player appears.

Here is how the exterior door's variables should look:

[[Image:Area tutorial door variables.png|frame|center|Area transition door's variables]]

And here is the interior door, with the destination waypoint:

[[Image:Area tutorial interior door.png|frame|center|Interior door with destination waypoint]]

The interior door is set up in the same manner, with a destination area of "hut_exterior" and a matching destination waypoint of "hut_door_exterior".

{{sidebox|
* Use invisible area transition "doors" when the transition is already built into the area layout art
}}

If you want to create an area transition that doesn't look like a door, or is otherwise already represented by the level art, you can use an invisible 'door' instead. Appearances for these invisible placeables are named "Area Transition, Invisible". Set its variables the same way as was done for the visible door.

[[Image:Area Transition, Invisible.png|frame|center|Invisible area transition]]

The player won't see this 'door' in the game, but when he moves the mouse pointer over it it will change to signify that an area transition lies there and it can be right-clicked to be activated just like a visible door.

== Area transitions via triggers ==

{{sidebox|
* Triggers use variables with a different prefix for setting their area transition effect
}}

Finally, you can also create an area transition that triggers automatically when the player walks into a predefined area. This is done using [[trigger]]s. ([[Image:IconTrigger.png]]) You'll first have to create a trigger resource, much like how you had to create a placeable door earlier, but trigger resources are much simpler and for area transitions you won't need to change any of the defaults. Create a default trigger with "New -> Trigger" (either by right-clicking the resource palette or from the File menu) and give it an informative name such as "trigger_area_transition".

Go back to your area map, select the trigger from the resource palette, and then click on the map to define the corner points of the area the trigger will occupy. Double-click the last vertex to complete the polygon. A trigger can have any number of vertices, and vertices can be moved, added, or deleted after the trigger is created so don't worry if you don't get it exactly right. Note that the blue plane the trigger uses to show the enclosed area will pass through the ground and may not be entirely visible in the toolset, but it extends infinitely upward so the trigger will still take effect if the player enters its boundaries.

To set the trigger's destination, you'll find a familiar pair of variables in the trigger's default variable table:

*TRIGGER_AT_DEST_AREA_TAG - tag of the destination area
*TRIGGER_AT_DEST_TAG - tag of the destination waypoint within the destination area

(Note the prefix "TRIGGER" instead of "PLC")

Below is an example where we've placed both a trigger and an invisible door across a pathway. Note that this is redundant, only one or the other is really needed. For most purposes a placeable area transition is probably best. (''It is worth noting that placeable area transitions prompt a popup asking the player if they want to transition when bumped, but not when clicked upon - effectively acting as either a door or a trigger.'') The waypoint shown is the arrival spot for the player when coming in from the other side; note how it's placed outside the trigger area, allowing the player to immediately back up and retreat through the area transition if he chooses.

[[Image:Area Transition, invisible with trigger.png|center]]

== Grouping Placeables ==

{{sidebox|
* Two or more placeables can be grouped together using Associations.
}}

Often the placeables within an area are related. For example, a firepit placeable probably has an associated sound emitter. The toolset needs to be told that these two objects are related.

# Create a new Placeable and change its "Appearance" to "Firepit (Dialog)", then place it in your area.
# Next, click on the musical note icon in the Palette for "Sounds".
# In the folder tree, go to global_amb_fade > 3D_placeables > 3d_emitter and select the amb_ext_smfire1_lp and place the emitter in your area.
# Right-click on the firepit to bring up the menu and choose "Add Associated object." The cursor changes to a cross-hair.
# Click on the sound emitter placeable.

Now when you drag the firepit placeable around the area, the sound emitter will automatically follow. Use the "Managed Links" menu item if you want to remove an association. Note that associations are uni-directional; you can still move the sound emitter without moving the firepit. Examples of other useful associations: a table and all of the items on top of the table, a table surrounded by chairs, etc.

[[Category:Areas]]
[[Category:Tutorials]]

Area tutorial

2009-11-09T08:11:39Z

Imgettingpissedoff: /* Area transitions via doors */

Once you have created a new module (see [[creating a module]]), the first thing you will likely want to do is create one or more areas where your adventure is going to be set.

== Creating the area ==

[[Image:New resource.png|thumb|New resource menu]]

There are several ways to reach the "new area" command; you can right-click on the resource palette window, or select "new" from the file menu.

<br clear="all" />

Areas are represented with the [[Image:IconArea.png]] icon. When you select it you'll be presented with a "Create New Resource" window:

[[Image:Create new resource.png|center|]]

{{sidebox|
* Resref names should be useful to the designer
* Set the "area layout" property to assign terrain to an area
* "Resource Name" and "Tag" are only seen by developers
* "Name" may be seen by players
}}

Most of the fields are already filled in with good defaults for the module you're working with. You'll need to supply a "ResRef Name", which is the name by which the resource will be known internally to the toolset. (This is the "Name" field on the "Create New Resource" dialog box.) You'll probably want to use a name that will remind you, the module designer, of the purpose or important features of the area. Changing a resource's name is difficult to do later. We're going to call the first area of the tutorial "hut_exterior".

After creating the area you'll be presented with a completely blank area editor. There will be no environment or objects of any kind. To specify what environment you'll be placing objects into, open the object inspector and select the "Area Layout" property. There will be an ellipsis button ([[Image:ellipsis.png]]) in the property's data field that will bring up a resource selection window where you can select an environment to use for this area. The environment we wish to select is in the area layout file "ost101d.arl". Once we select it, the area layout appears in the main area window.

The resource's internal resource name is hut_exterior but the player will not see this when he's playing the game. To give the area a name meaningful to the player we'll set the "Name" field to "Deep in the Swamp". All of the other defaults are fine for now, we will leave them as is.

[[Image:Area tutorial 1.png|thumb|600px|center]]

== Area Basics ==
{{sidebox|
* See [[3D control]] for camera and movement controls
* You can double-click on an object in the area's object list to zoom in to it.
}}

Moving the view around inside the area layout can be somewhat non-intuitive and frustrating at first. The toolset has a number of different control schemes it can be set to; see [[3D control]] for a summary of the various options. By default, you can:

* zoom in and out by using the mouse wheel
* rotate the camera around the target it's focused on by holding the middle button down or by holding down the Ctrl key and the right mouse button while moving the mouse
* translate the camera by holding down the Ctrl key and the left mouse button while moving the mouse

To see where you are a bit better, it is helpful to deactivate real lighting or turn on full brightness. Above the area viewer, the sun-like button should be toggled so that it isn't highlighted; see [[Area]] for a more complete summary of various options within the Area Editor.

Before we move along to placing a starting location, it is important to touch upon Pathfinding points. All BioWare areas include walkmesh or pathfinding information. To view pathfinding information for your area, goto View, then Environment, and then toggle Pathfinding Points on. The green dots represent areas where characters can walk. Note, in this map, the area that is walkable is quite small compared to the entire area. When placing your starting location, you should ensure it is in a walkable portion of the area.

== Setting the start point ==

{{sidebox|
* Create a waypoint to mark where the player starts the game
}}

This is going to be the starting area for the adventure, so we're going to want to define a spot within the area where the player will first appear. This is done by setting a [[waypoint]]. Waypoints are very simple objects that mark locations in an area that other objects in the game can refer to; they are not normally visible to the player. To create a waypoint, right-click somewhere in the area and select "Insert Waypoint" from the resulting menu. A waypoint will appear at the location of your mouse pointer and follow it around along the area's floor; move it to the approximate place you want to have the player appear and left-click to place it. By default the waypoint is named "Waypoint".

The waypoint will be automatically selected, indicated by a yellow wireframe box surrounding it. You'll also see the waypoint listed in the area's object list, to the left of the display window. If you lose track of the waypoint later a good way to find it again is to right-click on the waypoint in the list and select "Zoom to Object" in the resulting menu or double click on its tag to center the object in the display window. The waypoint's properties will be shown in the object inspector. We want to change the waypoint's name to something more informative, in this case to "start". More importantly for the game itself, though, we'll also want to change the waypoint's tag to "start" (it defaults to blank). An object's tag is how scripts and other resources will refer to the waypoint. Since this particular waypoint is never going to be visible to the player it's likely that the waypoint's name will never be seen at all.

The player will also start out facing in the same direction that the waypoint is facing (indicated by the arrow-shaped base of the waypoint object). If we don't want the player to start out facing in the default direction, we'll want to rotate the waypoint to point in a new direction. To rotate an object, use the toolbar to switch from standard selection mode ([[Image:Standard selection mode.png]]) to 3-axis rotation mode ([[Image:3 axis rotation mode.png]]).
When you select the waypoint in this mode you'll see a set of circles around the waypoint's base with various orientations; clicking and holding the mouse button on one of them will allow you to rotate the waypoint around its center.

[[Image:Waypoint rotation.png|center]]

Now that we have an area and a waypoint to start at, we can now tell the module that this is where the player is to appear. Reopen the "Manage Modules" window (available via a command under the File menu), select your module, and click the "Properties" button. This opens the module's properties. For the "Starting Area" property, click on the ellipsis button ([[Image:ellipsis.png]]) and select the starting area from the areas available in the module; since we've only put one area in so far "hut_exterior" will be the only available option. Once the area has been selected we can then select the starting waypoint from the waypoints currently placed in the area. Again, we've only put in one so this will be easy. You can also set the player to appear at the origin of the map (coordinates 0,0,0), but this is generally a poor choice and available only as a default in case there are no waypoints defined yet.

== Area transitions via doors ==

Adventures almost always have more than one area in them, so we'll create a second area to demonstrate travel between the two. The area "hut_interior" will use area layout ost102d, which is a cosy little room that represents the interior of the small hut present in the hut_exterior area.

{{sidebox|
* [[Door]]s are special placeables
* Doors can attach to "hooks" pre-built into the area layout
* Area transition doors use a different "appearance" than within-area doors
}}

Next we will need to create some doors. We'll create a default door placeable using the "New Placable" command, reached in a similar way as the "New Area" command explained earlier (placeables will be covered in the [[Placeable tutorial]], but the core game resources will come with a variety of default doors usable in many situations like this) and place it in the area near the empty doorframe built into the hut's exterior. For an area transition, use one of the "Area Transition" appearances for the door. To place the door, click on it in the palette; the mouse cursor will turn into a crosshair; then click in the area viewer near the doorframe.

As a side note, if you accidentally use one of the standard door appearances it won't work as an area transition: the door will simply swing open when clicked on instead. Each standard door appearance has a matching area transition door appearance in the resource database so this can be an easy mistake to make, but it's also easily correctable - just go back to the door's placeable resource and swap in the correct appearance, and all copies of that door in use throughout your game will be updated. The "Area Transition" doors are at the top of the list of placeables under the Appearance list, e.g. "Area Transition, Ferelden Small" as apposed to "Door, Ferelden, Small".

You may notice that when the door you placed in the area is selected a small blue sphere will appear at one edge in addition to the yellow wireframe bounding box. This is the door's "hook". Area layouts come with hidden "hooks" pre-installed to place doors on, and doors have matching hooks of their own. If you click on the blue sphere it will turn red, and all of the compatible door hooks built into the area's layout will appear. The following image illustrates this:

[[Image:Door with door hook selected.png|400px|center|thumb|Drag the red sphere near to the blue sphere to automatically position the door]]

To hook a door up with its frame, simply click and drag the door's hook to a location very close to the matching frame hook. You don't need to get the positioning exact; if the two hooks are close enough together when you release the mouse button they'll automatically snap together. The door will be positioned and reoriented to fit correctly into the frame. Make sure you're still in the 'Standard Selection' mode ([[Image:IconStandardSelection.png]]) for the snap to occur, if you're in the more advanced 3 Axis Movement tool, the snap will not happen.

Note that door hooks are only there to make it easy to get exact matches on frames and walls that need a snug fit, to ensure that Artists and Designers don't have to spend a lot of time putting it in place. Doors will function just as well off of hooks as on them.

{{sidebox|
* Area transition effect is defined in the door's "Variables" property
}}

Next, we'll tell the game engine that the door is an area transition door and that when the player clicks on it he will be transported to another area of the game. This is done by setting two of the door's [[variable]]s. Select the door (either in the area's object palette or directly in the main display window) and right-click on it, selecting "properties" from the resulting menu. This will open the door's properties in the Object Inspector window. Select the "Variables" property and click on the ellipsis ([[Image:ellipsis.png]]) button. This will open up the variable browser for that particular instance of the door object.

There are two key variables in this list that we'll need to set:

*PLC_AT_DEST_AREA_TAG - tag of the destination area
*PLC_AT_DEST_TAG - tag of the destination waypoint within the destination area

Once we've set these the door will become an area transition door, and when the player interacts with it they'll be transported to the target area.

The destination area is "hut_interior". We'll create a waypoint just inside the hut's interior door, tagged "hut_door_interior", to serve as the place where the player appears.

Here is how the exterior door's variables should look:

[[Image:Area tutorial door variables.png|frame|center|Area transition door's variables]]

And here is the interior door, with the destination waypoint:

[[Image:Area tutorial interior door.png|frame|center|Interior door with destination waypoint]]

The interior door is set up in the same manner, with a destination area of "hut_exterior" and a matching destination waypoint of "hut_door_exterior".

{{sidebox|
* Use invisible area transition "doors" when the transition is already built into the area layout art
}}

If you want to create an area transition that doesn't look like a door, or is otherwise already represented by the level art, you can use an invisible 'door' instead. Appearances for these invisible placeables are named "Area Transition, Invisible". Set its variables the same way as was done for the visible door.

[[Image:Area Transition, Invisible.png|frame|center|Invisible area transition]]

The player won't see this 'door' in the game, but when he moves the mouse pointer over it it will change to signify that an area transition lies there and it can be right-clicked to be activated just like a visible door.

== Area transitions via triggers ==

{{sidebox|
* Triggers use variables with a different prefix for setting their area transition effect
}}

Finally, you can also create an area transition that triggers automatically when the player walks into a predefined area. This is done using [[trigger]]s. ([[Image:IconTrigger.png]]) You'll first have to create a trigger resource, much like how you had to create a placeable door earlier, but trigger resources are much simpler and for area transitions you won't need to change any of the defaults. Create a default trigger with "New -> Trigger" (either by right-clicking the resource palette or from the File menu) and give it an informative name such as "trigger_area_transition".

Go back to your area map, select the trigger from the resource palette, and then click on the map to define the corner points of the area the trigger will occupy. Double-click the last vertex to complete the polygon. A trigger can have any number of vertices, and vertices can be moved, added, or deleted after the trigger is created so don't worry if you don't get it exactly right. Note that the blue plane the trigger uses to show the enclosed area will pass through the ground and may not be entirely visible in the toolset, but it extends infinitely upward so the trigger will still take effect if the player enters its boundaries.

To set the trigger's destination, you'll find a familiar pair of variables in the trigger's default variable table:

*TRIGGER_AT_DEST_AREA_TAG - tag of the destination area
*TRIGGER_AT_DEST_TAG - tag of the destination waypoint within the destination area

(Note the prefix "TRIGGER" instead of "PLC")

Below is an example where we've placed both a trigger and an invisible door across a pathway. Note that this is redundant, only one or the other is really needed. For most purposes a placeable area transition is probably best. (''It is worth noting that placeable area transitions prompt a popup asking the player if they want to transition when bumped, but not when clicked upon - effectively acting as either a door or a trigger.'') The waypoint shown is the arrival spot for the player when coming in from the other side; note how it's placed outside the trigger area, allowing the player to immediately back up and retreat through the area transition if he chooses.

[[Image:Area Transition, invisible with trigger.png|center]]

== Grouping Placeables ==

{{sidebox|
* Two or more placeables can be grouped together using Associations.
}}

Often the placeables within an area are related. For example, a firepit placeable probably has an associated sound emitter. The toolset needs to be told that these two objects are related.

# Create a new Placeable and change its "Appearance" to "Firepit (Dialog)", then place it in your area.
# Next, click on the musical note icon in the Palette for "Sounds".
# In the folder tree, go to global_amb_fade > 3D_placeables > 3d_emitter and select the amb_ext_smfire1_lp and place the emitter in your area.
# Right-click on the firepit to bring up the menu and choose "Add Associated object." The cursor changes to a cross-hair.
# Click on the sound emitter placeable.

Now when you drag the firepit placeable around the area, the sound emitter will automatically follow. Use the "Managed Links" menu item if you want to remove an association. Note that associations are uni-directional; you can still move the sound emitter without moving the firepit. Examples of other useful associations: a table and all of the items on top of the table, a table surrounded by chairs, etc.

[[Category:Areas]]
[[Category:Tutorials]]