Dragon Age Toolset Wiki - User contributions [en]

Installation troubleshooting

2009-12-12T12:53:48Z

Axe Murderer: punctuation

'''NOTE: version 1.00 had a problem with installing to directories with paths longer than 58 characters, which is the default for Steam installations. 1.01 overcomes this problem, but if you wish to install 1.00 see [[Installation with Steam]] for details and a workaround.'''

Refer to [[Known issues]] for the current list of issues that are being worked on, and their status.

See [[Installing the toolset]] for general information and guidance about installing the Dragon Age toolset. If something goes wrong during that process this page may have useful information and advice.

If you experience a crash, logs can be found in <code>My Documents\BioWare\Dragon Age\Toolset\logs</code>. The log filenames will include the date on which the log file was created. Sending in a log will help greatly with bug fixing.

== General errors ==

If you get the "Dragon Age: Origins game install not found" error when you run the toolset installer:
* You must have the game installed before you can install the toolset. Please install the game first.
* If you have installed the game, but not yet run the configure program, you will get this message: "Please launch the Dragon Age: Origins Configure Utility". This happens automatically the first time you attempt to run the game. After you have successfully configured and launched the game at least once, you should no longer get this error.

If the toolset cannot find DLLs you may need to run the configuration tool after installation to tell the toolset where to find the Dragon Age build. This can happen if you uninstall the toolset and then reinstall it again in a different location.

If you install the toolset in a non-default location, the toolset may not be made aware of where the [[Resource Builder]] has been put. This can be easily fixed by changing the "Resource Build Path" variable found in Options->Environment.

On Vista and Windows 7 systems you may get a message reading "Windows has blocked some of the features of this program." It will indicate that the offending program is "Microsoft Register Server", located at C:\windows\system32\regsvr32.exe. The installer makes use of this program to register the game engine's DLL for use by the toolset. You can choose to block or allow this, the installer will work either way. It is somewhat safer to leave it blocked.

MSSQL Express 2005's installer has a limitation that prevents it from installing to a directory path that's longer than 58 characters.[http://support.microsoft.com/kb/935371] Version 1.01 of the toolset installer has addressed this issue by installing the database to a predefined location independant of the location of the game executable.

== "[[Unable to connect to the database]]" ==
If you receive the "unable to connect to the database" error message there are many reasons why this happens, and various ways to correct it.

A new troubleshooting page for this error has been created. Rather than random suggestions of things to try, it has a troubleshooting flowchart to help you diagnose and fix your problem. Please visit [[Unable to connect to the database]] for the latest help with this problem.

== Installer hangs at the stage of "Execute:regsvr32.exe /s "C:\Dragon Age\tools\Engine.dll" ==

In some instances Regsvr32.exe is failing for some unknown reason and refusing to terminate. Version 1.01 of the toolset installer has addressed this problem by no longer waiting for a return value from regsvr32, so the installer should no longer hang at this stage.

If you encounter this problem on installing version 1.00, open the task manager and kill regsvr32.exe. The installer should continue on installing after that's done. This could mean that engine.dll won't be registered, however, so you may need to do that manually.

To manually register the dll, go to "run" in your start menu and type in the following command:

regsvr32 "C:\Program Files\Dragon Age\tools\Engine.dll"

(or substitute the actual path to Engine.dll if it it's different from that). Make sure to run this as an administrator. It should pop up a "success!" message. If it fails, it should hopefully pop up an error message that will tell us how to fix it once and for all. It should be safe to re-try this command over and over, registering the dll more than once is harmless. Some users have found that the only way to successfully register Engine.dll is to boot up in safe mode and log in as administrator before registering it. After it is registered, you can then boot normally.

NOTE: If you purchased the game through Steam, your Engine.dll will be located in a different folder. Assuming that you installed the toolset in the default folder, the path will be:

C:\Program Files\Steam\steamapps\common\dragon age origins\tools

So the command in the Run window will be"

regsvr32 "C:\Program Files\Steam\steamapps\common\dragon age origins\tools\Engine.dll"

== Other database issues and solutions ==

If you have never installed MSSQLServer Express, check for updates available for it through Windows Update after installing the toolset.

If the SQL install fails with a crash it is possible that it is conflicting with MSXML6. If you have MSXML6 installed, uninstall it and try reinstalling the toolset. See [http://support.microsoft.com/kb/968749 Microsoft's support page on this issue]. If you have trouble uninstalling MSXML6, try the [http://support.microsoft.com/kb/290301 Microsoft Windows Installer Cleanup Utility].

During the SQL Server Express installation when the installation script attempts to start the database, a message box with the "The SQL Server service failed to start..." error message and options to Retry or Cancel may pop up.
*Don't hit cancel. Cancel rolls back the installation, preventing the creation of the BWDATOOLSET database. You'll need to reinstall from scratch if this happens.
*Instead, navigate to C:\Documents and Settings\NetworkService\Application Data\Microsoft\ and right click on the Protect folder and open the Properties window. On the Security tab add NETWORK SERVICE to the list of Groups and User names and grant it Full Permissions.
*If you don't have a Security tab then close the Properties window and select Tools | Folder Options from Explorer's menu bar. In the Folder Options window click on the View tab, scroll to the last option and uncheck Use simple file sharing (Recommended) option. Now you should be able to do complete the previous step.
*Finally return to the "The SQL Server service failed to start..." error message and click on the Retry option.

The version of MSSQL Server 2005 included with the toolset may have trouble installing on 64-bit operating systems. This can be indicated by SQL Server Error 70047 in the installer's logs. To resolve this problem, install [http://go.microsoft.com/fwlink/?LinkId=55734 Microsoft .NET Framework Version 2.0] for 64-bit architectures before installing the toolset. 

You may also encounter issues running migration scripts on 64 bit OSes. An alternate migration script can be found here: http://social.bioware.com/project/46/

You may get issues with access permissions. This can be avoided by giving your username admin rights to the database. To do this:
# Run "SQL Server Surface Area Configuration" (should be on your start menu under Microsoft SQL Server 2005)
# Select the "Add new administrator" option.
# Add yourself as administrator.

If you get a syntax error during installation, it could be caused by the path being too long. Rather than moving your whole install, try this: http://support.microsoft.com/kb/935371

See [[Manual database installation]] for instructions on how to manually set up the database for use with your toolset.

== Windows XP SP 2 and endless reboot cycles after install ==

The MSSQL Server Express installer bundled with the toolset has a potential issue when installed on Windows XP Service Pack 2 that can cause an endless cycle of reboots. The toolset installer will warn you not to proceed if it detects SP2 on your system. Dragon Age: Origins has Service Pack 3 as part of its minimum installation requirements, so you should try upgrading to Service Pack 3 and reinstall.

If you're stuck in an endless reboot cycle:

*Press ctrl+alt+del and open the task manager as soon as possible. Failing that, try booting in safe mode by holding down F8 during the boot process.
*Then go to the start menu and in execute type in "msconfig"
*In MSConfig go to services and deactivate all the SQL services.
*Now you can go to control panel...software and uninstall the SQL server from the last piece upward.

Alternately, instead of booting into safe mode after holding down F8 during boot, you can choose the option "Last known good configuration (your most recent settings that worked)". This may restore your system to a functional state and allow SQL Server to function correctly.

Once you've uninstalled SQL Server this should prevent further reboot cycles. You can now install Windows XP Service Pack 3.

== Externals links for troubleshooting ==

[http://forum.canardpc.com/showthread.php?p=2675920 Canard PC forum] French only :Forum résumant la marche a faire en cas de problèmes.

[[Category:Toolset installation]]

Installing the toolset

2009-12-12T12:50:29Z

Axe Murderer: /* Troubleshooting */ punctuation

The Dragon Age Toolset installer comes with several pieces of third-party software that are needed for the toolset to function. They are:

* DirectX 9.0c
* Visual C Runtime Library
* Microsoft SQL Server Express 2005 Edition
* Nvidia PhysX drivers

These components will be installed along with the toolset by the toolset's installer.

== Location ==

The first screen you'll get to after starting the installer and passing the title page is the install location selector. The toolset can only install the program into a specific subdirectory of the Dragon Age game directory, so you won't be able to alter the installation path; it's for informational purposes.

'''Note:''' MSSQL Express 2005 is bundled with this toolset and is required for it to function. Unfortunately, MSSQL Express 2005's installer has a limitation that prevents it from installing to a directory path that's longer than 58 characters.[http://support.microsoft.com/kb/935371]

Follow the instructions on [[installation into a directory with a long path name]] for a workaround on this issue.

== Components ==

The next screen after location has been selected is where you can choose which components to install. There are only two selectable components here; Core Resources (the toolset itself) and Microsoft SQL Server Express. To run the toolkit you'll obviously need to install the Core Resources option. SQL Server is presented as a separate option so that if you already have a database server installed on your system you can use that instead of installing a whole new one.

If you don't have an SQL server installed, or if you don't know whether you have one installed, it's safe to go with the default and install SQL Server Express. SQLServer's installer will check the existing components and, finding that all required components are already in place, won't do anything after you click "finish."

== Manual database selection ==

If you choose not to install SQL Server Express, the installer will ask for a database server and database name to install the toolset's resource database to instead. The default server is <code>.\BWDATOOLSET</code> and the default database name is <code>bw_dragonage_content</code>.

== Installation ==

Once you have selected these options the Dragon Age toolset will begin the installation process. This can take a while. When the install process is finished you'll be given the option to read a readme.txt file.

The toolset will create a start menu folder named "Dragon Age". The start menu folder will include a link to start the toolset, a link to the toolset's uninstaller, and a link to the toolset's external configuration utility.

The installer will write a log file in your My Documents folder. If installation fails this log file will be helpful for debugging purposes.

If you are installing over a previous version of the toolset, you may need to update the format of your old database to make it compatible with the new version of the toolset. See [[database migration]] for details.

=== Lightmapper ===

The [[lightmap|lightmapper]] is the tool used to calculate lighting in level layouts. You only need to use it if you're going to be creating or modifying level layouts. The lightmapper included with the toolset requires Python to run but Python isn't currently bundled with the toolset, so if you don't already have it installed you'll need to do the following:

# Install [http://www.python.org/ftp/python/2.5.4/python-2.5.4.msi Python 2.5.4 ]
# Install the [http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/pywin32-214.win32-py2.5.exe/download win32 extensions] for Python 2.5 '''OR'''
# Install [http://downloads.activestate.com/ActivePython/windows/2.5/ActivePython-2.5.4.4-win32-x86.msi ActiveState Python 2.5.4.4]

The easiest way to do this is to download and install ActiveState python which comes with the needed extensions. Just click through the defaults on the installer and you will be ready to go. If you want to use python.org installer, maker sure to install it first, then install the win32 extensions.

* If you don't have Python installed and try to run the lightmapper, you'll receive a standard Windows error message indicating that "EclipseRay.exe has stopped working.

* Note for 64 bit machines: There appears to be a bug with the 64-bit version of ActiveState Python 2.5 for Windows that prevents the lightmapper from functioning. Install the 32-bit version instead, it works. The 32-bit version is the one linked above.

* Do not install both ActivePython and Python.org. This will most likely cause you to get an Error Code 1 when rendering lightmaps.

* If you get an error code of -1073741819 this means you either have the 64 bit version or you have a version higher than 2.5. Uninstall and use the installers from the links above.

== Configuration ==

The external configuration utility [[ConfigureToolset.exe]] (found in the Dragon Age\tools directory) is used to configure the toolset's database connection and to tell the toolset where the game's executable is. You shouldn't need to run the configuration utility during routine usage of the toolset, and if the defaults set up by your installer work you may not need to run it at all.

The default database string is "<code>Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=bw_dragonage_content;Data Source=.\SQLEXPRESS</code>". For advanced configuration, click on the ellipsis button ([[Image:ellipsis.png]]) to open the data link properties window.

== Uninstallation ==

An uninstaller shortcut is available from the same start menu folder as the toolset itself. It will autodetect the location you installed the toolset in, display it to you to confirm that this is correct, and then after you click "next" it will ask which components to uninstall.

* Core Resources - uninstalled by default, this is the toolset itself.
* Database - Since the uninstaller can't automatically determine if you're using SQLServer Express purposes other than just the Dragon Age toolset, SQLServer is ''not'' uninstalled automatically by default. To have the uninstaller remove the database server as well, unselect this checkbox.

The uninstaller is generated on installation and therefore isn't signed. This may cause Vista to complain under some circumstances but shouldn't affect the uninstaller's functioning.

== Troubleshooting ==

See [[installation troubleshooting]] for a list of common problems that can occur during installation and how to correct or work around them.

Note that there is currently an issue with installing the toolset for games that have been installed via Steam. See [[Installation with Steam]] for specific instructions on how to resolve this issue. If you have installed your game in a directory with a path name longer than 58 characters you may also encounter this same issue.

If you experience a crash, logs can be found in <code>My Documents\BioWare\Dragon Age\Toolset\logs</code>. The log filenames will include the date on which the log file was created. Sending in a log will help greatly with bug fixing.

== Documentation ==

Documentation is currently provided via the wiki at:

http://social.bioware.com/wiki/datoolset/

[[Category:Toolset installation]]

EVENT TYPE CRAFT ITEM

2009-11-29T19:52:06Z

Axe Murderer: missing the link brackets

{{needs review}}
{{event
|sourcefile=script.ldf
|when=
|from=[[engine]]
|to=[[module]]
|object0name=oCrafter
}}

[[Category:Event types|CRAFT_ITEM]]

Ambient behaviour

2009-11-27T16:52:02Z

Axe Murderer: /* Local Variables (var_creature) */ Incorrect information, someone verify my assumption that PATROL == palindrome order is proper

Ambient behaviour begins when the player moves within 50m of a creature and ceases when the player remains more than 50m away for at least 40s. Ambient behaviour alternates between a movement phase and an animation phase, simulating a bubble of activity around the player. In a movement phase, the creature (optionally) moves to a new destination (typically a [[waypoint]] but it could be any object) and turns to face the same direction as the destination object. In an animation phase, the creature (optionally) performs one or more animations either in sequence or at random. Exact behaviour is controlled by local variables set on either the creature instance or template (see table below). All other local variables with the prefix AMBIENT_* are used internally by the ambient behaviour system (see script [[sys_ambient_h]].nss) and should not be manually modified. Never directly modify AMBIENT_* local variables at run time using [[SetLocalInt]] - always use the functions [[Ambient_Start]], [[Ambient_Stop]], [[Ambient_OverrideBehaviour]], and [[Ambient_RestoreBehaviour]] instead. Ambient behaviour is persisted when a game is saved and automatically resumes when a game is loaded.

== Local Variables (var_creature) ==

{{Variable table start}}
{{Variable table row|AMBIENT_SYSTEM_STATE| int| 0| Bitmask controlling ambient system operation. (ergo, values below are in hexadecimal).
* 0x01 (AMBIENT_SYSTEM_ENABLED): Ambient behaviour enabled. For non-looping animations this is the only bit that need be set.
* 0x02 (AMBIENT_SYSTEM_SPAWNSTART: Begin ambient behaviour immediately after spawning. Generally, only infinitely looping animations require this.
* 0x04 (AMBIENT_SYSTEM_NOPLAYNEXT): Sets '''bPlayNext''' parameter to [[CommandPlayAnimation]] to false. Only infinitely looping animations require this.
* 0x08 (AMBIENT_SYSTEM_NOBLEND): Sets '''bBlendIn''' parameter to [[CommandPlayAnimation]] to false. Set this to force a creature to resume an infinitely looping animation after a conversation.
* 0x10 (AMBIENT_SYSTEM_ALWAYSON): Ambient behaviour never stops, regardless of distance to player. This should rarely, if ever, be used but at least the functionality exists if needed.}}
{{Variable table row|AMBIENT_MOVE_PATTERN| int | 0 | Dictates how the creature moves. Add 100 to the values below make creature run instead of walk.
* 0 (AMBIENT_MOVE_NONE): No ambient movement
* 1 (AMBIENT_MOVE_PATROL): Patrol waypoints (1, 2, 3, 2, 1, ...)
* 2 (AMBIENT_MOVE_LOOP): Loop through waypoints (1, 2, 3, 1, 2, 3, ...)
* 3 (AMBIENT_MOVE_WARP): Jump creature from the last waypoint to the first (1, 2, 3, jump to 1, 2, 3, ...)
* 4 (AMBIENT_MOVE_RANDOM): Move to a random waypoint other than the one the creature is currently at
* 5 (AMBIENT_MOVE_WANDER): Move to random location within 10m of home location
* 6 (AMBIENT_MOVE_WANDER_FAR): Move to random location within 30m of home location
* 7 (AMBIENT_MOVE_PATH_PATROL): Patrol all waypoints using [[CommandMoveToMultiLocations]] (1,2,3,2,1,...)
* 8 (AMBIENT_MOVE_PATH_LOOP): Loop through all waypoints using [[CommandMoveToMultiLocations]] (1,2,3. 1,2,3)
* 9 (AMBIENT_MOVE_ONCE): Walk through the waypoint set once (1-2-3)}}
{{Variable table row|AMBIENT_MOVE_PREFIX| string | ap_<tag>| The prefix used to determine the waypoints the creature can travel to. Note that ''<tag>'' is a placeholder filled in at run-time with the tag of the creature. Hence, for example, if AMBIENT_MOVE_PREFIX is ''ap_<tag>'' and the creature's tag is ''cr_dog'' then the system will look for waypoints with tags ''ap_cr_dog_01'', ''ap_cr_dog_02'', ''etc''. If no waypoint is found with the ''_01'' extension, the system will search instead for all waypoints with tags matching the AMBIENT_MOVE_PREFIX value exactly (i.e. ''ap_cr_dog''). This is useful in cases where you just want to add N waypoints all with the same tag.}}
{{Variable table row| AMBIENT_ANIM_PATTERN| int | 0 | Index into [[ambient_ai.xls]]. Specifies the list of possible actions the creature can/will perform during an animation phase.
* 0: No ambient animation pattern (ergo, no ambient animations).}}
{{Variable table row| AMBIENT_ANIM_FREQ| float | -1.0 | Animation frequency. The part left of the decimal specifies the minimum and the part right of the decimal specifies the maximum number of random animations to play during an animation phase. So, for example, a value of 1.3 will play between 1 and 3 random animations from the animation pattern listed in ambient_ai.xls. A value of -1.0 plays all animations in the animation pattern in the order they are listed in ambient_ai.xls. Animation pattens that are highlighted in green on the worksheeet should always be played in order (i.e. AMBIENT_ANIM_FREQ is -1.0).}}
{{Variable table row| AMBIENT_COMMAND | int | 0 |If non-zero, this value forces the creature to perform a specific command (instead of moving and animating).
* 0: Use standard ambient ambient behaviour system to perform movement and animations.
* 1: Forces creature to attack the nearest object with tag ''<tag>_target''. There's an interval of 1-5 seconds between attack commands.
* 2: Forces creature to attack the nearest object with tag ''<tag>_target''. There's an interval of 0-0.5 seconds between attack commands.}}
{{Variable table row|AMBIENT_ANIM_PATTERN_OVERRIDE| int| 0| Overrides AMBIENT_ANIM_PATTERN if non-zero.}}
{{Variable table row|AMBIENT_ANIM_FREQ_OVERRIDE| int| 0| Overrides AMBIENT_ANIM_FREQ if non-zero.}}
{{Variable table row|AMBIENT_ANIM_STATE | int |0| Internal use by ambient behaviour system. Tracks number of animations left to play.}}
{{Variable table row|AMBIENT_MOVE_COUNT | int |-1| Internal use by ambient behaviour system. Tracks total number of destination points for a creature.}}
{{Variable table row|AMBIENT_MOVE_STATE | int |0| Internal use by ambient behaviour system. Tracks the last waypoint creature moved to and direction of travel.}}
{{Variable table row|AMBIENT_TICK_COUNT | int |0| Used internally, do not modify}}
{{Variable table row|AMBIENT_ANIM_OVERRIDE_COUNT|int|0|}}
{{Variable table end}}

== ambient_ai.xls ==
The actions used in an animation phase are listed in the ambient_anim_patterns worksheet of [[ambient_ai.xls]]. Each row defines an animation pattern, consisting of up to thirteen actions. Each action is composed of an animation (left of the decimal) and the number of loops it is played (right of decimal). For example, 619.02 will play a sleeping loop animation twice and 619.99 will play an infinitely looping sleeping animation. Non-looping animations require no loop-count (i.e. decimal) component. The list of all available animations is located in [[ANIM_base.xls]].

== sys_ambient_h ==

The script [[sys_ambient_h]] contains the implementation of the ambient behaviour system. The AMBIENT_* local variables should never be directly modified at run-time. Instead, use the following functions to customize a creature's ambient behaviour through script.

<dascript>
// Normally this function is called automatically to begin or resume ambient behaviour when a
// creature perceives the player. However, it can be called explicitly to force a creature to begin
// performing ambient behaviour or, if nAmbientEnable is 1, to enable ambient behaviour on a creature.
void Ambient_Start(object oCreature = OBJECT_SELF, int nAmbientEnable = 0, int nMovePattern = 0, string sMovePrefix = "");

// Normally this function is called automatically to pause ambient behaviour after the party has
// been out of the creature's sight for a while. However, this function can be used to force a
// creature to temporarily cease ambient behaviour. Note that the creature will automatically
// resume ambient behaviour when it perceives the player again.
void Ambient_Pause(object oCreature = OBJECT_SELF, int bCheckVisibility = TRUE);

// Turns off ambient behaviour on a creature. The creature will resume ambient behaviour only
// after Ambient_Start() is called.
void Ambient_Stop(object oCreature = OBJECT_SELF);

// Overrides the ambient animation pattern and animation frequency defined by the creature's template.
void Ambient_OverrideBehaviour(object oCreature, int nAnimPattern, float fAnimFreq);

// Restores a creature's ambient animation behaviour to that defined in the creature's template.
void Ambient_RestoreBehaviour(object oCreature);
</dascript>

== Overriding Ambient Behaviour ==

{{Variable table start}}
{{Variable table row|AMBIENT_ANIM_PATTERN_OVERRIDE | int | 0 | Index into [[ambient_ai.xls]]. Specifies the list of possible actions the creature can/will perform during an animation phase.
* 0: no animations.}}
{{Variable table row| AMBIENT_ANIM_FREQ_OVERRIDE | float | -1.0 | Animation frequency. The portion left of decimal specifies the minimum and the portion right of the decimal specifies the maximum number of animations to play during an animation phase. A value of -1.0 plays all animations in the animation pattern in the order listed in [[ambient_ai.xls]].}}
{{Variable table row| AMBIENT_ANIM_OVERRIDE_COUNT | int | | Used internally, do not modify}}
{{Variable table end}}

[[Category:Ambient behavior]]

CreateObject

2009-11-20T07:25:59Z

Axe Murderer: /* Remarks */ grammar

{{dafunction
|name=CreateObject
|brief=Create an object in the specified location. Will attempt to use a corresponding pool if one exists.
|param1type=int
|param1name=nObjectType
|param1desc=The object type (placeable, creature, etc)
|param1default=
|param2type=resource
|param2name=rTemplate
|param2desc=The template to use
|param2default=
|param3type=location
|param3name=lLoc
|param3desc=Location of the object
|param3default=
|param4type=string
|param4name=sOverrideScript
|param4desc=Script assigned to the object. If empty, the engine will use the template script
|param4default=""
|param5type=int
|param5name=bSpawnActive
|param5desc=Whether or not this object is enabled at spawn time
|param5default=TRUE
|param6type=int
|param6name=bNoPermDeath
|param6desc=Set to TRUE to avoid destroying the object permanently (only valid for pool creatures)
|param6default=FALSE
|returntype=object
|returndesc=The new object, OBJECT_INVALID on failure
|sourcefile=script.ldf
|sourcemodule=
}}




== Remarks ==


Note that dynamic creation of objects in the engine is subject to a host of limitations, reason being attempts to cut down 'unaccounted' memory usage.

Avoid using CreateObject whenever possible.

These objects can be created with CreateObject: 
- Creature 
- Placeable 

These objects can not be created with CreateObject: 
- Merchant (Store) 

The function appears to assume that the lLoc parameter represents a valid safe location. If it is valid but not safe, it will be adjusted to the nearest safe location and the object will be created there instead. This is not completely confirmed, but it is clear that placeables cannot be created above the ground level in the air (z-coordinate gets adjusted). However, using SetPosition after creating the object allows you to immediately move the object to an unsafe location if that is desired (see the custom function called CreateObjectIn3DSpace provided in the example below).

== Examples ==

<dascript>void main()
{
// get a location from a waypoint with a unique tag
object oWaypoint = GetObjectByTag("wp_werewolf_spawn");
location lWaypoint = GetLocation(oWaypoint);

// create a werewolf object at the location
object oWerewolf = CreateObject(OBJECT_TYPE_CREATURE, R"werewolf_core.utc", lWaypoint);
}</dascript>

<dascript>// CreateObjectIn3DSpace - Creates a new object allowing for
// locations that are valid but unsafe.
//
// Same as CreateObject except the lLoc parameter is not adjusted to
// the nearest safe location allowing for creation of objects anywhere
// in the area including up in the air and below ground.
//
object CreateObjectIn3DSpace( int nObjectType, resource rTemplate,
location lLoc, string sOverrideScript = "",
int bSpawnActive = TRUE, int bNoPermDeath = FALSE );

object CreateObjectIn3DSpace( int nObjectType, resource rTemplate,
location lLoc, string sOverrideScript = "",
int bSpawnActive = TRUE, int bNoPermDeath = FALSE )
{
// Create the object using CreateObject.
object oNewObject = CreateObject( nObjectType, rTemplate, lLoc, sOverrideScript, bSpawnActive, bNoPermDeath );
if( !IsObjectValid( oNewObject ) ) return OBJECT_INVALID;

// Move the object to absolute location in 3D space even if it is
// unsafe, then return the new object.
SetPosition( oNewObject, GetPositionFromLocation( lLoc ), FALSE );
return oNewObject;
}</dascript>

== See also ==

[[CreatePool]], [[DestroyObject]], [[OBJECT_TYPE*]]
[[Category: Object functions]]

CreateObject

2009-11-20T07:24:22Z

Axe Murderer: /* Remarks */ clarified Merchant means Store (OBJECT_TYPE_STORE) here.

{{dafunction
|name=CreateObject
|brief=Create an object in the specified location. Will attempt to use a corresponding pool if one exists.
|param1type=int
|param1name=nObjectType
|param1desc=The object type (placeable, creature, etc)
|param1default=
|param2type=resource
|param2name=rTemplate
|param2desc=The template to use
|param2default=
|param3type=location
|param3name=lLoc
|param3desc=Location of the object
|param3default=
|param4type=string
|param4name=sOverrideScript
|param4desc=Script assigned to the object. If empty, the engine will use the template script
|param4default=""
|param5type=int
|param5name=bSpawnActive
|param5desc=Whether or not this object is enabled at spawn time
|param5default=TRUE
|param6type=int
|param6name=bNoPermDeath
|param6desc=Set to TRUE to avoid destroying the object permanently (only valid for pool creatures)
|param6default=FALSE
|returntype=object
|returndesc=The new object, OBJECT_INVALID on failure
|sourcefile=script.ldf
|sourcemodule=
}}




== Remarks ==


Note that dynamic creation of objects in the engine is subject to a host of limitations, reason being attempts to cut down 'unaccounted' memory usage.

Avoid using CreateObject whenever possible.

These objects can be created with CreateObject: 
- Creature 
- Placeable 

These objects can not be created with CreateObject: 
- Merchant (Store) 

The function appears to assume that the lLoc parameter represents a valid safe location. If it is valid but not safe, it will be adjusted to the nearest safe location and the object will be created there instead. This is not completely confirmed, but it is clear that placeables cannot be created above the ground level in the air (z-coordinate gets adjusted). However, using SetPosition after creating the object allows you to immediately move the object to an unsafe location if that is desired (see the custom function provided in the example below).

== Examples ==

<dascript>void main()
{
// get a location from a waypoint with a unique tag
object oWaypoint = GetObjectByTag("wp_werewolf_spawn");
location lWaypoint = GetLocation(oWaypoint);

// create a werewolf object at the location
object oWerewolf = CreateObject(OBJECT_TYPE_CREATURE, R"werewolf_core.utc", lWaypoint);
}</dascript>

<dascript>// CreateObjectIn3DSpace - Creates a new object allowing for
// locations that are valid but unsafe.
//
// Same as CreateObject except the lLoc parameter is not adjusted to
// the nearest safe location allowing for creation of objects anywhere
// in the area including up in the air and below ground.
//
object CreateObjectIn3DSpace( int nObjectType, resource rTemplate,
location lLoc, string sOverrideScript = "",
int bSpawnActive = TRUE, int bNoPermDeath = FALSE );

object CreateObjectIn3DSpace( int nObjectType, resource rTemplate,
location lLoc, string sOverrideScript = "",
int bSpawnActive = TRUE, int bNoPermDeath = FALSE )
{
// Create the object using CreateObject.
object oNewObject = CreateObject( nObjectType, rTemplate, lLoc, sOverrideScript, bSpawnActive, bNoPermDeath );
if( !IsObjectValid( oNewObject ) ) return OBJECT_INVALID;

// Move the object to absolute location in 3D space even if it is
// unsafe, then return the new object.
SetPosition( oNewObject, GetPositionFromLocation( lLoc ), FALSE );
return oNewObject;
}</dascript>

== See also ==

[[CreatePool]], [[DestroyObject]], [[OBJECT_TYPE*]]
[[Category: Object functions]]

CreateObject

2009-11-20T07:21:14Z

Axe Murderer: /* Examples */ added custom function showing how to make a wrapper to create new objects at absolute locations in 3D space.

{{dafunction
|name=CreateObject
|brief=Create an object in the specified location. Will attempt to use a corresponding pool if one exists.
|param1type=int
|param1name=nObjectType
|param1desc=The object type (placeable, creature, etc)
|param1default=
|param2type=resource
|param2name=rTemplate
|param2desc=The template to use
|param2default=
|param3type=location
|param3name=lLoc
|param3desc=Location of the object
|param3default=
|param4type=string
|param4name=sOverrideScript
|param4desc=Script assigned to the object. If empty, the engine will use the template script
|param4default=""
|param5type=int
|param5name=bSpawnActive
|param5desc=Whether or not this object is enabled at spawn time
|param5default=TRUE
|param6type=int
|param6name=bNoPermDeath
|param6desc=Set to TRUE to avoid destroying the object permanently (only valid for pool creatures)
|param6default=FALSE
|returntype=object
|returndesc=The new object, OBJECT_INVALID on failure
|sourcefile=script.ldf
|sourcemodule=
}}




== Remarks ==


Note that dynamic creation of objects in the engine is subject to a host of limitations, reason being attempts to cut down 'unaccounted' memory usage.

Avoid using CreateObject whenever possible.

These objects can be created with CreateObject: 
- Creature 
- Placeable 

These objects can not be created with CreateObject: 
- Merchant 

The function appears to assume that the lLoc parameter represents a valid safe location. If it is valid but not safe, it will be adjusted to the nearest safe location and the object will be created there instead. This is not completely confirmed, but it is clear that placeables cannot be created above the ground level in the air (z-coordinate gets adjusted). However, using SetPosition after creating the object allows you to immediately move the object to an unsafe location if that is desired (see the custom function provided in the example below).

== Examples ==

<dascript>void main()
{
// get a location from a waypoint with a unique tag
object oWaypoint = GetObjectByTag("wp_werewolf_spawn");
location lWaypoint = GetLocation(oWaypoint);

// create a werewolf object at the location
object oWerewolf = CreateObject(OBJECT_TYPE_CREATURE, R"werewolf_core.utc", lWaypoint);
}</dascript>

<dascript>// CreateObjectIn3DSpace - Creates a new object allowing for
// locations that are valid but unsafe.
//
// Same as CreateObject except the lLoc parameter is not adjusted to
// the nearest safe location allowing for creation of objects anywhere
// in the area including up in the air and below ground.
//
object CreateObjectIn3DSpace( int nObjectType, resource rTemplate,
location lLoc, string sOverrideScript = "",
int bSpawnActive = TRUE, int bNoPermDeath = FALSE );

object CreateObjectIn3DSpace( int nObjectType, resource rTemplate,
location lLoc, string sOverrideScript = "",
int bSpawnActive = TRUE, int bNoPermDeath = FALSE )
{
// Create the object using CreateObject.
object oNewObject = CreateObject( nObjectType, rTemplate, lLoc, sOverrideScript, bSpawnActive, bNoPermDeath );
if( !IsObjectValid( oNewObject ) ) return OBJECT_INVALID;

// Move the object to absolute location in 3D space even if it is
// unsafe, then return the new object.
SetPosition( oNewObject, GetPositionFromLocation( lLoc ), FALSE );
return oNewObject;
}</dascript>

== See also ==

[[CreatePool]], [[DestroyObject]], [[OBJECT_TYPE*]]
[[Category: Object functions]]

CreateObject

2009-11-20T07:09:09Z

Axe Murderer: /* Remarks */ added paragraph concerning the function's behavior in regards to its handling of the location parameter provided to it. Needs further testing, clarification, and verification.

{{dafunction
|name=CreateObject
|brief=Create an object in the specified location. Will attempt to use a corresponding pool if one exists.
|param1type=int
|param1name=nObjectType
|param1desc=The object type (placeable, creature, etc)
|param1default=
|param2type=resource
|param2name=rTemplate
|param2desc=The template to use
|param2default=
|param3type=location
|param3name=lLoc
|param3desc=Location of the object
|param3default=
|param4type=string
|param4name=sOverrideScript
|param4desc=Script assigned to the object. If empty, the engine will use the template script
|param4default=""
|param5type=int
|param5name=bSpawnActive
|param5desc=Whether or not this object is enabled at spawn time
|param5default=TRUE
|param6type=int
|param6name=bNoPermDeath
|param6desc=Set to TRUE to avoid destroying the object permanently (only valid for pool creatures)
|param6default=FALSE
|returntype=object
|returndesc=The new object, OBJECT_INVALID on failure
|sourcefile=script.ldf
|sourcemodule=
}}




== Remarks ==


Note that dynamic creation of objects in the engine is subject to a host of limitations, reason being attempts to cut down 'unaccounted' memory usage.

Avoid using CreateObject whenever possible.

These objects can be created with CreateObject: 
- Creature 
- Placeable 

These objects can not be created with CreateObject: 
- Merchant 

The function appears to assume that the lLoc parameter represents a valid safe location. If it is valid but not safe, it will be adjusted to the nearest safe location and the object will be created there instead. This is not completely confirmed, but it is clear that placeables cannot be created above the ground level in the air (z-coordinate gets adjusted). However, using SetPosition after creating the object allows you to immediately move the object to an unsafe location if that is desired (see the custom function provided in the example below).

== Examples ==

<dascript>void main()
{
// get a location from a waypoint with a unique tag
object oWaypoint = GetObjectByTag("wp_werewolf_spawn");
location lWaypoint = GetLocation(oWaypoint);

// create a werewolf object at the location
object oWerewolf = CreateObject(OBJECT_TYPE_CREATURE, R"werewolf_core.utc", lWaypoint);
}</dascript>

== See also ==

[[CreatePool]], [[DestroyObject]], [[OBJECT_TYPE*]]
[[Category: Object functions]]

Classes

2009-11-15T04:08:27Z

Axe Murderer: /* Character Creation Scripting */ grammar

''Work in progress''

=== Overview ===

Dragon Age: Origins is a strongly class based RPG featuring 3 distinct character classes with exclusive abilities and progressions.

=== Description ===

This page explains the technical implementation and role of character classes in Dragon Age: Origins and is aimed at people wishing to create new content, modifications or adventures using the Dragon Age ruleset.

The classes of the game are defined in '''[[CLA_base.xls]]'''.
The following is an excerpt of the game rules and systems relevant columns in the file and illustrates how data relating to character class is stored.

{| border="1" width="100%" style="font-size:xx-small"
|-
|'''ID'''||'''Label'''||'''BaseHealth'''||'''BaseManaStamina'''||'''DepletableProgression'''||'''StrAdjust'''||'''ConAdjust'''||'''WillAdjust'''||'''MagAdjust'''||'''CunAdjust'''||'''DexAdjust'''||'''BaseAttack'''||'''BaseDefense'''||'''DefensePerLevel'''||'''HealthPerLevel'''||'''LevelsPerAbility'''||'''LevelsPerSkill'''||'''DamagePerLevel'''
|-
|0||INVALID||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****||****|
|-
|1||Warrior||100||100||5||4||3||0||0||0||3||60||45||1||6||1||3||0.4
|-
|2||Wizard||85||115||6||0||0||4||5||1||0||50||40||1||4||1||3||0.1
|-
|3||Rogue||90||90||4||0||0||2||0||4||4||55||50||1||5||1||2||0.2
|-|
|}
For details on the meaning of each column, please refer to '''[[CLA_base.xls]]'''.

=== Character Creation Scripting ===

Dragon Age characters are 'blank' when the game starts, with all their [[Creature Properties]] initialized to default values.

The character generation scripts, through interaction with the Character Creation UIs, use the data in [[CLA_base.xls]] to construct the character based on the player's choices. They are also responsible for any modification to the character's base stats during the Levelup process.

Note that major party members will use the character creation scripts, hostile enemies use a speed optimized and abreviated algorithm to determine their attributes based on rank, AI package and level.

==== Scripts ====

The scripts that handle most of character creation and levelup are:

* sys_chargen - Entry point for all character creation based [[Event]]s that get routed into this file from module_core.nss.
* sys_chargen_h - Library containing most of the underlying logic for modifying [[Creature Properties]] based on the game rules.
* sys_chargen_engine - Include defining a few constants and containing some snippets of relevant engine code for reference.
* sys_autolevelup_h - File defining the logic used by Party Member NPCs to level up when they are hired. After that, they use normal levelup.
* sys_autoscale_h - Contains shared logic used for determining levelup condition and code for creature autoscaling.
* sys_rewards_h - File containing XP reward entry point and levelup checks.

[[Category: Scripts]]
[[Category: Character_generation]]

CreateObject

2009-11-15T03:15:24Z

Axe Murderer: /* Remarks */ grammar

2DA

2009-11-12T11:46:52Z

Axe Murderer: removed section for item xls files. items are already in the objects section.

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]]

ABI base.xls

2009-11-12T11:39:28Z

Axe Murderer: /* ability_effects worksheet */ moved line in table to a more appropriate row

This is the 2DA that integrates all talents and spells into the game. It sets their names, icons, prerequesites, and various standard details of how they function (animations, cooldown period, etc.).

When making abilities the best way to proceed is to copy the nearest analogous ability and then modify the specific columns you need to.

During Dragon Age's development this file was automatically updated from an internal database. End user builders can update it manually.

== ABI_Base worksheet ==

{{2da start|ABI_Base}}
{{2da column| label |string| Purely for readability, not accessed anywhere.}}
{{2da column| namestrref |int| String Ref ID of the name of the ability (put in Core Talk Table).}}
{{2da column| descstrref |int| String Ref ID of the description of the ability (put in Core Talk Table).}}
{{2da column| tooltipstrref |int| }}
{{2da column| strid_effect| int| String Ref ID of the buff/debuff description on mouse over (put in Core Talk Table).}}
{{2da column| icon|string| Name of the icon file, without extension.}}
{{2da column| abilitytype | int| See 2DA_Constants_H for what the numbers are. 1 - talent, 2 - spell, 3 - skill, 4 - item}}
{{2da column| abilitymode |int| }}
{{2da column| conditions |int| }}
{{2da column| condition_mode | int| }}
{{2da column| condition_group |int| This links abilities. Use the lowest integer of the group. Whenever one of these abilities is used it will turn off the other linked abilities. So it makes it so that multiple modal abilities can't be activated at once.}}
{{2da column| cost| float| How much Mana/Stamina an ability will cost.}}
{{2da column| costupkeep |float| How much from the max Mana/Stamina an ability takes away until it is deactivated (modal abilities only)}}
{{2da column| prereqability |int | The ID of a prereq ability.}}
{{2da column| prereqlevel | int| Minimum character level to pick it up.}}
{{2da column| prereqattribute | int | Which attribute is a prereq for the ability. See [[properties.xls]] for what this number maps to.}}
{{2da column| prereqattvalue | int | The value the specified attribute has to be greater than.}}
{{2da column| guitype | int | This is the category that the ability is grouped into. Things like, "Creation" and "Primal". See [[guitypes.xls]].}}
{{2da column| targettype | int | A bit operator which indicates which classes of targets the ability will affect. Check out the "_Control" tab of ABI_base.xls. Search for "Friendly Creature" and you'll get to the right values.}}
{{2da column| autotarget | int| If set to TRUE then it will automatically target a selected hostile or friendly creature. }}
{{2da column| range | int| Range 1 means melee, 2 close spell range, 3 long spell range. 4+ should be used only with care.}}
{{2da column| speed |int| This is the speed the ability is used at. 0 is instant, 1 is quick, 2 is slow, 3+ is too slow to be fun.}}
{{2da column| usetype |int | Whether the ability is a passive, toggle, or instant use. Check out the "_Control" tab of ABI_base.xls. Search for "ABILITY_USETYPE_".}}
{{2da column| spellscript |string| This is the script that is run when the ability is used. Includes the file extension ".ncs".}}
{{2da column| cooldown | float | The ability cooldown in seconds.}}
{{2da column| conjurevfx | int| This is the VFX that is played during the conjure stage of the ability. This is defined in [[VFX_base.xls]]. Best practices is to make one entry for each spell so that way the FX artists can make a unique VFX tweak to an ability easily.}}
{{2da column| blendtree | string| Set by animators for abilities that change the default animations of a PC or party member. E.g. when you use "Shield Wall" your idle becomes a defensive crouch using your shield prominently.}}
{{2da column| conjureanim | int | Which animation to play during the conjure sequence. A list of values is located at [[ANIM_base.xls]].}}
{{2da column| castanim | int | Which animation to play during the casting sequence. A list of values is located at [[ANIM_base.xls]].}}
{{2da column| projectile | int | This is the model name for projectiles. See [[PRJ_base.xls]] for the integers. 1 is a common one for arrow.}}
{{2da column| autocancel | int| Obsolete }}
{{2da column| autodraw |int| Whether using this ability will automatically draw your weapon.}}
{{2da column| threat_use|float| Obsolete}}
{{2da column| threat_impact|float| This is the amount of threat generated by each impact. May be obsolete.}}
{{2da column| aoe_type|int| 1 is a circle, 2 is a cone.}}
{{2da column| aoe_idx|int| Defined areas of effect. Located at [[VFX_base.xls]].}}
{{2da column| aoe_param1 |float| Either the radius of the circle or degree arc of the cone.}}
{{2da column| aoe_param2 |float| Obsolete}}
{{2da column| vfx_impact0| int| The VFX that is used at each impact. [[VFX_base.xls]]}}
{{2da column| vfx_impact1|int| This isn't used by the engine, but can be used as a constant in the scripts if you like.}}
{{2da column| flags |int|{{undocumented}} }}
{{2da column| showintactics| int| Set to 1 for abilities that PC or party members will want to use in the tactics system.}}
{{2da column| showinchargen |int| {{undocumented}} }}
{{2da column| passive_id |int| {{undocumented}} }}
{{2da column| crust_id | int| Obsolete}}
{{2da column| resistance |int | {{undocumented}} }}
{{2da column| damageinfo | int| {{undocumented}} }}
{{2da column| condition_appgroup|int|{{undocumented}} }}
{{2da column| ProcessWithEvent | int| If specified this ability does not use any of the normal ability functionality but instead fires and processes and event - meaning it even works when the game is paused. Use with care. }}
{{2da column| fatigue | float | {{undocumented}} }}
{{2da end}}

== ability_data worksheet ==

{{2da start|ability_data}}
{{2da column| Label | comment | {{undocumented}} }}
{{2da column| bHostileint | int | {{undocumented}} }}
{{2da column| effectImpact | int | {{undocumented}} }}
{{2da column| effectResisted| int | {{undocumented}} }}
{{2da column| effectDuration| float | positive: temporary. 0.0 instant. negative permanent }}
{{2da column| dmg_function | int | {{undocumented}} }}
{{2da column| dmg_param0 | float | {{undocumented}} }}
{{2da column| dmg_param1| int | {{undocumented}} }}
{{2da column| dmg_type| int |
*const int DAMAGE_TYPE_INVALID - 0;
*const int DAMAGE_TYPE_PHYSICAL - 1;
*const int DAMAGE_TYPE_FIRE - 2;
*const int DAMAGE_TYPE_COLD - 3;
*const int DAMAGE_TYPE_ELECTRICITY - 4;
*const int DAMAGE_TYPE_POISON - 5;
*const int DAMAGE_TYPE_LETHAL - 6;
*const int DAMAGE_TYPE_TBD - 7;}}
{{2da column| dmg_flags | int |
*const int DAMAGE_EFFECT_FLAG_NONE - 0x00000000 ;
*const int DAMAGE_EFFECT_FLAG_CRITICAL - 0x00000001; //critical hit
*const int DAMAGE_EFFECT_FLAG_DEATHBLOW - 0x00000002; //death blow
*const int DAMAGE_EFFECT_FLAG_UPDATE_GORE - 0x00000004; //update gore on attacker
*const int DAMAGE_EFFECT_FLAG_LEECH_50 - 0x00000008; //leech 50% health back to attacker
*const int DAMAGE_EFFECT_FLAG_LEECH_75 - 0x00000010; //leech 75% health back to attacker
*const int DAMAGE_EFFECT_FLAG_LEECH_100 - 0x00000020; //leech 100% health back to attacker
*const int DAMAGE_EFFECT_FLAG_LEECH_MANA - 0x00000040; // mana is leeched instead of health}}
{{2da end}}

== ability_effects worksheet ==

{{2da start|ability_effects}}
{{2da column| Label| string | {{undocumented}} }}
{{2da column| effect| int | {{undocumented}} }}
{{2da column| effect_label| comment | {{undocumented}} }}
{{2da column| effect_int1| int | {{undocumented}} }}
{{2da column| effect_int2| int | {{undocumented}} }}
{{2da column| effect_int3| int | {{undocumented}} }}
{{2da column| effect_float0| float | {{undocumented}} }}
{{2da column| effect_float1| float | {{undocumented}} }}
{{2da column| effect_object0 |int| 0 - don't set, 1 - set to OBJECT_SELF, 2 - set to caster}}
{{2da column| scaled_field |int| 0 - none, 1 - float0, 2 - float1}}
{{2da column| vfx| int | {{undocumented}} }}
{{2da column| resistance| int |
*const int PROPERTY_ATTRIBUTE_RESISTANCE_MENTAL - 32;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_AVOIDANCE - 31;
*const int PROPERTY_ATTRIBUTE_RESISTANCE_PHYSICAL - 33;}}
{{2da end}}

== passive_abilities worksheet ==

{{2da start|passive_abilities}}
{{2da column| Label | comment | }}
{{2da column| Prop1 |int| link to [[properties.xls]]}}
{{2da column| Modifier1|float| Modifier this applies onto the property}}
{{2da column| Prop2| int | }}
{{2da column| Modifier2| float | }}
{{2da column| Prop3| int | }}
{{2da column| Modifier3| float | }}
{{2da column| Comment| comment | Summary of the ability in human-readable form }}
{{2da end}}

[[Category:2DAs]]

2DA

2009-11-12T10:53:02Z

Axe Murderer: /* Items */

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

=== Items ===

*[[filename.xls]] - description.

== 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]]

2DA

2009-11-12T10:52:20Z

Axe Murderer: /* Items */

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

=== Items ===

*[[ ]] -

== 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]]

2DA

2009-11-12T10:51:42Z

Axe Murderer: added new empty subsection for item xls files.

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

=== Items ===

*[[]] -

== 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]]

GetEffectsFlags

2009-11-12T10:40:21Z

Axe Murderer: /* Description */ speeling

{{Generated with errors}}
{{dafunction
|name=GetEffectsFlags
|brief=Returns the effect flags on a given object.
|param1type=object
|param1name=oOwner
|param1desc=The object that contains effects
|returntype=int
|returndesc=
|sourcefile=script.ldf
|sourcemodule=
}}

== Description ==

Effects can set effect flags. This function returns
an integer that contains all the effect flags on an object
due to the effects it currently holds.










[[Category: Effect access functions]]

Placeable

2009-11-01T01:02:09Z

Axe Murderer: /* Locked Objects */ reorganized paragraphs

Interactive Objects are the objects placed in the designer toolset that the end-user can interact with. They are also known as placeable objects.

Designers place interactive objects in area using the Area Editor. Placeable and trigger templates must be created prior to being placed in an area. In the toolset, doors are considered to be just another form of placeables.

Interactive objects are placed in the Area Editor of the Designer toolest. They can be interacted with by the player in-game.

Like all objects, interactive objects receive only one [[event]]. Information encoded in this event can be used to determine if this is a default action or a secondary action (for example, determining whether the player is picking the placeable's lock or simply bashing it open).

== Locked Objects ==

Any interactive object can be locked (though generally it only makes sense to do so with containers and doors). If the character's lockpicking skill is higher than the lock, the lock is opened.

Interactive objects cannot be trapped in the manner that Neverwinter objects were trapped (i.e., no trapped chests or doors). Instead, a placeable object can be set as the trigger for an associated trap object; Dragon Age generally does this via floor plates that trigger when stepped on.

== Destroying Objects ==

All interactive objects need a destroyed animation. If a container is destroyed the contents of its inventory are transferred to a Bodybag. Some of the items may be destroyed (scripting determines the chance of this).

== Types of Interactive Objects ==

The function that a placeable performs when interacted with is defined by its appearance, as listed in [[Placeables.xls]].

=== Doors ===
Doors can be opened and closed by the player. They restrict access between portions of an area.
* Examples: Door, Cage Door, Secret door
* Default Action: When a character clicks on the door it opens with an animation.
* Secondary Action: The character attacks the door with his equipped weapon
* Doors are special and get [[Door|their own page]] describing additional details.
=== Trigger-Animating ===
These are items that a player clicks on to activate something elsewhere on a level. Usually this means a locked or secret door somewhere on the level, though sometimes it might summon a monster or sound the alarm for the entire level.
* Examples: Lever, gong, turning wheel.
* Default Action: When a character clicks on the object, it plays an animation and an effect. The effect can be a script, a sound, a spell or a combination.
* Secondary Action: The character attacks the object with his equipped weapon.
=== Container-Animating ===
These are common containers where a player can find treasure. These objects play a simple ‘open’ animation when left clicked.
* Examples: Chest, Armoire, Safe.
* Default Action: An open animation is played. The container’s inventory is shown on a GUI. If the container is locked, then the character’s lock picking skill is compared against the lock’s complexity.
* Secondary Action: The character attacks the container with his equipped weapon.
=== Container-Static ===
These are common containers where a player can find treasure. These containers have no ‘open’ animation.
* Examples: Bookshelf, bush (with material components), corpse.
* Default Action: The container’s inventory is shown on a GUI. Static containers cannot be locked.
* Secondary Action: The character attacks the container with his equipped weapon.
=== Cage ===
These are cages where animals or prisoners are kept. Players can release prisoners as an act of good will or simply to interrogate them for information. Animals can be released to act as temporary allies.
*Examples: Animal cage, gaol.
*Default Action: An open animation is played. If the cage is locked, then the character’s lock picking skill is compared against the lock’s complexity.
*Secondary Action: The character attacks the cage with his equipped weapon.
=== Informational ===
These are notes or signs that a player can click on to learn important information about the game. They range from simply location signs to notes giving information about a plot.
*Examples: Road sign, note on wall.
*Default Action: A GUI pops up displaying the text of the message.
*Secondary Action: Nothing happens.
=== Selectable Trap ===
These are traps that originate from visible (and thus selectable and destroyable) objects. They can also can be disarmed by disarming their floor trigger - i.e., sinking floor piece - (see Trap Triggers).
*Examples: Archer statue that fires arrows (after player steps on floor piece). Dragon statue that breathes fire(after player steps on floor piece).
*Default Action: Trap triggers, targeting the character that selected it.
*Secondary Action: The character attacks the trap with his equipped weapon.
=== Non-Selectable Trap ===
These are hidden traps that spring from the walls, floor or ceiling. These traps cannot be selected or destroyed directly BUT they can be disarmed by disarming their floor trigger - i.e., sinking floor piece - (see Trap Triggers).
*Examples: Pendulum blade, scything blade.
*Default Action: Cannot target trap.
*Secondary Action: Cannot target trap.
=== Trap Trigger ===
All traps need to be associated with a floor trigger. When a character walks over a floor trigger, the trap will activate. If two or more characters are selected, the one with the highest trap skill is the one that moves to disarm the trap.
*Examples: Sinking floor piece.
*Default Action: If the character has the ‘Traps’ skill, then he plays a ‘disarm’ animation and his skill is compared against the difficulty of the trap. Characters without the traps skill cannot select the trap trigger.
*Secondary Action: The character attacks the trigger with his equipped weapon. This triggers the trap.
=== Area Effect Item/Informational ===
These are objects that a character can attack, triggering an event that has an immediate effect on the battlefield. When a character attacks one of these objects, the object usually falls over and deals damage to any creature in its area of effect. If a player just left clicks on one of these objects, he will receive a text message.
*Examples: Weakened pillar (pillar collapses into rubble), old rotting tree (tree falls over), chandelier (rope is cut, chandelier smashes into floor and vanishes), marble statue (statue tips over), window (window smashes, leaving glass all over floor), boulder (rolls along preset path).
*Default Action: A GUI pops up displaying the text of a message.
*Secondary Action: The character attacks the trigger with his equipped weapon. If the player has the appropriate strength, then the item plays its ‘area effect damage’ animation.
=== Area Effect Item/Container ===
These These are objects that a character can attack, triggering an event that has an immediate effect on the battlefield. When a character attacks one of these objects, the object usually falls over and deals damage to any creature in its area of effect. If a player just left clicks on one of these objects, it will act as a container.
*Examples: Bag of flour (explodes into cloud of flour), wagon with barrels (wagon tips and barrels spill over floor), bookcase (bookcase tips over).
*Default Action: The container’s inventory is shown on a GUI.
*Secondary Action: The character attacks the trigger with his equipped weapon. If the player has the appropriate strength, then the item plays its ‘area effect damage’ animation.
=== Furniture ===
Characters can either sit down or lie down on these objects.
*Examples: Chair, couch, bed, bench.
*Default Action: The character either sits down or lies down on the furniture object. As soon as the player clicks to move, he will stand up.
*Secondary Action: The character attacks the object with his equipped weapon.
=== Puzzle ===
The player clicks and triggers an interactive dialog with the object
*Examples: any puzzle object.
*Default Action: Trigger dialog.
*Secondary Action: The character attacks the object with his equipped weapon.
=== Area Transition ===
These are visible or invisible objects used to transition between areas.
*Examples: Large Gate
*Default Action: Transition into destination area.
*Secondary Action: Nothing happens.

== How will designers assign appearances to interactive objects? ==
*This will be done through the Toolset appearance field. It refers placeables.2da
*Each placeable has a Type.
*Each TYPE corresponds to an Animation State Type (example, the AnimCnt_Door sheet in placeables.2da controls the door states). This controls the type of animations available to this object. There should be 10-15 types or so
**Death
**Damaged
**Normal State
**Others...
*Each Animation State Type refers to a list of animations in the Animations 2da ([[ANIM_Placeables.xls]])

== How will battle-field damage work? ==
*Interactive Objects will not have DECALS or BATTLE-SCARING.
*Interactive Objects will have a Damage state, in addition to the Death state that they all have. Example damage states:
**A chest might have a chunk of wood taken out of its front
**A cask of ale might start leaking ale

== Use Points ==
Objects will have use points to indicate where people using them stand. There will be multiple use points on an object.

Use points will need to be activated relative to what state they are in (i.e., an overturned pillar will have different action points than an upright pillar).

Use points may also need to be labeled and are activated relative to a players position. This seems likely how are doors will work. Since we decided that doors in Dragon Age will function like real-world doors, they will always open in the same direction every time. This means that the use point I use is NOT relative to the state, but instead to the position of the character. We might need use points labeled.

This system will probably also be used by creatures (a dragon might have Front-Claw Use Point, Tail Use Point et cetera)

== How Will Sitting and Sleeping Work? ==
* All things that can be sat on will need a consistent Height and Width
* All things that can be slept on will need a consistent Height and Width
* Animals will not be able to sit or sleep on anything
* Animation will create sit & sleep animations for Elves, Dwarves, Humans
* The player can’t sit — only ambient NPCs.

The current planned interactive object animation system should be able to handle the "sitting" and "lying down" of creatures.

== What happens if no animations exist for an action? ==
Example: E.g A creature uses an object for which there is no proper animation, like a Dog opens a chest.

The chest will still open but if no animations were created to show Dog opening the chest, none will play.

== Variables ==

For var_placeable:

{{variable table start}}
{{variable table row| PLC_AT_DEST_AREA_TAG | string |none| resource name of an area transition door's destination area}}
{{variable table row| PLC_AT_DEST_TAG | string |none| resource name of the waypoint within that area to send the PC to. }}
{{variable table row|PLC_AT_WORLD_MAP_ACTIVE_1 to 5 | string |none| resource name of pins on the world map that should be made active when the player uses this area transition to reach the world map. }}
{{variable table row|PLC_CODEX_FLAG | int | -1 | Flag within the CODEX_PLOT plot that is set when this placeable is examined. }}
{{variable table row|PLC_CODEX_PLOT | string |none| resource name of a plot containing a codex page that is given to the player when this placeable is examined. }}
{{variable table row|PLC_COUNTER_1 to 3 | int |0| generic counter variables }}
{{variable table row|PLC_DO_ONCE_A and B | int |0| flags for behaviors that happen only once }}
{{variable table row|PLC_FLIP_COVER_USE_COUNT | int |0| Flip cover has been removed from the default ruleset }}
{{variable table row|PLC_SPAWN_NON_INTERACTIVE | int |0| }}
{{variable table row|PLC_TRAP_* | || see [[Trap system]] }}
{{variable table row|TS_OVERRIDE_* | || See [[Treasure system]] }}
{{variable table row|TS_TREASURE_GENERATED | int || }}
{{variable table end}}

If you use the var_placeable_react 2da instead, the above variables are all included and the following are added:

{{variable table start}}
{{variable table row|PLC_REACT_DESTROY_SET_FLAG | int || When placeable is destroyed set this flag }}
{{variable table row|PLC_REACT_DESTROY_SET_PLOT | string || When placeable is destroyed set this plot}}
{{variable table row|PLC_REACT_INVENTORY_REMOVED_SET_FLAG | int || When the PC takes something from the placeable fire this flag}}
{{variable table row|PLC_REACT_INVENTORY_REMOVED_SET_PLOT | string || When the PC takes something from the placeable fire this plot}}
{{variable table row|PLC_REACT_OVERRIDE_USE_BEHAVIOR | int |0| Makes it so what's supposed to happen when you use the placeable doesn't happen (e.g. a door doesn't open)}}
{{variable table row|PLC_REACT_REPEAT | int | 1 | Whether or not the placeable reaction script will fire multiple times (default to TRUE)}}
{{variable table row|PLC_REACT_USE_SET_FLAG | int |0| When placeable is used fire this flag}}
{{variable table row|PLC_REACT_USE_SET_PLOT | string || When placeable is used fire this plot}}
{{variable table end}}

== Properties ==

{{inspector start}}
{{inspector section|General}}
{{inspector row|Appearance| Appearance type for the placeable }}
{{inspector row|Character| One or more placeables can be mapped to a single character. }}
{{inspector row|Comments| General information about this placeable. }}
{{inspector row|Conversation| Default conversation resource for this placeable. }}
{{inspector row|Group| The placeable's group as specified in groups.2da. Each group can be either hostile or non-hostile towards each other. }}
{{inspector row|Name| Name of the placeable as seen in the game. }}
{{inspector row|NameRequiresReTranslation| A true/false flag used during game development for localization work }}
{{inspector row|Plot| True/false, if true the placeable cannot be damaged or affected by any hostile effect. }}
{{inspector row|PopupText| !!Property description!! }}
{{inspector row|PopupTextRequiresReTranslation| A true/false flag used during game development for localization work }}
{{inspector row|Rank| Placeables are never involved in combat, but their combat rank is still used by the [[treasure system]] when generating treasure. }}
{{inspector row|Resource Name| A unique string identifier the tooleset and the game both use to refer to this resource. }}
{{inspector row|Script| Event script assigned to the resource. }}
{{inspector row|Tag| A non-unique string identifier used mostly by scripts and other resources to refer to this resource. }}
{{inspector row|Team| Numeric identifier of the team the placeable belongs to. Team numbers are often used in scripting. }}
{{inspector row|Treasure Category| Determines what variety of treasure is generated by the [[treasure system]] }}
{{inspector row|Variable 2da| Allows selecting a variable table. Only the values in this table can be set and retrieved by scripting. }}
{{inspector row|Variables| Displays the table selected in the "Variable 2da" field. Allows setting initial states for parameters. }}

{{inspector section|Key}}
{{inspector row|Auto Remove Key| Sets whether the game will remove a key from inventory once used to open this placeable. }}
{{inspector row|Key Required| Sets whether or not a key is the only way to open this placeable }}
{{inspector row|Key Tag| The tag of the key needed to open this placeable }}

{{inspector section|Sound}}
{{inspector row|Close to Open Sound| Sound emitted when the object changes from a closed state to an opened state }}
{{inspector row|Destroyed Sound| Sound emitted when the object is destroyed }}
{{inspector row|Hit Sound| Sound emitted when the object is hit for damage }}
{{inspector row|Locked Sound| Sound emitted when an attempt is made to open a locked object }}
{{inspector row|Open to Close Sound| Sound emitted when the object changes from an opened to a closed state. }}
{{inspector row|Used Sound| Sound emitted when the object is "used" (generically). }}

{{inspector section|Stats}}
{{inspector row|Health| Amount of health the placeable currently has}}
{{inspector row|Initial State| The animation state the placeable will be in when first spawned. }}
{{inspector row|Interactive| Sets whether or not this placeable can be clicked on during the game. }}
{{inspector row|Inventory List| Opens the inventory panel and enables user to assign items to the placeable's inventory }}
{{inspector row|Max Health| The maximum amount of health this placeable can have.}}
{{inspector row|Pick Lock Level| The difficulty level to pick the lock }}

{{inspector section|Trap}}
{{inspector row|Is Trapped| Sets whether or not a trap trigger is linked to this placeable }}
{{inspector row|Trap Detection Difficulty| Sets the skill level required to detect this trap. }}
{{inspector row|Trap Disarm Difficulty| Sets the skill level required to disarm this trap. }}

{{inspector end}}

== See also ==

*[[Chanter's board]]

[[Category:Placeables]]

Talk:EVENT TYPE BLOCKED

2009-11-01T00:42:21Z

Axe Murderer: /* Sent When: */

== Sent When: ==

The wording here is a little ambiguous and I don't know enough about placeables and walkmeshes in DA to resolve it.

You could say it is implying that there can be placeables which do change the walkmesh & terrain and others that cannot. And this event is never sent when you bump into those that cannot. One is left to assume that it is always sent when you're blocked by those that can.

It can also be read to be saying that because all placeables cannot change the walkmesh and terrain, this event is never sent when you get blocked by any placeable for that reason.

If it is the latter, it should simply state it isn't sent when you bump placeables. Or, actually, take it out completely since you are really explaining, in the Sent When section, situations when you don't send it. And so it isn't all that relevant unless you plan to list along side it all the other situations when it also is not sent. Maybe it would be better to make this clarification in a Remarks section where it can be detailed better.

[[User:Axe Murderer|Axe Murderer]] 00:19, 1 November 2009 (UTC)

Talk:EVENT TYPE BLOCKED

2009-11-01T00:38:46Z

Axe Murderer:

== Sent When: ==

The wording here is a little ambiguous and I don't know enough about placeables and walkmeshes in DA to resolve it.

You could say it is implying that there can be placeables which do change the walkmesh & terrain and others that cannot. And this event is never sent when you bump into those that cannot. One is left to assume that it is always sent when you're blocked by those that can.

It can also be read to be saying that because all placeables cannot change the walkmesh and terrain, this event is never sent when you get blocked by any placeable for that reason.

If it is the latter, it should simply state it isn't sent when you bump placeables. Or, actually, take it out completely since you are really explaining, in the Sent When section, situations when you don't send it. And so it isn't all that relevant unless you plan to list all the other situations when it also is not sent along side it. Maybe it would be better to make this clarification in a Remarks section where it can be detailed better.

[[User:Axe Murderer|Axe Murderer]] 00:19, 1 November 2009 (UTC)

Talk:EVENT TYPE BLOCKED

2009-11-01T00:37:26Z

Axe Murderer: /* Sent When: */

== Sent When: ==

The wording here is a little ambiguous and I don't know enough about placeables and walkmeshes in DA to resolve it.

You could say it is implying that there can be placeables which do change the walkmesh & terrain and others that cannot. And this event is never sent when you bump into those that cannot. One is left to assume that it is always sent when you're blocked by those that can.

It can also be read to be saying that because all placeables cannot change the walkmesh and terrain, this event is never sent when you get blocked by any placeable for that reason.

If it is the latter, it should simply state it isn't sent when you bump placeables. Or, actually, take it out completely since you are really explaining, in the Sent When section, situations when you don't send it. And so it isn't all that relevant unless you plan to list all the other situations when it also is not sent. Maybe it would be better to make this clarification in one of the lower sections where it can be detailed better.

[[User:Axe Murderer|Axe Murderer]] 00:19, 1 November 2009 (UTC)

Talk:EVENT TYPE BLOCKED

2009-11-01T00:36:20Z

Axe Murderer: /* Sent When: */

== Sent When: ==

The wording here is a little ambiguous and I don't know enough about placeables and walkmeshes in DA to resolve it.

You could say it is implying that there can be placeables which do change the walkmesh & terrain and others that cannot. And this event is never sent when you bump into those that cannot. One is left to assume that it is always sent when you're blocked by those that can.

It can also be read to be saying that because all placeables cannot change the walkmesh and terrain, this event is never sent when you get blocked by any placeable for that reason.

If it is the latter, it should simply state it isn't sent when you bump placeables. Or, actually, take it out completely since you are really explaining, in the Sent When section, situations when you don't send it. And so it isn't all that relevant. Maybe it would be better to make this clarification in one of the lower sections where it can be detailed better.

[[User:Axe Murderer|Axe Murderer]] 00:19, 1 November 2009 (UTC)

EVENT TYPE BLOCKED

2009-11-01T00:31:42Z

Axe Murderer: spelling

{{event
|sourcefile=script.ldf
|when=The current creature's path has been blocked while moving by a creature or door. This event will NOT fire when blocked by placeables which cannot change the walk mesh or terrain.
|from=engine
|to=[[creature]]s
|tocategory1=creature
|sortkey=BLOCKED
|creatorname=oBlocker
|creatordesc=blocking object
}}

Also, this doesn't exist yet, but we'll need this event to fire for any time that the pathfinding failed.{{undocumented}}

Talk:EVENT TYPE BLOCKED

2009-11-01T00:30:15Z

Axe Murderer: /* Sent When: */

Talk:EVENT TYPE BLOCKED

2009-11-01T00:28:06Z

Axe Murderer: /* Sent When: */

Talk:EVENT TYPE BLOCKED

2009-11-01T00:27:46Z

Axe Murderer: /* Sent When: */

Talk:EVENT TYPE BLOCKED

2009-11-01T00:19:24Z

Axe Murderer: Sent When:

== Sent When: ==

The wording here seems to imply that there can be placeables which do change the walkmesh and terrain and others that cannot. And this event is never sent when you bump into those that cannot. One is left to assume that its always sent when you're blocked by those that can.

[[User:Axe Murderer|Axe Murderer]] 00:19, 1 November 2009 (UTC)

EVENT TYPE BLOCKED

2009-11-01T00:09:00Z

Axe Murderer: grammar

{{event
|sourcefile=script.ldf
|when=The current creature's path has been blocked while moving by a creature or door. This event will NOT fire when blocked by placeables which can not change the walk mesh or terrain.
|from=engine
|to=[[creature]]s
|tocategory1=creature
|sortkey=BLOCKED
|creatorname=oBlocker
|creatordesc=blocking object
}}

Also, this doesn't exist yet, but we'll need this event to fire for any time that the pathfinding failed.{{undocumented}}

Ability

2009-10-31T03:49:14Z

Axe Murderer: /* Q: How does Rank Based Mitigation Work ? */ formatting

=== Overview ===
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

=== Detailed Description ===

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

==== Basic Ability Types ====

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

==== Targeting Behavior ====

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| border="1"
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| border="1"
|-
|'''Bitmask''' || '''Effect'''
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| border="1"
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

==== Balancing (Cost, Cooldown, etc) ====

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

=== Q&A ===

==== Q: Where do we find the exact formula for abilities ? ====

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from [[ABI_base.xls]], a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

==== Q: What is Spellpower and how does it interact with abilities ====

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

==== Q: Can we have the damage formula for abilities ? ====

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

==== Q: What are the differences between damage types? ====

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

==== Q: Are sustained abilities mutually exclusive ? ====

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in [[ABI_base.xls]] that share the same 'condition_group' value are mutually exclusive.

==== Q: What are the rules for stacking effects and damage ? ====

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in [[effects.xls]].
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property ([[properties.xls]]). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some stat types there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

==== Q: How does game difficulty affect abilities ? ====

A: Our approach to game difficulty dictates that the effect of your chosen setting are

a) non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
b) challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
c) fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
d) non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

==== Q: What is spell affinity ? ====

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

==== Q: How does Rank Based Mitigation Work ? ====

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in [[creature_ranks.xls]] and [[difficulty.xls]].

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

[[Category:Scripts]]

==== Q: What does 'asymmetric rules system' mean ? ====

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

Ability

2009-10-31T03:05:19Z

Axe Murderer: /* Q: What are the rules for stacking effects and damage ? */ formatting

=== Overview ===
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

=== Detailed Description ===

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

==== Basic Ability Types ====

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

==== Targeting Behavior ====

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| border="1"
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| border="1"
|-
|'''Bitmask''' || '''Effect'''
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| border="1"
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

==== Balancing (Cost, Cooldown, etc) ====

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

=== Q&A ===

==== Q: Where do we find the exact formula for abilities ? ====

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from [[ABI_base.xls]], a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

==== Q: What is Spellpower and how does it interact with abilities ====

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

==== Q: Can we have the damage formula for abilities ? ====

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

==== Q: What are the differences between damage types? ====

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

==== Q: Are sustained abilities mutually exclusive ? ====

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in [[ABI_base.xls]] that share the same 'condition_group' value are mutually exclusive.

==== Q: What are the rules for stacking effects and damage ? ====

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in [[effects.xls]].
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property ([[properties.xls]]). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some stat types there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

==== Q: How does game difficulty affect abilities ? ====

A: Our approach to game difficulty dictates that the effect of your chosen setting are

a) non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
b) challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
c) fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
d) non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

==== Q: What is spell affinity ? ====

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

==== Q: How does Rank Based Mitigation Work ? ====

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in creature_ranks.xls and difficulty.xls.

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

[[Category:Scripts]]

==== Q: What does 'asymmetric rules system' mean ? ====

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

Ability

2009-10-31T02:37:03Z

Axe Murderer: /* Q: Are sustained abilities mutually exclusive ? */ formatting

=== Overview ===
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

=== Detailed Description ===

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

==== Basic Ability Types ====

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

==== Targeting Behavior ====

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| border="1"
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| border="1"
|-
|'''Bitmask''' || '''Effect'''
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| border="1"
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

==== Balancing (Cost, Cooldown, etc) ====

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

=== Q&A ===

==== Q: Where do we find the exact formula for abilities ? ====

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from [[ABI_base.xls]], a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

==== Q: What is Spellpower and how does it interact with abilities ====

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

==== Q: Can we have the damage formula for abilities ? ====

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

==== Q: What are the differences between damage types? ====

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

==== Q: Are sustained abilities mutually exclusive ? ====

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in [[ABI_base.xls]] that share the same 'condition_group' value are mutually exclusive.

==== Q: What are the rules for stacking effects and damage ? ====

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in effects.xls.
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property (properties.xls). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some type of stats there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

==== Q: How does game difficulty affect abilities ? ====

A: Our approach to game difficulty dictates that the effect of your chosen setting are

a) non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
b) challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
c) fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
d) non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

==== Q: What is spell affinity ? ====

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

==== Q: How does Rank Based Mitigation Work ? ====

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in creature_ranks.xls and difficulty.xls.

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

[[Category:Scripts]]

==== Q: What does 'asymmetric rules system' mean ? ====

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

Ability

2009-10-31T02:27:46Z

Axe Murderer: /* Q: Are sustained abilities mutually exclusive ? */ grammar

=== Overview ===
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

=== Detailed Description ===

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

==== Basic Ability Types ====

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

==== Targeting Behavior ====

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| border="1"
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| border="1"
|-
|'''Bitmask''' || '''Effect'''
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| border="1"
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

==== Balancing (Cost, Cooldown, etc) ====

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

=== Q&A ===

==== Q: Where do we find the exact formula for abilities ? ====

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from [[ABI_base.xls]], a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

==== Q: What is Spellpower and how does it interact with abilities ====

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

==== Q: Can we have the damage formula for abilities ? ====

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

==== Q: What are the differences between damage types? ====

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

==== Q: Are sustained abilities mutually exclusive ? ====

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in abi_base.xls that share the same 'condition_group' value are mutually exclusive.

==== Q: What are the rules for stacking effects and damage ? ====

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in effects.xls.
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property (properties.xls). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some type of stats there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

==== Q: How does game difficulty affect abilities ? ====

A: Our approach to game difficulty dictates that the effect of your chosen setting are

a) non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
b) challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
c) fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
d) non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

==== Q: What is spell affinity ? ====

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

==== Q: How does Rank Based Mitigation Work ? ====

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in creature_ranks.xls and difficulty.xls.

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

[[Category:Scripts]]

==== Q: What does 'asymmetric rules system' mean ? ====

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

Ability

2009-10-31T01:49:42Z

Axe Murderer: /* Q: Where do we find the exact formula for abilities ? */ formatting

=== Overview ===
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

=== Detailed Description ===

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

==== Basic Ability Types ====

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

==== Targeting Behavior ====

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| border="1"
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| border="1"
|-
|'''Bitmask''' || '''Effect'''
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| border="1"
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

==== Balancing (Cost, Cooldown, etc) ====

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

=== Q&A ===

==== Q: Where do we find the exact formula for abilities ? ====

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from [[ABI_base.xls]], a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

==== Q: What is Spellpower and how does it interact with abilities ====

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

==== Q: Can we have the damage formula for abilities ? ====

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

==== Q: What are the differences between damage types? ====

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

==== Q: Are sustained abilities mutually exclusive ? ====

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms are (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in abi_base.xls that share the same 'condition_group' value are mutually exclusive.

==== Q: What are the rules for stacking effects and damage ? ====

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in effects.xls.
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property (properties.xls). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some type of stats there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

==== Q: How does game difficulty affect abilities ? ====

A: Our approach to game difficulty dictates that the effect of your chosen setting are

a) non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
b) challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
c) fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
d) non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

==== Q: What is spell affinity ? ====

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

==== Q: How does Rank Based Mitigation Work ? ====

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in creature_ranks.xls and difficulty.xls.

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

[[Category:Scripts]]

==== Q: What does 'asymmetric rules system' mean ? ====

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

Ability

2009-10-31T01:36:39Z

Axe Murderer: /* Detailed Description */ grammar, formatting, punctuation

=== Overview ===
The Ability System is used to handle Spells, Talents, Skills, and Item Abilities in Dragon Age.

=== Detailed Description ===

Spells, Talents, Skills and item abilities all use the same backend in the game, a mostly script implemented system relying heavily on two dimensional data arrays.

The most important 2da file for abilities is '''[[ABI_base.xls]]''', as it defines each ability and all aspects of execution and handling in both scripting and engine code.

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Ability Design Notes'''

When creating an ability in Dragon Age: Origins, we generally stick to the following guidelines

* Keep it useful.
Some constant benefits (such as an increase in Attack or Defense) stay useful for the duration of the game as the progression of the related properties are slow.
For other effects, such as damage, a constant value would mean that the ability will become progressively worse through the game as damage needed to drop enemies increases from level to level. In such cases, the ability should be tied in some fashion to a Spellpower (for spells) or another relevant trait (such as cunning for rogues) to ensure they stay useful throughout the game.

* No repetition.
Each ability in Dragon Age: Origins is unique. No incremental abilities such as 'fireball I, fireball II, etc.'. Skills are exempt from this rule. Remember that the Damage Types dramatically alter the actual effect of an ability (such as lightning always draining stamina alongside doing damage), so having similar damaging abilities in different trees is usually fine.

* Thematic matching.
Abilities within the same chain should follow a common theme.

* Avoid binary abilities. Design hit heavy.
Avoid abilities that are hit-or-miss. Generally, abilities should hit whenever possible and use target side mitigation of effects (resistance checks, damage mitigation) instead of 'hit or miss' mechanics. Melee abilities may use the normal attack resolution routines but should always perform their attacks at a bonus. Use rank based mitigation and resistances to allow for very powerful effects that do not trivialize boss battles.

* Use meaningful effects
Abilities should always be worth it. Don't do minor effects (+1 attack). The player should always be able to see the effect of the ability in game (not necessarily visually, but at least through increased damage, etc.). The first ability in a chain should, whenever possible, be active. The fourth ability in a chain should always have the biggest 'bang-for-the-buck' factor. Abilities lower in the chain should have shorter cooldowns. Do not allow instant death on bosses and elite bosses.

* Avoid 'zero-sum' abilities
When possible, avoid 'zero-sum' abilities that trade a penalty for a benefit (e.g. increase defense but decrease attack). There are a number of these abilities that are valid (such as aim), but balancing them and keeping them useful is hard and requires a lot of work. This obviously does not apply to drastic abilities such as blood magic.

* No emulation of defining class capabilities
Never ever grant a basic class capability from one class to another class via abilities. This means no invisibility or magical unlock spells for mages, as these are defining capabilities of the rogue class. No weapon talents for mages. No magic spells or large, targeted area of effects for warriors or rogues. Items might blur this line if the cost is balanced properly (e.g. grenades).

|}

==== Basic Ability Types ====

Abilities are divided into 4 subtypes, as defined in the 'abilitytype' column in [[ABI_base.xls]]:

* Talents - Abilities used by warriors and rogues, usually non magical in nature. (abilitytype=1)
* Spells - Abilities used by mages, either spell or passive abilities. (abilitytype=2)
* Skills - Abilities usable by all classes, such as Survival and Combat training (abilitytype=3).
* Items - Abilities present on an item that are triggered when the item is used on the quickbar. (ability_type=4)

Note: Talents do not show up on mages and spells do not show up on rogue or warrior characters, so to create abilities that can be used by all classes, abilitytype 3 (Skill) must be used. To define under which heading an ability shows up on the character's talent/spell page, the field 'guitype' is used. It resolves against [[guitype.xls]] which lists all known headings.

There are 3 basic ability types in the game, defined by the field 'use_type' in [[ABI_base.xls]].

'''Passive Abilities'''

Passive abilities (use_type = 3) grant persistent or conditionally persistent bonuses or penalties to the creature that has the ability.

A passive ability may grant up to 3 modifications to creature properties ([[properties.xls]]). Those modifications are defined in the passive_abilities worksheet of [[ABI_base.xls]] and linked to the ability through the passive_id column in ABI_base.xls.

Additionally, the bonuses of an ability can be made conditional on the character's current 'wield mode' (2-handed, dual, weapon & shield, or universal) through the conditional integer field on the passive_abilities worksheet.

Finally, a number of passive abilities do not define any property modifications in passive_abilites but instead have checks coded against their Ids directly in the combat resolution scripts (e.g. HasAbility( oCreature, ABILITY_TALENT_LETHALITY )). The mere presence of the ability on a creature causes a different code path to be taken in the scripts in those cases.

Note that passive_ability benefits are not limited to abilities with use_type 3. Some active abilities also grant additional property modifying benefits to the owner.

'''Sustained Abilities'''

Sustained abilities (use_type = 2) are turned on and off per character and, while turned on, grant effects or property modifications to the user.
Most 'buffs' are implemented this way.

Only members of the player's party are using sustained ability as the code overhead required to track them is too expensive to be used on monsters that only exist to die in an encounter with the player's party. (These creatures use duration based effects to emulate similar abilities instead).

Most sustained abilities follow the same pattern:
* They do not have any activation cost, encouraging tactical use of buffs.
* They increase the users [[Fatigue]] property, therefore increasing the activation cost of all other abilities.
* They reduce the users maximum available mana or stamina by a constant value.
* They use cooldown to prevent the user from being too opportunistic with their use.
* Some abilities shut down when the user reaches 0 mana/stamina. Very powerful abilities (such as Momentum) have an associated stamina/mana drain effect to limit their use to a short or medium period of time. Creative item / buff use can be used to increase the length such an ability can be sustained.

The benefits from sustained abilities are calculated when the ability is activated. So if a character levels up or otherwise changes stats that influence the magnitude of a sustained ability, they will not update until the ability is reactivated the next time.

Some sustained abilities (such as Flaming Weapons) are active 'party-wide' - the caster not only sustains the ability on himself but on all his party members as well. This is controlled by the 'bPartyWide' flag in [[ABI_base.xls]]. Due to implementation limitations, party members who die or otherwise enter/exit the current party will not be affected by these abilities until they are recast. (we put low cooldown times on these abilities for that very reason).

{| style="margin:0; background:#f5faff; border:1px solid #a3b0bf; text-align:left; color:#000; padding:0.2em 0.4em; width:100%; height:100%"
|-
|'''Gameplay Design Note'''
* Unlike in games like Baldur's Gate, the system in DA: Origins is designed to encourage tactical use of buffs over strategical. We wanted to put an emphasis on the player making smart choices during an encounter vs. the player guessing which buffs might be useful ahead of time or having to employ save-die-reload to find out.

* It is generally wise to run only one or two buffs all around and activate additional buffs only when needed.
|}

'''Activated Abilities'''

Activated abilities (use_type = 4) are abilities that instantly execute their effect (see Targeting Behavior below). Most melee talents or targeted spells fall in this category. There are several sub-types of activated abilies, such as

* Targeted, single target spells and talents (such as Winter's Grasp or Flurry)
* Ground targeted abilities (such as Blizzard or various Glyphs)
* Self targeted activated abilities.

==== Targeting Behavior ====

An abilities targeting behavior is controlled by several settings in [[ABI_base.xls]]

'''AutoTarget''' is a boolean field that defines how the UI resolves targeting.

{| border="1"
|-
| 0 || The UI will always bring up a targeting cursor.
|-
| 1 || The UI will only produce a targeting cursor if no suitable target is currently selected. e.g if the player currently has a hostile creature targeted and if the spells TargetType includes 0x4 (hostile), the ability will trigger immediately, not producing a targeting cursor. Most single target spells and talents use this setting.
|}

Regardless of AutoTarget setting, the UI will never produce a targeting cursor if an ability is type 0x1 (self) -

'''TargetType''' is a bit mask derived from the following table and controls the behavior of the UI's targeting cursor.

{| border="1"
|-
|'''Bitmask''' || '''Effect'''
|-
| 0x1 || Self
|-
| 0x2 || Friendly Creature
|-
| 0x4 || Hostile Creature
|-
| 0x8 || Placeable Object
|-
| 0x10 || Area of Effect Object (deprecated)
|-
| 0x20 || Ground (see details)
|-
| 0x40 || Dead Body (deprecated)
|-
| 0x80 || Party Member
|}

'''AutoDraw''' is an integer boolean field that defines how a character's weapons are handled when the ability is triggered.

{| border="1"
|-
| 0 || The ability will not affect the player's weapon sheath status.
|-
| 1 || The engine will force the player to draw/unsheathe his weapon before executing the ability. This is used for most bow and melee weapon abilities.
|-
| 2 || The engine will force the player to stow away any non staff melee weapons before executing the ability. This is used to ensure that no inappropriate animations play with weapons drawn (e.g. the player conjuring with a sword clipping through his body) and to discourage switching between melee and spellcasting on the fly.
|}

==== Balancing (Cost, Cooldown, etc) ====

Abilities in Dragon Age are balanced along several vectors, most of which boil down to simple 'use frequency'. As a general rule of thumb, the more specialized and limited the effect of an ability is, the more outrageously powerful an ability can be.

Use frequency of abilities can be adjusted by modifying the following field in [[ABI_base.xls]]

* Cost: This is the simple mana (spells) or stamina (talents) activation cost of an ability. It is subtracted when the conjure phase of the spell has succesfully completed (e.g. no cost for spell interruptions). Without sufficient resources to cover activation cost, the UI will not allow the player to execute the ability. The value is a constant integer and is multiplied with 1+(Current Fatigue) of the caster.

* Cooldown: Cooldown is a constant float in seconds that defines how long the player has to wait after the successful activation of an ability until he can use it again. For abilities that apply duration based debuffs or effects to a target, cooldown is usually set slightly higher than the duration of the effect to avoid stacking by the same caster.

* Upkeep: Defines how much mana or stamina is removed from the casters overall pool while a sustained ability is active. This naturally limits the number of sustained abilities present on a creature and ensures that the more beneficial buffs are active on the caster, the less mana is available for immediate use.

* [[Fatigue]]: Fatigue affects use frequency only indirectly, but it prevents characters from stacking too many buffs on each other, as each sustained ability active usually adds around 5-10% fatigue to the caster.

* Mana/Stamina drain: By reducing the mana/stamina regeneration rate on a creature, the duration for which a sustained ability can be used can be restricted. This mechanic is used only for the most powerful sustained abilities in the game, which are flagged to turn off when the caster sustaining them reaches 0 mana/stamina.

Other balancing vectors:

* AoESize and AoeShape: Area of effect spells that deal friendly fire are location and situation restricted on normal+ difficulty (hard+ on the consoles). Since dropping an Inferno on your own party members is hardly a good idea in most cases, the usefulness of the spell becomes restricted to careful positioning and the earlier stages of combat.

* Threat Generation: Abilities apply threat not just by damage but often by activation. Higher activation threat of an ability can balance out outrageously powerful effects by making it harder for the player to use the spell. The prime example is the Walking Bomb kind of spells which deal excellent damage, but, on higher difficulties, also make the targets very very angry at the caster. Using these spells effectively often requires a tactical approach by the player, thus limiting their universal usefulness and offsetting their very powerful effects.

* Threat Removal: Some abilities are designed to only provide a short term benefit (Such as 3s stun on Mindblast) but offset their weakness by removing threat from the caster, often by reinitializing the threat tables on the target, causing enemies to randomly seek new targets.

* Conjure time: Spells with a conjure time of 1+ (Speed in [[ABI_base.xls]]) can be interrupted by damage, limiting their usefulness in melee situations or when only one party member remains on the battlefield. Many of the very powerful Area of Effect type spells use this feature. Most activated spells have a conjure time of 0, making them instant cast.

* Range: Lower ranges force the ability user into potentially more dangerous situations, adding additional risk to the use of an ability.

=== Q&A ===

==== Q: Where do we find the exact formula for abilities ? ====

A: Due to most abilities being unique, the only place to find the exact details on each spell is in the scripts. While a lot of data can be glanced from abi_base.xls, a lot of the detailed mechanics are very different between abilities and can only be found in the appropriate spellscript. The *_constant.nss files hold some basic values, but often get further modified in the scripts.

This is also one of the reasons why some elements of a talent are not displayed in the UI description in game. While we can calculate cost and cooldown based on the casting character and his fatigue and other properties (and consequently display it), we can usually not calculate damage or duration as they are mitigated on the target creature:

Displaying those values results in very misleading information (e.g. while damage seems to be higher on one ability, the mitigation mechanisms and unique side effects of another ability will make it just as good or better - in certain situations) and it turned out to be better to provide the player with general guidance than the misleading information.

==== Q: What is Spellpower and how does it interact with abilities ====

Spellpower is probably the most important stat for a mage character (and only exists on mage characters). It is calculated as max(Magic - 10,0) and therefore increases by one point for every point a mage spends on his Magic attribute.

Most mage spells benefit directly from higher spellpower by increased damage, effect magnitude and duration. It also plays a role in a mages ability to overcome mental or physical resistance on a target (where applicable). The actual impact of spellpower on an ability varies from spell to spell but the most common construct equates to something like 1% increase in spell potency per point of Spellpower. Thus, items and spells that increase spellpower are very powerful as they increase the potency of every spell the mage can cast.

Spellpower is the only factor that causes an increase of a spells potency over time, so a level 20 mage with neglected the Magic attribute would be much less powerful than a mage that didn't neglect Magic.

Some examples:

* The damage potential for Winter's Grasp is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.36f;
* The healing potential for the heal spell is calculated as (100.0f + GetCreatureSpellPower(stEvent.oCaster)) * 0.40f;
* The damage over time component of blizzard is executed as ApplyEffectDamageOverTime(a[i], oCreator, ABILITY_SPELL_BLIZZARD, (100.0f + GetCreatureSpellPower(oCreator)) * 0.1, (BLIZZARD_INTERVAL_DURATION - 0.5f), DAMAGE_TYPE_COLD);

Note that these formulas only list the raw damage potential and do not take into account the effects of damage types, difficulty, rank, resistances, magical shields and any other mitigating factors on the target or enhancing factors on the caster. This means that just comparing the numbers will not give you an idea which spell is better or worse.

For non-mage spells and abilities, spellpower is often substituted by an appropriate other construct (such as max(Cunning-10,0) for rogue abilities).

==== Q: Can we have the damage formula for abilities ? ====

A: There is no damage formula for abilities, as mentioned before, each ability follows their own rules.

In general, talent damage is based on the weapon being used (e.g. Assault does 3 melee attacks that deal weapon damage with some additional bonuses) and are modified by external cirumstances such as location, critical chance and ability to deliver a backstab and are mitigated by armor on the target.

Spells deal damage of different damage types following a rough rule of (Constant * (Spellpower / Variable)) / [Variables] ) + Modifiers but this only tells part of the story as actual damage is dependent on the target, it's resistances, rank and a number of other factors.

Some additional factors affecting spell damage are:

* damage resistance.
* magical shields.
* difficulty level.
* elemental damage bonuses from spells or items
* Environmental conditions (frozen targets take less damage from fire, etc.)

==== Q: What are the differences between damage types? ====

A: Creatures have variable damage resistances based on their type and rank. Dragons might get 60% less damage from fire (60% fire resistance), other creatures will have different immunities. Additional effects are:

* Electricity: In addition to normal damage, these also reduce the targets stamina (but not mana) by the same amount, making them very effective boss killers.

* Fire: Cancels Cold based damage over time effects and applies damage over time.

* Cold: Cancel Fire based damage over time effects and often is accompanied by slow or slipping effects.

* Spirit: There are very few ways of increasing spirit resistance in the game, so spells dealing spirit damage are universally useful...

* Nature: Rarely found on spells. Many creatures are resistant to this.

(This should probably go on its own wiki page)

==== Q: Are sustained abilities mutually exclusive ? ====

A: There is a very limited number of sustained abilities that are mutually exclusive, usually because it makes sense. Mutually exclusive abilities cancel each other upon activation.

* Shield stances (Shield Wall, Shield Cover, Shield Defense) are mutually exclusive.
* Archery stances (Aim, Rapid Fire, Defensive Fire) are mutually exclusive.
* Shapeshifting forms are (Sorry, no Bear-Wolfspider) are mutually exclusive.
* Weapon Enhancement spells are too, but only for the same caster (so two mages can run two different weapon enhancements if they want to).
* Bard Songs are mutually exclusive.
* The Death Syphon and Death Magic spells are mutually exclusive.

Technically, all abilities in abi_base.xls that share the same 'condition_group' value are mutually exclusive.

==== Q: What are the rules for stacking effects and damage ? ====

A: The general rules of stacking for abilities are:

* Identical effect from different abilities stack (e.g. getting +10 attack from one ability and +10 attack from another nets +20 attack).
* The effects of identical abilities stack as long as they are from different caster. (Same caster usually does not apply as cooldown often exceeds duration).
* Weapon enhancement spells of the same type (e.g. 2 mages with flame weapons) do not stack. The sword does not get more flaming, sorry :)
* Animation based effects (knockdown, stun, etc.) stack, but only the one with the highest priority is played. This is defined in the priority column in effects.xls.
* Glyphs do stack but there is a limit of 5 active glyphs per caster.
* Fire and Cold DoT effects do not stack, the spell cast last will cancel any existing spell of the opposite type.
* Fire and Cold AoEs cancel each other, other AoEs might interact rather violently, handle with care :)

For equipment and item based effects, the game usually stacks within the minumum and maximum clamp values of a property (properties.xls). This means that you can accumulate a lot of +damage or +critical critical chance effects, but for some type of stats there is a point where you are no longer gaining any benefits (e.g. speed modification - animations can only be sped up to a certain point before breaking, so stacking momentum, haste and a weapon with a speed based effect will not result in a -3.0s attack time, sorry :p)

For almost all effects, the total result of all property modifications on a creature are visible on the main character UI by hovering over the individual stats.

==== Q: How does game difficulty affect abilities ? ====

A: Our approach to game difficulty dictates that the effect of your chosen setting are

a) non punishing - You do not get less XP for chosing a lower difficulty mode, etc.
b) challenge scaling - Higher difficulty will reward you with greater obstacles to overcome.
c) fair - Lower difficulties grant benefits that gradually get removed. (This does not mean the rules are symmetric and is not true on nightmare at all. Nightmare is evil. And unfair.)
d) non persistent - Difficulty changes are possible on the fly, at any time and take immediate effect.

The game is balanced so that Hard mode is challenging for a Baldur's gate veteran.

Based on these guidelines, you can expect the following ability behaviors in game:

* The lower the difficulty, the longer your hostile effects such as stuns will last on enemies and the shorter they will last on you.
* The lower the difficulty, the more damage your abilities will do.
* The lower the difficulty, the less likely the enemy AI will use devastating special abilities (Note: less likely does not mean 'does not use').
* Casual and Normal have reduced friendly or nullified fire damage damage from area effect spells. Hard and Nightmare require careful positioning and tactical use of spells.
* The higher the difficulty, the more careful you need to manage threat when using spells and abilities (The AI becomes smarter about picking targets).

==== Q: What is spell affinity ? ====

A: Spell Affinity was a design we toyed with for a while during development but decided not to implement.

==== Q: How does Rank Based Mitigation Work ? ====

A: In line with Dragon Age: Origin's asymmetric approach to rules, the game uses creature ranks (instead of levels) in addition to stats and resistances to define how creatures get affected by abilities. In short: Boss monsters get affected differently by abilities and effects than Lieutenants or Critters.

The rank system is the primary balancing vector for the games difficulty levels and profoundly affects all aspects of combat. The gory details of this system are defined in creature_ranks.xls and difficulty.xls.

Rank mitigation affects not just damage in- and output of a creature, but also the duration that hostile effects persist on it and is different for each difficulty level of the game. Note that party members have their own rank in this system and are handled differently from other creatures in some cases.

Below is the formula used for rank based effect duration mitigation:

<dascript>
// sys_resistances_h
// @brief Returns an effect duration scaled by rank of oCreature and game difficulty
// @author Georg
float GetRankAdjustedEffectDuration(object oCreature, float fDur)
{

// -------------------------------------------------------------------------
// Georg: This deserves some explanation:
//
// One of the core issues when designing the combat system was always
// the fact that the story called for sequences during the game in which
// your main character acts solo.
//
// Characters reliant on special abilities, such as rogues, would require
// them to be very effective in order to beat enemies that a standard tank
// can plow through. However, if these abilities would maintain the same
// effectiveness in a full party, most encounters would turn into a stunfest.
//
// The solution is to add 1 second flat to each detrimental effect duration
// lasting at least 1 second for each unoccupied slot in the party - before applying
// rank and difficulty modifiers. This also makes solo play a bit more viable.
//
// This is in addition to the diminishing returns on quickly successive stuns.
//
// -------------------------------------------------------------------------
if (!IsPartyMember(oCreature))
{
float fPartySizeModifier = IntToFloat(Max(0,4 - GetArraySize(GetPartyList())));

if (fDur >= 1.0f)
{
fDur += fPartySizeModifier;
}
}

float fRankDurMod = Diff_GetDurationModifier(oCreature);
if (fRankDurMod >0.0f)
{
return (fDur * fRankDurMod);
}
else
{
return fDur;
}
}
</dascript>

[[Category:Scripts]]

==== Q: What does 'asymmetric rules system' mean ? ====

The goal behind Dragon Age: Origin's rule system was to create a fun and challenging video game experience first and foremost.

We describe the rules as 'asymmetric' because a subset of the game rules treats player controlled characters and monsters differently, which is a deviation from pen and paper rule design that often require player and opponents to be treated exactly the same.

Notable Examples:
* Party members never die permanently (get shattered, etc.)
* Differently ranked creatures (including party members) get affected for different durations by effects
* In limited situations in the game, we apply benefits to the player to overcome greater odds than they would usually be able to.
* Some abilities will work diferently when deployed against the party (although the visual results might be identical).
* Elimination of instant death situations (not fun!) against players but not against monsters (fun!).
* Sustained abilities only work for players (the overhead is not justified for monsters that won't ever reappear after they die).

Combat damage h.nss

2009-10-30T23:56:29Z

Axe Murderer: /* Combat_Damage_GetBackstabDamage */ grammar

=== Overview ===

combat_damage_h.nss handles the core rule resolution logic for non-spell damage.

=== Notable Functions ===

==== GetCriticalDamageModifier ====

Returns the multiplier for critical hit damage.

<dascript>
const float COMBAT_CRITICAL_DAMAGE_MODIFIER = 1.5f; // critical hits increase damage increase.

float GetCriticalDamageModifier(object oAttacker)
{
return COMBAT_CRITICAL_DAMAGE_MODIFIER + (GetCreatureProperty(oAttacker, 54 /*PROPERTY_ATTRIBUTE_CRITICAL_RANGE*/) / 100.0);
}
</dascript>

==== Combat_Damage_GetBackstabDamage ====

Determines the backstab damage given an attacker and attack damage. (weapon is passed in for future use)
Note: This function was slightly modified from the toolset version to remove some non-essential elements for clarity.

<dascript>
float Combat_Damage_GetBackstabDamage(object oAttacker, object oWeapon, float fDamage)
{
// ------------------------------------------------------------------------
// Each backstab does critical damage.
// ------------------------------------------------------------------------
fDamage *= GetCriticalDamageModifier(oAttacker);

// -------------------------------------------------------------------------
// Exploit Weakness: Backstab Damage + max(CUN-10,0) / 3.0
// -------------------------------------------------------------------------
if (HasAbility(oAttacker,ABILITY_TALENT_EXPLOIT_WEAKNESS))
{
float fBase = MaxF(0.0,(GetAttributeModifier(oAttacker,PROPERTY_ATTRIBUTE_CUNNING)/3.0)) ;
float fMod = MaxF(0.2,RandomFloat());
fDamage += (fBase * fMod);
}

return fDamage;
}
</dascript>

Combat Rules

2009-10-30T23:36:27Z

Axe Murderer: /* Flanking Bonus Determination */ grammar

'''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 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-10-30T23:29:49Z

Axe Murderer: /* Hit Resolution */ indentation

'''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 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 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-10-30T23:28:00Z

Axe Murderer: /* Hit Resolution */ indentation

'''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 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 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-10-30T23:27:11Z

Axe Murderer: /* Hit Resolution */ indentation

'''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 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 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-10-30T23:26:26Z

Axe Murderer: /* Hit Resolution */ spacing

'''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 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 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-10-30T23:22:59Z

Axe Murderer: /* Hit Resolution */ punctuation

'''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 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 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]]

Creature Properties

2009-10-30T22:35:45Z

Axe Murderer: /* Property Definitions */ grammar

=== 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 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 through 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.

Sound

2009-10-29T01:12:09Z

Axe Murderer: /* The object inspector */ spelling

Sounds are created and packaged using the [[FMOD]] tool. This is a third-party tool that is included with the Dragon Age toolset. See the [[FMOD]] page for documentation on how to use it to create sound resources for use in the designer toolkit.

The designer toolset is our way to get sounds into the game. In this application we can define the sound design for any particular area in the game. We have the ability to draw audio volumes to define certain areas, assign sounds to them and even modify and mix within the volume itself, in real time. We can drop emitters for our 3D sounds and modify them as well.

Voice over is handled separately by the toolset; see the relevant section of [[conversation]] for more details.

== Sounds in the area editor ==

Any sound that you create events for and build to the .fev/.fsb files is available for use in the [[area]] editor. The area editor will see these sounds and make them available when the editor is opened or when the “Refresh F5” option is selected from the menu. This way you can keep the editor open, go back to FMOD, edit, rebuild and then see your changes in the area editor.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m696ff502.png|frame|center|The refresh command in “View”]]

=== Where are they and how to get them ===

Sounds in the area editor are available in two places:

Sounds available to be used as 3D placeable emitters and 3D area effects can be accessed from the palette window under “Sounds”, located by the double eighth note icon.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4737e97a.png|frame|center|“Sounds” in the palette window.]]

Although all sounds in the FMOD project will be available here, we will only select the sounds used as emitters from this window. Sounds that we will assign to volumes will be accessed in another way.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m76633bf9.png|frame|center|Sounds used as emitters.]]

All of these sounds will be visible as they are in the event groups we have created in FMOD.

Sounds that we will assign to audio volumes are available in the object inspector window. When you click on an audio volume, the object inspector for that audio volume will come up allowing you to select sounds and assign them to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_3358dde5.png|frame|center|The audio volume selected in the area editor.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m239c4e80.png|frame|center|The object inspector for the audio volume.]]

In the object inspector we can name the audio volume, select a reverb for the volume and assign sounds to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_258f7e.png|frame|center|Name the volume.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2fd0e616.png|frame|center|Set the reverb preset.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_250eeee5.png|frame|center|Assign sounds to the volume.]]

To assign sounds to the volume, click on the “…” tab on the far right of the “Sounds” field. You will see a window called “Sound Instances” pop-up that will allow you to access sounds and assign them to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m14f66b49.png]]

Selecting the sound(s) you want to assign to the volume and clicking the “Add - >” button will transfer the sounds over to the next window.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7bd884d5.png]]

Likewise, the “Remove” or “Remove all” buttons will do just that, remove selected sounds or clear all sounds from the window.

When the sounds are in the window, you can audition them singly or all together and even edit their mix and other properties.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6bde288.png|frame|center|Sounds selected for audition or edit.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4dd5f697.png|frame|center|The object inspector for the sounds assigned to a volume.]]

Once selected and assigned to a volume, these sounds will now play in game in the area defined by the volume, based on their individual playback parameters.

== The object inspector ==

The object inspector is a facility offered by the DA designer toolset with which to perform several processes to the sounds we have applied to any given level. We have the ability to modify the audio events that we have created as well as modify other parameters such as the active/inactive status of an emitter, adjust the position of an object, change the 3D cone of an emitter, as well as adjust the max range of the radius of an emitter. These modifiers are also supported by the ability to adjust the occludability, pitch, priority and volume of any given object. These functions will be explained in two ways: 1. how the object inspector allows modification to an audio volume and: 2. how the object inspector allows modification to an emitter.

=== Use and utility ===

==== The object inspector and audio volumes ====

When you select an audio volume in the area editor, the object inspector shows several fields that will allow us to perform several actions directly related to that audio volume. These fields are:

1. Name- here we can name the volume, usually calling it what it is on the map or some name that describes its function is a good way to name these objects. For example: “Hallway 1, or Tower Courtyard Lower 1”. Note that there are numbers at the end of the name, you may have volumes that are the same name but are used multiple times, e.g. Alcove 1, 2, 3, 4… and so on, etc. Using a number after each volume, even if it is the only one on the map is an easy way to keep track of what and where things are.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_20762b04.png]]

2. Reverb Preset- in this field we can assign a reverb to the volume. Any reverb preset that is in the master_reverb FMOD project is available to use in your volumes.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2d41b5bb.png]]

3. Sounds- sounds can be assigned to audio volumes in this field. When you click to the right of the sounds field a menu called “Sound Instances” will open and you will be able to select sound events from the FMOD project for the level you are working on and assign them to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4927b95a.png]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6325a6cf.png|frame|center|Sounds assigned to a volume.]]

4. Position- this field describes the position of the volume on the map, with values representing points in 3D space including height, which is the last value.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m70cedfbe.png|frame|center|The height of the volume, in meters.]]

All of the numerical values relating to position are copy/pasteable from one object inspector to the other, which is useful when copying a volume from one map to another, for reuse.

5. Sound Instances- this window allows us to select and assign sound events to audio volumes, in addition, we can also perform some editing functions per sound event. When selecting a sound in the “Sound Instances” window the editing functions open up, as below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m467394a0.png|frame|center|Sound instance object inspector.]]

These functions enable greater control over each sound event assigned to the volume and we can effectively mix these sounds within each volume, as well as script instances within a volume.

==== The object inspector and emitters ====

When you select an emitter in the area editor, the object inspector shows several fields that will allow us to perform several actions directly related to that emitter. These fields are identical to the “Sound Instances” object inspector functions discussed in the previous entry.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m143509d9.png|frame|center|The emitter object inspector.]]

Within this window we have the ability to modify other parameters such as the active/inactive status of an emitter, adjust the position of the emitter, change the 3D cone of the emitter, as well as adjust the max range of the radius of an emitter, volume, pitch and priority. All of these values can be copied and pasted as well as manipulated instance to instance.

== Volumes and emitters. ==

We can use volumes for two purposes when designing the sound for an area in DA. The first is to use an audio volume to define an area in which you want to play certain sounds as 4.0 ambiences. For example: the borders of a town, or the path of a river, a room in a castle or an outdoor area. All of these instances can use volumes to define the ambient audio we will here when we are in that space in the game. Audio volumes are used in conjunction with emitters to fulfill the 4.0 and 3D directional aspects of all sounds used as ambiences in the game.

=== Audio volumes ===

Audio volumes are used to define an area for 4.0 ambiences to be assigned to. In the area editor, simply right clicking anywhere in the map will allow you to begin to draw an audio volume, as shown below..

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6f0fdea3.png|frame|center|Right click on the map.]]

You will then see a crosshairs with which you can point and click to draw virtually any complex shape necessary to define the area you need. You draw these shapes by dropping vertices which then can be moved as a group or independently, in 3 dimensions.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7bf496c3.png|frame|center|Draw the shape desired.]]

As stated we use these volumes and the shapes we draw to define the 4.0 audio for any given area. These volumes show up in the menu on the right hand side of the area editor. It is here that you can select them to edit their properties and parameters in the object inspector.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_69cbabfe.png|frame|center|Placed audio volumes in the menu.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m5099ccff.png|frame|center|Portion of map defined by volumes.]]

=== Reverb volumes ===

Reverb volumes share may of the same properties as audio volumes except they are designed to define an area for a certain reverb. Since we can assign reverbs to audio volumes, the reverb volumes are usually used to draw small volumes to place emitters in order for them to be in a separate reverb from the rest of the area. We can currently have 3 reverbs per area.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m44f5abfb.png|frame|center|Reverb volume with emitters placed inside. ]]

These volumes show up in the menu on the right hand side of the area editor. It is here that you can select them to edit their properties and parameters in the object inspector.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4fa514c0.png|frame|center|Placed reverb volumes in the menu.]]

=== Emitter properties and utility. ===

Emitters are used in the area editor to perform several functions, they can be placed to provide the sound for a 3D placeable object, like a fire, flag or waterfall:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m487b9558.png|frame|center|Emitter placed as a 3D placeable object.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4084754f.png|thumb|center|600px|The FMOD event for this instance.]]

They can be used to define a 3D area effect over an entire area of the map:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_484de945.png|frame|center|Emitter providing a 3D area effect.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_60d10943.png|thumb|center|600px|The FMOD event for this instance.]]

And finally, they can be used as point source 3D ambience over a selected area of the map.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7d17ec99.png|frame|center|Emitter used as point source ambience.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6daf1077.png|thumb|600px|center|The FMOD event for this instance.]]

To place an emitter, the sounds can be accessed in the “Sounds” palette window to the right of the area editor.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4737e97a.png|frame|center|“Sounds” selected in the palette window.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_7fa321e0.png|frame|center|Selecting a sound.]]

Upon selection of a sound, you will be given a crosshair and you can drop the sound anywhere on the map. You can then adjust its position in 3 dimensions as you see fit.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_bdda402.png|frame|center|Placed sounds in the menu.]]

Sounds used as emitters show up in the menu on the right hand side of the area editor. It is here that you can select them to edit their properties and parameters in the object inspector.

[[Category:Sounds]]

Sound

2009-10-29T01:05:55Z

Axe Murderer: /* Where are they and how to get them */ speeling

Sounds are created and packaged using the [[FMOD]] tool. This is a third-party tool that is included with the Dragon Age toolset. See the [[FMOD]] page for documentation on how to use it to create sound resources for use in the designer toolkit.

The designer toolset is our way to get sounds into the game. In this application we can define the sound design for any particular area in the game. We have the ability to draw audio volumes to define certain areas, assign sounds to them and even modify and mix within the volume itself, in real time. We can drop emitters for our 3D sounds and modify them as well.

Voice over is handled separately by the toolset; see the relevant section of [[conversation]] for more details.

== Sounds in the area editor ==

Any sound that you create events for and build to the .fev/.fsb files is available for use in the [[area]] editor. The area editor will see these sounds and make them available when the editor is opened or when the “Refresh F5” option is selected from the menu. This way you can keep the editor open, go back to FMOD, edit, rebuild and then see your changes in the area editor.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m696ff502.png|frame|center|The refresh command in “View”]]

=== Where are they and how to get them ===

Sounds in the area editor are available in two places:

Sounds available to be used as 3D placeable emitters and 3D area effects can be accessed from the palette window under “Sounds”, located by the double eighth note icon.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4737e97a.png|frame|center|“Sounds” in the palette window.]]

Although all sounds in the FMOD project will be available here, we will only select the sounds used as emitters from this window. Sounds that we will assign to volumes will be accessed in another way.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m76633bf9.png|frame|center|Sounds used as emitters.]]

All of these sounds will be visible as they are in the event groups we have created in FMOD.

Sounds that we will assign to audio volumes are available in the object inspector window. When you click on an audio volume, the object inspector for that audio volume will come up allowing you to select sounds and assign them to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_3358dde5.png|frame|center|The audio volume selected in the area editor.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m239c4e80.png|frame|center|The object inspector for the audio volume.]]

In the object inspector we can name the audio volume, select a reverb for the volume and assign sounds to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_258f7e.png|frame|center|Name the volume.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2fd0e616.png|frame|center|Set the reverb preset.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_250eeee5.png|frame|center|Assign sounds to the volume.]]

To assign sounds to the volume, click on the “…” tab on the far right of the “Sounds” field. You will see a window called “Sound Instances” pop-up that will allow you to access sounds and assign them to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m14f66b49.png]]

Selecting the sound(s) you want to assign to the volume and clicking the “Add - >” button will transfer the sounds over to the next window.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7bd884d5.png]]

Likewise, the “Remove” or “Remove all” buttons will do just that, remove selected sounds or clear all sounds from the window.

When the sounds are in the window, you can audition them singly or all together and even edit their mix and other properties.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6bde288.png|frame|center|Sounds selected for audition or edit.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4dd5f697.png|frame|center|The object inspector for the sounds assigned to a volume.]]

Once selected and assigned to a volume, these sounds will now play in game in the area defined by the volume, based on their individual playback parameters.

== The object inspector ==

The object inspector is a facility offered by the DA designer toolset with which to perform several processes to the sounds we have applied to any given level. We have the ability to modify the audio events that we have created as well as modify other parameters such as the active/inactive status of an emitter, adjust the position of an object, change the 3D cone of an emitter, as well as adjust the max range of the radius of an emitter. These modifiers are also supported by the ability to adjust the occludability, pitch, priority and volume of any given object. These functions will be explain in two ways: 1. how the object inspector allows modification to an audio volume and: 2. how the object inspector allows modification to an emitter.

=== Use and utility ===

==== The object inspector and audio volumes ====

When you select an audio volume in the area editor, the object inspector shows several fields that will allow us to perform several actions directly related to that audio volume. These fields are:

1. Name- here we can name the volume, usually calling it what it is on the map or some name that describes its function is a good way to name these objects. For example: “Hallway 1, or Tower Courtyard Lower 1”. Note that there are numbers at the end of the name, you may have volumes that are the same name but are used multiple times, e.g. Alcove 1, 2, 3, 4… and so on, etc. Using a number after each volume, even if it is the only one on the map is an easy way to keep track of what and where things are.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_20762b04.png]]

2. Reverb Preset- in this field we can assign a reverb to the volume. Any reverb preset that is in the master_reverb FMOD project is available to use in your volumes.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_2d41b5bb.png]]

3. Sounds- sounds can be assigned to audio volumes in this field. When you click to the right of the sounds field a menu called “Sound Instances” will open and you will be able to select sound events from the FMOD project for the level you are working on and assign them to the volume.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4927b95a.png]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6325a6cf.png|frame|center|Sounds assigned to a volume.]]

4. Position- this field describes the position of the volume on the map, with values representing points in 3D space including height, which is the last value.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m70cedfbe.png|frame|center|The height of the volume, in meters.]]

All of the numerical values relating to position are copy/pasteable from one object inspector to the other, which is useful when copying a volume from one map to another, for reuse.

5. Sound Instances- this window allows us to select and assign sound events to audio volumes, in addition, we can also perform some editing functions per sound event. When selecting a sound in the “Sound Instances” window the editing functions open up, as below:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m467394a0.png|frame|center|Sound instance object inspector.]]

These functions enable greater control over each sound event assigned to the volume and we can effectively mix these sounds within each volume, as well as script instances within a volume.

==== The object inspector and emitters ====

When you select an emitter in the area editor, the object inspector shows several fields that will allow us to perform several actions directly related to that emitter. These fields are identical to the “Sound Instances” object inspector functions discussed in the previous entry.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m143509d9.png|frame|center|The emitter object inspector.]]

Within this window we have the ability to modify other parameters such as the active/inactive status of an emitter, adjust the position of the emitter, change the 3D cone of the emitter, as well as adjust the max range of the radius of an emitter, volume, pitch and priority. All of these values can be copied and pasted as well as manipulated instance to instance.

== Volumes and emitters. ==

We can use volumes for two purposes when designing the sound for an area in DA. The first is to use an audio volume to define an area in which you want to play certain sounds as 4.0 ambiences. For example: the borders of a town, or the path of a river, a room in a castle or an outdoor area. All of these instances can use volumes to define the ambient audio we will here when we are in that space in the game. Audio volumes are used in conjunction with emitters to fulfill the 4.0 and 3D directional aspects of all sounds used as ambiences in the game.

=== Audio volumes ===

Audio volumes are used to define an area for 4.0 ambiences to be assigned to. In the area editor, simply right clicking anywhere in the map will allow you to begin to draw an audio volume, as shown below..

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6f0fdea3.png|frame|center|Right click on the map.]]

You will then see a crosshairs with which you can point and click to draw virtually any complex shape necessary to define the area you need. You draw these shapes by dropping vertices which then can be moved as a group or independently, in 3 dimensions.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7bf496c3.png|frame|center|Draw the shape desired.]]

As stated we use these volumes and the shapes we draw to define the 4.0 audio for any given area. These volumes show up in the menu on the right hand side of the area editor. It is here that you can select them to edit their properties and parameters in the object inspector.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_69cbabfe.png|frame|center|Placed audio volumes in the menu.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m5099ccff.png|frame|center|Portion of map defined by volumes.]]

=== Reverb volumes ===

Reverb volumes share may of the same properties as audio volumes except they are designed to define an area for a certain reverb. Since we can assign reverbs to audio volumes, the reverb volumes are usually used to draw small volumes to place emitters in order for them to be in a separate reverb from the rest of the area. We can currently have 3 reverbs per area.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m44f5abfb.png|frame|center|Reverb volume with emitters placed inside. ]]

These volumes show up in the menu on the right hand side of the area editor. It is here that you can select them to edit their properties and parameters in the object inspector.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4fa514c0.png|frame|center|Placed reverb volumes in the menu.]]

=== Emitter properties and utility. ===

Emitters are used in the area editor to perform several functions, they can be placed to provide the sound for a 3D placeable object, like a fire, flag or waterfall:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m487b9558.png|frame|center|Emitter placed as a 3D placeable object.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_4084754f.png|thumb|center|600px|The FMOD event for this instance.]]

They can be used to define a 3D area effect over an entire area of the map:

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_484de945.png|frame|center|Emitter providing a 3D area effect.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_60d10943.png|thumb|center|600px|The FMOD event for this instance.]]

And finally, they can be used as point source 3D ambience over a selected area of the map.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m7d17ec99.png|frame|center|Emitter used as point source ambience.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m6daf1077.png|thumb|600px|center|The FMOD event for this instance.]]

To place an emitter, the sounds can be accessed in the “Sounds” palette window to the right of the area editor.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_m4737e97a.png|frame|center|“Sounds” selected in the palette window.]]

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_7fa321e0.png|frame|center|Selecting a sound.]]

Upon selection of a sound, you will be given a crosshair and you can drop the sound anywhere on the map. You can then adjust its position in 3 dimensions as you see fit.

[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_bdda402.png|frame|center|Placed sounds in the menu.]]

Sounds used as emitters show up in the menu on the right hand side of the area editor. It is here that you can select them to edit their properties and parameters in the object inspector.

[[Category:Sounds]]

Creature tutorial

2009-10-29T00:05:38Z

Axe Murderer: punctuation

Now the player can navigate around between the various areas you've set up, but he's got nothing he can actually do there. Other tutorials will cover how to add interactive quests, conversations, and other such things, but for now to make things just a little more interesting, we can add a couple of monsters for the player to slay. We'll put them in the hut_interior area so the player won't be instantly thrust into combat.

== Creating a monstrous creature's template ==

{{sidebox|
* The "Group" property determines who is hostile to whom
* "Resource Name" and "Tag" are only seen by developers
* "Name" may be seen by players
}}

First, create a new creature template. You can leave most of its properties at their defaults for starters. To make it fight the player when it sees him, set the "Group" property to "_Hostile". Give it a name in the "Name" property ("Hut Monster" in this example) and change the "Appearance" property to something appropriate (a normal Hurlock in this case).

[[Image:Tutorial hut monster.png]]

{{sidebox|
* Put weapons in inventory and set them as "equipped"
}}

To make our monsters a bit more of a challenge for the player to fight, we'll add a sword to the creature's inventory and set it as "equipped". This will put the sword on the creature's back, where it will draw it from when it enters combat. To prevent the player from being laden down with hundreds of looted swords over the course of the game we'll leave the "Droppable" and "Stealable" flags unset - when the creature dies the sword will be unrecoverable.

[[Image:Tutorial inventory.png]]

{{sidebox|
* "Package" determines what sorts of abilities the creature will have
* "Package AI" determines how it will behave
* "Rank" determines how strong the creature will be and how much loot it drops
* "Treasure category" determines what type of loot it drops
}}

Finally, we'll want to set the creature's stats so that it will be the correct level of toughness to challenge the player when he meets him. The game has two basic parameters that need to be set for this; package (determines what general sorts of abilities the creature has) and rank (determines how good the creature is at what it does, and how tough it is).

We set the general package type to "Darkspawn" (this tells the game what general type of creature it is), the package to "Darkspawn weapon + shield (Hurlock)" since that's the closest match to a Hurlock weilding a one-handed sword that's available, and the package AI to "AIP_DS_WPN_SHLD_Hurlock" (since this is the only AI available for the selected package the choice is obvious. For some creatures there may be other AIs available, for example making the creature behave in a more "cowardly" fashion).

The rank of the creature tells the game's autoscaling system how good the creature should be at using its abilities and how tough it is. Since we want these creatures to be an interesting fight but not a serious challenge for our demo, we'll set the hut monster to "Critter". Rank also determines the quality of the treasure that is automatically generated for the player to loot from the monster's corpse; tougher monsters have higher-quality loot. To determine what ''kind'' of loot is generated, set the treasure category property. Different types of monsters will generally carry different types of loot, for example the Darkspawn are more likely to have vials of poison in their possession.

== Placing creatures ==

{{sidebox|
* See [[3D control]] for camera and movement controls
}}

Now that we have the basic template for the horrible hut monsters defined, we can place some in the hut's interior. The creature we've designed in the creature editor is a template from which many identical copies can be spawned and placed within the area, much like the placeable doors we've inserted previously. Open the area in the area editor, select the hut monster from the palette, and click on the area in the places you want to put copies of the creature.

[[Image:Tutorial hut interior.png]]

We've put three monsters in the hut. If we play the game now the monsters will attack the player as soon as they perceive him, which the small size of the hut will make almost instantaneous. Once slain the player will be able to loot their corpses for a small amount of treasure.

If you want to customize the individual monsters you've placed, you can right-click on the creature (either in the area map or on the area's object list to the left of the area display) and select "properties" from the menu.

[[Image:Tutorial individal creature properties.png]]

{{sidebox|
* Some creature properties can be customized on a per-creature basis, others are fixed with whatever value you set in the creature template it's based on.
}}

This will open the object inspector with a subset of the creature's properties that can be customized on a per-creature basis. Not all of the properties of the creature can be modified; some of them are defined by the template and can only be modified there. The properties that can be modified on a per-creature basis are:

*Active (useful for placing monsters that only "appear" later on when a script changes their active status)
*Interaction Radius (if not zero, overrides the default distance the PC needs to be to interact with this object)
*Platform (used when developing a game that can be ported to multiple different platforms with different capabilities)
*Rank (how tough the monster is, described above)
*Tag (a label the creature can be referred to by with scripting)
*Team (an identifier for grouping several monsters together, useful for keeping track of quests and for coordinated behavior)
*Trackable
*Treasure Category (type of treasure dropped, described above)
*Variables
*WeaponsDrawn
*Orientation (Don't bother manually setting orientation and position unless you need high-precision control, the area editor's positioning controls are generally easier)
*Position

So, for example, we could pick a particular one of these hut monsters and make him tougher than his fellows, or give him a different team ID (we'll see one way team IDs can be used later in the tutorial when we set up a quest for the player to slay all three of the monsters we've put in the hut).

== Creating an NPC quest giver ==

{{sidebox|
* Some humanoid creatures don't have clothing built in and need it to be added to their inventory and equipped for it to appear.
* Some humanoid creatures can have their appearance customized by selecting head [[morph]]s.
}}

The module is now vaguely playable, but not really all that interesting - it's hard to tell a story with nothing but area transitions and meaningless combat. The easiest way to add some depth to the adventure is to include some people that can be talked with. Conversations are complex and will be dealt with in a separate section of the tutorial, but we can lay the foundation here by creating and placing a neutral human to talk to. By putting him in the "_Neutral" group he won't attack the player and won't get involved in the player's fights. If he were in the _Friendly group he'd attack any _Hostile-grouped creatures he perceived, but for now we'll be putting him in an area with no other creatures so that won't make a difference.

The default new creature is human, but is unclothed and unequipped. It also has a very bland default appearance. To dress the creature we'll need to create some clothing as done in the [[Item tutorial]], add it to the creature's inventory, and equip it (if you cannot see your newly-created items in the inventory dialog, try checking them in first).

[[Image:Tutorial quest giver inventory.png]]

Next we're going to want to replace that bland default head with a different appearance. Dragon Age allows head appearance to be customized through the use of head morphs, a process with sufficient sophistication and scope that there's a separate editing tool dedicated to it. We won't cover that in this tutorial, however, and instead simply use one of the prefabricated head morphs that comes with the game.

Under the "Appearance" section of the object explorer is the "Head Morph" property. When you click on the ellipsis ([[Image:ellipsis.png]]) button you'll be presented with a file picker to choose a head morph from. Once you've selected a head morph most of the other options under Appearance will be disabled, since the head morph customizes all of those parameters in a much more fine-grained manner.

Since this NPC is not intended to ever enter or even respond to combat, the package and scaling is not particularly important. It can be left with the defaults.

{{sidebox|
* There are several different ways to make a creature "permanent," if needed
}}

The "Special" section is relevant in this case, on the other hand. Since this NPC is going to be the source of our quest, it wouldn't do to allow even the possibility that he might get himself killed early. If you set the "Plot" flag to true the creature will be immune to damage by any hostile effect. The "Immortal" flag allows the creature to be damaged, but it will never lose its last hit point - useful if you want a creature to get involved in a fight in a realistic manner but guarantee that it will survive the encounter. "No Permanent Death" tells the game engine not to dispose of the creature's body after it's killed and is used primarily for the player's companions.

Here is the NPC in his final form, ready to be placed in the hut_exterior area to tell the player about the monsters inside:

[[Image:Tutorial quest giver.png]]

[[Category:Tutorials]]
[[Category:Creatures]]

Creature tutorial

2009-10-29T00:04:27Z

Axe Murderer: punctuation

Now the player can navigate around between the various areas you've set up, but he's got nothing he can actually do there. Other tutorials will cover how to add interactive quests, conversations, and other such things, but for now to make things just a little more interesting we can add a couple of monsters for the player to slay. We'll put them in the hut_interior area so the player won't be instantly thrust into combat.

== Creating a monstrous creature's template ==

{{sidebox|
* The "Group" property determines who is hostile to whom
* "Resource Name" and "Tag" are only seen by developers
* "Name" may be seen by players
}}

First, create a new creature template. You can leave most of its properties at their defaults for starters. To make it fight the player when it sees him, set the "Group" property to "_Hostile". Give it a name in the "Name" property ("Hut Monster" in this example) and change the "Appearance" property to something appropriate (a normal Hurlock in this case).

[[Image:Tutorial hut monster.png]]

{{sidebox|
* Put weapons in inventory and set them as "equipped"
}}

To make our monsters a bit more of a challenge for the player to fight, we'll add a sword to the creature's inventory and set it as "equipped". This will put the sword on the creature's back, where it will draw it from when it enters combat. To prevent the player from being laden down with hundreds of looted swords over the course of the game we'll leave the "Droppable" and "Stealable" flags unset - when the creature dies the sword will be unrecoverable.

[[Image:Tutorial inventory.png]]

{{sidebox|
* "Package" determines what sorts of abilities the creature will have
* "Package AI" determines how it will behave
* "Rank" determines how strong the creature will be and how much loot it drops
* "Treasure category" determines what type of loot it drops
}}

Finally, we'll want to set the creature's stats so that it will be the correct level of toughness to challenge the player when he meets him. The game has two basic parameters that need to be set for this; package (determines what general sorts of abilities the creature has) and rank (determines how good the creature is at what it does, and how tough it is).

We set the general package type to "Darkspawn" (this tells the game what general type of creature it is), the package to "Darkspawn weapon + shield (Hurlock)" since that's the closest match to a Hurlock weilding a one-handed sword that's available, and the package AI to "AIP_DS_WPN_SHLD_Hurlock" (since this is the only AI available for the selected package the choice is obvious. For some creatures there may be other AIs available, for example making the creature behave in a more "cowardly" fashion).

The rank of the creature tells the game's autoscaling system how good the creature should be at using its abilities and how tough it is. Since we want these creatures to be an interesting fight but not a serious challenge for our demo, we'll set the hut monster to "Critter". Rank also determines the quality of the treasure that is automatically generated for the player to loot from the monster's corpse; tougher monsters have higher-quality loot. To determine what ''kind'' of loot is generated, set the treasure category property. Different types of monsters will generally carry different types of loot, for example the Darkspawn are more likely to have vials of poison in their possession.

== Placing creatures ==

{{sidebox|
* See [[3D control]] for camera and movement controls
}}

Now that we have the basic template for the horrible hut monsters defined, we can place some in the hut's interior. The creature we've designed in the creature editor is a template from which many identical copies can be spawned and placed within the area, much like the placeable doors we've inserted previously. Open the area in the area editor, select the hut monster from the palette, and click on the area in the places you want to put copies of the creature.

[[Image:Tutorial hut interior.png]]

We've put three monsters in the hut. If we play the game now the monsters will attack the player as soon as they perceive him, which the small size of the hut will make almost instantaneous. Once slain the player will be able to loot their corpses for a small amount of treasure.

If you want to customize the individual monsters you've placed, you can right-click on the creature (either in the area map or on the area's object list to the left of the area display) and select "properties" from the menu.

[[Image:Tutorial individal creature properties.png]]

{{sidebox|
* Some creature properties can be customized on a per-creature basis, others are fixed with whatever value you set in the creature template it's based on.
}}

This will open the object inspector with a subset of the creature's properties that can be customized on a per-creature basis. Not all of the properties of the creature can be modified; some of them are defined by the template and can only be modified there. The properties that can be modified on a per-creature basis are:

*Active (useful for placing monsters that only "appear" later on when a script changes their active status)
*Interaction Radius (if not zero, overrides the default distance the PC needs to be to interact with this object)
*Platform (used when developing a game that can be ported to multiple different platforms with different capabilities)
*Rank (how tough the monster is, described above)
*Tag (a label the creature can be referred to by with scripting)
*Team (an identifier for grouping several monsters together, useful for keeping track of quests and for coordinated behavior)
*Trackable
*Treasure Category (type of treasure dropped, described above)
*Variables
*WeaponsDrawn
*Orientation (Don't bother manually setting orientation and position unless you need high-precision control, the area editor's positioning controls are generally easier)
*Position

So, for example, we could pick a particular one of these hut monsters and make him tougher than his fellows, or give him a different team ID (we'll see one way team IDs can be used later in the tutorial when we set up a quest for the player to slay all three of the monsters we've put in the hut).

== Creating an NPC quest giver ==

{{sidebox|
* Some humanoid creatures don't have clothing built in and need it to be added to their inventory and equipped for it to appear.
* Some humanoid creatures can have their appearance customized by selecting head [[morph]]s.
}}

The module is now vaguely playable, but not really all that interesting - it's hard to tell a story with nothing but area transitions and meaningless combat. The easiest way to add some depth to the adventure is to include some people that can be talked with. Conversations are complex and will be dealt with in a separate section of the tutorial, but we can lay the foundation here by creating and placing a neutral human to talk to. By putting him in the "_Neutral" group he won't attack the player and won't get involved in the player's fights. If he were in the _Friendly group he'd attack any _Hostile-grouped creatures he perceived, but for now we'll be putting him in an area with no other creatures so that won't make a difference.

The default new creature is human, but is unclothed and unequipped. It also has a very bland default appearance. To dress the creature we'll need to create some clothing as done in the [[Item tutorial]], add it to the creature's inventory, and equip it (if you cannot see your newly-created items in the inventory dialog, try checking them in first).

[[Image:Tutorial quest giver inventory.png]]

Next we're going to want to replace that bland default head with a different appearance. Dragon Age allows head appearance to be customized through the use of head morphs, a process with sufficient sophistication and scope that there's a separate editing tool dedicated to it. We won't cover that in this tutorial, however, and instead simply use one of the prefabricated head morphs that comes with the game.

Under the "Appearance" section of the object explorer is the "Head Morph" property. When you click on the ellipsis ([[Image:ellipsis.png]]) button you'll be presented with a file picker to choose a head morph from. Once you've selected a head morph most of the other options under Appearance will be disabled, since the head morph customizes all of those parameters in a much more fine-grained manner.

Since this NPC is not intended to ever enter or even respond to combat, the package and scaling is not particularly important. It can be left with the defaults.

{{sidebox|
* There are several different ways to make a creature "permanent," if needed
}}

The "Special" section is relevant in this case, on the other hand. Since this NPC is going to be the source of our quest, it wouldn't do to allow even the possibility that he might get himself killed early. If you set the "Plot" flag to true the creature will be immune to damage by any hostile effect. The "Immortal" flag allows the creature to be damaged, but it will never lose its last hit point - useful if you want a creature to get involved in a fight in a realistic manner but guarantee that it will survive the encounter. "No Permanent Death" tells the game engine not to dispose of the creature's body after it's killed and is used primarily for the player's companions.

Here is the NPC in his final form, ready to be placed in the hut_exterior area to tell the player about the monsters inside:

[[Image:Tutorial quest giver.png]]

[[Category:Tutorials]]
[[Category:Creatures]]

Placeable tutorial

2009-10-28T23:43:38Z

Axe Murderer: /* Placing / Adjusting your Placeable */ punctuation

In Dragon Age, "[[placeable]]s" are objects that a player can interact with or are objects simply added to the area to create greater detail. They are added to areas simply by dropping them into the area landscape. Once placed, they can easily be moved into position or rotated on their axis to achieve the look you want.

In general, placeables can serve a wide variety of functions. They can render popup text. They can be destroyed or bashed or hold inventory or treasure within. They can be holders of conversations. In this tutorial we'll mainly stick to the basics, but placeables are an important part of any area design.

== Creating A Placeable ==

Similar to creating anything within the toolset, go to File > New > Placeable or right click in the Palette Window to access the New Placeable option.

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

The first step is naming the placeable. We'll need a door for the tutorial so lets start with a door that will serve as an area transition. Name the placeable "transition_door". Luckily and unluckily, the default object is a door. The lucky part is that it is a door. The unlucky part is that this is a non-area transition door. There are two types of doors, ones that open and allow for an area transition and ones that simply open. For the upcoming [[area tutorial]] we need a door that will allow the player to move from outside the hut to inside the hut.

Doors that allow transitions are all grouped under the Appearance beginning with "Area Transition". Change the appearance to be "Area Transition, Ferelden, Small". The placeable has the exact same appearance it had but now it will be able to function as an area transition. For more detail on doors, please see [[door]]s. They are a bit unique within the placeable world so it is important to understand how the two types function as well as some of the finer options that are available.

As you can see, placeables are straightforward and easy to create. Let's build one more for our module before moving along with the tutorial. Again create a new placeable and let's name it "statue". Any good exterior can always use a statue. For this lets set the appearance to "Statue, Giant" and rename the placeable "Huge Statue". By default, the placeable is "Interactive" so let's toggle that setting to false. You can either use the drop down menu OR just double click on TRUE to toggle the state. Now our statue is ready to be placed. It is basically an addition to the landscape. It won't be something you can interact with but it can add detail to your area and to your story.

While we are in the tutorial, let's quickly cover checking in and checking out resources which is a new concept for Dragon Age. For a more detailed summary, please see [[Resource palette]]. Briefly, in Dragon Age resources are stored within databases. When you work on a module and alter any existing work or create new work, you are creating an instance of the object (be it a placeable, item, creature, area etc.). There are a number of benefits for this that are beyond the scope of this tutorial but when you edit something, it has to be "checked out" (or never checked in) with you working on an instance.

For example, select your new statue and right click and you will see that many common tasks are NOT available because it has not been "checked in" to the database. For example, you can't rename or delete the placeable. In order to rename the placeable, we'll need to check in the placeable. Right click and select check in. Check the box for no comment or enter a comment and hit ok. At this point, the resource has been written to the database. Once the object is "checked in" you can adjust the name or delete it if you so choose (assuming it doesn't have other dependent resources).

== Placing / Adjusting your Placeable ==

That is a brief overview of how to create your first placeables. Now let's cover putting them into your module. To place a placeable, simply bring up an area (which we will make in the [[Area Tutorial]]), then highlight the placeable and left-click within the region.

To adjust the position or orientation of the object, you'll need to use the Camera and Movement Toolbar:

[[Image:Camera and movement toolbar labeled.png]]

To adjust the x,y,z position either activate the Local Coordinates button [[Image:IconLocalCoordinates.png]] or use the keyboard shortcut 'q'. With this activated, you can mouse over any axis (notice the change to the yellow highlight) and the object will move only in the selected dimension.

To adjust the rotational orientation, highlight the 3 Axis Rotation button [[Image:Icon3AxisRotation.png]] or use the keyboard shortcut 'e'. In a similar fashion, you can easily selected and adjust the rotational orientation of the placeable.

(For much more detail regarding 3D controls please see the [[3D control]] page).

Of course, you can use the Object Inspector to type in exact numbers for any of these parameters you choose. Simply ensure the object is selected within the area viewer and type in your changes.

== Field Notes ==

*'''Character''': Mapping a character to a placeable is done for VO when a placeable owns a conversation.

[[Category:Placeables]]
[[Category:Tutorials]]

Placeable tutorial

2009-10-28T23:43:08Z

Axe Murderer: /* Placing / Adjusting your Placeable */ grammar

In Dragon Age, "[[placeable]]s" are objects that a player can interact with or are objects simply added to the area to create greater detail. They are added to areas simply by dropping them into the area landscape. Once placed, they can easily be moved into position or rotated on their axis to achieve the look you want.

In general, placeables can serve a wide variety of functions. They can render popup text. They can be destroyed or bashed or hold inventory or treasure within. They can be holders of conversations. In this tutorial we'll mainly stick to the basics, but placeables are an important part of any area design.

== Creating A Placeable ==

Similar to creating anything within the toolset, go to File > New > Placeable or right click in the Palette Window to access the New Placeable option.

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

The first step is naming the placeable. We'll need a door for the tutorial so lets start with a door that will serve as an area transition. Name the placeable "transition_door". Luckily and unluckily, the default object is a door. The lucky part is that it is a door. The unlucky part is that this is a non-area transition door. There are two types of doors, ones that open and allow for an area transition and ones that simply open. For the upcoming [[area tutorial]] we need a door that will allow the player to move from outside the hut to inside the hut.

Doors that allow transitions are all grouped under the Appearance beginning with "Area Transition". Change the appearance to be "Area Transition, Ferelden, Small". The placeable has the exact same appearance it had but now it will be able to function as an area transition. For more detail on doors, please see [[door]]s. They are a bit unique within the placeable world so it is important to understand how the two types function as well as some of the finer options that are available.

As you can see, placeables are straightforward and easy to create. Let's build one more for our module before moving along with the tutorial. Again create a new placeable and let's name it "statue". Any good exterior can always use a statue. For this lets set the appearance to "Statue, Giant" and rename the placeable "Huge Statue". By default, the placeable is "Interactive" so let's toggle that setting to false. You can either use the drop down menu OR just double click on TRUE to toggle the state. Now our statue is ready to be placed. It is basically an addition to the landscape. It won't be something you can interact with but it can add detail to your area and to your story.

While we are in the tutorial, let's quickly cover checking in and checking out resources which is a new concept for Dragon Age. For a more detailed summary, please see [[Resource palette]]. Briefly, in Dragon Age resources are stored within databases. When you work on a module and alter any existing work or create new work, you are creating an instance of the object (be it a placeable, item, creature, area etc.). There are a number of benefits for this that are beyond the scope of this tutorial but when you edit something, it has to be "checked out" (or never checked in) with you working on an instance.

For example, select your new statue and right click and you will see that many common tasks are NOT available because it has not been "checked in" to the database. For example, you can't rename or delete the placeable. In order to rename the placeable, we'll need to check in the placeable. Right click and select check in. Check the box for no comment or enter a comment and hit ok. At this point, the resource has been written to the database. Once the object is "checked in" you can adjust the name or delete it if you so choose (assuming it doesn't have other dependent resources).

== Placing / Adjusting your Placeable ==

That is a brief overview of how to create your first placeables. Now let's cover putting them into your module. To place a placeable, simply bring up an area (which we will make in the [[Area Tutorial]]) then highlight the placeable and left-click within the region.

To adjust the position or orientation of the object, you'll need to use the Camera and Movement Toolbar:

[[Image:Camera and movement toolbar labeled.png]]

To adjust the x,y,z position either activate the Local Coordinates button [[Image:IconLocalCoordinates.png]] or use the keyboard shortcut 'q'. With this activated, you can mouse over any axis (notice the change to the yellow highlight) and the object will move only in the selected dimension.

To adjust the rotational orientation, highlight the 3 Axis Rotation button [[Image:Icon3AxisRotation.png]] or use the keyboard shortcut 'e'. In a similar fashion, you can easily selected and adjust the rotational orientation of the placeable.

(For much more detail regarding 3D controls please see the [[3D control]] page).

Of course, you can use the Object Inspector to type in exact numbers for any of these parameters you choose. Simply ensure the object is selected within the area viewer and type in your changes.

== Field Notes ==

*'''Character''': Mapping a character to a placeable is done for VO when a placeable owns a conversation.

[[Category:Placeables]]
[[Category:Tutorials]]

Talk:Placeable tutorial

2009-10-28T23:39:19Z

Axe Murderer:

There is a poorly worded fragmented sentence in the Creating A Placeable section. 2nd to last paragraph, last sentence in the paragraph (the one about checking stuff in and out). I think I know what it is trying to say but am not confident about it. It's that "with you working on an instance" bit tacked onto the end there that's throwing me.

I think it means to say that you must be working on an instance in order to make any changes, but in order to create an instance you can work on, you must check it out of the database first. The process of checking a resource out of the database creates this instance for you.

Needs a better writer than me to fix it.

There is also a surprise at the end of the following paragraph. You can freely change the name delete etc except (surprise) in this one case when you have dependent resources (which are ????).

Maybe just one more sentence there to flesh out that special case a tad more.

dependent resources ...such as when you have blah blah causing blah blah dependency.

[[User:Axe Murderer|Axe Murderer]] 23:30, 28 October 2009 (UTC)

Talk:Placeable tutorial

2009-10-28T23:31:40Z

Axe Murderer:

Talk:Placeable tutorial

2009-10-28T23:30:39Z

Axe Murderer: bad wording needs attention