2009-12-27T19:50:39Z

PavelNovotny: /* lgt */

This will help those that dont want to go through every area layout to find the one they want.
Hope this helps -RandyG

== brc ==
*brc501d - Road with a lake
*brc504d - Mountain road
*brc505d - Road with river and waterfall
*brc999d - Player Camp

== den ==
*den000d - Denerim Burning
*den001d - Denerim Royal Palace
*den005d - Denerim Palace District Arl Estate
*den009d - Haven Village: Shop
*den020d - Denerim: Gnawed Noble Tavern
*den200d - Denerim Alienage: Day
*den200n - Denerim Alienage: Night
*den202d - Denerim Alienage: Alarith's Store
*den207d - House
*den312d - Denerim: The Pearl
*den400d - Denerim Market

*den900d - Den Alienage
*den998d - Denerim Market Warehouse

== hrt ==
*hrt000d - Lothering
*hrt001d - chantry
*hrt002d - Lothering: Dane's Refuge
*hrt201d - highever/cousland castle human noble start
*hrt201n - highever/cousland castle under attack

== lak ==
*lak101 - 110 - shops/rooms
*lak200d- castle exit
*lak201d- redcliff
*lak202d- redcliff-upstairs
*lak203d- dungeon

== lgt ==
*lgt101d - Redcliff: Tavern

Area layouts used in the single player module

2009-12-27T19:50:09Z

PavelNovotny: /* den */

Module tutorial

2009-12-27T18:56:50Z

PavelNovotny:

The simple [[demo module]] that is included with the Dragon Age Toolset is intended to show off a variety of methods that will be commonly used in real stand-alone modules. The documentation on this website will walk you through the major steps required to set it all up, but the [[demo module]] itself also has documentation embedded within it in the form of comments; it is intended to be explored in the designer toolkit and dissected to see how things tick.

One thing that this demo doesn't demonstrate is the art of writing. As such the 'plot' of the adventure is somewhat nonsensical.

This tutorial also assumes that you've read many of the other basic tutorials elsewhere on this site and are familiar with the basic functioning of the toolkit. Links will be provided directing you to more specific information if needed.

== Organization ==

There are two major groups of resources that are used when creating a Dragon Age module; designer resources and art resources. Designer resources are housed in a database whereas art resources take the form of conventional files on your file system.

For your art resources the most convenient approach it is probably to create a directory tree with subdirectories sorting your art resources by what regions of the game they appear in. The directory tree should be someplace easily accessible and with full read/write priviledges - somewhere in your "My Documents" folder is a good place to put them.

In our example we're going to have three areas:
*A swampy outdoor area with a small tavern in it
*The tavern's interior
*An outdoor roadway

=== Naming conventions ===

For the most part the names you give your resources will matter only to you, there are very few situations where the toolset pays attention to the specific form that a resource name takes. So provided you're working on your own, any naming convention that suits your particular style will suffice.

Dragon Age is a large and complex game to create content for, however, so establishing ''some'' form of naming convention and adhering to it from the outset is important to ensure you don't lose track of things later on. A consistent naming system is very useful for debugging and if you later choose to collaborate with other builders it allows you to find your way around other peoples' work without needing to know it intimately.

The convention used in the main Single Player campaign of Dragon Age is as follows:

*Three-letter prefix indicating which large-scale area of the game the resource begins to (particular origin story, prelude, etc)
*three-digit number unique to a particular area, generally starting with 100 and incrementing in hundreds for major areas. Accessory areas are given numbers within the block of one hundred that their 'parent' area belongs to. "global" resources are often given the number 000.
*two-letter code indicating what general type of resource it is (for example "ar" for area, "pl" for placeable). A major exception here is event scripts, which have exactly the same name as the resource they're the script for. Dialogue files are also generally named exactly the same as their owner resource.
*An underscore.
*The remainder of the name is free-form and human-readable, a descriptive term to remind you at a glance what the resource is.

Designer resources will have a three-letter extension, much like a regular file system file, but this is not editable and does not frequently come up.

Resources in the designer toolkit can also be placed into folders, again much like a regular file system. Unlike most file systems, though, you don't need to explicitly create a folder in order to put a resource into it. Just edit the resource's "folder" property and if the folder didn't have anything in it before it'll be created automatically. Folders that don't have any resources in them are removed automatically.

Here's a preview of what we're going to put into the demo module, to illustrate how this naming convention looks in practice. We'll be using the four-letter prefix "demo" instead of the usual three-letter one for clarity.

[[screenshot of demo resource palette]]

== Setting up character generation in a new module ==

The most basic steps of creating a new module are described in "[[creating a module]]". A Dragon Age module, when first created, lacks many very basic components such as the ability to generate a character or an area to start in.

Note that you can actually start creating areas and testing content before you set up character creation if you prefer, the game will provide a player with a simple (and very weak!) default character if character generation isn't performed. You can also override the default starting area and waypoint every time you export for testing purposes, using the "Export Options" found under the "Tools" menu, so you can skip directly to the area you're working on without needing to write debugging scripts.

We're going to follow the flow of the finished game for now, though, so after creating the module the first thing we'll want to do is create a module script that triggers character generation.

Once you've created the initial empty module you'll need to create a module script. We call it "demo_module". The event that we'll want to handle character generation in is EVENT_TYPE_MODULE_START, which is sent to the module script only once when the game is first started up.

To call the default character generation system, simply have this event call the following functions:

<pre>
PreloadCharGen();
StartCharGen(GetHero(),0);
</pre>

PreloadCharGen causes the game to load up various resources that will be used in character generation, and StartCharGen causes the game to show the character generation GUI to the player.

== Creating our areas ==

This module will be very simple, consisting of only three areas - only two of which will have any signficiant amount of detail. They will be named:

* demo100ar_wilderness
* demo200ar_tavern
* demo300ar_road

Three level layouts ([[LVL]] files) are included with the module for use in these areas; ost101d (a swampy wasteland with a small wooden structure), hrt002d (a small tavern interior), and lgt600d (a section of roadway). The naming convention for level layouts used internally at BioWare is specific to the single player campaign, the meaning of these filenames is not relevant to this basic tutorial.

The area editor (and the game itself) cannot use a LVL file directly, it must be compiled into a more efficient form for use. Open up each LVL file in the level editor and, under tools, select "Post to local" to compile the level and export it to an appropriate directory where the game and toolset will be able to find it.

Once you've done this you can select the layout in the area editor's "Area Layout" property field.

== Placing area transitions and setting up the world map ==

See the [[Area tutorial]] for details on how to link areas up with level transitions. The transition from demo100ar_wilderness to demo200_tavern is straightforward and is basically the same as what's shown in that tutorial.

The transition between demo100ar_wilderness and demo300ar_road, however, is going to be handled via the world [[map]] instead. The demo's map is a resource named demo000mp_world.

To create an area transition that sends the player to the world map, set the PLC_AT_DEST_AREA_TAG to the string "world_map". The placeable_core script recognizes this string as a special override that triggers a map transition by sending the module script an EVENT_TYPE_BEGIN_TRAVEL event.

Note that you can have multiple world maps in a module, but under the default code you can't directly specify which one an area transition will send the player to. Instead, you will need to call the script function WR_SetWorldMapPrimary to specify which world map is the currently active "primary" one. In this demo the code that performs this is also in the EVENT_TYPE_MODULE_START event of the module script, since we only have one map and it only needs to be set as primary once. If you have multiple maps in your module you'll need to call this function again later from some other scripted event to change it.

Here, then, is the complete code for the demo module's EVENT_TYPE_MODULE_START event:

<pre>
case EVENT_TYPE_MODULE_START:
{
object oMapId = GetObjectByTag("demo000mp_world");
WR_SetWorldMapPrimary(oMapId);

PreloadCharGen();
StartCharGen(GetHero(),0);
break;
}

</pre>

Although the default placeable_core script has code in it to recognize that the "world_map" string should lead to a world transition and generates an EVENT_TYPE_BEGIN_TRAVEL event, the default module_core script doesn't actually do anything with this event. This is because the map transition code used in Dragon Age's single player world map transitions is rather complex and has to handle many special cases that depend on plot elements specific to the single player campaign, so BioWare never implemented a basic default - it would have had to be overridden completely anyway.

Fortunately it's quite easy to add one, though there's a slight hitch; the area transition code needs to be split over two different events.

* In EVENT_TYPE_BEGIN_TRAVEL you'll be able to get the target area and waypoint tags from the event object, and then call the <pre>WorldMapStartTravelling</pre> function to cause the map to start animating the map trail path the player is following.

* While the map trail animation is playing, the EVENT_TYPE_WORLDMAP_PRETRANSITION event is called. This is the event where you'll want to call the <pre>UT_DoAreaTransition</pre> function to start the loading process of the destination area. The area will load at the same time that the map trail animation is playing, making the transition seem more seamless for the player. Note, however, that EVENT_TYPE_WORLDMAP_PRETRANSITION's event object ''doesn't'' contain the destination area and waypoint tags as members; you'll need to use local variables in the module's variable table to preserve these strings and pass them on from EVENT_TYPE_BEGIN_TRAVEL.

The basic code to handle map travel, then, is:

<pre>
////////////////////////////////////////////////////////////////////////
// Sent by: The engine
// When: the player clicks on a destination in the world map
////////////////////////////////////////////////////////////////////////
case EVENT_TYPE_BEGIN_TRAVEL:
{
string sSource = GetEventString(ev, 0); //area tag source location
string sTarget = GetEventString(ev, 1); // area tag target location
string sWPOverride = GetEventString(ev, 2); // waypoint tag override
if (sSource != sTarget)
{
//store target area's tag to a local module variable
SetLocalString(GetModule(), "WM_STORED_AREA", sTarget);
//store target waypoint tag
SetLocalString(GetModule(), "WM_STORED_WP", sWPOverride);
//initiate the map's travelling animation. The engine will
//send EVENT_TYPE_WORLDMAP_PRETRANSITION once it's started.
WorldMapStartTravelling();
}
}

////////////////////////////////////////////////////////////////////////
// Sent by: The engine
// When: the world map has begun its "travelling" animation
////////////////////////////////////////////////////////////////////////
case EVENT_TYPE_WORLDMAP_PRETRANSITION:
{
//retrieve the target area tag we stored in EVENT_TYPE_BEGIN_TRAVEL
string sArea = GetLocalString(GetModule(), "WM_STORED_AREA");
//retrieve the target waypoint tag
string sWP = GetLocalString(GetModule(), "WM_STORED_WP");
//execute the area transition to that target.
UT_DoAreaTransition(sArea, sWP);
break;
}
</pre>

We'll need to come back to the module script later on to add some plot-specific code, but for now this is all that's needed to enable a basic adventure to stand on its own.

== Introductory cutscene ==

After the player has finished character generation we play an introductory cutscene for him before the game starts.

The cutscene itself is quite simple, consisting of a few camera movements and an actor (substituted by the player) playing a walking animation. See [[cutscene tutorial]] for how to create a cutscene.

To make it play when the game begins we need to call it at the appropriate time with the CS_LoadCutscene function. The appropriate time has to be after the area that the cutscene is located in as loaded, otherwise the cutscene won't be able to play. The event that's best suited for this is EVENT_TYPE_AREALOAD_SPECIAL, which is called on an area's event script after the area has loaded but before any of the other game systems (AI and so forth) have been enabled. So in this case we want to insert the function call into the area script for the starting area, demo100ar_wilderness. We only want the cutscene to play the first time we enter this area so we've wrapped the function call in a plot flag check;

<pre>
case EVENT_TYPE_AREALOAD_SPECIAL:
{
if (!WR_GetPlotFlag(PLT_DEMO000PL_MAIN, DEMO_INTRO_COMPLETE))
{
CS_LoadCutscene(R"demo100ct_intro.cut");
WR_SetPlotFlag(PLT_DEMO000PL_MAIN, DEMO_INTRO_COMPLETE,TRUE); //sets the plot flag to ensure we don't repeat the intro cutscene.
}
break;
}
</pre>

== The main plot file ==

For this demo module, all of the major events relating to the development of the plot are kept track of in the demo000pl_main plot file. This also allows for a centralized place to put scripting that deals with these events.

The plot outline of the demo module is:

#Player encounters the innkeeper outside his inn and speaks with him, receiving the quest to retrieve the innkeeper's sword.
#Player enters the inn. As he approaches the lever that will open the door to the room the sword is in, the bandit that's taken over the inn initiates conversation with the player. This leads to combat.
#Player pulls the lever, blowing up the door to the room the sword is in
#Player retrieves the sword
#Player returns the sword to the innkeeper, who offers to join the party. A new area also opens up on the world map at this point.

We'll cover each of these events in a separate section of this documentation.

You may also note that many of the constants used in the code have been separated out into a "demo_consts_h" script file, even if they are only currently used in one particular place. This is not strictly necessary, and in fact the toolset doesn't recognize the "_h" suffix as having any special significance; whenever you save an _h script the toolset will try to compile it and complain about the lack of a main() or StartingConditional() function (you can ignore this complaint). However, it makes typos much easier to find and debug, and should you need to change a constant later on this approach ensures that you can always catch every instance of it.

== Giving the player an item ==

The first thing that happens if the player talks to the barkeep and accepts the quest is that the barkeep will give him a key. The key is a "plot item", meaning it will be shown in a separate section of the player's inventory and can't be given away or destroyed by the player, but the mechanism used here can give the player non-plot items as well.

The function UT_AddItemToInventory takes a resource variable as its parameter. It causes a new instance of the item to be created and added. If you call it multiple times with the same resource, earlier copies won't be affected - multiple copies of the item will be created. You'll see one way of removing an object from the player's inventory at the end of the quest when the innkeeper takes back his sword.

== Using a trigger to initiate conversation ==

We want the bandit and his loyal patrons to attack the player before the lever can be pulled. A trigger has been placed in such a manner that the player will have to pass through it before reaching the lever; the trick is now to use that trigger to make the things we want to have happen, happen.

When a trigger is entered by any entity the trigger's event script is sent an EVENT_TYPE_ENTER event. Note that this is sent ''every'' time the trigger is entered, by ''any'' entity, so the first thing we'll need to do in the event script is a test to ensure that the triggering entity is the player or one of his party members.

The IsPartyMember function tests to see whether an object is player-controllable, which is true for the player's character and for any creature currently in the player's party. We call it on the event's creator to check if this is the right person; if it's not the event script does nothing.

If we wanted the bandit and patrons to simply charge and attack the player, we'd have the trigger call UT_TeamGoesHostile(BANDIT_TEAM); directly (the bandit and patrons' creature templates are all set to the same team so that we don't need to set each one hostile individually). In this case an unexplained attack would be strange, so instead a conversation has been set up that has the bandit and patrons explain themselves before attacking. So we've set the trigger script to call UT_Talk instead.

Once this has been called, we never want the trigger to fire again for anyone. It is important to note that setting a trigger to "inactive" will ''not'' work; an inactive trigger still fires EVENT_TYPE_ENTER whenever an entity enters it. There are several approaches that can be used here:

*Set the event script to check the trigger's active status and not perform any action if it's inactive
*Use a plot flag to make the code only fire once
*call Safe_Destroy_Object(OBJECT_SELF, 0); to destroy the trigger entirely

Since there will be no circumstances where we'll need the trigger to become active again in the future, destroying the trigger is the simplest and most foolproof way of accomplishing this.

== Using a placeable to call a script ==

The lever placeable has a "use" option that allows the player to flip it from one state to the other. When this happens an EVENT_TYPE_USE event is sent to the placeable's event script. We've added a custom event script to the lever to intercept this event and do something special; demo200pl_security_lever.nss.

Rather than handling all the details of what should happen when the lever is pulled right in this script, though, we've instead put them into the main plot file's script. The custom placeable script serves only to set the appropriate main plot file flag.

== Troubleshooting ==

=== Failure to exit combat mode after defeating the bandits in the inn ===

Try clearing out the folder My Documents\BioWare\Dragon Age\packages\core\override. As of version 1.0.982.0 of the Dragon Age Toolset, the export process deposits certain files to that override folder, which is currently causing conflicts within the game. One immediate indication of this may be that the player character is initially in their undergarments during character generation.

[[Category:Tutorials]]

Module tutorial

2009-12-27T18:56:18Z

PavelNovotny:

Area layouts used in the single player module

2009-12-27T18:52:15Z

PavelNovotny: Added more links

This will help those that dont want to go through every area layout to find the one they want.
Hope this helps -RandyG

== brc ==
*brc501d - Road with a lake
*brc504d - Mountain road
*brc505d - Road with river and waterfall
*brc999d - Player Camp

== den ==
*den000d - Denerim Burning
*den001d - Denerim Royal Palace
*den005d - Denerim Palace District Arl Estate
*den009d - Haven Village: Shop
*den020d - Denerim: Gnawed Noble Tavern
*den200d - Denerim Alienage: Day
*den200n - Denerim Alienage: Night
*den202d - Store
*den207d - House
*den312d - Denerim: The Pearl
*den400d - Denerim Market

*den900d - Den Alienage
*den998d - Denerim Market Warehouse

== hrt ==
*hrt000d - Lothering
*hrt001d - chantry
*hrt002d - Lothering: Dane's Refuge
*hrt201d - highever/cousland castle human noble start
*hrt201n - highever/cousland castle under attack

== lak ==
*lak101 - 110 - shops/rooms
*lak200d- castle exit
*lak201d- redcliff
*lak202d- redcliff-upstairs
*lak203d- dungeon

== lgt ==
*lgt101d- Redcliff: Tavern

Area layouts used in the single player module

2009-12-27T18:47:27Z

PavelNovotny: /* Den */ Added more links

This will help those that dont want to go through every area layout to find the one they want.
Hope this helps -RandyG
== brc ==
*forrest

== Den ==
*den000d - Denerim Burning
*den001d - Denerim Royal Palace
*den005d - Denerim Palace District Arl Estate
*den009d - Haven Village: Shop
*den020d - Denerim: Gnawed Noble Tavern
*den200d - Denerim Alienage: Day
*den200n - Denerim Alienage: Night
*den202d - Store
*den207d - House
*den312d - Denerim: The Pearl
*den400d - Denerim Market

*den900d - Den Alienage
*den998d - Denerim Market Warehouse

== hrt ==
*hrt000d - Lothering
*hrt001d - chantry
*hrt002d - inn
*hrt201d - highever/cousland castle human noble start
*hrt201n - highever/cousland castle under attack

== Lak ==
*lak101 - 110 - shops/rooms
*lak200d- castle exit
*lak201d- redcliff
*lak202d- redcliff-upstairs
*lak203d- dungeon

Design

2009-12-27T18:40:40Z

PavelNovotny: /* Database resources */

The Dragon Age toolset has two main classes of resource; designer resources that are stored in a [[database]] and art resources that are stored as files in your filesystem.

See [[resource list]] for a comprehensive list of all of the resource types.

== Database resources ==

Resources stored in the toolset's accompanying database are for the most part focused on the mechanics of the game - the stuff that makes an adventure "work".

* The [[resource palette]] details the main interface for selecting designer resources for editing.

*[[Creating new resources]]
*[[Deleting resources]]
*[[Modifying resources]]

*[[String editor]] - A tool that allows quick and easy access to all text that might be presented to the player in the game.

* [[Builder to builder]] - The mechanisms used by the toolset that allow packages of game resources to be shared between multiple collaborating builders. This is not intended for [[builder to player]] packaging, which produces installable files suitable for distribution to end users.

*[[Exporting and running a module]]

*[[ToolSet: Area Layouts]]

*[[Single Player Campaign Map Pin List]]

== Art resources ==

*[[Level editor]] (note that this is distinct from the [[Area]] editor)
*[[Morph]]s are generated with the face-morphing tool.
*[[FMOD]] generates sounds.
*[[FaceFX]] handles facial expressions and lip-synching.
*[[Animation blend tree editor]]
*[[Material editor]]
*[[VFX editor]]
**[[VFX list]] lists visual effects in Dragon Age's library.

Design

2009-12-27T18:40:04Z

PavelNovotny: /* Database resources */ Added links to Original Campaign Area Layouts and Map Pin List

The Dragon Age toolset has two main classes of resource; designer resources that are stored in a [[database]] and art resources that are stored as files in your filesystem.

See [[resource list]] for a comprehensive list of all of the resource types.

== Database resources ==

Resources stored in the toolset's accompanying database are for the most part focused on the mechanics of the game - the stuff that makes an adventure "work".

* The [[resource palette]] details the main interface for selecting designer resources for editing.

*[[Creating new resources]]
*[[Deleting resources]]
*[[Modifying resources]]

*[[String editor]] - A tool that allows quick and easy access to all text that might be presented to the player in the game.

* [[Builder to builder]] - The mechanisms used by the toolset that allow packages of game resources to be shared between multiple collaborating builders. This is not intended for [[builder to player]] packaging, which produces installable files suitable for distribution to end users.

*[[Exporting and running a module]]

*[[Toolset: Area Layouts]]

*[[Single Player Campaign Map Pin List]]

== Art resources ==

*[[Level editor]] (note that this is distinct from the [[Area]] editor)
*[[Morph]]s are generated with the face-morphing tool.
*[[FMOD]] generates sounds.
*[[FaceFX]] handles facial expressions and lip-synching.
*[[Animation blend tree editor]]
*[[Material editor]]
*[[VFX editor]]
**[[VFX list]] lists visual effects in Dragon Age's library.

Design

2009-12-27T18:36:22Z

PavelNovotny: /* Database resources */

The Dragon Age toolset has two main classes of resource; designer resources that are stored in a [[database]] and art resources that are stored as files in your filesystem.

See [[resource list]] for a comprehensive list of all of the resource types.

== Database resources ==

Resources stored in the toolset's accompanying database are for the most part focused on the mechanics of the game - the stuff that makes an adventure "work".

* The [[resource palette]] details the main interface for selecting designer resources for editing.

*[[Creating new resources]]
*[[Deleting resources]]
*[[Modifying resources]]

*[[String editor]] - A tool that allows quick and easy access to all text that might be presented to the player in the game.

* [[Builder to builder]] - The mechanisms used by the toolset that allow packages of game resources to be shared between multiple collaborating builders. This is not intended for [[builder to player]] packaging, which produces installable files suitable for distribution to end users.

*[[Exporting and running a module]]

*[[Single Player Campaign Map Pin List]]

== Art resources ==

*[[Level editor]] (note that this is distinct from the [[Area]] editor)
*[[Morph]]s are generated with the face-morphing tool.
*[[FMOD]] generates sounds.
*[[FaceFX]] handles facial expressions and lip-synching.
*[[Animation blend tree editor]]
*[[Material editor]]
*[[VFX editor]]
**[[VFX list]] lists visual effects in Dragon Age's library.

Placeable tutorial

2009-12-15T03:21:03Z

PavelNovotny:

In Dragon Age, "[[placeable]]s" are objects that a player can interact with or are objects simply added to the area to create greater detail. They are added to areas simply by dropping them into the area landscape. Once placed, they can easily be moved into position or rotated on their axis to achieve the look you want.

In general, placeables can serve a wide variety of functions. They can render popup text. They can be destroyed or bashed or hold inventory or treasure within. They can be holders of conversations. In this tutorial we'll mainly stick to the basics, but placeables are an important part of any area design.

== Creating A Placeable ==

Similar to creating anything within the toolset, go to File > New > Placeable or right click in the Palette Window to access the New Placeable option.

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

The first step is naming the placeable. We'll need a door for the tutorial so lets start with a door that will serve as an area transition. Name the placeable "transition_door". Luckily and unluckily, the default object is a door. The lucky part is that it is a door. The unlucky part is that this is a non-area transition door. There are two types of doors, ones that open and allow for an area transition and ones that simply open. For the upcoming [[area tutorial]] we need a door that will allow the player to move from outside the hut to inside the hut.

Doors that allow transitions are all grouped under the Appearance beginning with "Area Transition". Change the appearance to be "Area Transition, Ferelden, Small". The placeable has the exact same appearance it had but now it will be able to function as an area transition. For more detail on doors, please see [[door]]s. They are a bit unique within the placeable world so it is important to understand how the two types function as well as some of the finer options that are available.

Note that when you are placing an area transition door, the arrow should point in the direction you are going to travel. When placing a standard door the arrow points in the direction the door will open.

As you can see, placeables are straightforward and easy to create. Let's build one more for our module before moving along with the tutorial. Again create a new placeable and let's name it "statue". Any good exterior can always use a statue. For this lets set the appearance to "Statue, Giant" and rename the placeable "Huge Statue". By default, the placeable is "Interactive" so let's toggle that setting to false:
'''Scroll down to Stats; locate Interactive;'''
Use the drop down menu OR just double click on TRUE to toggle the state.
Now our statue is ready to be placed. It is basically an addition to the landscape. It won't be something you can interact with but it can add detail to your area and to your story.

While we are in the tutorial, let's quickly cover checking in and checking out resources which is a new concept for Dragon Age. For a more detailed summary, please see [[Resource palette]]. Briefly, in Dragon Age resources are stored within databases. When you work on a module and alter any existing work or create new work, you are creating an instance of the object (be it a placeable, item, creature, area etc.). There are a number of benefits for this that are beyond the scope of this tutorial but when you edit something, it has to be "checked out" (or never checked in) with you working on an instance.

For example, select your new statue and right click and you will see that many common tasks are NOT available because it has not been "[[checked in]]" to the database. For example, you can't rename or delete the placeable. In order to rename the placeable, we'll need to check in the placeable. Right click and select check in. Check the box for no comment or enter a comment and hit ok. At this point, the resource has been written to the database. Once the object is "checked in" you can adjust the name or delete it if you so choose (assuming it doesn't have other dependent resources).

== Placing / Adjusting your Placeable ==

That is a brief overview of how to create your first placeables. Now let's cover putting them into your module. To place a placeable, simply bring up an area (which we will make in the [[Area Tutorial]]), then highlight the placeable (which can be found by clicking on the table image in the palette window) and left-click within the region.

To adjust the position or orientation of the object, you'll need to use the Camera and Movement Toolbar:

[[Image:Camera and movement toolbar labeled.png]]

To adjust the x,y,z position either activate the Local Coordinates button [[Image:IconLocalCoordinates.png]] or use the keyboard shortcut 'q'. With this activated, you can mouse over any axis (notice the change to the yellow highlight) and the object will move only in the selected dimension.

To adjust the rotational orientation, highlight the 3 Axis Rotation button [[Image:Icon3AxisRotation.png]] or use the keyboard shortcut 'e'. In a similar fashion, you can easily selected and adjust the rotational orientation of the placeable.

'R' is the keyboard shortcut to return to the standard selection tool [[Image:IconStandardSelection.png]].

(For much more detail regarding 3D controls please see the [[3D control]] page).

Of course, you can use the Object Inspector to type in exact numbers for any of these parameters you choose. Simply ensure the object is selected within the area viewer and type in your changes.

== Field Notes ==

*'''Character''': Mapping a character to a placeable is done for VO when a placeable owns a conversation.

[[Category:Placeables]]
[[Category:Tutorials]]

Area tutorial

2009-12-15T03:12:13Z

PavelNovotny: /* Sound */

== Creating the area ==

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

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

 

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.

Sometimes the Area Editor may show your level as a wireframe when you create it. You can switch from a wireframe view to a normal view by going to the View menu and choosing View/Environment/Render Mode/Normal.

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. Note that the list will show waypoint tags rather than names. Again, we've only put in one so this will be easy. You can also set the player to appear at the origin of the map (coordinates 0,0,0), but this is generally a poor choice and available only as a default in case there are no waypoints defined yet.

== Area transitions via doors ==

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

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

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

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

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

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

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

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

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

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

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

*PLC_AT_DEST_AREA_TAG - tag of the destination area
*PLC_AT_DEST_TAG - tag of the destination waypoint within the destination area. This is a waypoint that you must add. It is NOT added automatically when you create the door.

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

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

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

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

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

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

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

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

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

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

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

== Area transitions via triggers ==

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

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

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

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

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

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

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

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

== Grouping Placeables ==

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

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

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

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

== Sound ==

Sounds are placed using the Area Editor. For more details see [[Sound]].

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

Area tutorial

2009-12-15T03:11:38Z

PavelNovotny:

Creating a custom placeable from a model tutorial

2009-12-13T23:07:50Z

PavelNovotny: /* Edit your MMH and PHY files */

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA]] page describes the process of creating the 2da file that you will need.

The columns you need to edit (or at least check) in the spreadsheet are ID, Label (something meaningful to you - does not have to be unique), ModelName (the name of your MMH file), OcclusionFactor (optional), StateController, and baseType (values are listed on the first tab in the excel file).

Check the [[2DA ranges in use]] page to make sure you are not using row IDs in your 2da file that will conflict with the core game or other popular modules.

The StateController field is very important because it determines the type of action that can be used with your placeable in game. For example, Informational objects can be examined, but cannot launch dialog. Puzzle items can launch a dialog. Think about what you want your placeable to do and choose the StateController to match it.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of characters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1. (This is the field that tells the toolset and the game to use your object as a placeable, making it clickable.)
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0. (This field tells the toolset and the game that your object is a prop and is not clickable.)
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable tutorial]] page.

Creating a custom placeable from a model tutorial

2009-12-13T23:06:13Z

PavelNovotny: /* Change the names of your MAO, MMH, and PHY files */

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA]] page describes the process of creating the 2da file that you will need.

The columns you need to edit (or at least check) in the spreadsheet are ID, Label (something meaningful to you - does not have to be unique), ModelName (the name of your MMH file), OcclusionFactor (optional), StateController, and baseType (values are listed on the first tab in the excel file).

Check the [[2DA ranges in use]] page to make sure you are not using row IDs in your 2da file that will conflict with the core game or other popular modules.

The StateController field is very important because it determines the type of action that can be used with your placeable in game. For example, Informational objects can be examined, but cannot launch dialog. Puzzle items can launch a dialog. Think about what you want your placeable to do and choose the StateController to match it.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of characters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1.
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0.
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable tutorial]] page.

Creating a custom placeable from a model tutorial

2009-12-12T16:20:59Z

PavelNovotny:

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA]] page describes the process of creating the 2da file that you will need.

The columns you need to edit (or at least check) in the spreadsheet are ID, Label (something meaningful to you - does not have to be unique), ModelName (the name of your MMH file), OcclusionFactor (optional), StateController, and baseType (values are listed on the first tab in the excel file).

Check the [[2DA ranges in use]] page to make sure you are not using row IDs in your 2da file that will conflict with the core game or other popular modules.

The StateController field is very important because it determines the type of action that can be used with your placeable in game. For example, Informational objects can be examined, but cannot launch dialog. Puzzle items can launch a dialog. Think about what you want your placeable to do and choose the StateController to match it.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of letters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1.
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0.
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable tutorial]] page.

Creating a custom placeable from a model tutorial

2009-12-12T16:20:34Z

PavelNovotny: Added more info on the 2da file.

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA]] page describes the process of creating the 2da file that you will need.

The columns you need to edit (or at least check) in the spreadsheet are ID, Label (something meaningful to you - does not have to be unique), ModelName (the name of your MMH file), OcclusionFactor (optional), StateController, and baseType (values are listed on the first tab in the excel file).

Check the [[2DA ranges in use]] page to make sure you are not using row IDs in your 2da file that will conflict with the core game or other popular modules.

The StateController field is very important because it determines the type of action that can be used with your placeable in game. For example, Informational objects can be examined, but cannot launch dialog. Puzzle items can launch a dialog. Think about what you want your placeable to do and choose the StateController to match it.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of letters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1.
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0.
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable tutorial]] page.

Creating a custom placeable from a model tutorial

2009-12-12T16:11:08Z

PavelNovotny: Changed a link

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA]] page describes the process of creating the 2da file that you will need.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of letters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1.
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0.
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable tutorial]] page.

Creating a custom placeable from a model tutorial

2009-12-12T16:06:51Z

PavelNovotny: Fixed a link

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA]] page describes the process of creating the 2da file that you will need.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of letters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1.
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0.
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable]] page.

Tutorials

2009-12-12T16:02:02Z

PavelNovotny: Added a link to the Creating a custom placeable from a model tutorial

==Introductory tutorials ==

In the course of these tutorials we'll go through all the steps needed to create a basic adventure.

{{sidebox|
*Boxes like this contain a checklist of important steps.
*They're intended as a reminder and as a navigational aid.
}}

*[[Introductory tutorial]] - An overview of the toolset as a whole
*[[Module tutorial]] - how to create a module to work in.

This set of tutorials forms a series, each building on or filling in omissions by the last:
*[[Area tutorial]]
*[[Placeable tutorial]]
*[[Item tutorial]]
*[[Creature tutorial]]
*[[Conversation tutorial]]

Once you've become familiar with the basics introduced on those tutorials you might have a better grounding for:
*[[Cutscene tutorial]]
*[[Map tutorial]] (which also introduces you to [[2DA]] editing)
*[[Level Editor Tutorial]]
*[[Scripting tutorial]]

== Demo module ==

The toolset currently ships with a simple demo module pre-loaded into its database.

*[[Demo module]] - how to export and run the demo module.

== Custom content tutorials ==
*[[Tutorial: Adding a Custom Model to Toolset]]
*[[Tutorial: Creating a custom placeable from a model]]
*[[Tutorial: Reskinning an Item]]

== Character generation tutorials ==
*[[Backgrounds tutorial]]
*[[Add A New Class Tutorial]]

== Other Tutorials ==
*[[Adding a Location to the Single Player Campaign Tutorial]]

== External Tutorials ==
*[http://dragonagemodding.wordpress.com Beyond Ferelden] has many in-depth tutorials by jwvanderbeck.
*[http://www.youtube.com/watch?v=TwQNRBFLhrE Playable Area and Conversation] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=CaHldJcUTz8 Simple Conversation Cameras] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=QOQJ2heQto4 Cutscene and Trigger] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=szWKgj2ZuXo Custom Level and Room Building] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=DKJ7F14n8o8 Downloading and Installing the Toolset] video tutorial by [http://social.bioware.com/74287/ DragonAge22].
*[http://www.youtube.com/watch?v=iMPBsulv9xI Creating a Room] video tutorial by [http://social.bioware.com/74287/ DragonAge22].
*[http://www.youtube.com/watch?v=g3kx2CaarHo How to Make an Interior Level with Lighting] video tutorial by [http://social.bioware.com/group/60/ Darkworld Development Team].
*[http://www.youtube.com/watch?v=O6TeZeE1Lc8 Making a Room] video tutorial by BigDrip681.
*[http://social.bioware.com/5339/blog/576/ Custom Player Items In Single Player] by [http://social.bioware.com/5339/ weriK].
*[http://social.bioware.com/5339/blog/651/ The Secret Behind Item Statistics] by [http://social.bioware.com/5339/ weriK].
*[http://social.bioware.com/project/923/ Guide for installing/uninstalling/updating Mods] Beginner Guide to get started with using Mods by [http://social.bioware.com/237411/ Alexspeed].
*[http://www.jezelf.co.uk/tutorials.htm Photoshop Map making tutorials] Credits to Jason Elford, brought to DAT wiki by [http://social.bioware.com/48156/ Arixsus]
*[http://social.bioware.com/project/527/ Video Tutorials by SilentCid] Multiple in-depth video tutorials of the DA Toolset
*[http://www.youtube.com/view_play_list?p=EF29DD1AACEBA92A Qkrch's Video Tutorials] Toolset tutorial complete series for the experienced builder (Spanish & English)
[[Category:Tutorials| ]]

Creating a custom placeable from a model tutorial

2009-12-12T16:00:52Z

PavelNovotny: Created this page

This tutorial describes how to create a custom [[Placeable]] based on a [[Model]] that is already active in your toolset. This process should work with any model, whether custom or packaged with the game. It is assumed that the reader is familiar with the Toolset.

__TOC__

==Set-up your [[2DA]] file==

The [[Placeables.xls]] file contains the placeable_types xls sheet that you will need to edit. The [[2DA or not 2DA - Overriding 2DA files]] article describes the process of creating the 2da file that you will need.

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override.

Tip: Excel Processor will generate a GDA file for every tab (xls sheet) within the 2da/m2da. You do not need all of these. Only keep the one that you edited (in this case it would be placeable_types) and place that one in the override folder.

==Extract model files==

Use DATool by Adinos ([[http://social.bioware.com/project/41/]]) to extract the DDS, [[MAO]], PHY, [[MMH]], and [[MSH]] files for the model you want to make into a placeable. Put them some place easy to access so you can work on them.

== Change the names of your MAO, MMH, and PHY files ==

Change the names of your MAO, MMH, and PHY files so that they start with plc_ instead of prp_. The new name must have the same number of letters as the old name.

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

*In <MaterialObject Name="filename"> change filename to the new name of the MAO file.
*In <Material Name="static.mat"> replace static.mat with Prop.mat.
*Delete the line that starts with <Texture Name="mml_tLightmap
*Delete the line that starts with <SoundType Name=
*Add a line that says <Texture Name="mml_tTintMask" ResName="Default_White.dds"></Texture>
*Save and close the MAO file.

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Save and close the MMH file.

Open your new PHY file.

*Change MMH_NAME to the name of your new MMH file.
*Change MMH_NODE_COLLISION_OBJ_TYPE from 2 to 1.
*Change MMH_SHAPE_COLLISION_MASK_PLACEABLES from 0 to 1.
*Change MMH_SHAPE_COLLISION_MASK_STATIC_GEOMETRY from 1 to 0.
*Save and close the PHY file.

Close your toolset.

== Put files in override folder ==

Put your new MAO, MMH, and PHY files in Dragon Age/Packages/Core/Override.

== Create your custom placeable ==

You can now create a new placeable in the toolset using your model. The process of creating a new placeable is described in the [[Placeable]] page.

2DA ranges in use

2009-12-09T00:34:52Z

PavelNovotny: Changed my reserved range for placeable_types

Lighting

2009-12-08T17:14:08Z

PavelNovotny: Andded a note about using one ambient light per level.

{{Infobox level editor}}

There are many different types of lighting and light combinations that can be placed in the editor.

There are also many tools used to create lighting and generate lighting and even visualize lighting in the editor. The goal with the editor is to give the artist the same experience as he/she would see in the game. This will help them to be able to create the levels and tweak lighting quickly without having to stop to see it in-game.

== Lights ==

Lights for the game are split into two categories based on what they affect: levels and characters. Character lights will affect the player, NPCs, and creatures. The level lights will affect static geometry and designer placeables.

The game supports several different light types, with the purpose of balancing quality vs performance. To understand the use of the light types, one must first know the general lighting equation:

Diffuse = DynamicAmbient + F(DynamicLights, DynamicShadows) + ( LightmapRGB + LightmapShadowMap * F(StaticLights , DynamicShadows) )

Where F is the function which calculates light contribution given the dynamic shadow map.

Light Effect:

* Baked: This is lighting that only affects things in the level layout. The player will not be lit by this. Its contribution to the lighting scene is encoded in the lightmap RGB.
* Dynamic: This only affects the Player Character. The dynamic lights will light all geometry without regard for baked shadow maps. They still however, respect the dynamically generated shadowmap.
* Static: This is lighting that is both baked and dynamic. The most “expensive” of the light types. Static lights are those that don’t move. This provides the opportunity to bake in the shadow contribution of that light into the lightmap. Multiple static lights will mix together in this baked-shadow map. No RGB contribution from the light will go into the lightmap when rendering lightmaps. During run-time, the game will calculate the RGB color of the static light and then only apply it in areas that are uncovered by the baked-shadow map. Characters and placeable props are fully lit by the static lights.
* Animated: Animated lights are those that don’t move about, but do have animation properties on their light intensity. These lights are baked into the shadow map.

Light Type:

* Point: The light originates from a spot. “Light Size” corresponds to the size of the object casting off light. “Num Samples” is the number of shadow render passes – the higher the number the “crisper” the shadows.
* Ambient: This is ever-present light that affects everything. Ambient lights effect an entire level, even when there are multiple rooms. You can only use one ambient light per level.
* Spot: This is directional light. To move the location of the light right click on the icon at the end of the effect. You will then see arrows that allow you to move it around.

Only dynamic lights will affect placeables placed in the design tool. So a designer chest will not be lit properly next to a chest placed in the art tool. That’s a limitation of the engine. Any object that is animated has to be placed in the designer tool (nothing placed in the art tool can ever, ever move).

Lights from different rooms only are applied if they are visible from your current room. Even an ambient light isn’t applied if the room it’s placed in isn’t visible to that room.

== Sunlight ==

When you are working with a terrain or exterior level, you can set the sunlight properties in the [[Level editor]] by clicking on the Exportable Area Properties button in the toolbar (next to the purple plus sign).

Clicking on the Exportable Area Properties button will cause an Area Properties window to pop up. Scrolling down the window you will see a section titled Layout Sunlight. In this section Color controls the color of the sunlight and Color Multiplier controls the brightness.

The direction of the sunlight can be set by either typing values into the Direction field, or by clicking the Set Sunlight button in the Exportable Area Properties window and moving the red arrow surrounded by a blue circle that will appear in the bottom left hand corner of your screen. The arrow is pointing in the sunlight direction.

The default shadows cast by sunlight are pitch black and very dark. If you do not like this default, you can change the color of the shadows by adding an Ambient - Baked light source that has the color you desire for your shadows. The default light color (grey - 0.50, 0.50. 0.50) works well, but you may change it to whatever you like.

== Light probes ==

Light probes are used to generate the appearance of nearby reflective surfaces and the illuminance values for characters. A light probe consists of an imaginary sphere that is textured with a pre-rendered view of its surroundings in every direction; reflective objects will use the texture of the nearest light probe to produce an approximation of what a reflection should look like. Light probes are particularly important where water planes are used.

The following example shows a light probe with the reflection texture rendered onto it (to make the light probe's texture visible you need to have "view models fully lit" turned off and "display light maps" turned on). The water below the light probe is using the probe's texture to determine its reflection.

[[Image:Level editor light probe.png|400px]]

If you make any changes to the level that would make a visible difference to what a light probe "sees" you'll have to re-render the light probes to update the reflection texture. This command is under the menu "Tools -> Render -> Render light probes", or you can click the toolbar button [[Image:IconRenderLightProbe.png]]

Light probes show up as a sphere with arrows pointing in each +/- axis direction. The only editable property that is unique is the High LOD Model Radius.

High LOD Model Radius: This is a setting that will flip all the models within this radius (in meters) of the light probe to high LOD before rendering it. It is only really useful in outdoor levels as indoors everything defaults to high Level Of Detail.

The tool for rendering light probes will render all the light probes within the current level. First what it does is switch the editor lighting to look exactly like it does in the game. Then it renders the light probes. Be patient, this can take a moment or two.

In general, you should render lightmaps first before rendering light probes because otherwise, the probes would not reflect the final in-game lightmapped appearance of the level.

Once the light probes have been rendered they will be packaged up with the level.

== Advanced lighting ==

=== Room-based lights ===

Each light placed in a room-based level is automatically attached to the parent room during export. This ensures that only those lights that are under a room affect the geometry in that room.
To specify lights in other rooms that can affect the selected room, the artist can bring up the Room Properties dialog and add references to additional lights in adjacent rooms.

=== Bloom and Other Effects ===

Bloom is activated the same way any other effect is activated. In order to activate the Bloom effect:

*Interiors:
** Select the interior AREA you want it to be applied to.
** Under the Effect section, modify the Buffer Effect Name text field to “da_bloom”.
* Exteriors:
** Select the exterior area you want to apply the effect to and bring up it's Exportable Area Properties.
** Under the Effect section, modify the Buffer Effect Name text field to “da_bloom”.

If you do not immediately see bloom effects take place, you might have visualization off, be sure to have it on to preview your bloom

== Light mapping ==

If the filename of your level file is <filename>.lvl, then the editor saves a <filename>.erf file in the same directory as <filename.lvl>. This [[ERF]] file contains the last set of lightmaps that the editor obtained from the lightmapper. When you share the LVL file with other artists you should also include the ERF so that the other artists can us your rendered lightmaps without having to render lightmaps themselves.

Under the "options" menu for the level editor are the following three settings. These are what they should be in a default installation:

;Lightmapper Command: $(TOOLSET)\lightmapper\EclipseRay.exe LightMapper.py --terse -cpus=2
;Lightmapper Command Working Folder: $(TOOLSET)\lightmapper\
;Lightmapper Texture Folder: $(TEMP)\DALightmap\

*Note: There appears to be a bug with the 64-bit version of ActiveState Python 2.5 for Windows that prevents the lightmapper from functioning. Install the 32-bit version as described in the [[Installing_the_toolset#Lightmapper|lightmapper section of the installation instructions]]. If you don't have Python installed you'll receive a standard Windows error message indicating that "EclipseRay.exe has stopped working."

[[Category:Level layouts]]

Lighting

2009-12-07T15:01:20Z

PavelNovotny: /* Sunlight */

{{Infobox level editor}}

There are many different types of lighting and light combinations that can be placed in the editor.

There are also many tools used to create lighting and generate lighting and even visualize lighting in the editor. The goal with the editor is to give the artist the same experience as he/she would see in the game. This will help them to be able to create the levels and tweak lighting quickly without having to stop to see it in-game.

== Lights ==

Lights for the game are split into two categories based on what they affect: levels and characters. Character lights will affect the player, NPCs, and creatures. The level lights will affect static geometry and designer placeables.

The game supports several different light types, with the purpose of balancing quality vs performance. To understand the use of the light types, one must first know the general lighting equation:

Diffuse = DynamicAmbient + F(DynamicLights, DynamicShadows) + ( LightmapRGB + LightmapShadowMap * F(StaticLights , DynamicShadows) )

Where F is the function which calculates light contribution given the dynamic shadow map.

Light Effect:

* Baked: This is lighting that only affects things in the level layout. The player will not be lit by this. Its contribution to the lighting scene is encoded in the lightmap RGB.
* Dynamic: This only affects the Player Character. The dynamic lights will light all geometry without regard for baked shadow maps. They still however, respect the dynamically generated shadowmap.
* Static: This is lighting that is both baked and dynamic. The most “expensive” of the light types. Static lights are those that don’t move. This provides the opportunity to bake in the shadow contribution of that light into the lightmap. Multiple static lights will mix together in this baked-shadow map. No RGB contribution from the light will go into the lightmap when rendering lightmaps. During run-time, the game will calculate the RGB color of the static light and then only apply it in areas that are uncovered by the baked-shadow map. Characters and placeable props are fully lit by the static lights.
* Animated: Animated lights are those that don’t move about, but do have animation properties on their light intensity. These lights are baked into the shadow map.

Light Type:

* Point: The light originates from a spot. “Light Size” corresponds to the size of the object casting off light. “Num Samples” is the number of shadow render passes – the higher the number the “crisper” the shadows.
* Ambient: This is ever-present light that affects everything.
* Spot: This is directional light. To move the location of the light right click on the icon at the end of the effect. You will then see arrows that allow you to move it around.

Only dynamic lights will affect placeables placed in the design tool. So a designer chest will not be lit properly next to a chest placed in the art tool. That’s a limitation of the engine. Any object that is animated has to be placed in the designer tool (nothing placed in the art tool can ever, ever move).

Lights from different rooms only are applied if they are visible from your current room. Even an ambient light isn’t applied if the room it’s placed in isn’t visible to that room.

== Sunlight ==

When you are working with a terrain or exterior level, you can set the sunlight properties in the [[Level editor]] by clicking on the Exportable Area Properties button in the toolbar (next to the purple plus sign).

Clicking on the Exportable Area Properties button will cause an Area Properties window to pop up. Scrolling down the window you will see a section titled Layout Sunlight. In this section Color controls the color of the sunlight and Color Multiplier controls the brightness.

The direction of the sunlight can be set by either typing values into the Direction field, or by clicking the Set Sunlight button in the Exportable Area Properties window and moving the red arrow surrounded by a blue circle that will appear in the bottom left hand corner of your screen. The arrow is pointing in the sunlight direction.

The default shadows cast by sunlight are pitch black and very dark. If you do not like this default, you can change the color of the shadows by adding an Ambient - Baked light source that has the color you desire for your shadows. The default light color (grey - 0.50, 0.50. 0.50) works well, but you may change it to whatever you like.

== Light probes ==

Light probes are used to generate the appearance of nearby reflective surfaces and the illuminance values for characters. A light probe consists of an imaginary sphere that is textured with a pre-rendered view of its surroundings in every direction; reflective objects will use the texture of the nearest light probe to produce an approximation of what a reflection should look like. Light probes are particularly important where water planes are used.

The following example shows a light probe with the reflection texture rendered onto it (to make the light probe's texture visible you need to have "view models fully lit" turned off and "display light maps" turned on). The water below the light probe is using the probe's texture to determine its reflection.

[[Image:Level editor light probe.png|400px]]

If you make any changes to the level that would make a visible difference to what a light probe "sees" you'll have to re-render the light probes to update the reflection texture. This command is under the menu "Tools -> Render -> Render light probes", or you can click the toolbar button [[Image:IconRenderLightProbe.png]]

Light probes show up as a sphere with arrows pointing in each +/- axis direction. The only editable property that is unique is the High LOD Model Radius.

High LOD Model Radius: This is a setting that will flip all the models within this radius (in meters) of the light probe to high LOD before rendering it. It is only really useful in outdoor levels as indoors everything defaults to high Level Of Detail.

The tool for rendering light probes will render all the light probes within the current level. First what it does is switch the editor lighting to look exactly like it does in the game. Then it renders the light probes. Be patient, this can take a moment or two.

In general, you should render lightmaps first before rendering light probes because otherwise, the probes would not reflect the final in-game lightmapped appearance of the level.

Once the light probes have been rendered they will be packaged up with the level.

== Advanced lighting ==

=== Room-based lights ===

Each light placed in a room-based level is automatically attached to the parent room during export. This ensures that only those lights that are under a room affect the geometry in that room.
To specify lights in other rooms that can affect the selected room, the artist can bring up the Room Properties dialog and add references to additional lights in adjacent rooms.

=== Bloom and Other Effects ===

Bloom is activated the same way any other effect is activated. In order to activate the Bloom effect:

*Interiors:
** Select the interior AREA you want it to be applied to.
** Under the Effect section, modify the Buffer Effect Name text field to “da_bloom”.
* Exteriors:
** Select the exterior area you want to apply the effect to and bring up it's Exportable Area Properties.
** Under the Effect section, modify the Buffer Effect Name text field to “da_bloom”.

If you do not immediately see bloom effects take place, you might have visualization off, be sure to have it on to preview your bloom

== Light mapping ==

If the filename of your level file is <filename>.lvl, then the editor saves a <filename>.erf file in the same directory as <filename.lvl>. This [[ERF]] file contains the last set of lightmaps that the editor obtained from the lightmapper. When you share the LVL file with other artists you should also include the ERF so that the other artists can us your rendered lightmaps without having to render lightmaps themselves.

Under the "options" menu for the level editor are the following three settings. These are what they should be in a default installation:

;Lightmapper Command: $(TOOLSET)\lightmapper\EclipseRay.exe LightMapper.py --terse -cpus=2
;Lightmapper Command Working Folder: $(TOOLSET)\lightmapper\
;Lightmapper Texture Folder: $(TEMP)\DALightmap\

*Note: There appears to be a bug with the 64-bit version of ActiveState Python 2.5 for Windows that prevents the lightmapper from functioning. Install the 32-bit version as described in the [[Installing_the_toolset#Lightmapper|lightmapper section of the installation instructions]]. If you don't have Python installed you'll receive a standard Windows error message indicating that "EclipseRay.exe has stopped working."

[[Category:Level layouts]]