http://www.datoolset.net/mw/api.php?action=feedcontributions&feedformat=atom&user=TrueKeatonDragon Age Toolset Wiki - User contributions [en]2026-04-22T02:21:44ZUser contributionsMediaWiki 1.25.6http://www.datoolset.net/mw/index.php?title=Cutscene_effect&diff=12961Cutscene effect2010-05-25T16:23:31Z<p>TrueKeaton: /* Sepia Fade */</p>
<hr />
<div>{{Infobox cutscenes}}<br />
<br />
[[Cutscene]] effects can be applied either to the MASTER object (in which case they apply to all cameras in the cutscene simultaneously) or to individual cameras.<br />
<br />
*Fade In/Fade Out<br />
*da_bloom<br />
*da_blurdesaturate<br />
*da_bssrdf<br />
*da_bssrdf_shared<br />
*da_cleartogreen<br />
*da_colorfade<br />
*da_copybackbuffer<br />
*da_depth<br />
*da_distortion<br />
*da_dof<br />
*da_fade<br />
*da_hsvmatrix<br />
*da_motionblur<br />
*da_sepiafade<br />
<br />
== Fade In/Fade Out ==<br />
<br />
This effect is only available for the MASTER object. Over the course of the event the screen will either fade in or out from a solid color, depending on the effect's type. The state of the view (faded in or faded out) will persist after the event, the event's duration only determines how rapidly the fade occurs.<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Fade}}<br />
{{inspector row|Fade Color| The color to fade in or out to. }}<br />
{{inspector row|Fade Type| Whether this is a fade in or a fade out. }}<br />
{{inspector end}}<br />
<br />
== Bloom ==<br />
<br />
Causes bright areas of the image to "bleed" over into adjacent dark areas, and to oversaturate the camera.<br />
<br />
The [[curve editor]] can be used to set the following parameters:<br />
<br />
*Brightness<br />
*Contrast<br />
*Glow intensity<br />
*Horizontal blur width<br />
*Vertical blur width<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|Brightness| }}<br />
{{inspector row|Contrast| }}<br />
{{inspector row|GlowIntensity| }}<br />
{{inspector row|HBlurWidth| Distance that the bloom's bleed-over extends in the horizontal direction. }}<br />
{{inspector row|VBlurWidth| Distance that the bloom's bleed-over extends in the vertical direction. }}<br />
{{inspector end}}<br />
<br />
== Blur desaturate ==<br />
<br />
The [[curve editor]] can be used with the following properties:<br />
<br />
*Brightness<br />
*Contrast<br />
*hblurwidth<br />
*hue<br />
*saturation<br />
*vblurwidth<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|Brightness|}}<br />
{{inspector row|Contrast|}}<br />
{{inspector row|FadeDirection|}}<br />
{{inspector row|FadeOutStart|}}<br />
{{inspector row|HBlurWidth|}}<br />
{{inspector row|Hue|}}<br />
{{inspector row|Saturation|}}<br />
{{inspector row|TimeToFade|}}<br />
{{inspector row|VBlurWidth|}}<br />
{{inspector end}}<br />
<br />
== BSSRDF ==<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
{{inspector end}}<br />
<br />
== BSSRDF Shared ==<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
{{inspector end}}<br />
<br />
== Clear to Green ==<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
{{inspector end}}<br />
<br />
== Color Fade ==<br />
<br />
A more fine-tunable variant on the "Fade to black" effect, color fade allows you to set the beginning and end colors and transparency of the fade as well as how long it takes for the fade to happen. By making the fade take longer than the duration of the effect you can get a partial fade.<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|EndColourAlpha| Transparency of the end color at TimeToFade seconds. }}<br />
{{inspector row|EndColourBlue| Blueness of the end color at TimeToFade seconds. }}<br />
{{inspector row|EndColourGreen| Greenness of the end color at TimeToFade seconds. }}<br />
{{inspector row|EndColourRed| Redness of the end color at TimeToFade seconds. }}<br />
{{inspector row|StartColourAlpha| Transparency of the color at the beginning of the fade (set to 0 to start out completely transparent) }}<br />
{{inspector row|StartColourBlue| Blueness of the color at the beginning of the fade. }}<br />
{{inspector row|StartColourGreen| Greenness of the color at the beginning of the fade. }}<br />
{{inspector row|StartColourRed| Redness of the color at the beginning of the fade. }}<br />
{{inspector row|TimeToFade| Time it takes for the fade to transition from the start color and transparency to the end color and transparency. Doesn't necessarily have to be the same as the duration of the effect - if it's longer the effect will only fade partway before ending, if it's shorter the fade will remain at the end color for the remaining duration of the effect.}}<br />
{{inspector end}}<br />
<br />
== Copy Back Buffer ==<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
{{inspector end}}<br />
<br />
== Distortion ==<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
{{inspector end}}<br />
<br />
== Depth ==<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
{{inspector end}}<br />
<br />
== Depth of Field (DOF) ==<br />
<br />
Sets the camera's focus on near/far objects. By default all objects are in focus regardless of how far away they are, but a real-world camera has a limited ability to focus on objects of differing ranges.<br />
<br />
The [[curve editor]] can be used to set the following properties:<br />
<br />
*Far fade<br />
*Focal radius<br />
*Focus distance<br />
*Max blur<br />
*Near fade<br />
*Weight blur<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|FarFade| Distance over which focus is lost in the direction away from the camera.}}<br />
{{inspector row|FocalRadius| The range over which the camera's focus is sharp, in meters. }}<br />
{{inspector row|FocalDistance| The center of the range over which the camera's focus is sharp. Objects that are FocalDistance meters away &plusmn; FocalRadius will be in sharp focus. }}<br />
{{inspector row|MaxBlur| }}<br />
{{inspector row|NearFade| Distance over which focus is lost in the direction toward the camera. }}<br />
{{inspector row|RenderBlurRadius| }}<br />
{{inspector row|WeightBlur| The strength of the blurring effect used on out-of-focus parts of the view. }}<br />
{{inspector end}}<br />
<br />
== Fade ==<br />
<br />
The [[curve editor]] can be used with the following properties:<br />
*BlurStrength<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|BlurStrength|}}<br />
{{inspector end}}<br />
<br />
== HSV Matrix ==<br />
<br />
Allows adjustment of the brightness, contrast, hue and saturation of the view.<br />
<br />
The [[curve editor]] can be used to set the following properties:<br />
<br />
*Brightness<br />
*Contrast<br />
*Hue<br />
*Saturation<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|Brightness| Brightness multiplier }}<br />
{{inspector row|Contrast| }}<br />
{{inspector row|Hue| }}<br />
{{inspector row|Saturation| Color intensity multiplier. 0 makes the view grayscale. Values between 0 and 1 make the colors muted, values greater than one make the colors unnaturally vibrant. }}<br />
{{inspector end}}<br />
<br />
== Motion Blur ==<br />
<br />
Motion blur blends previous frames into the current frame, creating the effect of motion blur. <br />
<br />
The [[curve editor]] can be used to set the blend property.<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|blend| A range from 0-1. Determines the strength of the blur. Note that 1 produces a nonfunctional effect. }}<br />
{{inspector end}}<br />
<br />
== Sepia Fade ==<br />
<br />
Adds a sepia (brown-hued) filter to the camera. Commonly used to indicate "old" film, often for flashbacks.<br />
<br />
{{inspector start}}<br />
{{inspector section|General}}<br />
{{inspector row|End Time| The time that the action ends }}<br />
{{inspector row|Infinite| If true this action extends on forever. It never ends. }}<br />
{{inspector row|Start Time| The time that the action begins }}<br />
<br />
{{inspector section|Effect}}<br />
{{inspector row|TimeToFade| Appears to have no effect }}<br />
{{inspector end}}<br />
<br />
[[Category:Cutscenes]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Level_Editor_Tutorial&diff=12834Level Editor Tutorial2010-04-07T16:44:13Z<p>TrueKeaton: /* Adding lights */</p>
<hr />
<div>=Building your room (Interior Level)=<br />
How to create/lightmap a [[Level]] for use in an Interior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple room from scratch in 10 minutes or less<br />
<br />
This was lifted from a posting by St4rdog http://social.bioware.com/forum/1/topic/8/index/150840<br />
It needs some additional formatting love, but is as good starting place for people to create usable <br />
interior levels<br />
<br />
File > New > Level > Room Level<br />
<br />
* Click on "New Area" in top-left list > Object Inspector in bottom-right > Layout Name > anything under 8 characters no spaces or special characters (*,&,%, etc).<br />
* Click the Setup Start Point icon, then click anywhere to make a start point.<br />
* Select the Area, then add the Start Point Name in the Object Inspector. <br />
*Right-click in 3D view and select Insert > New Room.<br />
*Click Models (blue box) in the Palette in the top-right. These folders contain everything such as floor tiles, walls, etc.<br />
*Enable Grid Snap with the magnet icon to make sure they line up.<br />
*The "prp" folder contains things like beds/barrels to clutter your Level.<br />
Hint: Use [[DATool]] (3rd party tool downloadable at http://social.bioware.com/project/41/ )to browse <br />
through these quickly to find the floors/walls you want.<br />
*Any gaps you can see between models (such as wall sections) will be visible in game. When you have time to refine the layout, you can remove most hairline gaps by setting exact X Y Z coordinates in the toolset (though sometimes 0.99 or 1.01 looks better than 1.00). Larger gaps may require the use of tileset assets such as pillars. The black box tileset (blk) can be placed outside a room to cover up any defects.<br />
Hint: If you need lots of wall sections quickly, place one at a convenient location e.g. (0,0). Copy (Ctrl-C) then Paste (Ctrl-V)<br />
as many as you need. In the Object Inspector, change the coordinates of successive sections to (0,8), (0,16) etc or drag manually <br />
if you can do that quicker.<br />
<br />
Note: If you get "Cannot spawn models into the selected parent object" when trying to place a model <br />
then you don't have "New Room" selected.<br />
<br />
==Working with multiple rooms==<br />
<br />
In general it is best to define each building room as a new room in the level. This becomes important when you work on lighting. To physically connect rooms you need to slide them together to get the doors to line up, they do not line up automatically. It takes some trial and error but becomes easier with practice.<br />
<br />
Use the Room Properties icon to specify which rooms are connected etc.<br />
<br />
==Pathfinding==<br />
<br />
Click the Generate Pathfinding icon. Green dots indicate where the player will be allowed to walk.<br />
<br />
For this to work, the area properties must name a valid start point, and it needs to be bounded by walls or other obstacles.<br />
<br />
Hint: you may need to place another startpoint in any room that can't be reached from the main startpoint. That would apply, for example, to<br />
rooms reached by transition doors within the area.<br />
<br />
==Adding lights==<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light<br />
<br />
* Move it up off the floor a little (e.g. Z = 2). In Object Inspector > Affects Characters TRUE > "Color Intensity" 2 or more > "Light Type" Point - Static (lc) > Choose any bright color.<br />
<br />
*Copy and paste. In Object Inspector >"Light Type" Ambient - Baked (this light stops your shadows being pitch black) > Choose a dark blue colour and keep the Color Intensity under 2/3.<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light Probe<br />
<br />
Note : you need a light probe to make character and water lighting work properly. The exact position doesn't seem to matter much.<br />
<br />
Note: I'm not sure what the mix of Baked/Static light is supposed to be. <br />
If you just put a Baked + Ambient it complains about not having Static, but if <br />
you put a Static + Ambient it seems to work fine, but the wiki says Static is <br />
the most expensive.<br />
<br />
Hint: For more even character lighting, use 3 or 4 static lights. Arrange them in <br />
a circle outside all of the rooms. Increase the Point Radius property of each light <br />
to a very large value, e.g. 10000 so that it works like a floodlight.<br />
<br />
==Rendering Lightmaps==<br />
<br />
*Press the Render Lightmaps icon (you need ActivePython 2.5 installed to default location). When it's done click the Display Lightmaps On/Off icon in the top-left to refresh the results.<br />
*Uncheck the "View Models Fully Lit" icon in the lop-left. You should see shadows from any objects you've dropped in.<br />
<br />
Note: Lightmap-atlas messages might appear the first time you render. That seems normal.<br />
Sometimes re-rendering the lightmaps messes them up badly when Display Lightmaps On/Off is on. It <br />
doesn't seem to use the latest lightmaps. Try pressing Display Lightmaps On/Off a few times to <br />
update it. If they're still messed up sometimes one of these fixes it (don't know which)<br />
unloading/reloading your Area or Level/changing your Area's layout property/posting your Level to <br />
Local.<br />
<br />
==Adding the Minimap==<br />
<br />
Select the area. Right click, then select Minimap > Minimap Selection Tool. The default green box appears. Right click on the area again, Minimap > Post Minimap to Local. <br />
<br />
==Exporting==<br />
<br />
*Press the Do All Local Posts icon to the right of the lightmapping icons. It will export the name you typed into the "New Area" "Layout Name". <br />
*If that doesn't work, select the area then Edit > Post Selection To Local.<br />
*If there's a complaint about walkable/player start then delete your old start then place a new one on a flat area.<br />
*Save your .lvl file. It's not used by the game and the name/location doesn't matter. Only the exported/posted files are used.<br />
<br />
==Using this in an Area==<br />
<br />
File > New > Area > Any Name<br />
<br />
*In the Object Inspector > Area Layout you should get a "..." box (make sure it's Checked Out) > click then select your "Layout Name" which should now be there.<br />
<br />
* Now you have a pretty lightmapped level inside an area.<br />
<br />
=Building your terrain (Exterior Level)=<br />
How to create/lightmap a [[Level]] for use in an Exterior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple terrain from scratch.<br />
<br />
File>New>Level<br />
<br />
* Choose Terrain (Landscape) Level and then click Next.<br />
<br />
* Accept the default values for the purpose of this tutorial and click Next and then click Finish. You can learn more about what the different terrain options do at the [[Level editor]] page.<br />
<br />
You should now see a flat, dark piece of terrain. To move around you hold down the mouse wheel. If you want to rotate the view press the Alt key while holding down the mouse wheel. You will want some light so you can see what you are doing, so we will generate a light source next.<br />
<br />
Tip: When choosing the size of your terrain level think about where you are going to put horizon and vista objects, like distant mountains and tree lines. You may need to allow for extra space around your adventure area to place those items.<br />
<br />
<br />
==Grid Size==<br />
<br />
If you want to work with a larger grid than the one provided by default you can change the grid size by going to: <br />
<br />
Tools/Options/Level Editor/Grid Square Size.<br />
<br />
This will not change the actual dimensions of the terrain level that you created, it only changes the size of the squares in the grid.<br />
<br />
==Define an area==<br />
<br />
Must be done before rendering the lightmap.<br />
<br />
* Click on the purple +-sign and click Define Area. Start in one corner and draw the green square to define the area that you will export.<br />
* Fill in the box Layout Name, max seven characters.<br />
* Fill in the box Name.<br />
<br />
==Lighting==<br />
<br />
* Right click on Terrain World to the upper left and choose Insert>New Light. This will spawn a light source in your area. Make sure you change the Light Type to Ambient - Baked (L). Be sure to click on the Render Lightmaps button if you want to see how your ambient light is working.<br />
<br />
Now that the terrain is lit we can modify it.<br />
<br />
<br />
==Modifying Terrain==<br />
<br />
The [[Terrain mesh]] tools allow you to modify the terrain by changing elevations, smoothing edges, flatting terrain, or painting textures.<br />
<br />
<br />
==Water==<br />
<br />
Please note that as of build 1.0.982.0 water is broken. You can see it in editor, but it is not making it into the game.<br />
<br />
First use the [[Terrain mesh]] tools to make a hole. It doesn't have to be deep. Then right-click on Terrain world and select Insert -> New Water Mesh. Double Click on the Water Mesh to zoom to it. By default it gets placed in a corner. Using the 3 Axis Movement tool [[File:moveTool.png]] grab the water and drag it to your hole. Depending on the size of the hole, you might have to adjust the water mesh size by changing the Size X and Size Y property values. Once you have the mesh placed, it's time to create the light probe. Right-click near the water mesh and select Insert -> New Light Probe. Using the move tool again, drag the light probe so that is roughly centered over the water mesh and slightly above it. Click on Render Lightmaps, then Render Light Probs. You might have to toggle Display Lightmaps, but you should now see your water looking like water and reflecting things around it.<br />
<br />
==Placing Models==<br />
<br />
* Click the blue box in the Palette Window to access the models that come with the game. The [[Model list]] shows pictures of many of the models available.<br />
<br />
* The [[Model]] page has more details on how to work with models.<br />
<br />
Tip 1: I had to change the Snap Options to make the models go where I wanted them. The settings I use were 0.10 for Snap to Grid and Snap Z Size. I also had to turn off Enable Snap to Surface whenever I wanted to change the vertical position of something (like creating the second floor of a building). Enable Snap to Surface is not applied globally, so once you turn it off and position an object vertically, turning it back on will not move that object unless you select it (or have it selected when you turn it back on).<br />
<br />
Tip 2: When placing premade cottages be aware that the door frames you can see attached to those buildings DO NOT have built in door hooks (see [[Area tutorial]] for information on placing doors). You can place a door frame model (for example, fhe_doorfrs_0) over the built in door frame to generate a door hook. The door frame model has to be placed from the Level Editor.<br />
<br />
<br />
==Adding Vegetation and Wind==<br />
<br />
The [[Vegetation]] page includes a list with pictures of the various plants available for placement. If you do not see the plants once you place them with the Scatter Object Tool then you may need to adjust your SpeedTree Rendering Distance Selector. This is a drop-down that you will see in the Tool Bar. It lists the distances at which plants will be visible. I set it to Very Far and left it there.<br />
<br />
Each level can have one active wind object in it. The location of the wind object doesn't matter. The wind object defines how wind behaves on this level, which is used for such things as flapping banners and swaying trees.<br />
<br />
Image:Level editor wind object.png <br />
<br />
The Wind Object may be found by right clicking on Terrain World and selecting:<br />
<br />
Insert>New Wind Object<br />
<br />
<br />
==Visual Effects (VFX)==<br />
<br />
Placeable visual effects like flames or smoke are considered to be art assets in the Dragon Age toolset, so you need to place them from within the Level Editor. <br />
<br />
The [[VFX Tutorial]] provides guidance on creating and placing visual effects.<br />
<br />
<br />
==Path finding and Obstructions==<br />
<br />
The path finding process lays down a grid of points that are marked "accessible" if they can be reached from a path finding start spot via passable terrain. This is essentially a flood-fill algorithm.<br />
<br />
You must create an [[Exportable area]] before you can generate any path finding data.<br />
<br />
* Click on the purple + in the tool bar ([[File:IconAddExportableArea.png]]). This will open an Area Properties window. The [[Level editor]] page has more details on this process, so I will just keep these steps very basic.<br />
* Name your Exportable Area in the Layout Name field of the Area Properties window. The name of an exportable area layout is limited to seven characters. BioWare uses the following naming system:<br />
** Three-letter prefix that describes the region or plot the layout is for. For example, "ost" for Ostagar and environs.<br />
** Three-digit number that uniquely identifies the layout within that region. Increments of one hundred are commonly used for major areas to allow sub-regions to be grouped together.<br />
** A single character identifying variants of the layout. For example, a "d" suffix for the "daytime" version of an exterior layout. "d" is also often used to mean "default", for areas where day and night are irrelevant (deep in a cave, for example).<br />
* Define your walkable area. Do this by clicking the Define Area button in the Area Properties window. The green box must include any areas that you want players to be able to walk. If you click in a corner of the level the green box will appear there. You can then expand it by dragging the corner.<br />
* Close the Area Properties window.<br />
<br />
In most cases you will want to block off certain areas of your terrain.<br />
* Turn on the Build Terrain Blocking tool. It is the middle mountain icon.<br />
* Using left-click to place and right-click to end chains/delete, place down blocks or 'walls' around areas you don't want the player to enter<br />
* Be sure to provide visual clues if it isn't obvious why the player can't walk there.<br />
<br />
Now that you have your exportable area you can generate path finding data.<br />
<br />
* Place a Starting Point in your level. I found that path finding does not work if you place the Starting Point before you have an Exportable Area. To place a Starting Point click on Setup Start Point in the tool bar.<br />
* Record the name of your Starting Point by clicking on it and looking at the name in the Object Inspector. Do not change the name - changing the name can prevent path finding from working.<br />
* Click Exportable Area Properties in the tool bar to open the Area Properties window. Put the Start Point name in the appropriate field and close the window.<br />
<br />
You should now be ready to generate pathfinding data by clicking on the Generate Pathfinding for Active Area button in the tool bar.<br />
<br />
==Converting Levels into Areas==<br />
<br />
Click on Do All Local Posts (you can avoid problems by generating a lightmap and pathfinding before doing local posts). This can be found in the menu at Tools>Export>Do All Local Posts<br />
<br />
Your level has now been converted and can be used to make an area. The [[Area tutorial]] will walk you through what to do next.<br />
<br />
<br />
<br />
[[Category: Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Level_Editor_Tutorial&diff=12833Level Editor Tutorial2010-04-07T16:43:36Z<p>TrueKeaton: /* Adding lights */</p>
<hr />
<div>=Building your room (Interior Level)=<br />
How to create/lightmap a [[Level]] for use in an Interior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple room from scratch in 10 minutes or less<br />
<br />
This was lifted from a posting by St4rdog http://social.bioware.com/forum/1/topic/8/index/150840<br />
It needs some additional formatting love, but is as good starting place for people to create usable <br />
interior levels<br />
<br />
File > New > Level > Room Level<br />
<br />
* Click on "New Area" in top-left list > Object Inspector in bottom-right > Layout Name > anything under 8 characters no spaces or special characters (*,&,%, etc).<br />
* Click the Setup Start Point icon, then click anywhere to make a start point.<br />
* Select the Area, then add the Start Point Name in the Object Inspector. <br />
*Right-click in 3D view and select Insert > New Room.<br />
*Click Models (blue box) in the Palette in the top-right. These folders contain everything such as floor tiles, walls, etc.<br />
*Enable Grid Snap with the magnet icon to make sure they line up.<br />
*The "prp" folder contains things like beds/barrels to clutter your Level.<br />
Hint: Use [[DATool]] (3rd party tool downloadable at http://social.bioware.com/project/41/ )to browse <br />
through these quickly to find the floors/walls you want.<br />
*Any gaps you can see between models (such as wall sections) will be visible in game. When you have time to refine the layout, you can remove most hairline gaps by setting exact X Y Z coordinates in the toolset (though sometimes 0.99 or 1.01 looks better than 1.00). Larger gaps may require the use of tileset assets such as pillars. The black box tileset (blk) can be placed outside a room to cover up any defects.<br />
Hint: If you need lots of wall sections quickly, place one at a convenient location e.g. (0,0). Copy (Ctrl-C) then Paste (Ctrl-V)<br />
as many as you need. In the Object Inspector, change the coordinates of successive sections to (0,8), (0,16) etc or drag manually <br />
if you can do that quicker.<br />
<br />
Note: If you get "Cannot spawn models into the selected parent object" when trying to place a model <br />
then you don't have "New Room" selected.<br />
<br />
==Working with multiple rooms==<br />
<br />
In general it is best to define each building room as a new room in the level. This becomes important when you work on lighting. To physically connect rooms you need to slide them together to get the doors to line up, they do not line up automatically. It takes some trial and error but becomes easier with practice.<br />
<br />
Use the Room Properties icon to specify which rooms are connected etc.<br />
<br />
==Pathfinding==<br />
<br />
Click the Generate Pathfinding icon. Green dots indicate where the player will be allowed to walk.<br />
<br />
For this to work, the area properties must name a valid start point, and it needs to be bounded by walls or other obstacles.<br />
<br />
Hint: you may need to place another startpoint in any room that can't be reached from the main startpoint. That would apply, for example, to<br />
rooms reached by transition doors within the area.<br />
<br />
==Adding lights==<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light<br />
<br />
* Move it up off the floor a little (e.g. Z = 2). In Object Inspector > Affects Characters TRUE > "Color Intensity" 2 or more > "Light Type" Point - Static (lc) > Choose any bright color.<br />
<br />
*Copy and paste. In Object Inspector >"Light Type" Ambient - Baked (this light stops your shadows being pitch black) > Choose a dark blue colour and keep the Color Intensity under 2/3.<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light Probe<br />
<br />
Note : you need a light probe to make character and water lighting work properly. The exact position doesn't seem to matter much.<br />
<br />
Note: I'm not sure what the mix of Baked/Static light is supposed to be. <br />
If you just put a Baked + Ambient it complains about not having Static, but if <br />
you put a Static + Ambient it seems to work fine, but the wiki says Static is <br />
the most expensive.<br />
<br />
Hint: For more even character lighting, use 3 or 4 static lights. Arrange them in a circle outside all of the rooms. Increase the Point Radius property of each light to a very large value, e.g. 10000 so that it works like a floodlight.<br />
<br />
==Rendering Lightmaps==<br />
<br />
*Press the Render Lightmaps icon (you need ActivePython 2.5 installed to default location). When it's done click the Display Lightmaps On/Off icon in the top-left to refresh the results.<br />
*Uncheck the "View Models Fully Lit" icon in the lop-left. You should see shadows from any objects you've dropped in.<br />
<br />
Note: Lightmap-atlas messages might appear the first time you render. That seems normal.<br />
Sometimes re-rendering the lightmaps messes them up badly when Display Lightmaps On/Off is on. It <br />
doesn't seem to use the latest lightmaps. Try pressing Display Lightmaps On/Off a few times to <br />
update it. If they're still messed up sometimes one of these fixes it (don't know which)<br />
unloading/reloading your Area or Level/changing your Area's layout property/posting your Level to <br />
Local.<br />
<br />
==Adding the Minimap==<br />
<br />
Select the area. Right click, then select Minimap > Minimap Selection Tool. The default green box appears. Right click on the area again, Minimap > Post Minimap to Local. <br />
<br />
==Exporting==<br />
<br />
*Press the Do All Local Posts icon to the right of the lightmapping icons. It will export the name you typed into the "New Area" "Layout Name". <br />
*If that doesn't work, select the area then Edit > Post Selection To Local.<br />
*If there's a complaint about walkable/player start then delete your old start then place a new one on a flat area.<br />
*Save your .lvl file. It's not used by the game and the name/location doesn't matter. Only the exported/posted files are used.<br />
<br />
==Using this in an Area==<br />
<br />
File > New > Area > Any Name<br />
<br />
*In the Object Inspector > Area Layout you should get a "..." box (make sure it's Checked Out) > click then select your "Layout Name" which should now be there.<br />
<br />
* Now you have a pretty lightmapped level inside an area.<br />
<br />
=Building your terrain (Exterior Level)=<br />
How to create/lightmap a [[Level]] for use in an Exterior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple terrain from scratch.<br />
<br />
File>New>Level<br />
<br />
* Choose Terrain (Landscape) Level and then click Next.<br />
<br />
* Accept the default values for the purpose of this tutorial and click Next and then click Finish. You can learn more about what the different terrain options do at the [[Level editor]] page.<br />
<br />
You should now see a flat, dark piece of terrain. To move around you hold down the mouse wheel. If you want to rotate the view press the Alt key while holding down the mouse wheel. You will want some light so you can see what you are doing, so we will generate a light source next.<br />
<br />
Tip: When choosing the size of your terrain level think about where you are going to put horizon and vista objects, like distant mountains and tree lines. You may need to allow for extra space around your adventure area to place those items.<br />
<br />
<br />
==Grid Size==<br />
<br />
If you want to work with a larger grid than the one provided by default you can change the grid size by going to: <br />
<br />
Tools/Options/Level Editor/Grid Square Size.<br />
<br />
This will not change the actual dimensions of the terrain level that you created, it only changes the size of the squares in the grid.<br />
<br />
==Define an area==<br />
<br />
Must be done before rendering the lightmap.<br />
<br />
* Click on the purple +-sign and click Define Area. Start in one corner and draw the green square to define the area that you will export.<br />
* Fill in the box Layout Name, max seven characters.<br />
* Fill in the box Name.<br />
<br />
==Lighting==<br />
<br />
* Right click on Terrain World to the upper left and choose Insert>New Light. This will spawn a light source in your area. Make sure you change the Light Type to Ambient - Baked (L). Be sure to click on the Render Lightmaps button if you want to see how your ambient light is working.<br />
<br />
Now that the terrain is lit we can modify it.<br />
<br />
<br />
==Modifying Terrain==<br />
<br />
The [[Terrain mesh]] tools allow you to modify the terrain by changing elevations, smoothing edges, flatting terrain, or painting textures.<br />
<br />
<br />
==Water==<br />
<br />
Please note that as of build 1.0.982.0 water is broken. You can see it in editor, but it is not making it into the game.<br />
<br />
First use the [[Terrain mesh]] tools to make a hole. It doesn't have to be deep. Then right-click on Terrain world and select Insert -> New Water Mesh. Double Click on the Water Mesh to zoom to it. By default it gets placed in a corner. Using the 3 Axis Movement tool [[File:moveTool.png]] grab the water and drag it to your hole. Depending on the size of the hole, you might have to adjust the water mesh size by changing the Size X and Size Y property values. Once you have the mesh placed, it's time to create the light probe. Right-click near the water mesh and select Insert -> New Light Probe. Using the move tool again, drag the light probe so that is roughly centered over the water mesh and slightly above it. Click on Render Lightmaps, then Render Light Probs. You might have to toggle Display Lightmaps, but you should now see your water looking like water and reflecting things around it.<br />
<br />
==Placing Models==<br />
<br />
* Click the blue box in the Palette Window to access the models that come with the game. The [[Model list]] shows pictures of many of the models available.<br />
<br />
* The [[Model]] page has more details on how to work with models.<br />
<br />
Tip 1: I had to change the Snap Options to make the models go where I wanted them. The settings I use were 0.10 for Snap to Grid and Snap Z Size. I also had to turn off Enable Snap to Surface whenever I wanted to change the vertical position of something (like creating the second floor of a building). Enable Snap to Surface is not applied globally, so once you turn it off and position an object vertically, turning it back on will not move that object unless you select it (or have it selected when you turn it back on).<br />
<br />
Tip 2: When placing premade cottages be aware that the door frames you can see attached to those buildings DO NOT have built in door hooks (see [[Area tutorial]] for information on placing doors). You can place a door frame model (for example, fhe_doorfrs_0) over the built in door frame to generate a door hook. The door frame model has to be placed from the Level Editor.<br />
<br />
<br />
==Adding Vegetation and Wind==<br />
<br />
The [[Vegetation]] page includes a list with pictures of the various plants available for placement. If you do not see the plants once you place them with the Scatter Object Tool then you may need to adjust your SpeedTree Rendering Distance Selector. This is a drop-down that you will see in the Tool Bar. It lists the distances at which plants will be visible. I set it to Very Far and left it there.<br />
<br />
Each level can have one active wind object in it. The location of the wind object doesn't matter. The wind object defines how wind behaves on this level, which is used for such things as flapping banners and swaying trees.<br />
<br />
Image:Level editor wind object.png <br />
<br />
The Wind Object may be found by right clicking on Terrain World and selecting:<br />
<br />
Insert>New Wind Object<br />
<br />
<br />
==Visual Effects (VFX)==<br />
<br />
Placeable visual effects like flames or smoke are considered to be art assets in the Dragon Age toolset, so you need to place them from within the Level Editor. <br />
<br />
The [[VFX Tutorial]] provides guidance on creating and placing visual effects.<br />
<br />
<br />
==Path finding and Obstructions==<br />
<br />
The path finding process lays down a grid of points that are marked "accessible" if they can be reached from a path finding start spot via passable terrain. This is essentially a flood-fill algorithm.<br />
<br />
You must create an [[Exportable area]] before you can generate any path finding data.<br />
<br />
* Click on the purple + in the tool bar ([[File:IconAddExportableArea.png]]). This will open an Area Properties window. The [[Level editor]] page has more details on this process, so I will just keep these steps very basic.<br />
* Name your Exportable Area in the Layout Name field of the Area Properties window. The name of an exportable area layout is limited to seven characters. BioWare uses the following naming system:<br />
** Three-letter prefix that describes the region or plot the layout is for. For example, "ost" for Ostagar and environs.<br />
** Three-digit number that uniquely identifies the layout within that region. Increments of one hundred are commonly used for major areas to allow sub-regions to be grouped together.<br />
** A single character identifying variants of the layout. For example, a "d" suffix for the "daytime" version of an exterior layout. "d" is also often used to mean "default", for areas where day and night are irrelevant (deep in a cave, for example).<br />
* Define your walkable area. Do this by clicking the Define Area button in the Area Properties window. The green box must include any areas that you want players to be able to walk. If you click in a corner of the level the green box will appear there. You can then expand it by dragging the corner.<br />
* Close the Area Properties window.<br />
<br />
In most cases you will want to block off certain areas of your terrain.<br />
* Turn on the Build Terrain Blocking tool. It is the middle mountain icon.<br />
* Using left-click to place and right-click to end chains/delete, place down blocks or 'walls' around areas you don't want the player to enter<br />
* Be sure to provide visual clues if it isn't obvious why the player can't walk there.<br />
<br />
Now that you have your exportable area you can generate path finding data.<br />
<br />
* Place a Starting Point in your level. I found that path finding does not work if you place the Starting Point before you have an Exportable Area. To place a Starting Point click on Setup Start Point in the tool bar.<br />
* Record the name of your Starting Point by clicking on it and looking at the name in the Object Inspector. Do not change the name - changing the name can prevent path finding from working.<br />
* Click Exportable Area Properties in the tool bar to open the Area Properties window. Put the Start Point name in the appropriate field and close the window.<br />
<br />
You should now be ready to generate pathfinding data by clicking on the Generate Pathfinding for Active Area button in the tool bar.<br />
<br />
==Converting Levels into Areas==<br />
<br />
Click on Do All Local Posts (you can avoid problems by generating a lightmap and pathfinding before doing local posts). This can be found in the menu at Tools>Export>Do All Local Posts<br />
<br />
Your level has now been converted and can be used to make an area. The [[Area tutorial]] will walk you through what to do next.<br />
<br />
<br />
<br />
[[Category: Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Level_Editor_Tutorial&diff=12832Level Editor Tutorial2010-04-07T16:43:20Z<p>TrueKeaton: /* Adding lights */</p>
<hr />
<div>=Building your room (Interior Level)=<br />
How to create/lightmap a [[Level]] for use in an Interior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple room from scratch in 10 minutes or less<br />
<br />
This was lifted from a posting by St4rdog http://social.bioware.com/forum/1/topic/8/index/150840<br />
It needs some additional formatting love, but is as good starting place for people to create usable <br />
interior levels<br />
<br />
File > New > Level > Room Level<br />
<br />
* Click on "New Area" in top-left list > Object Inspector in bottom-right > Layout Name > anything under 8 characters no spaces or special characters (*,&,%, etc).<br />
* Click the Setup Start Point icon, then click anywhere to make a start point.<br />
* Select the Area, then add the Start Point Name in the Object Inspector. <br />
*Right-click in 3D view and select Insert > New Room.<br />
*Click Models (blue box) in the Palette in the top-right. These folders contain everything such as floor tiles, walls, etc.<br />
*Enable Grid Snap with the magnet icon to make sure they line up.<br />
*The "prp" folder contains things like beds/barrels to clutter your Level.<br />
Hint: Use [[DATool]] (3rd party tool downloadable at http://social.bioware.com/project/41/ )to browse <br />
through these quickly to find the floors/walls you want.<br />
*Any gaps you can see between models (such as wall sections) will be visible in game. When you have time to refine the layout, you can remove most hairline gaps by setting exact X Y Z coordinates in the toolset (though sometimes 0.99 or 1.01 looks better than 1.00). Larger gaps may require the use of tileset assets such as pillars. The black box tileset (blk) can be placed outside a room to cover up any defects.<br />
Hint: If you need lots of wall sections quickly, place one at a convenient location e.g. (0,0). Copy (Ctrl-C) then Paste (Ctrl-V)<br />
as many as you need. In the Object Inspector, change the coordinates of successive sections to (0,8), (0,16) etc or drag manually <br />
if you can do that quicker.<br />
<br />
Note: If you get "Cannot spawn models into the selected parent object" when trying to place a model <br />
then you don't have "New Room" selected.<br />
<br />
==Working with multiple rooms==<br />
<br />
In general it is best to define each building room as a new room in the level. This becomes important when you work on lighting. To physically connect rooms you need to slide them together to get the doors to line up, they do not line up automatically. It takes some trial and error but becomes easier with practice.<br />
<br />
Use the Room Properties icon to specify which rooms are connected etc.<br />
<br />
==Pathfinding==<br />
<br />
Click the Generate Pathfinding icon. Green dots indicate where the player will be allowed to walk.<br />
<br />
For this to work, the area properties must name a valid start point, and it needs to be bounded by walls or other obstacles.<br />
<br />
Hint: you may need to place another startpoint in any room that can't be reached from the main startpoint. That would apply, for example, to<br />
rooms reached by transition doors within the area.<br />
<br />
==Adding lights==<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light<br />
<br />
* Move it up off the floor a little (e.g. Z = 2). In Object Inspector > Affects Characters TRUE > "Color Intensity" 2 or more > "Light Type" Point - Static (lc) > Choose any bright color.<br />
<br />
*Copy and paste. In Object Inspector >"Light Type" Ambient - Baked (this light stops your shadows being pitch black) > Choose a dark blue colour and keep the Color Intensity under 2/3.<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light Probe<br />
<br />
Note : you need a light probe to make character and water lighting work properly. The exact position doesn't seem to matter much.<br />
<br />
Note: I'm not sure what the mix of Baked/Static light is supposed to be. <br />
If you just put a Baked + Ambient it complains about not having Static, but if <br />
you put a Static + Ambient it seems to work fine, but the wiki says Static is <br />
the most expensive.<br />
<br />
Hint: For more even character lighting, use 3 or 4 static lights. Arrange them in a circle outside all of the rooms. Increase the Point<br />
Radius property of each light to a very large value, e.g. 10000 so that it works like a floodlight.<br />
<br />
==Rendering Lightmaps==<br />
<br />
*Press the Render Lightmaps icon (you need ActivePython 2.5 installed to default location). When it's done click the Display Lightmaps On/Off icon in the top-left to refresh the results.<br />
*Uncheck the "View Models Fully Lit" icon in the lop-left. You should see shadows from any objects you've dropped in.<br />
<br />
Note: Lightmap-atlas messages might appear the first time you render. That seems normal.<br />
Sometimes re-rendering the lightmaps messes them up badly when Display Lightmaps On/Off is on. It <br />
doesn't seem to use the latest lightmaps. Try pressing Display Lightmaps On/Off a few times to <br />
update it. If they're still messed up sometimes one of these fixes it (don't know which)<br />
unloading/reloading your Area or Level/changing your Area's layout property/posting your Level to <br />
Local.<br />
<br />
==Adding the Minimap==<br />
<br />
Select the area. Right click, then select Minimap > Minimap Selection Tool. The default green box appears. Right click on the area again, Minimap > Post Minimap to Local. <br />
<br />
==Exporting==<br />
<br />
*Press the Do All Local Posts icon to the right of the lightmapping icons. It will export the name you typed into the "New Area" "Layout Name". <br />
*If that doesn't work, select the area then Edit > Post Selection To Local.<br />
*If there's a complaint about walkable/player start then delete your old start then place a new one on a flat area.<br />
*Save your .lvl file. It's not used by the game and the name/location doesn't matter. Only the exported/posted files are used.<br />
<br />
==Using this in an Area==<br />
<br />
File > New > Area > Any Name<br />
<br />
*In the Object Inspector > Area Layout you should get a "..." box (make sure it's Checked Out) > click then select your "Layout Name" which should now be there.<br />
<br />
* Now you have a pretty lightmapped level inside an area.<br />
<br />
=Building your terrain (Exterior Level)=<br />
How to create/lightmap a [[Level]] for use in an Exterior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple terrain from scratch.<br />
<br />
File>New>Level<br />
<br />
* Choose Terrain (Landscape) Level and then click Next.<br />
<br />
* Accept the default values for the purpose of this tutorial and click Next and then click Finish. You can learn more about what the different terrain options do at the [[Level editor]] page.<br />
<br />
You should now see a flat, dark piece of terrain. To move around you hold down the mouse wheel. If you want to rotate the view press the Alt key while holding down the mouse wheel. You will want some light so you can see what you are doing, so we will generate a light source next.<br />
<br />
Tip: When choosing the size of your terrain level think about where you are going to put horizon and vista objects, like distant mountains and tree lines. You may need to allow for extra space around your adventure area to place those items.<br />
<br />
<br />
==Grid Size==<br />
<br />
If you want to work with a larger grid than the one provided by default you can change the grid size by going to: <br />
<br />
Tools/Options/Level Editor/Grid Square Size.<br />
<br />
This will not change the actual dimensions of the terrain level that you created, it only changes the size of the squares in the grid.<br />
<br />
==Define an area==<br />
<br />
Must be done before rendering the lightmap.<br />
<br />
* Click on the purple +-sign and click Define Area. Start in one corner and draw the green square to define the area that you will export.<br />
* Fill in the box Layout Name, max seven characters.<br />
* Fill in the box Name.<br />
<br />
==Lighting==<br />
<br />
* Right click on Terrain World to the upper left and choose Insert>New Light. This will spawn a light source in your area. Make sure you change the Light Type to Ambient - Baked (L). Be sure to click on the Render Lightmaps button if you want to see how your ambient light is working.<br />
<br />
Now that the terrain is lit we can modify it.<br />
<br />
<br />
==Modifying Terrain==<br />
<br />
The [[Terrain mesh]] tools allow you to modify the terrain by changing elevations, smoothing edges, flatting terrain, or painting textures.<br />
<br />
<br />
==Water==<br />
<br />
Please note that as of build 1.0.982.0 water is broken. You can see it in editor, but it is not making it into the game.<br />
<br />
First use the [[Terrain mesh]] tools to make a hole. It doesn't have to be deep. Then right-click on Terrain world and select Insert -> New Water Mesh. Double Click on the Water Mesh to zoom to it. By default it gets placed in a corner. Using the 3 Axis Movement tool [[File:moveTool.png]] grab the water and drag it to your hole. Depending on the size of the hole, you might have to adjust the water mesh size by changing the Size X and Size Y property values. Once you have the mesh placed, it's time to create the light probe. Right-click near the water mesh and select Insert -> New Light Probe. Using the move tool again, drag the light probe so that is roughly centered over the water mesh and slightly above it. Click on Render Lightmaps, then Render Light Probs. You might have to toggle Display Lightmaps, but you should now see your water looking like water and reflecting things around it.<br />
<br />
==Placing Models==<br />
<br />
* Click the blue box in the Palette Window to access the models that come with the game. The [[Model list]] shows pictures of many of the models available.<br />
<br />
* The [[Model]] page has more details on how to work with models.<br />
<br />
Tip 1: I had to change the Snap Options to make the models go where I wanted them. The settings I use were 0.10 for Snap to Grid and Snap Z Size. I also had to turn off Enable Snap to Surface whenever I wanted to change the vertical position of something (like creating the second floor of a building). Enable Snap to Surface is not applied globally, so once you turn it off and position an object vertically, turning it back on will not move that object unless you select it (or have it selected when you turn it back on).<br />
<br />
Tip 2: When placing premade cottages be aware that the door frames you can see attached to those buildings DO NOT have built in door hooks (see [[Area tutorial]] for information on placing doors). You can place a door frame model (for example, fhe_doorfrs_0) over the built in door frame to generate a door hook. The door frame model has to be placed from the Level Editor.<br />
<br />
<br />
==Adding Vegetation and Wind==<br />
<br />
The [[Vegetation]] page includes a list with pictures of the various plants available for placement. If you do not see the plants once you place them with the Scatter Object Tool then you may need to adjust your SpeedTree Rendering Distance Selector. This is a drop-down that you will see in the Tool Bar. It lists the distances at which plants will be visible. I set it to Very Far and left it there.<br />
<br />
Each level can have one active wind object in it. The location of the wind object doesn't matter. The wind object defines how wind behaves on this level, which is used for such things as flapping banners and swaying trees.<br />
<br />
Image:Level editor wind object.png <br />
<br />
The Wind Object may be found by right clicking on Terrain World and selecting:<br />
<br />
Insert>New Wind Object<br />
<br />
<br />
==Visual Effects (VFX)==<br />
<br />
Placeable visual effects like flames or smoke are considered to be art assets in the Dragon Age toolset, so you need to place them from within the Level Editor. <br />
<br />
The [[VFX Tutorial]] provides guidance on creating and placing visual effects.<br />
<br />
<br />
==Path finding and Obstructions==<br />
<br />
The path finding process lays down a grid of points that are marked "accessible" if they can be reached from a path finding start spot via passable terrain. This is essentially a flood-fill algorithm.<br />
<br />
You must create an [[Exportable area]] before you can generate any path finding data.<br />
<br />
* Click on the purple + in the tool bar ([[File:IconAddExportableArea.png]]). This will open an Area Properties window. The [[Level editor]] page has more details on this process, so I will just keep these steps very basic.<br />
* Name your Exportable Area in the Layout Name field of the Area Properties window. The name of an exportable area layout is limited to seven characters. BioWare uses the following naming system:<br />
** Three-letter prefix that describes the region or plot the layout is for. For example, "ost" for Ostagar and environs.<br />
** Three-digit number that uniquely identifies the layout within that region. Increments of one hundred are commonly used for major areas to allow sub-regions to be grouped together.<br />
** A single character identifying variants of the layout. For example, a "d" suffix for the "daytime" version of an exterior layout. "d" is also often used to mean "default", for areas where day and night are irrelevant (deep in a cave, for example).<br />
* Define your walkable area. Do this by clicking the Define Area button in the Area Properties window. The green box must include any areas that you want players to be able to walk. If you click in a corner of the level the green box will appear there. You can then expand it by dragging the corner.<br />
* Close the Area Properties window.<br />
<br />
In most cases you will want to block off certain areas of your terrain.<br />
* Turn on the Build Terrain Blocking tool. It is the middle mountain icon.<br />
* Using left-click to place and right-click to end chains/delete, place down blocks or 'walls' around areas you don't want the player to enter<br />
* Be sure to provide visual clues if it isn't obvious why the player can't walk there.<br />
<br />
Now that you have your exportable area you can generate path finding data.<br />
<br />
* Place a Starting Point in your level. I found that path finding does not work if you place the Starting Point before you have an Exportable Area. To place a Starting Point click on Setup Start Point in the tool bar.<br />
* Record the name of your Starting Point by clicking on it and looking at the name in the Object Inspector. Do not change the name - changing the name can prevent path finding from working.<br />
* Click Exportable Area Properties in the tool bar to open the Area Properties window. Put the Start Point name in the appropriate field and close the window.<br />
<br />
You should now be ready to generate pathfinding data by clicking on the Generate Pathfinding for Active Area button in the tool bar.<br />
<br />
==Converting Levels into Areas==<br />
<br />
Click on Do All Local Posts (you can avoid problems by generating a lightmap and pathfinding before doing local posts). This can be found in the menu at Tools>Export>Do All Local Posts<br />
<br />
Your level has now been converted and can be used to make an area. The [[Area tutorial]] will walk you through what to do next.<br />
<br />
<br />
<br />
[[Category: Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Adding_a_new_spell_tutorial&diff=12809Adding a new spell tutorial2010-03-30T18:30:36Z<p>TrueKeaton: /* Creating a custom spell script */</p>
<hr />
<div>This tutorial steps you through making a new spell called Full Heal. This will be a simple copy of the heal spell with a modification to the amount healed. The focus here is on creating a new spell, but the basic steps are the same for talents and other abilities. <br />
[[category:tutorials]]<br />
<br />
The process of adding a spell to the game is as follows:<br />
<br />
<br />
*Create a new module that extends the single player game<br />
*Create a new guitype that your spell exists under<br />
*Create a new ability entry for your spell<br />
*Create a custom script to handle your spell<br />
*Create strings to describe your spell in the talent page and tool tips<br />
*Testing it in the game<br />
<br />
<br />
Before beginning ensure you read the article on editing [[2DA]] files and how to convert them to GDA files for use in the game.<br />
<br />
<br />
== Creating your module ==<br />
<br />
These are just some basic settings required so that your module extends the Single Player campaign. <br />
<br />
<br />
# Load the toolset and select '''File''' > '''Manage Modules'''<br />
# Click on '''New''' and fill in the following fields:<br />
## '''Name''': Full Heal<br />
## '''Script''': (none) (Click on the ... button and select (none))<br />
## '''UID''': full_heal<br />
## '''Extended Module''': Single Player<br />
# Click '''Open''' to load your new module (it should be selected by default)<br />
# Select '''Tools''' > '''Export''' > '''Generate Module XML'''<br />
<br />
<br />
You now have a new module that will be loaded whenever you play the Single Player campaign.<br />
<br />
<br />
== Creating a new Spell Type == <br />
<br />
This step is not strictly necessary to get a new spell into the game, but is recommended. By doing this, your new spell will have its own category on the talents page. This is also how you can restrict which classes have access to the spell.<br />
<br />
For more information on the columns we are modifying refer to the article on [[Guitypes.xls]].<br />
<br />
# Open up your 2DA folder, it should be at \Dragon Age\tools\Source\2DA <br />
# Copy the file '''guitypes.xls''' to a new folder, for example C:\2DA<br />
# Open the file and delete all the rows except the headings<br />
# Create a new row with the following details:<br />
## '''ID''': 777<br />
## '''Label''': Divine Healer<br />
## '''StringID''': **** (we will replace this later with the proper string ID)<br />
## '''TintColor''': 0x888888 (I think this only matters if you are using the progress bar)<br />
## '''BlendTree''': ****<br />
## Any remaining columns in between set to 0<br />
# Save and close the file. <br />
# Convert it to a '''GDA''' file <br />
## To convert from XLS to GDA, there is an application called ExcelProcessor, which can be found in your installed Dragon Age directory - Dragon Age\tools\ResourceBuild\Processors. Just drag the XLS file onto the ExcelProcessor and it automatically converts it. See [[Compiling 2DAs]] for more detail.<br />
# Copy the GDA to your module override folder (My Documents\Bioware\Dragon Age\AddIns\full_heal\module\override)<br />
# Rename the file '''guitypes_fh.GDA'''<br />
<br />
== Creating a new ability entry == <br />
<br />
This is where you can specify the properties of your new spell. However for this example I'm just keeping it simple. I recommend reading this page to see what can be done: [[ABI_base.xls]]<br />
<br />
<br />
# Open up the rules folder in your 2DA folder, it should be at \Dragon Age\tools\Source\2DA\rules<br />
# Copy '''ABI_Base.xls''' to your 2DA folder<br />
# Open the file and find the entry for '''HEAL'''<br />
# Copy the whole row to the bottom of the file<br />
# Delete the rest of the rows except for the headings<br />
# Cut your row and paste it as the first row<br />
# Make the following changes to your HEAL row<br />
##''' ID''': 777777<br />
## '''label''': FULL HEAL<br />
## '''guitype''': 777<br />
# Save and close the file<br />
# Convert it to a '''GDA''' file (For instructions see [[Compiling 2DAs]])<br />
# Copy the '''ABI_Base.GDA''' file to your module override folder (My Documents\Bioware\Dragon Age\AddIns\full_heal\module\override)<br />
# Rename the file '''ABI_Base_fh.GDA'''<br />
<br />
== Preliminary Testing ==<br />
<br />
At this stage we want to ensure that the above steps worked, and that the new spell appears in-game. Simply run the game and check the talents page for a mage character. Your spell should appear in its own category down the bottom. If it doesn't try the following:<br />
<br />
<br />
* Check that the guitype for your ability in the ABI_base 2DA is the same as the id you set for your guitype in the guitypes 2DA<br />
* Check that your GDA files are copied to the correct override folder<br />
* Generate your module XML file again<br />
<br />
<br />
== Creating a custom spell script ==<br />
<br />
The easiest way to do this is generally open the script that the spell you are copying references, copy it to a new file and modify the contents to suit your purposes. Spell scripting is a little beyond the scope of this tutorial so I've prepared a simple script already. What it does is calculate the maximum health of the target of the spell and then heal them for that amount. <br />
<br />
<br />
# Select '''File''' > '''New''' > '''Script'''<br />
# Set the following properties<br />
## '''Resource Name''': full_heal<br />
## '''Folder''': \<br />
# Click '''OK''' to create the script <br />
# Copy the contents of the script below into the script and click '''Save'''<br />
<br />
<br />
The script should compile correctly if you check the log.<br />
<br />
<br />
<dascript><br />
// -----------------------------------------------------------------------------<br />
// full_heal.nss<br />
// -----------------------------------------------------------------------------<br />
<br />
#include "log_h"<br />
#include "abi_templates"<br />
#include "sys_traps_h"<br />
#include "spell_constants_h"<br />
<br />
<br />
const int FULL_HEAL = 777777;<br />
<br />
<br />
void _HandleImpact(struct EventSpellScriptImpactStruct stEvent)<br />
{<br />
<br />
effect eEffect;<br />
<br />
//int bHostile = FALSE;<br />
<br />
// make sure there is a location, just in case<br />
if (IsObjectValid(stEvent.oTarget) == TRUE)<br />
{<br />
stEvent.lTarget = GetLocation(stEvent.oTarget);<br />
}<br />
<br />
// -------------------------------------------------------------------------<br />
// Handle Spells<br />
// -------------------------------------------------------------------------<br />
switch (stEvent.nAbility)<br />
{ <br />
<br />
case FULL_HEAL:<br />
{<br />
float fHeal = GetCreatureProperty(stEvent.oTarget,7,PROPERTY_VALUE_TOTAL);<br />
eEffect = EffectHeal(fHeal);<br />
eEffect = SetEffectEngineInteger(eEffect, EFFECT_INTEGER_VFX, Ability_GetImpactObjectVfxId(stEvent.nAbility));<br />
ApplyEffectOnObject(EFFECT_DURATION_TYPE_INSTANT, eEffect, stEvent.oTarget, 0.0f, stEvent.oCaster, stEvent.nAbility);<br />
<br />
break;<br />
}<br />
<br />
<br />
}<br />
// if(bHostile) // sending only for hostile spells<br />
//SendEventOnCastAt(stEvent.oTarget, stEvent.oCaster, stEvent.nAbility, bHostile);<br />
}<br />
<br />
void main()<br />
{<br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_SPELLSCRIPT_PENDING:<br />
{<br />
Ability_SetSpellscriptPendingEventResult(COMMAND_RESULT_SUCCESS);<br />
<br />
break;<br />
}<br />
<br />
case EVENT_TYPE_SPELLSCRIPT_CAST:<br />
{<br />
// Get a structure with the event parameters<br />
struct EventSpellScriptCastStruct stEvent = Events_GetEventSpellScriptCastParameters(ev);<br />
<br />
// Hand this through to cast_impact<br />
SetAbilityResult(stEvent.oCaster, stEvent.nResistanceCheckResult);<br />
<br />
break;<br />
}<br />
<br />
case EVENT_TYPE_SPELLSCRIPT_IMPACT:<br />
{<br />
// Get a structure with the event parameters<br />
struct EventSpellScriptImpactStruct stEvent = Events_GetEventSpellScriptImpactParameters(ev);<br />
<br />
Log_Trace(LOG_CHANNEL_COMBAT_ABILITY, GetCurrentScriptName() + ".EVENT_TYPE_SPELLSCRIPT_IMPACT",Log_GetAbilityNameById(stEvent.nAbility));<br />
<br />
// Handle impact<br />
if (CheckSpellResistance(stEvent.oTarget, stEvent.oCaster, stEvent.nAbility) == FALSE)<br />
{<br />
_HandleImpact(stEvent);<br />
} else<br />
{<br />
UI_DisplayMessage(stEvent.oTarget, UI_MESSAGE_RESISTED);<br />
}<br />
<br />
break;<br />
}<br />
}<br />
}<br />
<br />
</dascript><br />
<br />
== Creating new Strings ==<br />
<br />
This step allows you to set your own description for the spell and have it appear correctly in tool tips. <br />
<br />
<br />
# Ensure your module is loaded in the toolset<br />
# Select '''Tools''' > '''String Editor'''<br />
# Right click in the empty space and select '''Insert''' > '''Insert String'''<br />
# Set the '''Type''' to '''Spells'''<br />
# Set the text to Divine Healer<br />
# Click '''OK''' to save the string<br />
# Make a note of the string ID generated and what it is for (in this case the Spell Type)<br />
# Repeat the above steps for the following text (without the information in brackets):<br />
<br />
:: Full Heal (note it down as the spell name)<br />
:: The mage channels divine energy to completely heal the target from all battle damage. (note it down as the description)<br />
<br />
The last string is for the tool tip, copy and paste the text below.<br />
<br />
<pre><br />
<name/> (<guitypename/>)<br />
<usetype/><br />
Range: <range/><br />
Activation: <cost/><br />
Cooldown: <cooldown/>s<br />
<br />
<requirements/><br />
<conditions/><br />
<br />
<description/><br />
</pre><br />
<br />
<br />
Once these strings are all created select '''Tools''' > '''Export''' > '''Export Talk Table'''. This will compile your strings into a talk table which can be used with the game. <br />
<br />
<br />
<br />
== Updating your ability ==<br />
<br />
This step involves tweaking our new spell to use the strings we created as well as the custom script. We will also adjust the cost and cooldown to make it a bit more balanced. <br />
<br />
<br />
For the following steps I recommend using '''GDApp''' to modify your GDA files rather than editing the excel files and recreating them. It can be found on the [[3rd_party_extensions]] page. <br />
<br />
<br />
# Open your '''ABI_base_fh.GDA''' file with '''GDApp'''<br />
# Set the '''namestrref''' field to the string ID for your spell name<br />
# Set the '''descstrref''' field to the string ID for your spell description<br />
# Set the '''tooltipstrref''' field to the string ID for your spell tooltip<br />
# Set the '''cost''' to 50<br />
# Set the '''spellscript''' to full_heal.ncs<br />
# Set the '''cooldown''' to 20<br />
# Save the file<br />
<br />
<br />
Next we modify the guitype:<br />
<br />
<br />
# Open your '''guitypes_fh.GDA''' file with '''GDApp'''<br />
# Set the '''stringid''' field to the string ID for your Spell Type<br />
# Save the file<br />
<br />
<br />
Now we have updated GDA files which reference our spell script and new strings. It should now function correctly in the game and look like any other spell.<br />
<br />
== Testing your new spell == <br />
<br />
Your new spell should be working and properly labeled in the game. You can select it when leveling up, or you can use a debug script to add your spell manually. <br />
<br />
With the developer console enabled, have your mage character selected and type the following:<br />
<br />
<pre>` runscript addtalent 777777</pre><br />
<br />
<br />
<br />
== Advanced Topics ==<br />
<br />
I will try and expand this section a bit later, but for now once you are confident with these steps, try the following:<br />
<br />
<br />
* Change the icon for the spell to make it stand out more. You can use one from another spell or make your own<br />
* Change the different values in ABI_base to alter the spell further<br />
* Create a new talent using the same procedure but copy and modify a talent instead of a spell<br />
* Set the ability field of the guitypes.xls to ensure your new ability type is only available to certain classes. This is how the specialization classes limit their abilities.</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Backgrounds_tutorial&diff=12808Backgrounds tutorial2010-03-29T15:17:06Z<p>TrueKeaton: /* Modifying the 2DAs */</p>
<hr />
<div>== Introduction ==<br />
This tutorial shows you how to modify the character backgrounds that can be selected during character generation. This is likely only of use if you are creating your own module or campaign as there would be no point to changing the background in the single player campaign unless you were also going to make extensive additions to support the new backgrounds (e.g a completely new origin story). So the example we will use for this tutorial is a new stand alone module in which we completely replace the existing backgrounds. Changing backgrounds is especially useful if your module is set in a different lore to the main Dragon Age game or if you simply want to reduce the scope of the number of different backgrounds.<br />
<br />
We will also demonstrate some important principals that can be followed when modifying other core rules such as available races or classes. Most importantly we will add the new backgrounds in a way that doesn’t require any editing of core resources. By leaving the core resources alone we make our changes compatible with future patches which might otherwise overwrite our work. Furthermore keeping the core resources in tact allows us to make different modifications to different modules within the same toolset.<br />
<br />
It is recommended that the reader should have some experience with scripting or coding in order to carry out the operations involved. The more you are relying on just copy pasting these instructions the more likely you are to make mistakes that you won’t know how to fix.<br />
<br />
== The backgrounds demo module ==<br />
Any basic module will do for the purposes of this tutorial. If you want to create a test module for this tutorial then just create a simple module with a single area and a starting location. Make sure that the only thing selected in the module’s hierarchy is ''Core game resources''. This will ensure that the module is a stand alone module rather than an add-in to the single player campaign or some other module. For the purposes of this tutorial we will assume the module is called ''Backgrounds demo'' and I will prefix my resources with ''bdm_'' to be sure that they are distinct from any that are already in existence.<br />
<br />
We are going to completely replace the existing backgrounds with 3 new ones of our own. You can use new backgrounds in your module however you see fit. You could create entire origin stories for each one like in the single player campaign (possibly a major undertaking depending on length) or you can just use them to influence dialogue and plot options in the main part of your game.<br />
<br />
For our demo we are creating a module in which the player starts off in a small human village (we will not be creating the details of this module so this is just for the purpose of an example). There is a wizard in this village who plays a pivotal role in the story. We allow the player to start as the wizard’s apprentice (if they are a mage) or as his servant (if they are human or elven and not a mage) or as a wandering traveller who has come to visit the wizard (if they are not human and not a mage). So the three backgrounds will be:<br />
<br />
* Servant<br />
* Apprentice<br />
* Traveller<br />
<br />
== Creating the background strings ==<br />
Before we start modifying the 2DA files we are going to create some strings. Open the string editor in the toolset and create the following strings in your ‘Backgrounds demo’ talk table:<br />
<br />
[[Image:Back_tut_talk_table.png]]<br />
<br />
Your string IDs might be different to these so be sure to reference the right string ID in the instructions that follow. Simply replace these string Ids with your own.<br />
<br />
'''IMPORTANT!''' ''There is currently a bug in the game that causes it to crash if a background description ID has a value greater than 109 912 680. To get around this you can go into your module’s properties and change the start and end IDs for strings to be less than that. After that the string editor will generate IDs in a range that won’t crash. You can always put those values back again after you create the background descriptions (that way you have less to alter once Bioware fix this). Hopefully Bioware will fix this bug soon as the official string range for non-Bioware / certified modules is over 610 000 000.''<br />
<br />
You may have noticed that we have given two different names and descriptions for the traveller background depending on the PC’s race. We will say more about that in the following section.<br />
<br />
{{TutorialRef|String editor}}<br />
<br />
== Modifying the 2DAs ==<br />
The next thing we need to do is to modify the worksheets in backgrounds.xls. Be sure to make a copy of the spreadsheet first so that you leave the original intact. See LINK for general information about editing 2DA files. The first worksheet is called ‘backgrounds’; modify it to look like the following:<br />
<br />
[[Image:back_tut_backgrounds.png]]<br />
<br />
Note that since 2DAs combine together to form M2DAs, and we don’t want the existing backgrounds in our game, we have overwritten the last two slots as unused1 and unused2, even though we won’t be using them. The name and desc string refs on this tab will be overwritten by the race specific ones on the names tab so we can leave those blank (AFAIK these string refs are not used providing the ones on the names tab are provided - also the tooltip string ref seems not to be used anywhere – if you prefer you can set these to something just to be safe).<br />
<br />
The three race columns determine which backgrounds can be selected by which race and the 3 class columns determine which background can be selected by which class. So, as you can see from the picture our Servant background is accessible to elf or human warriors and rogues, the Apprentice background can be selected by elf or human mages and the Traveller background by elf or dwarf warriors and rogues.<br />
<br />
The last three tabs indicate a starting ability for each background by race. Note that by default these columns are not hooked up into the character generation script (instead they are hard coded in the script) and are not used, but we will correct that later on when we do the scripting. You have to be careful here because the columns relate to the race IDs, so 1=dwarf, 2=elf and 3=human, which is in a different order to the other race columns in this table. The number in the column is an ability ID as given in ABI_base.xls. For this demo we have just given the same skill for each race for a given background. Servants get combat tactics, Apprentices get persuade and Travellers get survival.<br />
<br />
The next tab table to modify is background_names.<br />
<br />
[[Image:back_tut_bg_names.png]]<br />
<br />
Make sure that the IDs here match the IDs in your string table. Note that for Apprentices and Servants we use the same strings regardless of race, but for the Traveller background we use different strings. This is to illustrate how you can divide a single background up into multiple names and descriptions. Internally they are both stored as the same background ID but during character generation a different name, description and icon can be shown to the player. In the single player game this was done with the Noble background by splitting it into human and dwarf Noble variations.<br />
<br />
NOTE – you must be careful when splitting a single background into different parts for each race. You must make both the names and descriptions different! If you don’t make the descriptions different then the engine will not recognise them as different even if they have different names.<br />
<br />
Now modify the background_desc table as follows<br />
<br />
[[Image:back_tut_bg_desc.png]]<br />
<br />
Again note the distinct descriptions for the Traveller background.<br />
<br />
Now for the background_icons table. For this demo we will just use some of the existing icons but you may want to create your own icons to add here.<br />
<br />
[[Image:back_tut_bg_icons.png]]<br />
<br />
The background_defaults table must have an entry for each race, background and class combination that is allowed. The ID column must be calculated as follows:<br />
<br />
(1000 * raceID) + (100 * classID) + backgroundID<br />
<br />
[[Image:back_tute_bg_defaults.png]]<br />
<br />
The label column should give a description of the row (AFAIK this is not used anywhere).<br />
For this simple demo we will have each background combination spawn in the same place (the module default start location) but if you wanted different origins to spawn in different places then you can use the next two columns to specify this (AFAIK you have to write your own scripts to accomplish this though).<br />
<br />
In the template column you can put the name of a creature resource that you want to use as a template for this race/background/class combination. In the picture you can see that we have just used some default templates that shipped with the toolset but you can easily create your own. Note that only the inventory is copied across to the PC so if you want to create your own templates you do not need to alter anything on the creature except for their inventory.<br />
<br />
The name columns take string Ids. If you want to add your own names then you’ll have to create new strings in the string editor.<br />
<br />
Finally we have the ability column. As with the skill columns in the backgrounds table these IDs correspond to entries in the ABI_base.xls file. It should be noted that race, class and background are all possible sources of starting abilities so before you decide what to put in this column you should familiarise yourself with what skills are already being added in different parts of character generation in order to ensure that you don’t duplicate an ability somewhere.<br />
<br />
The final table is the chargen_preload table. The two columns here should exactly match the entries from the ID and Template columns of the previous table.<br />
<br />
[[Image:back_tut_chargen_preload.png]]<br />
<br />
{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}<br />
<br />
== Compiling and fixing the GDAs ==<br />
Now compile backgrounds.xls and place the resulting GDAs into your ''AddIns\module_name\module\override'' directory.<br />
Never place anything in your ''AddIns\module_name\core\override'' directory or it will affect other modules than the one you are editing.<br />
<br />
There used to be a [[Bug: ExcelProcessor doesn't handle row IDs above 8.3 million correctly|bug]] that prevented large string IDs from compiling correctly. This is now fixed. For the record, the old workaround was to edit the GDA files in the toolset to correct the string IDs manually, but you should now see that the string IDs are correct.<br />
<br />
{{TutorialRef|Compiling 2DAs|GDA}}<br />
<br />
== Creating the backgrounds plot ==<br />
The background plot is used for keeping track of a PC’s background and can be used to affect conversation options.<br />
<br />
The single player game uses a plot called gen00pt_backgrounds to keep track of the PC background. You can find it in the ''\_Global\Generic'' folder of the plots tab if you want to take a look. We will create a similar plot for our custom backgrounds. Create a new plot and call it ''bdm_000pt_backgrounds'' (My naming convention is to use 000 to indicate a resource that isn’t tied to any particular area – feel free to use your own convention but remember to update any references later in the tutorial). Add main plot flags as indicated in the picture below:<br />
<br />
[[Image:Back_tut_bg_plot.png]]<br />
<br />
You could also add some defined flags if you wanted. Defined flags can be used to return some combination of the main flags such as TRAVELLER or add some extra condition like FEMALE_APPRENTICE or ELVEN_APPRENTICE. Defined flags are beyond the scope of this tutorial however.<br />
<br />
{{TutorialRef|Designer Resources|Plot}}<br />
<br />
== Creating the scripts ==<br />
We are not going to edit any of the original core game scripts, we will only be adding new scripts of our own. As we discuss how to do this you should examine the core scripts that are referred to, but under no circumstances should you make any changes to those files. By leaving the core scripts as they are we make our modification more compatible with any future patches that may be released. If you modified the core scripts and then a patch was released that overwrote those scripts you would lose your changes. Also keeping your modification contained within your own module allows you to make different modifications to different modules within the one toolset.<br />
<br />
Lets start off with a script to handle the character generation events that are normally handled by the module_core script. Create a new script called ''bdm_module_core''. It is up to you what directory structure to use for your scripts but it can be a good idea to keep all your scripts in a directory with your module name to make them distinct from the core scripts. Then if you are emulating the functionality of a particular core script you can mirror the original directory structure underneath your main module folder. So in this case the module_core script is contained in the ''\_Core Scripts'' folder so we will put our bdm_module_core in ''\Backgrounds demo\_Core Scripts'' (the underscore ensures the core directories come first – looks like Bioware accidentally created one without it! I’m pretty sure Core and _Core are meant to be the same directory). Organising things this way will really help with keeping track of your scripts.<br />
<br />
The ''bdm_module_core'' script should contain the following code:<br />
<br />
<dascript><br />
#include "global_objects_h"<br />
void main(){<br />
event ev = GetCurrentEvent();<br />
int nEvent = GetEventType(ev); //extract event type from current event<br />
int nEventHandled = FALSE; //keep track of whether the event has been handled<br />
switch(nEvent){<br />
case EVENT_TYPE_MODULE_START:{<br />
// -----------------------------------------------------------------<br />
// Initiate character generation.<br />
// -----------------------------------------------------------------<br />
PreloadCharGen(); //preloads resources for character generation<br />
StartCharGen(GetHero(),0,TRUE); //initiates character generation<br />
break;<br />
}<br />
default:<br />
{<br />
// -----------------------------------------------------------------<br />
// Handle character generation events sent by the engine.<br />
// -----------------------------------------------------------------<br />
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END) <br />
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )<br />
{<br />
HandleEvent(ev, R"bdm_sys_chargen.ncs");<br />
nEventHandled = TRUE;<br />
}<br />
break;<br />
}<br />
<br />
}<br />
if (!nEventHandled) { //If this event wasn't handled by this script, let the core script try<br />
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);<br />
}<br />
}<br />
</dascript><br />
<br />
Now go to ''file > manage modules'' and open the properties for your module and set the script property to point at this script.<br />
<br />
Our new script handles some of the events that are usually handled by the module_core script. Once it has handled the event it chooses whether or not to pass the event on to module_core. The first event that we handle is EVENT_TYPE_MODULE_START, which is where we initiate character generation. In this case we pass the event on to the core script to handle after we have done what we need to.<br />
<br />
The second thing we handle is actually a group of events. If you look in the module_core script you will see that right down the bottom in the default event handler is some code that looks just like the code we have added in our default event, with a couple of little differences. Instead of passing the character generation events to the sys_chargen.ncs script we are going to pass it to our own script called ''bdm_sys_chargen.ncs'' which we will write shortly. If we catch one of those character generation events then we want to handle it ourselves and prevent the core script from handling it so we set nEventHandled = TRUE. Note that any other event that is caught by the default handler but isn’t a character generation event is going to go straight on through to the core script.<br />
<br />
Before we create the ''bdm_sys_chargen'' script we are going to need some new constants defined. Create a new script called ''bdm_2da_constants_h'' and put it in folder ''\Backgrounds demo\_Core Includes''. Now add the following to this script:<br />
<br />
<dascript><br />
// -----------------------------------------------------------------------------<br />
// Backgrounds - rules/backgrounds.xls<br />
// -----------------------------------------------------------------------------<br />
const int BACKGROUND_SERVANT = 1;<br />
const int BACKGROUND_APPRENTICE = 2;<br />
const int BACKGROUND_TRAVELLER = 3;<br />
</dascript><br />
<br />
These constants provide a way for us to refer to the background IDs that we defined in the 2DA files without having to remember the numbers. Constants like this also make your code more readable. If you need to add more new items to 2DAs when you are modding something else you can also add constants for them here. From now on we will be using these background constants instead of the original single player background constants that you can find in the ''2da_constants_h'' script. That means we’d better find all the places where those constants are used and update them with our own scripts.<br />
<br />
Create another new script and call it ''bdm_sys_chargen'' and put it in a folder called ''\Backgrounds demo\_Systems''. Put the following code in it:<br />
<br />
<dascript><br />
#include "bdm_sys_chargen_h"<br />
#include "log_h"<br />
<br />
const int CHARGEN_QUICKSTART_QUICK = 0;<br />
const int CHARGEN_QUICKSTART_NORMAL = 1;<br />
const int CHARGEN_QUICKSTART_ADVANCED = 2;<br />
<br />
void _RunChargen(int nRace, int nClass, object oChar, int nBackground)<br />
{<br />
<br />
Chargen_InitializeCharacter(oChar);<br />
Chargen_SelectGender(oChar,GENDER_MALE);<br />
Chargen_SelectRace(oChar,nRace);<br />
Chargen_SelectCoreClass(oChar,nClass);<br />
Chargen_SelectBackground(oChar, nBackground,FALSE);<br />
<br />
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);<br />
Chargen_InitInventory(oChar,0,nEquipIdx);<br />
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);<br />
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);<br />
<br />
}<br />
<br />
void main(){<br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
object oChar = GetEventObject(ev,0);<br />
<br />
int nMode;<br />
int nInt0 = GetEventInteger(ev,0);<br />
int nInt1 = GetEventInteger(ev,1);<br />
// -------------------------------------------------------------------------<br />
// Debug Data.<br />
// -------------------------------------------------------------------------<br />
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType) <br />
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);<br />
<br />
int nEventHandled = FALSE;<br />
<br />
switch (nEventType)<br />
{<br />
// ----------------------------------------------------------------------<br />
// This fires when the player selects the icon corresponding to any of<br />
// the available backgrounds<br />
//<br />
// nInt0 - Constant BACKGROUND_* integer<br />
// ----------------------------------------------------------------------<br />
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {<br />
int nBackground = nInt0;<br />
// -----------------------------------------------------------------<br />
// Set the background on the player and reinitialize plot flags<br />
// for the background<br />
// -----------------------------------------------------------------<br />
Chargen_InitializeCharacter(oChar,TRUE);<br />
Chargen_SelectGender(oChar,GetCreatureGender(oChar));<br />
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));<br />
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));<br />
<br />
bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);<br />
bdm_Chargen_SetupPlotFlags(oChar);<br />
<br />
// -----------------------------------------------------------------<br />
// Generate the index into the equipment template 2da and<br />
// then load the starting equipment based on the data returned.<br />
// -----------------------------------------------------------------<br />
int nClass = GetCreatureCoreClass(oChar);<br />
int nRace = GetCreatureRacialType(oChar);<br />
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);<br />
Chargen_InitInventory(oChar,0,nEquipIdx);<br />
nEventHandled = TRUE;<br />
break;<br />
}<br />
case EVENT_TYPE_CHARGEN_END: {<br />
nMode = nInt0;<br />
int nQuickStart = nInt1;<br />
// 0 - quickstart<br />
// 1 - normal \<br />
// 2 - advanced / treat as the same<br />
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode) <br />
+ ", Quick Start: " + IntToString(nQuickStart));<br />
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){<br />
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Setting default values for player character");<br />
<br />
int nRandClass = abs((GetLowResTimer()%3)+1);<br />
<br />
if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)<br />
{<br />
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );<br />
<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);<br />
}<br />
else // mage<br />
{<br />
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);<br />
}<br />
Chargen_SetNumTactics(oChar);<br />
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));<br />
SendEventModuleChargenDone("", "");<br />
nEventHandled = TRUE;<br />
}<br />
break;<br />
}<br />
} //end switch<br />
<br />
if (!nEventHandled){<br />
HandleEvent(ev, R"sys_chargen.ncs");<br />
}<br />
<br />
<br />
}<br />
</dascript><br />
<br />
There are two events in the original sys_chargen script that we need to replace because they deal with backgrounds. The first of these is EVENT_TYPE_CHARGEN_SELECT_BACKGROUND and the other is EVENT_TYPE_CHARGEN_END. For the second event we only need to change the case where the character is being created in quickstart mode, so we just handle that section of the code. The objective here is to change only as much as we need to and then pass any remaining events through to the original sys_chargen script. Take some time to compare the new script with Bioware’s ''sys_chargen'' script .<br />
<br />
You will notice that we include a script called ''bdm_sys_chargen_h'' and that we use some functions with a ''bdm_'' prefix. Those functions are contained in that include file which we’ll write now. Essentially these are modifications of a couple of functions from the ''sys_chargen_h'' include file. Create a new script and call it ''bdm_sys_chargen_h''. Put it in folder ''\Backgrounds demo\_Systems\Includes'' and add the following code:<br />
<br />
<dascript><br />
#include "sys_chargen_h"<br />
#include "bdm_2da_constants_h"<br />
#include "wrappers_h"<br />
#include "plt_bdm_000pt_backgrounds"<br />
<br />
void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)<br />
{<br />
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);<br />
// -------------------------------------------------------------------------<br />
// 1. Set the background variable<br />
// - Create creature property (or check what we used so far<br />
// - We don't set backgrounds on non player generated chars.<br />
// -------------------------------------------------------------------------<br />
if (bUnApply)<br />
{<br />
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);<br />
}<br />
else<br />
{<br />
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);<br />
}<br />
// -------------------------------------------------------------------------<br />
// 2. Give one skill<br />
// - retrieve the skill that is granted by the background from backgrounds.xls<br />
// - give it to the player.<br />
// -------------------------------------------------------------------------<br />
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);<br />
if (nAbility)<br />
{<br />
_AddAbility (oChar, nAbility, bUnApply);<br />
}<br />
}<br />
<br />
void bdm_Chargen_SetupPlotFlags(object oChar)<br />
{<br />
int nRace = GetCreatureRacialType(oChar);<br />
int nBackground = GetPlayerBackground(oChar);<br />
<br />
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Setting plot flags, race: " <br />
+ IntToString(nRace) + ", background: " + IntToString(nBackground));<br />
<br />
// First, init all flags (debug setup)<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);<br />
<br />
switch (nBackground)<br />
{<br />
case BACKGROUND_SERVANT:<br />
{<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;<br />
break;<br />
}<br />
case BACKGROUND_APPRENTICE:<br />
{<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;<br />
break;<br />
}<br />
case BACKGROUND_TRAVELLER:<br />
{<br />
switch(nRace)<br />
{<br />
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;<br />
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;<br />
}<br />
break;<br />
}<br />
}<br />
}<br />
</dascript><br />
<br />
Lets examine these two functions. First you should compare them to their original versions. For ''bdm_Chargen_SelectBackground()'' we have actually made a more generic version of the function that should work with any backgrounds. We have removed the hard coded values for the background abilities and now use the function ChargenGetBackgroundSkill() which actually gets the background skill from the backgrounds 2DA file that we edited earlier (recall the last three columns that give a skill depending on background and race). If you need fancier logic than just reading the values form the GDA (e.g. like Bioware’s logic for the Noble background) then you can always go back to hard coding them the way Bioware did.<br />
<br />
The second function is ''bdm_Chargen_SetupPlotFlags()'' which does just what it says. Remember the plot we created earlier? Here we set the appropriate flag based on race and background.<br />
<br />
{{TutorialRef|Script}}<br />
<br />
== Testing that everything works ==<br />
Now compile your scripts and export your module. Also, make sure that you export your talk table.<br />
<br />
'''IMPORTANT!''' ''Always make sure you empty your \Dragon Age\packages\core\override folder after doing an export. Due to a bug in the current toolset your single player game will become damaged if you don’t do this before playing.''<br />
<br />
You should now be able to run your game and see the backgrounds you created appear in character generation. If you want to test that the background plots have been set correctly, add an NPC to the start area and create a conversation for them in which each line is switched according to a background plot flag. You can also check that the character is receiving the abilities that we set in the 2DAs.<br />
<br />
'''NOTE''' ''There seems to be no way to change the popup message that comes up at the beginning of character generation. Altering the Pre-chargen string ID in the loadhints GDA does not seem to do anything.''<br />
<br />
{{TutorialRef|Exporting a module}}<br />
<br />
== Optional extras ==<br />
There are a couple of other Bioware scripts that reference the background constants. They are not essential to modify because they are not used anywhere by default. The genev_tutorial script uses a background check but unless you plan on firing the tutorial from your module then you won’t have need of it. Also there is at least one debug script that makes use of the original single player backgrounds (to grant a background plot flag to the PC) so if you want similar debug functionality you may have to roll your own function.<br />
<br />
== Conclusion ==<br />
In this tutorial we have demonstrated a way to modify the backgrounds used in the game without altering any of the core scripts. It is expected that a similar approach could be taken to modding other aspects of the game such as adding classes or races. In these cases the scripts that were created in this tutorial could be extended to handle other parts of the character generation process such as class and race selection.<br />
<br />
[[Category:Character generation]]<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Backgrounds_tutorial&diff=12718Backgrounds tutorial2010-03-19T15:56:53Z<p>TrueKeaton: /* Modifying the 2DAs */</p>
<hr />
<div>== Introduction ==<br />
This tutorial shows you how to modify the character backgrounds that can be selected during character generation. This is likely only of use if you are creating your own module or campaign as there would be no point to changing the background in the single player campaign unless you were also going to make extensive additions to support the new backgrounds (e.g a completely new origin story). So the example we will use for this tutorial is a new stand alone module in which we completely replace the existing backgrounds. Changing backgrounds is especially useful if your module is set in a different lore to the main Dragon Age game or if you simply want to reduce the scope of the number of different backgrounds.<br />
<br />
We will also demonstrate some important principals that can be followed when modifying other core rules such as available races or classes. Most importantly we will add the new backgrounds in a way that doesn’t require any editing of core resources. By leaving the core resources alone we make our changes compatible with future patches which might otherwise overwrite our work. Furthermore keeping the core resources in tact allows us to make different modifications to different modules within the same toolset.<br />
<br />
It is recommended that the reader should have some experience with scripting or coding in order to carry out the operations involved. The more you are relying on just copy pasting these instructions the more likely you are to make mistakes that you won’t know how to fix.<br />
<br />
== The backgrounds demo module ==<br />
Any basic module will do for the purposes of this tutorial. If you want to create a test module for this tutorial then just create a simple module with a single area and a starting location. Make sure that the only thing selected in the module’s hierarchy is ''Core game resources''. This will ensure that the module is a stand alone module rather than an add-in to the single player campaign or some other module. For the purposes of this tutorial we will assume the module is called ''Backgrounds demo'' and I will prefix my resources with ''bdm_'' to be sure that they are distinct from any that are already in existence.<br />
<br />
We are going to completely replace the existing backgrounds with 3 new ones of our own. You can use new backgrounds in your module however you see fit. You could create entire origin stories for each one like in the single player campaign (possibly a major undertaking depending on length) or you can just use them to influence dialogue and plot options in the main part of your game.<br />
<br />
For our demo we are creating a module in which the player starts off in a small human village (we will not be creating the details of this module so this is just for the purpose of an example). There is a wizard in this village who plays a pivotal role in the story. We allow the player to start as the wizard’s apprentice (if they are a mage) or as his servant (if they are human or elven and not a mage) or as a wandering traveller who has come to visit the wizard (if they are not human and not a mage). So the three backgrounds will be:<br />
<br />
* Servant<br />
* Apprentice<br />
* Traveller<br />
<br />
== Creating the background strings ==<br />
Before we start modifying the 2DA files we are going to create some strings. Open the string editor in the toolset and create the following strings in your ‘Backgrounds demo’ talk table:<br />
<br />
[[Image:Back_tut_talk_table.png]]<br />
<br />
Your string IDs might be different to these so be sure to reference the right string ID in the instructions that follow. Simply replace these string Ids with your own.<br />
<br />
'''IMPORTANT!''' ''There is currently a bug in the game that causes it to crash if a background description ID has a value greater than 109 912 680. To get around this you can go into your module’s properties and change the start and end IDs for strings to be less than that. After that the string editor will generate IDs in a range that won’t crash. You can always put those values back again after you create the background descriptions (that way you have less to alter once Bioware fix this). Hopefully Bioware will fix this bug soon as the official string range for non-Bioware / certified modules is over 610 000 000.''<br />
<br />
You may have noticed that we have given two different names and descriptions for the traveller background depending on the PC’s race. We will say more about that in the following section.<br />
<br />
{{TutorialRef|String editor}}<br />
<br />
== Modifying the 2DAs ==<br />
The next thing we need to do is to modify the worksheets in backgrounds.xls. Be sure to make a copy of the spreadsheet first so that you leave the original intact. See LINK for general information about editing 2DA files. The first worksheet is called ‘backgrounds’; modify it to look like the following:<br />
<br />
[[Image:back_tut_backgrounds.png]]<br />
<br />
Note that since 2DAs combine together to form M2DAs, and we don’t want the existing backgrounds in our game, we have overwritten the last two slots as unused1 and unused2, even though we won’t be using them. The name and desc string refs on this tab will be overwritten by the race specific ones on the names tab so we can leave those blank (AFAIK these string refs are not used providing the ones on the names tab are provided - also the tooltip string ref seems not to be used anywhere – if you prefer you can set these to something just to be safe).<br />
<br />
The three race columns determine which backgrounds can be selected by which race and the 3 class columns determine which background can be selected by which class. So, as you can see from the picture our Servant background is accessible to elf or human warriors and rogues, the Apprentice background can be selected by elf or human mages and the Traveller background by elf or dwarf warriors and rogues.<br />
<br />
The last three tabs indicate a starting ability for each background by race. Note that by default these columns are not hooked up into the character generation script (instead they are hard coded in the script) and are not used, but we will correct that later on when we do the scripting. You have to be careful here because the columns relate to the race IDs, so 1=dwarf, 2=elf and 3=human, which is in a different order to the other race columns in this table. The number in the column is an ability ID as given in ABI_base.xls. For this demo we have just given the same skill for each race for a given background. Servants get combat tactics, Apprentices get persuade and Travellers get survival.<br />
<br />
The next tab table to modify is background_names.<br />
<br />
[[Image:back_tut_bg_names.png]]<br />
<br />
Make sure that the IDs here match the IDs in your string table. Note that for Apprentices and Servants we use the same strings regardless of race, but for the Traveller background we use different strings. This is to illustrate how you can divide a single background up into multiple names and descriptions. Internally they are both stored as the same background ID but during character generation a different name, description and icon can be shown to the player. In the single player game this was done with the Noble background by splitting it into human and dwarf Noble variations.<br />
<br />
NOTE – you must be careful when splitting a single background into different parts for each race. You must make both the names and descriptions different! If you don’t make the descriptions different then the engine will not recognise them as different even if they have different names.<br />
<br />
Now modify the background_desc table as follows<br />
<br />
[[Image:back_tut_bg_desc.png]]<br />
<br />
Again note the distinct descriptions for the Traveller background.<br />
<br />
Now for the background_icons table. For this demo we will just use some of the existing icons but you may want to create your own icons to add here.<br />
<br />
[[Image:back_tut_bg_icons.png]]<br />
<br />
The background_defaults table must have an entry for each race, background and class combination that is allowed. The ID column must be calculated as follows:<br />
<br />
1000 * raceID + 100 * classID + backgroundID<br />
<br />
[[Image:back_tute_bg_defaults.png]]<br />
<br />
The label column should give a description of the row (AFAIK this is not used anywhere).<br />
For this simple demo we will have each background combination spawn in the same place (the module default start location) but if you wanted different origins to spawn in different places then you can use the next two columns to specify this (AFAIK you have to write your own scripts to accomplish this though).<br />
<br />
In the template column you can put the name of a creature resource that you want to use as a template for this race/background/class combination. In the picture you can see that we have just used some default templates that shipped with the toolset but you can easily create your own. Note that only the inventory is copied across to the PC so if you want to create your own templates you do not need to alter anything on the creature except for their inventory.<br />
<br />
The name columns take string Ids. If you want to add your own names then you’ll have to create new strings in the string editor.<br />
<br />
Finally we have the ability column. As with the skill columns in the backgrounds table these IDs correspond to entries in the ABI_base.xls file. It should be noted that race, class and background are all possible sources of starting abilities so before you decide what to put in this column you should familiarise yourself with what skills are already being added in different parts of character generation in order to ensure that you don’t duplicate an ability somewhere.<br />
<br />
The final table is the chargen_preload table. The two columns here should exactly match the entries from the ID and Template columns of the previous table.<br />
<br />
[[Image:back_tut_chargen_preload.png]]<br />
<br />
{{TutorialRef|2DA|2DA#Excel file formatting|Background.xls}}<br />
<br />
== Compiling and fixing the GDAs ==<br />
Now compile backgrounds.xls and place the resulting GDAs into your ''AddIns\module_name\module\override'' directory.<br />
Never place anything in your ''AddIns\module_name\core\override'' directory or it will affect other modules than the one you are editing.<br />
<br />
There used to be a [[Bug: ExcelProcessor doesn't handle row IDs above 8.3 million correctly|bug]] that prevented large string IDs from compiling correctly. This is now fixed. For the record, the old workaround was to edit the GDA files in the toolset to correct the string IDs manually, but you should now see that the string IDs are correct.<br />
<br />
{{TutorialRef|Compiling 2DAs|GDA}}<br />
<br />
== Creating the backgrounds plot ==<br />
The background plot is used for keeping track of a PC’s background and can be used to affect conversation options.<br />
<br />
The single player game uses a plot called gen00pt_backgrounds to keep track of the PC background. You can find it in the ''\_Global\Generic'' folder of the plots tab if you want to take a look. We will create a similar plot for our custom backgrounds. Create a new plot and call it ''bdm_000pt_backgrounds'' (My naming convention is to use 000 to indicate a resource that isn’t tied to any particular area – feel free to use your own convention but remember to update any references later in the tutorial). Add main plot flags as indicated in the picture below:<br />
<br />
[[Image:Back_tut_bg_plot.png]]<br />
<br />
You could also add some defined flags if you wanted. Defined flags can be used to return some combination of the main flags such as TRAVELLER or add some extra condition like FEMALE_APPRENTICE or ELVEN_APPRENTICE. Defined flags are beyond the scope of this tutorial however.<br />
<br />
{{TutorialRef|Designer Resources|Plot}}<br />
<br />
== Creating the scripts ==<br />
We are not going to edit any of the original core game scripts, we will only be adding new scripts of our own. As we discuss how to do this you should examine the core scripts that are referred to, but under no circumstances should you make any changes to those files. By leaving the core scripts as they are we make our modification more compatible with any future patches that may be released. If you modified the core scripts and then a patch was released that overwrote those scripts you would lose your changes. Also keeping your modification contained within your own module allows you to make different modifications to different modules within the one toolset.<br />
<br />
Lets start off with a script to handle the character generation events that are normally handled by the module_core script. Create a new script called ''bdm_module_core''. It is up to you what directory structure to use for your scripts but it can be a good idea to keep all your scripts in a directory with your module name to make them distinct from the core scripts. Then if you are emulating the functionality of a particular core script you can mirror the original directory structure underneath your main module folder. So in this case the module_core script is contained in the ''\_Core Scripts'' folder so we will put our bdm_module_core in ''\Backgrounds demo\_Core Scripts'' (the underscore ensures the core directories come first – looks like Bioware accidentally created one without it! I’m pretty sure Core and _Core are meant to be the same directory). Organising things this way will really help with keeping track of your scripts.<br />
<br />
The ''bdm_module_core'' script should contain the following code:<br />
<br />
<dascript><br />
#include "global_objects_h"<br />
void main(){<br />
event ev = GetCurrentEvent();<br />
int nEvent = GetEventType(ev); //extract event type from current event<br />
int nEventHandled = FALSE; //keep track of whether the event has been handled<br />
switch(nEvent){<br />
case EVENT_TYPE_MODULE_START:{<br />
// -----------------------------------------------------------------<br />
// Initiate character generation.<br />
// -----------------------------------------------------------------<br />
PreloadCharGen(); //preloads resources for character generation<br />
StartCharGen(GetHero(),0,TRUE); //initiates character generation<br />
break;<br />
}<br />
default:<br />
{<br />
// -----------------------------------------------------------------<br />
// Handle character generation events sent by the engine.<br />
// -----------------------------------------------------------------<br />
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END) <br />
|| nEvent == EVENT_TYPE_PLAYERLEVELUP )<br />
{<br />
HandleEvent(ev, R"bdm_sys_chargen.ncs");<br />
nEventHandled = TRUE;<br />
}<br />
break;<br />
}<br />
<br />
}<br />
if (!nEventHandled) { //If this event wasn't handled by this script, let the core script try<br />
HandleEvent(ev, RESOURCE_SCRIPT_MODULE_CORE);<br />
}<br />
}<br />
</dascript><br />
<br />
Now go to ''file > manage modules'' and open the properties for your module and set the script property to point at this script.<br />
<br />
Our new script handles some of the events that are usually handled by the module_core script. Once it has handled the event it chooses whether or not to pass the event on to module_core. The first event that we handle is EVENT_TYPE_MODULE_START, which is where we initiate character generation. In this case we pass the event on to the core script to handle after we have done what we need to.<br />
<br />
The second thing we handle is actually a group of events. If you look in the module_core script you will see that right down the bottom in the default event handler is some code that looks just like the code we have added in our default event, with a couple of little differences. Instead of passing the character generation events to the sys_chargen.ncs script we are going to pass it to our own script called ''bdm_sys_chargen.ncs'' which we will write shortly. If we catch one of those character generation events then we want to handle it ourselves and prevent the core script from handling it so we set nEventHandled = TRUE. Note that any other event that is caught by the default handler but isn’t a character generation event is going to go straight on through to the core script.<br />
<br />
Before we create the ''bdm_sys_chargen'' script we are going to need some new constants defined. Create a new script called ''bdm_2da_constants_h'' and put it in folder ''\Backgrounds demo\_Core Includes''. Now add the following to this script:<br />
<br />
<dascript><br />
// -----------------------------------------------------------------------------<br />
// Backgrounds - rules/backgrounds.xls<br />
// -----------------------------------------------------------------------------<br />
const int BACKGROUND_SERVANT = 1;<br />
const int BACKGROUND_APPRENTICE = 2;<br />
const int BACKGROUND_TRAVELLER = 3;<br />
</dascript><br />
<br />
These constants provide a way for us to refer to the background IDs that we defined in the 2DA files without having to remember the numbers. Constants like this also make your code more readable. If you need to add more new items to 2DAs when you are modding something else you can also add constants for them here. From now on we will be using these background constants instead of the original single player background constants that you can find in the ''2da_constants_h'' script. That means we’d better find all the places where those constants are used and update them with our own scripts.<br />
<br />
Create another new script and call it ''bdm_sys_chargen'' and put it in a folder called ''\Backgrounds demo\_Systems''. Put the following code in it:<br />
<br />
<dascript><br />
#include "bdm_sys_chargen_h"<br />
#include "log_h"<br />
<br />
const int CHARGEN_QUICKSTART_QUICK = 0;<br />
const int CHARGEN_QUICKSTART_NORMAL = 1;<br />
const int CHARGEN_QUICKSTART_ADVANCED = 2;<br />
<br />
void _RunChargen(int nRace, int nClass, object oChar, int nBackground)<br />
{<br />
<br />
Chargen_InitializeCharacter(oChar);<br />
Chargen_SelectGender(oChar,GENDER_MALE);<br />
Chargen_SelectRace(oChar,nRace);<br />
Chargen_SelectCoreClass(oChar,nClass);<br />
Chargen_SelectBackground(oChar, nBackground,FALSE);<br />
<br />
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);<br />
Chargen_InitInventory(oChar,0,nEquipIdx);<br />
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_STRENGTH, 3,FALSE);<br />
Chargen_SpendAttributePoints(oChar,PROPERTY_ATTRIBUTE_DEXTERITY, 2,FALSE);<br />
<br />
}<br />
<br />
void main(){<br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
object oChar = GetEventObject(ev,0);<br />
<br />
int nMode;<br />
int nInt0 = GetEventInteger(ev,0);<br />
int nInt1 = GetEventInteger(ev,1);<br />
// -------------------------------------------------------------------------<br />
// Debug Data.<br />
// -------------------------------------------------------------------------<br />
Log_Trace(LOG_CHANNEL_EVENTS_CHARGEN,"bdm_sys_chargen","Chargen Event:" + Log_GetEventNameById (nEventType) <br />
+ " " + ToString(nInt0) + "," + ToString(nInt1), oChar);<br />
<br />
int nEventHandled = FALSE;<br />
<br />
switch (nEventType)<br />
{<br />
// ----------------------------------------------------------------------<br />
// This fires when the player selects the icon corresponding to any of<br />
// the available backgrounds<br />
//<br />
// nInt0 - Constant BACKGROUND_* integer<br />
// ----------------------------------------------------------------------<br />
case EVENT_TYPE_CHARGEN_SELECT_BACKGROUND: {<br />
int nBackground = nInt0;<br />
// -----------------------------------------------------------------<br />
// Set the background on the player and reinitialize plot flags<br />
// for the background<br />
// -----------------------------------------------------------------<br />
Chargen_InitializeCharacter(oChar,TRUE);<br />
Chargen_SelectGender(oChar,GetCreatureGender(oChar));<br />
Chargen_SelectRace(oChar,GetCreatureRacialType(oChar));<br />
Chargen_SelectCoreClass(oChar,GetCreatureCoreClass(oChar));<br />
<br />
bdm_Chargen_SelectBackground(oChar, nBackground, FALSE);<br />
bdm_Chargen_SetupPlotFlags(oChar);<br />
<br />
// -----------------------------------------------------------------<br />
// Generate the index into the equipment template 2da and<br />
// then load the starting equipment based on the data returned.<br />
// -----------------------------------------------------------------<br />
int nClass = GetCreatureCoreClass(oChar);<br />
int nRace = GetCreatureRacialType(oChar);<br />
int nEquipIdx = Chargen_GetEquipIndex(nRace, nClass, nBackground);<br />
Chargen_InitInventory(oChar,0,nEquipIdx);<br />
nEventHandled = TRUE;<br />
break;<br />
}<br />
case EVENT_TYPE_CHARGEN_END: {<br />
nMode = nInt0;<br />
int nQuickStart = nInt1;<br />
// 0 - quickstart<br />
// 1 - normal \<br />
// 2 - advanced / treat as the same<br />
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","MODE: " + IntToString(nMode) <br />
+ ", Quick Start: " + IntToString(nQuickStart));<br />
if (nMode == CHARGEN_MODE_CREATE && nQuickStart == CHARGEN_QUICKSTART_QUICK){<br />
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen","Setting default values for player character");<br />
<br />
int nRandClass = abs((GetLowResTimer()%3)+1);<br />
<br />
if(nRandClass == CLASS_ROGUE || nRandClass == CLASS_WARRIOR)<br />
{<br />
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_SERVANT );<br />
<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT, TRUE);<br />
}<br />
else // mage<br />
{<br />
_RunChargen(RACE_HUMAN, nRandClass, oChar, BACKGROUND_APPRENTICE );<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE, TRUE);<br />
}<br />
Chargen_SetNumTactics(oChar);<br />
SetCanLevelUp(oChar,Chargen_HasPointsToSpend(oChar));<br />
SendEventModuleChargenDone("", "");<br />
nEventHandled = TRUE;<br />
}<br />
break;<br />
}<br />
} //end switch<br />
<br />
if (!nEventHandled){<br />
HandleEvent(ev, R"sys_chargen.ncs");<br />
}<br />
<br />
<br />
}<br />
</dascript><br />
<br />
There are two events in the original sys_chargen script that we need to replace because they deal with backgrounds. The first of these is EVENT_TYPE_CHARGEN_SELECT_BACKGROUND and the other is EVENT_TYPE_CHARGEN_END. For the second event we only need to change the case where the character is being created in quickstart mode, so we just handle that section of the code. The objective here is to change only as much as we need to and then pass any remaining events through to the original sys_chargen script. Take some time to compare the new script with Bioware’s ''sys_chargen'' script .<br />
<br />
You will notice that we include a script called ''bdm_sys_chargen_h'' and that we use some functions with a ''bdm_'' prefix. Those functions are contained in that include file which we’ll write now. Essentially these are modifications of a couple of functions from the ''sys_chargen_h'' include file. Create a new script and call it ''bdm_sys_chargen_h''. Put it in folder ''\Backgrounds demo\_Systems\Includes'' and add the following code:<br />
<br />
<dascript><br />
#include "sys_chargen_h"<br />
#include "bdm_2da_constants_h"<br />
#include "wrappers_h"<br />
#include "plt_bdm_000pt_backgrounds"<br />
<br />
void bdm_Chargen_SelectBackground(object oChar, int nBackground, int bUnApply = FALSE)<br />
{<br />
Log_Chargen("bdm_Chargen_SelectBackground","-- " + (bUnApply?"Un":"") +"Selecting BG: " + ToString(nBackground),oChar);<br />
// -------------------------------------------------------------------------<br />
// 1. Set the background variable<br />
// - Create creature property (or check what we used so far<br />
// - We don't set backgrounds on non player generated chars.<br />
// -------------------------------------------------------------------------<br />
if (bUnApply)<br />
{<br />
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, 0.0, PROPERTY_VALUE_BASE);<br />
}<br />
else<br />
{<br />
SetCreatureProperty(oChar, PROPERTY_SIMPLE_BACKGROUND, IntToFloat(nBackground), PROPERTY_VALUE_BASE);<br />
}<br />
// -------------------------------------------------------------------------<br />
// 2. Give one skill<br />
// - retrieve the skill that is granted by the background from backgrounds.xls<br />
// - give it to the player.<br />
// -------------------------------------------------------------------------<br />
int nAbility = ChargenGetBackgroundSkill(GetCreatureRacialType(oChar), nBackground);<br />
if (nAbility)<br />
{<br />
_AddAbility (oChar, nAbility, bUnApply);<br />
}<br />
}<br />
<br />
void bdm_Chargen_SetupPlotFlags(object oChar)<br />
{<br />
int nRace = GetCreatureRacialType(oChar);<br />
int nBackground = GetPlayerBackground(oChar);<br />
<br />
Log_Trace(LOG_CHANNEL_CHARACTER,"bdm_sys_chargen_h","Setting plot flags, race: " <br />
+ IntToString(nRace) + ", background: " + IntToString(nBackground));<br />
<br />
// First, init all flags (debug setup)<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,FALSE);<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,FALSE);<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,FALSE);<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,FALSE);<br />
<br />
switch (nBackground)<br />
{<br />
case BACKGROUND_SERVANT:<br />
{<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_SERVANT,TRUE); break;<br />
break;<br />
}<br />
case BACKGROUND_APPRENTICE:<br />
{<br />
WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_APPRENTICE,TRUE); break;<br />
break;<br />
}<br />
case BACKGROUND_TRAVELLER:<br />
{<br />
switch(nRace)<br />
{<br />
case RACE_DWARF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_DWARF_TRAVELLER,TRUE); break;<br />
case RACE_ELF: WR_SetPlotFlag(PLT_BDM_000PT_BACKGROUNDS, BDM_GEN_BACK_ELF_TRAVELLER,TRUE); break;<br />
}<br />
break;<br />
}<br />
}<br />
}<br />
</dascript><br />
<br />
Lets examine these two functions. First you should compare them to their original versions. For ''bdm_Chargen_SelectBackground()'' we have actually made a more generic version of the function that should work with any backgrounds. We have removed the hard coded values for the background abilities and now use the function ChargenGetBackgroundSkill() which actually gets the background skill from the backgrounds 2DA file that we edited earlier (recall the last three columns that give a skill depending on background and race). If you need fancier logic than just reading the values form the GDA (e.g. like Bioware’s logic for the Noble background) then you can always go back to hard coding them the way Bioware did.<br />
<br />
The second function is ''bdm_Chargen_SetupPlotFlags()'' which does just what it says. Remember the plot we created earlier? Here we set the appropriate flag based on race and background.<br />
<br />
{{TutorialRef|Script}}<br />
<br />
== Testing that everything works ==<br />
Now compile your scripts and export your module. Also, make sure that you export your talk table.<br />
<br />
'''IMPORTANT!''' ''Always make sure you empty your \Dragon Age\packages\core\override folder after doing an export. Due to a bug in the current toolset your single player game will become damaged if you don’t do this before playing.''<br />
<br />
You should now be able to run your game and see the backgrounds you created appear in character generation. If you want to test that the background plots have been set correctly, add an NPC to the start area and create a conversation for them in which each line is switched according to a background plot flag. You can also check that the character is receiving the abilities that we set in the 2DAs.<br />
<br />
'''NOTE''' ''There seems to be no way to change the popup message that comes up at the beginning of character generation. Altering the Pre-chargen string ID in the loadhints GDA does not seem to do anything.''<br />
<br />
{{TutorialRef|Exporting a module}}<br />
<br />
== Optional extras ==<br />
There are a couple of other Bioware scripts that reference the background constants. They are not essential to modify because they are not used anywhere by default. The genev_tutorial script uses a background check but unless you plan on firing the tutorial from your module then you won’t have need of it. Also there is at least one debug script that makes use of the original single player backgrounds (to grant a background plot flag to the PC) so if you want similar debug functionality you may have to roll your own function.<br />
<br />
== Conclusion ==<br />
In this tutorial we have demonstrated a way to modify the backgrounds used in the game without altering any of the core scripts. It is expected that a similar approach could be taken to modding other aspects of the game such as adding classes or races. In these cases the scripts that were created in this tutorial could be extended to handle other parts of the character generation process such as class and race selection.<br />
<br />
[[Category:Character generation]]<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Adding_custom_items_to_custom_modules_tutorial&diff=12715Adding custom items to custom modules tutorial2010-03-18T18:24:37Z<p>TrueKeaton: are != our</p>
<hr />
<div>This guide will show you the easiest way to create a custom item and add it to your inventory by using a console command '''runscript aa_give_item'''.<br />
<br />
There are people who say that using the default 'singleplayer' module is a source for future problems so we'll be using our own module.<br />
<br />
I hope this tutorial helps.<br />
<br />
Author: RandyG [mailto:randy@pcwinsupport.com Email Me]<br />
<br />
Revised by LazyMonk.<br />
<br />
Thanks LazyMonk, I'll probably add pictures later to make it easier<br />
<br />
== Things needed ==<br />
*1. Dragon age origins game.<br />
*2. Access to the console in-game ([http://dragonage.wikia.com/wiki/Console Instructions on accessing console]).<br />
*3. Dragon age origins Toolset.<br />
*4. Ability to follow instructions.<br />
<br />
== Creating a new module ==<br />
*1. Open the toolset and click on '''File -> Manage Modules'''.<br />
*2. Click '''New'''.<br />
*3. Enter 'my_module' in ''Name'' and ''UID'' fields, ignore the rest. Click '''OK'''.<br />
*4. Double-click 'my_module' that was added to the list.<br />
<br />
{{TutorialRef|Module|Module#Creating a new module}}<br />
<br />
== Creating an item ==<br />
<br />
*1. On the palette window select items (the sword icon).<br />
*2. Choose an item under global.<br />
*3. Right click on the item and select '''Duplicate'''.<br />
*4. A window will popup, ignore all fields except resource name.<br />
*5. Name your item in the resource name field (only letters, numbers and '_').<br />
*6. In the main tab you will see your item, modify it to your liking. Editing the item's additional effects is in 'Item properties'.<br />
*7. Once finished: click '''Tools -> save'''.<br />
*8. look above at the tab's title, it should be '''custom_resource_name.uti''' (with your selected name).<br />
*9. Right click on it again and select '''Export -> Export without dependent resources'''.<br />
<br />
{{TutorialRef|Designer Resources#Creating new resources|Item|Module#Exporting a module}}<br />
<br />
== Creating a script to summon your item ==<br />
<br />
*1. Click on '''File -> new -> Script'''.<br />
*2. A window will popup, ignore all fields except resource name.<br />
*3. Enter a custom name, '''aa_give_item''' (only letters, numbers and '_'), click Ok.<br />
*4. Copy the following to the blank script window:<br />
<dascript><br />
void main() {<br />
CreateItemOnObject(R"Item file.uti", OBJECT_SELF, 1, "", TRUE);<br />
}<br />
</dascript><br />
*5. Replace '''Item file.uti''' with your '''custom_resource_name.uti''' (the title on your item's tab).<br />
*6. Click '''File -> save''' (saving automatically compiles the script).<br />
'''Notice:''' If you make more than one item you can duplicate the script line for each item with it's file name. No need for a script for every item.<br />
<br />
{{TutorialRef|Script}}<br />
<br />
== Last Steps ==<br />
*1. Goto folder: My Documents\BioWare\Dragon Age\AddIns\my_module\core\override\toolsetexport.<br />
*2. look for the '''custom_resource_name.uti''' file.<br />
*3. Goto folder: My Documents\BioWare\Dragon Age\AddIns\my_module\module\override\toolsetexport.<br />
*4. look for two files named '''aa_give_item''', of types '''nss''' and '''ncs'''.<br />
*5. Move the '''uti''' and '''ncs''' to folder: My Documents\BioWare\Dragon Age\packages\core\override.<br />
*6. Delete the '''nss''' file.<br />
*7. Load a saved game and enter a console command '''runscript aa_give_item''' ([http://dragonage.wikia.com/wiki/Console Instructions on accessing console]). Comment - you may find that [[PRCSCR]] is a better method.<br />
*8. Your custom item should be in your inventory. Enjoy.<br />
<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Follower_tutorial&diff=12514Follower tutorial2010-03-11T21:35:23Z<p>TrueKeaton: /* Create a New Hire Function Include */</p>
<hr />
<div>== Simple Follower Creation ==<br />
<br />
Follow these steps to create a follower that<br />
<br />
- Levels up with a default package<br />
<br />
- Can be chosen from the party picker<br />
<br />
- Can gain XP<br />
<br />
This guide assumes you know how to create a creature and are comfortable with basic scripting.<br />
<br />
You should only use this simple method if you are sure there will be empty space in the active party when your follower is recruited.<br />
<br />
A more comprehensive approach when there are more than three potential party members is discussed in the FAQ below. It's worth taking the time to understand the basics first, though. <br />
<br />
=== Create the creature ===<br />
<br />
Create a creature to act as your follower. Set its name, appearance, gender, head morph, conversation, inventory etc as you want them to behave in-game.<br />
<br />
Set an appropriate '''Tag''' (you'll be using it a lot). I suggest "party_charname".<br />
<br />
Make sure you choose a '''Class'''. For most followers this should be Rogue, Warrior or Wizard.<br />
<br />
[[File:class.jpg]]<br />
<br />
<br />
Under Package/Scaling set:<br />
<br />
'''General Package Type''' to be '''Party Members'''<br />
<br />
'''Package''' to be an appropriate value (probably "Generic - Wizard" or similar)<br />
<br />
'''Package AI''' (there should only be one choice)<br />
<br />
'''Rank''' to be '''Player'''<br />
<br />
[[File:package.jpg]]<br />
<br />
Save and export your character as normal.<br />
<br />
<br />
=== Overlay char_stage ===<br />
<br />
In the official campaign, the party picker uses a special area called char_stage. Whether you're extending the official campaign or making a standalone campaign, there is a function that allows you to overlap the offical stage with your own, so that both stages are active simultaneously in game.<br />
<br />
In your resource palette, right-click char_stage under the Global folder and select Duplicate to make a copy of the stage with a new resource name, e.g. my_char_stage. In the resource properties, ensure that both Module and Owner Module are set to your module, and the folder of your choice.<br />
<br />
<br />
[[File:area_palette.jpg]]<br />
<br />
<br />
<br />
Create a new waypoint for your follower to appear on the party picker. This waypoint '''must''' have a tag in the form of "char_" followed by the exact tag of your follower.<br />
<br />
<br />
[[File:char_stage.jpg]]<br />
<br />
In this example the tag of my follower is '''bc_party_miera''' so her waypoint tag must be '''char_bc_party_miera'''<br />
<br />
For a standalone module (such as in this example), put your waypoint wherever you please. The illustrated one is directly on top of Morrigan's. For an add-in to the main campaign, you should position your wp appropriately relative to the core party members.<br />
<br />
Save and export the area.<br />
<br />
Add the following to your module event script:<br />
<dascript><br />
case EVENT_TYPE_MODULE_GETCHARSTAGE:<br />
{<br />
// Overlay the existing stage with my stage<br />
// "my_char_stage" is the resource name of the overlay area<br />
// "partypicker" is the name of the default GDA<br />
SetPartyPickerStage("my_char_stage", "partypicker");<br />
break;<br />
}<br />
</dascript><br />
<br />
=== Create m2DAs for the Party Picker ===<br />
<br />
You will need to create two Excel spreadsheets.<br />
<br />
The first should be named (both worksheet and file) '''partypicker_''' with a unique suffix. In this example, my first spreadsheet is named partypicker_fofbc.xls with a worksheet name of partypicker_fofbc - the suffix being the acronym of my module.<br />
<br />
Set up your columns as follows:<br />
<br />
<br />
[[File:partypickerm2da.jpg]]<br />
<br />
The '''ID''' for your follower must be '''12 or higher'''. 11 is the highest value used in the base 2DA. 12 is fine for standalone modules, add-ins will probably want to use an arbitrarily high number to avoid potential conflicts.<br />
<br />
The '''Label''' should be the follower's name as you wish it to appear on the party picker.<br />
<br />
The '''Tag''' must be your follower's tag.<br />
<br />
All other values are non-functioning defaults and should be specified as in the image above unless you know explicitly what you're doing.<br />
<br />
<br />
'''NOTE - ON SELECTION ANIMATIONS'''<br />
<br />
Add Animation and Remove Animation are actually Id numbers of different animations, taken from anim_base.gda<br />
<br />
Enter and Exit version of animations are generally the best ones to use, altough one can try others. NOT ALL ANIMATIONS WILL WORK, since some require special conditions.<br />
Here are some examples you can use:<br />
<br />
819 - talk cursing<br />
<br />
629 - reading a book (doesn't work, since it probably requires a book object)<br />
<br />
844 - hands behind back (848 and 849 are Enter and Exit versions respectfully)<br />
<br />
850 - chest pounding salute<br />
<br />
811 - fist pounding<br />
<br />
277 - dance<br />
<br />
247 - cast area spell<br />
<br />
500 - vfx cast<br />
<br />
600 - surprised<br />
<br />
603 - praying<br />
<br />
607 - head bow<br />
<br />
609 - standing at attention<br />
<br />
651,652 - crouch pray (Enter and exit)<br />
<br />
808 - point forward<br />
<br />
825 - nodding<br />
<br />
840 - hand chop or frustration<br />
<br />
905,906 - crouch (Enter, Exit)<br />
<br />
919,920 - sit on ground (enter, exit)<br />
<br />
965 - kneel down loop<br />
<br />
972 - wipe nose<br />
<br />
976,977 - squat (Enter, Exit)<br />
<br />
986 - wipe eyes<br />
<br />
998,999 - hands clasped (Enter, exit)<br />
<br />
3029 - inspect nails<br />
<br />
3031,3032 - playful (enter, exit)<br />
<br />
3054,3056 - slouch (enter, exit)<br />
255 - in-place fly<br />
<br />
<br />
'''NOTE - ON SELECTION VFX''' <br />
<br />
The VFX column is the ID of the vFX effect taken from vFx_base.gda. This one is a bit more tricky, since it also references the BlendTree value from the same file.<br />
Find the ID of the spell effect and look for the BlendTreeName column (should the the 12th columun) and enter BOTH into the respective columns for your character in the partypicker file.<br />
<br />
Some examples:<br />
<br />
ID --- BLENDTREENAME --- EFFECT<br />
<br />
6039 --- fxm_energy_up_p --- Lady of the Forest pillar of light<br />
<br />
6040 --- fxm_power_in_p --- Branka - power in<br />
<br />
3054 --- fxc_lotf_c --- Lady of the Forest - swirling leaves<br />
<br />
3009 --- fxc_succubus_c --- Succubus crust<br />
<br />
1549 --- fxa_hly_imp_c --- Holy Impact crust<br />
<br />
1076 --- fxa_spi_aur_mht_c --- Spirit - Aura Might crust<br />
<br />
<br />
<br />
<br />
The second spreadsheet should be named '''party_picker_''' (note middle underscore). Once again append your unique suffix (in this example party_picker_fofbc.xls with party_picker_fofbc as its worksheet).<br />
<br />
Set up your columns and data like so:<br />
<br />
<br />
[[File:party_pickerm2da.jpg]]<br />
<br />
'''ID''' and '''Tag''' should match what you did in the first spreadsheet. Specify INVALID COLUMN for the third column.<br />
<br />
<br />
If you're familiar with m2DAs, generate them from these files, copy them to your module's override directory, and skip to the next step. Otherwise, read on:<br />
<br />
- Go to '''\Program Files\Dragon Age\tools\ResourceBuild\Processors''' (or wherever you installed Dragon Age)<br />
<br />
- Copy '''ExcelProcessor.exe''' from that folder to whichever folder has the excel sheets you just created.<br />
<br />
- Drag and drop your xls files onto ExcelProcessor. This will create .gda files.<br />
<br />
- Copy these .gda files to your module's export directory (probably \Documents\Bioware\Dragon Age\AddIns\yourModule\module\override\toolsetexport). Make sure they are included in your .dazip when the time comes to build your module.<br />
<br />
If you are an OpenOffice user and have trouble with ExcelProcessor, you can use [http://social.bioware.com/project/755/ GDApp] to directly create the 2DAs. It rocks!<br />
<br />
=== Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event ===<br />
<br />
Amusingly enough, the Party Picker does not actually add followers to the party. However it raises an event that allows you to do so. Your module script needs to capture this event and execute some code.<br />
<br />
The following example shows what to do with the event. The full script would work as a module script for an add-in (assuming it didn't need to do anything else), but otherwise you'll have to incorporate the event into your own module script. <br />
<br />
If you're not sure how to set a module script, go to '''File''' then '''Manage Modules,''' select your module and click '''Properties.'''<br />
<br />
<dascript><br />
#include "utility_h"<br />
<br />
void main()<br />
{<br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_PARTYMEMBER_ADDED:<br />
{<br />
object oFollower = GetEventObject(ev, 0);<br />
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); //Allows the follower to gain XP<br />
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.<br />
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); //Adds follower to the active party<br />
break;<br />
}<br />
<br />
}<br />
}<br />
</dascript><br />
<br />
'''SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE)''' is the key statement to add the follower to the active party. You must have this.<br />
<br />
'''SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0)''' is a bug-fix, as followers hired with UT_HireFollower() do not receive XP by default. This statement fixes that, and I consider it best practice to keep it in this event to ensure it is always set. You will not wish to do this if you want a follower that should not gain XP to be on the party picker.<br />
<br />
<br />
Note that you do not need to intercept the corresponding event for a party member being removed - the party picker handles spawning/despawning, and thus will successfully remove members.<br />
<br />
<br />
Remember to save and export your module script.<br />
<br />
<br />
If you're not sure how to set a module script, go to '''File''' then '''Manage Modules,''' select your module and click '''Properties.''' The module script is in the General category, as seen below:<br />
<br />
[[File:module_script.jpg]]<br />
<br />
You can set this to any script you've created. See [[Scripting tutorial]] and [[Character generation]] for more background and some simple examples of event-handling scripts. In general, you will want to make sure standalone module scripts pass events through to module_core (as in the [[Character generation]] examples) and add-in scripts do not (as in the example above).<br />
<br />
=== Create Your Hiring Script ===<br />
<br />
Now all that remains is to actually hire the follower :)<br />
<br />
Create a script to handle the hiring (which will most likely be fired from a conversation). The script is quite simple:<br />
<br />
<dascript><br />
#include "utility_h"<br />
<br />
void main() {<br />
<br />
object oFollower = GetObjectByTag("bc_party_miera"); //Use CreateObject() if the creature isn't present in the module yet<br />
<br />
UT_HireFollower(oFollower); //Hires the follower<br />
<br />
SetPartyPickerGUIStatus(2);<br />
<br />
ShowPartyPickerGUI(); //Shows the Party Picker; necessary for the follower to gain XP<br />
<br />
}<br />
</dascript><br />
<br />
Make sure you use your own follower's tag and not the example one :)<br />
<br />
This script fires the party picker after hiring the follower. That is absolutely necessary via this method, as we have put the XP fix onto an event fired by the party picker. You cannot put the XP fix into this script, it must be called from a later one (the bug is caused by an errant call to an event in player_core, which will be executed AFTER this script).<br />
<br />
<br />
The easiest way to use this script is directly from conversation, putting it as an action on a line of dialogue where the PC invites the follower to join them. If you're not sure how to associate a script with a dialogue line, see the following image:<br />
<br />
[[File:hire_conv.jpg]]<br />
<br />
Create your dialogue as normal, select the line you want to fire the script, and click the '''Plots and Scripting''' tab. Use the '''Script''' file chooser in the Action section to browse to the script you created.<br />
<br />
<br />
If everything worked, you should see something like this:<br />
<br />
<br />
[[File:picker_success.jpg|thumb|200px|center]]<br />
<br />
== Advanced Follower Creation ==<br />
<br />
<br />
Follow these steps to have full control over the creation of your follower, with options such as:<br />
<br />
- Unique level-up template<br />
<br />
- Class and specialisation chosen via script<br />
<br />
- Any starting state<br />
<br />
- Level higher than the PC<br />
<br />
- Starts with a specialisation point rather than a specific specialisation<br />
<br />
- Set plot flags in the call to the hire script<br />
<br />
<br />
=== Prepare Creature, char_stage and Party Picker m2DAs ===<br />
<br />
<br />
Follow the same steps to create your follower creature, char_stage and Party Picker m2DAs as above.<br />
<br />
=== Create Party Plot ===<br />
<br />
While not necessary, it's very helpful to have plot flags set when a follower is hired or joins/leaves the active party. This makes conversation interjections and the like very easy.<br />
<br />
Create a plot with appropriate flags. There's no real need to associate journal text with them:<br />
<br />
[[File:follower_plot.jpg]]<br />
<br />
See FAQ for an alternative approach to plots when there are more than three potential party members.<br />
<br />
=== Add Plot Flags to Party Picker Event Intercept ===<br />
<br />
We then update our module script to make use of that plot, like so:<br />
<br />
<dascript><br />
#include "utility_h"<br />
#include "wrappers_h"<br />
#include "plt_bc_create_party" //make sure you include your own plot, not mine<br />
<br />
void main()<br />
{<br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_PARTYMEMBER_ADDED:<br />
{<br />
object oFollower = GetEventObject(ev, 0);<br />
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);<br />
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);<br />
<br />
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.<br />
<br />
if (GetTag(oFollower) == "bc_party_miera") { //You must explicitly test for your follower's tag.<br />
WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, TRUE); //Make sure you use your own flags!<br />
}<br />
<br />
break;<br />
} <br />
<br />
case EVENT_TYPE_PARTYMEMBER_DROPPED: <br />
{<br />
object oFollower = GetEventObject(ev, 0); <br />
<br />
if (GetTag(oFollower) == "bc_party_miera") { <br />
WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, FALSE); //As above, but set false.<br />
}<br />
<br />
}<br />
<br />
}<br />
}<br />
</dascript><br />
<br />
=== Create a Level Up Template ===<br />
<br />
<br />
You can skip this step if you're content to use one of the generic Rogue, Wizard or Warrior templates, but I don't recommend it. Making a template that suits your character is easy and will almost always be better for the player than a generic one that spends points poorly.<br />
<br />
Go to \Program Files\Dragon Age\tools\Source\2DA (or wherever you installed Dragon Age).<br />
<br />
You should see a number of excel sheets of the form '''ALCharacter.xls''' (such as ALAlistair.xls, ALLeliana.xls, ALRogue_Default.xls etc). Open the one closest to your character (ie Morrigan or Wynne for a wizard, Leliana or Zevran for a rogue). Save a copy as '''ALYourcharacter.xls''' in whatever directory you're using to create your 2DAs, remembering to rename the worksheet '''ALYourcharacter''' (in this example, ALMiera.xls with ALMiera as its worksheet).<br />
<br />
It should look something like this:<br />
<br />
[[File:ALtable.jpg|thumb|500px|center]]<br />
<br />
<br />
'''Columns B''' and '''C''' are the talents/spells available to this character. Do not change them.<br />
<br />
'''Columns F''' and '''G''' are the skills available to this character. Do not change them.<br />
<br />
We will edit the remaining columns like so:<br />
<br />
<br />
==== Setting Stat Weights ====<br />
<br />
<br />
The stat weights in '''column J''' determine how the follower will spend their attribute points, in a rough ratio. So if Dexterity is set to 1.5 and Intelligence to 1, you should expect to see 3 points of Dex for every 2 points of Cunning in-game (note Intelligence is the label used in the toolset for Cunning).<br />
<br />
Simply change the values in J to reflect how you'd like the character to spend their points. In this example we're creating a wizard, so we're not going to mess around:<br />
<br />
[[File:miera_stat_weights.jpg]]<br />
<br />
This character will only raise magic. I set the value to 5 rather than something like 1 to provide room underneath for the other stats while still overwhelmingly favouring magic, but in practice I only really ever want that one stat. <br />
<br />
In a note left on this column in the existing templates, Bioware's Georg Zoeller writes, "This is the weight of each attribute (row id links into properties.xls.id). 1.0 means 'try to keep this attribute level' (spend 1 point per level). 0.5 means 'try to spend 1 point every two levels' and so on."<br />
<br />
The default Mage, Rogue and Warrior templates include '''column L''' labeled "AttInit." Editing these values seems to have no effect on followers set to use these templates.<br />
<br />
<br />
==== Setting Talent and Skill Priorities ====<br />
<br />
<br />
'''Columns D''' and '''E''' are the talents/spells that the character will buy, in preference order from top to bottom.<br />
<br />
'''Columns H''' and '''I''' are the skills that the character will buy, in preference order from top to bottom.<br />
<br />
<br />
To change these, just copy the appropriate two cells from columns B&C or F&G over the ones you want to replace.<br />
<br />
For example, here we're copying Morrigan's template. Morrigan has Spider Shape high in her preferences, which we do not want.<br />
<br />
[[File:AlMori_talent_pref.jpg]]<br />
<br />
We decide we'd prefer Flame Blast, so we find it in columns B&C and copy both cells:<br />
<br />
[[File:ALMori_copy.jpg]]<br />
<br />
Then we select the cells we want to replace in columns D&E and paste over them:<br />
<br />
[[File:ALMori_paste.jpg]]<br />
<br />
<br />
<br />
Continue this process until your priorities list for both skills and talents/spells is exactly as you want it. Make sure you have at least as many priorities as the core follower you're copying - points that cannot be spent according to these priorities have a habit of vanishing.<br />
<br />
If you used any abilities from a specialisation, make sure you remember to set that specialisation with the function we'll introduce later. The autolevel scripts will add specialisation abilities to a character regardless of whether they have that spec or not.<br />
<br />
==== Create a M2DA_base_ m2DA ====<br />
<br />
Dragon Age will need to know where to find your autolevel template. We tell it by extending M2DA_base.gda<br />
<br />
Create a spreadsheet with the name and worksheet name in the form '''M2DA_base_''' with your unique suffix (in this example, M2DA_base_fofbc.xls with M2DA_base_fofbc as a worksheet).<br />
<br />
Set up its columns and data like so (note I used GDApp because Open Office wasn't cooperating for this one!):<br />
<br />
[[File:m2da_base_fofbc.jpg]]<br />
<br />
The '''ID''' should be very high to avoid conflicts. I've arbitrarily chosen 50,000+ here. Carefully note the ID you've chosen for your character, you will need it later.<br />
<br />
Set the '''Label''' and '''Worksheet''' to be the name of your autolevel template worksheet (ALCharactername if you've been following this).<br />
<br />
Set the '''PackageIDForAI''' to be 0, it shouldn't be needed for followers.<br />
<br />
<br />
When you're done, use ExcelProcessor to make GDAs of both spreadsheets and copy them to your module's export folder.<br />
<br />
<br />
<br />
FOR AUTOLEVEL TO WORK AFTER RECRUITING:<br />
<br />
Look in packages.xls. <br />
There is a column called LevelupTable. That links to a corresponding AL* table. For instance, row 81 is for Leliana. Her LevelupTable value is 258. If you look that up in 2DA_base, you'll see it links to ALLeliana.<br />
(alternatively, you could try packages_base.gda)<br />
<br />
=== Create a New Hire Function Include ===<br />
<br />
Many vital steps of follower addition happen inside an event in player_core. Followers tend to be extremely buggy (no skill tree, for example) if this event does not fire.<br />
<br />
However, that event is not very flexible. In order to control it to our requirements, we need to replicate its functionality inside our own script. This is probably much safer than messing with player_core directly!<br />
<br />
Create a new script file, naming it something like '''hireCustomFollower_h'''. We will be including this wherever we want to hire a follower.<br />
<br />
Paste in the following script:<br />
<br />
<dascript><br />
#include "sys_chargen_h"<br />
#include "wrappers_h"<br />
#include "utility_h"<br />
#include "sys_rewards_h"<br />
#include "approval_h"<br />
#include "sys_autolevelup_h"<br />
<br />
/* Jye Nicolson 5-Jan-2010<br />
This function set duplicates the full functionality chain of UT_HireFollower, with the following exceptions:<br />
<br />
- Followers can gain XP<br />
- Autolevel status can be set (default off)<br />
- Followers can be set to any starting state (default Available) and will still be properly initalised and added to the party pool<br />
- Autolevel tables for non-core followers can be explicitly set.<br />
- Class and Specialisation can be chosen via script<br />
- Followers without specialisations are granted a spec point by default.<br />
<br />
It should only ever be called once each for characters you intend to be full followers.<br />
Much of the protective code handling summoned creatures etc. in player_core is not present here.<br />
<br />
Calling the function:<br />
<br />
Simple:<br />
<br />
hireCustomFollower(oFollower, CLASS_WARRIOR);<br />
<br />
Change the class to CLASS_WIZARD or CLASS_ROGUE as appropriate. <br />
This will hire your follower and make them available. <br />
They will auto level up with a default package, and receive a free spec point.<br />
<br />
Best Practice:<br />
<br />
hireCustomFollower(oFollower, CLASS_WARRIOR, PLT_YOUR_PARTY_PLOT, YOUR_FOLLOWER_JOINED_FLAG, ABILITY_TALENT_HIDDEN_CHAMPION);<br />
<br />
Where the plot and flag are those for your module (remember to create the plot and include it on the calling script), and ABILITY_TALENT_HIDDEN etc is the desired spec.<br />
<br />
You should also have a custom ALTable set up. <br />
See wiki for details, and remember to edit it in to GetCustomFollowerALTable below or pass it directly as an argument to hireCustomFollower.<br />
<br />
<br />
Full argument list:<br />
<br />
void hireCustomFollower (<br />
object oFollower, //Pass your follower object, mandatory<br />
<br />
int nForceClass, //Pass a Class constant here, usually CLASS_ROGUE, CLASS_WARRIOR, CLASS_WIZARD. Mandatory due to a bug.<br />
<br />
string sPlot = "", //It's recommended you have a plot flag to be set when the follower joins. Pass the plot constant here. Remember to #include in calling script<br />
<br />
int nPlotFlag = "", //And then pass the flag constant. Will be set to TRUE if available.<br />
<br />
int nForceSpec = 0, //This is the ID of the Specialisation you want. Note they are NOT classes, but abilities. The full list is:<br />
//ABILITY_SPELL_HIDDEN_ARCANE_WARRIOR, ABILITY_SPELL_HIDDEN_BLOODMAGE, ABILITY_SPELL_HIDDEN_SHAPESHIFTER, ABILITY_SPELL_HIDDEN_SPIRIT_HEALER<br />
//ABILITY_SPELL_HIDDEN_BARD, ABILITY_TALENT_HIDDEN_ASSASSIN, ABILITY_TALENT_HIDDEN_DUELIST, ABILITY_TALENT_HIDDEN_RANGER<br />
//ABILITY_TALENT_HIDDEN_BERSERKER, ABILITY_TALENT_HIDDEN_CHAMPION, ABILITY_TALENT_HIDDEN_REAVER, ABILITY_TALENT_HIDDEN_TEMPLAR<br />
//I recommended forcing a spec, particularly if your ALTable includes abilities from one.<br />
<br />
int nALTable = 0, //This is the ID of an ALTable from 2DA_base.GDA or your module's m2DA_base_*.GDA I recommended the latter, but you can edit that into GetCustomFollowerALTable below rather than passing it.<br />
<br />
int bInvokePicker = FALSE, //Sets whether the party picker should be opened on hiring. I think it's cleaner to call the picker outside this script, particularly if you have multiple hires at once.<br />
<br />
int nInitialState = FOLLOWER_STATE_AVAILABLE, //This sets whether the follower joins the active party or not. Options are:<br />
//FOLLOWER_STATE_ACTIVE (put them in the active party)<br />
//FOLLOWER_STATE_LOCKEDACTIVE (force them into the active party and keep them there, remember to change this later.<br />
//FOLLOWER_STATE_AVAILABLE (make them available on the party picker (if you've set it up for them), but not in the active party)<br />
//Plus some others you're unlikely to need at this time. Defaults to AVAILABLE because having 4+ active followers is screwy.<br />
<br />
string sCurrPlot = "", //If you set FOLLOWER_STATE_ACTIVE or FOLLOWER_STATE_LOCKEDACTIVE, the script will check to see if you passed this.<br />
//It is recommended that you have a plot flag set for a given follower being in the active party, this makes conversation interjection etc. much easier.<br />
<br />
int nCurrPlotFlag = 0, //This flag will be set if FOLLOWER_STATE_ACTIVE or FOLLOWER_STATE_LOCKEDACTIVE are true<br />
//AND sCurrPlot has a value AND nCurrPlotFlag is > 0. <br />
//ie if you added someone to the active party and have a plot flag to cope with it.<br />
<br />
int nAutolevel = 0, //Sets the Autolevel flag on the character sheet. 0 is off, 1 is on, 2 forces it on and removes it so the player can't turn it off.<br />
<br />
<br />
bFreeSpecPoint = TRUE, //This grants a specialisation point to the follower if they do not have a specialisation. <br />
//It's important to set this false for classes that do not have specs, such as CLASS_DOG.<br />
<br />
int nTargetLevel = 0, //If you want a specific level, set this. Generally not worthwhile unless you set it higher than the player, since they'll just get XP from the party picker anyway.<br />
<br />
int nMinLevel = 0 //Set this if there's a specific level you don't want the follower to go below. Probably only useful if the PC might be very low level but not necessarily so. <br />
<br />
)<br />
*/ <br />
/* GetCustomFollowerALTable() <br />
This function is where you put your custom table assignments.<br />
<br />
You should explicitly test for the tag of your follower (not mine!) and assign a value to nTable from your m2DA extension to M2DA_base <br />
<br />
See wiki for details on how to do this, or ignore it to get the default Warrior/Rogue/Wizard AL tables.<br />
<br />
NOTE: you MUST explicitly set a table for non-Warrior/Rogue/Wizards, eg dogs. Use TABLE_AL_DOG for a default Mabari.<br />
*/<br />
<br />
int GetCustomFollowerALTable(object oFollower) {<br />
int nTable = _GetTableToUseForAL(oFollower);<br />
<br />
if (GetTag(oFollower) == "bc_party_miera") { <br />
nTable = 50143; <br />
} <br />
<br />
if (GetTag(oFollower) == "bc_party_jysavin") {<br />
nTable = 50144; <br />
}<br />
<br />
if (GetTag(oFollower) == "bc_party_geldual") {<br />
nTable = 50145; <br />
}<br />
<br />
if (GetTag(oFollower) == "bc_party_braghon") {<br />
nTable = 50146; <br />
}<br />
<br />
return nTable; <br />
} <br />
<br />
// This just cleans up the main function a little<br />
<br />
int GetCustomFollowerTargetLevel(object oFollower, object oHero, int nPackage, int nMinLevel = 0) {<br />
int nPlayerLevel = GetLevel(oHero);<br />
int nTargetLevel = 0;<br />
<br />
if((nPlayerLevel >= 13) || (nPlayerLevel == 1) || (!_UT_GetIsPlotFollower(oFollower))) {<br />
nTargetLevel = nPlayerLevel;<br />
} else {<br />
nTargetLevel = nPlayerLevel + 1;<br />
}<br />
<br />
if (nMinLevel == 0) { //If nMinLevel is not specified, checks package 2DA for a value<br />
nMinLevel = GetM2DAInt(TABLE_PACKAGES, "MinLevel", nPackage);<br />
}<br />
if(nMinLevel > 0 && nMinLevel > nTargetLevel) {<br />
nTargetLevel = nMinLevel;<br />
} <br />
<br />
return nTargetLevel;<br />
<br />
} <br />
<br />
// Moving this black box out :) I don't really understand it, but it should function if you have tactics set up in a package.<br />
<br />
void InitCustomFollowerTactics(object oFollower, int nPackage) {<br />
int nTableID = GetM2DAInt(TABLE_PACKAGES, "FollowerTacticsTable", nPackage);<br />
if (nTableID != -1)<br />
{<br />
int nRows = GetM2DARows(nTableID);<br />
int nMaxTactics = GetNumTactics(oFollower);<br />
<br />
int nTacticsEntry = 1;<br />
int i;<br />
for (i = 1; i <= nRows && nTacticsEntry <= nMaxTactics; ++i)<br />
{<br />
int bAddEntry = FALSE;<br />
int nTargetType = GetM2DAInt(nTableID, "TargetType", i);<br />
int nCondition = GetM2DAInt(nTableID, "Condition", i);<br />
int nCommandType = GetM2DAInt(nTableID, "Command", i);<br />
int nCommandParam = GetM2DAInt(nTableID, "SubCommand", i);<br />
<br />
int nUseType = GetM2DAInt(TABLE_COMMAND_TYPES, "UseType", nCommandType);<br />
if (nUseType == 0)<br />
{<br />
bAddEntry = TRUE;<br />
}<br />
else<br />
{<br />
bAddEntry = HasAbility(oFollower, nCommandParam);<br />
}<br />
<br />
if (bAddEntry)<br />
{<br />
SetTacticEntry(oFollower, nTacticsEntry, TRUE, nTargetType, nCondition, nCommandType, nCommandParam);<br />
++nTacticsEntry;<br />
}<br />
}<br />
}<br />
} <br />
<br />
/* InitCustomFollowerSpec:<br />
<br />
This function tries to set the forced Specialisation. If there is none, it checks the package for one. <br />
<br />
If there isn't either of those, it grants a free spec point if bFreeSpecPoint is true.<br />
<br />
*/<br />
<br />
void InitCustomFollowerSpec(object oFollower, int nPackage, int nForceSpec, int bFreeSpecPoint) {<br />
// Find specialization, and optionally add a spec point if none is found.<br />
<br />
if (nForceSpec == 0) {<br />
<br />
int nSpecAbility = GetM2DAInt(TABLE_PACKAGES, "switch1_class", nPackage); // followers can have only 1 advanced class<br />
if(nSpecAbility > 0)<br />
{<br />
AddAbility(oFollower, nSpecAbility);<br />
} else {<br />
if (bFreeSpecPoint) {<br />
SetCreatureProperty(oFollower, 38, 1.00);<br />
}<br />
} <br />
<br />
} else {<br />
<br />
AddAbility(oFollower, nForceSpec);<br />
<br />
}<br />
}<br />
<br />
/* hireCustomFollower() (See doco at top of page)<br />
<br />
I strongly suggest you reorder the parameters if you're adding many followers with advanced options.<br />
<br />
Feel free to leave them alone if you only want to set class, plot, spec or don't mind long declarations.<br />
<br />
Note nForceClass is currently compulsory due to flakiness with GetCreatureCoreClass()<br />
*/<br />
<br />
void hireCustomFollower(object oFollower, int nForceClass, string sPlot = "", int nPlotFlag = 0, int nForceSpec = 0, <br />
int nALTable = 0, int bInvokePicker = FALSE, int nInitialState = FOLLOWER_STATE_AVAILABLE, string sCurrPlot = "", <br />
int nCurrPlotFlag = 0, int nAutolevel = 0, int bFreeSpecPoint = TRUE, int nTargetLevel = 0, int nMinLevel = 0) <br />
{<br />
<br />
object oHero = GetHero();<br />
<br />
/* ################# BEGIN BASIC FOLLOWER JOIN BLOCK ###################<br />
<br />
This loosely replicates WR_SetFollowerState.<br />
<br />
<br />
*/ <br />
<br />
if (nForceClass == 0) {<br />
nForceClass = GetCreatureCoreClass(oFollower); //This is not working. Hence nForceClass mandatory.<br />
}<br />
<br />
<br />
SetGroupId(oFollower, GetGroupId(oHero)); //Puts the follower in the pc's Group.<br />
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE); //This makes them act like a player.<br />
SetFollowerState(oFollower, nInitialState); //This sets whether they are available, in the active party etc.<br />
<br />
/* ################# END BASIC FOLLOWER JOIN BLOCK ##################### */<br />
<br />
<br />
<br />
/* ################# BEGIN PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION #################<br />
This replicates the EVENT_TYPE_PARTY_MEMBER_HIRED handler from player_core, stripped down for simplicity and allowing our custom options.<br />
<br />
<br />
*/<br />
<br />
Chargen_EnableTacticsPresets(oFollower); //I assume this is important.<br />
<br />
SetLocalInt(oFollower, FOLLOWER_SCALED, 1); //This should prevent the follower being rescaled by player_core or what have you<br />
<br />
int nPackage = GetPackage(oFollower); //Gets the package, which will be used to find a number of 2DA IDs.<br />
int nPackageClass = GetM2DAInt(TABLE_PACKAGES, "StartingClass", nPackage); //I don't think this is used, even by player_core<br />
<br />
<br />
// set behavior according to package<br />
int nBehavior = GetM2DAInt(TABLE_PACKAGES, "FollowerBehavior", nPackage);<br />
<br />
if(nBehavior >= 0) {<br />
SetAIBehavior(oFollower, nBehavior);<br />
}<br />
<br />
Chargen_InitializeCharacter(oFollower); //We initialise the follower and choose race/class.<br />
<br />
Chargen_SelectRace(oFollower,GetCreatureRacialType(oFollower));<br />
Chargen_SelectCoreClass(oFollower,nForceClass); <br />
<br />
<br />
if (nTargetLevel == 0) { //This block picks a target level if not specified<br />
<br />
nTargetLevel = GetCustomFollowerTargetLevel(oFollower, oHero, nPackage, nMinLevel);<br />
}<br />
<br />
int nXp = RW_GetXPNeededForLevel(Max(nTargetLevel, 1)); //Here is where the XP is calculated and rewarded<br />
RewardXP(oFollower, nXp, FALSE, FALSE);<br />
<br />
// -------------------------------------------------------------<br />
// add hidden approval talents - (JN: I don't know how to set these yet, but when I figure it out this should make it work)<br />
// -------------------------------------------------------------<br />
int nIndex = Approval_GetFollowerIndex(oFollower);<br />
Approval_AddFollowerBonusAbility(nIndex, 0);<br />
<br />
//Handle Specialisation<br />
InitCustomFollowerSpec(oFollower, nPackage, nForceSpec, bFreeSpecPoint);<br />
<br />
// -------------------------------------------------------------<br />
// This spends all available attribute and stat points on the<br />
// creature according to the levelup table. (JN: this replicates AL_DoAutoLevelUp but with our choice of table)<br />
// -------------------------------------------------------------<br />
<br />
if (nALTable == 0) {<br />
nALTable = GetCustomFollowerALTable(oFollower);<br />
}<br />
<br />
AL_SpendAttributePoints(oFollower, nALTable, FALSE);<br />
AL_SpendSkillPoints(oFollower, nALTable, TRUE);<br />
AL_SpendSpecializationPoints(oFollower, nALTable);<br />
AL_SpendTalentSpellPoints(oFollower, nALTable, TRUE);<br />
<br />
// -------------------------------------------------------------------------<br />
// Update various UIs<br />
// -------------------------------------------------------------------------<br />
Chargen_SetNumTactics(oFollower);<br />
SetCanLevelUp(oFollower,Chargen_HasPointsToSpend(oFollower));<br />
<br />
// load tactics<br />
InitCustomFollowerTactics(oFollower, nPackage);<br />
<br />
/* ################# END PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION ################# */ <br />
<br />
<br />
SetAutoLevelUp(oFollower, nAutolevel); //This is the autolevel flag on the character sheet.<br />
<br />
//Set plot flags<br />
<br />
if (!((sPlot == "") || (nPlotFlag == 0))) { //Joined Party<br />
WR_SetPlotFlag(sPlot, nPlotFlag, TRUE); <br />
}<br />
<br />
if ((nInitialState == FOLLOWER_STATE_ACTIVE) || (nInitialState == FOLLOWER_STATE_LOCKEDACTIVE)) {<br />
if (!((sCurrPlot == "") || (nCurrPlotFlag == 0))) {<br />
WR_SetPlotFlag(sCurrPlot, nCurrPlotFlag, TRUE); //Currently in Party<br />
}<br />
}<br />
<br />
// Invoke picker if requested.<br />
<br />
if (bInvokePicker) {<br />
SetPartyPickerGUIStatus(2);<br />
ShowPartyPickerGUI();<br />
}<br />
}<br />
</dascript><br />
<br />
Yeah, I know. It can't really be any smaller. Feel free to modify it if you're confident with scripting.<br />
==== Add Your Custom Autolevel Template to GetCustomFollowerALTable() ====<br />
While you can pass the ID you made for your autolevel template to that monster function as an argument, it's better to have them all in one place if you have multiple followers.<br />
<br />
GetCustomFollowerALTable() is the first function in our include, and you can add an explicit if test for your follower there to assign the correct table id (the one from your M2DA_base_ m2DA). There is a function very much like it in sys_autolevel_h.nss for the core followers, so we'll copy Bioware's practice.<br />
<br />
Let's take a look at the function by itself:<br />
<br />
<dascript><br />
int GetCustomFollowerALTable(object oFollower) {<br />
int nTable = _GetTableToUseForAL(oFollower);<br />
<br />
if (GetTag(oFollower) == "bc_party_miera") { <br />
nTable = 50143; <br />
} <br />
<br />
if (GetTag(oFollower) == "bc_party_jysavin") {<br />
nTable = 50144; <br />
}<br />
<br />
if (GetTag(oFollower) == "bc_party_geldual") {<br />
nTable = 50145; <br />
}<br />
<br />
if (GetTag(oFollower) == "bc_party_braghon") {<br />
nTable = 50146; <br />
}<br />
<br />
return nTable; <br />
<br />
} <br />
</dascript><br />
<br />
So we have a test for each follower tag from my module, matching up to an ID which is assigned to nTable. All you need to do is change a tag from my follower to yours, and my ID to the correct one from your M2DA_base_* m2DA. Then you should delete the rest of the example if statements :)<br />
<br />
Save and export the script. Ignore the compiler error about lack of main();<br />
<br />
=== Include Function In Your Hire Script and Call It ===<br />
<br />
So instead of a hire script that calls UT_HireFollower(), we want one that includes our shiny new function and calls it.<br />
<br />
Take a look at the following example:<br />
<br />
<dascript><br />
#include "plt_bc_create_party" //Make sure you include your party handling plot<br />
#include "hireCustomFollower_h" // And include the function script - which will in turn include a bunch of stuff<br />
<br />
void main() {<br />
<br />
//Initialising my objects, not super-relevant to the example <br />
<br />
object oHero = GetHero();<br />
object oMiera = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_miera.utc", GetLocation(oHero));<br />
object oJysavin = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_jysavin.utc", GetLocation(oHero));<br />
object oBraghon = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_braghon.utc", GetLocation(oHero));<br />
object oSpider = CreateObject(OBJECT_TYPE_CREATURE, R"bc_party_geldual.utc", GetLocation(oHero));<br />
<br />
//Simplest hire call - adds to the party as a wizard. Class is currently compulsory due to a bug.<br />
hireCustomFollower(oMiera, CLASS_WIZARD);<br />
<br />
//Add to the party and set joining plot flags<br />
hireCustomFollower(oJysavin, CLASS_WARRIOR, PLT_BC_CREATE_PARTY, PARTY_JYSAVIN_JOINED);<br />
<br />
//Add to the party, set plot flags, force a specialisation<br />
hireCustomFollower(oBraghon, CLASS_ROGUE, PLT_BC_CREATE_PARTY, PARTY_BRAGHON_JOINED, ABILITY_TALENT_HIDDEN_ASSASSIN);<br />
<br />
//More complex example - Follower added as a unique class (Dog), not granted a specialisation or spec point. <br />
//Note unique classes must have an ALTable passed here or specified in GetCustomFollowerALTable() or they won't work<br />
hireCustomFollower(oSpider, CLASS_DOG, PLT_BC_CREATE_PARTY, PARTY_GELDUAL_JOINED, 0, 0, FALSE, FOLLOWER_STATE_AVAILABLE, "", 0, 0, FALSE);<br />
<br />
//Show the party picker to let the player choose from their new companions!<br />
SetPartyPickerGUIStatus(2);<br />
ShowPartyPickerGUI(); <br />
}<br />
</dascript><br />
<br />
The example shows several of the more simple ways of invoking the function. Check the comments at the start of the function for a full list of arguments.<br />
<br />
I would suggest best practice for most followers would be to call as follows:<br />
<br />
'''hireCustomFollower(oFollower, CLASS, PLOT, PLOT_FLAG, SPECIALISATION)'''<br />
<br />
This will safely set the follower up as the desired class and specialisation (doubly important if there are spec abilities in their ALTable) while setting your plot flag for them being in the party. hireCustomFollower(oFollower, CLASS, PLOT, PLOT_FLAG, SPECIALISATION, 0, TRUE) will do the same while invoking the Party Picker automatically.<br />
<br />
Note that the specialisations are abilities and not classes - you'll find them as ABILITY_HIDDEN_ constants.<br />
<br />
If it's all worked, you should find you can now add followers with a lot more flexibility!<br />
<br />
[[File:picker_advanced.jpg|thumb|500px|center]]<br />
<br />
== Common Follower Problems & FAQ ==<br />
<br />
====Why don't my followers gain XP?====<br />
There is a bug in UT_HireFollower. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:<br />
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);<br />
to<br />
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);<br />
(Note: Be aware if you use the name UT_HireFollower_Fixed you may end up finding your include file conflicting with someone else who has named it the same in their include.)<br />
<br />
Alternately you need to clear a flag in a separate script to the one in which they're hired.<br />
<br />
You must use the '''SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);''' statement in a script you can be sure will run soon after your hiring script.<br />
<br />
<br />
====When I choose followers from the Party Picker, they spawn into the area but do not join.====<br />
<br />
You need to intercept the EVENT_TYPE_PARTYMEMBER_ADDED event and set the follower to FOLLOWER_STATE_ACTIVE. See Simple Follower Creation earlier in this document.<br />
<br />
====My followers don't have skill trees!====<br />
<br />
If a follower hasn't been through an initial chargen/autolevel event (via player_core/sys_autolevel_h) then the skill tree doesn't show. You're probably trying to be clever and get around UT_HireFollower without going all the way (see monster function above ^_^).<br />
<br />
<br />
====My followers don't have a class====<br />
<br />
GetCreatureCoreClass() seems flaky under some conditions. It's best to explicitly set the class yourself; this is why class is currently a mandatory argument to hireCustomFollower()<br />
<br />
====Dog talents don't work====<br />
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots.<br />
<br />
Line 78 of packages_base in packages.xls (Dog) should have the LevelUpTable column set to 257 which is the ALDog table.<br />
<br />
====Isn't there an easier way to do this?====<br />
<br />
Possibly. There is a way of recruiting a follower by setting a plot flag. However I don't understand it, and I expect it still doesn't allow custom autolevel templates, full control over specialisations etc. There's still a fair bit of stuff hardcoded for the core followers, I'm not sure putting a custom follower through the same process as Al, Leli et al will have good results.<br />
<br />
The next section answers this question, up to a point.<br />
<br />
==== What if there are more than three potential followers? ====<br />
This example handles larger numbers of followers, and doesn't force the player to use the party picker unless the party is already full.<br />
<br />
If you're making a new campaign, to keep life simple, allocate a unique number to each follower. You could either use a creature variable or a script, e.g.<br />
<pre><br />
// Party member id (e.g. 1=Alicia, 2=Godwin...)<br />
int cocPartyMemberID(object oPartyMember)<br />
{<br />
string sPartyMember = GetTag(oPartyMember);<br />
<br />
if (sPartyMember == "coccr_alicia") return 1;<br />
if (sPartyMember == "coccr_godwin") return 2;<br />
if (sPartyMember == "coccr_harold") return 3;<br />
if (sPartyMember == "coccr_lara" ) return 4;<br />
return 0;<br />
}<br />
</pre><br />
<br />
Make two separate plots, e.g. cocpt_hired for when a follower is first recruited, and cocpt_party to flag whether they're currently in the party. Use flag values that correspond to the unique follower id, e.g. COCPT_HIRED_GODWIN will be 2.<br />
<br />
If you're modifying the official campaign, you won't be able to make this simplification - you'll need a set of plot flags for your new party members, similar to the official ones. The logic of what follows is still correct, it just means that instead of having one set of common code that works for everyone, you have to explicitly script each party member individually using their personal plot flags.<br />
<br />
Follower conversation is now very simple. In Godwin's dialogue, the hiring line will be conditional - when COCPT_HIRED_GODWIN is clear - and it will set COCPT_HIRED_GODWIN. No conversation script is necessary. Instead, in the properties of the plot cocpt_hired, we add a plot event script, as follows.<br />
<pre><br />
// PARTY HIRE PLOT SCRIPT<br />
//<br />
// This is called in conversation when a party member is hired for the first time.<br />
// If the party is full, the party picker is displayed, which forces the PARTYMEMBER_ADDED<br />
// module event.<br />
//<br />
// The flag value is never referenced, because the code is common for all party members.<br />
<br />
#include "events_h"<br />
#include "global_objects_h"<br />
#include "utility_h"<br />
#include "sys_rewards_h"<br />
#include "log_h"<br />
#include "utility_h"<br />
#include "wrappers_h"<br />
#include "plot_h"<br />
<br />
#include "coc_h" // A header containing the cocPartyMemberID function<br />
#include "plt_cocpt_hired"<br />
#include "plt_cocpt_party"<br />
<br />
int StartingConditional()<br />
{<br />
event eParms = GetCurrentEvent();<br />
int nType = GetEventType(eParms); // GET or SET<br />
string strPlot = GetEventString(eParms, 0); // Plot GUID<br />
int nFlag = GetEventInteger(eParms, 1); // Plot flag<br />
object oParty = GetEventCreator(eParms); // Plot table owner<br />
object oFollower = GetEventObject(eParms, 0); // Conversation owner (if any)<br />
int nPlotType = GetEventInteger(eParms, 5); // Plot type<br />
<br />
int bIsTutorial = GetM2DAInt(TABLE_PLOT_TYPES, "IsTutorial", nPlotType);<br />
int bIsCodex = GetM2DAInt(TABLE_PLOT_TYPES, "IsCodex", nPlotType);<br />
<br />
int nResult = FALSE; // return value for DEFINED GET<br />
object oPC = GetPartyLeader();<br />
<br />
plot_GlobalPlotHandler(eParms); // any global plot operations, including debug info<br />
<br />
if (nType == EVENT_TYPE_SET_PLOT) // actions -> normal flags only<br />
{<br />
int nValue = GetEventInteger(eParms, 2); // 0=Clear 1=Set<br />
int nOldValue = GetEventInteger(eParms, 3); // Current flag value<br />
<br />
if (nValue)<br />
{<br />
if (GetArraySize(GetPartyList(oPC)) < 4)<br />
{<br />
UT_HireFollower(oFollower);<br />
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);<br />
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));<br />
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);<br />
WR_SetPlotFlag(PLT_COCPT_PARTY, cocPartyMemberID(oFollower), TRUE);<br />
}<br />
else<br />
{<br />
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);<br />
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE);<br />
SendPartyMemberHiredEvent(oFollower, TRUE);<br />
// SetPartyPickerGUIStatus(PP_GUI_STATUS_USE);<br />
// ShowPartyPickerGUI();<br />
}<br />
}<br />
}<br />
else // EVENT_TYPE_GET_PLOT -> defined conditions only<br />
{<br />
switch(nFlag)<br />
{<br />
<br />
}<br />
}<br />
<br />
plot_OutputDefinedFlag(eParms, nResult);<br />
return nResult;<br />
}<br />
</pre><br />
We still need to handle the party picker events in our module event script:<br />
<pre><br />
// PARTY MEMBER ADDED - Allow XP gain. Come here, follow me, flag as party member.<br />
case EVENT_TYPE_PARTYMEMBER_ADDED:<br />
{<br />
object oFollower = GetEventObject(ev, 0);<br />
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);<br />
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));<br />
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);<br />
WR_SetPlotFlag(PLT_COCPT_PARTY, cocPartyMemberID(oFollower), TRUE);<br />
break;<br />
}<br />
// PARTY MEMBER DROPPED - flag as not party member.<br />
case EVENT_TYPE_PARTYMEMBER_DROPPED:<br />
{<br />
object oFollower = GetEventObject(ev, 0);<br />
WR_SetPlotFlag(PLT_COCPT_PARTY, cocPartyMemberID(oFollower), FALSE);<br />
}<br />
</pre><br />
When we need to refer to a particular follower explicitly, we can still do so - for example, the flag COCPT_PARTY_GODWIN will tell use whether Godwin is currently in the party or not. <br />
<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Scripting_tutorial&diff=12513Scripting tutorial2010-03-11T21:33:16Z<p>TrueKeaton: /* Interacting with plots */</p>
<hr />
<div>{{Infobox script}}<br />
The final piece of the puzzle in our little tutorial game is getting the <code>MONSTERS_SLAIN</code> flag set on our plot so that when the hero succeeds in his quest, the quest giver will know about it. This is done via scripting.<br />
<br />
Scripting is a programming language with a syntax similar to C. This tutorial assumes a small amount of programming knowledge but hopefully it will be possible even for one with no experience to pick up the basics here.<br />
<br />
== Dragon Age's event-driven model ==<br />
<br />
In Dragon Age scripts are primarily event-driven. An "event" is a package of information in a special format that gets passed around in the game to trigger behaviour. They are generated by other scripts or the game engine and are passed to an object's event-handling script.<br />
<br />
Events have a type, a target object, a time delay and a package of parameters (arbitrary number of ints, objects, floats and strings).<br />
<br />
As an example, the "<code>[[EVENT_TYPE_ATTACK_IMPACT]]</code>" event is sent by the game engine whenever an attack hits a target. It contains the identities of the attacker and the target, whether the attack was a critical hit, and the amount of damage that the attack did. It is sent to an event-handling script attached to the attacker, which takes the information it contains and handles it in whatever way is appropriate (reducing the target's hit points, usually).<br />
<br />
For our purposes right now we're not going to need to generate any events of our own. We have set all of the hut monsters to be members of team 1, and the game has a built-in feature that will generate an event when all of the members of a particular team of creatures has been killed. Our new script will respond to that event by setting the plot flag so that when the hut monsters are all defeated, the plot will change to indicate the quest objective has been accomplished.<br />
<br />
An enormous list of events for all occasions can be found at the [[Event (dascript type)|event]] page. The one we're going to want our script to look for is <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code>, which is sent when the last member of a team of creatures is destroyed. The event contains the team number within it.<br />
<br />
== Creating a basic event-handling script ==<br />
<br />
Start by creating a new script resource. We'll call our script "<code>hut_monsters_slain</code>".<br />
<br />
In most cases when a script is run the scripting engine will start with a function named "<code>main</code>". So for most scripts you'll want to start with this very basic beginning:<br />
<br />
<pre><br />
void main()<br />
{<br />
<br />
}<br />
</pre><br />
<br />
The code that will perform our tasks will be inserted between the { and } brackets. <code>main</code> doesn't return any results directly, so the function's return type is "<code>[[void]]</code>", and it takes no parameters, so the parameter list is an empty ().<br />
<br />
=== Event type constants ===<br />
<br />
Next we're going to need to make sure the script will know what we're talking about when we make references to events. The tag that tells us the type of each event is actually represented internally by a number, but since it would be impossible for a programmer to keep track of all the different event numbers without making hard-to-find mistakes Dragon Age has instead used named constants to represent them in a more human-readable name.<br />
<br />
Those constants are defined in the script <code>events_h</code>. The "<code>_h</code>" suffix stands for "header", which is a special class of script that contains only various definitions meant to be included in other scripts and doesn't do anything on its own.<br />
<br />
To include the header file, add this line to the top of our script:<br />
<br />
<pre>#include "events_h"</pre><br />
<br />
All <code>#include</code> commands should be at the top of your script before anything else, but if there's more than one it shouldn't matter what order they are in.<br />
<br />
To see whether our script now knows what <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> means you can use the constant browser on the right edge of the script editor to check if it's listed. The browser defaults to showing a list of all defined functions (the "f()" button), to set it to show all defined constants click on the "C" button.<br />
<br />
[[Image:Scripting constant browser.png]]<br />
<br />
Even without any included files the list of defined constants is going to be quite long, and for scripts with many include files it can be very difficult to find any particular constant - especially if you aren't sure exactly what its name is. To find constants more easily, type any part of its name into the filter field at the top.<br />
<br />
[[Image:Scripting constant browser filtered.png]]<br />
<br />
To insert the constant into the script at the location where the cursor is currently located, simply double-click on the constant in the constant browser. This avoids any risk of making a typo. You can also type the beginning of the constant (or any function, etc.) and press Ctrl-Space to see a list of matching values.<br />
<br />
=== Extracting information about the current event ===<br />
<br />
When an event is sent to a script the script's <code>main</code> function will be run, but it won't know anything about the event that caused it to be run without some explicit instructions.<br />
<br />
First, you will need to retrieve the package of data that is the event. We'll define a variable named <code>ev</code> that will hold this package, and set it to the "<code>event</code>" data type. To retrieve the current event and stick it into that variable, we'll use the engine-defined function <code>[[GetCurrentEvent]]</code>.<br />
<br />
The first line of the main function will therefore be:<br />
<code>event ev = GetCurrentEvent();</code><br />
<br />
Every event will have an event type. As described above, this event type is represented internally by an integer. We'll create an integer variable named <code>nEventType</code> to hold it, and use the <code>GetEventType</code> function to extract it from <code>ev</code>. The next line will be:<br />
<br />
<code>int nEventType = [[GetEventType]](ev);</code><br />
<br />
The rest of the information packaged with the event depends on exactly what kind of event it is, so the rest of the code we write will be event-specific. To make sure only the correct code is run we'll use a <code>switch</code> statement. We're only looking for one particular event so we could just as easily have used an <code>if</code> statement but a <code>switch</code> is more extendable for future use.<br />
<br />
<pre><br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
//our event-specific code goes here<br />
break;<br />
}<br />
}<br />
</pre><br />
<br />
We know from the documentation for the <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> event, that it comes with a single piece of information; the team number. It's an integer, so we can extract it with the <code>[[GetEventInteger]]</code> function. <code>[[GetEventInteger]]</code> takes two parameters, the event object (which we've stored in the variable <code>ev</code>) and the index of the integer we want, in this case 0 (this is listed in the documentation).<br />
<br />
We also know that the team number we gave the hut monsters is 1, so we want to update the plot only when we receive an event indicating that team number 1 has been destroyed. We can do this with an <code>if</code> statement:<br />
<br />
<pre><br />
if (GetEventInteger(ev,0) == 1)<br />
{<br />
//code to update the plot here<br />
}<br />
</pre><br />
<br />
== Interacting with plots ==<br />
<br />
To interact with a plot's flags you'll need to have some way for the script to know where the plot flags are and what they're named. This is done in a similar manner to how we told the script what the event types were named; by including the plot file in the script.<br />
<br />
Plots are not the same as regular scripts, though, so when including them they are distinguished from regular scripts through the use of a <code>plt_</code> prefix in their name. The plot we wish to interact with is called <code>clear_the_hut</code>, so at the top of the script file you'll need to put the line:<br />
<br />
<code>#include "plt_clear_the_hut"</code><br />
<br />
Now your script will have access to the plot's flags and will be able to read or change them. You'll find that several new constants have been defined; <code>PLT_CLEAR_THE_HUT</code> contains the plot object, and the integer constants <code>MONSTERS_SLAIN</code>, <code>QUEST_ACCEPTED</code> and <code>REWARD_RECEIVED</code> identify the flags within the plot.<br />
<br />
Changing the state of the flags is done with the <code>WR_SetPlotFlag</code> function that is defined in the include file <code>wrappers_h</code> (<code>wrappers_h</code> contains a variety of utility functions that handle operations requiring low-level access to the game. Add <code>#include "wrappers_h"</code> to the top of your script). In our case, we want to set the plot flag <code>MONSTERS_SLAIN</code>. The <code>WR_SetPlotFlag</code> function takes three parameters; the plot identifier, the flag identifier, and the state we want to set it to:<br />
<br />
<pre><br />
WR_SetPlotFlag(PLT_CLEAR_THE_HUT, MONSTERS_SLAIN, TRUE);<br />
</pre><br />
<br />
== Associating an event script with an object ==<br />
<br />
The script is almost complete now, but until we've linked it up to some object in the game that can receive events it will never actually be run.<br />
<br />
Most objects in the game will have a field named "Script" shown in the object inspector. According to the documentation for the <code>EVENT_TYPE_TEAM_DESTROYED</code> event it is sent to the area object the team is in, so we'll want to open the hut_interior area now and go to its Script entry. The default event script for areas is <code>area_core</code>, which handles basic area events in a default way.<br />
<br />
This is where you'll want to put the <code>hut_monsters_slain</code> script. Click on the ellipsis ([[Image:ellipsis.png]]) button and select the new script. It will replace <code>area_core</code>, and now when there are events sent to this area our new script will be triggered and handle them.<br />
<br />
=== Passing execution to other event handlers ===<br />
<br />
There is just one problem remaining to be resolved now. As mentioned above, the <code>area_core</code> script normally handles a variety of events that are sent to areas. Now that we've replaced the default event handler with our custom script, and our script only responds to one specific event, there's nothing responding to the rest of the events coming into the area any more. Our custom script has preempted and therefore effectively disabled all the default area event processing by not responding to every possible area event.<br />
<br />
We don't want to re-implement all that default event handling in our own script, for a variety of reasons; it's a lot of work, we could make mistakes, and it would be difficult to update the default event handling across all of our areas in the future. Fortunately there's an easy way to tell Dragon Age to use another script to handle events; namely, the <code>[[HandleEvent]]</code> function. It takes two parameters, the event object to be handled and an identifier for the script that should handle it.<br />
<br />
A set of constants defining identifiers for the common default scripts is in the <code>global_objects_h</code> header file, but we won't need to include that because <code>wrappers_h</code> includes it already. So all we need to do is insert the following line after our switch statement:<br />
<br />
<pre><br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
</pre><br />
<br />
(The RESOURCE_SCRIPT_AREA_CORE constant is defined in global_objects_h, which we don't need to include explicitly in this case because it's already included in wrappers_h.)<br />
<br />
With this addition, whenever any event is sent to the hut_interior area, first our script will run and process the event, and then it will send it on to <code>area_core</code> to handle the default area processing normally done when no custom event handling script is being used.<br />
<br />
The final text of our script, then, is:<br />
<br />
<pre><br />
#include "events_h"<br />
#include "plt_clear_The_hut"<br />
#include "wrappers_h"<br />
<br />
void main()<br />
{ <br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
if(GetEventInteger(ev,0) == 1)<br />
{<br />
WR_SetPlotFlag(PLT_CLEAR_THE_HUT, MONSTERS_SLAIN, TRUE);<br />
}<br />
break;<br />
}<br />
}<br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
}<br />
</pre><br />
<br />
[[Category:Scripts]]<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Scripting_tutorial&diff=12512Scripting tutorial2010-03-11T21:33:08Z<p>TrueKeaton: /* Passing execution to other event handlers */</p>
<hr />
<div>{{Infobox script}}<br />
The final piece of the puzzle in our little tutorial game is getting the <code>MONSTERS_SLAIN</code> flag set on our plot so that when the hero succeeds in his quest, the quest giver will know about it. This is done via scripting.<br />
<br />
Scripting is a programming language with a syntax similar to C. This tutorial assumes a small amount of programming knowledge but hopefully it will be possible even for one with no experience to pick up the basics here.<br />
<br />
== Dragon Age's event-driven model ==<br />
<br />
In Dragon Age scripts are primarily event-driven. An "event" is a package of information in a special format that gets passed around in the game to trigger behaviour. They are generated by other scripts or the game engine and are passed to an object's event-handling script.<br />
<br />
Events have a type, a target object, a time delay and a package of parameters (arbitrary number of ints, objects, floats and strings).<br />
<br />
As an example, the "<code>[[EVENT_TYPE_ATTACK_IMPACT]]</code>" event is sent by the game engine whenever an attack hits a target. It contains the identities of the attacker and the target, whether the attack was a critical hit, and the amount of damage that the attack did. It is sent to an event-handling script attached to the attacker, which takes the information it contains and handles it in whatever way is appropriate (reducing the target's hit points, usually).<br />
<br />
For our purposes right now we're not going to need to generate any events of our own. We have set all of the hut monsters to be members of team 1, and the game has a built-in feature that will generate an event when all of the members of a particular team of creatures has been killed. Our new script will respond to that event by setting the plot flag so that when the hut monsters are all defeated, the plot will change to indicate the quest objective has been accomplished.<br />
<br />
An enormous list of events for all occasions can be found at the [[Event (dascript type)|event]] page. The one we're going to want our script to look for is <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code>, which is sent when the last member of a team of creatures is destroyed. The event contains the team number within it.<br />
<br />
== Creating a basic event-handling script ==<br />
<br />
Start by creating a new script resource. We'll call our script "<code>hut_monsters_slain</code>".<br />
<br />
In most cases when a script is run the scripting engine will start with a function named "<code>main</code>". So for most scripts you'll want to start with this very basic beginning:<br />
<br />
<pre><br />
void main()<br />
{<br />
<br />
}<br />
</pre><br />
<br />
The code that will perform our tasks will be inserted between the { and } brackets. <code>main</code> doesn't return any results directly, so the function's return type is "<code>[[void]]</code>", and it takes no parameters, so the parameter list is an empty ().<br />
<br />
=== Event type constants ===<br />
<br />
Next we're going to need to make sure the script will know what we're talking about when we make references to events. The tag that tells us the type of each event is actually represented internally by a number, but since it would be impossible for a programmer to keep track of all the different event numbers without making hard-to-find mistakes Dragon Age has instead used named constants to represent them in a more human-readable name.<br />
<br />
Those constants are defined in the script <code>events_h</code>. The "<code>_h</code>" suffix stands for "header", which is a special class of script that contains only various definitions meant to be included in other scripts and doesn't do anything on its own.<br />
<br />
To include the header file, add this line to the top of our script:<br />
<br />
<pre>#include "events_h"</pre><br />
<br />
All <code>#include</code> commands should be at the top of your script before anything else, but if there's more than one it shouldn't matter what order they are in.<br />
<br />
To see whether our script now knows what <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> means you can use the constant browser on the right edge of the script editor to check if it's listed. The browser defaults to showing a list of all defined functions (the "f()" button), to set it to show all defined constants click on the "C" button.<br />
<br />
[[Image:Scripting constant browser.png]]<br />
<br />
Even without any included files the list of defined constants is going to be quite long, and for scripts with many include files it can be very difficult to find any particular constant - especially if you aren't sure exactly what its name is. To find constants more easily, type any part of its name into the filter field at the top.<br />
<br />
[[Image:Scripting constant browser filtered.png]]<br />
<br />
To insert the constant into the script at the location where the cursor is currently located, simply double-click on the constant in the constant browser. This avoids any risk of making a typo. You can also type the beginning of the constant (or any function, etc.) and press Ctrl-Space to see a list of matching values.<br />
<br />
=== Extracting information about the current event ===<br />
<br />
When an event is sent to a script the script's <code>main</code> function will be run, but it won't know anything about the event that caused it to be run without some explicit instructions.<br />
<br />
First, you will need to retrieve the package of data that is the event. We'll define a variable named <code>ev</code> that will hold this package, and set it to the "<code>event</code>" data type. To retrieve the current event and stick it into that variable, we'll use the engine-defined function <code>[[GetCurrentEvent]]</code>.<br />
<br />
The first line of the main function will therefore be:<br />
<code>event ev = GetCurrentEvent();</code><br />
<br />
Every event will have an event type. As described above, this event type is represented internally by an integer. We'll create an integer variable named <code>nEventType</code> to hold it, and use the <code>GetEventType</code> function to extract it from <code>ev</code>. The next line will be:<br />
<br />
<code>int nEventType = [[GetEventType]](ev);</code><br />
<br />
The rest of the information packaged with the event depends on exactly what kind of event it is, so the rest of the code we write will be event-specific. To make sure only the correct code is run we'll use a <code>switch</code> statement. We're only looking for one particular event so we could just as easily have used an <code>if</code> statement but a <code>switch</code> is more extendable for future use.<br />
<br />
<pre><br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
//our event-specific code goes here<br />
break;<br />
}<br />
}<br />
</pre><br />
<br />
We know from the documentation for the <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> event, that it comes with a single piece of information; the team number. It's an integer, so we can extract it with the <code>[[GetEventInteger]]</code> function. <code>[[GetEventInteger]]</code> takes two parameters, the event object (which we've stored in the variable <code>ev</code>) and the index of the integer we want, in this case 0 (this is listed in the documentation).<br />
<br />
We also know that the team number we gave the hut monsters is 1, so we want to update the plot only when we receive an event indicating that team number 1 has been destroyed. We can do this with an <code>if</code> statement:<br />
<br />
<pre><br />
if (GetEventInteger(ev,0) == 1)<br />
{<br />
//code to update the plot here<br />
}<br />
</pre><br />
<br />
== Interacting with plots ==<br />
<br />
To interact with a plot's flags you'll need to have some way for the script to know where the plot flags are and what they're named. This is done in a similar manner to how we told the script what the event types were named; by including the plot file in the script.<br />
<br />
Plots are not the same as regular scripts, though, so when including them they are distinguished from regular scripts through the use of a <code>plt_</code> prefix in their name. The plot we wish to interact with is called <code>clear_the_hut</code>, so at the top of the script file you'll need to put the line:<br />
<br />
<code>#include "plt_clear_the_hut"</code><br />
<br />
Now your script will have access to the plot's flags and will be able to read or change them. You'll find that several new constants have been defined; <code>PLT_CLEAR_THE_HUT</code> contains the plot object, and the integer constants <code>MONSTERS_SLAIN</code>, <code>QUEST_ACCEPTED</code> and <code>REWARD_RECEIVED</code> identify the flags within the plot.<br />
<br />
Changing the state of the flags is done with the <code>WR_SetPlotFlag</code> function that is defined in the include file <code>wrappers_h</code> (<code>wrappers_h</code> contains a variety of utility functions that handle operations requiring low-level access to the game. Add <code>#include "wrappers_h"</code> to the top of your script). In our case, we want to set the plot flag <code>MONSTERS_SLAIN</code>. The <code>WR_SetPlotFlag</code> function takes three parameters; the plot identifier, the flag identifier, and the state we want to set it to:<br />
<br />
<pre><br />
WR_SetPlotFlag("PLT_CLEAR_THE_HUT", MONSTERS_SLAIN, TRUE);<br />
</pre><br />
<br />
== Associating an event script with an object ==<br />
<br />
The script is almost complete now, but until we've linked it up to some object in the game that can receive events it will never actually be run.<br />
<br />
Most objects in the game will have a field named "Script" shown in the object inspector. According to the documentation for the <code>EVENT_TYPE_TEAM_DESTROYED</code> event it is sent to the area object the team is in, so we'll want to open the hut_interior area now and go to its Script entry. The default event script for areas is <code>area_core</code>, which handles basic area events in a default way.<br />
<br />
This is where you'll want to put the <code>hut_monsters_slain</code> script. Click on the ellipsis ([[Image:ellipsis.png]]) button and select the new script. It will replace <code>area_core</code>, and now when there are events sent to this area our new script will be triggered and handle them.<br />
<br />
=== Passing execution to other event handlers ===<br />
<br />
There is just one problem remaining to be resolved now. As mentioned above, the <code>area_core</code> script normally handles a variety of events that are sent to areas. Now that we've replaced the default event handler with our custom script, and our script only responds to one specific event, there's nothing responding to the rest of the events coming into the area any more. Our custom script has preempted and therefore effectively disabled all the default area event processing by not responding to every possible area event.<br />
<br />
We don't want to re-implement all that default event handling in our own script, for a variety of reasons; it's a lot of work, we could make mistakes, and it would be difficult to update the default event handling across all of our areas in the future. Fortunately there's an easy way to tell Dragon Age to use another script to handle events; namely, the <code>[[HandleEvent]]</code> function. It takes two parameters, the event object to be handled and an identifier for the script that should handle it.<br />
<br />
A set of constants defining identifiers for the common default scripts is in the <code>global_objects_h</code> header file, but we won't need to include that because <code>wrappers_h</code> includes it already. So all we need to do is insert the following line after our switch statement:<br />
<br />
<pre><br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
</pre><br />
<br />
(The RESOURCE_SCRIPT_AREA_CORE constant is defined in global_objects_h, which we don't need to include explicitly in this case because it's already included in wrappers_h.)<br />
<br />
With this addition, whenever any event is sent to the hut_interior area, first our script will run and process the event, and then it will send it on to <code>area_core</code> to handle the default area processing normally done when no custom event handling script is being used.<br />
<br />
The final text of our script, then, is:<br />
<br />
<pre><br />
#include "events_h"<br />
#include "plt_clear_The_hut"<br />
#include "wrappers_h"<br />
<br />
void main()<br />
{ <br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
if(GetEventInteger(ev,0) == 1)<br />
{<br />
WR_SetPlotFlag(PLT_CLEAR_THE_HUT, MONSTERS_SLAIN, TRUE);<br />
}<br />
break;<br />
}<br />
}<br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
}<br />
</pre><br />
<br />
[[Category:Scripts]]<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Scripting_tutorial&diff=12511Scripting tutorial2010-03-11T21:02:54Z<p>TrueKeaton: /* Interacting with plots */</p>
<hr />
<div>{{Infobox script}}<br />
The final piece of the puzzle in our little tutorial game is getting the <code>MONSTERS_SLAIN</code> flag set on our plot so that when the hero succeeds in his quest, the quest giver will know about it. This is done via scripting.<br />
<br />
Scripting is a programming language with a syntax similar to C. This tutorial assumes a small amount of programming knowledge but hopefully it will be possible even for one with no experience to pick up the basics here.<br />
<br />
== Dragon Age's event-driven model ==<br />
<br />
In Dragon Age scripts are primarily event-driven. An "event" is a package of information in a special format that gets passed around in the game to trigger behaviour. They are generated by other scripts or the game engine and are passed to an object's event-handling script.<br />
<br />
Events have a type, a target object, a time delay and a package of parameters (arbitrary number of ints, objects, floats and strings).<br />
<br />
As an example, the "<code>[[EVENT_TYPE_ATTACK_IMPACT]]</code>" event is sent by the game engine whenever an attack hits a target. It contains the identities of the attacker and the target, whether the attack was a critical hit, and the amount of damage that the attack did. It is sent to an event-handling script attached to the attacker, which takes the information it contains and handles it in whatever way is appropriate (reducing the target's hit points, usually).<br />
<br />
For our purposes right now we're not going to need to generate any events of our own. We have set all of the hut monsters to be members of team 1, and the game has a built-in feature that will generate an event when all of the members of a particular team of creatures has been killed. Our new script will respond to that event by setting the plot flag so that when the hut monsters are all defeated, the plot will change to indicate the quest objective has been accomplished.<br />
<br />
An enormous list of events for all occasions can be found at the [[Event (dascript type)|event]] page. The one we're going to want our script to look for is <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code>, which is sent when the last member of a team of creatures is destroyed. The event contains the team number within it.<br />
<br />
== Creating a basic event-handling script ==<br />
<br />
Start by creating a new script resource. We'll call our script "<code>hut_monsters_slain</code>".<br />
<br />
In most cases when a script is run the scripting engine will start with a function named "<code>main</code>". So for most scripts you'll want to start with this very basic beginning:<br />
<br />
<pre><br />
void main()<br />
{<br />
<br />
}<br />
</pre><br />
<br />
The code that will perform our tasks will be inserted between the { and } brackets. <code>main</code> doesn't return any results directly, so the function's return type is "<code>[[void]]</code>", and it takes no parameters, so the parameter list is an empty ().<br />
<br />
=== Event type constants ===<br />
<br />
Next we're going to need to make sure the script will know what we're talking about when we make references to events. The tag that tells us the type of each event is actually represented internally by a number, but since it would be impossible for a programmer to keep track of all the different event numbers without making hard-to-find mistakes Dragon Age has instead used named constants to represent them in a more human-readable name.<br />
<br />
Those constants are defined in the script <code>events_h</code>. The "<code>_h</code>" suffix stands for "header", which is a special class of script that contains only various definitions meant to be included in other scripts and doesn't do anything on its own.<br />
<br />
To include the header file, add this line to the top of our script:<br />
<br />
<pre>#include "events_h"</pre><br />
<br />
All <code>#include</code> commands should be at the top of your script before anything else, but if there's more than one it shouldn't matter what order they are in.<br />
<br />
To see whether our script now knows what <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> means you can use the constant browser on the right edge of the script editor to check if it's listed. The browser defaults to showing a list of all defined functions (the "f()" button), to set it to show all defined constants click on the "C" button.<br />
<br />
[[Image:Scripting constant browser.png]]<br />
<br />
Even without any included files the list of defined constants is going to be quite long, and for scripts with many include files it can be very difficult to find any particular constant - especially if you aren't sure exactly what its name is. To find constants more easily, type any part of its name into the filter field at the top.<br />
<br />
[[Image:Scripting constant browser filtered.png]]<br />
<br />
To insert the constant into the script at the location where the cursor is currently located, simply double-click on the constant in the constant browser. This avoids any risk of making a typo. You can also type the beginning of the constant (or any function, etc.) and press Ctrl-Space to see a list of matching values.<br />
<br />
=== Extracting information about the current event ===<br />
<br />
When an event is sent to a script the script's <code>main</code> function will be run, but it won't know anything about the event that caused it to be run without some explicit instructions.<br />
<br />
First, you will need to retrieve the package of data that is the event. We'll define a variable named <code>ev</code> that will hold this package, and set it to the "<code>event</code>" data type. To retrieve the current event and stick it into that variable, we'll use the engine-defined function <code>[[GetCurrentEvent]]</code>.<br />
<br />
The first line of the main function will therefore be:<br />
<code>event ev = GetCurrentEvent();</code><br />
<br />
Every event will have an event type. As described above, this event type is represented internally by an integer. We'll create an integer variable named <code>nEventType</code> to hold it, and use the <code>GetEventType</code> function to extract it from <code>ev</code>. The next line will be:<br />
<br />
<code>int nEventType = [[GetEventType]](ev);</code><br />
<br />
The rest of the information packaged with the event depends on exactly what kind of event it is, so the rest of the code we write will be event-specific. To make sure only the correct code is run we'll use a <code>switch</code> statement. We're only looking for one particular event so we could just as easily have used an <code>if</code> statement but a <code>switch</code> is more extendable for future use.<br />
<br />
<pre><br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
//our event-specific code goes here<br />
break;<br />
}<br />
}<br />
</pre><br />
<br />
We know from the documentation for the <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> event, that it comes with a single piece of information; the team number. It's an integer, so we can extract it with the <code>[[GetEventInteger]]</code> function. <code>[[GetEventInteger]]</code> takes two parameters, the event object (which we've stored in the variable <code>ev</code>) and the index of the integer we want, in this case 0 (this is listed in the documentation).<br />
<br />
We also know that the team number we gave the hut monsters is 1, so we want to update the plot only when we receive an event indicating that team number 1 has been destroyed. We can do this with an <code>if</code> statement:<br />
<br />
<pre><br />
if (GetEventInteger(ev,0) == 1)<br />
{<br />
//code to update the plot here<br />
}<br />
</pre><br />
<br />
== Interacting with plots ==<br />
<br />
To interact with a plot's flags you'll need to have some way for the script to know where the plot flags are and what they're named. This is done in a similar manner to how we told the script what the event types were named; by including the plot file in the script.<br />
<br />
Plots are not the same as regular scripts, though, so when including them they are distinguished from regular scripts through the use of a <code>plt_</code> prefix in their name. The plot we wish to interact with is called <code>clear_the_hut</code>, so at the top of the script file you'll need to put the line:<br />
<br />
<code>#include "plt_clear_the_hut"</code><br />
<br />
Now your script will have access to the plot's flags and will be able to read or change them. You'll find that several new constants have been defined; <code>PLT_CLEAR_THE_HUT</code> contains the plot object, and the integer constants <code>MONSTERS_SLAIN</code>, <code>QUEST_ACCEPTED</code> and <code>REWARD_RECEIVED</code> identify the flags within the plot.<br />
<br />
Changing the state of the flags is done with the <code>WR_SetPlotFlag</code> function that is defined in the include file <code>wrappers_h</code> (<code>wrappers_h</code> contains a variety of utility functions that handle operations requiring low-level access to the game. Add <code>#include "wrappers_h"</code> to the top of your script). In our case, we want to set the plot flag <code>MONSTERS_SLAIN</code>. The <code>WR_SetPlotFlag</code> function takes three parameters; the plot identifier, the flag identifier, and the state we want to set it to:<br />
<br />
<pre><br />
WR_SetPlotFlag("PLT_CLEAR_THE_HUT", MONSTERS_SLAIN, TRUE);<br />
</pre><br />
<br />
== Associating an event script with an object ==<br />
<br />
The script is almost complete now, but until we've linked it up to some object in the game that can receive events it will never actually be run.<br />
<br />
Most objects in the game will have a field named "Script" shown in the object inspector. According to the documentation for the <code>EVENT_TYPE_TEAM_DESTROYED</code> event it is sent to the area object the team is in, so we'll want to open the hut_interior area now and go to its Script entry. The default event script for areas is <code>area_core</code>, which handles basic area events in a default way.<br />
<br />
This is where you'll want to put the <code>hut_monsters_slain</code> script. Click on the ellipsis ([[Image:ellipsis.png]]) button and select the new script. It will replace <code>area_core</code>, and now when there are events sent to this area our new script will be triggered and handle them.<br />
<br />
=== Passing execution to other event handlers ===<br />
<br />
There is just one problem remaining to be resolved now. As mentioned above, the <code>area_core</code> script normally handles a variety of events that are sent to areas. Now that we've replaced the default event handler with our custom script, and our script only responds to one specific event, there's nothing responding to the rest of the events coming into the area any more. Our custom script has preempted and therefore effectively disabled all the default area event processing by not responding to every possible area event.<br />
<br />
We don't want to re-implement all that default event handling in our own script, for a variety of reasons; it's a lot of work, we could make mistakes, and it would be difficult to update the default event handling across all of our areas in the future. Fortunately there's an easy way to tell Dragon Age to use another script to handle events; namely, the <code>[[HandleEvent]]</code> function. It takes two parameters, the event object to be handled and an identifier for the script that should handle it.<br />
<br />
A set of constants defining identifiers for the common default scripts is in the <code>global_objects_h</code> header file, but we won't need to include that because <code>wrappers_h</code> includes it already. So all we need to do is insert the following line after our switch statement:<br />
<br />
<pre><br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
</pre><br />
<br />
(The RESOURCE_SCRIPT_AREA_CORE constant is defined in global_objects_h, which we don't need to include explicitly in this case because it's already included in wrappers_h.)<br />
<br />
With this addition, whenever any event is sent to the hut_interior area, first our script will run and process the event, and then it will send it on to <code>area_core</code> to handle the default area processing normally done when no custom event handling script is being used.<br />
<br />
The final text of our script, then, is:<br />
<br />
<pre><br />
#include "events_h"<br />
#include "plt_clear_The_hut"<br />
#include "wrappers_h"<br />
<br />
void main()<br />
{ <br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
if(GetEventInteger(ev,0) == 1)<br />
{<br />
WR_SetPlotFlag("PLT_CLEAR_THE_HUT", MONSTERS_SLAIN, TRUE);<br />
}<br />
break;<br />
}<br />
}<br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
}<br />
</pre><br />
<br />
[[Category:Scripts]]<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Scripting_tutorial&diff=12510Scripting tutorial2010-03-11T21:02:44Z<p>TrueKeaton: /* Passing execution to other event handlers */</p>
<hr />
<div>{{Infobox script}}<br />
The final piece of the puzzle in our little tutorial game is getting the <code>MONSTERS_SLAIN</code> flag set on our plot so that when the hero succeeds in his quest, the quest giver will know about it. This is done via scripting.<br />
<br />
Scripting is a programming language with a syntax similar to C. This tutorial assumes a small amount of programming knowledge but hopefully it will be possible even for one with no experience to pick up the basics here.<br />
<br />
== Dragon Age's event-driven model ==<br />
<br />
In Dragon Age scripts are primarily event-driven. An "event" is a package of information in a special format that gets passed around in the game to trigger behaviour. They are generated by other scripts or the game engine and are passed to an object's event-handling script.<br />
<br />
Events have a type, a target object, a time delay and a package of parameters (arbitrary number of ints, objects, floats and strings).<br />
<br />
As an example, the "<code>[[EVENT_TYPE_ATTACK_IMPACT]]</code>" event is sent by the game engine whenever an attack hits a target. It contains the identities of the attacker and the target, whether the attack was a critical hit, and the amount of damage that the attack did. It is sent to an event-handling script attached to the attacker, which takes the information it contains and handles it in whatever way is appropriate (reducing the target's hit points, usually).<br />
<br />
For our purposes right now we're not going to need to generate any events of our own. We have set all of the hut monsters to be members of team 1, and the game has a built-in feature that will generate an event when all of the members of a particular team of creatures has been killed. Our new script will respond to that event by setting the plot flag so that when the hut monsters are all defeated, the plot will change to indicate the quest objective has been accomplished.<br />
<br />
An enormous list of events for all occasions can be found at the [[Event (dascript type)|event]] page. The one we're going to want our script to look for is <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code>, which is sent when the last member of a team of creatures is destroyed. The event contains the team number within it.<br />
<br />
== Creating a basic event-handling script ==<br />
<br />
Start by creating a new script resource. We'll call our script "<code>hut_monsters_slain</code>".<br />
<br />
In most cases when a script is run the scripting engine will start with a function named "<code>main</code>". So for most scripts you'll want to start with this very basic beginning:<br />
<br />
<pre><br />
void main()<br />
{<br />
<br />
}<br />
</pre><br />
<br />
The code that will perform our tasks will be inserted between the { and } brackets. <code>main</code> doesn't return any results directly, so the function's return type is "<code>[[void]]</code>", and it takes no parameters, so the parameter list is an empty ().<br />
<br />
=== Event type constants ===<br />
<br />
Next we're going to need to make sure the script will know what we're talking about when we make references to events. The tag that tells us the type of each event is actually represented internally by a number, but since it would be impossible for a programmer to keep track of all the different event numbers without making hard-to-find mistakes Dragon Age has instead used named constants to represent them in a more human-readable name.<br />
<br />
Those constants are defined in the script <code>events_h</code>. The "<code>_h</code>" suffix stands for "header", which is a special class of script that contains only various definitions meant to be included in other scripts and doesn't do anything on its own.<br />
<br />
To include the header file, add this line to the top of our script:<br />
<br />
<pre>#include "events_h"</pre><br />
<br />
All <code>#include</code> commands should be at the top of your script before anything else, but if there's more than one it shouldn't matter what order they are in.<br />
<br />
To see whether our script now knows what <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> means you can use the constant browser on the right edge of the script editor to check if it's listed. The browser defaults to showing a list of all defined functions (the "f()" button), to set it to show all defined constants click on the "C" button.<br />
<br />
[[Image:Scripting constant browser.png]]<br />
<br />
Even without any included files the list of defined constants is going to be quite long, and for scripts with many include files it can be very difficult to find any particular constant - especially if you aren't sure exactly what its name is. To find constants more easily, type any part of its name into the filter field at the top.<br />
<br />
[[Image:Scripting constant browser filtered.png]]<br />
<br />
To insert the constant into the script at the location where the cursor is currently located, simply double-click on the constant in the constant browser. This avoids any risk of making a typo. You can also type the beginning of the constant (or any function, etc.) and press Ctrl-Space to see a list of matching values.<br />
<br />
=== Extracting information about the current event ===<br />
<br />
When an event is sent to a script the script's <code>main</code> function will be run, but it won't know anything about the event that caused it to be run without some explicit instructions.<br />
<br />
First, you will need to retrieve the package of data that is the event. We'll define a variable named <code>ev</code> that will hold this package, and set it to the "<code>event</code>" data type. To retrieve the current event and stick it into that variable, we'll use the engine-defined function <code>[[GetCurrentEvent]]</code>.<br />
<br />
The first line of the main function will therefore be:<br />
<code>event ev = GetCurrentEvent();</code><br />
<br />
Every event will have an event type. As described above, this event type is represented internally by an integer. We'll create an integer variable named <code>nEventType</code> to hold it, and use the <code>GetEventType</code> function to extract it from <code>ev</code>. The next line will be:<br />
<br />
<code>int nEventType = [[GetEventType]](ev);</code><br />
<br />
The rest of the information packaged with the event depends on exactly what kind of event it is, so the rest of the code we write will be event-specific. To make sure only the correct code is run we'll use a <code>switch</code> statement. We're only looking for one particular event so we could just as easily have used an <code>if</code> statement but a <code>switch</code> is more extendable for future use.<br />
<br />
<pre><br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
//our event-specific code goes here<br />
break;<br />
}<br />
}<br />
</pre><br />
<br />
We know from the documentation for the <code>[[EVENT_TYPE_TEAM_DESTROYED]]</code> event, that it comes with a single piece of information; the team number. It's an integer, so we can extract it with the <code>[[GetEventInteger]]</code> function. <code>[[GetEventInteger]]</code> takes two parameters, the event object (which we've stored in the variable <code>ev</code>) and the index of the integer we want, in this case 0 (this is listed in the documentation).<br />
<br />
We also know that the team number we gave the hut monsters is 1, so we want to update the plot only when we receive an event indicating that team number 1 has been destroyed. We can do this with an <code>if</code> statement:<br />
<br />
<pre><br />
if (GetEventInteger(ev,0) == 1)<br />
{<br />
//code to update the plot here<br />
}<br />
</pre><br />
<br />
== Interacting with plots ==<br />
<br />
To interact with a plot's flags you'll need to have some way for the script to know where the plot flags are and what they're named. This is done in a similar manner to how we told the script what the event types were named; by including the plot file in the script.<br />
<br />
Plots are not the same as regular scripts, though, so when including them they are distinguished from regular scripts through the use of a <code>plt_</code> prefix in their name. The plot we wish to interact with is called <code>clear_the_hut</code>, so at the top of the script file you'll need to put the line:<br />
<br />
<code>#include "plt_clear_the_hut"</code><br />
<br />
Now your script will have access to the plot's flags and will be able to read or change them. You'll find that several new constants have been defined; <code>PLT_CLEAR_THE_HUT</code> contains the plot object, and the integer constants <code>MONSTERS_SLAIN</code>, <code>QUEST_ACCEPTED</code> and <code>REWARD_RECEIVED</code> identify the flags within the plot.<br />
<br />
Changing the state of the flags is done with the <code>WR_SetPlotFlag</code> function that is defined in the include file <code>wrappers_h</code> (<code>wrappers_h</code> contains a variety of utility functions that handle operations requiring low-level access to the game. Add <code>#include "wrappers_h"</code> to the top of your script). In our case, we want to set the plot flag <code>MONSTERS_SLAIN</code>. The <code>WR_SetPlotFlag</code> function takes three parameters; the plot identifier, the flag identifier, and the state we want to set it to:<br />
<br />
<pre><br />
WR_SetPlotFlag(PLT_CLEAR_THE_HUT, MONSTERS_SLAIN, TRUE);<br />
</pre><br />
<br />
== Associating an event script with an object ==<br />
<br />
The script is almost complete now, but until we've linked it up to some object in the game that can receive events it will never actually be run.<br />
<br />
Most objects in the game will have a field named "Script" shown in the object inspector. According to the documentation for the <code>EVENT_TYPE_TEAM_DESTROYED</code> event it is sent to the area object the team is in, so we'll want to open the hut_interior area now and go to its Script entry. The default event script for areas is <code>area_core</code>, which handles basic area events in a default way.<br />
<br />
This is where you'll want to put the <code>hut_monsters_slain</code> script. Click on the ellipsis ([[Image:ellipsis.png]]) button and select the new script. It will replace <code>area_core</code>, and now when there are events sent to this area our new script will be triggered and handle them.<br />
<br />
=== Passing execution to other event handlers ===<br />
<br />
There is just one problem remaining to be resolved now. As mentioned above, the <code>area_core</code> script normally handles a variety of events that are sent to areas. Now that we've replaced the default event handler with our custom script, and our script only responds to one specific event, there's nothing responding to the rest of the events coming into the area any more. Our custom script has preempted and therefore effectively disabled all the default area event processing by not responding to every possible area event.<br />
<br />
We don't want to re-implement all that default event handling in our own script, for a variety of reasons; it's a lot of work, we could make mistakes, and it would be difficult to update the default event handling across all of our areas in the future. Fortunately there's an easy way to tell Dragon Age to use another script to handle events; namely, the <code>[[HandleEvent]]</code> function. It takes two parameters, the event object to be handled and an identifier for the script that should handle it.<br />
<br />
A set of constants defining identifiers for the common default scripts is in the <code>global_objects_h</code> header file, but we won't need to include that because <code>wrappers_h</code> includes it already. So all we need to do is insert the following line after our switch statement:<br />
<br />
<pre><br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
</pre><br />
<br />
(The RESOURCE_SCRIPT_AREA_CORE constant is defined in global_objects_h, which we don't need to include explicitly in this case because it's already included in wrappers_h.)<br />
<br />
With this addition, whenever any event is sent to the hut_interior area, first our script will run and process the event, and then it will send it on to <code>area_core</code> to handle the default area processing normally done when no custom event handling script is being used.<br />
<br />
The final text of our script, then, is:<br />
<br />
<pre><br />
#include "events_h"<br />
#include "plt_clear_The_hut"<br />
#include "wrappers_h"<br />
<br />
void main()<br />
{ <br />
event ev = GetCurrentEvent();<br />
int nEventType = GetEventType(ev);<br />
<br />
switch(nEventType)<br />
{<br />
case EVENT_TYPE_TEAM_DESTROYED:<br />
{<br />
if(GetEventInteger(ev,0) == 1)<br />
{<br />
WR_SetPlotFlag("PLT_CLEAR_THE_HUT", MONSTERS_SLAIN, TRUE);<br />
}<br />
break;<br />
}<br />
}<br />
HandleEvent(ev, RESOURCE_SCRIPT_AREA_CORE);<br />
}<br />
</pre><br />
<br />
[[Category:Scripts]]<br />
[[Category:Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Level_Editor_Tutorial&diff=12508Level Editor Tutorial2010-03-10T17:07:23Z<p>TrueKeaton: /* Rendering Lightmaps */</p>
<hr />
<div>=Building your room (Interior Level)=<br />
How to create/lightmap a [[Level]] for use in an Interior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple room from scratch in 10 minutes or less<br />
<br />
This was lifted from a posting by St4rdog http://social.bioware.com/forum/1/topic/8/index/150840<br />
It needs some additional formatting love, but is as good starting place for people to create usable <br />
interior levels<br />
<br />
File > New > Level > Room Level<br />
<br />
* Click on "New Area" in top-left list > Object Inspector in bottom-right > Layout Name > anything under 8 characters no spaces or special characters (*,&,%, etc).<br />
<br />
*Right-click in 3D view and select Insert > New Room.<br />
*Click Models (blue box) in the Palette in the top-right. These folders contain everything such as floor tiles, walls, etc.<br />
*Enable Grid Snap with the magnet icon to make sure they line up.<br />
*The "prp" folder contains things like beds/barrels to clutter your Level.<br />
Hint: Use [[DATool]] (3rd party tool downloadable at http://social.bioware.com/project/41/ )to browse <br />
through these quickly to find the floors/walls you want.<br />
<br />
Note: If you get "Cannot spawn models into the selected parent object" when trying to place a model <br />
then you don't have "New Room" selected.<br />
<br />
<br />
==Working with multiple rooms==<br />
<br />
In general it is best to define each building room as a new room in the level. This becomes important when you work on lighting. To physically connect rooms you need to slide them together to get the doors to line up, they do not line up automatically. It takes some trial and error but becomes easier with practice.<br />
<br />
<br />
==Adding lights==<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light<br />
<br />
* Move it up off the floor a little. In Object Inspector > "Color Intensity" 2 or more > "Light Type" Point - Static (lc) > Choose any bright color.<br />
<br />
*Copy and paste. In Object Inspector >"Light Type" Ambient - Baked (this light stops your shadows being pitch black) > Choose a dark blue colour and keep the Color Intensity under 2/3.<br />
<br />
Note: I'm not sure what the mix of Baked/Static light is supposed to be. <br />
If you just put a Baked + Ambient it complains about not having Static, but if <br />
you put a Static + Ambient it seems to work fine, but the wiki says Static is <br />
the most expensive.<br />
<br />
==Rendering Lightmaps==<br />
<br />
*Press the Render Lightmaps icon (you need ActivePython 2.5 installed to default location). When it's done click the Display Lightmaps On/Off icon in the top-left to refresh the results.<br />
*Uncheck the "View Models Fully Lit" icon in the lop-left. You should see shadows from any objects you've dropped in.<br />
<br />
Note: Lightmap-atlas messages might appear the first time you render. That seems normal.<br />
Sometimes re-rendering the lightmaps messes them up badly when Display Lightmaps On/Off is on. It <br />
doesn't seem to use the latest lightmaps. Try pressing Display Lightmaps On/Off a few times to <br />
update it. If they're still messed up sometimes one of these fixes it (don't know which)<br />
unloading/reloading your Area or Level/changing your Area's layout property/posting your Level to <br />
Local.<br />
<br />
==Exporting==<br />
<br />
*Press the Do All Local Posts icon to the right of the lightmapping icons. It will export the name you typed into the "New Area" "Layout Name". If there's a complaint about walkable/player start then delete your old start then place a new one on a flat area.<br />
<br />
*Save your .lvl file. It's not used by the game and the name/location doesn't matter. Only the exported/posted files are used.<br />
<br />
<br />
<br />
==Using this in an Area==<br />
<br />
File > New > Area > Any Name<br />
<br />
*In the Object Inspector > Area Layout you should get a "..." box (make sure it's Checked Out) > click then select your "Layout Name" which should now be there.<br />
<br />
* Now you have a pretty lightmapped level inside an area.<br />
<br />
<br />
=Building your terrain (Exterior Level)=<br />
How to create/lightmap a [[Level]] for use in an Exterior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple terrain from scratch.<br />
<br />
File>New>Level<br />
<br />
* Choose Terrain (Landscape) Level and then click Next.<br />
<br />
* Accept the default values for the purpose of this tutorial and click Next and then click Finish. You can learn more about what the different terrain options do at the [[Level editor]] page.<br />
<br />
You should now see a flat, dark piece of terrain. To move around you hold down the mouse wheel. If you want to rotate the view press the Alt key while holding down the mouse wheel. You will want some light so you can see what you are doing, so we will generate a light source next.<br />
<br />
Tip: When choosing the size of your terrain level think about where you are going to put horizon and vista objects, like distant mountains and tree lines. You may need to allow for extra space around your adventure area to place those items.<br />
<br />
<br />
==Grid Size==<br />
<br />
If you want to work with a larger grid than the one provided by default you can change the grid size by going to: <br />
<br />
Tools/Options/Level Editor/Grid Square Size.<br />
<br />
This will not change the actual dimensions of the terrain level that you created, it only changes the size of the squares in the grid.<br />
<br />
==Define an area==<br />
<br />
Must be done before rendering the lightmap.<br />
<br />
* Click on the purple +-sign and click Define Area. Start in one corner and draw the green square to define the area that you will export.<br />
* Fill in the box Layout Name, max seven characters.<br />
* Fill in the box Name.<br />
<br />
==Lighting==<br />
<br />
* Right click on Terrain World to the upper left and choose Insert>New Light. This will spawn a light source in your area. Make sure you change the Light Type to Ambient - Baked (L). Be sure to click on the Render Lightmaps button if you want to see how your ambient light is working.<br />
<br />
Now that the terrain is lit we can modify it.<br />
<br />
<br />
==Modifying Terrain==<br />
<br />
The [[Terrain mesh]] tools allow you to modify the terrain by changing elevations, smoothing edges, flatting terrain, or painting textures.<br />
<br />
<br />
==Water==<br />
<br />
Please note that as of build 1.0.982.0 water is broken. You can see it in editor, but it is not making it into the game.<br />
<br />
First use the [[Terrain mesh]] tools to make a hole. It doesn't have to be deep. Then right-click on Terrain world and select Insert -> New Water Mesh. Double Click on the Water Mesh to zoom to it. By default it gets placed in a corner. Using the 3 Axis Movement tool [[File:moveTool.png]] grab the water and drag it to your hole. Depending on the size of the hole, you might have to adjust the water mesh size by changing the Size X and Size Y property values. Once you have the mesh placed, it's time to create the light probe. Right-click near the water mesh and select Insert -> New Light Probe. Using the move tool again, drag the light probe so that is roughly centered over the water mesh and slightly above it. Click on Render Lightmaps, then Render Light Probs. You might have to toggle Display Lightmaps, but you should now see your water looking like water and reflecting things around it.<br />
<br />
==Placing Models==<br />
<br />
* Click the blue box in the Palette Window to access the models that come with the game. The [[Model list]] shows pictures of many of the models available.<br />
<br />
* The [[Model]] page has more details on how to work with models.<br />
<br />
Tip 1: I had to change the Snap Options to make the models go where I wanted them. The settings I use were 0.10 for Snap to Grid and Snap Z Size. I also had to turn off Enable Snap to Surface whenever I wanted to change the vertical position of something (like creating the second floor of a building). Enable Snap to Surface is not applied globally, so once you turn it off and position an object vertically, turning it back on will not move that object unless you select it (or have it selected when you turn it back on).<br />
<br />
Tip 2: When placing premade cottages be aware that the door frames you can see attached to those buildings DO NOT have built in door hooks (see [[Area tutorial]] for information on placing doors). You can place a door frame model (for example, fhe_doorfrs_0) over the built in door frame to generate a door hook. The door frame model has to be placed from the Level Editor.<br />
<br />
<br />
==Adding Vegetation and Wind==<br />
<br />
The [[Vegetation]] page includes a list with pictures of the various plants available for placement. If you do not see the plants once you place them with the Scatter Object Tool then you may need to adjust your SpeedTree Rendering Distance Selector. This is a drop-down that you will see in the Tool Bar. It lists the distances at which plants will be visible. I set it to Very Far and left it there.<br />
<br />
Each level can have one active wind object in it. The location of the wind object doesn't matter. The wind object defines how wind behaves on this level, which is used for such things as flapping banners and swaying trees.<br />
<br />
Image:Level editor wind object.png <br />
<br />
The Wind Object may be found by right clicking on Terrain World and selecting:<br />
<br />
Insert>New Wind Object<br />
<br />
<br />
==Visual Effects (VFX)==<br />
<br />
Placeable visual effects like flames or smoke are considered to be art assets in the Dragon Age toolset, so you need to place them from within the Level Editor. <br />
<br />
The [[VFX Tutorial]] provides guidance on creating and placing visual effects.<br />
<br />
<br />
==Path finding and Obstructions==<br />
<br />
The path finding process lays down a grid of points that are marked "accessible" if they can be reached from a path finding start spot via passable terrain. This is essentially a flood-fill algorithm.<br />
<br />
You must create an [[Exportable area]] before you can generate any path finding data.<br />
<br />
* Click on the purple + in the tool bar ([[File:IconAddExportableArea.png]]). This will open an Area Properties window. The [[Level editor]] page has more details on this process, so I will just keep these steps very basic.<br />
* Name your Exportable Area in the Layout Name field of the Area Properties window. The name of an exportable area layout is limited to seven characters. BioWare uses the following naming system:<br />
** Three-letter prefix that describes the region or plot the layout is for. For example, "ost" for Ostagar and environs.<br />
** Three-digit number that uniquely identifies the layout within that region. Increments of one hundred are commonly used for major areas to allow sub-regions to be grouped together.<br />
** A single character identifying variants of the layout. For example, a "d" suffix for the "daytime" version of an exterior layout. "d" is also often used to mean "default", for areas where day and night are irrelevant (deep in a cave, for example).<br />
* Define your walkable area. Do this by clicking the Define Area button in the Area Properties window. The green box must include any areas that you want players to be able to walk. If you click in a corner of the level the green box will appear there. You can then expand it by dragging the corner.<br />
* Close the Area Properties window.<br />
<br />
In most cases you will want to block off certain areas of your terrain.<br />
* Turn on the Build Terrain Blocking tool. It is the middle mountain icon.<br />
* Using left-click to place and right-click to end chains/delete, place down blocks or 'walls' around areas you don't want the player to enter<br />
* Be sure to provide visual clues if it isn't obvious why the player can't walk there.<br />
<br />
Now that you have your exportable area you can generate path finding data.<br />
<br />
* Place a Starting Point in your level. I found that path finding does not work if you place the Starting Point before you have an Exportable Area. To place a Starting Point click on Setup Start Point in the tool bar.<br />
* Record the name of your Starting Point by clicking on it and looking at the name in the Object Inspector. Do not change the name - changing the name can prevent path finding from working.<br />
* Click Exportable Area Properties in the tool bar to open the Area Properties window. Put the Start Point name in the appropriate field and close the window.<br />
<br />
You should now be ready to generate pathfinding data by clicking on the Generate Pathfinding for Active Area button in the tool bar.<br />
<br />
==Converting Levels into Areas==<br />
<br />
Click on Do All Local Posts (you can avoid problems by generating a lightmap and pathfinding before doing local posts). This can be found in the menu at Tools>Export>Do All Local Posts<br />
<br />
Your level has now been converted and can be used to make an area. The [[Area tutorial]] will walk you through what to do next.<br />
<br />
<br />
<br />
[[Category: Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Level_Editor_Tutorial&diff=12507Level Editor Tutorial2010-03-10T17:07:06Z<p>TrueKeaton: /* Adding lights */</p>
<hr />
<div>=Building your room (Interior Level)=<br />
How to create/lightmap a [[Level]] for use in an Interior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple room from scratch in 10 minutes or less<br />
<br />
This was lifted from a posting by St4rdog http://social.bioware.com/forum/1/topic/8/index/150840<br />
It needs some additional formatting love, but is as good starting place for people to create usable <br />
interior levels<br />
<br />
File > New > Level > Room Level<br />
<br />
* Click on "New Area" in top-left list > Object Inspector in bottom-right > Layout Name > anything under 8 characters no spaces or special characters (*,&,%, etc).<br />
<br />
*Right-click in 3D view and select Insert > New Room.<br />
*Click Models (blue box) in the Palette in the top-right. These folders contain everything such as floor tiles, walls, etc.<br />
*Enable Grid Snap with the magnet icon to make sure they line up.<br />
*The "prp" folder contains things like beds/barrels to clutter your Level.<br />
Hint: Use [[DATool]] (3rd party tool downloadable at http://social.bioware.com/project/41/ )to browse <br />
through these quickly to find the floors/walls you want.<br />
<br />
Note: If you get "Cannot spawn models into the selected parent object" when trying to place a model <br />
then you don't have "New Room" selected.<br />
<br />
<br />
==Working with multiple rooms==<br />
<br />
In general it is best to define each building room as a new room in the level. This becomes important when you work on lighting. To physically connect rooms you need to slide them together to get the doors to line up, they do not line up automatically. It takes some trial and error but becomes easier with practice.<br />
<br />
<br />
==Adding lights==<br />
<br />
* Right-click on "New Room" in top-left list > Insert > New Light<br />
<br />
* Move it up off the floor a little. In Object Inspector > "Color Intensity" 2 or more > "Light Type" Point - Static (lc) > Choose any bright color.<br />
<br />
*Copy and paste. In Object Inspector >"Light Type" Ambient - Baked (this light stops your shadows being pitch black) > Choose a dark blue colour and keep the Color Intensity under 2/3.<br />
<br />
Note: I'm not sure what the mix of Baked/Static light is supposed to be. <br />
If you just put a Baked + Ambient it complains about not having Static, but if <br />
you put a Static + Ambient it seems to work fine, but the wiki says Static is <br />
the most expensive.<br />
<br />
==Rendering Lightmaps==<br />
<br />
*Press the Render Lightmaps icon (you need ActivePython 2.5 installed to default location). When it's done click the Display<br />
Lightmaps On/Off icon in the top-left to refresh the results.<br />
*Uncheck the "View Models Fully Lit" icon in the lop-left. You should see shadows from any objects you've dropped in.<br />
<br />
Note: Lightmap-atlas messages might appear the first time you render. That seems normal.<br />
Sometimes re-rendering the lightmaps messes them up badly when Display Lightmaps On/Off is on. It <br />
doesn't seem to use the latest lightmaps. Try pressing Display Lightmaps On/Off a few times to <br />
update it. If they're still messed up sometimes one of these fixes it (don't know which)<br />
unloading/reloading your Area or Level/changing your Area's layout property/posting your Level to <br />
Local.<br />
<br />
<br />
==Exporting==<br />
<br />
*Press the Do All Local Posts icon to the right of the lightmapping icons. It will export the name you typed into the "New Area" "Layout Name". If there's a complaint about walkable/player start then delete your old start then place a new one on a flat area.<br />
<br />
*Save your .lvl file. It's not used by the game and the name/location doesn't matter. Only the exported/posted files are used.<br />
<br />
<br />
<br />
==Using this in an Area==<br />
<br />
File > New > Area > Any Name<br />
<br />
*In the Object Inspector > Area Layout you should get a "..." box (make sure it's Checked Out) > click then select your "Layout Name" which should now be there.<br />
<br />
* Now you have a pretty lightmapped level inside an area.<br />
<br />
<br />
=Building your terrain (Exterior Level)=<br />
How to create/lightmap a [[Level]] for use in an Exterior [[Area]]:<br />
Objective: Following along with this tutorial, you should be able to create a simple terrain from scratch.<br />
<br />
File>New>Level<br />
<br />
* Choose Terrain (Landscape) Level and then click Next.<br />
<br />
* Accept the default values for the purpose of this tutorial and click Next and then click Finish. You can learn more about what the different terrain options do at the [[Level editor]] page.<br />
<br />
You should now see a flat, dark piece of terrain. To move around you hold down the mouse wheel. If you want to rotate the view press the Alt key while holding down the mouse wheel. You will want some light so you can see what you are doing, so we will generate a light source next.<br />
<br />
Tip: When choosing the size of your terrain level think about where you are going to put horizon and vista objects, like distant mountains and tree lines. You may need to allow for extra space around your adventure area to place those items.<br />
<br />
<br />
==Grid Size==<br />
<br />
If you want to work with a larger grid than the one provided by default you can change the grid size by going to: <br />
<br />
Tools/Options/Level Editor/Grid Square Size.<br />
<br />
This will not change the actual dimensions of the terrain level that you created, it only changes the size of the squares in the grid.<br />
<br />
==Define an area==<br />
<br />
Must be done before rendering the lightmap.<br />
<br />
* Click on the purple +-sign and click Define Area. Start in one corner and draw the green square to define the area that you will export.<br />
* Fill in the box Layout Name, max seven characters.<br />
* Fill in the box Name.<br />
<br />
==Lighting==<br />
<br />
* Right click on Terrain World to the upper left and choose Insert>New Light. This will spawn a light source in your area. Make sure you change the Light Type to Ambient - Baked (L). Be sure to click on the Render Lightmaps button if you want to see how your ambient light is working.<br />
<br />
Now that the terrain is lit we can modify it.<br />
<br />
<br />
==Modifying Terrain==<br />
<br />
The [[Terrain mesh]] tools allow you to modify the terrain by changing elevations, smoothing edges, flatting terrain, or painting textures.<br />
<br />
<br />
==Water==<br />
<br />
Please note that as of build 1.0.982.0 water is broken. You can see it in editor, but it is not making it into the game.<br />
<br />
First use the [[Terrain mesh]] tools to make a hole. It doesn't have to be deep. Then right-click on Terrain world and select Insert -> New Water Mesh. Double Click on the Water Mesh to zoom to it. By default it gets placed in a corner. Using the 3 Axis Movement tool [[File:moveTool.png]] grab the water and drag it to your hole. Depending on the size of the hole, you might have to adjust the water mesh size by changing the Size X and Size Y property values. Once you have the mesh placed, it's time to create the light probe. Right-click near the water mesh and select Insert -> New Light Probe. Using the move tool again, drag the light probe so that is roughly centered over the water mesh and slightly above it. Click on Render Lightmaps, then Render Light Probs. You might have to toggle Display Lightmaps, but you should now see your water looking like water and reflecting things around it.<br />
<br />
==Placing Models==<br />
<br />
* Click the blue box in the Palette Window to access the models that come with the game. The [[Model list]] shows pictures of many of the models available.<br />
<br />
* The [[Model]] page has more details on how to work with models.<br />
<br />
Tip 1: I had to change the Snap Options to make the models go where I wanted them. The settings I use were 0.10 for Snap to Grid and Snap Z Size. I also had to turn off Enable Snap to Surface whenever I wanted to change the vertical position of something (like creating the second floor of a building). Enable Snap to Surface is not applied globally, so once you turn it off and position an object vertically, turning it back on will not move that object unless you select it (or have it selected when you turn it back on).<br />
<br />
Tip 2: When placing premade cottages be aware that the door frames you can see attached to those buildings DO NOT have built in door hooks (see [[Area tutorial]] for information on placing doors). You can place a door frame model (for example, fhe_doorfrs_0) over the built in door frame to generate a door hook. The door frame model has to be placed from the Level Editor.<br />
<br />
<br />
==Adding Vegetation and Wind==<br />
<br />
The [[Vegetation]] page includes a list with pictures of the various plants available for placement. If you do not see the plants once you place them with the Scatter Object Tool then you may need to adjust your SpeedTree Rendering Distance Selector. This is a drop-down that you will see in the Tool Bar. It lists the distances at which plants will be visible. I set it to Very Far and left it there.<br />
<br />
Each level can have one active wind object in it. The location of the wind object doesn't matter. The wind object defines how wind behaves on this level, which is used for such things as flapping banners and swaying trees.<br />
<br />
Image:Level editor wind object.png <br />
<br />
The Wind Object may be found by right clicking on Terrain World and selecting:<br />
<br />
Insert>New Wind Object<br />
<br />
<br />
==Visual Effects (VFX)==<br />
<br />
Placeable visual effects like flames or smoke are considered to be art assets in the Dragon Age toolset, so you need to place them from within the Level Editor. <br />
<br />
The [[VFX Tutorial]] provides guidance on creating and placing visual effects.<br />
<br />
<br />
==Path finding and Obstructions==<br />
<br />
The path finding process lays down a grid of points that are marked "accessible" if they can be reached from a path finding start spot via passable terrain. This is essentially a flood-fill algorithm.<br />
<br />
You must create an [[Exportable area]] before you can generate any path finding data.<br />
<br />
* Click on the purple + in the tool bar ([[File:IconAddExportableArea.png]]). This will open an Area Properties window. The [[Level editor]] page has more details on this process, so I will just keep these steps very basic.<br />
* Name your Exportable Area in the Layout Name field of the Area Properties window. The name of an exportable area layout is limited to seven characters. BioWare uses the following naming system:<br />
** Three-letter prefix that describes the region or plot the layout is for. For example, "ost" for Ostagar and environs.<br />
** Three-digit number that uniquely identifies the layout within that region. Increments of one hundred are commonly used for major areas to allow sub-regions to be grouped together.<br />
** A single character identifying variants of the layout. For example, a "d" suffix for the "daytime" version of an exterior layout. "d" is also often used to mean "default", for areas where day and night are irrelevant (deep in a cave, for example).<br />
* Define your walkable area. Do this by clicking the Define Area button in the Area Properties window. The green box must include any areas that you want players to be able to walk. If you click in a corner of the level the green box will appear there. You can then expand it by dragging the corner.<br />
* Close the Area Properties window.<br />
<br />
In most cases you will want to block off certain areas of your terrain.<br />
* Turn on the Build Terrain Blocking tool. It is the middle mountain icon.<br />
* Using left-click to place and right-click to end chains/delete, place down blocks or 'walls' around areas you don't want the player to enter<br />
* Be sure to provide visual clues if it isn't obvious why the player can't walk there.<br />
<br />
Now that you have your exportable area you can generate path finding data.<br />
<br />
* Place a Starting Point in your level. I found that path finding does not work if you place the Starting Point before you have an Exportable Area. To place a Starting Point click on Setup Start Point in the tool bar.<br />
* Record the name of your Starting Point by clicking on it and looking at the name in the Object Inspector. Do not change the name - changing the name can prevent path finding from working.<br />
* Click Exportable Area Properties in the tool bar to open the Area Properties window. Put the Start Point name in the appropriate field and close the window.<br />
<br />
You should now be ready to generate pathfinding data by clicking on the Generate Pathfinding for Active Area button in the tool bar.<br />
<br />
==Converting Levels into Areas==<br />
<br />
Click on Do All Local Posts (you can avoid problems by generating a lightmap and pathfinding before doing local posts). This can be found in the menu at Tools>Export>Do All Local Posts<br />
<br />
Your level has now been converted and can be used to make an area. The [[Area tutorial]] will walk you through what to do next.<br />
<br />
<br />
<br />
[[Category: Tutorials]]</div>TrueKeatonhttp://www.datoolset.net/mw/index.php?title=Exporting_a_module&diff=12026Exporting a module2010-02-22T23:56:23Z<p>TrueKeaton: /* Overview */</p>
<hr />
<div>{{Infobox module}}<br />
For the Game to load a [[Module]] and any Resources of it, it has to get exported from the Toolset first.<br />
<br />
__TOC__<br />
== Overview ==<br />
<br />
<!-- Short explanation for noobies only --><br />
<!-- Definition --><br />
Exporting a [[Module]] is the process of exporting a single or all [[Designer Resources|Designer Resources]] from the Database. <br />
<br />
The toolset stores exported Resources as files in Folders that are unique to the Module a Resource belongs to, so that the Game which has no access to the Database can read them. Exporting is done 'per resource' on a single by single basis, however you can tell the toolset to export all at once, or a single resource with all dependend resources. Dependand Resources are those which are required for a Resource to work correctly, like a Vendor who sells a Sword is dependant on the Sword Resource. The Toolset will see the dependency automatically. <br />
<br />
[[Art Resources|Art Resources]] and [[2DA|2DA's]] are already present as files, which the creator has to put into into the respective Override Folder of the [[Module]] manually. {{undocumented}}<br />
<br />
<br />
All of the Resources can then be packaged into a [[Builder to player|"Builder to Player"]] package, once the [[Module]] is finished. This will collect all those ''loose'' files, and put it in a single downloadable file. Which is known as [[DAZIP|"DAZIP"]].<br />
<br />
== Exporting ==<br />
<br />
Exporting by single Resources is done to test single resources in game during development. During Export, the toolset extends the "Addins.xml" file, which enables the Module to be seen from the Games Menu. <br />
<br />
=== Export Capabilities ===<br />
<br />
*Export with dependent resources: This will export the currently selected resource, as well as any other resources that it depends upon. For instance, if you have created an area with a creature in it, this option will export the area, the creature, the creature's inventory, the scripts, etc. It would then grab any dependencies for the creature, inventory, or scripts and continue until it exhausted all of their dependencies. Doing this is a good way to make sure you get all of the needed pieces for any particular resource, but it can also quickly multiply to the point where it is picking up half of the module.<br />
<br />
*Export without dependent resource: This will only export the currently selected resource. This is a quick and efficient way to update your module when you have modified parts of a resource that only affect that resource.<br />
<br />
*Export all resources of type: This will export every resource of the same type as that which is currently selected in the palette. For instance, if you select a creature and choose this method, it will export all creatures in the module.<br />
<br />
*Full export: This option exports every resource associated with the module. It is the most comprehensive, and takes the longest to run.<br />
<br />
{| align=right<br />
|-<br />
|[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_6cd0bb27.png|400px]]<br />
|-<br />
|[[Image:DA_Audio_Design_Documentation_Ambience_Content_html_6e39c036.png|300px]]<br />
|}<br />
=== Testing an Area by overriding the starting area ===<br />
<br />
Area Resources can be tested in a very convinient way. If you just want to give it a test run you can override the module's start area on an export-by-export basis.<br />
<br />
#Save the Area you are working on<br />
#Navigate Tools/Export/Export Options<br />
#Activate "Override campaign export settings"<br />
#Choose the Area, and a Waypoint with it<br />
#Export the Area with or without dependand resources as needed<br />
<br />
Once the export has completed you should be able to start a "New Game" (if editing the main campaign) or select your module under "Other Campaigns" (for stand-alone content). You should start in the level that you have exported at the waypoint that you have set as your starting point. You need to have an custom module setup as Standalone, see above.<br />
<br />
== Creating a downloadable Package ==<br />
<br />
All of the Resources which are exported are only ''loose'' files in your Filesystem. However to create downloadable and installable packages the toolset is capable of creating so called [[Builder to player]] packages, to create [[DAZIP|"DAZIP"]] installable Filetype.<br />
<br />
:''See Article: [[Builder to player]]''<br />
<br />
== Exporting resources to other Modders ==<br />
<br />
Normally the whole process will convert Resources into Gamereadable formats. Which excludes being able to edit them further with the Toolset. The source is however stored in the cloggy Database. [[Builder to builder]] is the mechanisms used by the toolset that allow packages of game resources to be shared between multiple collaborating builders.<br />
<br />
:''See Article: [[Builder to builder]]''<br />
<br />
[[Category:Modules]]</div>TrueKeaton