Dragon Age Toolset Wiki - User contributions [en]

DEBUG PrintToScreen

2011-01-24T11:50:45Z

Craig Graff:

{{dafunction
|name=DEBUG_PrintToScreen
|brief=Prints a string to all the client screens.
|param1type=string
|param1name=sString
|param1desc=The string value to print out to the screen
|param1default=
|param2type=int
|param2name=nPosFromTop
|param2desc=Where to output the string on the client's screen
|param2default=10
|param3type=float
|param3name=fLife
|param3desc=life for the string in seconds
|param3default=10.0
|returntype=void
|returndesc=
|sourcefile=script.ldf
|sourcemodule=
}}

== Description ==

Prints the string sString to the screen in all the available clients.



This function doesn't work in the retail version of the game. Use [[DisplayFloatyMessage]] or [[PrintToLog]] instead.







[[Category: Print & log functions]]

Useful Scripts

2010-03-15T14:14:31Z

Craig Graff: /* Insert content into an existing area */

{{Infobox script}}

This page lists how to accomplish tasks that are relatively simple and commonly needed, but that otherwise require deep scripting knowledge to figure out intuitively how to do.

Feel free to add new sections describing any tricks or techniques you think is worth documenting. If the page becomes too large it can be split up into specific topics.

See also: [[PRCSCR Script Templates]]

__TOC__
== Run a cutscene from a trigger ==

Create a script:

<dascript>
#include "events_h"
#include "global_objects_h"
#include "utility_h"

void main ()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
int bEventHandled = FALSE;
switch (nEventType)
{
case EVENT_TYPE_ENTER:
{
object oCreature = GetEventCreator(ev);
if(GetObjectActive(OBJECT_SELF)
&& IsPartyMember(oCreature))
{
resource rCutscene = R"my_cutscene.cut";
CS_LoadCutscene(rCutscene);
SetObjectActive(OBJECT_SELF, FALSE);
}
}
break;
}
if (!bEventHandled) //If this event wasn't handled by this script, let the core script try
{
HandleEvent(ev, RESOURCE_SCRIPT_TRIGGER_CORE);
}
}
</dascript>

And set it as the event script for the trigger that you want to have run the cutscene.

== Add a follower to the player's party ==

<dascript>
if(IsPlayer(oCreature)) {
object oFollower = GetObjectByTag("myfollower");
UT_HireFollower(oCreature, oFollower);
}
</dascript>

Note that with Toolset v1.0.982.0, calling UT_HireFollower() will result in a follower who's unable to gain xp. This happens due to the call of
<dascript>
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, '''TRUE''');
</dascript>
to the function
<dascript>
void WR_SetFollowerState(object oCreature, int nState, int nSendEvent = TRUE, int nMinLevel = 0, '''int bPreventLevelup''' = FALSE)
</dascript>
To enable the xp gain, the flag CREATURE_REWARD_FLAGS needs to be cleared from the follower after the hired event was processed (there the flag is set). For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:

<dascript>
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
</dascript>
to
<dascript>
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
</dascript>

== Have an enemy play possum and then get up to fight ==

Set the creature's CREATURE_SPAWN_DEAD variable to 2.

When it's time for the creature to rise and attack, execute the following script commands:

<dascript>
#include "wrappers_h"
...
WR_SetObjectActive(oCreature, TRUE);
SetCommandable(oCreature, TRUE);
// Make sure to set this flag back to 0 to avoid problems with savegames.
SetLocalInt(oCreature, CREATURE_SPAWN_DEAD, 0);
UT_CombatStart(oCreature, oPC);
</dascript>

== Insert content into an existing area ==

If you want to add new content on to an existing area (for example, putting a new character or area transition door into an area that exists in the single-player campaign) there are two different ways to do it. One is to override the existing area with a new area of your own design that duplicates the original with the exception of your additions. This is straightforward to do but can interact poorly with other add-ons - you can only have one version of an area active at a time. '''[To Editor: Edit in a Custom Module or the existing Single Player Campaign Module?]'''

A more elegant and extensible approach is to use a [[PRCSCR]]_-prefixed M2DA. The PRCSCR M2DA has a very simple structure and a simple but profound effect:

*ID - a unique integer identifier for each row
*AreaListName - a string that identifies a specific area list, or the special keyword "any".
*Script - the name of a script file.

Whenever a player enters an area in an area list in this M2DA the associated script will be run. A modder can therefore include a script with his mod that will be run when the player enters an existing area that he didn't create. This script can freely add or remove placeables and creatures and perform whatever other modifications to the area that a script is capable of doing.

Note that the script will be run every time the player enters the area, so you'll want to have an associated plot flag to ensure that the changes are only made once.

The following example is a script that adds a new character from an add-on module to an existing area in the main game:

<dascript>
// this is the name of a precreated plot file "joblos_quest" prefixed with the special "plt_"
// "plt_" + quest name allows you to reference the flag names as constants.
#include "plt_joblos_quest"
#include "wrappers_h"

void main()
{
//Check whether we've added Joblo already.
if (WR_GetPlotFlag(PLT_JOBLOS_QUEST, JOBLO_ADDED_TO_TOWN) == FALSE)
{
object oTown = GetObjectByTag("lot100ar_lothering"); //An area's tag is the same as its resource name
vector vJobloLocation = Vector(126.745f, 120.724f, 0.460568f); // See below for how to get these coordinates

CreateObject(
OBJECT_TYPE_CREATURE,
R"joblo.utc",
Location(oTown, vJobloLocation, 180.0f); //See below for how to get the value for orientation
)

WR_SetPlotFlag("joblos_quest", JOBLO_ADDED_TO_TOWN, TRUE);
}
}
</dascript>

Since you can't add [[waypoint]]s to an existing area you'll need to enter the position and orientation values for the target location manually. You can find them by creating a local copy of the area in question and temporarily adding a waypoint to copy down the coordinates and orientation you'll need.

== Create a lootable placeable that vanishes when looted ==

For a player-usable placeable, use the following event script to make it give its contents to the player and then vanish when clicked on.

<dascript>
#include "wrappers_h"
void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch (nEventType)
{
case EVENT_TYPE_USE:
{
//MoveAllItems(OBJECT_SELF, GetHero());
AddCreatureMoney (1000000, GetHero(), TRUE);
Safe_Destroy_Object(OBJECT_SELF);
}
}
}
</dascript>

If you wanted to use standard resources you could achieve the same thing (though not destroying the placeable) simply by adding "_autoloot" to the end of the placeable's tag.

== Move the player to a new area after a cutscene plays ==

Stand-alone cutscenes have an "end script" parameter that sets a script to run once the cutscene ends. Use a script such as the following:

<dascript>
void main()
{
DoAreaTransition("destination_area_tag", "destination_waypoint_tag");
}
</dascript>

== Override Events (e.g. those in player_core) ==

Look here: [[Event override]]

[[category:tutorials]]
[[Category:Scripts]]

2DA

2010-03-03T03:43:46Z

Craig Graff: /* Users of Open Office */

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. Each 2DA is simply an organized collection of strings and numbers. The specific function of each 2DA depends on how it is used by other systems in the game.

__TOC__
== Overview - what is a 2DA? ==

A 2DA contains a set of columns, with each column having a fixed label and a fixed data type. For example, the ABI_Base 2DA has a column that is labeled "namestrref" and has the data type "int". This means that the data stored in this column must be an integer and that the data stored in this column can be retrieved by referring to the label "namestrref". The number and types of columns in a 2DA does not usually ever change. The columns provide the structure of the 2DA that allows it to be referred to and used in a consistent manner. The first column of every 2DA is always labeled "ID" and is always of type "integer". This column is used to uniquely identify the rows in the 2DA.

A 2DA's rows are what contain the data being stored in it. Each row's columns have the same set of labels and data types (as defined at the top of the 2DA) but the data contained within them can be different. Adding new rows to a 2DA is common and easy; you just need to give it a new ID number in the "ID" column and then fill in the rest of the cells with whatever information you need. Once you've given a row an ID number it generally never changes. The game also has a mechanism called "M2DAs" that allow rows to be added to existing 2DAs without having to edit the original file, see below for more detail.

Some 2DAs reference rows in other 2DAs. For example the ABI_Base 2DA has an integer column named "projectile", and each row can have an integer in that column that identifies a row in the PRJ_Base 2DA. These relationships are generally only defined in the scripts that use the 2DAs and are not inherent to the 2DAs themselves so you'll have to keep track of these things yourself.

== Excel file formatting ==

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

''See: [[compiling 2DAs]]'' - for several methods of how to perform this conversion, and where to put 2DAs.

{| border="2" cellpadding="5" cellspacing="0" width="700pt" align"left"
|+ '''Example Worksheet "Monsters"'''
| width="30pt" style="background-color:#808080" |'''ID'''
| width="30pt" style="background-color:#AFAFAF" |'''Label'''
| width="50pt" style="background-color:#AFAFAF" |'''Strenght'''
| width="50pt" style="background-color:#AFAFAF" |'''Name'''
| width="50pt" style="background-color:#AFAFAF" |'''ResourceExample'''
| width="50pt" style="background-color:#AFAFAF" |'''Scale'''
| width="50pt" style="background-color:#AFAFAF" |'''disabled'''
| width="50pt" style="background-color:#AFAFAF" |'''Commentexample'''
|-
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''resource'''''
| style="background-color:#AFAFAF" |'''''float'''''
| style="background-color:#AFAFAF" |'''''bool'''''
| style="background-color:#AFAFAF" |'''''comment'''''
|-
| style="background-color:#AFAFAF" |0
|INVALID
|****
|sometimes
|bioware said
|****
|****
|i stay unused
|-
| style="background-color:#AFAFAF" |1
|Evilmonster1
|23
|Abomination
|prp_barrel01
|1,0
|0
|totally evil
|-
| style="background-color:#AFAFAF" |2
|Evilmonster2
|34
|Shriek
|prp_bucket_01
|1,0
|1
|very bad
|}

Data in a 2DA is identified by a row number, with the first row (using ID zero) usually being reserved for internal use (undefined value, etc.) by convention. Each row has an arbitrary number of columns identified by strings. The grey fields in this example table are very specific to the 2DA, the white fields are arbitrary data which the Gameengine identifies for that 2DA.

The ID of a Row is the reference for the Game to access and link to them. As such they are unique across the 2DA, and any M2DA that extends it. The contents of each column is specific to the 2DA given, and arbitrary. When extending a 2DA, new ID's have to be given, and Columns have to be exactly the same.

=== Guidelines ===
*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.
*ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== Extending the game via M2DAs ==

{| border="2" cellpadding="5" cellspacing="0" width="700pt" align"left"
|+ '''Example Worksheet "MonstersCustom"'''
| width="30pt" style="background-color:#808080" |'''ID'''
| width="30pt" style="background-color:#AFAFAF" |'''Label'''
| width="50pt" style="background-color:#AFAFAF" |'''Strenght'''
| width="50pt" style="background-color:#AFAFAF" |'''Name'''
| width="50pt" style="background-color:#AFAFAF" |'''ResourceExample'''
| width="50pt" style="background-color:#AFAFAF" |'''Scale'''
| width="50pt" style="background-color:#AFAFAF" |'''disabled'''
| width="50pt" style="background-color:#AFAFAF" |'''Commentexample'''
|-
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''resource'''''
| style="background-color:#AFAFAF" |'''''float'''''
| style="background-color:#AFAFAF" |'''''bool'''''
| style="background-color:#AFAFAF" |'''''comment'''''
|-
| style="background-color:#AFAFAF" |2300000
|Evilmonster3
|32
|Wolf
|c_wolfa
|1,0
|0
|New Monster
|}

An "M2DA" is a "Multiple 2DA" that stacks a number of 2DAs into one larger table. They work much like single 2DA files except they can be patched or expanded later by adding another 2DA. 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. 2DAs are merged row by row, keyed on the ID column.

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.

Every M2DA used by the game is listed in M2DA_base ([[2DA_base.xls]]) and 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 start with, as the name is actually a prefix to the file. 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_".

Note that M2DA_base is itself an M2DA file and can be extended in the same manner.

*''This example 2DA "MonstersCustom" would be merged into the original 2DA "Monsters", if "Monsters" were one of the worksheets listed in the M2DA_base. ''

=== Reserved ID Ranges and overriding existing rows ===

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it. If you use an existing row ID in your M2DA you can override the existing row with new data. Note that this can be a useful mechanism in some situations, for example allowing you to override existing content without having to edit the original 2DAs directly.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

''See: [[compiling 2DAs#Afterwards|compiling 2DAs]]'' - for Information on where to place M2DA files to achieve the desired effect.

=== Bug with M2DA ===

It should be noted, that currently there is a bug with certain M2DA's, which prevents new ID's above 255 to work in the game. It is unclear which are affected, but most certainly it is [[ItemVariations.xls]] related. See [[Bug: High M2DA ID ranges might work in the toolset, but not in game|Bug report]].

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

[[List of 2DA XLS files]]

The source files for the 2DAs that came with the installed game can be found under the toolsets directory
<pre><Installdir>\Dragon Age\tools\Source\2DA\</pre>

== Users of Open Office ==
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gda file (e.g. placeable_types.gda). Alternately, upload your .xls file to Google Docs and then download the file as Excel format, then process the file with ExcelProcessor.exe.
* When editing existing xls files, it also works to leave the format as standard while saving the file. Open Office asks to change the file to its own spreatsheet format when saving a format other then its own, don't change the format and it should work. [Edit- And yet it doesn't seem to.]
* It is seemingly better at this time to simply use [http://docs.google.com Google Docs] instead as a free alternative, as Open Office will truncate floating point values in certain XLS files when compiled into a [[GDA]], while seemingly not in others. This can lead to unpredictable behavior, such as the game crashing when extending [[APR_base.xls]] while all appears normal in the toolset. (Possibly this was just a result of adding an extraneous space to a cell.)

== Adding Strings ==

{{needs review}}

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

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

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

'''Attention:'''

* The current version of the "ExelProcessor"-App is buggy as it can't hanlde INT values above 8388607! Many thanks to elys for figuring that out.
* Also note that the original toolset (v1.0) core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory if you are still using that version.

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

[[Category:2DAs]]

Community support ideas

2010-02-07T18:55:13Z

Craig Graff:

Unfortunately the team at BioWare that prepared the toolset for public use doesn't have enough resources to address every request or suggestion for improvement. The following is a collection of ideas for improvements that BioWare couldn't get to but that could quite possibly be done by community contributions instead.

;Better, more consistent camera control settings: At BioWare the various different editors of the toolset are used by various different specialists, each focused on their own area of expertise. This has led to different camera controls schemes being used in the area and level editors, for example. The [[camera control]] schemes are set in the [[DefaultSettings.xml]] file. Community-contributed versions of DefaultSettings with more consistent control schemes would be most welcome, or perhaps even a third-party application to make it easier to edit camera controls without XML expertise.

; Voice over management tools : BioWare was unable to release their [[voice over]] and [[localization]] software. The information needed for managing voice over work can be extracted from module [[talk table]]s; it would likely be very useful if there were some sort of application available to make recording VO for dialogue lines easier.

; String ID migration tools : One of the knottier problems that the toolset has with [[builder to builder]] export and import is keeping [[string ID]] numbers from colliding. It frequently has to renumber string IDs as a result. The toolset is able to find and correct all of the string ID references used internally when it does this, but it is unable to automatically find and correct the filenames of voice over wav files and [[FaceFX]] files (these files include the string ID number in their filenames as a way of associating them with their respective lines). A log file is generated during the builder to builder process that records what string ID changes were done, an application that uses this log to rename files could be quite useful.

; Other text tools : the ability to search and replace text in a module's talk table or in its scripts could be useful, especially if there are scripts that refer to specific string IDs (see string ID migration, above).

; Model import tools : Due to legal constraints BioWare was unable to release the export scripts they used to turn 3DSMax models into the format the game uses. Third-party converters and plugins for 3DSMax or for other 3D modeling programs will be essential for full-blown content creation. See [[MMH]] and [[MSH]] for model file specifications.

; Conflict detector : It should be relatively straightforward to extract a list of all the string IDs and [[resref]]s used by any given module. Given that, it should be possible to create an application to automatically compare a set of modules and determine if there are any conflicts between them.

; Variable 2DA management : One of the major differences in how scripting functions between NWN and DA is that you need to pre-define [[local variable]]s in a variable [[2DA]] before they can be used. Changing this would require a major overhaul of how the engine works and so isn't really an option, but perhaps applications could be written to ease local variable management if it proves to be a long-term hassle. In theory one could perhaps scan through all the scripts in a module looking for local variable assignment functions and then try to automatically add the local variables used to local variable 2DAs.(One alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.)

[[Category:Feature requests]]

Local variable

2010-02-04T04:33:55Z

Craig Graff:

Local variables are persistent variables that are associated with in-game objects. They are not the same as the temporary variables you can create in a script; local variables retain their values even when no scripts are using them, and are shared across any scripts that choose to access them.

==Functions that work ==
Local variables are set using the SetLocal* functions and read using the GetLocal* functions. There are a number of SetLocal* functions in the game engine. The five that are of use to you (that Programming fully supports) are:

*[[SetLocalInt]]
*[[SetLocalFloat]]
*[[SetLocalObject]]
*[[SetLocalString]]
*[[SetLocalResource]]

These functions work and have been through the fire of QA for many months. They are solid and work well.

==Functions that don't work ==
There are a number of other functions that happen to exist such as:
*[[SetLocalPlayer]]
*[[SetLocalEffect]]
*[[SetLocalEvent]]
*[[SetLocalCommand]]
*[[SetLocalItemProperty]]
*[[SetLocalLocation]]

These functions do *NOT* work the way that the first five do. The major issue with this second set of functions is that they are not saved/loaded via the save system. So, if a community member or designer wants to save information like this for use later, and someone saves/loads the game, that information is lost forever. Thus, using them outside of situations where you can guarantee no save/load occurs (i.e. during combat) is pretty much guaranteed to fail for some enduser. Furthermore, if you use these variable types in the var_ 2DAs, it will fail gloriously.

Don’t use these functions. They will in all likelihood be removed in a future patch.

== Variable 2DAs ==

Local variables must be pre-defined in a variable 2DA before they can be read or set using these functions. The structure of a variable 2DA is as follows:

{{2da start|var_*}}
{{2da column|Label|string|The name of the variable.}}
{{2da column|Type|string|The type of the variable.}}
{{2da column|Default|string|The default value of the variable. Resources can have the string "NONE" to indicate an empty default.}}
{{2da column|IsPlot|int|Set this to 1 to indicate that a string variable is meant to contain the name of a plot resource. 0 otherwise.}}
{{2da end}}

Each different type of resource has a standard default variable 2DA, whose entries are described in the variable tables associated with their respective articles. You can create your own variable tables or extend existing ones with M2DAs if you need additional local variables for specific objects.

Dragon Age doesn't support the dynamic in-game allocation of new local variables.

==Alternatives ==
An alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.

[[Category:Variable functions|*]]

Local variable

2010-02-04T04:26:33Z

Craig Graff:

Local variables are persistent variables that are associated with in-game objects. They are not the same as the temporary variables you can create in a script; local variables retain their values even when no scripts are using them, and are shared across any scripts that choose to access them.

Local variables are set using the SetLocal* functions and read using the GetLocal* functions. There are a number of SetLocal* functions in the game engine. The five that are of use to you (that Programming fully supports) are:

*[[SetLocalInt]]
*[[SetLocalFloat]]
*[[SetLocalObject]]
*[[SetLocalString]]
*[[SetLocalResource]]

These functions work and have been through the fire of QA for many months. They are solid and work well.

There are a number of other functions that happen to exist such as:
*[[SetLocalPlayer]]
*[[SetLocalEffect]]
*[[SetLocalEvent]]
*[[SetLocalCommand]]
*[[SetLocalItemProperty]]
*[[SetLocalLocation]]

These functions do *NOT* work the way that the first five do. The major issue with this second set of functions is that they are not saved/loaded via the save system. So, if a community member or designer wants to save information like this for use later, and someone saves/loads the game, that information is lost forever. Thus, using them outside of situations where you can guarantee no save/load occurs (i.e. during combat) is pretty much guaranteed to fail for some enduser. Furthermore, if you use these variable types in the var_ 2DAs, it will fail gloriously.

Don’t use these functions. They will in all likelihood be removed in a future patch.

== Variable 2DAs ==

Local variables must be pre-defined in a variable 2DA before they can be read or set using these functions. The structure of a variable 2DA is as follows:

{{2da start|var_*}}
{{2da column|Label|string|The name of the variable.}}
{{2da column|Type|string|The type of the variable.}}
{{2da column|Default|string|The default value of the variable. Resources can have the string "NONE" to indicate an empty default.}}
{{2da column|IsPlot|int|Set this to 1 to indicate that a string variable is meant to contain the name of a plot resource. 0 otherwise.}}
{{2da end}}

Each different type of resource has a standard default variable 2DA, whose entries are described in the variable tables associated with their respective articles. You can create your own variable tables or extend existing ones with M2DAs if you need additional local variables for specific objects.

Dragon Age doesn't support the dynamic in-game allocation of new local variables.

An alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.

[[Category:Variable functions|*]]

Script

2010-02-04T04:23:55Z

Craig Graff: /* Local variables - data repositories for individual objects */

{| style="float:right;"
|-
| {{Resource palette}}
|-
| {{Infobox script}}
|}

Scripts in Dragon Age are used to control all manner of game activity. Much of the functionality that would normally be handled by the game engine is actually managed by core scripts, allowing deep customizability.

== [[Scripting overview]] - basic syntax ==

The DA scripting language is very similar to C in terms of syntax. Files can be included into other files, with files containing libraries of functions designated by a "_h" suffix. (eg. wrappers_h)

:''See [[Scripting overview]].''

== [[Event (dascript type)|Event]]s - driving practically everything ==

Dragon Age has an [[Event (dascript type)|Event]]-driven scripting model, with event objects being passed to scripts containing different parameters depending on the event's type. A large portion of script-writing for a standard adventure is going to involve dealing with events. Common examples include:

* An event is fired to a plot's script whenever one of its flags is set or cleared
* An event is fired to an area's script when a team of creatures dies in it or when a creature (such as the player) enters
* Events are fired to the module's script during character generation
* Events are fired to creatures when certain things happen to them (such as being hit)

[[Custom AI]] for creatures is handled by creating custom AI event handlers.

:''See [[Event (dascript type)|Event]] for more details.''

== [[Effect (dascript type)|Effect]]s and [[Ability|Abilities]] - how to make things affect other things ==

[[Effect (dascript type)|Effect]]s are a bundle of modifiers that are applied to an object or creature. Every effect has a type set on it that determines how it affects the object it is applied to. They also have a number of parameters on them, which vary based on the type, that change the specific behaviour. When the effect is removed (usually because the duration on the effect expires) the modifier is removed. These modifiers can be rule or stat based or more complicated visual and game effects.

They can be assigned different duration types which affect how they're applied and removed:

# Temporary: Applied for a short duration (measured in seconds)
# Permanent: Applied until manually removed through scripting
# Instant: These are one-shot modifiers that are not stored on the object (the death effect is an instant modifier for example)
# Equipped: Associated with an equipped item. The effect is removed when the item is unequipped.

Effects are commonly applied by [[Ability|Abilities]], which are possessed by both creatures and player characters.

== 2DA files - All-purpose game-wide data repositories ==

2-Dimensional Arrays contain much of the raw data used by the game. They are generated from Microsoft Excel files. If you want to add new basic creature types, new treasure types, and so forth, you'll need to create new [[2DA]] files.

:''See Main Article: [[2DA]]''

== [[Treasure system]] ==

The treasure possessed by most creatures and containers is randomly generated by the game's core scripts using a system that selects from appropriate treasure types (for example, wild animals should rarely possess steel armor in their inventories, and Darkspawn are unlikely to be carrying fine porcelain vases) and auto-scales it to be reasonably useful or valuable at the character's level. Manipulating the treasure system can involve both [[local variable]]s and [[event (type)|event]]s.

To put a specific treasure item in a specific creature's [[inventory]], you'll have to create a new creature template for that creature. Inventory cannot be directly defined for particular objects already placed in an [[area]].

:''See main article: [[Treasure system]]''

== [[Local variable]]s - data repositories for individual objects ==

[[Local variable]]s are persistent variables that are associated with in-game objects. They are not the same as the temporary variables you can create in a script; local variables retain their values even when no scripts are using them, and are shared across any scripts that choose to access them.

Local variables are set using the SetLocal* functions and read using the GetLocal* functions. There are a number of SetLocal* functions in the game engine.

Local variables must be pre-defined in a variable [[2DA]] before they can be read or set using these functions. Dragon Age doesn't support the dynamic in-game allocation of new local variables.

An alternative to local variables can be found in the unlimited variable storage project[http://social.bioware.com/project/1787/]. With a single include file and a simple function call in your module script, you can have unlimited variable and array storage with no need to declare anything in a 2da.

:''See main article: [[Local variable]]s''

[[Category:Scripts]]

Getting Started

2010-02-01T23:13:05Z

Craig Graff: /* Starting the Toolset */

== Installing the toolset ==
* First, make sure you have the game installed. The toolset relies on the game's resources and engine and cannot function without them.
* [http://social.bioware.com/toolset.php Download the toolset from here].
*[[Creating an account]] - how to create an account for this wiki and social.bioware.com
* [[Installing the toolset]]
*'''[[Installation troubleshooting]]''' - information on how to fix things in the event that toolset installation goes awry.
*[[Known issues]] with the current version of the toolset

== Overview of the Toolset ==

*[[Overview of the toolset]] - How the Toolset manages Resources you create, and giving a quiet good overview.

*[[Comparisons with other toolkits]] - for users who are familiar with other similar toolkits (eg, the Neverwinter Nights tookit) and would like a brief overview of how the Dragon Age toolkit compares.

== Starting the Toolset ==

{| align=right
|[[File:Titlebar components.png|thumb|300px|right|How to determine which module is currently open]]
|-
|{{Warnbox|Do not edit Single Player or Core Resources with custom content!|300px}}
|}
Before using the Toolset it is important to take note of the [[Module|module]] the toolset has open. A module is a "container" that game resources are stored in; you will only be able to see the resources for the currently-open module (and any modules that it is marked as depending on). The default module when first starting the Toolset is the "Demo" module, which is a very small and simple module intended to show several common resource types in a basic pre-built adventure you can experiment with safely.

The main Dragon Age: Origins campaign resources are stored in a module named "Single Player". If you're just starting out with the toolset it can be dangerous to edit these, as you could inadvertantly corrupt your main campaign. Take care when exploring not to edit any of those resources without knowing what you're doing.

The first basic steps in the Toolset shall be to create your own [[Module]]. The only possible type of Module is "Addin", but note that this name is somewhat misleading; it is possible to have "standalone addins" that are completely separate from any other module (such as the main campaign).

*See: [[Module]] - For a general overview of how a Module works, and what awaits you.

== Using the Toolset ==

As described in the overview linked to above, the game uses a wide variety of resource types. A "resource" is something that you can create, such as a script or a creature, and you will often need to combine many different resources together to accomplish a particular design goal. The toolset consists of many independent tools for working with these different types of resources. These tools can be well discussed separately.

The next best step for learning the toolset would be to look into the categories on the [[Main Page]], which link deeper into each topic and the tools involved with them. If you are having questions at a specific part of the toolset give this Wiki a search for it. This can be very specific, and always worth a try. You may also find the [http://social.bioware.com/forum/1/subindex/70 toolset forums] to be useful in solving specific problems the documentation here may not cover.

A list of certain Interest, and the 3 Resource types:
*[[Design]] - Talks mainly about Designer Resources, in question is Items, Monsters, NPC's, Vendors, etcetc
*[[Art]] - Talks mainly about Art Resources, in question Models, Textures, Facemorphs, etcetc
*[[2DA]] - Talks about the 2DA Resourcetype, which is sets of Gamewide usable variables and references.
*etc

=== Tips and tricks ===
*[[Shortcuts]] - Assorted toolset shortcuts.
*[[Common Problems]] - Little things that most people will need to know but that are not necessarily obvious.

== Specials ==

[[Deleting a module]] - This is currently not possible by normal means.

If you run into a problem that the documentation doesn't cover and that you can't fix, contact toolsetsupport@bioware.com

2DA

2010-01-31T08:32:19Z

Craig Graff: /* Users of Open Office */

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. Each 2DA is simply an organized collection of strings and numbers. The specific function of each 2DA depends on how it is used by other systems in the game.

__TOC__
== Overview - what is a 2DA? ==

A 2DA contains a set of columns, with each column having a fixed label and a fixed data type. For example, the ABI_Base 2DA has a column that is labeled "namestrref" and has the data type "int". This means that the data stored in this column must be an integer and that the data stored in this column can be retrieved by referring to the label "namestrref". The number and types of columns in a 2DA does not usually ever change. The columns provide the structure of the 2DA that allows it to be referred to and used in a consistent manner. The first column of every 2DA is always labeled "ID" and is always of type "integer". This column is used to uniquely identify the rows in the 2DA.

A 2DA's rows are what contain the data being stored in it. Each row's columns have the same set of labels and data types (as defined at the top of the 2DA) but the data contained within them can be different. Adding new rows to a 2DA is common and easy; you just need to give it a new ID number in the "ID" column and then fill in the rest of the cells with whatever information you need. Once you've given a row an ID number it generally never changes. The game also has a mechanism called "M2DAs" that allow rows to be added to existing 2DAs without having to edit the original file, see below for more detail.

Some 2DAs reference rows in other 2DAs. For example the ABI_Base 2DA has an integer column named "projectile", and each row can have an integer in that column that identifies a row in the PRJ_Base 2DA. These relationships are generally only defined in the scripts that use the 2DAs and are not inherent to the 2DAs themselves so you'll have to keep track of these things yourself.

== Excel file formatting ==

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

''See: [[compiling 2DAs]]'' - for several methods of how to perform this conversion, and where to put 2DAs.

{| border="2" cellpadding="5" cellspacing="0" width="700pt" align"left"
|+ '''Example Worksheet "Monsters"'''
| width="30pt" style="background-color:#808080" |'''ID'''
| width="30pt" style="background-color:#AFAFAF" |'''Label'''
| width="50pt" style="background-color:#AFAFAF" |'''Strenght'''
| width="50pt" style="background-color:#AFAFAF" |'''Name'''
| width="50pt" style="background-color:#AFAFAF" |'''ResourceExample'''
| width="50pt" style="background-color:#AFAFAF" |'''Scale'''
| width="50pt" style="background-color:#AFAFAF" |'''disabled'''
| width="50pt" style="background-color:#AFAFAF" |'''Commentexample'''
|-
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''resource'''''
| style="background-color:#AFAFAF" |'''''float'''''
| style="background-color:#AFAFAF" |'''''bool'''''
| style="background-color:#AFAFAF" |'''''comment'''''
|-
| style="background-color:#AFAFAF" |0
|INVALID
|****
|sometimes
|bioware said
|****
|****
|i stay unused
|-
| style="background-color:#AFAFAF" |1
|Evilmonster1
|23
|Abomination
|prp_barrel01
|1,0
|0
|totally evil
|-
| style="background-color:#AFAFAF" |2
|Evilmonster2
|34
|Shriek
|prp_bucket_01
|1,0
|1
|very bad
|}

Data in a 2DA is identified by a row number, with the first row (using ID zero) usually being reserved for internal use (undefined value, etc.) by convention. Each row has an arbitrary number of columns identified by strings. The grey fields in this example table are very specific to the 2DA, the white fields are arbitrary data which the Gameengine identifies for that 2DA.

The ID of a Row is the reference for the Game to access and link to them. As such they are unique across the 2DA, and any M2DA that extends it. The contents of each column is specific to the 2DA given, and arbitrary. When extending a 2DA, new ID's have to be given, and Columns have to be exactly the same.

=== Guidelines ===
*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.
*ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== Extending the game via M2DAs ==

{| border="2" cellpadding="5" cellspacing="0" width="700pt" align"left"
|+ '''Example Worksheet "MonstersCustom"'''
| width="30pt" style="background-color:#808080" |'''ID'''
| width="30pt" style="background-color:#AFAFAF" |'''Label'''
| width="50pt" style="background-color:#AFAFAF" |'''Strenght'''
| width="50pt" style="background-color:#AFAFAF" |'''Name'''
| width="50pt" style="background-color:#AFAFAF" |'''ResourceExample'''
| width="50pt" style="background-color:#AFAFAF" |'''Scale'''
| width="50pt" style="background-color:#AFAFAF" |'''disabled'''
| width="50pt" style="background-color:#AFAFAF" |'''Commentexample'''
|-
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''resource'''''
| style="background-color:#AFAFAF" |'''''float'''''
| style="background-color:#AFAFAF" |'''''bool'''''
| style="background-color:#AFAFAF" |'''''comment'''''
|-
| style="background-color:#AFAFAF" |2300000
|Evilmonster3
|32
|Wolf
|c_wolfa
|1,0
|0
|New Monster
|}

An "M2DA" is a "Multiple 2DA" that stacks a number of 2DAs into one larger table. They work much like single 2DA files except they can be patched or expanded later by adding another 2DA. 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. 2DAs are merged row by row, keyed on the ID column.

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.

Every M2DA used by the game is listed in M2DA_base ([[2DA_base.xls]]) and 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 start with, as the name is actually a prefix to the file. 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_".

Note that M2DA_base is itself an M2DA file and can be extended in the same manner.

*''This example 2DA "MonstersCustom" would be merged into the original 2DA "Monsters", if "Monsters" were one of the worksheets listed in the M2DA_base. ''

=== Reserved ID Ranges and overriding existing rows ===

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it. If you use an existing row ID in your M2DA you can override the existing row with new data. Note that this can be a useful mechanism in some situations, for example allowing you to override existing content without having to edit the original 2DAs directly.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

''See: [[compiling 2DAs#Afterwards|compiling 2DAs]]'' - for Information on where to place M2DA files to achieve the desired effect.

=== Bug with M2DA ===

It should be noted, that currently there is a bug with certain M2DA's, which prevents new ID's above 255 to work in the game. It is unclear which are affected, but most certainly it is [[ItemVariations.xls]] related. See [[Bug: High M2DA ID ranges might work in the toolset, but not in game|Bug report]].

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

[[List of 2DA XLS files]]

The source files for the 2DAs that came with the installed game can be found under the toolsets directory
<pre><Installdir>\Dragon Age\tools\Source\2DA\</pre>

== Users of Open Office ==
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gda file (e.g. placeable_types.gda). Alternately, upload your .xls file to Google Docs and then download the file as Excel format, then process the file with ExcelProcessor.exe.
* When editing existing xls files, it also works to leave the format as standard while saving the file. Open Office asks to change the file to its own spreatsheet format when saving a format other then its own, don't change the format and it should work. [Edit- And yet it doesn't seem to.]

== Adding Strings ==

{{needs review}}

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

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

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

'''Attention:'''

* The current version of the "ExelProcessor"-App is buggy as it can't hanlde INT values above 8388607! Many thanks to elys for figuring that out.
* Also note that the original toolset (v1.0) core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory if you are still using that version.

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

[[Category:2DAs]]

2DA

2010-01-31T08:31:52Z

Craig Graff: /* Users of Open Office */

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. Each 2DA is simply an organized collection of strings and numbers. The specific function of each 2DA depends on how it is used by other systems in the game.

__TOC__
== Overview - what is a 2DA? ==

A 2DA contains a set of columns, with each column having a fixed label and a fixed data type. For example, the ABI_Base 2DA has a column that is labeled "namestrref" and has the data type "int". This means that the data stored in this column must be an integer and that the data stored in this column can be retrieved by referring to the label "namestrref". The number and types of columns in a 2DA does not usually ever change. The columns provide the structure of the 2DA that allows it to be referred to and used in a consistent manner. The first column of every 2DA is always labeled "ID" and is always of type "integer". This column is used to uniquely identify the rows in the 2DA.

A 2DA's rows are what contain the data being stored in it. Each row's columns have the same set of labels and data types (as defined at the top of the 2DA) but the data contained within them can be different. Adding new rows to a 2DA is common and easy; you just need to give it a new ID number in the "ID" column and then fill in the rest of the cells with whatever information you need. Once you've given a row an ID number it generally never changes. The game also has a mechanism called "M2DAs" that allow rows to be added to existing 2DAs without having to edit the original file, see below for more detail.

Some 2DAs reference rows in other 2DAs. For example the ABI_Base 2DA has an integer column named "projectile", and each row can have an integer in that column that identifies a row in the PRJ_Base 2DA. These relationships are generally only defined in the scripts that use the 2DAs and are not inherent to the 2DAs themselves so you'll have to keep track of these things yourself.

== Excel file formatting ==

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

''See: [[compiling 2DAs]]'' - for several methods of how to perform this conversion, and where to put 2DAs.

{| border="2" cellpadding="5" cellspacing="0" width="700pt" align"left"
|+ '''Example Worksheet "Monsters"'''
| width="30pt" style="background-color:#808080" |'''ID'''
| width="30pt" style="background-color:#AFAFAF" |'''Label'''
| width="50pt" style="background-color:#AFAFAF" |'''Strenght'''
| width="50pt" style="background-color:#AFAFAF" |'''Name'''
| width="50pt" style="background-color:#AFAFAF" |'''ResourceExample'''
| width="50pt" style="background-color:#AFAFAF" |'''Scale'''
| width="50pt" style="background-color:#AFAFAF" |'''disabled'''
| width="50pt" style="background-color:#AFAFAF" |'''Commentexample'''
|-
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''resource'''''
| style="background-color:#AFAFAF" |'''''float'''''
| style="background-color:#AFAFAF" |'''''bool'''''
| style="background-color:#AFAFAF" |'''''comment'''''
|-
| style="background-color:#AFAFAF" |0
|INVALID
|****
|sometimes
|bioware said
|****
|****
|i stay unused
|-
| style="background-color:#AFAFAF" |1
|Evilmonster1
|23
|Abomination
|prp_barrel01
|1,0
|0
|totally evil
|-
| style="background-color:#AFAFAF" |2
|Evilmonster2
|34
|Shriek
|prp_bucket_01
|1,0
|1
|very bad
|}

Data in a 2DA is identified by a row number, with the first row (using ID zero) usually being reserved for internal use (undefined value, etc.) by convention. Each row has an arbitrary number of columns identified by strings. The grey fields in this example table are very specific to the 2DA, the white fields are arbitrary data which the Gameengine identifies for that 2DA.

The ID of a Row is the reference for the Game to access and link to them. As such they are unique across the 2DA, and any M2DA that extends it. The contents of each column is specific to the 2DA given, and arbitrary. When extending a 2DA, new ID's have to be given, and Columns have to be exactly the same.

=== Guidelines ===
*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.
*ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== Extending the game via M2DAs ==

{| border="2" cellpadding="5" cellspacing="0" width="700pt" align"left"
|+ '''Example Worksheet "MonstersCustom"'''
| width="30pt" style="background-color:#808080" |'''ID'''
| width="30pt" style="background-color:#AFAFAF" |'''Label'''
| width="50pt" style="background-color:#AFAFAF" |'''Strenght'''
| width="50pt" style="background-color:#AFAFAF" |'''Name'''
| width="50pt" style="background-color:#AFAFAF" |'''ResourceExample'''
| width="50pt" style="background-color:#AFAFAF" |'''Scale'''
| width="50pt" style="background-color:#AFAFAF" |'''disabled'''
| width="50pt" style="background-color:#AFAFAF" |'''Commentexample'''
|-
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''int'''''
| style="background-color:#AFAFAF" |'''''string'''''
| style="background-color:#AFAFAF" |'''''resource'''''
| style="background-color:#AFAFAF" |'''''float'''''
| style="background-color:#AFAFAF" |'''''bool'''''
| style="background-color:#AFAFAF" |'''''comment'''''
|-
| style="background-color:#AFAFAF" |2300000
|Evilmonster3
|32
|Wolf
|c_wolfa
|1,0
|0
|New Monster
|}

An "M2DA" is a "Multiple 2DA" that stacks a number of 2DAs into one larger table. They work much like single 2DA files except they can be patched or expanded later by adding another 2DA. 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. 2DAs are merged row by row, keyed on the ID column.

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.

Every M2DA used by the game is listed in M2DA_base ([[2DA_base.xls]]) and 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 start with, as the name is actually a prefix to the file. 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_".

Note that M2DA_base is itself an M2DA file and can be extended in the same manner.

*''This example 2DA "MonstersCustom" would be merged into the original 2DA "Monsters", if "Monsters" were one of the worksheets listed in the M2DA_base. ''

=== Reserved ID Ranges and overriding existing rows ===

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it. If you use an existing row ID in your M2DA you can override the existing row with new data. Note that this can be a useful mechanism in some situations, for example allowing you to override existing content without having to edit the original 2DAs directly.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

''See: [[compiling 2DAs#Afterwards|compiling 2DAs]]'' - for Information on where to place M2DA files to achieve the desired effect.

=== Bug with M2DA ===

It should be noted, that currently there is a bug with certain M2DA's, which prevents new ID's above 255 to work in the game. It is unclear which are affected, but most certainly it is [[ItemVariations.xls]] related. See [[Bug: High M2DA ID ranges might work in the toolset, but not in game|Bug report]].

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

[[List of 2DA XLS files]]

The source files for the 2DAs that came with the installed game can be found under the toolsets directory
<pre><Installdir>\Dragon Age\tools\Source\2DA\</pre>

== Users of Open Office ==
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gda file (e.g. placeable_types.gda). Alternately, upload your .xls file to Google Docs and then download the file as Excel format, then process the file with ExcelProcessor.exe.
* When editing existing xls files, it also works to leave the format as standard while saving the file. Open Office asks to change the file to its own spreatsheet format when saving a format other then its own, don't change the format and it should work. [Ed- And yet it doesn't seem to.]

== Adding Strings ==

{{needs review}}

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

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

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

'''Attention:'''

* The current version of the "ExelProcessor"-App is buggy as it can't hanlde INT values above 8388607! Many thanks to elys for figuring that out.
* Also note that the original toolset (v1.0) core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory if you are still using that version.

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

[[Category:2DAs]]

2DA

2010-01-24T22:04:54Z

Craig Graff: /* Users of Open Office */

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.

ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== 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 the [[2DA_base.xls]] file 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_candy" and "longsword_variationcandy" would work as M2DA worksheet names.

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

== Converting XLS files into 2DA files ==

In the "Dragon Age\tools\ResourceBuild\Processors" folder there is an executable named "ExcelProcessor.exe". This is the file that handles conversions from XLS to 2DA format. Below are described 3 ways in which this file may be used.

=== Drag & Drop Method ===

# Copy ExcelProcessor.exe and source .XLS files to a new directory (not explicitly neccessary, but advised)
# Select source .XLS files and drag them onto ExcelProcessor.exe
# Cut & Paste resulting .2DA files, which will be located in the same directory as the source .XLS files, to your desired location (usually to "My Documents\BioWare\Dragon Age\AddIns\yourmodulename\module\overrides\")

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

Here's an easy way to add a context (ie, right-click) 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:\Program Files\Dragon Age\tools\ResourceBuild\Processors\ExcelProcessor.exe" "%1" -outdir="C:\Documents and Settings\YOURNAME\My Documents\BioWare\Dragon Age\packages\core\override"</tt>
## For the Steam version, use the following: <tt>"C:\Program Files\Steam\steamapps\common\dragon age origins\tools\ResourceBuild\Processors\ExcelProcessor.exe" "%1" -outdir="C:\Documents and Settings\YOURNAME\My Documents\BioWare\Dragon Age\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.

[[File:Adding binarize 2da to Windows XP explorer.png|center|thumb|300px|An example of how setting this up in Windows XP looks]]

=== Using a .BAT file ===

The following method may work better for you 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.
*'''If you copied your new 2DA file in your Override directory while Dragon Age Game was running, you will need to exit to windows and re-run the game to let your changes to work.'''

== 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 to the official campaign ===
*[[PRCSCR]] - specifies scripts to run when an area or area list is loaded or entered.

== Adding Strings ==

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

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

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

'''Attention:'''

* The current version of the "ExelProcessor"-App is buggy as it can't hanlde INT values above 8388607! Many thanks to elys for figuring that out.
* Also note that the original toolset (v1.0) core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory if you are still using that version.

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

== Reserved ID Ranges ==

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

== Users of Open Office ==
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gda file (e.g. placeable_types.gda). Alternately, upload your .xls file to Google Docs and then download the file as Excel format, then process the file with ExcelProcessor.exe.

[[Category:2DAs]]

2DA

2010-01-07T21:54:47Z

Craig Graff: /* Adding Strings */

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.

ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== 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 the [[2DA_base.xls]] file is actually a prefix. The system reads this prefix and then searches through all the 2DAs for the ones starting with this prefix and merges them together as one 2DA. For example: M2DA Id 0 is "ANIM_". The system looks through its list of 2das and finds "ANIM_base", "ANIM_combat" and "ANIM_walk". It will read and merge all 3 2DAs into an M2DA called "ANIM_".

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

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

== Converting XLS files into 2DA files ==

In the "Dragon Age\tools\ResourceBuild\Processors" folder there is an executable named "ExcelProcessor.exe". This is the file that handles conversions from XLS to 2DA format. Below are described 3 ways in which this file may be used.

=== Drag & Drop Method ===

# Copy ExcelProcessor.exe and source .XLS files to a new directory (not explicitly neccessary, but advised)
# Select source .XLS files and drag them onto ExcelProcessor.exe
# Cut & Paste resulting .2DA files, which will be located in the same directory as the source .XLS files, to your desired location (usually to "My Documents\BioWare\Dragon Age\AddIns\yourmodulename\module\overrides\")

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

Here's an easy way to add a context (ie, right-click) 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:\Program Files\Dragon Age\tools\ResourceBuild\Processors\ExcelProcessor.exe" "%1" -outdir="C:\Documents and Settings\YOURNAME\My Documents\BioWare\Dragon Age\packages\core\override"</tt>
## For the Steam version, use the following: <tt>"C:\Program Files\Steam\steamapps\common\dragon age origins\tools\ResourceBuild\Processors\ExcelProcessor.exe" "%1" -outdir="C:\Documents and Settings\YOURNAME\My Documents\BioWare\Dragon Age\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.

[[File:Adding binarize 2da to Windows XP explorer.png|center|thumb|300px|An example of how setting this up in Windows XP looks]]

=== Using a .BAT file ===

The following method may work better for you 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 to the official campaign ===
*[[PRCSCR]] - specifies scripts to run when an area or area list is loaded or entered.

== Adding Strings ==

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

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

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

'''Attention:'''

* The current version of the "ExelProcessor"-App is buggy as it can't hanlde INT values above 8388607! Many thanks to elys for figuring that out.
* Also note that the original toolset (v1.0) core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory if you are still using that version.

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

== Reserved ID Ranges ==

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

== Users of Open Office ==
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gda file (e.g. placeable_types.gda).

[[Category:2DAs]]

Follower tutorial

2010-01-06T17:29:02Z

Craig Graff: /* Why don't my followers gain XP? */

== Simple Follower Creation ==

Follow these steps to create a follower that

- Levels up with a default package

- Can be chosen from the party picker

- Can gain XP

This guide assumes you know how to create a creature and are comfortable with basic scripting.

You should only use this simple method if you are sure there will be empty space in the active party when your follower is recruited.

=== Create the creature ===

Create a creature to act as your follower. Set its name, appearance, gender, head morph, conversation, inventory etc as you want them to behave in-game.

Set an appropriate '''Tag''' (you'll be using it a lot). I suggest "party_charname".

Make sure you choose a '''Class'''. For most followers this should be Rogue, Warrior or Wizard.

[[File:class.jpg]]

Under Package/Scaling set:

'''General Package Type''' to be '''Party Members'''

'''Package''' to be an appropriate value (probably "Generic - Wizard" or similar)

'''Package AI''' (there should only be one choice)

'''Rank''' to be '''Player'''

[[File:package.jpg]]

Save and export your character as normal.

=== Override char_stage ===

In your resource palette, open char_stage under the Global folder:

[[File:area_palette.jpg]]

Create a new waypoint for your follower to appear on the party picker. This waypoint '''must''' have a tag in the form of "char_" followed by the exact tag of your follower.

[[File:char_stage.jpg]]

In this example the tag of my follower is '''bc_party_miera''' so her waypoint tag must be '''char_bc_party_miera'''

For a standalone module (such as in this example), put your waypoint wherever you please. The illustrated one is directly on top of Morrigan's. For an add-in to the main campaign, you should position your wp appropriately relative to the core party members.

Save and export the area.

Move the '''char_stage.are''' and '''char_stage.lst''' files from your core export folder to your module's export folder (probably from \Documents\Bioware\Dragon Age\packages\core\override\toolsetexport to \Documents\Bioware\Dragon Age\AddIns\yourModule\module\override\toolsetoverride). This ensures that the modification to the character stage only takes effect if your module is installed and enabled, which will help manage compatibility problems. Make sure those files are included when you package your module for distribution.

=== Create m2DAs for the Party Picker ===

You will need to create two Excel spreadsheets.

The first should be named (both worksheet and file) '''partypicker_''' with a unique suffix. In this example, my first spreadsheet is named partypicker_fofbc.xls with a worksheet name of partypicker_fofbc - the suffix being the acronym of my module.

Set up your columns as follows:

[[File:partypickerm2da.jpg]]

The '''ID''' for your follower must be '''12 or higher'''. 11 is the highest value used in the base 2DA. 12 is fine for standalone modules, add-ins will probably want to use an arbitrarily high number to avoid potential conflicts.

The '''Label''' should be the follower's name as you wish it to appear on the party picker.

The '''Tag''' must be your follower's tag.

All other values are non-functioning defaults and should be specified as in the image above unless you know explicitly what you're doing.

The second spreadsheet should be named '''party_picker_''' (note middle underscore). Once again append your unique suffix (in this example party_picker_fofbc.xls with party_picker_fofbc as its worksheet).

Set up your columns and data like so:

[[File:party_pickerm2da.jpg]]

'''ID''' and '''Tag''' should match what you did in the first spreadsheet. Specify INVALID COLUMN for the third column.

If you're familiar with m2DAs, generate them from these files, copy them to your module's override directory, and skip to the next step. Otherwise, read on:

- Go to '''\Program Files\Dragon Age\tools\ResourceBuild\Processors''' (or wherever you installed Dragon Age)

- Copy '''ExcelProcessor.exe''' from that folder to whichever folder has the excel sheets you just created.

- Drag and drop your xls files onto ExcelProcessor. This will create .gda files.

- Copy these .gda files to your module's export directory (probably \Documents\Bioware\Dragon Age\AddIns\yourModule\module\override\toolsetoverride). Make sure they are included in your .dazip when the time comes to build your module.

If you are an OpenOffice user and have trouble with ExcelProcessor, you can use [http://social.bioware.com/project/755/ GDApp] to directly create the 2DAs. It rocks!

=== Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event ===

Amusingly enough, the Party Picker does not actually add followers to the party. However it raises an event that allows you to do so. Your module script needs to capture this event and execute some code.

The following example shows what to do with the event. The full script would work as a module script for an add-in (assuming it didn't need to do anything else), but otherwise you'll have to incorporate the event into your own script:

<pre>

#include "utility_h"

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); //Allows the follower to gain XP
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); //Adds follower to the active party
break;
}

}
}

</pre>

'''SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE)''' is the key statement to add the follower to the active party. You must have this.

'''SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0)''' is a bug-fix, as followers hired with UT_HireFollower() do not receive XP by default. This statement fixes that, and I consider it best practice to keep it in this event to ensure it is always set. You will not wish to do this if you want a follower that should not gain XP to be on the party picker.

Note that you do not need to intercept the corresponding event for a party member being removed - the party picker handles spawning/despawning, and thus will successfully remove members.

Remember to save and export your module script.

=== Create Your Hiring Script ===

Now all that remains is to actually hire the follower :)

Create a script to handle the hiring (which will most likely be fired from a conversation). The script is quite simple:

<pre>

#include "utility_h"

void main() {

object oFollower = GetObjectByTag("bc_party_miera"); //Use CreateObject() if the creature isn't present in the module yet

UT_HireFollower(oFollower); //Hires the follower

SetPartyPickerGUIStatus(2);

ShowPartyPickerGUI(); //Shows the Party Picker; necessary for the follower to gain XP

}
</pre>

Make sure you use your own follower's tag and not the example one :)

This script fires the party picker after hiring the follower. That is absolutely necessary via this method, as we have put the XP fix onto an event fired by the party picker. You cannot put the XP fix into this script, it must be called from a later one (the bug is caused by an errant call to an event in player_core, which will be executed AFTER this script).

If everything worked, you should see something like this:

[[File:picker_success.jpg|thumb|200px|center]]

== Advanced Follower Creation ==

Follow these steps to have full control over the creation of your follower, with options such as:

- Unique level-up template

- Class and specialisation chosen via script

- Any starting state

- Level higher than the PC

- Starts with a specialisation point rather than a specific specialisation

- Set plot flags in the call to the hire script

=== Prepare Creature, char_stage and Party Picker m2DAs ===

Follow the same steps to create your create your follower creature, override char_stage and create your Party Picker m2DAs as above.

=== Create Party Plot ===

While not necessary, it's very helpful to have plot flags set when a follower is hired or joins/leaves the active party. This makes conversation interjections and the like very easy.

Create a plot with appropriate flags. There's no real need to associate journal text with them:

[[File:follower_plot.jpg]]

=== Add Plot Flags to Party Picker Event Intercept ===

We then update our module script to make use of that plot, like so:

<pre>
#include "utility_h"
#include "wrappers_h"
#include "plt_bc_create_party" //make sure you include your own plot, not mine

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);

if (GetTag(oFollower) == "bc_party_miera") { //You must explicitly test for your follower's tag.
WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, TRUE); //Make sure you use your own flags!
}

break;
}

case EVENT_TYPE_PARTYMEMBER_DROPPED:
{
object oFollower = GetEventObject(ev, 0);

if (GetTag(oFollower) == "bc_party_miera") {
WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, FALSE); //As above, but set false.
}

}

}
}

</pre>

=== Create a Level Up Template ===

You can skip this step if you're content to use one of the generic Rogue, Wizard or Warrior templates, but I don't recommend it. Making a template that suits your character is easy and will almost always be better for the player than a generic one that spends points poorly.

Go to \Program Files\Dragon Age\tools\Source\2DA (or wherever you installed Dragon Age).

You should see a number of excel sheets of the form '''ALCharacter.xls''' (such as ALAlistair.xls, ALLeliana.xls, ALRogue_Default.xls etc). Open the one closest to your character (ie Morrigan or Wynne for a wizard, Leliana or Zevran for a rogue). Save a copy as '''ALYourcharacter.xls''' in whatever directory you're using to create your 2DAs, remembering to rename the worksheet '''ALYourcharacter''' (in this example, ALMiera.xls with ALMiera as its worksheet).

It should look something like this:

[[File:ALtable.jpg|thumb|500px|center]]

'''Columns B''' and '''C''' are the talents/spells available to this character. Do not change them.

'''Columns F''' and '''G''' are the skills available to this character. Do not change them.

We will edit the remaining columns like so:

==== Setting Stat Weights ====

The stat weights in '''column J''' determine how the follower will spend their attribute points, in a rough ratio. So if Dexterity is set to 1.5 and Intelligence to 1, you should expect to see 3 points of Dex for every 2 points of Cunning in-game (note Intelligence is the label used in the toolset for Cunning).

Simply change the values in J to reflect how you'd like the character to spend their points. In this example we're creating a wizard, so we're not going to mess around:

[[File:miera_stat_weights.jpg]]

This character will only raise magic. I set the value to 5 rather than something like 1 to provide room underneath for the other stats while still overwhelmingly favouring magic, but in practice I only really ever want that one stat.

==== Setting Talent and Skill Priorities ====

'''Columns D''' and '''E''' are the talents/spells that the character will buy, in preference order from top to bottom.

'''Columns H''' and '''I''' are the skills available to this character, in preference order from top to bottom.

To change these, just copy the appropriate two cells from columns B&C or F&G over the ones you want to replace.

For example, here we're copying Morrigan's template. Morrigan has Spider Shape high in her preferences, which we do not want.

[[File:AlMori_talent_pref.jpg]]

We decide we'd prefer Flame Blast, so we find it in columns B&C and copy both cells:

[[File:ALMori_copy.jpg]]

Then we select the cells we want to replace in columns D&E and paste over them:

[[File:ALMori_paste.jpg]]

Continue this process until your priorities list for both skills and talents/spells is exactly as you want it. Make sure you have at least as many priorities as the core follower you're copying - points that cannot be spent according to these priorities have a habit of vanishing.

If you used any abilities from a specialisation, make sure you remember to set that specialisation with the function we'll introduce later. The autolevel scripts will add specialisation abilities to a character regardless of whether they have that spec or not.

==== Create a M2DA_base_ m2DA ====

Dragon Age will need to know where to find your autolevel template. We tell it by extending M2DA_base.gda

Create a spreadsheet with the name and worksheet name in the form '''M2DA_base_''' with your unique suffix (in this example, M2DA_base_fofbc.xls with M2DA_base_fofbc as a worksheet).

Set up its columns and data like so (note I used GDApp because Open Office wasn't cooperating for this one!):

[[File:m2da_base_fofbc.jpg]]

The '''ID''' should be very high to avoid conflicts. I've arbitrarily chosen 50,000+ here. Carefully note the ID you've chosen for your character, you will need it later.

Set the '''Label''' and '''Worksheet''' to be the name of your autolevel template worksheet (ALCharactername if you've been following this).

Set the '''PackageIDForAI''' to be 0, it shouldn't be needed for followers.

When you're done, use ExcelProcessor to make GDAs of both spreadsheets and copy them to your module's export folder.

=== Create a New Hire Function Include ===

Many vital steps of follower addition happen inside an event in player_core. Followers tend to be extremely buggy (no skill tree, for example) if this event does not fire.

However, that event is not very flexible. In order to control it to our requirements, we need to replicate its functionality inside our own script. This is probably much safer than messing with player_core directly!

Create a new script file, naming it something like '''hireCustomFollower_h'''. We will be including this wherever we want to hire a follower.

Paste in the following script:

<pre>

#include "sys_chargen_h"
#include "wrappers_h"
#include "utility_h"
#include "sys_rewards_h"
#include "approval_h"
#include "sys_autolevelup_h"

/* Jye Nicolson 5-Jan-2010

This function set duplicates the full functionality chain of UT_HireFollower, with the following exceptions:

- Followers can gain XP
- Autolevel status can be set (default off)
- Followers can be set to any starting state (default Available) and will still be properly initalised and added to the party pool
- Autolevel tables for non-core followers can be explicitly set.
- Class and Specialisation can be chosen via script
- Followers without specialisations are granted a spec point by default.

It should only ever be called once each for characters you intend to be full followers.
Much of the protective code handling summoned creatures etc. in player_core is not present here.

Calling the function:

Simple:

hireCustomFollower(oFollower, CLASS_WARRIOR);

Change the class to CLASS_WIZARD or CLASS_ROGUE as appropriate.
This will hire your follower and make them available.
They will auto level up with a default package, and receive a free spec point.

Best Practice:

hireCustomFollower(oFollower, CLASS_WARRIOR, PLT_YOUR_PARTY_PLOT, YOUR_FOLLOWER_JOINED_FLAG, ABILITY_TALENT_HIDDEN_CHAMPION);

Where the plot and flag are those for your module (remember to create the plot and include it on the calling script), and ABILITY_TALENT_HIDDEN etc is the desired spec.

You should also have a custom ALTable set up.
See wiki for details, and remember to edit it in to GetCustomFollowerALTable below or pass it directly as an argument to hireCustomFollower.

Full argument list:

void hireCustomFollower (
object oFollower, //Pass your follower object, mandatory

int nForceClass, //Pass a Class constant here, usually CLASS_ROGUE, CLASS_WARRIOR, CLASS_WIZARD. Mandatory due to a bug.

string sPlot = "", //It's recommended you have a plot flag to be set when the follower joins. Pass the plot constant here. Remember to #include in calling script

int nPlotFlag = "", //And then pass the flag constant. Will be set to TRUE if available.

int nForceSpec = 0, //This is the ID of the Specialisation you want. Note they are NOT classes, but abilities. The full list is:
//ABILITY_SPELL_HIDDEN_ARCANE_WARRIOR, ABILITY_SPELL_HIDDEN_BLOODMAGE, ABILITY_SPELL_HIDDEN_SHAPESHIFTER, ABILITY_SPELL_HIDDEN_SPIRIT_HEALER
//ABILITY_SPELL_HIDDEN_BARD, ABILITY_TALENT_HIDDEN_ASSASSIN, ABILITY_TALENT_HIDDEN_DUELIST, ABILITY_TALENT_HIDDEN_RANGER
//ABILITY_TALENT_HIDDEN_BERSERKER, ABILITY_TALENT_HIDDEN_CHAMPION, ABILITY_TALENT_HIDDEN_REAVER, ABILITY_TALENT_HIDDEN_TEMPLAR
//I recommended forcing a spec, particularly if your ALTable includes abilities from one.

int nALTable = 0, //This is the ID of an ALTable from 2DA_base.GDA or your module's m2DA_base_*.GDA I recommended the latter, but you can edit that into GetCustomFollowerALTable below rather than passing it.

int bInvokePicker = FALSE, //Sets whether the party picker should be opened on hiring. I think it's cleaner to call the picker outside this script, particularly if you have multiple hires at once.

int nInitialState = FOLLOWER_STATE_AVAILABLE, //This sets whether the follower joins the active party or not. Options are:
//FOLLOWER_STATE_ACTIVE (put them in the active party)
//FOLLOWER_STATE_LOCKEDACTIVE (force them into the active party and keep them there, remember to change this later.
//FOLLOWER_STATE_AVAILABLE (make them available on the party picker (if you've set it up for them), but not in the active party)
//Plus some others you're unlikely to need at this time. Defaults to AVAILABLE because having 4+ active followers is screwy.

string sCurrPlot = "", //If you set FOLLOWER_STATE_ACTIVE or FOLLOWER_STATE_LOCKEDACTIVE, the script will check to see if you passed this.
//It is recommended that you have a plot flag set for a given follower being in the active party, this makes conversation interjection etc. much easier.

int nCurrPlotFlag = 0, //This flag will be set if FOLLOWER_STATE_ACTIVE or FOLLOWER_STATE_LOCKEDACTIVE are true
//AND sCurrPlot has a value AND nCurrPlotFlag is > 0.
//ie if you added someone to the active party and have a plot flag to cope with it.

int nAutolevel = 0, //Sets the Autolevel flag on the character sheet. 0 is off, 1 is on, 2 forces it on and removes it so the player can't turn it off.

bFreeSpecPoint = TRUE, //This grants a specialisation point to the follower if they do not have a specialisation.
//It's important to set this false for classes that do not have specs, such as CLASS_DOG.

int nTargetLevel = 0, //If you want a specific level, set this. Generally not worthwhile unless you set it higher than the player, since they'll just get XP from the party picker anyway.

int nMinLevel = 0 //Set this if there's a specific level you don't want the follower to go below. Probably only useful if the PC might be very low level but not necessarily so.

)

*/

/* GetCustomFollowerALTable()

This function is where you put your custom table assignments.

You should explicitly test for the tag of your follower (not mine!) and assign a value to nTable from your m2DA extension to M2DA_base

See wiki for details on how to do this, or ignore it to get the default Warrior/Rogue/Wizard AL tables.

NOTE: you MUST explicitly set a table for non-Warrior/Rogue/Wizards, eg dogs. Use TABLE_AL_DOG for a default Mabari.

*/

int GetCustomFollowerALTable(object oFollower) {
int nTable = _GetTableToUseForAL(oFollower);

if (GetTag(oFollower) == "bc_party_miera") {
nTable = 50143;
}

if (GetTag(oFollower) == "bc_party_jysavin") {
nTable = 50144;
}

if (GetTag(oFollower) == "bc_party_geldual") {
nTable = 50145;
}

if (GetTag(oFollower) == "bc_party_braghon") {
nTable = 50146;
}

return nTable;

}

// This just cleans up the main function a little

int GetCustomFollowerTargetLevel(object oFollower, object oHero, int nPackage, int nMinLevel = 0) {
int nPlayerLevel = GetLevel(oHero);
int nTargetLevel = 0;

if((nPlayerLevel >= 13) || (nPlayerLevel == 1) || (!_UT_GetIsPlotFollower(oFollower))) {
nTargetLevel = nPlayerLevel;
} else {
nTargetLevel = nPlayerLevel + 1;
}

if (nMinLevel == 0) { //If nMinLevel is not specified, checks package 2DA for a value
nMinLevel = GetM2DAInt(TABLE_PACKAGES, "MinLevel", nPackage);
}
if(nMinLevel > 0 && nMinLevel > nTargetLevel) {
nTargetLevel = nMinLevel;
}

return nTargetLevel;

}

// Moving this black box out :) I don't really understand it, but it should function if you have tactics set up in a package.

void InitCustomFollowerTactics(object oFollower, int nPackage) {
int nTableID = GetM2DAInt(TABLE_PACKAGES, "FollowerTacticsTable", nPackage);
if (nTableID != -1)
{
int nRows = GetM2DARows(nTableID);
int nMaxTactics = GetNumTactics(oFollower);

int nTacticsEntry = 1;
int i;
for (i = 1; i <= nRows && nTacticsEntry <= nMaxTactics; ++i)
{
int bAddEntry = FALSE;
int nTargetType = GetM2DAInt(nTableID, "TargetType", i);
int nCondition = GetM2DAInt(nTableID, "Condition", i);
int nCommandType = GetM2DAInt(nTableID, "Command", i);
int nCommandParam = GetM2DAInt(nTableID, "SubCommand", i);

int nUseType = GetM2DAInt(TABLE_COMMAND_TYPES, "UseType", nCommandType);
if (nUseType == 0)
{
bAddEntry = TRUE;
}
else
{
bAddEntry = HasAbility(oFollower, nCommandParam);
}

if (bAddEntry)
{
SetTacticEntry(oFollower, nTacticsEntry, TRUE, nTargetType, nCondition, nCommandType, nCommandParam);
++nTacticsEntry;
}
}
}
}

/* InitCustomFollowerSpec:

This function tries to set the forced Specialisation. If there is none, it checks the package for one.

If there isn't either of those, it grants a free spec point if bFreeSpecPoint is true.

*/

void InitCustomFollowerSpec(object oFollower, int nPackage, int nForceSpec, int bFreeSpecPoint) {
// Find specialization, and optionally add a spec point if none is found.

if (nForceSpec == 0) {

int nSpecAbility = GetM2DAInt(TABLE_PACKAGES, "switch1_class", nPackage); // followers can have only 1 advanced class
if(nSpecAbility > 0)
{
AddAbility(oFollower, nSpecAbility);
} else {
if (bFreeSpecPoint) {
SetCreatureProperty(oFollower, 38, 1.00);
}
}

} else {

AddAbility(oFollower, nForceSpec);

}
}

/* hireCustomFollower() (See doco at top of page)

I strongly suggest you reorder the parameters if you're adding many followers with advanced options.

Feel free to leave them alone if you only want to set class, plot, spec or don't mind long declarations.

Note nForceClass is currently compulsory due to flakiness with GetCreatureCoreClass()

*/

void hireCustomFollower(object oFollower, int nForceClass, string sPlot = "", int nPlotFlag = 0, int nForceSpec = 0, int nALTable = 0, int bInvokePicker = FALSE, int nInitialState = FOLLOWER_STATE_AVAILABLE, string sCurrPlot = "", int nCurrPlotFlag = 0, int nAutolevel = 0, int bFreeSpecPoint = TRUE, int nTargetLevel = 0, int nMinLevel = 0) {

object oHero = GetHero();

/* ################# BEGIN BASIC FOLLOWER JOIN BLOCK ###################

This loosely replicates WR_SetFollowerState.

*/

if (nForceClass == 0) {
nForceClass = GetCreatureCoreClass(oFollower); //This is not working. Hence nForceClass mandatory.
}

SetGroupId(oFollower, GetGroupId(oHero)); //Puts the follower in the pc's Group.
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE); //This makes them act like a player.
SetFollowerState(oFollower, nInitialState); //This sets whether they are available, in the active party etc.

/* ################# END BASIC FOLLOWER JOIN BLOCK ##################### */

/* ################# BEGIN PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION #################

This replicates the EVENT_TYPE_PARTY_MEMBER_HIRED handler from player_core, stripped down for simplicity and allowing our custom options.

*/

Chargen_EnableTacticsPresets(oFollower); //I assume this is important.

SetLocalInt(oFollower, FOLLOWER_SCALED, 1); //This should prevent the follower being rescaled by player_core or what have you

int nPackage = GetPackage(oFollower); //Gets the package, which will be used to find a number of 2DA IDs.
int nPackageClass = GetM2DAInt(TABLE_PACKAGES, "StartingClass", nPackage); //I don't think this is used, even by player_core

// set behavior according to package
int nBehavior = GetM2DAInt(TABLE_PACKAGES, "FollowerBehavior", nPackage);

if(nBehavior >= 0) {
SetAIBehavior(oFollower, nBehavior);
}

Chargen_InitializeCharacter(oFollower); //We initialise the follower and choose race/class.

Chargen_SelectRace(oFollower,GetCreatureRacialType(oFollower));
Chargen_SelectCoreClass(oFollower,nForceClass);

if (nTargetLevel == 0) { //This block picks a target level if not specified

nTargetLevel = GetCustomFollowerTargetLevel(oFollower, oHero, nPackage, nMinLevel);
}

int nXp = RW_GetXPNeededForLevel(Max(nTargetLevel, 1)); //Here is where the XP is calculated and rewarded
RewardXP(oFollower, nXp, FALSE, FALSE);

// -------------------------------------------------------------
// add hidden approval talents - (JN: I don't know how to set these yet, but when I figure it out this should make it work)
// -------------------------------------------------------------
int nIndex = Approval_GetFollowerIndex(oFollower);
Approval_AddFollowerBonusAbility(nIndex, 0);

//Handle Specialisation
InitCustomFollowerSpec(oFollower, nPackage, nForceSpec, bFreeSpecPoint);

// -------------------------------------------------------------
// This spends all available attribute and stat points on the
// creature according to the levelup table. (JN: this replicates AL_DoAutoLevelUp but with our choice of table)
// -------------------------------------------------------------

if (nALTable == 0) {
nALTable = GetCustomFollowerALTable(oFollower);
}

AL_SpendAttributePoints(oFollower, nALTable, FALSE);
AL_SpendSkillPoints(oFollower, nALTable, TRUE);
AL_SpendSpecializationPoints(oFollower, nALTable);
AL_SpendTalentSpellPoints(oFollower, nALTable, TRUE);

// -------------------------------------------------------------------------
// Update various UIs
// -------------------------------------------------------------------------
Chargen_SetNumTactics(oFollower);
SetCanLevelUp(oFollower,Chargen_HasPointsToSpend(oFollower));

// load tactics
InitCustomFollowerTactics(oFollower, nPackage);

/* ################# END PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION ################# */

SetAutoLevelUp(oFollower, nAutolevel); //This is the autolevel flag on the character sheet.

//Set plot flags

if (!((sPlot == "") || (nPlotFlag == 0))) { //Joined Party
WR_SetPlotFlag(sPlot, nPlotFlag, TRUE);
}

if ((nInitialState == FOLLOWER_STATE_ACTIVE) || (nInitialState == FOLLOWER_STATE_LOCKEDACTIVE)) {
if (!((sCurrPlot == "") || (nCurrPlotFlag == 0))) {
WR_SetPlotFlag(sCurrPlot, nCurrPlotFlag, TRUE); //Currently in Party
}
}

// Invoke picker if requested.

if (bInvokePicker) {
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();

}

}

</pre>

Yeah, I know. It can't really be any smaller. Feel free to modify it if you're confident with scripting.

==== Add Your Custom Autolevel Template to GetCustomFollowerALTable() ====

While you can pass the ID you made for your autolevel template to that monster function as an argument, it's better to have them all in one place if you have multiple followers.

GetCustomFollowerALTable() is the first function in our include, and you can add an explicit if test for your follower there to assign the correct table id (the one from your M2DA_base_ m2DA). There is a function very much like it in sys_autolevel_h.nss for the core followers, so we'll copy Bioware's practice.

Let's take a look at the function by itself:

<pre>
int GetCustomFollowerALTable(object oFollower) {
int nTable = _GetTableToUseForAL(oFollower);

if (GetTag(oFollower) == "bc_party_miera") {
nTable = 50143;
}

if (GetTag(oFollower) == "bc_party_jysavin") {
nTable = 50144;
}

if (GetTag(oFollower) == "bc_party_geldual") {
nTable = 50145;
}

if (GetTag(oFollower) == "bc_party_braghon") {
nTable = 50146;
}

return nTable;

}
</pre>

So we have a test for each follower tag from my module, matching up to an ID which is assigned to nTable. All you need to do is change a tag from my follower to yours, and my ID to the correct one from your M2DA_base_* m2DA. Then you should delete the rest of the example if statements :)

Save and export the script. Ignore the compiler error about lack of main();

=== Include Function In Your Hire Script and Call It ===

So instead of a hire script that calls UT_HireFollower(), we want one that includes our shiny new function and calls it.

Take a look at the following example:

<pre>

#include "plt_bc_create_party" //Make sure you include your party handling plot
#include "hireCustomFollower_h" // And include the function script - which will in turn include a bunch of stuff

void main() {

//Initialising my objects, not super-relevant to the example

object oHero = GetHero();
object oMiera = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_miera.utc", GetLocation(oHero));
object oJysavin = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_jysavin.utc", GetLocation(oHero));
object oBraghon = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_braghon.utc", GetLocation(oHero));
object oSpider = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_geldual.utc", GetLocation(oHero));

//Simplest hire call - adds to the party as a wizard. Class is currently compulsory due to a bug.

hireCustomFollower(oMiera, CLASS_WIZARD);

//Add to the party and set joining plot flags

hireCustomFollower(oJysavin, CLASS_WARRIOR, PLT_BC_CREATE_PARTY, PARTY_JYSAVIN_JOINED);

//Add to the party, set plot flags, force a specialisation

hireCustomFollower(oBraghon, CLASS_ROGUE, PLT_BC_CREATE_PARTY, PARTY_BRAGHON_JOINED, ABILITY_TALENT_HIDDEN_ASSASSIN);

//More complex example - Follower added as a unique class (Dog), not granted a specialisation or spec point.
//Note unique classes must have an ALTable passed here or specified in GetCustomFollowerALTable() or they won't work

hireCustomFollower(oSpider, CLASS_DOG, PLT_BC_CREATE_PARTY, PARTY_GELDUAL_JOINED, 0, 0, FALSE, FOLLOWER_STATE_AVAILABLE, "", 0, 0, FALSE);

//Show the party picker to let the player choose from their new companions!

SetPartyPickerGUIStatus(2);

ShowPartyPickerGUI();

}

</pre>

The example shows several of the more simple ways of invoking the function. Check the comments at the start of the function for a full list of arguments.

I would suggest best practice for most followers would be to call as follows:

'''hireCustomFollower(oFollower, CLASS, PLOT, PLOT_FLAG, SPECIALISATION)'''

This will safely set the follower up as the desired class and specialisation (doubly important if there are spec abilities in their ALTable) while setting your plot flag for them being in the party. hireCustomFollower(oFollower, CLASS, PLOT, PLOT_FLAG, SPECIALISATION, 0, TRUE) will do the same while invoking the Party Picker automatically.

Note that the specialisations are abilities and not classes - you'll find them as ABILITY_HIDDEN_ constants.

If it's all worked, you should find you can now add followers with a lot more flexibility!

[[File:picker_advanced.jpg|thumb|500px|center]]

== Common Follower Problems & FAQ ==

====Why don't my followers gain XP?====
There is a bug in UT_HireFollower. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
(Note: Be aware if you use the name UT_HireFollower_Fixed you may end up finding your include file conflicting with someone else who has named it the same in their include.)

Alternately you need to clear a flag in a separate script to the one in which they're hired.

You must use the '''SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);''' statement in a script you can be sure will run soon after your hiring script.

====When I choose followers from the Party Picker, they spawn into the area but do not join.====

You need to intercept the EVENT_TYPE_PARTYMEMBER_ADDED event and set the follower to FOLLOWER_STATE_ACTIVE. See Simple Follower Creation earlier in this document.

====My followers don't have skill trees!====

If a follower hasn't been through an initial chargen/autolevel event (via player_core/sys_autolevel_h) then the skill tree doesn't show. You're probably trying to be clever and get around UT_HireFollower without going all the way (see monster function above ^_^).

====My followers don't have a class====

GetCreatureCoreClass() seems flaky under some conditions. It's best to explicitly set the class yourself; this is why class is currently a mandatory argument to hireCustomFollower()

====Isn't there an easier way to do this?====

Possibly. There is a way of recruiting a follower by setting a plot flag. However I don't understand it, and I expect it still doesn't allow custom autolevel templates, full control over specialisations etc. There's still a fair bit of stuff hardcoded for the core followers, I'm not sure putting a custom follower through the same process as Al, Leli et al will have good results.

Follower tutorial

2010-01-06T17:19:15Z

Craig Graff: /* Why don't my followers gain XP? */

== Simple Follower Creation ==

Follow these steps to create a follower that

- Levels up with a default package

- Can be chosen from the party picker

- Can gain XP

This guide assumes you know how to create a creature and are comfortable with basic scripting.

You should only use this simple method if you are sure there will be empty space in the active party when your follower is recruited.

=== Create the creature ===

Create a creature to act as your follower. Set its name, appearance, gender, head morph, conversation, inventory etc as you want them to behave in-game.

Set an appropriate '''Tag''' (you'll be using it a lot). I suggest "party_charname".

Make sure you choose a '''Class'''. For most followers this should be Rogue, Warrior or Wizard.

[[File:class.jpg]]

Under Package/Scaling set:

'''General Package Type''' to be '''Party Members'''

'''Package''' to be an appropriate value (probably "Generic - Wizard" or similar)

'''Package AI''' (there should only be one choice)

'''Rank''' to be '''Player'''

[[File:package.jpg]]

Save and export your character as normal.

=== Override char_stage ===

In your resource palette, open char_stage under the Global folder:

[[File:area_palette.jpg]]

Create a new waypoint for your follower to appear on the party picker. This waypoint '''must''' have a tag in the form of "char_" followed by the exact tag of your follower.

[[File:char_stage.jpg]]

In this example the tag of my follower is '''bc_party_miera''' so her waypoint tag must be '''char_bc_party_miera'''

For a standalone module (such as in this example), put your waypoint wherever you please. The illustrated one is directly on top of Morrigan's. For an add-in to the main campaign, you should position your wp appropriately relative to the core party members.

Save and export the area.

Move the '''char_stage.are''' and '''char_stage.lst''' files from your core export folder to your module's export folder (probably from \Documents\Bioware\Dragon Age\packages\core\override\toolsetexport to \Documents\Bioware\Dragon Age\AddIns\yourModule\module\override\toolsetoverride). This ensures that the modification to the character stage only takes effect if your module is installed and enabled, which will help manage compatibility problems. Make sure those files are included when you package your module for distribution.

=== Create m2DAs for the Party Picker ===

You will need to create two Excel spreadsheets.

The first should be named (both worksheet and file) '''partypicker_''' with a unique suffix. In this example, my first spreadsheet is named partypicker_fofbc.xls with a worksheet name of partypicker_fofbc - the suffix being the acronym of my module.

Set up your columns as follows:

[[File:partypickerm2da.jpg]]

The '''ID''' for your follower must be '''12 or higher'''. 11 is the highest value used in the base 2DA. 12 is fine for standalone modules, add-ins will probably want to use an arbitrarily high number to avoid potential conflicts.

The '''Label''' should be the follower's name as you wish it to appear on the party picker.

The '''Tag''' must be your follower's tag.

All other values are non-functioning defaults and should be specified as in the image above unless you know explicitly what you're doing.

The second spreadsheet should be named '''party_picker_''' (note middle underscore). Once again append your unique suffix (in this example party_picker_fofbc.xls with party_picker_fofbc as its worksheet).

Set up your columns and data like so:

[[File:party_pickerm2da.jpg]]

'''ID''' and '''Tag''' should match what you did in the first spreadsheet. Specify INVALID COLUMN for the third column.

If you're familiar with m2DAs, generate them from these files, copy them to your module's override directory, and skip to the next step. Otherwise, read on:

- Go to '''\Program Files\Dragon Age\tools\ResourceBuild\Processors''' (or wherever you installed Dragon Age)

- Copy '''ExcelProcessor.exe''' from that folder to whichever folder has the excel sheets you just created.

- Drag and drop your xls files onto ExcelProcessor. This will create .gda files.

- Copy these .gda files to your module's export directory (probably \Documents\Bioware\Dragon Age\AddIns\yourModule\module\override\toolsetoverride). Make sure they are included in your .dazip when the time comes to build your module.

If you are an OpenOffice user and have trouble with ExcelProcessor, you can use [http://social.bioware.com/project/755/ GDApp] to directly create the 2DAs. It rocks!

=== Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event ===

Amusingly enough, the Party Picker does not actually add followers to the party. However it raises an event that allows you to do so. Your module script needs to capture this event and execute some code.

The following example shows what to do with the event. The full script would work as a module script for an add-in (assuming it didn't need to do anything else), but otherwise you'll have to incorporate the event into your own script:

<pre>

#include "utility_h"

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); //Allows the follower to gain XP
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); //Adds follower to the active party
break;
}

}
}

</pre>

'''SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE)''' is the key statement to add the follower to the active party. You must have this.

'''SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0)''' is a bug-fix, as followers hired with UT_HireFollower() do not receive XP by default. This statement fixes that, and I consider it best practice to keep it in this event to ensure it is always set. You will not wish to do this if you want a follower that should not gain XP to be on the party picker.

Note that you do not need to intercept the corresponding event for a party member being removed - the party picker handles spawning/despawning, and thus will successfully remove members.

Remember to save and export your module script.

=== Create Your Hiring Script ===

Now all that remains is to actually hire the follower :)

Create a script to handle the hiring (which will most likely be fired from a conversation). The script is quite simple:

<pre>

#include "utility_h"

void main() {

object oFollower = GetObjectByTag("bc_party_miera"); //Use CreateObject() if the creature isn't present in the module yet

UT_HireFollower(oFollower); //Hires the follower

SetPartyPickerGUIStatus(2);

ShowPartyPickerGUI(); //Shows the Party Picker; necessary for the follower to gain XP

}
</pre>

Make sure you use your own follower's tag and not the example one :)

This script fires the party picker after hiring the follower. That is absolutely necessary via this method, as we have put the XP fix onto an event fired by the party picker. You cannot put the XP fix into this script, it must be called from a later one (the bug is caused by an errant call to an event in player_core, which will be executed AFTER this script).

If everything worked, you should see something like this:

[[File:picker_success.jpg|thumb|200px|center]]

== Advanced Follower Creation ==

Follow these steps to have full control over the creation of your follower, with options such as:

- Unique level-up template

- Class and specialisation chosen via script

- Any starting state

- Level higher than the PC

- Starts with a specialisation point rather than a specific specialisation

- Set plot flags in the call to the hire script

=== Prepare Creature, char_stage and Party Picker m2DAs ===

Follow the same steps to create your create your follower creature, override char_stage and create your Party Picker m2DAs as above.

=== Create Party Plot ===

While not necessary, it's very helpful to have plot flags set when a follower is hired or joins/leaves the active party. This makes conversation interjections and the like very easy.

Create a plot with appropriate flags. There's no real need to associate journal text with them:

[[File:follower_plot.jpg]]

=== Add Plot Flags to Party Picker Event Intercept ===

We then update our module script to make use of that plot, like so:

<pre>
#include "utility_h"
#include "wrappers_h"
#include "plt_bc_create_party" //make sure you include your own plot, not mine

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);

if (GetTag(oFollower) == "bc_party_miera") { //You must explicitly test for your follower's tag.
WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, TRUE); //Make sure you use your own flags!
}

break;
}

case EVENT_TYPE_PARTYMEMBER_DROPPED:
{
object oFollower = GetEventObject(ev, 0);

if (GetTag(oFollower) == "bc_party_miera") {
WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, FALSE); //As above, but set false.
}

}

}
}

</pre>

=== Create a Level Up Template ===

You can skip this step if you're content to use one of the generic Rogue, Wizard or Warrior templates, but I don't recommend it. Making a template that suits your character is easy and will almost always be better for the player than a generic one that spends points poorly.

Go to \Program Files\Dragon Age\tools\Source\2DA (or wherever you installed Dragon Age).

You should see a number of excel sheets of the form '''ALCharacter.xls''' (such as ALAlistair.xls, ALLeliana.xls, ALRogue_Default.xls etc). Open the one closest to your character (ie Morrigan or Wynne for a wizard, Leliana or Zevran for a rogue). Save a copy as '''ALYourcharacter.xls''' in whatever directory you're using to create your 2DAs, remembering to rename the worksheet '''ALYourcharacter''' (in this example, ALMiera.xls with ALMiera as its worksheet).

It should look something like this:

[[File:ALtable.jpg|thumb|500px|center]]

'''Columns B''' and '''C''' are the talents/spells available to this character. Do not change them.

'''Columns F''' and '''G''' are the skills available to this character. Do not change them.

We will edit the remaining columns like so:

==== Setting Stat Weights ====

The stat weights in '''column J''' determine how the follower will spend their attribute points, in a rough ratio. So if Dexterity is set to 1.5 and Intelligence to 1, you should expect to see 3 points of Dex for every 2 points of Cunning in-game (note Intelligence is the label used in the toolset for Cunning).

Simply change the values in J to reflect how you'd like the character to spend their points. In this example we're creating a wizard, so we're not going to mess around:

[[File:miera_stat_weights.jpg]]

This character will only raise magic. I set the value to 5 rather than something like 1 to provide room underneath for the other stats while still overwhelmingly favouring magic, but in practice I only really ever want that one stat.

==== Setting Talent and Skill Priorities ====

'''Columns D''' and '''E''' are the talents/spells that the character will buy, in preference order from top to bottom.

'''Columns H''' and '''I''' are the skills available to this character, in preference order from top to bottom.

To change these, just copy the appropriate two cells from columns B&C or F&G over the ones you want to replace.

For example, here we're copying Morrigan's template. Morrigan has Spider Shape high in her preferences, which we do not want.

[[File:AlMori_talent_pref.jpg]]

We decide we'd prefer Flame Blast, so we find it in columns B&C and copy both cells:

[[File:ALMori_copy.jpg]]

Then we select the cells we want to replace in columns D&E and paste over them:

[[File:ALMori_paste.jpg]]

Continue this process until your priorities list for both skills and talents/spells is exactly as you want it. Make sure you have at least as many priorities as the core follower you're copying - points that cannot be spent according to these priorities have a habit of vanishing.

If you used any abilities from a specialisation, make sure you remember to set that specialisation with the function we'll introduce later. The autolevel scripts will add specialisation abilities to a character regardless of whether they have that spec or not.

==== Create a M2DA_base_ m2DA ====

Dragon Age will need to know where to find your autolevel template. We tell it by extending M2DA_base.gda

Create a spreadsheet with the name and worksheet name in the form '''M2DA_base_''' with your unique suffix (in this example, M2DA_base_fofbc.xls with M2DA_base_fofbc as a worksheet).

Set up its columns and data like so (note I used GDApp because Open Office wasn't cooperating for this one!):

[[File:m2da_base_fofbc.jpg]]

The '''ID''' should be very high to avoid conflicts. I've arbitrarily chosen 50,000+ here. Carefully note the ID you've chosen for your character, you will need it later.

Set the '''Label''' and '''Worksheet''' to be the name of your autolevel template worksheet (ALCharactername if you've been following this).

Set the '''PackageIDForAI''' to be 0, it shouldn't be needed for followers.

When you're done, use ExcelProcessor to make GDAs of both spreadsheets and copy them to your module's export folder.

=== Create a New Hire Function Include ===

Many vital steps of follower addition happen inside an event in player_core. Followers tend to be extremely buggy (no skill tree, for example) if this event does not fire.

However, that event is not very flexible. In order to control it to our requirements, we need to replicate its functionality inside our own script. This is probably much safer than messing with player_core directly!

Create a new script file, naming it something like '''hireCustomFollower_h'''. We will be including this wherever we want to hire a follower.

Paste in the following script:

<pre>

#include "sys_chargen_h"
#include "wrappers_h"
#include "utility_h"
#include "sys_rewards_h"
#include "approval_h"
#include "sys_autolevelup_h"

/* Jye Nicolson 5-Jan-2010

This function set duplicates the full functionality chain of UT_HireFollower, with the following exceptions:

- Followers can gain XP
- Autolevel status can be set (default off)
- Followers can be set to any starting state (default Available) and will still be properly initalised and added to the party pool
- Autolevel tables for non-core followers can be explicitly set.
- Class and Specialisation can be chosen via script
- Followers without specialisations are granted a spec point by default.

It should only ever be called once each for characters you intend to be full followers.
Much of the protective code handling summoned creatures etc. in player_core is not present here.

Calling the function:

Simple:

hireCustomFollower(oFollower, CLASS_WARRIOR);

Change the class to CLASS_WIZARD or CLASS_ROGUE as appropriate.
This will hire your follower and make them available.
They will auto level up with a default package, and receive a free spec point.

Best Practice:

hireCustomFollower(oFollower, CLASS_WARRIOR, PLT_YOUR_PARTY_PLOT, YOUR_FOLLOWER_JOINED_FLAG, ABILITY_TALENT_HIDDEN_CHAMPION);

Where the plot and flag are those for your module (remember to create the plot and include it on the calling script), and ABILITY_TALENT_HIDDEN etc is the desired spec.

You should also have a custom ALTable set up.
See wiki for details, and remember to edit it in to GetCustomFollowerALTable below or pass it directly as an argument to hireCustomFollower.

Full argument list:

void hireCustomFollower (
object oFollower, //Pass your follower object, mandatory

int nForceClass, //Pass a Class constant here, usually CLASS_ROGUE, CLASS_WARRIOR, CLASS_WIZARD. Mandatory due to a bug.

string sPlot = "", //It's recommended you have a plot flag to be set when the follower joins. Pass the plot constant here. Remember to #include in calling script

int nPlotFlag = "", //And then pass the flag constant. Will be set to TRUE if available.

int nForceSpec = 0, //This is the ID of the Specialisation you want. Note they are NOT classes, but abilities. The full list is:
//ABILITY_SPELL_HIDDEN_ARCANE_WARRIOR, ABILITY_SPELL_HIDDEN_BLOODMAGE, ABILITY_SPELL_HIDDEN_SHAPESHIFTER, ABILITY_SPELL_HIDDEN_SPIRIT_HEALER
//ABILITY_SPELL_HIDDEN_BARD, ABILITY_TALENT_HIDDEN_ASSASSIN, ABILITY_TALENT_HIDDEN_DUELIST, ABILITY_TALENT_HIDDEN_RANGER
//ABILITY_TALENT_HIDDEN_BERSERKER, ABILITY_TALENT_HIDDEN_CHAMPION, ABILITY_TALENT_HIDDEN_REAVER, ABILITY_TALENT_HIDDEN_TEMPLAR
//I recommended forcing a spec, particularly if your ALTable includes abilities from one.

int nALTable = 0, //This is the ID of an ALTable from 2DA_base.GDA or your module's m2DA_base_*.GDA I recommended the latter, but you can edit that into GetCustomFollowerALTable below rather than passing it.

int bInvokePicker = FALSE, //Sets whether the party picker should be opened on hiring. I think it's cleaner to call the picker outside this script, particularly if you have multiple hires at once.

int nInitialState = FOLLOWER_STATE_AVAILABLE, //This sets whether the follower joins the active party or not. Options are:
//FOLLOWER_STATE_ACTIVE (put them in the active party)
//FOLLOWER_STATE_LOCKEDACTIVE (force them into the active party and keep them there, remember to change this later.
//FOLLOWER_STATE_AVAILABLE (make them available on the party picker (if you've set it up for them), but not in the active party)
//Plus some others you're unlikely to need at this time. Defaults to AVAILABLE because having 4+ active followers is screwy.

string sCurrPlot = "", //If you set FOLLOWER_STATE_ACTIVE or FOLLOWER_STATE_LOCKEDACTIVE, the script will check to see if you passed this.
//It is recommended that you have a plot flag set for a given follower being in the active party, this makes conversation interjection etc. much easier.

int nCurrPlotFlag = 0, //This flag will be set if FOLLOWER_STATE_ACTIVE or FOLLOWER_STATE_LOCKEDACTIVE are true
//AND sCurrPlot has a value AND nCurrPlotFlag is > 0.
//ie if you added someone to the active party and have a plot flag to cope with it.

int nAutolevel = 0, //Sets the Autolevel flag on the character sheet. 0 is off, 1 is on, 2 forces it on and removes it so the player can't turn it off.

bFreeSpecPoint = TRUE, //This grants a specialisation point to the follower if they do not have a specialisation.
//It's important to set this false for classes that do not have specs, such as CLASS_DOG.

int nTargetLevel = 0, //If you want a specific level, set this. Generally not worthwhile unless you set it higher than the player, since they'll just get XP from the party picker anyway.

int nMinLevel = 0 //Set this if there's a specific level you don't want the follower to go below. Probably only useful if the PC might be very low level but not necessarily so.

)

*/

/* GetCustomFollowerALTable()

This function is where you put your custom table assignments.

You should explicitly test for the tag of your follower (not mine!) and assign a value to nTable from your m2DA extension to M2DA_base

See wiki for details on how to do this, or ignore it to get the default Warrior/Rogue/Wizard AL tables.

NOTE: you MUST explicitly set a table for non-Warrior/Rogue/Wizards, eg dogs. Use TABLE_AL_DOG for a default Mabari.

*/

int GetCustomFollowerALTable(object oFollower) {
int nTable = _GetTableToUseForAL(oFollower);

if (GetTag(oFollower) == "bc_party_miera") {
nTable = 50143;
}

if (GetTag(oFollower) == "bc_party_jysavin") {
nTable = 50144;
}

if (GetTag(oFollower) == "bc_party_geldual") {
nTable = 50145;
}

if (GetTag(oFollower) == "bc_party_braghon") {
nTable = 50146;
}

return nTable;

}

// This just cleans up the main function a little

int GetCustomFollowerTargetLevel(object oFollower, object oHero, int nPackage, int nMinLevel = 0) {
int nPlayerLevel = GetLevel(oHero);
int nTargetLevel = 0;

if((nPlayerLevel >= 13) || (nPlayerLevel == 1) || (!_UT_GetIsPlotFollower(oFollower))) {
nTargetLevel = nPlayerLevel;
} else {
nTargetLevel = nPlayerLevel + 1;
}

if (nMinLevel == 0) { //If nMinLevel is not specified, checks package 2DA for a value
nMinLevel = GetM2DAInt(TABLE_PACKAGES, "MinLevel", nPackage);
}
if(nMinLevel > 0 && nMinLevel > nTargetLevel) {
nTargetLevel = nMinLevel;
}

return nTargetLevel;

}

// Moving this black box out :) I don't really understand it, but it should function if you have tactics set up in a package.

void InitCustomFollowerTactics(object oFollower, int nPackage) {
int nTableID = GetM2DAInt(TABLE_PACKAGES, "FollowerTacticsTable", nPackage);
if (nTableID != -1)
{
int nRows = GetM2DARows(nTableID);
int nMaxTactics = GetNumTactics(oFollower);

int nTacticsEntry = 1;
int i;
for (i = 1; i <= nRows && nTacticsEntry <= nMaxTactics; ++i)
{
int bAddEntry = FALSE;
int nTargetType = GetM2DAInt(nTableID, "TargetType", i);
int nCondition = GetM2DAInt(nTableID, "Condition", i);
int nCommandType = GetM2DAInt(nTableID, "Command", i);
int nCommandParam = GetM2DAInt(nTableID, "SubCommand", i);

int nUseType = GetM2DAInt(TABLE_COMMAND_TYPES, "UseType", nCommandType);
if (nUseType == 0)
{
bAddEntry = TRUE;
}
else
{
bAddEntry = HasAbility(oFollower, nCommandParam);
}

if (bAddEntry)
{
SetTacticEntry(oFollower, nTacticsEntry, TRUE, nTargetType, nCondition, nCommandType, nCommandParam);
++nTacticsEntry;
}
}
}
}

/* InitCustomFollowerSpec:

This function tries to set the forced Specialisation. If there is none, it checks the package for one.

If there isn't either of those, it grants a free spec point if bFreeSpecPoint is true.

*/

void InitCustomFollowerSpec(object oFollower, int nPackage, int nForceSpec, int bFreeSpecPoint) {
// Find specialization, and optionally add a spec point if none is found.

if (nForceSpec == 0) {

int nSpecAbility = GetM2DAInt(TABLE_PACKAGES, "switch1_class", nPackage); // followers can have only 1 advanced class
if(nSpecAbility > 0)
{
AddAbility(oFollower, nSpecAbility);
} else {
if (bFreeSpecPoint) {
SetCreatureProperty(oFollower, 38, 1.00);
}
}

} else {

AddAbility(oFollower, nForceSpec);

}
}

/* hireCustomFollower() (See doco at top of page)

I strongly suggest you reorder the parameters if you're adding many followers with advanced options.

Feel free to leave them alone if you only want to set class, plot, spec or don't mind long declarations.

Note nForceClass is currently compulsory due to flakiness with GetCreatureCoreClass()

*/

void hireCustomFollower(object oFollower, int nForceClass, string sPlot = "", int nPlotFlag = 0, int nForceSpec = 0, int nALTable = 0, int bInvokePicker = FALSE, int nInitialState = FOLLOWER_STATE_AVAILABLE, string sCurrPlot = "", int nCurrPlotFlag = 0, int nAutolevel = 0, int bFreeSpecPoint = TRUE, int nTargetLevel = 0, int nMinLevel = 0) {

object oHero = GetHero();

/* ################# BEGIN BASIC FOLLOWER JOIN BLOCK ###################

This loosely replicates WR_SetFollowerState.

*/

if (nForceClass == 0) {
nForceClass = GetCreatureCoreClass(oFollower); //This is not working. Hence nForceClass mandatory.
}

SetGroupId(oFollower, GetGroupId(oHero)); //Puts the follower in the pc's Group.
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE); //This makes them act like a player.
SetFollowerState(oFollower, nInitialState); //This sets whether they are available, in the active party etc.

/* ################# END BASIC FOLLOWER JOIN BLOCK ##################### */

/* ################# BEGIN PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION #################

This replicates the EVENT_TYPE_PARTY_MEMBER_HIRED handler from player_core, stripped down for simplicity and allowing our custom options.

*/

Chargen_EnableTacticsPresets(oFollower); //I assume this is important.

SetLocalInt(oFollower, FOLLOWER_SCALED, 1); //This should prevent the follower being rescaled by player_core or what have you

int nPackage = GetPackage(oFollower); //Gets the package, which will be used to find a number of 2DA IDs.
int nPackageClass = GetM2DAInt(TABLE_PACKAGES, "StartingClass", nPackage); //I don't think this is used, even by player_core

// set behavior according to package
int nBehavior = GetM2DAInt(TABLE_PACKAGES, "FollowerBehavior", nPackage);

if(nBehavior >= 0) {
SetAIBehavior(oFollower, nBehavior);
}

Chargen_InitializeCharacter(oFollower); //We initialise the follower and choose race/class.

Chargen_SelectRace(oFollower,GetCreatureRacialType(oFollower));
Chargen_SelectCoreClass(oFollower,nForceClass);

if (nTargetLevel == 0) { //This block picks a target level if not specified

nTargetLevel = GetCustomFollowerTargetLevel(oFollower, oHero, nPackage, nMinLevel);
}

int nXp = RW_GetXPNeededForLevel(Max(nTargetLevel, 1)); //Here is where the XP is calculated and rewarded
RewardXP(oFollower, nXp, FALSE, FALSE);

// -------------------------------------------------------------
// add hidden approval talents - (JN: I don't know how to set these yet, but when I figure it out this should make it work)
// -------------------------------------------------------------
int nIndex = Approval_GetFollowerIndex(oFollower);
Approval_AddFollowerBonusAbility(nIndex, 0);

//Handle Specialisation
InitCustomFollowerSpec(oFollower, nPackage, nForceSpec, bFreeSpecPoint);

// -------------------------------------------------------------
// This spends all available attribute and stat points on the
// creature according to the levelup table. (JN: this replicates AL_DoAutoLevelUp but with our choice of table)
// -------------------------------------------------------------

if (nALTable == 0) {
nALTable = GetCustomFollowerALTable(oFollower);
}

AL_SpendAttributePoints(oFollower, nALTable, FALSE);
AL_SpendSkillPoints(oFollower, nALTable, TRUE);
AL_SpendSpecializationPoints(oFollower, nALTable);
AL_SpendTalentSpellPoints(oFollower, nALTable, TRUE);

// -------------------------------------------------------------------------
// Update various UIs
// -------------------------------------------------------------------------
Chargen_SetNumTactics(oFollower);
SetCanLevelUp(oFollower,Chargen_HasPointsToSpend(oFollower));

// load tactics
InitCustomFollowerTactics(oFollower, nPackage);

/* ################# END PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION ################# */

SetAutoLevelUp(oFollower, nAutolevel); //This is the autolevel flag on the character sheet.

//Set plot flags

if (!((sPlot == "") || (nPlotFlag == 0))) { //Joined Party
WR_SetPlotFlag(sPlot, nPlotFlag, TRUE);
}

if ((nInitialState == FOLLOWER_STATE_ACTIVE) || (nInitialState == FOLLOWER_STATE_LOCKEDACTIVE)) {
if (!((sCurrPlot == "") || (nCurrPlotFlag == 0))) {
WR_SetPlotFlag(sCurrPlot, nCurrPlotFlag, TRUE); //Currently in Party
}
}

// Invoke picker if requested.

if (bInvokePicker) {
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();

}

}

</pre>

Yeah, I know. It can't really be any smaller. Feel free to modify it if you're confident with scripting.

==== Add Your Custom Autolevel Template to GetCustomFollowerALTable() ====

While you can pass the ID you made for your autolevel template to that monster function as an argument, it's better to have them all in one place if you have multiple followers.

GetCustomFollowerALTable() is the first function in our include, and you can add an explicit if test for your follower there to assign the correct table id (the one from your M2DA_base_ m2DA). There is a function very much like it in sys_autolevel_h.nss for the core followers, so we'll copy Bioware's practice.

Let's take a look at the function by itself:

<pre>
int GetCustomFollowerALTable(object oFollower) {
int nTable = _GetTableToUseForAL(oFollower);

if (GetTag(oFollower) == "bc_party_miera") {
nTable = 50143;
}

if (GetTag(oFollower) == "bc_party_jysavin") {
nTable = 50144;
}

if (GetTag(oFollower) == "bc_party_geldual") {
nTable = 50145;
}

if (GetTag(oFollower) == "bc_party_braghon") {
nTable = 50146;
}

return nTable;

}
</pre>

So we have a test for each follower tag from my module, matching up to an ID which is assigned to nTable. All you need to do is change a tag from my follower to yours, and my ID to the correct one from your M2DA_base_* m2DA. Then you should delete the rest of the example if statements :)

Save and export the script. Ignore the compiler error about lack of main();

=== Include Function In Your Hire Script and Call It ===

So instead of a hire script that calls UT_HireFollower(), we want one that includes our shiny new function and calls it.

Take a look at the following example:

<pre>

#include "plt_bc_create_party" //Make sure you include your party handling plot
#include "hireCustomFollower_h" // And include the function script - which will in turn include a bunch of stuff

void main() {

//Initialising my objects, not super-relevant to the example

object oHero = GetHero();
object oMiera = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_miera.utc", GetLocation(oHero));
object oJysavin = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_jysavin.utc", GetLocation(oHero));
object oBraghon = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_braghon.utc", GetLocation(oHero));
object oSpider = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_geldual.utc", GetLocation(oHero));

//Simplest hire call - adds to the party as a wizard. Class is currently compulsory due to a bug.

hireCustomFollower(oMiera, CLASS_WIZARD);

//Add to the party and set joining plot flags

hireCustomFollower(oJysavin, CLASS_WARRIOR, PLT_BC_CREATE_PARTY, PARTY_JYSAVIN_JOINED);

//Add to the party, set plot flags, force a specialisation

hireCustomFollower(oBraghon, CLASS_ROGUE, PLT_BC_CREATE_PARTY, PARTY_BRAGHON_JOINED, ABILITY_TALENT_HIDDEN_ASSASSIN);

//More complex example - Follower added as a unique class (Dog), not granted a specialisation or spec point.
//Note unique classes must have an ALTable passed here or specified in GetCustomFollowerALTable() or they won't work

hireCustomFollower(oSpider, CLASS_DOG, PLT_BC_CREATE_PARTY, PARTY_GELDUAL_JOINED, 0, 0, FALSE, FOLLOWER_STATE_AVAILABLE, "", 0, 0, FALSE);

//Show the party picker to let the player choose from their new companions!

SetPartyPickerGUIStatus(2);

ShowPartyPickerGUI();

}

</pre>

The example shows several of the more simple ways of invoking the function. Check the comments at the start of the function for a full list of arguments.

I would suggest best practice for most followers would be to call as follows:

'''hireCustomFollower(oFollower, CLASS, PLOT, PLOT_FLAG, SPECIALISATION)'''

This will safely set the follower up as the desired class and specialisation (doubly important if there are spec abilities in their ALTable) while setting your plot flag for them being in the party. hireCustomFollower(oFollower, CLASS, PLOT, PLOT_FLAG, SPECIALISATION, 0, TRUE) will do the same while invoking the Party Picker automatically.

Note that the specialisations are abilities and not classes - you'll find them as ABILITY_HIDDEN_ constants.

If it's all worked, you should find you can now add followers with a lot more flexibility!

[[File:picker_advanced.jpg|thumb|500px|center]]

== Common Follower Problems & FAQ ==

====Why don't my followers gain XP?====
There is a bug in UT_HireFollower. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:

WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);

Alternately you need to clear a flag in a seperate script to the one in which they're hired.

You must use the '''SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);''' statement in a script you can be sure will run soon after your hiring script.

====When I choose followers from the Party Picker, they spawn into the area but do not join.====

You need to intercept the EVENT_TYPE_PARTYMEMBER_ADDED event and set the follower to FOLLOWER_STATE_ACTIVE. See Simple Follower Creation earlier in this document.

====My followers don't have skill trees!====

If a follower hasn't been through an initial chargen/autolevel event (via player_core/sys_autolevel_h) then the skill tree doesn't show. You're probably trying to be clever and get around UT_HireFollower without going all the way (see monster function above ^_^).

====My followers don't have a class====

GetCreatureCoreClass() seems flaky under some conditions. It's best to explicitly set the class yourself; this is why class is currently a mandatory argument to hireCustomFollower()

====Isn't there an easier way to do this?====

Possibly. There is a way of recruiting a follower by setting a plot flag. However I don't understand it, and I expect it still doesn't allow custom autolevel templates, full control over specialisations etc. There's still a fair bit of stuff hardcoded for the core followers, I'm not sure putting a custom follower through the same process as Al, Leli et al will have good results.

How-tos

2010-01-03T20:37:34Z

Craig Graff: /* Add a follower to the player's party */

This page lists how to accomplish tasks that are relatively simple and commonly needed, but that touch on multiple areas of the toolset or are difficult to figure out intuitively how to do.

Just collecting ideas at the moment, add headers if you think a how-to is needed on a particular subject.

*[[3D control]]

== Run a cutscene from a trigger ==

Create a script:

<dascript>
#include "events_h"
#include "global_objects_h"
#include "utility_h"

void main ()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
int bEventHandled = FALSE;
switch (nEventType)
{
case EVENT_TYPE_ENTER:
{
object oCreature = GetEventCreator(ev);
if(GetObjectActive(OBJECT_SELF)
&& IsPartyMember(oCreature))
{
resource rCutscene = R"my_cutscene.cut";
CS_LoadCutscene(rCutscene);
SetObjectActive(OBJECT_SELF, FALSE);
}
}
break;
}
if (!bEventHandled) //If this event wasn't handled by this script, let the core script try
{
HandleEvent(ev, RESOURCE_SCRIPT_TRIGGER_CORE);
}
}
</dascript>

And set it as the event script for the trigger that you want to have run the cutscene.

== Add a follower to the player's party ==

<dascript>
if(IsPlayer(oCreature)) {
object oFollower = GetObjectByTag("myfollower");
UT_HireFollower(oCreature, oFollower);
}
</dascript>

Note that with Toolset v1.0.982.0, calling UT_HireFollower() will result in a follower who's unable to gain xp. This happens due to the call of
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, '''TRUE''');
to the function
void WR_SetFollowerState(object oCreature, int nState, int nSendEvent = TRUE, int nMinLevel = 0, '''int bPreventLevelup''' = FALSE)
To enable the xp gain, the flag CREATURE_REWARD_FLAGS needs to be cleared from the follower after the hired event was processed (there the flag is set). For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:

WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);

== Have an enemy play possum and then get up to fight ==

Set the creature's CREATURE_SPAWN_DEAD variable to 2.

When it's time for the creature to rise and attack, execute the following script commands:

<dascript>
#include "wrappers_h"
...
WR_SetObjectActive(oCreature, TRUE);
SetCommandable(oCreature, TRUE);
// Make sure to set this flag back to 0 to avoid problems with savegames.
SetLocalInt(oCreature, CREATURE_SPAWN_DEAD, 0);
UT_CombatStart(oCreature, oPC);
</dascript>

== Insert content into an existing area ==

If you want to add new content on to an existing area (for example, putting a new character or area transition door into an area that exists in the single-player campaign) there are two different ways to do it. One is to override the existing area with a new area of your own design that duplicates the original with the exception of your additions. This is straightforward to do but can interact poorly with other add-ons - you can only have one version of an area active at a time.

A more elegant and extensible approach is to use a [[PRCSCR]]_-prefixed M2DA. The PRCSCR M2DA has a very simple structure and a simple but profound effect:

*ID - a unique integer identifier for each row
*AreaListName - a string that identifies a specific area list, or the special keyword "any".
*Script - the name of a script file.

Whenever a player enters an area in an area list in this M2DA the associated script will be run. A modder can therefore include a script with his mod that will be run when the player enters an existing area that he didn't create. This script can freely add or remove placeables and creatures and perform whatever other modifications to the area that a script is capable of doing.

Note that the script will be run every time the player enters the area, so you'll want to have an associated plot flag to ensure that the changes are only made once.

The following example is a script that adds a new character from an add-on module to an existing area in the main game:

<dascript>
// this is the name of a precreated plot file "joblos_quest" prefixed with the special "plt_"
// "plt_" + quest name allows you to reference the flag names as constants.
#include "plt_joblos_quest"
#include "wrappers_h"

void main()
{
//Check whether we've added Joblo already.
if (WR_GetPlotFlag(PLT_JOBLOS_QUEST, JOBLO_ADDED_TO_TOWN) == FALSE)
{
object oTown = GetObjectByTag("lot100ar_lothering"); //An area's tag is the same as its resource name
vector vJobloLocation = Vector(126.745f, 120.724f, 0.460568f); // See below for how to get these coordinates

CreateObject(
OBJECT_TYPE_CREATURE,
R"joblo.utc",
Location(oTown, vJobloLocation, 180.0f) //See below for how to get the value for orientation
)

WR_SetPlotFlag("joblos_quest", JOBLO_ADDED_TO_TOWN, TRUE);
}
}
</dascript>

Since you can't add [[waypoint]]s to an existing area you'll need to enter the position and orientation values for the target location manually. You can find them by creating a local copy of the area in question and temporarily adding a waypoint to copy down the coordinates and orientation you'll need.

== Add new music ==

Open up [[FMOD]]

It creates a project - set the build directory to your DA override directory - with project highlighted, it is over on the top right about half way down the project settings. You can set a default resource directory but that will just set where the file browser defaults to so it is optional. I'd also define a name in those parameters while you are there.

From there, you need a new event !!(not sure whether a blank default is generated or whether you have to right click and make a default blank event)!!. After you have an event, highlight it and change to the event tab (2nd tab). Here you need to import your file to link to that event.

On that tab I think it creates a empty row for your new event - right click and add wavetable or something like that - I think I use the top option. (Again, might be wrong but the basic goal is getting a audio file in that screen that plays when you hit the play button at the top)

Browse to your wav file or whatever you have.

From there you should be able to play the sound both in the pop-up box and (once that is closed) back in the event tab. You'll see the name of the wave in that once empty row (IIRC).

If you want, you can add layers of sounds to this event using the same process over and over, but keeping it simple; we'll just move along.

Now you have a project and an event. You can set various parameters on the first tab that alter pitch etc on the first tab. (When you import the sound, you set whether it is a one shot or looping).

Once you have that done, go to the top drop down and find build. Build the files and you should see extra files in your override directory.

From there, just open up the toolset (or hit refresh from within the toolset) and your project and event sounds should show up in the listing of sounds.

You can then drag and drop them into the game or cutscene and they will play.

== Adding music to cutscenes ==

The way we have been doing the music changes is via placed sound objects. These sound objects are generally created in [[FMOD]], and in FMOD you can say if the music will persist after the cutscene or end when the cutscene ends.

We are just using other sounds to switch music tracks. Designers can add music switch parameter to any sound in Fmod Designer, usually this is just VO line to change music track, for example:

[[Image:FMOD music switch.jpg]]

If there are no other sounds, designers can create empty sound event and add #music parameter there and place this sound on cutscene timeline.
Music track has to be defined in the same group as music in current area in “music.fdp” to work.

[[Image:FMOD music switch 2.jpg]]

<pre>
#music:name,1 – non looping, for stingers
#music:name – for looping music
</pre>

--------------
Another way
--------------

1. Open up '''FMOD''' (fmod comes with dragon age, do a search for fmod in dragon age directory)

2. '''File''' ---> '''New Project''' --> and call the project whatever you want and place it in whatever folder you want.

3. '''Double click''' the '''folder''' under '''Hierarchy''' (purple icon folder) and an event will appear beneath it. Name this event whatever you want. (If there is no event for some reason right click and add one).

4. Now click '''"Event Editor"''' Tab. (Make sure your event was selected before you do this).

5. '''Right click''' one of the open sound fields (find it) and click '''"Add Sound"'''. (just right click all over until you see the option).

6. In this window you will see '''"LOOPING"''' and '''"ONE SHOT"''' on the right hand side. Looping will be selected by default. If you want your music to loop over & over again even after a cutscene is over leave it there. If you want your music to play ONE TIME then select "One Shot".

7. Now it's time to '''pick your music file''' by clicking '''"new wavetable"'''. '''Browse''' to your music file (wav), select it and '''press ok'''.

8. '''VERY VERY IMPORTANT'''.. '''YOU MUST DO THIS STEP'''....... Right click slightly above the timeline and click '''"ADD PARAMETER"'''.

9. Now '''right click''' your new blank parameter, look at the bottom and click '''"PARAMETER PROPERTIES"'''. Another new window will pop up.

10. '''VERY IMPORTANT'''..... Name this parameter:

#duck:music,1000,0,5000,-30

Now click ok.

11. Your new parameter should read: '''#duck:music,1000,0,5000,-30 (Primary)'''

12. Now click '''"Build"''' and do '''"build project"'''.

13. Note the new files in the directory where you saved the project.

14. Copy the '''FEV & FSB''' files from your FMOD project folder '''INTO YOUR OVERRIDE folder'''. I made a folder called music to be organized.

FMODProjectFolder/whatever.fev
FMODProjectFolder/whatever.fsb

COPY TO

Dragon Age\modules\Single Player\override\toolsetexport\music

15. Now open up '''toolset''' and navigate to '''sound palette''' and you should see your new sound file. Type the name of your sound file in the filter to find it faster. (Do not type the folder name in the filter. The filter works by filenames and not folders).

16. Open a '''cutscene''', then left click your new sound file in the right hand sound palette window to select and highlight it. (just a simple left click on it).

17. Now '''left click anywhere in your cutscene''' and a sound icon will be added which is your sound file.

'''Congrats''', 17 steps and now you've added a simple music file to your project and ready for your cutscene. *Sweats*

== Delete resources ==

Resource deletion can sometimes be a bit complicated. Check the following:

*Resources must be checked in when deleted. This is so that the toolset can be sure that all dependencies have been properly resolved.
*If other resources reference the resource it can't be deleted. This means that sometimes you'll need to delete resources in a specific order. For example, you can't delete a creature that's being used in an area, but you could delete the area and then delete the creature. Occasionally there may be circular references that you'll need to break by editing the resources before deleting them. For example:
**A stage can reference an area, which can then reference the stage.
**A plot file can have an associated event script, which will almost certainly include the plot file.
**A stage can reference a creature, which references a dialogue, which references the original stage.

== Removing Modules ==

Deleting a Module from the Toolset
Setup:
I created a module called Meep with a unique id of rcfMeep, added in one area with a waypoint, configured the starting area/waypoint info, and exported it with dependencies. And now I want to strip it out.

Step 1: Removing it from the game

* Navigate to My Documents\Bioware\AddIns
* Delete the folder called rcfMeep
* Done

Removing from the game is fairly easy. The toolset? Not so much. The reason for this is that the information is stored in the SQL Database. Now if you just want to remove the module from the Manage Modules list, that is easy.

* Open Sql Server Management Studio Express. I'm not sure if the default installation installs this or not. If not, it can be downloaded from Microsoft.
* Connect to the BWDATOOLSET server, assuming that you kept the default options.
* Expand Databases
* Expand bw_dragonage_content
* Expand Tables
* Right click and select open on the dbo.Modules table
* This will bring up an excell-like window. Find your module, right-click on the row, and select delete. Say ok to the confirmation.
* Module is now PERMANENTLY removed. Absolutely no way of recovering it.

Now depending on the size of the Module, you just orphaned a bunch of resources. Areas, placables, conversations, they all get placed into the database. And once you remove the module ID, you just lost your ability to remove these resources. Now do keep in mind that 95% of this junk is just text, so it hardly takes up any room. It's not really a major issue. However if you [[How-tos#Delete resources|delete out the resources]] within the toolset before you remove the module reference you should avoid this.

== Override Events (e.g. those in player_core) ==
Look here: [[Event override]]

== Create a lootable placeable that vanishes when looted ==

For a player-usable placeable, use the following event script to make it give its contents to the player and then vanish when clicked on.

<dascript>
#include "wrappers_h"
void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch (nEventType)
{
case EVENT_TYPE_USE:
{
//MoveAllItems(OBJECT_SELF, GetHero());
AddCreatureMoney (1000000, GetHero(), TRUE);
Safe_Destroy_Object(OBJECT_SELF);
}
}
}
</dascript>

If you wanted to use standard resources you could achieve the same thing (though not destroying the placeable) simply by adding "_autoloot" to the end of the placeable's tag.

== Move the player to a new area after a cutscene plays ==

Stand-alone cutscenes have an "end script" parameter that sets a script to run once the cutscene ends. Use a script such as the following:

<dascript>
void main()
{
DoAreaTransition("destination_area_tag", "destination_waypoint_tag");
}
</dascript>
[[category:tutorials]]

How-tos

2010-01-01T05:14:27Z

Craig Graff: /* Insert content into an existing area */

This page lists how to accomplish tasks that are relatively simple and commonly needed, but that touch on multiple areas of the toolset or are difficult to figure out intuitively how to do.

Just collecting ideas at the moment, add headers if you think a how-to is needed on a particular subject.

*[[3D control]]

== Run a cutscene from a trigger ==

Create a script:

<dascript>
#include "events_h"
#include "global_objects_h"
#include "utility_h"

void main ()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
int bEventHandled = FALSE;
switch (nEventType)
{
case EVENT_TYPE_ENTER:
{
object oCreature = GetEventCreator(ev);
if(GetObjectActive(OBJECT_SELF)
&& IsPartyMember(oCreature))
{
resource rCutscene = R"my_cutscene.cut";
CS_LoadCutscene(rCutscene);
SetObjectActive(OBJECT_SELF, FALSE);
}
}
break;
}
if (!bEventHandled) //If this event wasn't handled by this script, let the core script try
{
HandleEvent(ev, RESOURCE_SCRIPT_TRIGGER_CORE);
}
}
</dascript>

And set it as the event script for the trigger that you want to have run the cutscene.

== Add a follower to the player's party ==

<dascript>
if(IsPlayer(oCreature)) {
object oFollower = GetObjectByTag("myfollower");
UT_HireFollower(oCreature, oFollower);
}
</dascript>

Note that with Toolset v1.0.982.0, calling UT_HireFollower() will result in a follower who's unable to gain xp. This happens due to the call of
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, '''TRUE''');
to the function
void WR_SetFollowerState(object oCreature, int nState, int nSendEvent = TRUE, int nMinLevel = 0, '''int bPreventLevelup''' = FALSE)
To enable the xp gain, the flag CREATURE_REWARD_FLAGS needs to be cleared from the follower after the hired event was processed (there the flag is set). Alternatively, the relevant contents of UT_HireFollower() are to be called directly using bPreventLevelup = FALSE.

== Have an enemy play possum and then get up to fight ==

Set the creature's CREATURE_SPAWN_DEAD variable to 2.

When it's time for the creature to rise and attack, execute the following script commands:

<dascript>
#include "wrappers_h"
...
WR_SetObjectActive(oCreature, TRUE);
SetCommandable(oCreature, TRUE);
// Make sure to set this flag back to 0 to avoid problems with savegames.
SetLocalInt(oCreature, CREATURE_SPAWN_DEAD, 0);
UT_CombatStart(oCreature, oPC);
</dascript>

== Insert content into an existing area ==

If you want to add new content on to an existing area (for example, putting a new character or area transition door into an area that exists in the single-player campaign) there are two different ways to do it. One is to override the existing area with a new area of your own design that duplicates the original with the exception of your additions. This is straightforward to do but can interact poorly with other add-ons - you can only have one version of an area active at a time.

A more elegant and extensible approach is to use a [[PRCSCR]]_-prefixed M2DA. The PRCSCR M2DA has a very simple structure and a simple but profound effect:

*ID - a unique integer identifier for each row
*AreaListName - a string that identifies a specific area list, or the special keyword "any".
*Script - the name of a script file.

Whenever a player enters an area in an area list in this M2DA the associated script will be run. A modder can therefore include a script with his mod that will be run when the player enters an existing area that he didn't create. This script can freely add or remove placeables and creatures and perform whatever other modifications to the area that a script is capable of doing.

Note that the script will be run every time the player enters the area, so you'll want to have an associated plot flag to ensure that the changes are only made once.

The following example is a script that adds a new character from an add-on module to an existing area in the main game:

<dascript>
// this is the name of a precreated plot file "joblos_quest" prefixed with the special "plt_"
// "plt_" + quest name allows you to reference the flag names as constants.
#include "plt_joblos_quest"
#include "wrappers_h"

void main()
{
//Check whether we've added Joblo already.
if (WR_GetPlotFlag(PLT_JOBLOS_QUEST, JOBLO_ADDED_TO_TOWN) == FALSE)
{
object oTown = GetObjectByTag("lot100ar_lothering"); //An area's tag is the same as its resource name
vector vJobloLocation = Vector(126.745f, 120.724f, 0.460568f); // See below for how to get these coordinates

CreateObject(
OBJECT_TYPE_CREATURE,
R"joblo.utc",
Location(oTown, vJobloLocation, 180.0f) //See below for how to get the value for orientation
)

WR_SetPlotFlag("joblos_quest", JOBLO_ADDED_TO_TOWN, TRUE);
}
}
</dascript>

Since you can't add [[waypoint]]s to an existing area you'll need to enter the position and orientation values for the target location manually. You can find them by creating a local copy of the area in question and temporarily adding a waypoint to copy down the coordinates and orientation you'll need.

== Add new music ==

Open up [[FMOD]]

It creates a project - set the build directory to your DA override directory - with project highlighted, it is over on the top right about half way down the project settings. You can set a default resource directory but that will just set where the file browser defaults to so it is optional. I'd also define a name in those parameters while you are there.

From there, you need a new event !!(not sure whether a blank default is generated or whether you have to right click and make a default blank event)!!. After you have an event, highlight it and change to the event tab (2nd tab). Here you need to import your file to link to that event.

On that tab I think it creates a empty row for your new event - right click and add wavetable or something like that - I think I use the top option. (Again, might be wrong but the basic goal is getting a audio file in that screen that plays when you hit the play button at the top)

Browse to your wav file or whatever you have.

From there you should be able to play the sound both in the pop-up box and (once that is closed) back in the event tab. You'll see the name of the wave in that once empty row (IIRC).

If you want, you can add layers of sounds to this event using the same process over and over, but keeping it simple; we'll just move along.

Now you have a project and an event. You can set various parameters on the first tab that alter pitch etc on the first tab. (When you import the sound, you set whether it is a one shot or looping).

Once you have that done, go to the top drop down and find build. Build the files and you should see extra files in your override directory.

From there, just open up the toolset (or hit refresh from within the toolset) and your project and event sounds should show up in the listing of sounds.

You can then drag and drop them into the game or cutscene and they will play.

== Adding music to cutscenes ==

The way we have been doing the music changes is via placed sound objects. These sound objects are generally created in [[FMOD]], and in FMOD you can say if the music will persist after the cutscene or end when the cutscene ends.

We are just using other sounds to switch music tracks. Designers can add music switch parameter to any sound in Fmod Designer, usually this is just VO line to change music track, for example:

[[Image:FMOD music switch.jpg]]

If there are no other sounds, designers can create empty sound event and add #music parameter there and place this sound on cutscene timeline.
Music track has to be defined in the same group as music in current area in “music.fdp” to work.

[[Image:FMOD music switch 2.jpg]]

<pre>
#music:name,1 – non looping, for stingers
#music:name – for looping music
</pre>

--------------
Another way
--------------

1. Open up '''FMOD''' (fmod comes with dragon age, do a search for fmod in dragon age directory)

2. '''File''' ---> '''New Project''' --> and call the project whatever you want and place it in whatever folder you want.

3. '''Double click''' the '''folder''' under '''Hierarchy''' (purple icon folder) and an event will appear beneath it. Name this event whatever you want. (If there is no event for some reason right click and add one).

4. Now click '''"Event Editor"''' Tab. (Make sure your event was selected before you do this).

5. '''Right click''' one of the open sound fields (find it) and click '''"Add Sound"'''. (just right click all over until you see the option).

6. In this window you will see '''"LOOPING"''' and '''"ONE SHOT"''' on the right hand side. Looping will be selected by default. If you want your music to loop over & over again even after a cutscene is over leave it there. If you want your music to play ONE TIME then select "One Shot".

7. Now it's time to '''pick your music file''' by clicking '''"new wavetable"'''. '''Browse''' to your music file (wav), select it and '''press ok'''.

8. '''VERY VERY IMPORTANT'''.. '''YOU MUST DO THIS STEP'''....... Right click slightly above the timeline and click '''"ADD PARAMETER"'''.

9. Now '''right click''' your new blank parameter, look at the bottom and click '''"PARAMETER PROPERTIES"'''. Another new window will pop up.

10. '''VERY IMPORTANT'''..... Name this parameter:

#duck:music,1000,0,5000,-30

Now click ok.

11. Your new parameter should read: '''#duck:music,1000,0,5000,-30 (Primary)'''

12. Now click '''"Build"''' and do '''"build project"'''.

13. Note the new files in the directory where you saved the project.

14. Copy the '''FEV & FSB''' files from your FMOD project folder '''INTO YOUR OVERRIDE folder'''. I made a folder called music to be organized.

FMODProjectFolder/whatever.fev
FMODProjectFolder/whatever.fsb

COPY TO

Dragon Age\modules\Single Player\override\toolsetexport\music

15. Now open up '''toolset''' and navigate to '''sound palette''' and you should see your new sound file. Type the name of your sound file in the filter to find it faster. (Do not type the folder name in the filter. The filter works by filenames and not folders).

16. Open a '''cutscene''', then left click your new sound file in the right hand sound palette window to select and highlight it. (just a simple left click on it).

17. Now '''left click anywhere in your cutscene''' and a sound icon will be added which is your sound file.

'''Congrats''', 17 steps and now you've added a simple music file to your project and ready for your cutscene. *Sweats*

== Delete resources ==

Resource deletion can sometimes be a bit complicated. Check the following:

*Resources must be checked in when deleted. This is so that the toolset can be sure that all dependencies have been properly resolved.
*If other resources reference the resource it can't be deleted. This means that sometimes you'll need to delete resources in a specific order. For example, you can't delete a creature that's being used in an area, but you could delete the area and then delete the creature. Occasionally there may be circular references that you'll need to break by editing the resources before deleting them. For example:
**A stage can reference an area, which can then reference the stage.
**A plot file can have an associated event script, which will almost certainly include the plot file.
**A stage can reference a creature, which references a dialogue, which references the original stage.

== Removing Modules ==

Deleting a Module from the Toolset
Setup:
I created a module called Meep with a unique id of rcfMeep, added in one area with a waypoint, configured the starting area/waypoint info, and exported it with dependencies. And now I want to strip it out.

Step 1: Removing it from the game

* Navigate to My Documents\Bioware\AddIns
* Delete the folder called rcfMeep
* Done

Removing from the game is fairly easy. The toolset? Not so much. The reason for this is that the information is stored in the SQL Database. Now if you just want to remove the module from the Manage Modules list, that is easy.

* Open Sql Server Management Studio Express. I'm not sure if the default installation installs this or not. If not, it can be downloaded from Microsoft.
* Connect to the BWDATOOLSET server, assuming that you kept the default options.
* Expand Databases
* Expand bw_dragonage_content
* Expand Tables
* Right click and select open on the dbo.Modules table
* This will bring up an excell-like window. Find your module, right-click on the row, and select delete. Say ok to the confirmation.
* Module is now PERMANENTLY removed. Absolutely no way of recovering it.

Now depending on the size of the Module, you just orphaned a bunch of resources. Areas, placables, conversations, they all get placed into the database. And once you remove the module ID, you just lost your ability to remove these resources. Now do keep in mind that 95% of this junk is just text, so it hardly takes up any room. It's not really a major issue. However if you [[How-tos#Delete resources|delete out the resources]] within the toolset before you remove the module reference you should avoid this.

== Override Events (e.g. those in player_core) ==
Look here: [[Event override]]

== Create a lootable placeable that vanishes when looted ==

For a player-usable placeable, use the following event script to make it give its contents to the player and then vanish when clicked on.

<dascript>
#include "wrappers_h"
void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch (nEventType)
{
case EVENT_TYPE_USE:
{
//MoveAllItems(OBJECT_SELF, GetHero());
AddCreatureMoney (1000000, GetHero(), TRUE);
Safe_Destroy_Object(OBJECT_SELF);
}
}
}
</dascript>

If you wanted to use standard resources you could achieve the same thing (though not destroying the placeable) simply by adding "_autoloot" to the end of the placeable's tag.

== Move the player to a new area after a cutscene plays ==

Stand-alone cutscenes have an "end script" parameter that sets a script to run once the cutscene ends. Use a script such as the following:

<dascript>
void main()
{
DoAreaTransition("destination_area_tag", "destination_waypoint_tag");
}
</dascript>
[[category:tutorials]]

How-tos

2009-12-30T21:00:19Z

Craig Graff: /* Run a cutscene from a trigger */

This page lists how to accomplish tasks that are relatively simple and commonly needed, but that touch on multiple areas of the toolset or are difficult to figure out intuitively how to do.

Just collecting ideas at the moment, add headers if you think a how-to is needed on a particular subject.

*[[3D control]]

== Run a cutscene from a trigger ==

Create a script:

<dascript>
#include "events_h"
#include "global_objects_h"
#include "utility_h"

void main ()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
int bEventHandled = FALSE;
switch (nEventType)
{
case EVENT_TYPE_ENTER:
{
object oCreature = GetEventCreator(ev);
if(GetObjectActive(OBJECT_SELF)
&& IsPartyMember(oCreature))
{
resource rCutscene = R"my_cutscene.cut";
CS_LoadCutscene(rCutscene);
SetObjectActive(OBJECT_SELF, FALSE);
}
}
break;
}
if (!bEventHandled) //If this event wasn't handled by this script, let the core script try
{
HandleEvent(ev, RESOURCE_SCRIPT_TRIGGER_CORE);
}
}
</dascript>

And set it as the event script for the trigger that you want to have run the cutscene.

== Add a follower to the player's party ==

<dascript>
if(IsPlayer(oCreature)) {
object oFollower = GetObjectByTag("myfollower");
UT_HireFollower(oCreature, oFollower);
}
</dascript>

Note that with Toolset v1.0.982.0, calling UT_HireFollower() will result in a follower who's unable to gain xp. This happens due to the call of
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, '''TRUE''');
to the function
void WR_SetFollowerState(object oCreature, int nState, int nSendEvent = TRUE, int nMinLevel = 0, '''int bPreventLevelup''' = FALSE)
To enable the xp gain, the flag CREATURE_REWARD_FLAGS needs to be cleared from the follower after the hired event was processed (there the flag is set). Alternatively, the relevant contents of UT_HireFollower() are to be called directly using bPreventLevelup = FALSE.

== Have an enemy play possum and then get up to fight ==

Set the creature's CREATURE_SPAWN_DEAD variable to 2.

When it's time for the creature to rise and attack, execute the following script commands:

<dascript>
#include "wrappers_h"
...
WR_SetObjectActive(oCreature, TRUE);
SetCommandable(oCreature, TRUE);
// Make sure to set this flag back to 0 to avoid problems with savegames.
SetLocalInt(oCreature, CREATURE_SPAWN_DEAD, 0);
UT_CombatStart(oCreature, oPC);
</dascript>

== Insert content into an existing area ==

If you want to add new content on to an existing area (for example, putting a new character or area transition door into an area that exists in the single-player campaign) there are two different ways to do it. One is to override the existing area with a new area of your own design that duplicates the original with the exception of your additions. This is straightforward to do but can interact poorly with other add-ons - you can only have one version of an area active at a time.

A more elegant and extensible approach is to use a [[PRCSCR]]_-prefixed M2DA. The PRCSCR M2DA has a very simple structure and a simple but profound effect:

*ID - a unique integer identifier for each row
*AreaListName - a string that identifies a specific area list, or the special keyword "any".
*Script - the name of a script file.

Whenever a player enters an area in an area list in this M2DA the associated script will be run. A modder can therefore include a script with his mod that will be run when the player enters an existing area that he didn't create. This script can freely add or remove placeables and creatures and perform whatever other modifications to the area that a script is capable of doing.

Note that the script will be run every time the player enters the area, so you'll want to have an associated plot flag to ensure that the changes are only made once.

The following example is a script that adds a new character from an add-on module to an existing area in the main game:

<dascript>
void main()
{
//Check whether we've added Joblo already.
if (WR_GetPlotFlag("joblos_quest", JOBLO_ADDED_TO_TOWN) == FALSE)
{
object oTown = GetObjectByTag("lot100ar_lothering"); //An area's tag is the same as its resource name
vector vJobloLocation = Vector(126.745f,120.724f,0.460568f); // See below for how to get these coordinates

CreateObject(
OBJECT_TYPE_CREATURE,
R"joblo.utc",
Location(oTown, vJobloLocation, 180.0f) //See below for how to get the value for orientation
)

WR_SetPlotFlag("joblos_quest", JOBLO_ADDED_TO_TOWN, TRUE);
}
}
</dascript>

Since you can't add [[waypoint]]s to an existing area you'll need to enter the position and orientation values for the target location manually. You can find them by creating a local copy of the area in question and temporarily adding a waypoint to copy down the coordinates and orientation you'll need.

== Add new music ==

Open up [[FMOD]]

It creates a project - set the build directory to your DA override directory - with project highlighted, it is over on the top right about half way down the project settings. You can set a default resource directory but that will just set where the file browser defaults to so it is optional. I'd also define a name in those parameters while you are there.

From there, you need a new event !!(not sure whether a blank default is generated or whether you have to right click and make a default blank event)!!. After you have an event, highlight it and change to the event tab (2nd tab). Here you need to import your file to link to that event.

On that tab I think it creates a empty row for your new event - right click and add wavetable or something like that - I think I use the top option. (Again, might be wrong but the basic goal is getting a audio file in that screen that plays when you hit the play button at the top)

Browse to your wav file or whatever you have.

From there you should be able to play the sound both in the pop-up box and (once that is closed) back in the event tab. You'll see the name of the wave in that once empty row (IIRC).

If you want, you can add layers of sounds to this event using the same process over and over, but keeping it simple; we'll just move along.

Now you have a project and an event. You can set various parameters on the first tab that alter pitch etc on the first tab. (When you import the sound, you set whether it is a one shot or looping).

Once you have that done, go to the top drop down and find build. Build the files and you should see extra files in your override directory.

From there, just open up the toolset (or hit refresh from within the toolset) and your project and event sounds should show up in the listing of sounds.

You can then drag and drop them into the game or cutscene and they will play.

== Adding music to cutscenes ==

The way we have been doing the music changes is via placed sound objects. These sound objects are generally created in [[FMOD]], and in FMOD you can say if the music will persist after the cutscene or end when the cutscene ends.

We are just using other sounds to switch music tracks. Designers can add music switch parameter to any sound in Fmod Designer, usually this is just VO line to change music track, for example:

[[Image:FMOD music switch.jpg]]

If there are no other sounds, designers can create empty sound event and add #music parameter there and place this sound on cutscene timeline.
Music track has to be defined in the same group as music in current area in “music.fdp” to work.

[[Image:FMOD music switch 2.jpg]]

<pre>
#music:name,1 – non looping, for stingers
#music:name – for looping music
</pre>

--------------
Another way
--------------

1. Open up '''FMOD''' (fmod comes with dragon age, do a search for fmod in dragon age directory)

2. '''File''' ---> '''New Project''' --> and call the project whatever you want and place it in whatever folder you want.

3. '''Double click''' the '''folder''' under '''Hierarchy''' (purple icon folder) and an event will appear beneath it. Name this event whatever you want. (If there is no event for some reason right click and add one).

4. Now click '''"Event Editor"''' Tab. (Make sure your event was selected before you do this).

5. '''Right click''' one of the open sound fields (find it) and click '''"Add Sound"'''. (just right click all over until you see the option).

6. In this window you will see '''"LOOPING"''' and '''"ONE SHOT"''' on the right hand side. Looping will be selected by default. If you want your music to loop over & over again even after a cutscene is over leave it there. If you want your music to play ONE TIME then select "One Shot".

7. Now it's time to '''pick your music file''' by clicking '''"new wavetable"'''. '''Browse''' to your music file (wav), select it and '''press ok'''.

8. '''VERY VERY IMPORTANT'''.. '''YOU MUST DO THIS STEP'''....... Right click slightly above the timeline and click '''"ADD PARAMETER"'''.

9. Now '''right click''' your new blank parameter, look at the bottom and click '''"PARAMETER PROPERTIES"'''. Another new window will pop up.

10. '''VERY IMPORTANT'''..... Name this parameter:

#duck:music,1000,0,5000,-30

Now click ok.

11. Your new parameter should read: '''#duck:music,1000,0,5000,-30 (Primary)'''

12. Now click '''"Build"''' and do '''"build project"'''.

13. Note the new files in the directory where you saved the project.

14. Copy the '''FEV & FSB''' files from your FMOD project folder '''INTO YOUR OVERRIDE folder'''. I made a folder called music to be organized.

FMODProjectFolder/whatever.fev
FMODProjectFolder/whatever.fsb

COPY TO

Dragon Age\modules\Single Player\override\toolsetexport\music

15. Now open up '''toolset''' and navigate to '''sound palette''' and you should see your new sound file. Type the name of your sound file in the filter to find it faster. (Do not type the folder name in the filter. The filter works by filenames and not folders).

16. Open a '''cutscene''', then left click your new sound file in the right hand sound palette window to select and highlight it. (just a simple left click on it).

17. Now '''left click anywhere in your cutscene''' and a sound icon will be added which is your sound file.

'''Congrats''', 17 steps and now you've added a simple music file to your project and ready for your cutscene. *Sweats*

== Delete resources ==

Resource deletion can sometimes be a bit complicated. Check the following:

*Resources must be checked in when deleted. This is so that the toolset can be sure that all dependencies have been properly resolved.
*If other resources reference the resource it can't be deleted. This means that sometimes you'll need to delete resources in a specific order. For example, you can't delete a creature that's being used in an area, but you could delete the area and then delete the creature. Occasionally there may be circular references that you'll need to break by editing the resources before deleting them. For example:
**A stage can reference an area, which can then reference the stage.
**A plot file can have an associated event script, which will almost certainly include the plot file.
**A stage can reference a creature, which references a dialogue, which references the original stage.

== Removing Modules ==

Deleting a Module from the Toolset
Setup:
I created a module called Meep with a unique id of rcfMeep, added in one area with a waypoint, configured the starting area/waypoint info, and exported it with dependencies. And now I want to strip it out.

Step 1: Removing it from the game

* Navigate to My Documents\Bioware\AddIns
* Delete the folder called rcfMeep
* Done

Removing from the game is fairly easy. The toolset? Not so much. The reason for this is that the information is stored in the SQL Database. Now if you just want to remove the module from the Manage Modules list, that is easy.

* Open Sql Server Management Studio Express. I'm not sure if the default installation installs this or not. If not, it can be downloaded from Microsoft.
* Connect to the BWDATOOLSET server, assuming that you kept the default options.
* Expand Databases
* Expand bw_dragonage_content
* Expand Tables
* Right click and select open on the dbo.Modules table
* This will bring up an excell-like window. Find your module, right-click on the row, and select delete. Say ok to the confirmation.
* Module is now PERMANENTLY removed. Absolutely no way of recovering it.

Now depending on the size of the Module, you just orphaned a bunch of resources. Areas, placables, conversations, they all get placed into the database. And once you remove the module ID, you just lost your ability to remove these resources. Now do keep in mind that 95% of this junk is just text, so it hardly takes up any room. It's not really a major issue. However if you [[How-tos#Delete resources|delete out the resources]] within the toolset before you remove the module reference you should avoid this.

== Override Events (e.g. those in player_core) ==
Look here: [[Event override]]

== Create a lootable placeable that vanishes when looted ==

For a player-usable placeable, use the following event script to make it give its contents to the player and then vanish when clicked on.

<dascript>
#include "wrappers_h"
void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch (nEventType)
{
case EVENT_TYPE_USE:
{
//MoveAllItems(OBJECT_SELF, GetHero());
AddCreatureMoney (1000000, GetHero(), TRUE);
Safe_Destroy_Object(OBJECT_SELF);
}
}
}
</dascript>

If you wanted to use standard resources you could achieve the same thing (though not destroying the placeable) simply by adding "_autoloot" to the end of the placeable's tag.

== Move the player to a new area after a cutscene plays ==

Stand-alone cutscenes have an "end script" parameter that sets a script to run once the cutscene ends. Use a script such as the following:

<dascript>
void main()
{
DoAreaTransition("destination_area_tag", "destination_waypoint_tag");
}
</dascript>
[[category:tutorials]]

2DA ranges in use

2009-12-08T22:16:51Z

Craig Graff:

This page is meant to enumerate row ID ranges that are used by the main game and by various popular addins, to avoid accidental overlap. Note that there's no need for 2DA row IDs to be sequential, so you can use very large row ID numbers to reduce the chances of collision.

Version 1.0 of the toolset has a bug in ExcelProcessor.exe that causes row IDs to become inaccurate when larger than 8 million. This bug will be fixed in the next release of the toolset.

== ABI_base ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-200262'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 568000-568020
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 6 used rows)
|}

----

== APR_base ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-90'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|}

----

== crafting_recipe_types ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-7'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 568000-568010
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 2 used rows)
|}

----

== crafting_recipes ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-91'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 568000-568999
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 326 used rows)
|}

----

== M2DA_base ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-1016, 2000-2010, 10011-10142, ...? '''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 7000000 - 7000050
| FtG - [http://social.bioware.com/project/567/ Ongoing UI Mod Project]
|}

----

== PRCSCR ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 86568000-86568010
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 3 used rows)
|}

----

== placeable_types ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 6549-6700
| PavelNovotny - [http://social.bioware.com/project/517/ Gay Bars of Ferelden]
|}

[[Category:2DAs]]

2DA ranges in use

2009-12-08T22:16:14Z

Craig Graff:

This page is meant to enumerate row ID ranges that are used by the main game and by various popular addins, to avoid accidental overlap. Note that there's no need for 2DA row IDs to be sequential, so you can use very large row ID numbers to reduce the chances of collision.

Version 1.0 of the toolset has a bug in ExcelProcessor.exe that causes row IDs to become inaccurate when larger than 8 million. This bug will be fixed in the next release of the toolset.

== ABI_base ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-200262'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 568000-568020
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 6 used rows)
|}

----

== APR_base ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-90'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|}

----

== crafting_recipe_types ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-7'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 568000-568010
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 2 used rows)
|}

----

== crafting_recipes ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-91'''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 568000-568999
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 326 used rows)
|}

----

== M2DA_base ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-1016, 2000-2010, 10011-10142, ...? '''
| '''Bioware - Main campaign'''
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 7000000 - 7000050
| FtG - [http://social.bioware.com/project/567/ Ongoing UI Mod Project]
|}

----

== PRCSCR ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| 86568000-86568010
| Phaenan's [http://social.bioware.com/project/672/ The Winter Forge] (Currently 3 used rows)
|}

----

== placeable_types ==
{| class="wikitable" border="1"
|-
! Range
! Used by
|-
| '''0-1000000'''
| '''Bioware - reserved'''
|-
| '''6549-6700'''
| '''PavelNovotny - [http://social.bioware.com/project/517/ Gay Bars of Ferelden]'''
|}

[[Category:2DAs]]

2DA

2009-12-07T18:37:55Z

Craig Graff:

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.

ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== 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 the [[2DA_base.xls]] file is actually a prefix. The system reads this prefix and then searches through all the 2DAs for the ones starting with this prefix and merges them together as one 2DA. For example: M2DA Id 0 is "ANIM_". The system looks through its list of 2das and finds "ANIM_base", "ANIM_combat" and "ANIM_walk". It will read and merge all 3 2DAs into an M2DA called "ANIM_".

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

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

== Converting XLS files into 2DA files ==

In the "Dragon Age\tools\ResourceBuild\Processors" folder there is an executable named "ExcelProcessor.exe". This is the file that handles conversions from XLS to 2DA format. Below are described 3 ways in which this file may be used.

=== Drag & Drop Method ===

# Copy ExcelProcessor.exe and source .XLS files to a new directory (not explicitly neccessary, but advised)
# Select source .XLS files and drag them onto ExcelProcessor.exe
# Cut & Paste resulting .2DA files, which will be located in the same directory as the source .XLS files, to your desired location (usually to "My Documents\BioWare\Dragon Age\AddIns\yourmodulename\module\overrides\")

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

Here's an easy way to add a context (ie, right-click) 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>
## For the Steam version, use the following: <tt>"C:\Program Files\Steam\steamapps\common\dragon age origins\tools\ResourceBuild\Processors\ExcelProcessor.exe" "%1" -outdir="C:\Documents and Settings\YOURNAME\My Documents\BioWare\Dragon Age\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.

=== Using a .BAT file ===

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 to the official campaign ===
*[[PRCSCR]] - specifies scripts to run when an area or area list is loaded or entered.

== Adding Strings ==

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

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

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

'''Attention:'''

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

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

== Reserved ID Ranges ==

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

== Users of Open Office ==
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gds file (e.g. placeable_types.gda).

[[Category:2DAs]]

PRCSCR.xls

2009-12-07T17:27:54Z

Craig Graff:

Whenever a player enters an area in an area list in this M2DA the associated script will be run. A modder can therefore include a script with his mod that will be run when the player enters an existing area that he didn't create. This script can freely add or remove placeables and creatures and perform whatever other modifications to the area that a script is capable of doing.

Note that the script will be run every time the player enters the area, so you'll want to have an associated plot flag to ensure that the changes are only made once.

{{2da start|PRCSCR_}}
{{2da column|AreaListName|string|a string that identifies a specific area list, or the special keyword "any".}}
{{2da column|Script|string|the name of a script file to run}}
{{2da end}}

Using "any" in the AreaListName column will trigger the specified script when entering or loading any area.

[[Category:2DAs]]

2DA

2009-12-07T17:24:04Z

Craig Graff:

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.

ExcelProcessor.exe constrains the name length of a worksheet to 27 characters.

== 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 the [[2DA_base.xls]] file is actually a prefix. The system reads this prefix and then searches through all the 2DAs for the ones starting with this prefix and merges them together as one 2DA. For example: M2DA Id 0 is "ANIM_". The system looks through its list of 2das and finds "ANIM_base", "ANIM_combat" and "ANIM_walk". It will read and merge all 3 2DAs into an M2DA called "ANIM_".

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

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

== Converting XLS files into 2DA files ==

In the "Dragon Age\tools\ResourceBuild\Processors" folder there is an executable named "ExcelProcessor.exe". This is the file that handles conversions from XLS to 2DA format. Below are described 3 ways in which this file may be used.

=== Drag & Drop Method ===

# Copy ExcelProcessor.exe and source .XLS files to a new directory (not explicitly neccessary, but advised)
# Select source .XLS files and drag them onto ExcelProcessor.exe
# Cut & Paste resulting .2DA files, which will be located in the same directory as the source .XLS files, to your desired location (usually to "My Documents\BioWare\Dragon Age\AddIns\yourmodulename\module\overrides\")

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

Here's an easy way to add a context (ie, right-click) 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>
## For the Steam version, use the following: <tt>"C:\Program Files\Steam\steamapps\common\dragon age origins\tools\ResourceBuild\Processors\ExcelProcessor.exe" "%1" -outdir="C:\Documents and Settings\YOURNAME\My Documents\BioWare\Dragon Age\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.

=== Using a .BAT file ===

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 to the official campaign ===
*[[PRCSCR]] - specifies scripts to run when an area or area list is loaded or entered.

== Adding Strings ==

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

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

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

'''Attention:'''

* The current version of the "Exelprocessor"-App is buggy as it can't hanlde INT values above 8388607! Many thx to elys for figuring that out.
* Also note that the current toolset core-talktable contains wrong ids as well - don't forget to delete it from the "packages\core\override\toolsetexport" directory.
* Users of Open Office may find that no .gda file is created when they use ExcelProcessor.exe - one workaround is to copy a worksheet from an existing .xls file (such as placeable_types from placeables.xls), process the file, then remove the extraneous .gds file (e.g. placeable_types.gda).

'''Workaround:'''

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

'''Remark:'''

The previous Version stated: ''Take that StringID and add 16777216 to the number.'' this appears to be wrong and is likely a holdover from NWN.

== Reserved ID Ranges ==

While M2DA files avoid some of the problems associated with ordinary 2DA files, the IDs in each row of the final M2DA must still be unique across all 2DAs associated with it.

To help ensure compatibility between authors' custom content, you should make sure that the ranges you choose don't conflict with ones already in use: [[2DA_ranges_in_use]].

[[Category:2DAs]]

Area tutorial

2009-09-09T20:48:25Z

Craig Graff:

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

== Creating the area ==

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

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

<br clear="all" />

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

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

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

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

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

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

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

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

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

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

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

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

== Setting the start point ==

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

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

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

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

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

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

== Area transitions via doors ==

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

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

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

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

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

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

To hook a door up with its frame, simply click and drag the door's hook to a location very close to the matching frame hook. You don't need to get the positioning exact; if the two hooks are close enough together when you release the mouse button they'll automatically snap together. The door will be positioned and reoriented to fit correctly into the frame.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Area transitions via triggers ==

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

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

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

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

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

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

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

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

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

GetEventResource

2009-08-17T22:20:26Z

Craig Graff:

{{dafunction
|name=GetEventResource
|brief=Gets the specified resource on the event.
|param1type=event
|param1name=evEvent
|param1desc=The event to get the resource from
|param2type=int
|param2name=nIndex
|param2desc=The index of the resource to get
|returntype=resource
|returndesc=Returns the specified resource, returns an empty resource on error.
|sourcefile=script.ldf
|sourcemodule=
}}

== Description ==

Gets the specified resource on the event.







== See also ==

[[SetEventResource]]
[[Category: Event functions]]

EVENT TYPE TRANSITION TO WORLD MAP

2009-08-07T05:43:02Z

Craig Graff:

{{event
|when=Player uses the generic transition system to open the world map
|from=
|to= [[module]]
|string0name= sWorldMap
|string0desc{the tag of the map to activate}
|string1name=sTransType
|string1desc={{undocumented}}
|string2name= sWorldMapLoc1
|string2desc={the tag of a map location to activate}
|string3name= sWorldMapLoc2
|string3desc={the tag of a map location to activate}
|string4name= sWorldMapLoc3
|string4desc={the tag of a map location to activate}
|string5name=sWorldMapLoc4
|string5desc={the tag of a map location to activate}
|string6name= sWorldMapLoc5
|string6desc={the tag of a map location to activate}
}}

[[Category:Event types|TRANSITION_TO_WORLD_MAP]]
[[Category:Maps]]

EVENT TYPE TRANSITION TO WORLD MAP

2009-08-07T05:42:05Z

Craig Graff:

{{event
|when=Player uses the generic transition system to open the world map
|from=
|to= [[module]]
|string0name= sWorldMap
|string0desc{{the tag of the map to activate}}
|string1name=sTransType
|string1desc={{undocumented}}
|string2name= sWorldMapLoc1
|string2desc={{the tag of a map location to activate}}
|string3name= sWorldMapLoc2
|string3desc={{the tag of a map location to activate}}
|string4name= sWorldMapLoc3
|string4desc={{the tag of a map location to activate}}
|string5name=sWorldMapLoc4
|string5desc={{the tag of a map location to activate}}
|string6name= sWorldMapLoc5
|string6desc={{the tag of a map location to activate}}
}}

[[Category:Event types|TRANSITION_TO_WORLD_MAP]]
[[Category:Maps]]

EVENT TYPE TRANSITION TO WORLD MAP

2009-08-07T05:40:13Z

Craig Graff:

{{event
|when=Player uses the generic transition system to open the world map
|from=
|to= [[module]]
|string0name= sWorldMap
|string0desc{{the tag of the map to activate}}
|string1name=sTransType
|string1desc={{undocumented}}
|string2name= sWorldMapLoc1
|string2desc={{undocumented}}
|string3name= sWorldMapLoc2
|string3desc={{undocumented}}
|string4name= sWorldMapLoc3
|string4desc={{undocumented}}
|string5name=sWorldMapLoc4
|string5desc={{undocumented}}
|string6name= sWorldMapLoc5
|string6desc={{undocumented}}
}}

[[Category:Event types|TRANSITION_TO_WORLD_MAP]]
[[Category:Maps]]