Dragon Age Toolset Wiki - User contributions [en]

Sound and music

2011-09-28T04:03:45Z

Obadiah: /* Character soundsets */

Sound in Dragon Age is packaged using a program called [[FMOD]]. FMOD sound banks include the audio waveform itself, and can also include settings determining how the sound is played.

== Voice-over ==

Voice over doesn't actually require you to work with FMOD, as the tools to package VO into FMOD sound banks are built into the toolset.

Placeholder [[Voice-Over]] can be generated automatically by the toolset (using the default Microsoft text-to-speech engine that comes with your OS). This is intended as a way to easily produce a "rough cut" of a cinematic, giving an approximate feel for how long the line will last and allowing [[FaceFX]] to be generated.

Recording real [[Voice-Over]] for [[conversation]]s is straightforward, though you'll need to keep track of the string IDs of the lines you're recording in order to give the wav files the proper filenames.

== Placeable sound resources ==

Other types of sound resources will require work with [[FMOD]] itself to get them into the game. See [[FMOD]] for details.

Sound events are placed in an [[area]] layout using the area editor. Details such as how the sound loops, where the sound is simulated as coming from, and so forth, are defined in [[FMOD]].

Areas can also have [[audio volume]]s, [[music volume]]s and [[reverb volume]]s defined, with associated sound events.

== Adding sounds to animations ==

The [[Blend tree editor]] allows sound events to be associated with an animation's timeline. So for example, an animation of a golem clapping could have a clanging sound added to the moment of impact of its hands.

== Character soundsets ==

Soundsets for characters (the collection of lines they choose from in combat and other routine in-game activities) are created as [[conversation]] resources, and are associated with individual creatures via a [[character]] resource. This allows one soundset to be reused for multiple different creatures. New soundsets can be created from templates listed in /_Core Soundsets/.

Sound and music

2011-09-28T04:03:11Z

Obadiah: /* Character soundsets */

UI Tutorial (draft)

2011-07-14T01:35:51Z

Obadiah: /* Getting Information From The Engine */

'''Author's note''': STILL A WORK IN PROGRESS - FIRST DUMPING INFORMATION OUT, THEN I'LL FORMAT AND SECTION IT OFF BETTER. This isn't a very good tutorial, but as I said, I'm just trying to get the information out there and I'm slow to update this. Also, it may be simpler now that the UDK has support for GFX files, but I don't know the cross-licensing or technical situation on that right now.

== Introduction ==

The UI files are basically just version 8 Adobe Flash files, but extended with some extra properties and image handling (they even use nonstandard tags in the SWF for that). GFX files supposedly have more optimized fonts and who really knows what else, but you shouldn't have to worry about font embedding in Dragon Age.

This means they use the older ActionScript 2.0, which you can find some learning resources on here [http://download.macromedia.com/pub/documentation/en/flash/fl8/fl8_learning_as2.pdf fl8_learning_as2.pdf] and here [http://livedocs.adobe.com/flash/9.0/main/flash_as2_learning.pdf flash_as2_learning.pdf], among other places scattered on the web. You can download the API reference, but a decent online location is [http://flash-reference.icod.de/ here] (faster than Adobe's site I find).

For it to work in game, the U.I. element must be saved using the name of an existing U.I. file, as the engine will only run U.I. elements it is expecting. You can, however, leave the file extension as .swf and it will still run.

=== Other information sources ===
There's a woefully incomplete GUI category on the wiki here [[:Category:GUI]]. It was an early effort at detailing some of the class specifics in the UI files. There are a lot of stubs, but some classes are more detailed.

There's also a long-standing draft article on the profile page here [[User:FollowTheGourd]] about the conversation UI. It could also be ammended to explain things like 800x600 is treated as if it were 1024x768, and that the cutscene bars actually have a negative height if the screen width is much longer than the screen height, as seen with Eyefinity display setups.

Another thing to realize is the game's aspect ratio correction and how one resolution in window mode will get stretched to fill your screen space in fullscreen mode. So then there's a difference between the Stage (Flash term) width and height and the video settings which you can access using the ExternalCommands ActionScript class. The point is that the Stage dimensions are more reliable than the video settings you can retrieve through the ExternalCommands class, although it doesn't stop the quickbar UI file from reading the attribute ''"ClientOptions.VideoOptions.ResolutionWidth"'' from it, but there might be a perfectly good reason for that like the engine notifying the GUI when it changes.

== Toolchain ==

[http://www.flashdevelop.org/ FlashDevelop IDE.]
etc

== Organizing Sources ==

Obtain an ActionScript 2.0 decompiler such as Sothink or Trillix. Each has their shortcomings and will require further post-processing. Sothink's ActionScript output will probably require more work to make compile with MTASC, but Trillix's output seems to have some stranger bugs I'll mention later, which makes me more hesitant to recommend it. Sothink's tool still seems to have an issue formatting double-precision values as single-precision, as detailed in the section below. [http://www.nowrap.de/flare.html Flare] is also a nice free tool to compare output against, but it unfortunately isn't in a format that you can simply recompile.

[http://www.nowrap.de/flasm.html Flasm] is also a useful tool if you wish to examine the p-code directly (as a debug or learning aid perhaps), or even modify it that way.

=== GFX to SWF ===

If you want your changes to be compatible with a certain or the latest game patch, then you'll also have to first merge the appropriate [[GFX]] files. For example, to be compatible with game v1.03, you'll first need to extract the GFX files from guiexport.erf, and then from the patch000.erf, patch001.erf, and patch002.erf files found under C:\Program Files\Dragon Age\packages\core\patch. If you want to be compatible with v1.02a, then it should suffice to stop merging after patch001.erf.

Then you want to change the first three bytes for the GFX to CWS and change the file suffix to SWF.
Example Python script:
<dascript>
from __future__ import with_statement
# The first line is required if you get the following error when running the python script under 2.5.4/2.5.5
# SyntaxError: invalid syntax - with open(gfxPath, "rb+") as gfxFile:
import glob
import os
import struct

for gfxPath in glob.glob('*.gfx'):
with open(gfxPath, "rb+") as gfxFile:
print(gfxPath)
gfxFile.write(struct.pack('3s', "CWS"))
os.rename(gfxPath, os.path.splitext(gfxPath)[0] + ".swf")

line = input("Press enter to exit.")
</dascript>

=== Obtain ActionScript Sources ===

If you're using Sothink's tool, then here's an example of how you would quickly retrieve the ActionScript, if you've converted the GFX into SWFs as mentioned above. Do a multi-file export with all of the SWF files (merged to whichever patch version you wish). [http://i1002.photobucket.com/albums/af150/FollowTheGourd/sothink_swf.jpg Screen shot]

=== Merge ActionScript Classes ===

It's a good idea to create a single ActionScript library of all the game sources; that way you don't have to repeatedly make the same modifications for every SWF file that uses the same modified classes. As you'll see later when using the SWF injection method, that this doesn't make available all of the classes to every SWF file, but it's a way to avoid redundant editing.

For instance, here's a embarrassingly quick and dirty way of doing it with a Python script:
''Note:'' this will throw an exception on later versions of Python because shutil.move undocumentedly doesn't want to clobber existing files. You could add a check if the file already exists and not move it - or rewrite the script and make something better.
<dascript>
from __future__ import with_statement
# The first line is required if you get the following error when running the python script under 2.5.4/2.5.5
# SyntaxError: invalid syntax - with open(gfxPath, "rb+") as gfxFile:
# [Yes, this code probably sucks]

import shutil
import os
import re
import zlib

# Usage: have the batch exported ActionScript from the decompiler (say Sothink) in a dir called export. Then run this
# script at the same level as the export dir. It will create a C:\commonlib folder with the ActionScript merged into it.
# Left over in export is what you can import into a FlashDevelop project. You'll also want to make
# intrinsics out of export and commonlib, but commlib goes in the global classpath, while
# the appropriate export subfolder goes in the appropriate project classpath.

mergedir = r'C:\commonlib'
scriptdict = {}
for dirpath, dirnames, filenames in os.walk('export'):
print(dirpath)
for junk in filter (lambda x: not x.endswith(".as"), filenames):
os.remove(os.path.join(dirpath, junk))
for script in filter( lambda x : x.endswith(".as"), filenames):
scriptfile = open(os.path.join(dirpath, script))
relativedir = re.sub(r'export\\[^\\]+\\?', '', dirpath)
relativepath = os.path.join(relativedir, script)
crc32 = zlib.crc32(scriptfile.read())
scriptfile.close()
sourcepath = os.path.join(dirpath, script)
if relativepath in scriptdict:
lastval = scriptdict[relativepath]
if lastval['crc32'] == crc32:
destdir = os.path.join(mergedir, relativedir)
if os.path.exists(lastval['sourcepath']):
os.remove(lastval['sourcepath'])
if not os.path.exists(destdir):
os.makedirs(destdir)
#print("move " + sourcepath + " to " + destdir)
shutil.move(sourcepath, destdir)
else:
# There any many *Scene.as files that are the same
# BUT there's an "emptyish" Scene.as used an as interface as well.
# So you probably want Scene.as as common, but the other scenes as unique
# even if they have the same name. Still throw if script is Scene.as but not if it ends with it.
if not re.search(r'.Scene\.as$', script):
raise Exception("Same name, different CRC32: " + sourcepath)
else:
scriptdict[relativepath] = { 'crc32': crc32, 'sourcepath': sourcepath }

# Find unique entries in SharedLibary, GUI, etc. Copy them over to commonlib but print out what we found.
# [Bit of a copy-pasta job here...]
for dirpath, dirnames, filenames in os.walk('export'):
for script in filter (lambda x: x.endswith(".as"), filenames):
relativedir = re.sub(r'export\\[^\\]+\\?', '', dirpath)
if relativedir == '':
continue
relativepath = os.path.join(relativedir, script)
sourcepath = os.path.join(dirpath, script)
destdir = os.path.join(mergedir, relativedir)
if not os.path.exists(destdir):
os.makedirs(destdir)
print("Unique commonlib: " + sourcepath)
shutil.move(sourcepath, destdir)

# Clean up empty dirs
for dirpath, dirnames, filenames in os.walk('export', topdown=False):
for d in dirnames:
try:
os.rmdir(os.path.join(dirpath, d))
except OSError:
pass
</dascript>

== Making Modifications ==
=== Bugs and getting sources to compile ===
[ Note: this is mostly just copy and pasted from my post in another forum at the moment. It still needs some reworking to better explain things ]

You can first get the open source FlashDevelop IDE which comes with MTASC and the standard Flash library. If you have the SWFs and the ActionScript *.as files, then what you can do is create an empty ActionScript 2 project, in the project settings turn off "use main entry point" and under the project "injection" tab, point it to the SWF you want to update with your new ActionScript.

You'll also want to update the project classpaths to point to your game's ActionScript library. Just in my experience, there seem to be some properties on some of the standard classes that would normally prevent the script from compiling - but in that case what you can do is modify the so-called intrinsic files to let the compiler know about them. E.g., you can add needed function and var declarations to the intrinsic class interfaces under C:\Program Files\FlashDevelop\Tools\mtasc. The nice thing about ActionScript and intrinsics is that (unless used as a case value in a switch-statement) you don't even need to know the values of these "missing" properties or functions if they're basically defined in the runtime environment. E.g., Mouse.LEFT isn't standard Flash, but if you edit Mouse.as and add '''static var LEFT;''' to the intrinsic class definition, then you're good to go, as the value gets looked up during execution like a dictionary value (in fact, Mouse["LEFT"] should yield the same result).

Also if you press Ctrl+J you'll get the type explorer where you can right click on a folder (that you've added to your classpath) and select "convert to intrinsic". So this way you only need to compile the actual *.as file you're making changes to and keep the others around as intrinsics. Using the IDE's SWF injection I mentioned above will make it so you don't have to worry about recompiling everything.

You'll probably get a bunch of warnings like "... needs the class <Whatever> which was not compiled" but that's just MTASC not liking how some class names are used outside of what you're compiling like in Flash registerObject calls.

Now the bigger issue is that MTASC is pickier about things than Adobe's compiler. You'll often have to write this.varname or ClassName.varname instead of just varname, and MTASC doesn't like named *nested* functions. So you'll sometimes have to convert function FooBar() { ... } into something like "this.FooBar = function() { };" or "_root.FooBar = function() { };". But also make sure that the variable for the function is a class member and not function-local or it'll just be a register or randomly named variable when compiled, or just not be available in the scope you need it to be.

MTASC is also pickier about the scope of local variables. It may sound weird, but in ActionScript 2.0 a function-local variable is defined for the scope of the function - it doesn't matter if declared in an if-statement or in braces. But the MTASC compiler will enforce that you define the variable in a "proper" scope, so you may need to move where it's declared if you want things to compile. E.g., "if (foo) { var tmp = 1; } else { tmp = 2; }" won't fly with MTASC.

Also it seems like MTASC doesn't like the global function "Array", but doesn't mind if you use the constructor instead. E.g., I've had issues with var ar = Array(...), but var ar = new Array(...) works or you could use the square-bracket notation instead.

Some other stuff... if you want multiple projects, just create the projects all in the same dir (but create folders if you want to separate stuff and adjust the project classpath accordingly).
Also, don't necessarily set "Always compile" for the *.as file or you might run into duplicate definition errors - things should get drawn in as needed, but I think you need to set it for classes in the original SWF you wish to update. That might be a little hit and miss at first, but you can always check to make sure your changes got in.

Also, looking at the output in FLASM, MTASC might not generate the most blazing bytecode ever - but neither does Adobe's compiler. Just some things I noticed is that Adobe's will use function argument registers more than MTASC seems to... e.g., "push '_root'; getVariable" vs just a r:_root register.

Another apparent annoyance with MTASC is that it doesn't seem to recognize some global variables (which you can confirm with flasm's output (push 'somevar'; getVariable). Workarounds include ''_global.someVariable'', or sometimes ''_root.someVariable'' as appropriate.

One last thing... you may want to organize your *.as files so you combine the ones that are commonly used across different SWF files so you're not always having to edit multiple copies of SomeClass.as for each SWF that uses it.

Also, I noticed a bug in sothink that I emailed them about: doubles are formatted as single-precision floating point. But some other tools, e.g., flare, get the value correctly. You might want to search your *.as files for "E-" and "E+" to look for these misformatted values if you're using it.

EDIT: Here's a bug with Trillix I noticed, but they said it'll be fixed soon: if you have "var foo = this" and if a register is used for 'foo', then Trillix doesn't properly initialize the register... but instead just uses 'this' everywhere else. This causes problems if you needed that variable to choose between using 'this' and possibly another object. E.g., "var obj = this; if (something) { obj = someOtherObject; } someFunc.doIt(obj);" only works as long as "obj" is stored as a variable and not a register, which is up to the original compiler. In reply, they mentioned that you could work around that issue by turning off the "ActionScript 'Recover arguments' names" setting, which makes it a bit more difficult to keep track of function arguments, so it's less than ideal.

=== Getting Information From The Engine ===
It is possible to get information from the engine using the ExternalCommands class. More on this class can be found at [[ActionScript:ExternalCommands|External Commands]]. Of particular interest is [[ActionScript:ExternalCommands.GetValue|GetValue]]

=== Issues displaying custom MovieClip subclasses ===
'''Note:''' this tries to explain some of the issues, and isn't suggesting best practices. This is a bit rambling and should be presented with more concrete examples. Ideally it wouldn't be needed at all and we could use the Scaleform SDK to convert our SWFs into GFX, or we could splice in our own movieclip symbol tags into the GFX file.

The simple issue is this: if it wasn't originally created in the Flash designer (also having a symbol in the Flash library), then you'll have a harder time of showing custom MovieClip objects through ActionScript alone. This would appear to be a bug, but speculatively, it could be for performance reasons.

==== Using swfmill ====
This hasn't been thoroughly tested, but swfmill may be a simple way to add you own symbols. Use swfmill to convert the SWF into an XML file, edit it, and then use swfmill to convert it back. It appears to work, and even properly retains the non-standard SWF tags. For custom class behavior, you'll still need to make an ''Object.registerClass'' call to associate the library symbol with the class. If you do use this method, one thing to make sure of is that the embedded textures display properly, since they're being referred to using a non-standard SWF tag.

==== createEmptyMovieClip method ====
So until splicing in tags becomes more streamlined, or some other method is found, then it may be easier to just create an empty movieclip and then populate the member fields using a mixin from another class or manually, although that's probably still less than ideal for classes that use the onLoad event. Another thing as mentioned below is the possibility of abusing prototype mechanics (which can be somewhat messy) or subclass an existing class to specialize the beha

It would appear that the ''MovieClip'' method ''createEmptyMovieClip'' is of limited use unless you then load another movieclip (such as an icon image) into it or or do a ''beginFill ... endFill'' ('''fill-code''') for a few frames to define its dimensions, filling it for as many frames until, say, its '''_height''' property becomes non-zero. It's ugly, but works. Also, if you do a fill on an object in the library, then you actually affect its '''_xscale''' and '''_yscale''' by making the object stretch to fit into your fill. Ultimately, it'd probably be less of a hassle to alter the SWF file to insert your object. Because of having to rerun the code, you'll probably want to delay having to reload images or other intensive operations. You'll have to rerun the fill-code at least twice for this to work, timing alone doesn't matter as has been determined through trial and error.

==== attachMovie method ====
Perhaps a simpler way is to use ''attachMovie'', although you'll have to find a pre-existing movieclip symbol that suites your needs, and if you want to change its default dimensions then you'll have to delay the fill-code for a few (let's say 150 or so since the scene began) frames after the game loads until it actually works. '''NOTE:''' Reconfirm this is actually necessary instead of just being able to set the _height/_width/_xscale/_yscale, although you may still need to delay setting those for the change to take effect. This way you shouldn't have to keep rerunning the fill-code as with the above ''createEmptyMovieClip'' method. This whole delay business is probably more of an issue in UI elements that are on the HUD instead of selected later from the navbar. You can probably check for when you've waited enough frames by running some simple fill-code on an empty movieclip and checking whether the '''_height''' property changes.
E.g., the PieCooldown symbol exists in the quickbar.swf file and isn't the worst choice for an empty MovieClip. You can use programs like swix, swfmill, and probably others to find simple objects without much embedded graphics.
<dascript>
private static var EMPTYMC_LINKID:String = "PieCooldown";
var mc:MovieClip = someClip_mc.attachMovie(EMPTYMC_LINKID, "SomeName_mc", someClip_mc.getNextHighestDepth(), {_x:10, _y:10});

// Changing the default dimensions of "PieCooldown"
// Although you can probably just change the _height, _width or scales after the
// needed delay instead, unlike with the createEmptyMovieClip method apparently.
// Also not really necessary if you just want to use it as an invisible container,
// since other items can be positioned outside of it, relative to its local
// coordinates.
with(mc)
{
beginFill(0, 0); // alpha is zero.
moveTo(0, 0);
lineTo(21, 0);
lineTo(21, 21);
lineTo(0, 21);
endFill();
}
</dascript>

The game's script sources also come with a ''MovieUtils'' class, which has a wrapper around ''attachMovie''. This can be useful to create an instance of a library symbol in the SWF file and use it instead for another purpose.

Other useful workaround would be abusing prototype mechanics of ActionScript to give an already existing class other behavior if desired, and can be switched using a custom argument for the initObject during the attachMovie call. This way you don't have to edit the actual class file, if making it recompile is problematic or time consuming. Although this is a kludge method of doing it.

Also of note is that ''Object.registerClass'' or the so-called [http://www.google.com/search?hl=en&source=hp&q=attachMovie+__packages+trick __Packages trick] won't really get you anywhere either. You'll be able to create the MovieClip subclass, but it won't display properly (or just differently) without the above-mentioned tricks.

Creating a subclass of an existing class that's registered with ''Object.registerClass'' may also be a convenient way to customize class behavior without having to recompile the base class if you then change the registerClass call to use the subclass.

Follower tutorial

2011-07-13T16:16:47Z

Obadiah: /* Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event */

== Simple Follower Creation ==

Follow these steps to create a follower that

- Levels up with a default package

- Can be chosen from the party picker

- Can gain XP

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

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

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.

=== Create the creature ===

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

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

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

[[File:class.jpg]]

Under Package/Scaling set:

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

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

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

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

[[File:package.jpg]]

Save and export your character as normal.

=== Overlay char_stage ===

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.

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.

[[File:area_palette.jpg]]

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

[[File:char_stage.jpg]]

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

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

Save and export the area.

Add the following to your module event script:
<dascript>
case EVENT_TYPE_MODULE_GETCHARSTAGE:
{
// Overlay the existing stage with my stage
// "my_char_stage" is the resource name of the overlay area
// "partypicker" is the name of the default GDA
SetPartyPickerStage("my_char_stage", "partypicker");
break;
}
</dascript>

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

You will need to create two Excel spreadsheets.

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

Set up your columns as follows:

[[File:partypickerm2da.jpg]]

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

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

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

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

'''NOTE - ON SELECTION ANIMATIONS'''

Add Animation and Remove Animation are actually Id numbers of different animations, taken from anim_base.gda

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.
Here are some examples you can use:

819 - talk cursing

629 - reading a book (doesn't work, since it probably requires a book object)

844 - hands behind back (848 and 849 are Enter and Exit versions respectfully)

850 - chest pounding salute

811 - fist pounding

277 - dance

247 - cast area spell

500 - vfx cast

600 - surprised

603 - praying

607 - head bow

609 - standing at attention

651,652 - crouch pray (Enter and exit)

808 - point forward

825 - nodding

840 - hand chop or frustration

905,906 - crouch (Enter, Exit)

919,920 - sit on ground (enter, exit)

965 - kneel down loop

972 - wipe nose

976,977 - squat (Enter, Exit)

986 - wipe eyes

998,999 - hands clasped (Enter, exit)

3029 - inspect nails

3031,3032 - playful (enter, exit)

3054,3056 - slouch (enter, exit)
255 - in-place fly

'''NOTE - ON SELECTION VFX'''

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

Some examples:

ID --- BLENDTREENAME --- EFFECT

6039 --- fxm_energy_up_p --- Lady of the Forest pillar of light

6040 --- fxm_power_in_p --- Branka - power in

3054 --- fxc_lotf_c --- Lady of the Forest - swirling leaves

3009 --- fxc_succubus_c --- Succubus crust

1549 --- fxa_hly_imp_c --- Holy Impact crust

1076 --- fxa_spi_aur_mht_c --- Spirit - Aura Might crust

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

Set up your columns and data like so:

[[File:party_pickerm2da.jpg]]

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

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

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

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

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

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

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

=== Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event ===

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

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

If you're not sure how to set a module script, go to '''File''' then '''Manage Modules,''' select your module and click '''Properties.'''

<dascript>
#include "utility_h"

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); //Allows the follower to gain XP
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); //Adds follower to the active party
break;
}

}
}
</dascript>

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

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

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

Remember to save and export your module script.

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:

[[File:module_script.jpg]]

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

=== Create Your Hiring Script ===

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

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

<dascript>
#include "utility_h"

void main() {

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

UT_HireFollower(oFollower); //Hires the follower

SetPartyPickerGUIStatus(2);

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

}
</dascript>

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

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

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:

[[File:hire_conv.jpg]]

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.

If everything worked, you should see something like this:

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

== Advanced Follower Creation ==

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

- Unique level-up template

- Class and specialisation chosen via script

- Any starting state

- Level higher than the PC

- Starts with a specialisation point rather than a specific specialisation

- Set plot flags in the call to the hire script

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

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

=== Create Party Plot ===

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

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

[[File:follower_plot.jpg]]

See FAQ for an alternative approach to plots when there are more than three potential party members.

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

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

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

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

AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.

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

break;
}

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

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

}

}
}
</dascript>

=== Create a Level Up Template ===

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

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

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

It should look something like this:

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

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

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

We will edit the remaining columns like so:

==== Setting Stat Weights ====

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

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

[[File:miera_stat_weights.jpg]]

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

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

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.

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

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

'''Columns H''' and '''I''' are the skills that the character will buy, in preference order from top to bottom.

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

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

[[File:AlMori_talent_pref.jpg]]

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

[[File:ALMori_copy.jpg]]

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

[[File:ALMori_paste.jpg]]

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

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

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

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

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

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

[[File:m2da_base_fofbc.jpg]]

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

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

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

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

FOR AUTOLEVEL TO WORK AFTER RECRUITING:

Look in packages.xls.
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.
(alternatively, you could try packages_base.gda)

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

This section is probably only relevent if you have a specific need to override the functionality of player_core.

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

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

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

Paste in the following script:

<dascript>
#include "sys_chargen_h"
#include "wrappers_h"
#include "utility_h"
#include "sys_rewards_h"
#include "approval_h"
#include "sys_autolevelup_h"

/* Jye Nicolson 5-Jan-2010
This function set duplicates the full functionality chain of UT_HireFollower, with the following exceptions:

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

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

Calling the function:

Simple:

hireCustomFollower(oFollower, CLASS_WARRIOR);

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

Best Practice:

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

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

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

Full argument list:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

)
*/
/* GetCustomFollowerALTable()
This function is where you put your custom table assignments.

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

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

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

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

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

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

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

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

return nTable;
}

// This just cleans up the main function a little

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

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

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

return nTargetLevel;

}

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

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

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

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

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

/* InitCustomFollowerSpec:

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

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

*/

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

if (nForceSpec == 0) {

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

} else {

AddAbility(oFollower, nForceSpec);

}
}

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

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

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

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

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

object oHero = GetHero();

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

This loosely replicates WR_SetFollowerState.

*/

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

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

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

/* ################# BEGIN PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION #################
This replicates the EVENT_TYPE_PARTY_MEMBER_HIRED handler from player_core, stripped down for simplicity and allowing our custom options.

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// load tactics
InitCustomFollowerTactics(oFollower, nPackage);

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

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

//Set plot flags

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

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

// Invoke picker if requested.

if (bInvokePicker) {
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();
}
}
</dascript>

Yeah, I know. It can't really be any smaller. Feel free to modify it if you're confident with scripting.
==== Add Your Custom Autolevel Template to GetCustomFollowerALTable() ====
While you can pass the ID you made for your autolevel template to that monster function as an argument, it's better to have them all in one place if you have multiple followers.

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

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

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

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

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

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

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

return nTable;

}
</dascript>

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

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

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

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

Take a look at the following example:

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

void main() {

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

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

//Simplest hire call - adds to the party as a wizard. Class is currently compulsory due to a bug.
hireCustomFollower(oMiera, CLASS_WIZARD);

//Add to the party and set joining plot flags
hireCustomFollower(oJysavin, CLASS_WARRIOR, PLT_BC_CREATE_PARTY, PARTY_JYSAVIN_JOINED);

//Add to the party, set plot flags, force a specialisation
hireCustomFollower(oBraghon, CLASS_ROGUE, PLT_BC_CREATE_PARTY, PARTY_BRAGHON_JOINED, ABILITY_TALENT_HIDDEN_ASSASSIN);

//More complex example - Follower added as a unique class (Dog), not granted a specialisation or spec point.
//Note unique classes must have an ALTable passed here or specified in GetCustomFollowerALTable() or they won't work
hireCustomFollower(oSpider, CLASS_DOG, PLT_BC_CREATE_PARTY, PARTY_GELDUAL_JOINED, 0, 0, FALSE, FOLLOWER_STATE_AVAILABLE, "", 0, 0, FALSE);

//Show the party picker to let the player choose from their new companions!
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();
}
</dascript>

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

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

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

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

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

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

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

== Common Follower Problems & FAQ ==

====Why don't my followers gain XP?====
There is a bug in UT_HireFollower. Make a copy of UT_HireFollower in a function of your own, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);

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

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

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

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

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

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

====Dog talents and equipment slots don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots. Equipment slots are for humans, not dogs.

Line 78 of packages_base in packages.xls (Dog) should have the LevelUpTable column set to 257 which is the ALDog table.

The EquipmentLayout 2DA needs a new entry for the follower:

ID=same as partypicker 2DA
Tag=follower tag
AvailableEquipmentSlots=794624
Layout=2
EnableWeaponSets=0

If the creature is not using the appearance "Dog, Party Member", it needs a new appearance line in APR_base. Most of the entries can be copied from the standard appearance (e.g. Wolf), but

MaxScaleLevel=-1
DefaultArmor=
AppearanceRestrictionGroup=1

Otherwise, it won't be able to progress beyond a specified level. The player will receive an unwanted set of armour when the it is hired, and it won't be able to use Marabi crunch items. You may also need to tweak PERSPACE and/or BumpLevel if excessive clipping occurs.

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

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

The next section answers this question, up to a point.

==== What if there are more than three potential followers? ====
This example handles larger numbers of followers, and doesn't force the player to use the party picker unless the party is already full.

The prefix zzz, used throughout, can be replaced with whatever [[Prefixes_in_use | prefix]] you are using for your resources.

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.
<pre>
// Party member id (e.g. 1=Alicia, 2=Godwin...)
int zzzPartyMemberID(object oPartyMember)
{
string sPartyMember = GetTag(oPartyMember);

if (sPartyMember == "zzzcr_alicia") return 1;
if (sPartyMember == "zzzcr_godwin") return 2;
if (sPartyMember == "zzzcr_harold") return 3;
if (sPartyMember == "zzzcr_lara" ) return 4;
return 0;
}
</pre>

Make two separate plots, e.g. zzzpt_hired for when a follower is first recruited, and zzzpt_party to flag whether they're currently in the party. Use flag values that correspond to the unique follower id, e.g. ZZZPT_HIRED_GODWIN will be 2.

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.

Follower conversation is now very simple. In Godwin's dialogue, the hiring line will be conditional - when ZZZPT_HIRED_GODWIN is clear - and it will set ZZZPT_HIRED_GODWIN. No conversation script is necessary. Instead, in the properties of the plot zzzpt_hired, we add a plot event script, as follows.
<pre>
// PARTY HIRE PLOT SCRIPT
//
// This is called in conversation when a party member is hired for the first time.
// If the party is full, the party picker is displayed, which forces the PARTYMEMBER_ADDED
// module event.
//
// The flag value is never referenced, because the code is common for all party members.

#include "events_h"
#include "global_objects_h"
#include "utility_h"
#include "sys_rewards_h"
#include "log_h"
#include "utility_h"
#include "wrappers_h"
#include "plot_h"

#include "zzz_h" // A header containing the zzzPartyMemberID function
#include "plt_zzzpt_hired"
#include "plt_zzzpt_party"

int StartingConditional()
{
event eParms = GetCurrentEvent();
int nType = GetEventType(eParms); // GET or SET
string strPlot = GetEventString(eParms, 0); // Plot GUID
int nFlag = GetEventInteger(eParms, 1); // Plot flag
object oParty = GetEventCreator(eParms); // Plot table owner
object oFollower = GetEventObject(eParms, 0); // Conversation owner (if any)
int nPlotType = GetEventInteger(eParms, 5); // Plot type

int bIsTutorial = GetM2DAInt(TABLE_PLOT_TYPES, "IsTutorial", nPlotType);
int bIsCodex = GetM2DAInt(TABLE_PLOT_TYPES, "IsCodex", nPlotType);

int nResult = FALSE; // return value for DEFINED GET
object oPC = GetPartyLeader();

plot_GlobalPlotHandler(eParms); // any global plot operations, including debug info

if (nType == EVENT_TYPE_SET_PLOT) // actions -> normal flags only
{
int nValue = GetEventInteger(eParms, 2); // 0=Clear 1=Set
int nOldValue = GetEventInteger(eParms, 3); // Current flag value

if (nValue)
{
if (GetArraySize(GetPartyList(oPC)) < 4)
{
// Code from UT_HireFollower with level up bug fixed
SetAutoLevelUp(oFollower, 2);
SetGroupId(oFollower, GetGroupId(GetHero()));
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, FALSE);
// End of code from UT_HireFollower
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE);
}
else
{
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE);
SendPartyMemberHiredEvent(oFollower, TRUE);
// SetPartyPickerGUIStatus(PP_GUI_STATUS_USE);
// ShowPartyPickerGUI();
}
}
}
else // EVENT_TYPE_GET_PLOT -> defined conditions only
{
switch(nFlag)
{

}
}

plot_OutputDefinedFlag(eParms, nResult);
return nResult;
}
</pre>
We still need to handle the party picker events in our module event script:
<pre>
// PARTY MEMBER ADDED - Allow XP gain. Come here, follow me, flag as party member.
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE);
break;
}
// PARTY MEMBER DROPPED - flag as not party member.
case EVENT_TYPE_PARTYMEMBER_DROPPED:
{
object oFollower = GetEventObject(ev, 0);
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), FALSE);
}
</pre>
When we need to refer to a particular follower explicitly, we can still do so - for example, the flag ZZZPT_PARTY_GODWIN will tell use whether Godwin is currently in the party or not.

==== How do I turn off sustained abilities when a follower is dismissed? ====
'''Please note:''' The 1.04 DA:O patch is bugged and removed/broke several features of the toolkit, if you are using it please follow [http://social.bioware.com/forum/1/topic/71/index/3172230/1#3172537 these steps] to re-enable them as one is required for the script below to compile.

There is a potential exploit in what we've done so far. If a follower casts a sustained spell like Flaming Weapons, it affects all party members. When the follower is dismissed, the remaining party members continue to benefit from the spell.

We can prevent this by deactivating modal abilities before opening the party picker. Add these snippets to the module event script:
<pre>
#include "ability_h"
void zDeactivateModalAbilities();
</pre>
and
<pre>
case EVENT_TYPE_PARTYPICKER_INIT:
{
// Deactivate party modal abilities. This ensures that the party no longer benefits
// from spells like Flaming Weapons if the caster is dismissed from the party.
zDeactivateModalAbilities();
break;
}
</pre>
The function looks like this:
<pre>
// Deactivate party's modal abilities

void zDeactivateModalAbilities()
{
object oPC = GetHero();
object [] oFollowerTable = GetPartyList(oPC);
object oFollower;
int nPartySize = GetArraySize(oFollowerTable);
int [] nAbilityTable;
int nAbilityCount;
int nAbility;
int i = -1;
int j;

while (++i < nPartySize)
{
oFollower = oFollowerTable[i];
nAbilityTable = GetAbilityList(oFollower);
nAbilityCount = GetArraySize(nAbilityTable);
j = -1;

while (++j < nAbilityCount)
{
nAbility = nAbilityTable[j];

if (Ability_IsAbilityActive(oFollower, nAbility))
if (Ability_IsModalAbility(nAbility))
Ability_DeactivateModalAbility(oFollower, nAbility);
}
}
}
</pre>
If other ways of dismissing party members are permitted, the same function can be used.

== Advanced Follower Creation: An Alternative Approach ==

While these things are to a large extent a matter of taste, I see no reason to reinvent the wheel when there is a perfectly good wheel at hand. The following describes how to adapt the existing machinery for the recruitment and tracking of your own party members.

First create the setup as described above in Simple Follower Creation, except for the scripts and plot tables. In addition, create the GDA extensions for a level-up table and the M2DA which points to those tables, as described in Advanced Follower Creation above.

Now ...

=== Step 1: Create a party plot table ===

Have a look at the gen00pt_party plot table and create a similar table for your own followers. Don't bother with the Defined Flags for the moment, just the Main Flags will do, ie recruited, in-camp and in-party for each follower. (Critical Note: Do not duplicate the plot table, create one from scratch. This is the case for ALL plot tables because of a show-stopping bug which means a new GUID is not assigned on Duplicate of a plot.)

=== Step 2: Create a party script ===

Duplicate the gen00pt_party script and rename for your module (conventionally plot tables and their plot scripts have the same name). Delete (or comment out) the Defined Flags section at the end and any lines dealing with logging and tutorials. Change names to those of your party members. If you are using gifting, approval or forced inclusion you may wish to retain those sections of code, but additional machinery will be needed for these facilities to work. For approval you can specify a starting level of approval here for each follower if you want it to be other than zero (as per the existing section dealing with Dog). Note that the custom hire function at the head of the script allows you to specify whether or not to invoke the party picker on recruitment. You may not want to do so for the first couple of followers (but see below). You should already have defined all required constants in a separate file for your module, eg <module prefix>_constants_h. If not, do so now and include it, as well as your plot table, at the head of the script. Delete includes that only refer to the main campaign. (If this is all Greek to you, spend a couple of hours examining the set-up of the Demo, which is packaged with the toolset, and go through the introductory tutorials referenced on the main page of this wiki).

Looking at the new party script, notice that the follower-in-camp function is not defined. This is because for some arcane reason it is defined in party_h, and unhappily references the main campaign's plot table. So we will have to create a new function to replace it, change the other function's flag reference (for the sake of neatness), and change the call in the main body of the script. (You may decide later for other reasons to replicate and customise party_h, but that won't interfere with re-creating this function here.)

Our two functions at the head of the script should be:

<dascript>void SetFollowerInParty(object oFollower, string sPlot, int nCampFlag)
{
WR_SetPlotFlag(sPlot, nCampFlag, FALSE);
WR_SetObjectActive(oFollower, TRUE);
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE);
command cJump = CommandJumpToObject(GetPartyLeader());
WR_AddCommand(oFollower, cJump);
}

void SetFollowerInCamp(object oFollower, string sPlot, int nPartyFlag)
{
WR_SetPlotFlag(sPlot, nPartyFlag, FALSE);
WR_SetObjectActive(oFollower, FALSE);
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);
}</dascript>

and the line in the in-camp sections for each follower should now be:

<dascript>SetFollowerInCamp(o<follower>, strPlot, <follower>_IN_PARTY);</dascript>

=== Step 3: Create package GDAs and reference them in you 2DA_base extension ===

Look at the packages_base GDA and create an extension GDA with one line for each follower based on a main campaign follower that is most like your own follower, eg a sword-shield warrior can be a copy of Alistair, a battle mage a copy of Morrigan, etc. You can look at the Excel version of this GDA to more easily see what the fields mean. It is here that you can specify what if any specialisation will be assigned on hire and the level at which this spec point becomes available. (The IDs for each spec are in the 4000-range of ABI_base.)

Most importantly, it is here also that you define the ID of both your level-up table and the AIP table you are about to create.

Now create aip_follower_<follower name> gda tables, again based on a existing tables most like your own followers. No changes should be required to the copies you create.

In the m2da_base_<your module> extension you have already created, add lines for your AIP tables with a package ID referencing the IDs you assigned in your packages extension table.

Carefully check that all IDs in your GDAs are correct and cross-reference properly, and save the GDAs to your override directory.

Desirable but not obligatory (except for non-humanoid characters), is an extension to the Portraits gda. Finally the Equipment Layout gda will need an extension for non-humanoids, who use a different equipment mask.

=== Step 4: Module script addition ===

Modify your own module script to point to the new plot table and your own followers. To see an example of the required code for the two new sections look at the relevant section of module_core, which are for EVENT_TYPE_PARTYMEMBER_ADDED and EVENT_TYPE_PARTYMEMBER_DROPPED.

=== How it works ===

The recruit flag is set in a conversation (usually, but it could be a script) and that event is then processed by the plot script, which among other things sets both the in-camp and in-party flags, and fires up the party picker by default. If the player then selects the follower in the picker, the in-camp flag is unset (or vice versa if the follower is not selected to join). Subsequently, if the character is selected (or unselected) in the picker, the event is picked up by the module script, which sets the relevant plot flag as true, and that plot event is then sent to the plot scipt which sets the other flag as false.

(Note that if the party picker is turned off for a particular follower's recruit event, that follower will be placed in the active party regardless of the number of members, so ONLY do this for a follower who cannot be recruited when there are already 3 possible followers.)

On recruitment, player_core rebuilds the character according to the specifications laid out in the GDAs, so no further scripting is required.

=== Uses ===

To recruit a party member, set the recruit flag from your plot table in the relevant dialogue. Adding or subtracting followers from the active party is automatically tracked via this machinery, and the plot flags can be interrogated in all your scripts and conversations if you need to know who is currently in the party and who is in camp.

Defined flags can be added as you need them to the script and plot table but there is no point having flags that you will not use, so as with all Defined Flags this is an as-you-go decision, but quite easy to do.

Hiring and firing of temporary party members at the start of a campaign (such as Ser Jory, or Jowan, or Soris, etc) can be handled by UT_HireFollower, and the party picker is not invoked (nor is the Party Camp an available destination).

=== Troubleshooting ===

If you haven't done so already, create a simple debugging area for your module where you can dump the player, all followers and a couple of conversation dummies, and set up a dialogue in which you can invoke all required flags and conditions and see if they actually work as expected. (This setup can be used to test many other components as well.) Global machinery such as this can be painful to set up and get right (unless you are of an exceptionally methodical cast of mind), but it is worthwhile to ensure they are absolutely bullet-proof before you develop the specifics of your module.

=== The KISS principle ===

This is an "out-of-the-box" solution, and once set up is quite robust. If you want variants not catered for here, do NOT try to modify what you already have working.

'''Use-case:''' You want a follower (example tag: dairren) to be recruited without a set specialisation and one level higher than the PC.

Go to your packages gda and set the spec field to 0. In the character's plot table (you should have at least one for each follower) create a flag which we will call BLAH_BLAH. In the table's plot scipt insert the following very simple event handler:

<dascript>case BLAH_BLAH:
{
SetCreatureProperty(oDairren, 38, 1.00); //awards the spec point; field from the properties gda
int aLevel = GetLevel(oHero); //some simple arithmetic to find out the XP we need to award
int bLevel = (aLevel+1);
int aPoints = RW_GetXPNeededForLevel(aLevel);
int bPoints = RW_GetXPNeededForLevel(bLevel);
int targetPoints = (bPoints - aPoints);
RewardXP(oDairren, targetPoints, FALSE, TRUE); //award the XP, and we're done
break;
}</dascript>

The flag can be set in the same conversation as the recruit flag, so long as it comes afterwards. This way you not only maintain the integrity of your core machinery, but keep exceptions/variations for particular characters where they belong -- with that character's plot tables and scripts.

[[Category:Tutorials]]
{{Languages}}

Follower tutorial

2011-07-13T16:13:50Z

Obadiah: /* Add Plot Flags to Party Picker Event Intercept */

== Simple Follower Creation ==

Follow these steps to create a follower that

- Levels up with a default package

- Can be chosen from the party picker

- Can gain XP

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

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

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.

=== Create the creature ===

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

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

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

[[File:class.jpg]]

Under Package/Scaling set:

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

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

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

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

[[File:package.jpg]]

Save and export your character as normal.

=== Overlay char_stage ===

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.

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.

[[File:area_palette.jpg]]

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

[[File:char_stage.jpg]]

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

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

Save and export the area.

Add the following to your module event script:
<dascript>
case EVENT_TYPE_MODULE_GETCHARSTAGE:
{
// Overlay the existing stage with my stage
// "my_char_stage" is the resource name of the overlay area
// "partypicker" is the name of the default GDA
SetPartyPickerStage("my_char_stage", "partypicker");
break;
}
</dascript>

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

You will need to create two Excel spreadsheets.

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

Set up your columns as follows:

[[File:partypickerm2da.jpg]]

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

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

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

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

'''NOTE - ON SELECTION ANIMATIONS'''

Add Animation and Remove Animation are actually Id numbers of different animations, taken from anim_base.gda

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.
Here are some examples you can use:

819 - talk cursing

629 - reading a book (doesn't work, since it probably requires a book object)

844 - hands behind back (848 and 849 are Enter and Exit versions respectfully)

850 - chest pounding salute

811 - fist pounding

277 - dance

247 - cast area spell

500 - vfx cast

600 - surprised

603 - praying

607 - head bow

609 - standing at attention

651,652 - crouch pray (Enter and exit)

808 - point forward

825 - nodding

840 - hand chop or frustration

905,906 - crouch (Enter, Exit)

919,920 - sit on ground (enter, exit)

965 - kneel down loop

972 - wipe nose

976,977 - squat (Enter, Exit)

986 - wipe eyes

998,999 - hands clasped (Enter, exit)

3029 - inspect nails

3031,3032 - playful (enter, exit)

3054,3056 - slouch (enter, exit)
255 - in-place fly

'''NOTE - ON SELECTION VFX'''

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

Some examples:

ID --- BLENDTREENAME --- EFFECT

6039 --- fxm_energy_up_p --- Lady of the Forest pillar of light

6040 --- fxm_power_in_p --- Branka - power in

3054 --- fxc_lotf_c --- Lady of the Forest - swirling leaves

3009 --- fxc_succubus_c --- Succubus crust

1549 --- fxa_hly_imp_c --- Holy Impact crust

1076 --- fxa_spi_aur_mht_c --- Spirit - Aura Might crust

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

Set up your columns and data like so:

[[File:party_pickerm2da.jpg]]

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

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

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

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

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

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

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

=== Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event ===

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

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

If you're not sure how to set a module script, go to '''File''' then '''Manage Modules,''' select your module and click '''Properties.'''

<dascript>
#include "utility_h"

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); //Allows the follower to gain XP
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); //Adds follower to the active party
break;
}

}
}
</dascript>

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

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

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

Remember to save and export your module script.

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:

[[File:module_script.jpg]]

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

=== Create Your Hiring Script ===

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

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

<dascript>
#include "utility_h"

void main() {

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

UT_HireFollower(oFollower); //Hires the follower

SetPartyPickerGUIStatus(2);

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

}
</dascript>

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

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

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:

[[File:hire_conv.jpg]]

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.

If everything worked, you should see something like this:

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

== Advanced Follower Creation ==

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

- Unique level-up template

- Class and specialisation chosen via script

- Any starting state

- Level higher than the PC

- Starts with a specialisation point rather than a specific specialisation

- Set plot flags in the call to the hire script

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

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

=== Create Party Plot ===

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

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

[[File:follower_plot.jpg]]

See FAQ for an alternative approach to plots when there are more than three potential party members.

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

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

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

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

AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.

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

break;
}

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

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

}

}
}
</dascript>

=== Create a Level Up Template ===

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

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

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

It should look something like this:

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

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

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

We will edit the remaining columns like so:

==== Setting Stat Weights ====

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

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

[[File:miera_stat_weights.jpg]]

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

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

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.

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

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

'''Columns H''' and '''I''' are the skills that the character will buy, in preference order from top to bottom.

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

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

[[File:AlMori_talent_pref.jpg]]

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

[[File:ALMori_copy.jpg]]

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

[[File:ALMori_paste.jpg]]

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

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

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

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

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

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

[[File:m2da_base_fofbc.jpg]]

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

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

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

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

FOR AUTOLEVEL TO WORK AFTER RECRUITING:

Look in packages.xls.
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.
(alternatively, you could try packages_base.gda)

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

This section is probably only relevent if you have a specific need to override the functionality of player_core.

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

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

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

Paste in the following script:

<dascript>
#include "sys_chargen_h"
#include "wrappers_h"
#include "utility_h"
#include "sys_rewards_h"
#include "approval_h"
#include "sys_autolevelup_h"

/* Jye Nicolson 5-Jan-2010
This function set duplicates the full functionality chain of UT_HireFollower, with the following exceptions:

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

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

Calling the function:

Simple:

hireCustomFollower(oFollower, CLASS_WARRIOR);

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

Best Practice:

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

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

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

Full argument list:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

)
*/
/* GetCustomFollowerALTable()
This function is where you put your custom table assignments.

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

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

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

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

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

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

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

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

return nTable;
}

// This just cleans up the main function a little

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

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

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

return nTargetLevel;

}

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

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

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

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

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

/* InitCustomFollowerSpec:

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

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

*/

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

if (nForceSpec == 0) {

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

} else {

AddAbility(oFollower, nForceSpec);

}
}

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

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

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

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

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

object oHero = GetHero();

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

This loosely replicates WR_SetFollowerState.

*/

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

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

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

/* ################# BEGIN PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION #################
This replicates the EVENT_TYPE_PARTY_MEMBER_HIRED handler from player_core, stripped down for simplicity and allowing our custom options.

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// load tactics
InitCustomFollowerTactics(oFollower, nPackage);

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

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

//Set plot flags

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

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

// Invoke picker if requested.

if (bInvokePicker) {
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();
}
}
</dascript>

Yeah, I know. It can't really be any smaller. Feel free to modify it if you're confident with scripting.
==== Add Your Custom Autolevel Template to GetCustomFollowerALTable() ====
While you can pass the ID you made for your autolevel template to that monster function as an argument, it's better to have them all in one place if you have multiple followers.

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

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

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

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

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

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

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

return nTable;

}
</dascript>

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

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

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

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

Take a look at the following example:

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

void main() {

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

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

//Simplest hire call - adds to the party as a wizard. Class is currently compulsory due to a bug.
hireCustomFollower(oMiera, CLASS_WIZARD);

//Add to the party and set joining plot flags
hireCustomFollower(oJysavin, CLASS_WARRIOR, PLT_BC_CREATE_PARTY, PARTY_JYSAVIN_JOINED);

//Add to the party, set plot flags, force a specialisation
hireCustomFollower(oBraghon, CLASS_ROGUE, PLT_BC_CREATE_PARTY, PARTY_BRAGHON_JOINED, ABILITY_TALENT_HIDDEN_ASSASSIN);

//More complex example - Follower added as a unique class (Dog), not granted a specialisation or spec point.
//Note unique classes must have an ALTable passed here or specified in GetCustomFollowerALTable() or they won't work
hireCustomFollower(oSpider, CLASS_DOG, PLT_BC_CREATE_PARTY, PARTY_GELDUAL_JOINED, 0, 0, FALSE, FOLLOWER_STATE_AVAILABLE, "", 0, 0, FALSE);

//Show the party picker to let the player choose from their new companions!
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();
}
</dascript>

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

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

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

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

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

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

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

== Common Follower Problems & FAQ ==

====Why don't my followers gain XP?====
There is a bug in UT_HireFollower. Make a copy of UT_HireFollower in a function of your own, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);

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

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

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

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

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

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

====Dog talents and equipment slots don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots. Equipment slots are for humans, not dogs.

Line 78 of packages_base in packages.xls (Dog) should have the LevelUpTable column set to 257 which is the ALDog table.

The EquipmentLayout 2DA needs a new entry for the follower:

ID=same as partypicker 2DA
Tag=follower tag
AvailableEquipmentSlots=794624
Layout=2
EnableWeaponSets=0

If the creature is not using the appearance "Dog, Party Member", it needs a new appearance line in APR_base. Most of the entries can be copied from the standard appearance (e.g. Wolf), but

MaxScaleLevel=-1
DefaultArmor=
AppearanceRestrictionGroup=1

Otherwise, it won't be able to progress beyond a specified level. The player will receive an unwanted set of armour when the it is hired, and it won't be able to use Marabi crunch items. You may also need to tweak PERSPACE and/or BumpLevel if excessive clipping occurs.

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

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

The next section answers this question, up to a point.

==== What if there are more than three potential followers? ====
This example handles larger numbers of followers, and doesn't force the player to use the party picker unless the party is already full.

The prefix zzz, used throughout, can be replaced with whatever [[Prefixes_in_use | prefix]] you are using for your resources.

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.
<pre>
// Party member id (e.g. 1=Alicia, 2=Godwin...)
int zzzPartyMemberID(object oPartyMember)
{
string sPartyMember = GetTag(oPartyMember);

if (sPartyMember == "zzzcr_alicia") return 1;
if (sPartyMember == "zzzcr_godwin") return 2;
if (sPartyMember == "zzzcr_harold") return 3;
if (sPartyMember == "zzzcr_lara" ) return 4;
return 0;
}
</pre>

Make two separate plots, e.g. zzzpt_hired for when a follower is first recruited, and zzzpt_party to flag whether they're currently in the party. Use flag values that correspond to the unique follower id, e.g. ZZZPT_HIRED_GODWIN will be 2.

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.

Follower conversation is now very simple. In Godwin's dialogue, the hiring line will be conditional - when ZZZPT_HIRED_GODWIN is clear - and it will set ZZZPT_HIRED_GODWIN. No conversation script is necessary. Instead, in the properties of the plot zzzpt_hired, we add a plot event script, as follows.
<pre>
// PARTY HIRE PLOT SCRIPT
//
// This is called in conversation when a party member is hired for the first time.
// If the party is full, the party picker is displayed, which forces the PARTYMEMBER_ADDED
// module event.
//
// The flag value is never referenced, because the code is common for all party members.

#include "events_h"
#include "global_objects_h"
#include "utility_h"
#include "sys_rewards_h"
#include "log_h"
#include "utility_h"
#include "wrappers_h"
#include "plot_h"

#include "zzz_h" // A header containing the zzzPartyMemberID function
#include "plt_zzzpt_hired"
#include "plt_zzzpt_party"

int StartingConditional()
{
event eParms = GetCurrentEvent();
int nType = GetEventType(eParms); // GET or SET
string strPlot = GetEventString(eParms, 0); // Plot GUID
int nFlag = GetEventInteger(eParms, 1); // Plot flag
object oParty = GetEventCreator(eParms); // Plot table owner
object oFollower = GetEventObject(eParms, 0); // Conversation owner (if any)
int nPlotType = GetEventInteger(eParms, 5); // Plot type

int bIsTutorial = GetM2DAInt(TABLE_PLOT_TYPES, "IsTutorial", nPlotType);
int bIsCodex = GetM2DAInt(TABLE_PLOT_TYPES, "IsCodex", nPlotType);

int nResult = FALSE; // return value for DEFINED GET
object oPC = GetPartyLeader();

plot_GlobalPlotHandler(eParms); // any global plot operations, including debug info

if (nType == EVENT_TYPE_SET_PLOT) // actions -> normal flags only
{
int nValue = GetEventInteger(eParms, 2); // 0=Clear 1=Set
int nOldValue = GetEventInteger(eParms, 3); // Current flag value

if (nValue)
{
if (GetArraySize(GetPartyList(oPC)) < 4)
{
// Code from UT_HireFollower with level up bug fixed
SetAutoLevelUp(oFollower, 2);
SetGroupId(oFollower, GetGroupId(GetHero()));
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, FALSE);
// End of code from UT_HireFollower
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE);
}
else
{
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE);
SendPartyMemberHiredEvent(oFollower, TRUE);
// SetPartyPickerGUIStatus(PP_GUI_STATUS_USE);
// ShowPartyPickerGUI();
}
}
}
else // EVENT_TYPE_GET_PLOT -> defined conditions only
{
switch(nFlag)
{

}
}

plot_OutputDefinedFlag(eParms, nResult);
return nResult;
}
</pre>
We still need to handle the party picker events in our module event script:
<pre>
// PARTY MEMBER ADDED - Allow XP gain. Come here, follow me, flag as party member.
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE);
break;
}
// PARTY MEMBER DROPPED - flag as not party member.
case EVENT_TYPE_PARTYMEMBER_DROPPED:
{
object oFollower = GetEventObject(ev, 0);
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), FALSE);
}
</pre>
When we need to refer to a particular follower explicitly, we can still do so - for example, the flag ZZZPT_PARTY_GODWIN will tell use whether Godwin is currently in the party or not.

==== How do I turn off sustained abilities when a follower is dismissed? ====
'''Please note:''' The 1.04 DA:O patch is bugged and removed/broke several features of the toolkit, if you are using it please follow [http://social.bioware.com/forum/1/topic/71/index/3172230/1#3172537 these steps] to re-enable them as one is required for the script below to compile.

There is a potential exploit in what we've done so far. If a follower casts a sustained spell like Flaming Weapons, it affects all party members. When the follower is dismissed, the remaining party members continue to benefit from the spell.

We can prevent this by deactivating modal abilities before opening the party picker. Add these snippets to the module event script:
<pre>
#include "ability_h"
void zDeactivateModalAbilities();
</pre>
and
<pre>
case EVENT_TYPE_PARTYPICKER_INIT:
{
// Deactivate party modal abilities. This ensures that the party no longer benefits
// from spells like Flaming Weapons if the caster is dismissed from the party.
zDeactivateModalAbilities();
break;
}
</pre>
The function looks like this:
<pre>
// Deactivate party's modal abilities

void zDeactivateModalAbilities()
{
object oPC = GetHero();
object [] oFollowerTable = GetPartyList(oPC);
object oFollower;
int nPartySize = GetArraySize(oFollowerTable);
int [] nAbilityTable;
int nAbilityCount;
int nAbility;
int i = -1;
int j;

while (++i < nPartySize)
{
oFollower = oFollowerTable[i];
nAbilityTable = GetAbilityList(oFollower);
nAbilityCount = GetArraySize(nAbilityTable);
j = -1;

while (++j < nAbilityCount)
{
nAbility = nAbilityTable[j];

if (Ability_IsAbilityActive(oFollower, nAbility))
if (Ability_IsModalAbility(nAbility))
Ability_DeactivateModalAbility(oFollower, nAbility);
}
}
}
</pre>
If other ways of dismissing party members are permitted, the same function can be used.

== Advanced Follower Creation: An Alternative Approach ==

While these things are to a large extent a matter of taste, I see no reason to reinvent the wheel when there is a perfectly good wheel at hand. The following describes how to adapt the existing machinery for the recruitment and tracking of your own party members.

First create the setup as described above in Simple Follower Creation, except for the scripts and plot tables. In addition, create the GDA extensions for a level-up table and the M2DA which points to those tables, as described in Advanced Follower Creation above.

Now ...

=== Step 1: Create a party plot table ===

Have a look at the gen00pt_party plot table and create a similar table for your own followers. Don't bother with the Defined Flags for the moment, just the Main Flags will do, ie recruited, in-camp and in-party for each follower. (Critical Note: Do not duplicate the plot table, create one from scratch. This is the case for ALL plot tables because of a show-stopping bug which means a new GUID is not assigned on Duplicate of a plot.)

=== Step 2: Create a party script ===

Duplicate the gen00pt_party script and rename for your module (conventionally plot tables and their plot scripts have the same name). Delete (or comment out) the Defined Flags section at the end and any lines dealing with logging and tutorials. Change names to those of your party members. If you are using gifting, approval or forced inclusion you may wish to retain those sections of code, but additional machinery will be needed for these facilities to work. For approval you can specify a starting level of approval here for each follower if you want it to be other than zero (as per the existing section dealing with Dog). Note that the custom hire function at the head of the script allows you to specify whether or not to invoke the party picker on recruitment. You may not want to do so for the first couple of followers (but see below). You should already have defined all required constants in a separate file for your module, eg <module prefix>_constants_h. If not, do so now and include it, as well as your plot table, at the head of the script. Delete includes that only refer to the main campaign. (If this is all Greek to you, spend a couple of hours examining the set-up of the Demo, which is packaged with the toolset, and go through the introductory tutorials referenced on the main page of this wiki).

Looking at the new party script, notice that the follower-in-camp function is not defined. This is because for some arcane reason it is defined in party_h, and unhappily references the main campaign's plot table. So we will have to create a new function to replace it, change the other function's flag reference (for the sake of neatness), and change the call in the main body of the script. (You may decide later for other reasons to replicate and customise party_h, but that won't interfere with re-creating this function here.)

Our two functions at the head of the script should be:

<dascript>void SetFollowerInParty(object oFollower, string sPlot, int nCampFlag)
{
WR_SetPlotFlag(sPlot, nCampFlag, FALSE);
WR_SetObjectActive(oFollower, TRUE);
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE);
command cJump = CommandJumpToObject(GetPartyLeader());
WR_AddCommand(oFollower, cJump);
}

void SetFollowerInCamp(object oFollower, string sPlot, int nPartyFlag)
{
WR_SetPlotFlag(sPlot, nPartyFlag, FALSE);
WR_SetObjectActive(oFollower, FALSE);
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);
}</dascript>

and the line in the in-camp sections for each follower should now be:

<dascript>SetFollowerInCamp(o<follower>, strPlot, <follower>_IN_PARTY);</dascript>

=== Step 3: Create package GDAs and reference them in you 2DA_base extension ===

Look at the packages_base GDA and create an extension GDA with one line for each follower based on a main campaign follower that is most like your own follower, eg a sword-shield warrior can be a copy of Alistair, a battle mage a copy of Morrigan, etc. You can look at the Excel version of this GDA to more easily see what the fields mean. It is here that you can specify what if any specialisation will be assigned on hire and the level at which this spec point becomes available. (The IDs for each spec are in the 4000-range of ABI_base.)

Most importantly, it is here also that you define the ID of both your level-up table and the AIP table you are about to create.

Now create aip_follower_<follower name> gda tables, again based on a existing tables most like your own followers. No changes should be required to the copies you create.

In the m2da_base_<your module> extension you have already created, add lines for your AIP tables with a package ID referencing the IDs you assigned in your packages extension table.

Carefully check that all IDs in your GDAs are correct and cross-reference properly, and save the GDAs to your override directory.

Desirable but not obligatory (except for non-humanoid characters), is an extension to the Portraits gda. Finally the Equipment Layout gda will need an extension for non-humanoids, who use a different equipment mask.

=== Step 4: Module script addition ===

Modify your own module script to point to the new plot table and your own followers. To see an example of the required code for the two new sections look at the relevant section of module_core, which are for EVENT_TYPE_PARTYMEMBER_ADDED and EVENT_TYPE_PARTYMEMBER_DROPPED.

=== How it works ===

The recruit flag is set in a conversation (usually, but it could be a script) and that event is then processed by the plot script, which among other things sets both the in-camp and in-party flags, and fires up the party picker by default. If the player then selects the follower in the picker, the in-camp flag is unset (or vice versa if the follower is not selected to join). Subsequently, if the character is selected (or unselected) in the picker, the event is picked up by the module script, which sets the relevant plot flag as true, and that plot event is then sent to the plot scipt which sets the other flag as false.

(Note that if the party picker is turned off for a particular follower's recruit event, that follower will be placed in the active party regardless of the number of members, so ONLY do this for a follower who cannot be recruited when there are already 3 possible followers.)

On recruitment, player_core rebuilds the character according to the specifications laid out in the GDAs, so no further scripting is required.

=== Uses ===

To recruit a party member, set the recruit flag from your plot table in the relevant dialogue. Adding or subtracting followers from the active party is automatically tracked via this machinery, and the plot flags can be interrogated in all your scripts and conversations if you need to know who is currently in the party and who is in camp.

Defined flags can be added as you need them to the script and plot table but there is no point having flags that you will not use, so as with all Defined Flags this is an as-you-go decision, but quite easy to do.

Hiring and firing of temporary party members at the start of a campaign (such as Ser Jory, or Jowan, or Soris, etc) can be handled by UT_HireFollower, and the party picker is not invoked (nor is the Party Camp an available destination).

=== Troubleshooting ===

If you haven't done so already, create a simple debugging area for your module where you can dump the player, all followers and a couple of conversation dummies, and set up a dialogue in which you can invoke all required flags and conditions and see if they actually work as expected. (This setup can be used to test many other components as well.) Global machinery such as this can be painful to set up and get right (unless you are of an exceptionally methodical cast of mind), but it is worthwhile to ensure they are absolutely bullet-proof before you develop the specifics of your module.

=== The KISS principle ===

This is an "out-of-the-box" solution, and once set up is quite robust. If you want variants not catered for here, do NOT try to modify what you already have working.

'''Use-case:''' You want a follower (example tag: dairren) to be recruited without a set specialisation and one level higher than the PC.

Go to your packages gda and set the spec field to 0. In the character's plot table (you should have at least one for each follower) create a flag which we will call BLAH_BLAH. In the table's plot scipt insert the following very simple event handler:

<dascript>case BLAH_BLAH:
{
SetCreatureProperty(oDairren, 38, 1.00); //awards the spec point; field from the properties gda
int aLevel = GetLevel(oHero); //some simple arithmetic to find out the XP we need to award
int bLevel = (aLevel+1);
int aPoints = RW_GetXPNeededForLevel(aLevel);
int bPoints = RW_GetXPNeededForLevel(bLevel);
int targetPoints = (bPoints - aPoints);
RewardXP(oDairren, targetPoints, FALSE, TRUE); //award the XP, and we're done
break;
}</dascript>

The flag can be set in the same conversation as the recruit flag, so long as it comes afterwards. This way you not only maintain the integrity of your core machinery, but keep exceptions/variations for particular characters where they belong -- with that character's plot tables and scripts.

[[Category:Tutorials]]
{{Languages}}

Follower tutorial

2011-07-13T16:07:05Z

Obadiah: /* Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event */

== Simple Follower Creation ==

Follow these steps to create a follower that

- Levels up with a default package

- Can be chosen from the party picker

- Can gain XP

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

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

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.

=== Create the creature ===

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

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

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

[[File:class.jpg]]

Under Package/Scaling set:

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

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

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

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

[[File:package.jpg]]

Save and export your character as normal.

=== Overlay char_stage ===

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.

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.

[[File:area_palette.jpg]]

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

[[File:char_stage.jpg]]

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

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

Save and export the area.

Add the following to your module event script:
<dascript>
case EVENT_TYPE_MODULE_GETCHARSTAGE:
{
// Overlay the existing stage with my stage
// "my_char_stage" is the resource name of the overlay area
// "partypicker" is the name of the default GDA
SetPartyPickerStage("my_char_stage", "partypicker");
break;
}
</dascript>

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

You will need to create two Excel spreadsheets.

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

Set up your columns as follows:

[[File:partypickerm2da.jpg]]

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

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

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

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

'''NOTE - ON SELECTION ANIMATIONS'''

Add Animation and Remove Animation are actually Id numbers of different animations, taken from anim_base.gda

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.
Here are some examples you can use:

819 - talk cursing

629 - reading a book (doesn't work, since it probably requires a book object)

844 - hands behind back (848 and 849 are Enter and Exit versions respectfully)

850 - chest pounding salute

811 - fist pounding

277 - dance

247 - cast area spell

500 - vfx cast

600 - surprised

603 - praying

607 - head bow

609 - standing at attention

651,652 - crouch pray (Enter and exit)

808 - point forward

825 - nodding

840 - hand chop or frustration

905,906 - crouch (Enter, Exit)

919,920 - sit on ground (enter, exit)

965 - kneel down loop

972 - wipe nose

976,977 - squat (Enter, Exit)

986 - wipe eyes

998,999 - hands clasped (Enter, exit)

3029 - inspect nails

3031,3032 - playful (enter, exit)

3054,3056 - slouch (enter, exit)
255 - in-place fly

'''NOTE - ON SELECTION VFX'''

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

Some examples:

ID --- BLENDTREENAME --- EFFECT

6039 --- fxm_energy_up_p --- Lady of the Forest pillar of light

6040 --- fxm_power_in_p --- Branka - power in

3054 --- fxc_lotf_c --- Lady of the Forest - swirling leaves

3009 --- fxc_succubus_c --- Succubus crust

1549 --- fxa_hly_imp_c --- Holy Impact crust

1076 --- fxa_spi_aur_mht_c --- Spirit - Aura Might crust

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

Set up your columns and data like so:

[[File:party_pickerm2da.jpg]]

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

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

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

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

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

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

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

=== Capture the EVENT_TYPE_PARTYMEMBER_ADDED Event ===

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

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

If you're not sure how to set a module script, go to '''File''' then '''Manage Modules,''' select your module and click '''Properties.'''

<dascript>
#include "utility_h"

void main()
{
event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
switch(nEventType)
{
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); //Allows the follower to gain XP
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); //Adds follower to the active party
break;
}

}
}
</dascript>

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

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

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

Remember to save and export your module script.

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:

[[File:module_script.jpg]]

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

=== Create Your Hiring Script ===

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

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

<dascript>
#include "utility_h"

void main() {

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

UT_HireFollower(oFollower); //Hires the follower

SetPartyPickerGUIStatus(2);

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

}
</dascript>

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

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

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:

[[File:hire_conv.jpg]]

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.

If everything worked, you should see something like this:

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

== Advanced Follower Creation ==

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

- Unique level-up template

- Class and specialisation chosen via script

- Any starting state

- Level higher than the PC

- Starts with a specialisation point rather than a specific specialisation

- Set plot flags in the call to the hire script

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

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

=== Create Party Plot ===

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

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

[[File:follower_plot.jpg]]

See FAQ for an alternative approach to plots when there are more than three potential party members.

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

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

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

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

AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location.

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

break;
}

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

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

}

}
}
</dascript>

=== Create a Level Up Template ===

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

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

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

It should look something like this:

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

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

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

We will edit the remaining columns like so:

==== Setting Stat Weights ====

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

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

[[File:miera_stat_weights.jpg]]

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

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

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.

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

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

'''Columns H''' and '''I''' are the skills that the character will buy, in preference order from top to bottom.

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

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

[[File:AlMori_talent_pref.jpg]]

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

[[File:ALMori_copy.jpg]]

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

[[File:ALMori_paste.jpg]]

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

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

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

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

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

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

[[File:m2da_base_fofbc.jpg]]

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

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

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

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

FOR AUTOLEVEL TO WORK AFTER RECRUITING:

Look in packages.xls.
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.
(alternatively, you could try packages_base.gda)

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

This section is probably only relevent if you have a specific need to override the functionality of player_core.

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

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

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

Paste in the following script:

<dascript>
#include "sys_chargen_h"
#include "wrappers_h"
#include "utility_h"
#include "sys_rewards_h"
#include "approval_h"
#include "sys_autolevelup_h"

/* Jye Nicolson 5-Jan-2010
This function set duplicates the full functionality chain of UT_HireFollower, with the following exceptions:

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

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

Calling the function:

Simple:

hireCustomFollower(oFollower, CLASS_WARRIOR);

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

Best Practice:

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

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

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

Full argument list:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

)
*/
/* GetCustomFollowerALTable()
This function is where you put your custom table assignments.

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

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

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

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

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

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

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

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

return nTable;
}

// This just cleans up the main function a little

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

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

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

return nTargetLevel;

}

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

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

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

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

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

/* InitCustomFollowerSpec:

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

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

*/

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

if (nForceSpec == 0) {

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

} else {

AddAbility(oFollower, nForceSpec);

}
}

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

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

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

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

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

object oHero = GetHero();

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

This loosely replicates WR_SetFollowerState.

*/

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

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

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

/* ################# BEGIN PLAYER_CORE EVENT_TYPE_PARTY_MEMBER_HIRED EMULATION #################
This replicates the EVENT_TYPE_PARTY_MEMBER_HIRED handler from player_core, stripped down for simplicity and allowing our custom options.

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// load tactics
InitCustomFollowerTactics(oFollower, nPackage);

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

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

//Set plot flags

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

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

// Invoke picker if requested.

if (bInvokePicker) {
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();
}
}
</dascript>

Yeah, I know. It can't really be any smaller. Feel free to modify it if you're confident with scripting.
==== Add Your Custom Autolevel Template to GetCustomFollowerALTable() ====
While you can pass the ID you made for your autolevel template to that monster function as an argument, it's better to have them all in one place if you have multiple followers.

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

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

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

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

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

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

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

return nTable;

}
</dascript>

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

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

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

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

Take a look at the following example:

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

void main() {

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

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

//Simplest hire call - adds to the party as a wizard. Class is currently compulsory due to a bug.
hireCustomFollower(oMiera, CLASS_WIZARD);

//Add to the party and set joining plot flags
hireCustomFollower(oJysavin, CLASS_WARRIOR, PLT_BC_CREATE_PARTY, PARTY_JYSAVIN_JOINED);

//Add to the party, set plot flags, force a specialisation
hireCustomFollower(oBraghon, CLASS_ROGUE, PLT_BC_CREATE_PARTY, PARTY_BRAGHON_JOINED, ABILITY_TALENT_HIDDEN_ASSASSIN);

//More complex example - Follower added as a unique class (Dog), not granted a specialisation or spec point.
//Note unique classes must have an ALTable passed here or specified in GetCustomFollowerALTable() or they won't work
hireCustomFollower(oSpider, CLASS_DOG, PLT_BC_CREATE_PARTY, PARTY_GELDUAL_JOINED, 0, 0, FALSE, FOLLOWER_STATE_AVAILABLE, "", 0, 0, FALSE);

//Show the party picker to let the player choose from their new companions!
SetPartyPickerGUIStatus(2);
ShowPartyPickerGUI();
}
</dascript>

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

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

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

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

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

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

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

== Common Follower Problems & FAQ ==

====Why don't my followers gain XP?====
There is a bug in UT_HireFollower. Make a copy of UT_HireFollower in a function of your own, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);

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

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

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

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

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

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

====Dog talents and equipment slots don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots. Equipment slots are for humans, not dogs.

Line 78 of packages_base in packages.xls (Dog) should have the LevelUpTable column set to 257 which is the ALDog table.

The EquipmentLayout 2DA needs a new entry for the follower:

ID=same as partypicker 2DA
Tag=follower tag
AvailableEquipmentSlots=794624
Layout=2
EnableWeaponSets=0

If the creature is not using the appearance "Dog, Party Member", it needs a new appearance line in APR_base. Most of the entries can be copied from the standard appearance (e.g. Wolf), but

MaxScaleLevel=-1
DefaultArmor=
AppearanceRestrictionGroup=1

Otherwise, it won't be able to progress beyond a specified level. The player will receive an unwanted set of armour when the it is hired, and it won't be able to use Marabi crunch items. You may also need to tweak PERSPACE and/or BumpLevel if excessive clipping occurs.

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

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

The next section answers this question, up to a point.

==== What if there are more than three potential followers? ====
This example handles larger numbers of followers, and doesn't force the player to use the party picker unless the party is already full.

The prefix zzz, used throughout, can be replaced with whatever [[Prefixes_in_use | prefix]] you are using for your resources.

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.
<pre>
// Party member id (e.g. 1=Alicia, 2=Godwin...)
int zzzPartyMemberID(object oPartyMember)
{
string sPartyMember = GetTag(oPartyMember);

if (sPartyMember == "zzzcr_alicia") return 1;
if (sPartyMember == "zzzcr_godwin") return 2;
if (sPartyMember == "zzzcr_harold") return 3;
if (sPartyMember == "zzzcr_lara" ) return 4;
return 0;
}
</pre>

Make two separate plots, e.g. zzzpt_hired for when a follower is first recruited, and zzzpt_party to flag whether they're currently in the party. Use flag values that correspond to the unique follower id, e.g. ZZZPT_HIRED_GODWIN will be 2.

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.

Follower conversation is now very simple. In Godwin's dialogue, the hiring line will be conditional - when ZZZPT_HIRED_GODWIN is clear - and it will set ZZZPT_HIRED_GODWIN. No conversation script is necessary. Instead, in the properties of the plot zzzpt_hired, we add a plot event script, as follows.
<pre>
// PARTY HIRE PLOT SCRIPT
//
// This is called in conversation when a party member is hired for the first time.
// If the party is full, the party picker is displayed, which forces the PARTYMEMBER_ADDED
// module event.
//
// The flag value is never referenced, because the code is common for all party members.

#include "events_h"
#include "global_objects_h"
#include "utility_h"
#include "sys_rewards_h"
#include "log_h"
#include "utility_h"
#include "wrappers_h"
#include "plot_h"

#include "zzz_h" // A header containing the zzzPartyMemberID function
#include "plt_zzzpt_hired"
#include "plt_zzzpt_party"

int StartingConditional()
{
event eParms = GetCurrentEvent();
int nType = GetEventType(eParms); // GET or SET
string strPlot = GetEventString(eParms, 0); // Plot GUID
int nFlag = GetEventInteger(eParms, 1); // Plot flag
object oParty = GetEventCreator(eParms); // Plot table owner
object oFollower = GetEventObject(eParms, 0); // Conversation owner (if any)
int nPlotType = GetEventInteger(eParms, 5); // Plot type

int bIsTutorial = GetM2DAInt(TABLE_PLOT_TYPES, "IsTutorial", nPlotType);
int bIsCodex = GetM2DAInt(TABLE_PLOT_TYPES, "IsCodex", nPlotType);

int nResult = FALSE; // return value for DEFINED GET
object oPC = GetPartyLeader();

plot_GlobalPlotHandler(eParms); // any global plot operations, including debug info

if (nType == EVENT_TYPE_SET_PLOT) // actions -> normal flags only
{
int nValue = GetEventInteger(eParms, 2); // 0=Clear 1=Set
int nOldValue = GetEventInteger(eParms, 3); // Current flag value

if (nValue)
{
if (GetArraySize(GetPartyList(oPC)) < 4)
{
// Code from UT_HireFollower with level up bug fixed
SetAutoLevelUp(oFollower, 2);
SetGroupId(oFollower, GetGroupId(GetHero()));
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, FALSE);
// End of code from UT_HireFollower
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE);
}
else
{
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);
SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE);
SendPartyMemberHiredEvent(oFollower, TRUE);
// SetPartyPickerGUIStatus(PP_GUI_STATUS_USE);
// ShowPartyPickerGUI();
}
}
}
else // EVENT_TYPE_GET_PLOT -> defined conditions only
{
switch(nFlag)
{

}
}

plot_OutputDefinedFlag(eParms, nResult);
return nResult;
}
</pre>
We still need to handle the party picker events in our module event script:
<pre>
// PARTY MEMBER ADDED - Allow XP gain. Come here, follow me, flag as party member.
case EVENT_TYPE_PARTYMEMBER_ADDED:
{
object oFollower = GetEventObject(ev, 0);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE);
break;
}
// PARTY MEMBER DROPPED - flag as not party member.
case EVENT_TYPE_PARTYMEMBER_DROPPED:
{
object oFollower = GetEventObject(ev, 0);
WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), FALSE);
}
</pre>
When we need to refer to a particular follower explicitly, we can still do so - for example, the flag ZZZPT_PARTY_GODWIN will tell use whether Godwin is currently in the party or not.

==== How do I turn off sustained abilities when a follower is dismissed? ====
'''Please note:''' The 1.04 DA:O patch is bugged and removed/broke several features of the toolkit, if you are using it please follow [http://social.bioware.com/forum/1/topic/71/index/3172230/1#3172537 these steps] to re-enable them as one is required for the script below to compile.

There is a potential exploit in what we've done so far. If a follower casts a sustained spell like Flaming Weapons, it affects all party members. When the follower is dismissed, the remaining party members continue to benefit from the spell.

We can prevent this by deactivating modal abilities before opening the party picker. Add these snippets to the module event script:
<pre>
#include "ability_h"
void zDeactivateModalAbilities();
</pre>
and
<pre>
case EVENT_TYPE_PARTYPICKER_INIT:
{
// Deactivate party modal abilities. This ensures that the party no longer benefits
// from spells like Flaming Weapons if the caster is dismissed from the party.
zDeactivateModalAbilities();
break;
}
</pre>
The function looks like this:
<pre>
// Deactivate party's modal abilities

void zDeactivateModalAbilities()
{
object oPC = GetHero();
object [] oFollowerTable = GetPartyList(oPC);
object oFollower;
int nPartySize = GetArraySize(oFollowerTable);
int [] nAbilityTable;
int nAbilityCount;
int nAbility;
int i = -1;
int j;

while (++i < nPartySize)
{
oFollower = oFollowerTable[i];
nAbilityTable = GetAbilityList(oFollower);
nAbilityCount = GetArraySize(nAbilityTable);
j = -1;

while (++j < nAbilityCount)
{
nAbility = nAbilityTable[j];

if (Ability_IsAbilityActive(oFollower, nAbility))
if (Ability_IsModalAbility(nAbility))
Ability_DeactivateModalAbility(oFollower, nAbility);
}
}
}
</pre>
If other ways of dismissing party members are permitted, the same function can be used.

== Advanced Follower Creation: An Alternative Approach ==

While these things are to a large extent a matter of taste, I see no reason to reinvent the wheel when there is a perfectly good wheel at hand. The following describes how to adapt the existing machinery for the recruitment and tracking of your own party members.

First create the setup as described above in Simple Follower Creation, except for the scripts and plot tables. In addition, create the GDA extensions for a level-up table and the M2DA which points to those tables, as described in Advanced Follower Creation above.

Now ...

=== Step 1: Create a party plot table ===

Have a look at the gen00pt_party plot table and create a similar table for your own followers. Don't bother with the Defined Flags for the moment, just the Main Flags will do, ie recruited, in-camp and in-party for each follower. (Critical Note: Do not duplicate the plot table, create one from scratch. This is the case for ALL plot tables because of a show-stopping bug which means a new GUID is not assigned on Duplicate of a plot.)

=== Step 2: Create a party script ===

Duplicate the gen00pt_party script and rename for your module (conventionally plot tables and their plot scripts have the same name). Delete (or comment out) the Defined Flags section at the end and any lines dealing with logging and tutorials. Change names to those of your party members. If you are using gifting, approval or forced inclusion you may wish to retain those sections of code, but additional machinery will be needed for these facilities to work. For approval you can specify a starting level of approval here for each follower if you want it to be other than zero (as per the existing section dealing with Dog). Note that the custom hire function at the head of the script allows you to specify whether or not to invoke the party picker on recruitment. You may not want to do so for the first couple of followers (but see below). You should already have defined all required constants in a separate file for your module, eg <module prefix>_constants_h. If not, do so now and include it, as well as your plot table, at the head of the script. Delete includes that only refer to the main campaign. (If this is all Greek to you, spend a couple of hours examining the set-up of the Demo, which is packaged with the toolset, and go through the introductory tutorials referenced on the main page of this wiki).

Looking at the new party script, notice that the follower-in-camp function is not defined. This is because for some arcane reason it is defined in party_h, and unhappily references the main campaign's plot table. So we will have to create a new function to replace it, change the other function's flag reference (for the sake of neatness), and change the call in the main body of the script. (You may decide later for other reasons to replicate and customise party_h, but that won't interfere with re-creating this function here.)

Our two functions at the head of the script should be:

<dascript>void SetFollowerInParty(object oFollower, string sPlot, int nCampFlag)
{
WR_SetPlotFlag(sPlot, nCampFlag, FALSE);
WR_SetObjectActive(oFollower, TRUE);
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE);
command cJump = CommandJumpToObject(GetPartyLeader());
WR_AddCommand(oFollower, cJump);
}

void SetFollowerInCamp(object oFollower, string sPlot, int nPartyFlag)
{
WR_SetPlotFlag(sPlot, nPartyFlag, FALSE);
WR_SetObjectActive(oFollower, FALSE);
WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE);
}</dascript>

and the line in the in-camp sections for each follower should now be:

<dascript>SetFollowerInCamp(o<follower>, strPlot, <follower>_IN_PARTY);</dascript>

=== Step 3: Create package GDAs and reference them in you 2DA_base extension ===

Look at the packages_base GDA and create an extension GDA with one line for each follower based on a main campaign follower that is most like your own follower, eg a sword-shield warrior can be a copy of Alistair, a battle mage a copy of Morrigan, etc. You can look at the Excel version of this GDA to more easily see what the fields mean. It is here that you can specify what if any specialisation will be assigned on hire and the level at which this spec point becomes available. (The IDs for each spec are in the 4000-range of ABI_base.)

Most importantly, it is here also that you define the ID of both your level-up table and the AIP table you are about to create.

Now create aip_follower_<follower name> gda tables, again based on a existing tables most like your own followers. No changes should be required to the copies you create.

In the m2da_base_<your module> extension you have already created, add lines for your AIP tables with a package ID referencing the IDs you assigned in your packages extension table.

Carefully check that all IDs in your GDAs are correct and cross-reference properly, and save the GDAs to your override directory.

Desirable but not obligatory (except for non-humanoid characters), is an extension to the Portraits gda. Finally the Equipment Layout gda will need an extension for non-humanoids, who use a different equipment mask.

=== Step 4: Module script addition ===

Modify your own module script to point to the new plot table and your own followers. To see an example of the required code for the two new sections look at the relevant section of module_core, which are for EVENT_TYPE_PARTYMEMBER_ADDED and EVENT_TYPE_PARTYMEMBER_DROPPED.

=== How it works ===

The recruit flag is set in a conversation (usually, but it could be a script) and that event is then processed by the plot script, which among other things sets both the in-camp and in-party flags, and fires up the party picker by default. If the player then selects the follower in the picker, the in-camp flag is unset (or vice versa if the follower is not selected to join). Subsequently, if the character is selected (or unselected) in the picker, the event is picked up by the module script, which sets the relevant plot flag as true, and that plot event is then sent to the plot scipt which sets the other flag as false.

(Note that if the party picker is turned off for a particular follower's recruit event, that follower will be placed in the active party regardless of the number of members, so ONLY do this for a follower who cannot be recruited when there are already 3 possible followers.)

On recruitment, player_core rebuilds the character according to the specifications laid out in the GDAs, so no further scripting is required.

=== Uses ===

To recruit a party member, set the recruit flag from your plot table in the relevant dialogue. Adding or subtracting followers from the active party is automatically tracked via this machinery, and the plot flags can be interrogated in all your scripts and conversations if you need to know who is currently in the party and who is in camp.

Defined flags can be added as you need them to the script and plot table but there is no point having flags that you will not use, so as with all Defined Flags this is an as-you-go decision, but quite easy to do.

Hiring and firing of temporary party members at the start of a campaign (such as Ser Jory, or Jowan, or Soris, etc) can be handled by UT_HireFollower, and the party picker is not invoked (nor is the Party Camp an available destination).

=== Troubleshooting ===

If you haven't done so already, create a simple debugging area for your module where you can dump the player, all followers and a couple of conversation dummies, and set up a dialogue in which you can invoke all required flags and conditions and see if they actually work as expected. (This setup can be used to test many other components as well.) Global machinery such as this can be painful to set up and get right (unless you are of an exceptionally methodical cast of mind), but it is worthwhile to ensure they are absolutely bullet-proof before you develop the specifics of your module.

=== The KISS principle ===

This is an "out-of-the-box" solution, and once set up is quite robust. If you want variants not catered for here, do NOT try to modify what you already have working.

'''Use-case:''' You want a follower (example tag: dairren) to be recruited without a set specialisation and one level higher than the PC.

Go to your packages gda and set the spec field to 0. In the character's plot table (you should have at least one for each follower) create a flag which we will call BLAH_BLAH. In the table's plot scipt insert the following very simple event handler:

<dascript>case BLAH_BLAH:
{
SetCreatureProperty(oDairren, 38, 1.00); //awards the spec point; field from the properties gda
int aLevel = GetLevel(oHero); //some simple arithmetic to find out the XP we need to award
int bLevel = (aLevel+1);
int aPoints = RW_GetXPNeededForLevel(aLevel);
int bPoints = RW_GetXPNeededForLevel(bLevel);
int targetPoints = (bPoints - aPoints);
RewardXP(oDairren, targetPoints, FALSE, TRUE); //award the XP, and we're done
break;
}</dascript>

The flag can be set in the same conversation as the recruit flag, so long as it comes afterwards. This way you not only maintain the integrity of your core machinery, but keep exceptions/variations for particular characters where they belong -- with that character's plot tables and scripts.

[[Category:Tutorials]]
{{Languages}}

Tutorials

2011-05-07T16:56:02Z

Obadiah:

This page lists links to step-by-step tutorials, both on this wiki and on external sites.

==Introductory tutorials ==

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

{|align=right
|{{TutorialRef|<nowiki>Boxes like these contain links,</nowiki>|<nowiki>to topics taking you to further information</nowiki>}}
|-
|
|-
|{{sidebox|
*Boxes like this contain a checklist of important steps.
*They're intended as a reminder and as a navigational aid.
}}
|}

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

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

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

Various small Tutorials, in a unsorted manner.
*[[How-tos]]
*[[VFX Tutorial]]

== Demo module ==

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

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

== Custom content tutorials ==
*[[Tutorial: Using DLC areas in your mods]]
*[[Tutorial: Adding custom items to custom modules]]
*[[Tutorial: Adding a Custom Model to Toolset]]
*[[Tutorial: Creating a custom placeable from a model]]
*[[Tutorial: Reskinning an Item]]
*[[Tutorial: Creating recolors of existing items]]
*[[Tutorial: Understanding Tints: Overriding Defaults & Creating New Ones]]
*[[Tutorial: Adding a New Weapon Type]]
*[[Tutorial: Adding custom heraldry to a shield]]
*[[Tutorial: Usable campaign items]]
*[[Adding a New Spell Tutorial]]
*[[UI Tutorial (draft)]]

== Character generation tutorials ==
*[[Backgrounds tutorial|Background/Origin Tutorial]]
*[[Add A New Class Tutorial]]
*[[High-Level Character Generation]]

== Companion Tutorials ==
*[[Follower tutorial]] (Simple and advanced, requires scripting knowledge)
*[[Follower_guidelines]] (contains general guidelines and compatibility information)

== Other Tutorials ==
*[[ToolSet: Area Layouts]]
*[[Adding a Location to the Single Player Campaign Tutorial]]
*[[Noob to pro]] (Step by step guide to making a new standalone campaign)
*[[Module Priority Tutorial]] How to set module. Priority for multiple mods with similar files, so they don't interfere
*[[Plot]] Information on configuring plot flags for journal and codex entries

== External Tutorials ==
*[http://dragonagemodding.wordpress.com Beyond Ferelden] has many in-depth tutorials by jwvanderbeck.
*[http://www.youtube.com/watch?v=TwQNRBFLhrE Playable Area and Conversation] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=CaHldJcUTz8 Simple Conversation Cameras] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=QOQJ2heQto4 Cutscene and Trigger] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=szWKgj2ZuXo Custom Level and Room Building] video tutorial by [http://social.bioware.com/64020/ st4rdog].
*[http://www.youtube.com/watch?v=DKJ7F14n8o8 Downloading and Installing the Toolset] video tutorial by [http://social.bioware.com/74287/ DragonAge22].
*[http://www.youtube.com/watch?v=iMPBsulv9xI Creating a Room] video tutorial by [http://social.bioware.com/74287/ DragonAge22].
*[http://www.youtube.com/watch?v=g3kx2CaarHo How to Make an Interior Level with Lighting] video tutorial by [http://social.bioware.com/group/60/ Darkworld Development Team].
*[http://www.youtube.com/watch?v=O6TeZeE1Lc8 Making a Room] video tutorial by BigDrip681.
*[http://social.bioware.com/5339/blog/576/ Custom Player Items In Single Player] by [http://social.bioware.com/5339/ weriK].
*[http://social.bioware.com/5339/blog/651/ The Secret Behind Item Statistics] by [http://social.bioware.com/5339/ weriK].
*[http://social.bioware.com/project/923/ Guide for installing/uninstalling/updating Mods] Beginner Guide to get started with using Mods by [http://social.bioware.com/237411/ Alexspeed].
*[http://www.jezelf.co.uk/tutorials.htm Photoshop Map making tutorials] Credits to Jason Elford, brought to DAT wiki by [http://social.bioware.com/48156/ Arixsus]
*[http://social.bioware.com/project/527/ Video Tutorials by SilentCid] Multiple in-depth video tutorials of the DA Toolset
*[http://www.youtube.com/view_play_list?p=EF29DD1AACEBA92A Qkrch's Video Tutorials] Toolset tutorial complete series for the experienced builder (Spanish & English)
*[http://www.theengineeringguild.co.uk/da-new-campaign-location-tutorial World Editing and Area Creation] Tutorial by [http://social.bioware.com/profile/7848 giskard44] where he walks you through a module creation process for an single player addin.
*[http://social.bioware.com/203442/blog/1352/ Custom Item Materials] by [http://social.bioware.com/203442/ Chains-Gore].
*[http://bg2redux.student.utwente.nl/trac/wiki/TutorialLightmapping Lighting Tutorial with Troubleshooting section] (aimed at beginners)

== See Also ==
*[[Compatibility]]
*[[Dragon Age 2]]
*Can't find what you need? See [[Wiki Improvement Requests]]
{{Languages|Tutorials}}
[[Category:Tutorials| ]]