Dragon Age Toolset Wiki - User contributions [en]

Talk:Compatibility

2011-01-10T08:26:18Z

Gaxkang55: /* Resource scope edit */

== What if my mod extends both Single Player and Awakening? ==

I moved this section here because it's under discussion. [[User:Proleric1|Proleric1]] 08:27, 21 July 2010 (UTC)

-------------
NOTE:

There is an easier way than creating two scripts. Just put the information for both in the manifest.xml file. For one of my mods, the manifest file looked like this:

<pre>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Manifest Type="AddIn">
<AddInsList>
<AddInItem UID="elf_cat_pet" Name="ELF the pet cat for DAO and Awakening" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1">
<Title DefaultText="ELF the pet cat for DAO and Awakening"></Title>
<Description DefaultText="ELF the pet cat adds a 'Cat Toy' to the players inventory (rest of text deleted for brevity)

((This package will work in both DAO and Awakening!))"></Description>
<Image>ico_elf_cat_sleep</Image>
<Rating DefaultText="10"></Rating>
<RatingDescription DefaultText=""></RatingDescription>
<URL DefaultText="www.ELFpath.com"></URL>
<ReleaseDate>6 April 2010</ReleaseDate>
<Version>2.0</Version>
<GameVersion/>
<Type>1</Type>
<Publisher DefaultText="Angel == monkeysnest@yahoo.com"></Publisher>
<PrereqList/>
<FileList>
<Folder src="packages/" Type="package"/>
<Folder src="addins/" Type="addin"/>
</FileList>
</AddInItem>

<AddInItem UID="elf_cat_pet" Name="ELF the pet cat for DAO and Awakening" ExtendedModuleUID="DAO_PRC_EP_1" Priority="100" Enabled="1" State="2" Format="1">
<Title DefaultText="ELF the pet cat"></Title>
<Image>ico_elf_cat_sleep</Image>
<Rating DefaultText=""></Rating>
<RatingDescription DefaultText=""></RatingDescription>
<URL DefaultText="www.ELFpath.com"></URL>
<ReleaseDate>6 April 2010</ReleaseDate>
<Version>2.0</Version>
<GameVersion/>
<Type>1</Type>
<Publisher DefaultText="Angel == monkeysnest@yahoo.com"></Publisher>
<PrereqList/>
<FileList>
<Folder src="addins/" Type="addin"/>
</FileList>
</AddInItem>

</AddInsList>
</Manifest>
</pre>

doing this allowed users to install one package (using DAModder) which worked for both awakening and DAO.

============== ++ Angel

@monkeysnest - good to have the update concerning the manifest. A few queries:

* Perhaps the article would be clearer if you explained which line has to change, rather than reproduce the entire manifest here?

* Would DAUpdater work? I don't see DAModder listed as a project download on the Bioware social site.

* We don't normally leave our signatures on the content pages of a wiki.

Thanks.

[[User:Proleric1|Proleric1]] 05:47, 8 April 2010 (UTC)

I don't think the "dual entry, single manifest" approach should be followed or encouraged. Creating two separate .dazip installations as mentioned in [[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | Compatibility: What if my mod extends both Single Player and Awakening?]] is IMHO the preferred approach.

--[[User:Nukenin|Nukenin]] 00:24, 24 April 2010 (UTC)

I'll have to agree with Nukenin here, especially since using the "dual entry, single manifest" approach will cause DAUpdater to crash and would unnecessarily force players to use third-party apps. Moreover, it's perfectly possible to include several addons (each one with its own manifest entry) in a single dazip package :
* Package root
** Manifest including several AddInItem elements
** Contents
*** addins
**** addin_uid1
**** addin_uid2
**** addin_uid3
**** etc
*** packages

--[[User:Phaenan|Phaenan]] 06:45, 21 July 2010 (UTC)

I find myself agreeing with Phaenan and Nukenin on this; end users should only use community created tools if they want a specific function that's only available to them that way (like the ability to uninstall a dazip).
[[User:Ladydesire|Ladydesire]] 18:40, 25 December 2010 (UTC)

== Override Events while minimizing compat issues.. ==

I believe this may be useful to others - through trial and error, and with some help, I have figured out a way to override events only when my module is running - I had to add a variable to var_module.xls/gda (which is probably where the only potential compatibility issue will arise via string ID, though I am not sure what would happen if someone tried to override the same events - depends on which engineevents get's loaded last I suppose...).

The variable is defaulted to a 0....in my modules properties, I set the variable to a 1. My event overrides check for this variable to be == 1, if not, send it off the proper handler.

See the following post where I came to this 'workaround'...would love to know if there is a better way:

http://social.bioware.com/forum/1/topic/8/index/2371093/1#2531362

== Resource scope edit ==

I have removed the reference to tint maps following the discussion at http://social.bioware.com/group/2937/discussion/12738/ .

Also beefed up the recommendations about not putting files into packages --[[User:Gaxkang55|Gaxkang55]] 12:43, 30 December 2010 (UTC)
-------------
Good update! I'm very much on the same wavelength. I have one question, though, concerning the Talk Table. Normally, the best way to change a core string is to make a new one, then point the appropriate 2DA at it. However, there are cases where no such mechanism exists. For example, if you want to make a module that isn't set in the Ferelden gameworld, you need to change the gender descriptions, replace all instances of "marabi" with "dog" and so on. To the best of my knowledge, this can't be done without an override - see [[String_editor]]. If there's a better solution, I'd be keen to hear it. [[User:Proleric1|Proleric1]] 08:50, 31 December 2010 (UTC)
-------------
As it happens, I had to do exactly that for the campaign I have in development, where I wanted to override the gender description. Create the string but make the Owner Module your module. This will be exported to the talktable placed in your core, and will overwrite the core string as long as your module is enabled. Also tested the head morph stuff, and that doesn't need to be in packages either, so will make a further update. --[[User:Gaxkang55|Gaxkang55]] 04:28, 3 January 2011 (UTC)
-------------
Have you tried to reproduce this [[Bug:_Talk_table_exported_to_packages_override | bug]] for the specific string mentioned there? I double-checked that the Owner Module is set correctly. It isn't exported to the talk table in core (which seems to be empty), nor does it work if the talk table in packages override is moved to any of the add-in folders.

A couple of other issues:

You recommend moving content from the override folders before B2P packaging. Is there any technical reason for that? I haven't heard this from Bioware. "If it ain't bust, don't fix it" might apply here?

You've added some strong words about mods that use packages override. My heart is with you, but my head says the tone could be counter-productive. We seem to be making some progress with persuading the community that compatibility is important, but the "package overriders" are still in the majority. IMO we need to convince them to change their approach voluntarily, not antagonise them. After all, none of us has the power to deprecate anything (nor would we wish to have it). What do you think? [[User:Proleric1|Proleric1]] 08:27, 3 January 2011 (UTC)
-------------
Moving the compiled scripts and exported plots out of the toolsetexport folder '''into''' the override folder is a good idea, since when doing an "empty export directories", you could accidently delete files needed for the builder to player package. I'm not sure why it would be necessary to move files out of the override folder.

As far as the "package overriders" go, some may never change, no matter what we do; I have even seen people that were doing it basically the right way change because they weren't wanting to build multiple packages for their mods. [[User:Ladydesire|Ladydesire]] 00:03, 4 January 2011 (UTC)
-------------
1. I have deleted the sentence about DAZIPs. On re-reading it actually compresses together two different ideas, and in any case doesn't really belong there. I will have a rethink about this when I have a bit more time on the weekend :-)

2. Proleric, the string I override is the gender description string 377283. I export the talktable (which creates the three files) and delete the one in packages, ''core_en-us.tlk'', together with everything else there). Start my game and the string in overwritten correctly by the ''<uid>_c_en-us.tlk'' table.

3. On the issue of packages override, the issue is whether or not this wiki contains correct information and procedures. If someone disagrees that this is the correct procedure (particularly in terms of mod inter-compatibility), I am more than happy to have the discussion. I suspect real change is only going to happen if the end-users start complaining in the comments sections of the download pages, but that's another story. In the meantime, the wiki should stick to the straight and narrow of providing the best information we can assemble --[[User:Gaxkang55|Gaxkang55]] 04:37, 4 January 2011 (UTC)
-------------
1. Thanks.

2. Issue closed. EDIT [[User:Proleric1|Proleric1]] 17:16, 4 January 2011 (UTC) It is not necessary to put a talk table in packages override. Instead of changing core strings, it's better to refer to new strings in the 2DA files (even though finding them is a lot of work when making a global change, such as "Marabi" to "Dog". The gender description string does have to be overridden, but since it's only used in character generation, it's not affected by the save-load bug.

3. Agreed. However, the wiki is about practical advice. The section in question talks about deprecating other people's stuff, which is beyond the reader's control! Instead, I suggest a two-pronged approach. Firstly, we already have the Disclaimer section of this article. Secondly, contribute to the [http://social.bioware.com/project/3966/ project] which is developing an FAQ for players. Just my 2 cents. [[User:Proleric1|Proleric1]] 08:33, 4 January 2011 (UTC)
-------------

On 3, since most players assume that the modder knows best, or are from a game where adding mods can only be done in a specific directory (TES III and TES IV, Fallot 3 and Fallout: New Vegas, just for a few examples), they won't be the ones to complain about having to do that. We should be suggesting the use of modules/Single Player/override for Origins content, addins/<uid>/module/override for things for DLCs (where uid is the folder name of the specific DLC (I listed several of them in the Module Priority tutorial) instead of packages/core/override if a mod '''must''' use the override. The only mods that need to be done this way are compatibility files for various mods that might be editing the same files, at least as far as I'm concerned; everything else should be done as dazips. [[User:Ladydesire|Ladydesire]] 23:26, 6 January 2011 (UTC)
-------------
Just on the term "deprecated", this is really a technical term in software development and deployment, and does not carry a value judgement. It simply means a superseded method that should no longer be used. This is a developer not a player wiki, and the use of the term is entirely appropriate, imho --[[User:Gaxkang55|Gaxkang55]] 07:56, 8 January 2011 (UTC)
-------------
OK I had a go at rewording, to emphasise that it is the technique which is deprecated, not the mods. Only players have the power to deprecate (i.e. cease using and/or archive) mods, which I've reiterated in the form of a link to the Disclaimer section. What do you think?

@ladydesire : you might want to do an edit to capture your thoughts above. I don't disagree, but you know a lot more than I about how to mod the OC.
[[User:Proleric1|Proleric1]] 11:43, 8 January 2011 (UTC)
--------------
That edit looks fine to me.

On the separate issue of what should be in the core and what in the module folders of you <uid> folder, I am actually scheduled to do some testing on this very question for my own campaign (in dev), and will return to this issue for this page in a week or two --[[User:Gaxkang55|Gaxkang55]] 08:26, 10 January 2011 (UTC)

Talk:Follower tutorial

2011-01-10T08:19:53Z

Gaxkang55: /* Handling followers more robustly */

== Handling followers more robustly ==

Just a few things
* I don't think the described behaviour is a bug in [[UT_HireFollower]](). It's documented that "This function will do nothing for plot followers". It was never intended for use with normal followers, and the code even checks the object tag against the single player campaign's companions. It'll fail to check against your own module's custom followers, though, so it'll do something, but that something isn't always what you want either.

* Plot script gen00pt_party.nss and party_h have some plot-companion handling functions. I wouldn't really give it a short treatment at the bottom under "Advanced Follower Creation" if it's a solid approach. See things like Party_GetFollowerByTag in party_h with an interesting function and comment:
<dascript>
object Party_GetFollowerByTag(string sTag)
{
// We have to retrieve the follower like this. Trying to do it with
// GetObjectByTag proved to mess up lots of stuff. -- yaron.
object [] arParty = GetPartyPoolList();
int i;
int nSize = GetArraySize(arParty);
object oCurrent;
for(i = 0; i < nSize; i++)
{
oCurrent = arParty[i];
if(GetTag(oCurrent) == sTag)
return oCurrent;
}

return UT_GetNearestObjectByTag(GetMainControlled(), sTag, TRUE);
</dascript>

* It's probably worth going through those scripts and adapting them for general tutorial use. That way we can benefit from whatever gotchas have already been solved.

--[[User:FollowTheGourd|FollowTheGourd]] 17:52, 1 January 2011 (UTC)
-------------------
As the author of the "alternative approach" section, my own view is that this should effectively replace that whole section with the monstrous hire script, which really belongs in a how-I-did-it page rather than in a tutorial. However, I am currently up to my armpits in work on my own mod and just don't currently have the bandwidth to undertake the redraft. --[[User:Gaxkang55|Gaxkang55]] 04:10, 8 January 2011 (UTC)
-------------------
I have some sympathy with that. Indeed, I suspect that most of the additions could be integrated into one "best practice" approach. However, I hesitate to carve this up without some informed debate. I'll volunteer to redraft if a few people are willing to join a group discussion first. [[User:Proleric1|Proleric1]] 12:06, 8 January 2011 (UTC)
-------------------
Would be happy to be part of the discussion. Perhaps FollowTheGourd might join the party as well :-) --[[User:Gaxkang55|Gaxkang55]] 08:19, 10 January 2011 (UTC)

== ==

great tutorial. my only problem is: my companion, Erik has different skills and doesn't seem to follow his autolevel template. --[[User:Mono0x32440|Mono0x32440]] 17:46, 25 February 2010 (UTC)

== Follower's Portrait ==

I cannot figure out how to change the default grey backgrounded portrait for the new followers. It would be nice to have pose and background options.

== Dog equipment slots ==

Mention should be made of the fact that a dog follower needs to have the appropriate equipment slot mask. I will make the addition to the text if no-one has any objections/suggestions in a couple of days. --[[User:Gaxkang55|Gaxkang55]] 09:38, 21 October 2010 (UTC)

I don't think that happened, so I've done it now. [[User:Proleric1|Proleric1]] 10:12, 2 January 2011 (UTC)

Talk:Compatibility

2011-01-08T07:56:13Z

Gaxkang55: /* Resource scope edit */

Talk:Follower tutorial

2011-01-08T04:10:02Z

Gaxkang55: /* Handling followers more robustly */

== Handling followers more robustly ==

Just a few things
* I don't think the described behaviour is a bug in [[UT_HireFollower]](). It's documented that "This function will do nothing for plot followers". It was never intended for use with normal followers, and the code even checks the object tag against the single player campaign's companions. It'll fail to check against your own module's custom followers, though, so it'll do something, but that something isn't always what you want either.

* Plot script gen00pt_party.nss and party_h have some plot-companion handling functions. I wouldn't really give it a short treatment at the bottom under "Advanced Follower Creation" if it's a solid approach. See things like Party_GetFollowerByTag in party_h with an interesting function and comment:
<dascript>
object Party_GetFollowerByTag(string sTag)
{
// We have to retrieve the follower like this. Trying to do it with
// GetObjectByTag proved to mess up lots of stuff. -- yaron.
object [] arParty = GetPartyPoolList();
int i;
int nSize = GetArraySize(arParty);
object oCurrent;
for(i = 0; i < nSize; i++)
{
oCurrent = arParty[i];
if(GetTag(oCurrent) == sTag)
return oCurrent;
}

return UT_GetNearestObjectByTag(GetMainControlled(), sTag, TRUE);
</dascript>

* It's probably worth going through those scripts and adapting them for general tutorial use. That way we can benefit from whatever gotchas have already been solved.

--[[User:FollowTheGourd|FollowTheGourd]] 17:52, 1 January 2011 (UTC)

As the author of the "alternative approach" section, my own view is that this should effectively replace that whole section with the monstrous hire script, which really belongs in a how-I-did-it page rather than in a tutorial. However, I am currently up to my armpits in work on my own mod and just don't currently have the bandwidth to undertake the redraft. --[[User:Gaxkang55|Gaxkang55]] 04:10, 8 January 2011 (UTC)

== ==

great tutorial. my only problem is: my companion, Erik has different skills and doesn't seem to follow his autolevel template. --[[User:Mono0x32440|Mono0x32440]] 17:46, 25 February 2010 (UTC)

== Follower's Portrait ==

I cannot figure out how to change the default grey backgrounded portrait for the new followers. It would be nice to have pose and background options.

== Dog equipment slots ==

Mention should be made of the fact that a dog follower needs to have the appropriate equipment slot mask. I will make the addition to the text if no-one has any objections/suggestions in a couple of days. --[[User:Gaxkang55|Gaxkang55]] 09:38, 21 October 2010 (UTC)

I don't think that happened, so I've done it now. [[User:Proleric1|Proleric1]] 10:12, 2 January 2011 (UTC)

Talk:Compatibility

2011-01-04T04:37:52Z

Gaxkang55: /* Resource scope edit */

== What if my mod extends both Single Player and Awakening? ==

I moved this section here because it's under discussion. [[User:Proleric1|Proleric1]] 08:27, 21 July 2010 (UTC)

===============
NOTE:

There is an easier way than creating two scripts. Just put the information for both in the manifest.xml file. For one of my mods, the manifest file looked like this:

<pre>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Manifest Type="AddIn">
<AddInsList>
<AddInItem UID="elf_cat_pet" Name="ELF the pet cat for DAO and Awakening" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1">
<Title DefaultText="ELF the pet cat for DAO and Awakening"></Title>
<Description DefaultText="ELF the pet cat adds a 'Cat Toy' to the players inventory (rest of text deleted for brevity)

((This package will work in both DAO and Awakening!))"></Description>
<Image>ico_elf_cat_sleep</Image>
<Rating DefaultText="10"></Rating>
<RatingDescription DefaultText=""></RatingDescription>
<URL DefaultText="www.ELFpath.com"></URL>
<ReleaseDate>6 April 2010</ReleaseDate>
<Version>2.0</Version>
<GameVersion/>
<Type>1</Type>
<Publisher DefaultText="Angel == monkeysnest@yahoo.com"></Publisher>
<PrereqList/>
<FileList>
<Folder src="packages/" Type="package"/>
<Folder src="addins/" Type="addin"/>
</FileList>
</AddInItem>

<AddInItem UID="elf_cat_pet" Name="ELF the pet cat for DAO and Awakening" ExtendedModuleUID="DAO_PRC_EP_1" Priority="100" Enabled="1" State="2" Format="1">
<Title DefaultText="ELF the pet cat"></Title>
<Image>ico_elf_cat_sleep</Image>
<Rating DefaultText=""></Rating>
<RatingDescription DefaultText=""></RatingDescription>
<URL DefaultText="www.ELFpath.com"></URL>
<ReleaseDate>6 April 2010</ReleaseDate>
<Version>2.0</Version>
<GameVersion/>
<Type>1</Type>
<Publisher DefaultText="Angel == monkeysnest@yahoo.com"></Publisher>
<PrereqList/>
<FileList>
<Folder src="addins/" Type="addin"/>
</FileList>
</AddInItem>

</AddInsList>
</Manifest>
</pre>

doing this allowed users to install one package (using DAModder) which worked for both awakening and DAO.

============== ++ Angel

@monkeysnest - good to have the update concerning the manifest. A few queries:

* Perhaps the article would be clearer if you explained which line has to change, rather than reproduce the entire manifest here?

* Would DAUpdater work? I don't see DAModder listed as a project download on the Bioware social site.

* We don't normally leave our signatures on the content pages of a wiki.

Thanks.

[[User:Proleric1|Proleric1]] 05:47, 8 April 2010 (UTC)

I don't think the "dual entry, single manifest" approach should be followed or encouraged. Creating two separate .dazip installations as mentioned in [[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | Compatibility: What if my mod extends both Single Player and Awakening?]] is IMHO the preferred approach.

--[[User:Nukenin|Nukenin]] 00:24, 24 April 2010 (UTC)

I'll have to agree with Nukenin here, especially since using the "dual entry, single manifest" approach will cause DAUpdater to crash and would unnecessarily force players to use third-party apps. Moreover, it's perfectly possible to include several addons (each one with its own manifest entry) in a single dazip package :
* Package root
** Manifest including several AddInItem elements
** Contents
*** addins
**** addin_uid1
**** addin_uid2
**** addin_uid3
**** etc
*** packages

--[[User:Phaenan|Phaenan]] 06:45, 21 July 2010 (UTC)

I find myself agreeing with Phaenan and Nukenin on this; end users should only use community created tools if they want a specific function that's only available to them that way (like the ability to uninstall a dazip).
[[User:Ladydesire|Ladydesire]] 18:40, 25 December 2010 (UTC)

== Override Events while minimizing compat issues.. ==

I believe this may be useful to others - through trial and error, and with some help, I have figured out a way to override events only when my module is running - I had to add a variable to var_module.xls/gda (which is probably where the only potential compatibility issue will arise via string ID, though I am not sure what would happen if someone tried to override the same events - depends on which engineevents get's loaded last I suppose...).

The variable is defaulted to a 0....in my modules properties, I set the variable to a 1. My event overrides check for this variable to be == 1, if not, send it off the proper handler.

See the following post where I came to this 'workaround'...would love to know if there is a better way:

http://social.bioware.com/forum/1/topic/8/index/2371093/1#2531362

== Resource scope edit ==

I have removed the reference to tint maps following the discussion at http://social.bioware.com/group/2937/discussion/12738/ .

Also beefed up the recommendations about not putting files into packages --[[User:Gaxkang55|Gaxkang55]] 12:43, 30 December 2010 (UTC)

Good update! I'm very much on the same wavelength. I have one question, though, concerning the Talk Table. Normally, the best way to change a core string is to make a new one, then point the appropriate 2DA at it. However, there are cases where no such mechanism exists. For example, if you want to make a module that isn't set in the Ferelden gameworld, you need to change the gender descriptions, replace all instances of "marabi" with "dog" and so on. To the best of my knowledge, this can't be done without an override - see [[String_editor]]. If there's a better solution, I'd be keen to hear it. [[User:Proleric1|Proleric1]] 08:50, 31 December 2010 (UTC)

As it happens, I had to do exactly that for the campaign I have in development, where I wanted to override the gender description. Create the string but make the Owner Module your module. This will be exported to the talktable placed in your core, and will overwrite the core string as long as your module is enabled. Also tested the head morph stuff, and that doesn't need to be in packages either, so will make a further update. --[[User:Gaxkang55|Gaxkang55]] 04:28, 3 January 2011 (UTC)

Have you tried to reproduce this [[Bug:_Talk_table_exported_to_packages_override | bug]] for the specific string mentioned there? I double-checked that the Owner Module is set correctly. It isn't exported to the talk table in core (which seems to be empty), nor does it work if the talk table in packages override is moved to any of the add-in folders.

A couple of other issues:

You recommend moving content from the override folders before B2P packaging. Is there any technical reason for that? I haven't heard this from Bioware. "If it ain't bust, don't fix it" might apply here?

You've added some strong words about mods that use packages override. My heart is with you, but my head says the tone could be counter-productive. We seem to be making some progress with persuading the community that compatibility is important, but the "package overriders" are still in the majority. IMO we need to convince them to change their approach voluntarily, not antagonise them. After all, none of us has the power to deprecate anything (nor would we wish to have it). What do you think? [[User:Proleric1|Proleric1]] 08:27, 3 January 2011 (UTC)

Moving the compiled scripts and exported plots out of the toolsetexport folder '''into''' the override folder is a good idea, since when doing an "empty export directories", you could accidently delete files needed for the builder to player package. I'm not sure why it would be necessary to move files out of the override folder.

As far as the "package overriders" go, some may never change, no matter what we do; I have even seen people that were doing it basically the right way change because they weren't wanting to build multiple packages for their mods. [[User:Ladydesire|Ladydesire]] 00:03, 4 January 2011 (UTC)

1. I have deleted the sentence about DAZIPs. On re-reading it actually compresses together two different ideas, and in any case doesn't really belong there. I will have a rethink about this when I have a bit more time on the weekend :-)

2. Proleric, the string I override is the gender description string 377283. I export the talktable (which creates the three files) and delete the one in packages, ''core_en-us.tlk'', together with everything else there). Start my game and the string in overwritten correctly by the ''<uid>_c_en-us.tlk'' table.

3. On the issue of packages override, the issue is whether or not this wiki contains correct information and procedures. If someone disagrees that this is the correct procedure (particularly in terms of mod inter-compatibility), I am more than happy to have the discussion. I suspect real change is only going to happen if the end-users start complaining in the comments sections of the download pages, but that's another story. In the meantime, the wiki should stick to the straight and narrow of providing the best information we can assemble --[[User:Gaxkang55|Gaxkang55]] 04:37, 4 January 2011 (UTC)

Compatibility

2011-01-04T04:08:32Z

Gaxkang55: /* Resource Scope */ deleted sentence pending further discussion

DAO has an active modding community. Over time, players will accumulate many new campaigns and game mods. So, as a courtesy to players and other builders, it's helpful to try to make our mods mutually compatible.

From time to time, Bioware may well issue new releases, so it's good to reduce the risk of conflict in that respect, too.

Since we can't be sure that all authors will respect compatibility considerations, the emphasis here is on techniques that reduce the risk of conflict, regardless of what other people do (though not all are foolproof).

Obviously, there are some conflicts with no win-win (hurlocks can't be both green and purple at the same time), but that doesn't stop us trying to avoid unnecessary win-lose or corruption.

We begin with a concrete example - a tutorial on script conflict in OC mods, which is one of the most common problems to avoid. The remainder of the page is a more systematic discussion, which applies to both OC mods and custom campaigns.

== Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) ==

I'm hoping to save my modding friends some time. (Tutorial by Immortality)

'''Remember: IT'S YOUR RESPONSIBILITY TO ENSURE YOUR MOD DOES NOT BREAK THE GAME, THE EXPANSION, DLCS, OR OTHER MODS!!'''

'''''The problem:'''''

- While working in my Origins mod, and then on my Awakening mod, I realized that my Origins mod was breaking Awakening (scripts were not triggering, and even objects were moving around!).

- In the same way, my mod for Awakening was interfeering in Origins, breaking it (wrong scripts triggering, destroying the party recruiting).

'''''The objective:'''''

- Prevent the Origins mod to interfere with Awakening. If your mod is for Origins, it should only work in Origins.

- Prevent the Awakening mod to interfere with Origins. If your mod is for Awakening, it should only work in Awakening.

- If you have one mod for both, to ensure that the Origins part triggers in Origins and Awakening part in Awakening.

'''''Procedure:'''''

'''1- Ensure your Origins mod is for Origins only!'''

NEVER EVER EVER set your core scripts or handling scripts as Core Game Resources. NEVER!

There's absolutely no need for your scripts (especially your module core) to be a core game resource.

This means that whenever you create a mod for origins you should always set the properties of your major handling scripts as "Module: your module", and "Owner Module: your module". NEVER as a core game resource. Otherwise they will interfere with awakening and will break it (make no mistake, they will).

Example:

This is how you set your Origins module: [[image:Originshierarchy.jpg]]

This is how you set all your script's properties: [[image:Originsproperties.jpg]]

'''2- Ensure your Awakening mod is for Awakening only!'''

Things are different for Awakening because you DO have to set all your materials' properties as "Module: Core Game Resources", and "Owner Module: your module". (read the tutorial if you need to know more: http://social.bioware.com/53295/blog/10858/ )

This means that your Awakening mod will interfere with Origins and will break the game.

Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred method of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.

'''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!

In order to avoid this, you can rename your functions.
For example, if your Origins script has the function "SetFollowerInParty", then rename the function in your Awakening script to "SetFollowerInParty_awakening", and etc.

== Disable Add-Ins : Suggested Disclaimer ==

If the player disables all other add-ins on the in game DLC screen, no conflict should occur between them. Tedious, but effective.

This should rarely be necessary if the compatibility guidelines listed here are observed.

Exception : there is a [[Bug:_export_creates_unnecessary_core_override | toolset bug]] which produces content that persists in game, even when the add-in is disabled, unless the builder cleans it out before making the Builder-to-Player file. The same problem can occur if a builder has intentionally placed content in the packages\override folder (which should normally be avoided, as it is very rarely necessary).

Mod authors can work together to set player expectations in this respect. For example, the installation instructions might say

<dascript>Reasonable steps have been taken to make this mod compatible.
Obviously, the author has no control over the quality of other mods you may have installed.
So, to reduce the risk of conflict, you are are strongly advised to move all files out of your
packages\override folders, and consider disabling unnecessary community mods on your in-game
DLC screen, before playing.</dascript>

== Module Scope ==

Setting the Extended Module in Module properties to "Core Game Resources" means that the add-in will change every campaign in game. If that's not intended, select the campaign you're trying to extend e.g. Single Player for the official campaign, (None) for a new standalone campaign.

[[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | What if my mod extends both Single Player and Awakening?]]

== Resource Scope ==

By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.

Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled. There are currently no resources known which need to be in the packages folder in order to work.

Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder. Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.

Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Most of those resources can, and should be, moved to the module folder and still work. The only exceptions are resources intended to overwrite a core game resouce.

There are a large number of mods available that use the packages folder, creating headaches for other modders and often users since such overwrites cannot be turned off in the game GUI. Users should be told to avoid mods whose method of installation is "place this folder in packages\override" and to delete any content that is currently in that folder. Mods not properly organised into dazips and installed with the Bioware supplied daupdater should also be deprecated, unless a good reason is given why they are being distributed that way.

== Resource Conflict ==

Resource names need to be unique within type. For example, genpt_party.plt and genpt_party.nss are different resources, becasue the type is different. However, if two modules both have resources called genpt_party.plt, only one will load in game, following the [[Source directory priorities]].

Within the toolset database, duplicate resource names are forbidden, but there's nothing to stop different builders making resources which accidentally conflict, so it's wise to choose a unique range of names. Each builder can register the prefix they require. See [[Naming_conventions#Resource_Naming_Convention | Resource Naming Convention]] and especially [[Prefixes in use]].

It is possible to override a core resource intentionally, by editing a copy, exporting it, and renaming it in the export folder to the same name as the original. However, almost invariably there is a cleaner way of doing this - for example, by changing the 2DA which identifies which resource to use.

== Existing Content Modification ==

When adding new content or content hooks to existing areas, do not modify the area directly and deploy the modified area as an override with your mod. This is incompatible with other mods trying to edit the same area since only one modified version of the area will "win", and changes made by other mods to that area will not be available. Instead, use the [[PRCSCR]] system to add new content to existing areas.

== 2DA Conflict ==

Conflict between 2DA mods can be reduced using the [[2DA#Extending_the_game_via_M2DAs | M2DA]] mechanism and [[2DA#Reserved_ID_Ranges_and_overriding_existing_rows | reserving ID ranges]].

2DA mods should normally be placed in the add-in's module folder. Exception : if they are meant to be universally applied to all campaigns, they should be in the addin/core/override folder. The packages override folder should normally be avoided (because that removes control from the player, by forcing the 2DA to load even if the player has disabled the add-in).

== String Conflict ==

When a new module is created, its properties include a [[String ID]] range which starts at a very large random number. This makes it very unlikely that text created by one add-in will override another.

See [[String ID]] main article for a discussion of how this impacts sharing between Builders.

The [[String editor]] article discusses techniques for editing strings which are outside of the module's normal range. It is not normally necessary to customise core strings directly, but if there is no alternative, change the Owner Module to the current module, and the Table to the current module's talk table. Otherwise, the custom string will override all campaigns.

== Event Handling Conflict ==

Bear in mind that an add-in which impacts all campaigns could have undesirable consequences if it changes scripts or event-handling, given that custom campaigns may well have made changes of their own. If in doubt, consider modding the Single Player campaign only.

See [[Event_override | event override]] for recommended methods of intercepting events.

Note that script resources are never overwritten in these methods. Conceptually, the event is intercepted by a custom script, then passed on (unless the event has been handled successfully and further processing would be harmful). In this way, mods try not to interfere unnecessarily with other scripts.

Given the variety of actions that can be taken in a script, and that fact that one mod can't know what other mods are trying to do, we can't guarantee that this approach will be entirely free of logical problems, but the Perfect is the enemy of the Good.

The simplest and safest method is to assign a custom event script to a resource. This is likely to be used by custom campaigns, and also by Single Player mods to specific resources, as it is the approach that Bioware devs have often recommended.

Mods which aim to impact all campaigns globally are better advised to use the second method, i.e. overriding [[Event_(dascript_type) | event]] handling using an Events M2DA. As illustrated in the example script, if possible the event should be passed on to the default handler of the event's target object (which might be a custom event script). In this way, a global mod can be compatible with custom campaigns and specific resource mods.

Unfortunately, if two mods simply try to override the same event with an M2DA, they will be incompatible.

The best solution to override, partially override, or just listen for events via M2DA at this point would be to use a system such as [http://social.bioware.com/project/1907/#details Event Manager], though to ensure compatibility all modules overriding or listening for events should also be using the same system.

In the case of modules trying to totally override an event, only one module that does so will ultimately "win" (no such modules can ever truly be compatible with one another short of merging their functionality into one unified module as possible), but utilizing a system such as Event Manager will allow modules to partially override an event (i.e. only handle the event in certain situations), and will allow any module to listen for an event (without handling it) before or after the event is handled.

== Plot Property ==

Scripts that impact all campaigns should respect the plot property on resources. For example, if a campaign author has flagged an NPC as plot, it might not be helpful to change the creature AI.

== Open Source ==

If mod authors choose to publish their source code, with no restrictions on re-deployment, other builders can work around any residual incompatibilities (either by understanding the conflict more clearly, or by integrating the mod into their own work).

This technical wiki is not the place to discuss any legal or ethical considerations.

== FAQ ==

=== What if my mod extends both Single Player and Awakening? ===

Just create two dazips for your module. Name one yourprefix_yourmodule_version and the other yourprefix_yourmodule_EP1_version.

Edit the Manifest.xml file inside yourprefix_yourmodule_EP_1_version.dazip.
Change the line

<AddInItem UID="yourprefix_yourmodule" Name="Your Module Name" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1"> to

<AddInItem UID="yourprefix_yourmodule_EP_1" Name="Your Module Name" ExtendedModuleUID="DAO_PRC_EP_1" Priority="200" Enabled="1" State="2" Format="1">

See also [[Talk:Compatibility | Discussion]]

=== How can I import an item with my existing character to a new campaign? ===

The Awakening expansion allows an existing character to be imported from one campaign to another.

There are two methods of ensuring that an item in the player's inventory is imported successfully:

* Make the item a core resource
* Include the item template in separate add-ins to both campaigns (see Awakening example above)

=== How can I stop items being imported into my campaign? ===

Assuming your campaign allows existing characters to be imported during Character Generation, you might want to clear the player's inventory before adding your starting equipment. Imported equipment might upset the balance of your campaign.

If you decide to do this, it's a good idea to warn players, so that they understand what's happening.

Compatibility

2011-01-03T04:40:51Z

Gaxkang55: /* Resource Scope */

DAO has an active modding community. Over time, players will accumulate many new campaigns and game mods. So, as a courtesy to players and other builders, it's helpful to try to make our mods mutually compatible.

From time to time, Bioware may well issue new releases, so it's good to reduce the risk of conflict in that respect, too.

Since we can't be sure that all authors will respect compatibility considerations, the emphasis here is on techniques that reduce the risk of conflict, regardless of what other people do (though not all are foolproof).

Obviously, there are some conflicts with no win-win (hurlocks can't be both green and purple at the same time), but that doesn't stop us trying to avoid unnecessary win-lose or corruption.

We begin with a concrete example - a tutorial on script conflict in OC mods, which is one of the most common problems to avoid. The remainder of the page is a more systematic discussion, which applies to both OC mods and custom campaigns.

== Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) ==

I'm hoping to save my modding friends some time. (Tutorial by Immortality)

'''Remember: IT'S YOUR RESPONSIBILITY TO ENSURE YOUR MOD DOES NOT BREAK THE GAME, THE EXPANSION, DLCS, OR OTHER MODS!!'''

'''''The problem:'''''

- While working in my Origins mod, and then on my Awakening mod, I realized that my Origins mod was breaking Awakening (scripts were not triggering, and even objects were moving around!).

- In the same way, my mod for Awakening was interfeering in Origins, breaking it (wrong scripts triggering, destroying the party recruiting).

'''''The objective:'''''

- Prevent the Origins mod to interfere with Awakening. If your mod is for Origins, it should only work in Origins.

- Prevent the Awakening mod to interfere with Origins. If your mod is for Awakening, it should only work in Awakening.

- If you have one mod for both, to ensure that the Origins part triggers in Origins and Awakening part in Awakening.

'''''Procedure:'''''

'''1- Ensure your Origins mod is for Origins only!'''

NEVER EVER EVER set your core scripts or handling scripts as Core Game Resources. NEVER!

There's absolutely no need for your scripts (especially your module core) to be a core game resource.

This means that whenever you create a mod for origins you should always set the properties of your major handling scripts as "Module: your module", and "Owner Module: your module". NEVER as a core game resource. Otherwise they will interfere with awakening and will break it (make no mistake, they will).

Example:

This is how you set your Origins module: [[image:Originshierarchy.jpg]]

This is how you set all your script's properties: [[image:Originsproperties.jpg]]

'''2- Ensure your Awakening mod is for Awakening only!'''

Things are different for Awakening because you DO have to set all your materials' properties as "Module: Core Game Resources", and "Owner Module: your module". (read the tutorial if you need to know more: http://social.bioware.com/53295/blog/10858/ )

This means that your Awakening mod will interfere with Origins and will break the game.

Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred method of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.

'''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!

In order to avoid this, you can rename your functions.
For example, if your Origins script has the function "SetFollowerInParty", then rename the function in your Awakening script to "SetFollowerInParty_awakening", and etc.

== Disable Add-Ins : Suggested Disclaimer ==

If the player disables all other add-ins on the in game DLC screen, no conflict should occur between them. Tedious, but effective.

This should rarely be necessary if the compatibility guidelines listed here are observed.

Exception : there is a [[Bug:_export_creates_unnecessary_core_override | toolset bug]] which produces content that persists in game, even when the add-in is disabled, unless the builder cleans it out before making the Builder-to-Player file. The same problem can occur if a builder has intentionally placed content in the packages\override folder (which should normally be avoided, as it is very rarely necessary).

Mod authors can work together to set player expectations in this respect. For example, the installation instructions might say

<dascript>Reasonable steps have been taken to make this mod compatible.
Obviously, the author has no control over the quality of other mods you may have installed.
So, to reduce the risk of conflict, you are are strongly advised to move all files out of your
packages\override folders, and consider disabling unnecessary community mods on your in-game
DLC screen, before playing.</dascript>

== Module Scope ==

Setting the Extended Module in Module properties to "Core Game Resources" means that the add-in will change every campaign in game. If that's not intended, select the campaign you're trying to extend e.g. Single Player for the official campaign, (None) for a new standalone campaign.

[[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | What if my mod extends both Single Player and Awakening?]]

== Resource Scope ==

By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.

When creating the player DAZIP, these resources should be taken out of override and put in the appropriate subfolders in your module folder. The module's override folders should only be used for changes and bug fixes, ie for overriding your own module after it has been distributed and installed.

Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled. There are currently no resources known which need to be in the packages folder in order to work.

Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder. Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.

Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Most of those resources can, and should be, moved to the module folder and still work. The only exceptions are resources intended to overwrite a core game resouce.

There are a large number of mods available that use the packages folder, creating headaches for other modders and often users since such overwrites cannot be turned off in the game GUI. Users should be told to avoid mods whose method of installation is "place this folder in packages\override" and to delete any content that is currently in that folder. Mods not properly organised into dazips and installed with the Bioware supplied daupdater should also be deprecated, unless a good reason is given why they are being distributed that way.

== Resource Conflict ==

Resource names need to be unique within type. For example, genpt_party.plt and genpt_party.nss are different resources, becasue the type is different. However, if two modules both have resources called genpt_party.plt, only one will load in game, following the [[Source directory priorities]].

Within the toolset database, duplicate resource names are forbidden, but there's nothing to stop different builders making resources which accidentally conflict, so it's wise to choose a unique range of names. Each builder can register the prefix they require. See [[Naming_conventions#Resource_Naming_Convention | Resource Naming Convention]] and especially [[Prefixes in use]].

It is possible to override a core resource intentionally, by editing a copy, exporting it, and renaming it in the export folder to the same name as the original. However, almost invariably there is a cleaner way of doing this - for example, by changing the 2DA which identifies which resource to use.

== Existing Content Modification ==

When adding new content or content hooks to existing areas, do not modify the area directly and deploy the modified area as an override with your mod. This is incompatible with other mods trying to edit the same area since only one modified version of the area will "win", and changes made by other mods to that area will not be available. Instead, use the [[PRCSCR]] system to add new content to existing areas.

== 2DA Conflict ==

Conflict between 2DA mods can be reduced using the [[2DA#Extending_the_game_via_M2DAs | M2DA]] mechanism and [[2DA#Reserved_ID_Ranges_and_overriding_existing_rows | reserving ID ranges]].

2DA mods should normally be placed in the add-in's module folder. Exception : if they are meant to be universally applied to all campaigns, they should be in the addin/core/override folder. The packages override folder should normally be avoided (because that removes control from the player, by forcing the 2DA to load even if the player has disabled the add-in).

== String Conflict ==

When a new module is created, its properties include a [[String ID]] range which starts at a very large random number. This makes it very unlikely that text created by one add-in will override another.

See [[String ID]] main article for a discussion of how this impacts sharing between Builders.

The [[String editor]] article discusses techniques for editing strings which are outside of the module's normal range. It is not normally necessary to customise core strings directly, but if there is no alternative, change the Owner Module to the current module, and the Table to the current module's talk table. Otherwise, the custom string will override all campaigns.

== Event Handling Conflict ==

Bear in mind that an add-in which impacts all campaigns could have undesirable consequences if it changes scripts or event-handling, given that custom campaigns may well have made changes of their own. If in doubt, consider modding the Single Player campaign only.

See [[Event_override | event override]] for recommended methods of intercepting events.

Note that script resources are never overwritten in these methods. Conceptually, the event is intercepted by a custom script, then passed on (unless the event has been handled successfully and further processing would be harmful). In this way, mods try not to interfere unnecessarily with other scripts.

Given the variety of actions that can be taken in a script, and that fact that one mod can't know what other mods are trying to do, we can't guarantee that this approach will be entirely free of logical problems, but the Perfect is the enemy of the Good.

The simplest and safest method is to assign a custom event script to a resource. This is likely to be used by custom campaigns, and also by Single Player mods to specific resources, as it is the approach that Bioware devs have often recommended.

Mods which aim to impact all campaigns globally are better advised to use the second method, i.e. overriding [[Event_(dascript_type) | event]] handling using an Events M2DA. As illustrated in the example script, if possible the event should be passed on to the default handler of the event's target object (which might be a custom event script). In this way, a global mod can be compatible with custom campaigns and specific resource mods.

Unfortunately, if two mods simply try to override the same event with an M2DA, they will be incompatible.

The best solution to override, partially override, or just listen for events via M2DA at this point would be to use a system such as [http://social.bioware.com/project/1907/#details Event Manager], though to ensure compatibility all modules overriding or listening for events should also be using the same system.

In the case of modules trying to totally override an event, only one module that does so will ultimately "win" (no such modules can ever truly be compatible with one another short of merging their functionality into one unified module as possible), but utilizing a system such as Event Manager will allow modules to partially override an event (i.e. only handle the event in certain situations), and will allow any module to listen for an event (without handling it) before or after the event is handled.

== Plot Property ==

Scripts that impact all campaigns should respect the plot property on resources. For example, if a campaign author has flagged an NPC as plot, it might not be helpful to change the creature AI.

== Open Source ==

If mod authors choose to publish their source code, with no restrictions on re-deployment, other builders can work around any residual incompatibilities (either by understanding the conflict more clearly, or by integrating the mod into their own work).

This technical wiki is not the place to discuss any legal or ethical considerations.

== FAQ ==

=== What if my mod extends both Single Player and Awakening? ===

Just create two dazips for your module. Name one yourprefix_yourmodule_version and the other yourprefix_yourmodule_EP1_version.

Edit the Manifest.xml file inside yourprefix_yourmodule_EP_1_version.dazip.
Change the line

<AddInItem UID="yourprefix_yourmodule" Name="Your Module Name" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1"> to

<AddInItem UID="yourprefix_yourmodule_EP_1" Name="Your Module Name" ExtendedModuleUID="DAO_PRC_EP_1" Priority="200" Enabled="1" State="2" Format="1">

See also [[Talk:Compatibility | Discussion]]

=== How can I import an item with my existing character to a new campaign? ===

The Awakening expansion allows an existing character to be imported from one campaign to another.

There are two methods of ensuring that an item in the player's inventory is imported successfully:

* Make the item a core resource
* Include the item template in separate add-ins to both campaigns (see Awakening example above)

=== How can I stop items being imported into my campaign? ===

Assuming your campaign allows existing characters to be imported during Character Generation, you might want to clear the player's inventory before adding your starting equipment. Imported equipment might upset the balance of your campaign.

If you decide to do this, it's a good idea to warn players, so that they understand what's happening.

Talk:Compatibility

2011-01-03T04:28:16Z

Gaxkang55: /* Resource scope edit */

Bug: Toolset loses M2DA dropdown selection, resets to default

2010-12-30T17:31:16Z

Gaxkang55:

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

== Description ==
The toolset will from time to time report it can no longer find name of ... , referring to a selection defined in a M2DA and previously selected, saved and exported. On the next export in which the affected object is also exported as a dependent resource, it will have reverted to whatever the default is in the main 2DA. This has affected new placeables, appearances, tints and tint overrides, and alternative variable tables that I have noticed so far, but the spread indicates any M2DA can be effected. The bug is particularly toxic because several hundred exports may occur when, for instance, an area is exported and the warning is then very easy to miss. Needless to say, the effects can be quite drastic ingame, with placeables disappearing, tints non-existent, scripts unable to get variables, etc, and of course it is not always clear what the source of perceived problem is, since the damage may have been done many days before ingame testing discovers there is a problem. The phenomenon is random, and varies in frequency to several times an hour for a particular table to no problems for days on end for the same table.

== Workarounds ==
Once discovered, closing and reopening the toolset will set the correct option without further intervention, and the object can be re-exported successfully. In general, keeping a weather eye on the log is a good idea, since the toolset will repeatedly complain whenever anything affecting the damaged resource is worked on, eg when scripts are compiled that reference the resource. If you see such a warning, call up the object and verify it has reverted to default for relevant field. Close the toolset immediately, and on reopening export the resource.

[[Category:Toolset bugs]]

Bug: Toolset loses M2DA dropdown selection, resets to default

2010-12-30T17:29:37Z

Gaxkang55: Created page with '*'''Version found:''' 1.0.1008.0 *'''Status:''' Open == Description == <!-- Describe the bug here including as many details a...'

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

== Description ==
The toolset will from time to time report it can no longer find name of ... , referring to a selection defined in a M2DA and previously selected, saved and exported. On the next export in which the affected object is also exported as a dependent resource, it will have reverted to whatever the default is in the main 2DA. This has affected new placeables, appearances, tints and tint overrides, and alternative variable tables that I have noticed so far, but the spread indicates any M2DA can be effected. The bug is particularly toxic because several hundred exports may occur when, for instance, and area is exported and the warning is then very easy to miss. Needless to say, the effects can be quite drastic ingame, with placeable disappearing, tints non-existent, scripts unable to get variables, etc, and of course it is not always clear what the source of perceived problem is, since the damage may have been done many days before ingame testing discovers there is a problem. The phenomenon is random, and varies in frequency to several times an hour for a particular table to no problems for days on end for the same table.

== Workarounds ==
Once discovered, closing and reopening the toolset will set the correct option without further intervention, and the object can be re-exported successfully. In general, keeping a weather eye on the log is a good idea, since the toolset will repeatedly complain whenever anything affecting the damaged resource is worked on, eg when scripts are compiled that reference the resource. If you see such a warning, call up the object and verify it has reverted to default for relevant field. Close the toolset immediately, and on reopening export the resource.

[[Category:Toolset bugs]]

Compatibility

2010-12-30T12:57:14Z

Gaxkang55: /* Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) */

DAO has an active modding community. Over time, players will accumulate many new campaigns and game mods. So, as a courtesy to players and other builders, it's helpful to try to make our mods mutually compatible.

From time to time, Bioware may well issue new releases, so it's good to reduce the risk of conflict in that respect, too.

Since we can't be sure that all authors will respect compatibility considerations, the emphasis here is on techniques that reduce the risk of conflict, regardless of what other people do (though not all are foolproof).

Obviously, there are some conflicts with no win-win (hurlocks can't be both green and purple at the same time), but that doesn't stop us trying to avoid unnecessary win-lose or corruption.

We begin with a concrete example - a tutorial on script conflict in OC mods, which is one of the most common problems to avoid. The remainder of the page is a more systematic discussion, which applies to both OC mods and custom campaigns.

== Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) ==

I'm hoping to save my modding friends some time. (Tutorial by Immortality)

'''Remember: IT'S YOUR RESPONSIBILITY TO ENSURE YOUR MOD DOES NOT BREAK THE GAME, THE EXPANSION, DLCS, OR OTHER MODS!!'''

'''''The problem:'''''

- While working in my Origins mod, and then on my Awakening mod, I realized that my Origins mod was breaking Awakening (scripts were not triggering, and even objects were moving around!).

- In the same way, my mod for Awakening was interfeering in Origins, breaking it (wrong scripts triggering, destroying the party recruiting).

'''''The objective:'''''

- Prevent the Origins mod to interfere with Awakening. If your mod is for Origins, it should only work in Origins.

- Prevent the Awakening mod to interfere with Origins. If your mod is for Awakening, it should only work in Awakening.

- If you have one mod for both, to ensure that the Origins part triggers in Origins and Awakening part in Awakening.

'''''Procedure:'''''

'''1- Ensure your Origins mod is for Origins only!'''

NEVER EVER EVER set your core scripts or handling scripts as Core Game Resources. NEVER!

There's absolutely no need for your scripts (especially your module core) to be a core game resource.

This means that whenever you create a mod for origins you should always set the properties of your major handling scripts as "Module: your module", and "Owner Module: your module". NEVER as a core game resource. Otherwise they will interfere with awakening and will break it (make no mistake, they will).

Example:

This is how you set your Origins module: [[image:Originshierarchy.jpg]]

This is how you set all your script's properties: [[image:Originsproperties.jpg]]

'''2- Ensure your Awakening mod is for Awakening only!'''

Things are different for Awakening because you DO have to set all your materials' properties as "Module: Core Game Resources", and "Owner Module: your module". (read the tutorial if you need to know more: http://social.bioware.com/53295/blog/10858/ )

This means that your Awakening mod will interfere with Origins and will break the game.

Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred method of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.

'''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!

In order to avoid this, you can rename your functions.
For example, if your Origins script has the function "SetFollowerInParty", then rename the function in your Awakening script to "SetFollowerInParty_awakening", and etc.

== Disable Add-Ins : Suggested Disclaimer ==

If the player disables all other add-ins on the in game DLC screen, no conflict should occur between them. Tedious, but effective.

This should rarely be necessary if the compatibility guidelines listed here are observed.

Exception : there is a [[Bug:_export_creates_unnecessary_core_override | toolset bug]] which produces content that persists in game, even when the add-in is disabled, unless the builder cleans it out before making the Builder-to-Player file. The same problem can occur if a builder has intentionally placed content in the packages\override folder (which should normally be avoided, as it is very rarely necessary).

Mod authors can work together to set player expectations in this respect. For example, the installation instructions might say

<dascript>Reasonable steps have been taken to make this mod compatible.
Obviously, the author has no control over the quality of other mods you may have installed.
So, to reduce the risk of conflict, you are are strongly advised to move all files out of your
packages\override folders, and consider disabling unnecessary community mods on your in-game
DLC screen, before playing.</dascript>

== Module Scope ==

Setting the Extended Module in Module properties to "Core Game Resources" means that the add-in will change every campaign in game. If that's not intended, select the campaign you're trying to extend e.g. Single Player for the official campaign, (None) for a new standalone campaign.

[[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | What if my mod extends both Single Player and Awakening?]]

== Resource Scope ==

By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.

Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled.

It appears the packages folder has to be used for resources that won't load from the addins folder, namely

* The Talk Table (see [[Bug:_Talk_table_exported_to_packages_override | bug]]) that overrides existing game strings. Best practice is to avoid doing this in the first place.
* The chargenmorphcfg.xml file, which can be used to add new morph presets for character generation.

It was reported that tint maps needed to be in packages, but this was based on a misunderstanding.

Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder.

Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.

Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Many of those resources can in any case be moved to the module folder and still work.

There are a large number of mods available that use the packages folder, creating headaches for other modders and often users since such overwrites cannot be turned off in the game GUI. Users should be told to avoid mods whose method of installation is "place this folder in packages\override" and to delete any content that is currently in that folder. Mods not properly organised into dazips and installed with the Bioware supplied daupdater should also be deprecated, unless a good reason is given why they are being distributed that way.

== Resource Conflict ==

Resource names need to be unique within type. For example, genpt_party.plt and genpt_party.nss are different resources, becasue the type is different. However, if two modules both have resources called genpt_party.plt, only one will load in game, following the [[Source directory priorities]].

Within the toolset database, duplicate resource names are forbidden, but there's nothing to stop different builders making resources which accidentally conflict, so it's wise to choose a unique range of names. Each builder can register the prefix they require. See [[Naming_conventions#Resource_Naming_Convention | Resource Naming Convention]] and especially [[Prefixes in use]].

It is possible to override a core resource intentionally, by editing a copy, exporting it, and renaming it in the export folder to the same name as the original. However, almost invariably there is a cleaner way of doing this - for example, by changing the 2DA which identifies which resource to use.

== Existing Content Modification ==

When adding new content or content hooks to existing areas, do not modify the area directly and deploy the modified area as an override with your mod. This is incompatible with other mods trying to edit the same area since only one modified version of the area will "win", and changes made by other mods to that area will not be available. Instead, use the [[PRCSCR]] system to add new content to existing areas.

== 2DA Conflict ==

Conflict between 2DA mods can be reduced using the [[2DA#Extending_the_game_via_M2DAs | M2DA]] mechanism and [[2DA#Reserved_ID_Ranges_and_overriding_existing_rows | reserving ID ranges]].

2DA mods should normally be placed in the add-in's module folder. Exception : if they are meant to be universally applied to all campaigns, they should be in the addin/core/override folder. The packages override folder should normally be avoided (because that removes control from the player, by forcing the 2DA to load even if the player has disabled the add-in).

== String Conflict ==

When a new module is created, its properties include a [[String ID]] range which starts at a very large random number. This makes it very unlikely that text created by one add-in will override another.

See [[String ID]] main article for a discussion of how this impacts sharing between Builders.

The [[String editor]] article discusses techniques for editing strings which are outside of the module's normal range. It is not normally necessary to customise core strings directly, but if there is no alternative, change the Owner Module to the current module, and the Table to the current module's talk table. Otherwise, the custom string will override all campaigns.

== Event Handling Conflict ==

Bear in mind that an add-in which impacts all campaigns could have undesirable consequences if it changes scripts or event-handling, given that custom campaigns may well have made changes of their own. If in doubt, consider modding the Single Player campaign only.

See [[Event_override | event override]] for recommended methods of intercepting events.

Note that script resources are never overwritten in these methods. Conceptually, the event is intercepted by a custom script, then passed on (unless the event has been handled successfully and further processing would be harmful). In this way, mods try not to interfere unnecessarily with other scripts.

Given the variety of actions that can be taken in a script, and that fact that one mod can't know what other mods are trying to do, we can't guarantee that this approach will be entirely free of logical problems, but the Perfect is the enemy of the Good.

The simplest and safest method is to assign a custom event script to a resource. This is likely to be used by custom campaigns, and also by Single Player mods to specific resources, as it is the approach that Bioware devs have often recommended.

Mods which aim to impact all campaigns globally are better advised to use the second method, i.e. overriding [[Event_(dascript_type) | event]] handling using an Events M2DA. As illustrated in the example script, if possible the event should be passed on to the default handler of the event's target object (which might be a custom event script). In this way, a global mod can be compatible with custom campaigns and specific resource mods.

Unfortunately, if two mods simply try to override the same event with an M2DA, they will be incompatible.

The best solution to override, partially override, or just listen for events via M2DA at this point would be to use a system such as [http://social.bioware.com/project/1907/#details Event Manager], though to ensure compatibility all modules overriding or listening for events should also be using the same system.

In the case of modules trying to totally override an event, only one module that does so will ultimately "win" (no such modules can ever truly be compatible with one another short of merging their functionality into one unified module as possible), but utilizing a system such as Event Manager will allow modules to partially override an event (i.e. only handle the event in certain situations), and will allow any module to listen for an event (without handling it) before or after the event is handled.

== Plot Property ==

Scripts that impact all campaigns should respect the plot property on resources. For example, if a campaign author has flagged an NPC as plot, it might not be helpful to change the creature AI.

== Open Source ==

If mod authors choose to publish their source code, with no restrictions on re-deployment, other builders can work around any residual incompatibilities (either by understanding the conflict more clearly, or by integrating the mod into their own work).

This technical wiki is not the place to discuss any legal or ethical considerations.

== FAQ ==

=== What if my mod extends both Single Player and Awakening? ===

Just create two dazips for your module. Name one yourprefix_yourmodule_version and the other yourprefix_yourmodule_EP1_version.

Edit the Manifest.xml file inside yourprefix_yourmodule_EP_1_version.dazip.
Change the line

<AddInItem UID="yourprefix_yourmodule" Name="Your Module Name" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1"> to

<AddInItem UID="yourprefix_yourmodule_EP_1" Name="Your Module Name" ExtendedModuleUID="DAO_PRC_EP_1" Priority="200" Enabled="1" State="2" Format="1">

See also [[Talk:Compatibility | Discussion]]

=== How can I import an item with my existing character to a new campaign? ===

The Awakening expansion allows an existing character to be imported from one campaign to another.

There are two methods of ensuring that an item in the player's inventory is imported successfully:

* Make the item a core resource
* Include the item template in separate add-ins to both campaigns (see Awakening example above)

=== How can I stop items being imported into my campaign? ===

Assuming your campaign allows existing characters to be imported during Character Generation, you might want to clear the player's inventory before adding your starting equipment. Imported equipment might upset the balance of your campaign.

If you decide to do this, it's a good idea to warn players, so that they understand what's happening.

Compatibility

2010-12-30T12:53:50Z

Gaxkang55: cleaned up text. this is not a discussion page, we should just provide the best advice available not have a debate.

DAO has an active modding community. Over time, players will accumulate many new campaigns and game mods. So, as a courtesy to players and other builders, it's helpful to try to make our mods mutually compatible.

From time to time, Bioware may well issue new releases, so it's good to reduce the risk of conflict in that respect, too.

Since we can't be sure that all authors will respect compatibility considerations, the emphasis here is on techniques that reduce the risk of conflict, regardless of what other people do (though not all are foolproof).

Obviously, there are some conflicts with no win-win (hurlocks can't be both green and purple at the same time), but that doesn't stop us trying to avoid unnecessary win-lose or corruption.

We begin with a concrete example - a tutorial on script conflict in OC mods, which is one of the most common problems to avoid. The remainder of the page is a more systematic discussion, which applies to both OC mods and custom campaigns.

== Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) ==

I'm hoping to save my modding friends some time. (Tutorial by Immortality)

'''Remember: IT'S YOUR RESPONSIBILITY TO ENSURE YOUR MOD DOES NOT BREAK THE GAME, THE EXPANSION, DLCS, OR OTHER MODS!!'''

'''''The problem:'''''

- While working in my Origins mod, and then on my Awakening mod, I realized that my Origins mod was breaking Awakening (scripts were not triggering, and even objects were moving around!).

- In the same way, my mod for Awakening was interfeering in Origins, breaking it (wrong scripts triggering, destroying the party recruiting).

'''''The objective:'''''

- Prevent the Origins mod to interfere with Awakening. If your mod is for Origins, it should only work in Origins.

- Prevent the Awakening mod to interfere with Origins. If your mod is for Awakening, it should only work in Awakening.

- If you have one mod for both, to ensure that the Origins part triggers in Origins and Awakening part in Awakening.

'''''Procedure:'''''

'''1- Ensure your Origins mod is for Origins only!'''

NEVER EVER EVER set your core scripts or handling scripts as Core Game Resources. NEVER!

There's absolutely no need for your scripts (especially your module core) to be a core game resource.

This means that whenever you create a mod for origins you should always set the properties of your major handling scripts as "Module: your module", and "Owner Module: your module". NEVER as a core game resource. Otherwise they will interfere with awakening and will break it (make no mistake, they will).

Example:

This is how you set your Origins module: [[image:Originshierarchy.jpg]]

This is how you set all your script's properties: [[image:Originsproperties.jpg]]

'''2- Ensure your Awakening mod is for Awakening only!'''

Things are different for Awakening because you DO have to set all your materials' properties as "Module: Core Game Resources", and "Owner Module: your module". (read the tutorial if you need to know more: http://social.bioware.com/53295/blog/10858/ )

This means that your Awakening mod will interfere with Origins and will break the game.

Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.

'''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!

In order to avoid this, you can rename your functions.
For example, if your Origins script has the function "SetFollowerInParty", then rename the function in your Awakening script to "SetFollowerInParty_awakening", and etc.

== Disable Add-Ins : Suggested Disclaimer ==

If the player disables all other add-ins on the in game DLC screen, no conflict should occur between them. Tedious, but effective.

This should rarely be necessary if the compatibility guidelines listed here are observed.

Exception : there is a [[Bug:_export_creates_unnecessary_core_override | toolset bug]] which produces content that persists in game, even when the add-in is disabled, unless the builder cleans it out before making the Builder-to-Player file. The same problem can occur if a builder has intentionally placed content in the packages\override folder (which should normally be avoided, as it is very rarely necessary).

Mod authors can work together to set player expectations in this respect. For example, the installation instructions might say

<dascript>Reasonable steps have been taken to make this mod compatible.
Obviously, the author has no control over the quality of other mods you may have installed.
So, to reduce the risk of conflict, you are are strongly advised to move all files out of your
packages\override folders, and consider disabling unnecessary community mods on your in-game
DLC screen, before playing.</dascript>

== Module Scope ==

Setting the Extended Module in Module properties to "Core Game Resources" means that the add-in will change every campaign in game. If that's not intended, select the campaign you're trying to extend e.g. Single Player for the official campaign, (None) for a new standalone campaign.

[[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | What if my mod extends both Single Player and Awakening?]]

== Resource Scope ==

By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.

Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled.

It appears the packages folder has to be used for resources that won't load from the addins folder, namely

* The Talk Table (see [[Bug:_Talk_table_exported_to_packages_override | bug]]) that overrides existing game strings. Best practice is to avoid doing this in the first place.
* The chargenmorphcfg.xml file, which can be used to add new morph presets for character generation.

It was reported that tint maps needed to be in packages, but this was based on a misunderstanding.

Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder.

Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.

Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Many of those resources can in any case be moved to the module folder and still work.

There are a large number of mods available that use the packages folder, creating headaches for other modders and often users since such overwrites cannot be turned off in the game GUI. Users should be told to avoid mods whose method of installation is "place this folder in packages\override" and to delete any content that is currently in that folder. Mods not properly organised into dazips and installed with the Bioware supplied daupdater should also be deprecated, unless a good reason is given why they are being distributed that way.

== Resource Conflict ==

Resource names need to be unique within type. For example, genpt_party.plt and genpt_party.nss are different resources, becasue the type is different. However, if two modules both have resources called genpt_party.plt, only one will load in game, following the [[Source directory priorities]].

Within the toolset database, duplicate resource names are forbidden, but there's nothing to stop different builders making resources which accidentally conflict, so it's wise to choose a unique range of names. Each builder can register the prefix they require. See [[Naming_conventions#Resource_Naming_Convention | Resource Naming Convention]] and especially [[Prefixes in use]].

It is possible to override a core resource intentionally, by editing a copy, exporting it, and renaming it in the export folder to the same name as the original. However, almost invariably there is a cleaner way of doing this - for example, by changing the 2DA which identifies which resource to use.

== Existing Content Modification ==

When adding new content or content hooks to existing areas, do not modify the area directly and deploy the modified area as an override with your mod. This is incompatible with other mods trying to edit the same area since only one modified version of the area will "win", and changes made by other mods to that area will not be available. Instead, use the [[PRCSCR]] system to add new content to existing areas.

== 2DA Conflict ==

Conflict between 2DA mods can be reduced using the [[2DA#Extending_the_game_via_M2DAs | M2DA]] mechanism and [[2DA#Reserved_ID_Ranges_and_overriding_existing_rows | reserving ID ranges]].

2DA mods should normally be placed in the add-in's module folder. Exception : if they are meant to be universally applied to all campaigns, they should be in the addin/core/override folder. The packages override folder should normally be avoided (because that removes control from the player, by forcing the 2DA to load even if the player has disabled the add-in).

== String Conflict ==

When a new module is created, its properties include a [[String ID]] range which starts at a very large random number. This makes it very unlikely that text created by one add-in will override another.

See [[String ID]] main article for a discussion of how this impacts sharing between Builders.

The [[String editor]] article discusses techniques for editing strings which are outside of the module's normal range. It is not normally necessary to customise core strings directly, but if there is no alternative, change the Owner Module to the current module, and the Table to the current module's talk table. Otherwise, the custom string will override all campaigns.

== Event Handling Conflict ==

Bear in mind that an add-in which impacts all campaigns could have undesirable consequences if it changes scripts or event-handling, given that custom campaigns may well have made changes of their own. If in doubt, consider modding the Single Player campaign only.

See [[Event_override | event override]] for recommended methods of intercepting events.

Note that script resources are never overwritten in these methods. Conceptually, the event is intercepted by a custom script, then passed on (unless the event has been handled successfully and further processing would be harmful). In this way, mods try not to interfere unnecessarily with other scripts.

Given the variety of actions that can be taken in a script, and that fact that one mod can't know what other mods are trying to do, we can't guarantee that this approach will be entirely free of logical problems, but the Perfect is the enemy of the Good.

The simplest and safest method is to assign a custom event script to a resource. This is likely to be used by custom campaigns, and also by Single Player mods to specific resources, as it is the approach that Bioware devs have often recommended.

Mods which aim to impact all campaigns globally are better advised to use the second method, i.e. overriding [[Event_(dascript_type) | event]] handling using an Events M2DA. As illustrated in the example script, if possible the event should be passed on to the default handler of the event's target object (which might be a custom event script). In this way, a global mod can be compatible with custom campaigns and specific resource mods.

Unfortunately, if two mods simply try to override the same event with an M2DA, they will be incompatible.

The best solution to override, partially override, or just listen for events via M2DA at this point would be to use a system such as [http://social.bioware.com/project/1907/#details Event Manager], though to ensure compatibility all modules overriding or listening for events should also be using the same system.

In the case of modules trying to totally override an event, only one module that does so will ultimately "win" (no such modules can ever truly be compatible with one another short of merging their functionality into one unified module as possible), but utilizing a system such as Event Manager will allow modules to partially override an event (i.e. only handle the event in certain situations), and will allow any module to listen for an event (without handling it) before or after the event is handled.

== Plot Property ==

Scripts that impact all campaigns should respect the plot property on resources. For example, if a campaign author has flagged an NPC as plot, it might not be helpful to change the creature AI.

== Open Source ==

If mod authors choose to publish their source code, with no restrictions on re-deployment, other builders can work around any residual incompatibilities (either by understanding the conflict more clearly, or by integrating the mod into their own work).

This technical wiki is not the place to discuss any legal or ethical considerations.

== FAQ ==

=== What if my mod extends both Single Player and Awakening? ===

Just create two dazips for your module. Name one yourprefix_yourmodule_version and the other yourprefix_yourmodule_EP1_version.

Edit the Manifest.xml file inside yourprefix_yourmodule_EP_1_version.dazip.
Change the line

<AddInItem UID="yourprefix_yourmodule" Name="Your Module Name" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1"> to

<AddInItem UID="yourprefix_yourmodule_EP_1" Name="Your Module Name" ExtendedModuleUID="DAO_PRC_EP_1" Priority="200" Enabled="1" State="2" Format="1">

See also [[Talk:Compatibility | Discussion]]

=== How can I import an item with my existing character to a new campaign? ===

The Awakening expansion allows an existing character to be imported from one campaign to another.

There are two methods of ensuring that an item in the player's inventory is imported successfully:

* Make the item a core resource
* Include the item template in separate add-ins to both campaigns (see Awakening example above)

=== How can I stop items being imported into my campaign? ===

Assuming your campaign allows existing characters to be imported during Character Generation, you might want to clear the player's inventory before adding your starting equipment. Imported equipment might upset the balance of your campaign.

If you decide to do this, it's a good idea to warn players, so that they understand what's happening.

Talk:Compatibility

2010-12-30T12:43:05Z

Gaxkang55: /* Resource scope edit */ new section

Compatibility

2010-12-30T12:38:48Z

Gaxkang55: /* Resource Scope */ See talk page

DAO has an active modding community. Over time, players will accumulate many new campaigns and game mods. So, as a courtesy to players and other builders, it's helpful to try to make our mods mutually compatible.

From time to time, Bioware may well issue new releases, so it's good to reduce the risk of conflict in that respect, too.

Since we can't be sure that all authors will respect compatibility considerations, the emphasis here is on techniques that reduce the risk of conflict, regardless of what other people do (though not all are foolproof).

Obviously, there are some conflicts with no win-win (hurlocks can't be both green and purple at the same time), but that doesn't stop us trying to avoid unnecessary win-lose or corruption.

We begin with a concrete example - a tutorial on script conflict in OC mods, which is one of the most common problems to avoid. The remainder of the page is a more systematic discussion, which applies to both OC mods and custom campaigns.

== Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) ==

I'm hoping to save my modding friends some time. (Tutorial by Immortality)

'''Remember: IT'S YOUR RESPONSIBILITY TO ENSURE YOUR MOD DOES NOT BREAK THE GAME, THE EXPANSION, DLCS, OR OTHER MODS!!'''

'''''The problem:'''''

- While working in my Origins mod, and then on my Awakening mod, I realized that my Origins mod was breaking Awakening (scripts were not triggering, and even objects were moving around!).

- In the same way, my mod for Awakening was interfeering in Origins, breaking it (wrong scripts triggering, destroying the party recruiting).

'''''The objective:'''''

- Prevent the Origins mod to interfere with Awakening. If your mod is for Origins, it should only work in Origins.

- Prevent the Awakening mod to interfere with Origins. If your mod is for Awakening, it should only work in Awakening.

- If you have one mod for both, to ensure that the Origins part triggers in Origins and Awakening part in Awakening.

'''''Procedure:'''''

'''1- Ensure your Origins mod is for Origins only!'''

NEVER EVER EVER set your core scripts or handling scripts as Core Game Resources. NEVER!

There's absolutely no need for your scripts (especially your module core) to be a core game resource.

This means that whenever you create a mod for origins you should always set the properties of your major handling scripts as "Module: your module", and "Owner Module: your module". NEVER as a core game resource. Otherwise they will interfere with awakening and will break it (make no mistake, they will).

Example:

This is how you set your Origins module: [[image:Originshierarchy.jpg]]

This is how you set all your script's properties: [[image:Originsproperties.jpg]]

'''2- Ensure your Awakening mod is for Awakening only!'''

Things are different for Awakening because you DO have to set all your materials' properties as "Module: Core Game Resources", and "Owner Module: your module". (read the tutorial if you need to know more: http://social.bioware.com/53295/blog/10858/ )

This means that your Awakening mod will interfere with Origins and will break the game.

We will use a plot flag check to ensure that your module core script and handling scripts only trigger in Awakening.

You should insert this code in all your handling scripts:

if(!WR_GetPlotFlag("C0B7199C74CA4B67B143ACA8CDCFCF9D",0, TRUE))
return;

Where "C0B7199C74CA4B67B143ACA8CDCFCF9D" is actually gxa000pt_awakening,plo, and "0", is "GXA_AWAKENING_START", but you can use any other Awakening plot that you may need.

Please read this tutorial to learn how to mod using Awakening's plot flags: http://social.bioware.com/53295/blog/10881/
(For for people who don't know how to script, like me, this tells the game not to run the script unless GXA_AWAKENING_START is true.)

Screenshots of my Awakening handling scripts with the code inserted:
[[image:Awakening1.jpg]] [[image:Awakening2.jpg]]

'''OR'''

(From TimelordDC)

Use IsUsingEP1Resources() [returns TRUE or FALSE] instead of that plot flag check.

Origins code itself has a lot of code that was written for Awakening and in all cases, they use this function to check if Awakening is being used or not.

Immortality's editor note: Instead of my code, you can use '''IsUsingEP1Resources()''', which is probably safer. :-)

And as always... BE CAREFUL! :-)

'''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!

In order to avoid this, you can rename your functions.
For example, if your Origins script has the function "SetFollowerInParty", then rename the function in your Awakening script to "SetFollowerInParty_awakening", and etc.

== Disable Add-Ins : Suggested Disclaimer ==

If the player disables all other add-ins on the in game DLC screen, no conflict should occur between them. Tedious, but effective.

This should rarely be necessary if the compatibility guidelines listed here are observed.

Exception : there is a [[Bug:_export_creates_unnecessary_core_override | toolset bug]] which produces content that persists in game, even when the add-in is disabled, unless the builder cleans it out before making the Builder-to-Player file. The same problem can occur if a builder has intentionally placed content in the packages\override folder (which should normally be avoided, as it is very rarely necessary).

Mod authors can work together to set player expectations in this respect. For example, the installation instructions might say

<dascript>Reasonable steps have been taken to make this mod compatible.
Obviously, the author has no control over the quality of other mods you may have installed.
So, to reduce the risk of conflict, you are are strongly advised to move all files out of your
packages\override folders, and consider disabling unnecessary community mods on your in-game
DLC screen, before playing.</dascript>

== Module Scope ==

Setting the Extended Module in Module properties to "Core Game Resources" means that the add-in will change every campaign in game. If that's not intended, select the campaign you're trying to extend e.g. Single Player for the official campaign, (None) for a new standalone campaign.

[[Compatibility#What_if_my_mod_extends_both_Single_Player_and_Awakening.3F | What if my mod extends both Single Player and Awakening?]]

== Resource Scope ==

By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.

Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled.

It appears the packages folder has to be used for resources that won't load from the addins folder, namely

* The Talk Table (see [[Bug:_Talk_table_exported_to_packages_override | bug]]) that overrides existing game strings. Best practice is to avoid doing this in the first place.
* The chargenmorphcfg.xml file, which can be used to add new morph presets for character generation.

It was reported that tint maps needed to be in packages, but this was based on a misunderstanding.

Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder.

Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.

Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Many of those resources can in any case be moved to the module folder and still work.

There are a large number of mods available that use the packages folder, creating headaches for other modders and often users since such overwrites cannot be turned off in the game GUI. Users should be told to avoid mods whose method of installation is "place this folder in packages\override" and to delete any content that is currently in that folder. Mods not properly organised into dazips and installed with the Bioware supplied daupdater should also be deprecated, unless a good reason is given why they are being distributed that way.

== Resource Conflict ==

Resource names need to be unique within type. For example, genpt_party.plt and genpt_party.nss are different resources, becasue the type is different. However, if two modules both have resources called genpt_party.plt, only one will load in game, following the [[Source directory priorities]].

Within the toolset database, duplicate resource names are forbidden, but there's nothing to stop different builders making resources which accidentally conflict, so it's wise to choose a unique range of names. Each builder can register the prefix they require. See [[Naming_conventions#Resource_Naming_Convention | Resource Naming Convention]] and especially [[Prefixes in use]].

It is possible to override a core resource intentionally, by editing a copy, exporting it, and renaming it in the export folder to the same name as the original. However, almost invariably there is a cleaner way of doing this - for example, by changing the 2DA which identifies which resource to use.

== Existing Content Modification ==

When adding new content or content hooks to existing areas, do not modify the area directly and deploy the modified area as an override with your mod. This is incompatible with other mods trying to edit the same area since only one modified version of the area will "win", and changes made by other mods to that area will not be available. Instead, use the [[PRCSCR]] system to add new content to existing areas.

== 2DA Conflict ==

Conflict between 2DA mods can be reduced using the [[2DA#Extending_the_game_via_M2DAs | M2DA]] mechanism and [[2DA#Reserved_ID_Ranges_and_overriding_existing_rows | reserving ID ranges]].

2DA mods should normally be placed in the add-in's module folder. Exception : if they are meant to be universally applied to all campaigns, they should be in the addin/core/override folder. The packages override folder should normally be avoided (because that removes control from the player, by forcing the 2DA to load even if the player has disabled the add-in).

== String Conflict ==

When a new module is created, its properties include a [[String ID]] range which starts at a very large random number. This makes it very unlikely that text created by one add-in will override another.

See [[String ID]] main article for a discussion of how this impacts sharing between Builders.

The [[String editor]] article discusses techniques for editing strings which are outside of the module's normal range. It is not normally necessary to customise core strings directly, but if there is no alternative, change the Owner Module to the current module, and the Table to the current module's talk table. Otherwise, the custom string will override all campaigns.

== Event Handling Conflict ==

Bear in mind that an add-in which impacts all campaigns could have undesirable consequences if it changes scripts or event-handling, given that custom campaigns may well have made changes of their own. If in doubt, consider modding the Single Player campaign only.

See [[Event_override | event override]] for recommended methods of intercepting events.

Note that script resources are never overwritten in these methods. Conceptually, the event is intercepted by a custom script, then passed on (unless the event has been handled successfully and further processing would be harmful). In this way, mods try not to interfere unnecessarily with other scripts.

Given the variety of actions that can be taken in a script, and that fact that one mod can't know what other mods are trying to do, we can't guarantee that this approach will be entirely free of logical problems, but the Perfect is the enemy of the Good.

The simplest and safest method is to assign a custom event script to a resource. This is likely to be used by custom campaigns, and also by Single Player mods to specific resources, as it is the approach that Bioware devs have often recommended.

Mods which aim to impact all campaigns globally are better advised to use the second method, i.e. overriding [[Event_(dascript_type) | event]] handling using an Events M2DA. As illustrated in the example script, if possible the event should be passed on to the default handler of the event's target object (which might be a custom event script). In this way, a global mod can be compatible with custom campaigns and specific resource mods.

Unfortunately, if two mods simply try to override the same event with an M2DA, they will be incompatible.

The best solution to override, partially override, or just listen for events via M2DA at this point would be to use a system such as [http://social.bioware.com/project/1907/#details Event Manager], though to ensure compatibility all modules overriding or listening for events should also be using the same system.

In the case of modules trying to totally override an event, only one module that does so will ultimately "win" (no such modules can ever truly be compatible with one another short of merging their functionality into one unified module as possible), but utilizing a system such as Event Manager will allow modules to partially override an event (i.e. only handle the event in certain situations), and will allow any module to listen for an event (without handling it) before or after the event is handled.

== Plot Property ==

Scripts that impact all campaigns should respect the plot property on resources. For example, if a campaign author has flagged an NPC as plot, it might not be helpful to change the creature AI.

== Open Source ==

If mod authors choose to publish their source code, with no restrictions on re-deployment, other builders can work around any residual incompatibilities (either by understanding the conflict more clearly, or by integrating the mod into their own work).

This technical wiki is not the place to discuss any legal or ethical considerations.

== FAQ ==

=== What if my mod extends both Single Player and Awakening? ===

Just create two dazips for your module. Name one yourprefix_yourmodule_version and the other yourprefix_yourmodule_EP1_version.

Edit the Manifest.xml file inside yourprefix_yourmodule_EP_1_version.dazip.
Change the line

<AddInItem UID="yourprefix_yourmodule" Name="Your Module Name" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1"> to

<AddInItem UID="yourprefix_yourmodule_EP_1" Name="Your Module Name" ExtendedModuleUID="DAO_PRC_EP_1" Priority="200" Enabled="1" State="2" Format="1">

See also [[Talk:Compatibility | Discussion]]

=== How can I import an item with my existing character to a new campaign? ===

The Awakening expansion allows an existing character to be imported from one campaign to another.

There are two methods of ensuring that an item in the player's inventory is imported successfully:

* Make the item a core resource
* Include the item template in separate add-ins to both campaigns (see Awakening example above)

=== How can I stop items being imported into my campaign? ===

Assuming your campaign allows existing characters to be imported during Character Generation, you might want to clear the player's inventory before adding your starting equipment. Imported equipment might upset the balance of your campaign.

If you decide to do this, it's a good idea to warn players, so that they understand what's happening.

Talk:Overriding and creating tints tutorial

2010-12-25T20:33:32Z

Gaxkang55: Created page with 'This is terrible advice on several fronts. If core game resources are to overwritten by a mod, then disabling the mod through the game GUI should turn off the overwrite. Nothing...'

This is terrible advice on several fronts. If core game resources are to overwritten by a mod, then disabling the mod through the game GUI should turn off the overwrite. Nothing should go into packages unless it absolutely has to, which is certainly not the case here. I may put a note on this after I finish an alternative tutorial on the tint system. Would welcome any discussion in the meantime since it goes to the broader question of good and bad modding practices. --[[User:Gaxkang55|Gaxkang55]] 20:33, 25 December 2010 (UTC)

Reskinning an item tutorial

2010-12-22T13:01:11Z

Gaxkang55: /* General considerations */

__TOC__

This tutorial describes how to reskin, or change the default texture, of items that already exist in-game. As an example, the default textures of the human female mage's apprentice robes will be changed.

Tools needed are the Dragon Age Toolset, and a grafic editing Applications capable of Opening, Editing and Saving DDS Texture Files.

==General considerations==
Most armor and weapons have a tint map, and if the aim is simply to recolor a model, then a custom tint should be used. In any case, recoloring a model which already has a tint applied will either not work or lead to unpredictable results. Additionally, a custom tint file has the advantage of working for both high and medium textures at all LOD. See below for further tutorials. However, there are situations where creating/modifying textures is appropriate, but in those situations it is preferable to create a new item variation and associated machinery to '''add''' the texture rather than overwriting an existing game resource.

== Locating the Model Textures the Hard Way==

At the beginning, you only know how the [[Model]] looks and what its called. A somewhat difficult task will be finding out which files are tied to the model so that you can edit them.

First and foremost, you are looking for DDS Files. How DDS Files are referenced by an Item you see in Game is a long list of database references.

A quick rundown on references we need to be aware of

#A DDS File is referenced by the Material Properties of a [[Model]]
#A [[Model]] is then referenced by the "ItemVariation" type of files. In our example, the sub "clothing_variation.gda"
#The different Clothing Variations are then referenced by the Item Type made via the Toolset
#The Item Type is lastly referenced by the Game, when choosing which gender and race this item is worn. And then displays the final version in your game.

-----

To track back to the DDS File, you need to run up this list in reverse. Starting up our example, the mages apprentice robe, as it is worn by human females.

#Open up the Toolset and in the Resource Palette on the upper right click on "Items" (appears as a sword icon). Now comes guessing where this piece is to be found there. These Items are pretty well sorted though, it is to be found under _global / Clothing / Mage Robes / Unique. In the following list you see the ResourceName followed by ItemName "gen_im_cth_mag_app (Apprentice Robes)". Any Item can be found in the "Item" Category. Doubleclick that entry to look inside.
#In the listing of information that appears to the left of the item, note that the "Base Item Type" is "Clothing", which is branching off into the Item Variation. The robe has a "Item Variation" called "Robe, Apprentice". Variation in mind, onto the next step.
#Open up the "ItemVariations.xls" File located under "(dragon age install directory)/tools/Source/2da/rules". It has many pages, locate page "clothing_variation" since we know our "Base Item Type" is of "Clothing". In there, locate the Row called whatever Item Variation your Item had. "Robe, Apprentice" has Namestrings followed by "rob" "app" "a".
#With these 3 Strings, and Dragon Age's [[Naming conventions|Naming Scheme]] you can find the [[MMH]] Main Modelfile.
#At the end of MMH file (extract, open and Expand All with the toolset), is the reference to the material object filename (page up two or three times from the end of the file).
#And inside the [[MAO]] File (open with Notepad) are the references to the texture filenames.

Spend a little time browsing through these files, and the naming convention will become clear. The armor prefixes are a compound of a "race" letter -- h, d, e, q, k (for children) and p (for person, or humanoid) -- and a gender letter -- m, f or n. For instance, a Chest mesh (the actual model or msh file) is by necessity both race and usually gender specific, several mmh files will usually reference one msh and are prefixed similarly, while textures will map to any model with the correct UV map, so usually begin with "p" and may or may not be gender specific. Once you understand the prefixes, the textures can usually be located quickly in the relevant erf, with the part code (where applicable) coming next, followed by the item variation code, followed by the texture code.

(There are some anomalies: for instance Ancient Elven Armor is listed in the toolset as Medium Armor E, but is in fact heavy armor so has an item variation code of "hvye" (it also has no tint map, being a one-off piece), but such cases are not too hard to track down once you understand the overall schema.)

== Extracting the Texture from the Package ==

Model textures are located in two "texturepack.erf" [[ERF]] packages, corresponding to high resolution and medium resolution textures. These packages can be found in the (dragon age install directory)\packages\core\textures\ folder. For example, the packages might be:

<pre>C:\Program Files\Dragon Age\packages\core\textures\high\texturepack.erf
C:\Program Files\Dragon Age\packages\core\textures\medium\texturepack.erf</pre>

Drag and drop these ERF Files onto the Toolset to browse and extract their content. If you have the Name, finding the Files will be easy. The Files will be in both "high" and "medium" and the quality setting in the game will decide which to choose. To make it compatible enough, taking them all may be neccessary.

Incidentally, high and medium texture versions are only required for certain model types. For example, heraldry and props only have one texture, and these can be found in

<pre>C:\Program Files\Dragon Age\packages\core\data\textures.erf</pre>

To prepare for extracting the textures, we must create a directory mimicking the structure of the Dragon Age packages folder. To do this, create a new folder named "textures" in a convenient location (for example, on your desktop). Inside this folder, create two new folders, named "high" and "medium". The "high" folder will be where the high-resolution textures are extracted to, and the "medium" folder will be where the medium-resolution textures are extracted to.

For this tutorial, we are interested in the mage's robes. To locate the textures of the mage's robes, scroll down to "pf_rob_appa_0d.dds" in one of the two texturepack ERFs. In each texturepack.erf, select all of the image files prefixed with "pf_rob_appa" (from "pf_rob_appa_0d.dds" to "pf_rob_appa_0tl3.dds"). For the high-resolution texturepack.erf, extract these images to the "textures\high\" folder just created. Extract the medium-resolution textures to the "textures\medium\" folder.

The Suffixes for Texturefiles are describing their Formats, which is described under [[Textureformats]].

To extract one of the textures, right-click on it and select "Extract Resource."

== Editing the Textures ==

At this stage, if we wanted to edit the existing robe textures, we could do so by changing these files. See [[Textureformats]].

Once this has been done for all of the robe textures (in both the "High" and "Medium" folders), we'll be ready to override the default textures in Dragon Age.

== Overriding the Existing Textures ==
[[Image:Demo-retexture.jpg|thumb|The end result: reskinned default mage robes.]]

Comment : this section doesn't agree with the guidance on [[Compatibility]]. Surely textures should be placed in the module's texture folder?

To override the existing textures, copy the "textures" folder containing the modified textures, and paste this folder into the Dragon Age override folder. The override folder is found in:
*Documents\BioWare\Dragon Age\packages\core\override\
for Windows Vista and 7, and in a similar location on Windows XP.

So, after pasting in the modified textures, the structure of the override folder should look like this:

*Documents\BioWare\Dragon Age\packages\core\override\
**textures
***high
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds
***medium
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds

== Further Tutorials ==

[[Tutorial: Creating recolors of existing items]] - A way to change the tint of the new texture

== Related Links ==

[[Texture Formats]] - Texture formats in detail.

[[Art Resources]] - Broad topic of Art Resources, which textures are a part of.

[[category:tutorials]]
[[Category:Textures]]

Reskinning an item tutorial

2010-12-22T12:52:25Z

Gaxkang55:

__TOC__

This tutorial describes how to reskin, or change the default texture, of items that already exist in-game. As an example, the default textures of the human female mage's apprentice robes will be changed.

Tools needed are the Dragon Age Toolset, and a grafic editing Applications capable of Opening, Editing and Saving DDS Texture Files.

==General considerations==
Most armor and weapons have a tint map, and if the aim is simply to recolor a model, then a custom tint should be used. In any case, recoloring a model which has a tint applied will either not work or lead to unpredictable results. See below for further tutorials. However, there are situations where creating/modifying textures is appropriate, but in those situations it is preferable to create a new item variation and associated machinery to ''''add'''' the texture rather than overwriting an existing ingame resource.

== Locating the Model Textures the Hard Way==

At the beginning, you only know how the [[Model]] looks and what its called. A somewhat difficult task will be finding out which files are tied to the model so that you can edit them.

First and foremost, you are looking for DDS Files. How DDS Files are referenced by an Item you see in Game is a long list of database references.

A quick rundown on references we need to be aware of

#A DDS File is referenced by the Material Properties of a [[Model]]
#A [[Model]] is then referenced by the "ItemVariation" type of files. In our example, the sub "clothing_variation.gda"
#The different Clothing Variations are then referenced by the Item Type made via the Toolset
#The Item Type is lastly referenced by the Game, when choosing which gender and race this item is worn. And then displays the final version in your game.

-----

To track back to the DDS File, you need to run up this list in reverse. Starting up our example, the mages apprentice robe, as it is worn by human females.

#Open up the Toolset and in the Resource Palette on the upper right click on "Items" (appears as a sword icon). Now comes guessing where this piece is to be found there. These Items are pretty well sorted though, it is to be found under _global / Clothing / Mage Robes / Unique. In the following list you see the ResourceName followed by ItemName "gen_im_cth_mag_app (Apprentice Robes)". Any Item can be found in the "Item" Category. Doubleclick that entry to look inside.
#In the listing of information that appears to the left of the item, note that the "Base Item Type" is "Clothing", which is branching off into the Item Variation. The robe has a "Item Variation" called "Robe, Apprentice". Variation in mind, onto the next step.
#Open up the "ItemVariations.xls" File located under "(dragon age install directory)/tools/Source/2da/rules". It has many pages, locate page "clothing_variation" since we know our "Base Item Type" is of "Clothing". In there, locate the Row called whatever Item Variation your Item had. "Robe, Apprentice" has Namestrings followed by "rob" "app" "a".
#With these 3 Strings, and Dragon Age's [[Naming conventions|Naming Scheme]] you can find the [[MMH]] Main Modelfile.
#At the end of MMH file (extract, open and Expand All with the toolset), is the reference to the material object filename (page up two or three times from the end of the file).
#And inside the [[MAO]] File (open with Notepad) are the references to the texture filenames.

Spend a little time browsing through these files, and the naming convention will become clear. The armor prefixes are a compound of a "race" letter -- h, d, e, q, k (for children) and p (for person, or humanoid) -- and a gender letter -- m, f or n. For instance, a Chest mesh (the actual model or msh file) is by necessity both race and usually gender specific, several mmh files will usually reference one msh and are prefixed similarly, while textures will map to any model with the correct UV map, so usually begin with "p" and may or may not be gender specific. Once you understand the prefixes, the textures can usually be located quickly in the relevant erf, with the part code (where applicable) coming next, followed by the item variation code, followed by the texture code.

(There are some anomalies: for instance Ancient Elven Armor is listed in the toolset as Medium Armor E, but is in fact heavy armor so has an item variation code of "hvye" (it also has no tint map, being a one-off piece), but such cases are not too hard to track down once you understand the overall schema.)

== Extracting the Texture from the Package ==

Model textures are located in two "texturepack.erf" [[ERF]] packages, corresponding to high resolution and medium resolution textures. These packages can be found in the (dragon age install directory)\packages\core\textures\ folder. For example, the packages might be:

<pre>C:\Program Files\Dragon Age\packages\core\textures\high\texturepack.erf
C:\Program Files\Dragon Age\packages\core\textures\medium\texturepack.erf</pre>

Drag and drop these ERF Files onto the Toolset to browse and extract their content. If you have the Name, finding the Files will be easy. The Files will be in both "high" and "medium" and the quality setting in the game will decide which to choose. To make it compatible enough, taking them all may be neccessary.

Incidentally, high and medium texture versions are only required for certain model types. For example, heraldry and props only have one texture, and these can be found in

<pre>C:\Program Files\Dragon Age\packages\core\data\textures.erf</pre>

To prepare for extracting the textures, we must create a directory mimicking the structure of the Dragon Age packages folder. To do this, create a new folder named "textures" in a convenient location (for example, on your desktop). Inside this folder, create two new folders, named "high" and "medium". The "high" folder will be where the high-resolution textures are extracted to, and the "medium" folder will be where the medium-resolution textures are extracted to.

For this tutorial, we are interested in the mage's robes. To locate the textures of the mage's robes, scroll down to "pf_rob_appa_0d.dds" in one of the two texturepack ERFs. In each texturepack.erf, select all of the image files prefixed with "pf_rob_appa" (from "pf_rob_appa_0d.dds" to "pf_rob_appa_0tl3.dds"). For the high-resolution texturepack.erf, extract these images to the "textures\high\" folder just created. Extract the medium-resolution textures to the "textures\medium\" folder.

The Suffixes for Texturefiles are describing their Formats, which is described under [[Textureformats]].

To extract one of the textures, right-click on it and select "Extract Resource."

== Editing the Textures ==

At this stage, if we wanted to edit the existing robe textures, we could do so by changing these files. See [[Textureformats]].

Once this has been done for all of the robe textures (in both the "High" and "Medium" folders), we'll be ready to override the default textures in Dragon Age.

== Overriding the Existing Textures ==
[[Image:Demo-retexture.jpg|thumb|The end result: reskinned default mage robes.]]

Comment : this section doesn't agree with the guidance on [[Compatibility]]. Surely textures should be placed in the module's texture folder?

To override the existing textures, copy the "textures" folder containing the modified textures, and paste this folder into the Dragon Age override folder. The override folder is found in:
*Documents\BioWare\Dragon Age\packages\core\override\
for Windows Vista and 7, and in a similar location on Windows XP.

So, after pasting in the modified textures, the structure of the override folder should look like this:

*Documents\BioWare\Dragon Age\packages\core\override\
**textures
***high
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds
***medium
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds

== Further Tutorials ==

[[Tutorial: Creating recolors of existing items]] - A way to change the tint of the new texture

== Related Links ==

[[Texture Formats]] - Texture formats in detail.

[[Art Resources]] - Broad topic of Art Resources, which textures are a part of.

[[category:tutorials]]
[[Category:Textures]]

Reskinning an item tutorial

2010-12-22T11:40:01Z

Gaxkang55: /* Locating the Model Textures the Hard Way */

__TOC__

This tutorial describes how to reskin, or change the default texture, of items that already exist in-game. As an example, the default textures of the human female mage's apprentice robes will be changed.

Tools needed are the Dragon Age Toolset, and a grafic editing Applications capable of Opening, Editing and Saving DDS Texture Files.

'''Note:''' The game utilizes Tints, which reuse the same Texture in colorized or tinted versions. Thus the texture in our example doesn't look quite as it does in game, and vice versa. If you edit the Texture, it won't look quite like that when put back into the game. The difference is merely color differences, so this process is limited. However, you can only change Tints, or both. See below for further tutorials.

== Locating the Model Textures the Hard Way==

At the beginning, you only know how the [[Model]] looks and what its called. A somewhat difficult task will be finding out which files are tied to the model so that you can edit them.

First and foremost, you are looking for DDS Files. How DDS Files are referenced by an Item you see in Game is a long list of database references.

A quick rundown on references we need to be aware of

#A DDS File is referenced by the Material Properties of a [[Model]]
#A [[Model]] is then referenced by the "ItemVariation" type of files. In our example, the sub "clothing_variation.gda"
#The different Clothing Variations are then referenced by the Item Type made via the Toolset
#The Item Type is lastly referenced by the Game, when choosing which gender and race this item is worn. And then displays the final version in your game.

-----

To track back to the DDS File, you need to run up this list in reverse. Starting up our example, the mages apprentice robe, as it is worn by human females.

#Open up the Toolset and in the Resource Palette on the upper right click on "Items" (appears as a sword icon). Now comes guessing where this piece is to be found there. These Items are pretty well sorted though, it is to be found under _global / Clothing / Mage Robes / Unique. In the following list you see the ResourceName followed by ItemName "gen_im_cth_mag_app (Apprentice Robes)". Any Item can be found in the "Item" Category. Doubleclick that entry to look inside.
#In the listing of information that appears to the left of the item, note that the "Base Item Type" is "Clothing", which is branching off into the Item Variation. The robe has a "Item Variation" called "Robe, Apprentice". Variation in mind, onto the next step.
#Open up the "ItemVariations.xls" File located under "(dragon age install directory)/tools/Source/2da/rules". It has many pages, locate page "clothing_variation" since we know our "Base Item Type" is of "Clothing". In there, locate the Row called whatever Item Variation your Item had. "Robe, Apprentice" has Namestrings followed by "rob" "app" "a".
#With these 3 Strings, and Dragon Age's [[Naming conventions|Naming Scheme]] you can find the [[MMH]] Main Modelfile.
#At the end of MMH file (extract, open and Expand All with the toolset), is the reference to the material object filename (page up two or three times from the end of the file).
#And inside the [[MAO]] File (open with Notepad) are the references to the texture filenames.

Spend a little time browsing through these files, and the naming convention will become clear. The armor prefixes are a compound of a "race" letter -- h, d, e, q, k (for children) and p (for person, or humanoid) -- and a gender letter -- m, f or n. For instance, a Chest mesh (the actual model or msh file) is by necessity both race and usually gender specific, several mmh files will usually reference one msh and are prefixed similarly, while textures will map to any model with the correct UV map, so usually begin with "p" and may or may not be gender specific. Once you understand the prefixes, the textures can usually be located quickly in the relevant erf, with the part code (where applicable) coming next, followed by the item variation code, followed by the texture code.

(There are some anomalies: for instance Ancient Elven Armor is listed in the toolset as Medium Armor E, but is in fact heavy armor so has an item variation code of "hvye" (it also has no tint map, being a one-off piece), but such cases are not too hard to track down once you understand the overall schema.)

== Extracting the Texture from the Package ==

Model textures are located in two "texturepack.erf" [[ERF]] packages, corresponding to high resolution and medium resolution textures. These packages can be found in the (dragon age install directory)\packages\core\textures\ folder. For example, the packages might be:

<pre>C:\Program Files\Dragon Age\packages\core\textures\high\texturepack.erf
C:\Program Files\Dragon Age\packages\core\textures\medium\texturepack.erf</pre>

Drag and drop these ERF Files onto the Toolset to browse and extract their content. If you have the Name, finding the Files will be easy. The Files will be in both "high" and "medium" and the quality setting in the game will decide which to choose. To make it compatible enough, taking them all may be neccessary.

Incidentally, high and medium texture versions are only required for certain model types. For example, heraldry and props only have one texture, and these can be found in

<pre>C:\Program Files\Dragon Age\packages\core\data\textures.erf</pre>

To prepare for extracting the textures, we must create a directory mimicking the structure of the Dragon Age packages folder. To do this, create a new folder named "textures" in a convenient location (for example, on your desktop). Inside this folder, create two new folders, named "high" and "medium". The "high" folder will be where the high-resolution textures are extracted to, and the "medium" folder will be where the medium-resolution textures are extracted to.

For this tutorial, we are interested in the mage's robes. To locate the textures of the mage's robes, scroll down to "pf_rob_appa_0d.dds" in one of the two texturepack ERFs. In each texturepack.erf, select all of the image files prefixed with "pf_rob_appa" (from "pf_rob_appa_0d.dds" to "pf_rob_appa_0tl3.dds"). For the high-resolution texturepack.erf, extract these images to the "textures\high\" folder just created. Extract the medium-resolution textures to the "textures\medium\" folder.

The Suffixes for Texturefiles are describing their Formats, which is described under [[Textureformats]].

To extract one of the textures, right-click on it and select "Extract Resource."

== Editing the Textures ==

At this stage, if we wanted to edit the existing robe textures, we could do so by changing these files. See [[Textureformats]].

Once this has been done for all of the robe textures (in both the "High" and "Medium" folders), we'll be ready to override the default textures in Dragon Age.

== Overriding the Existing Textures ==
[[Image:Demo-retexture.jpg|thumb|The end result: reskinned default mage robes.]]

Comment : this section doesn't agree with the guidance on [[Compatibility]]. Surely textures should be placed in the module's texture folder?

To override the existing textures, copy the "textures" folder containing the modified textures, and paste this folder into the Dragon Age override folder. The override folder is found in:
*Documents\BioWare\Dragon Age\packages\core\override\
for Windows Vista and 7, and in a similar location on Windows XP.

So, after pasting in the modified textures, the structure of the override folder should look like this:

*Documents\BioWare\Dragon Age\packages\core\override\
**textures
***high
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds
***medium
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds

== Further Tutorials ==

[[Tutorial: Creating recolors of existing items]] - A way to change the tint of the new texture

== Related Links ==

[[Texture Formats]] - Texture formats in detail.

[[Art Resources]] - Broad topic of Art Resources, which textures are a part of.

[[category:tutorials]]
[[Category:Textures]]

Reskinning an item tutorial

2010-12-22T10:44:45Z

Gaxkang55: /* Locating the Model Textures the Hard Way */ removed wrong "hidden filename" stuff, replaced with simpler explanation

__TOC__

This tutorial describes how to reskin, or change the default texture, of items that already exist in-game. As an example, the default textures of the human female mage's apprentice robes will be changed.

Tools needed are the Dragon Age Toolset, and a grafic editing Applications capable of Opening, Editing and Saving DDS Texture Files.

'''Note:''' The game utilizes Tints, which reuse the same Texture in colorized or tinted versions. Thus the texture in our example doesn't look quite as it does in game, and vice versa. If you edit the Texture, it won't look quite like that when put back into the game. The difference is merely color differences, so this process is limited. However, you can only change Tints, or both. See below for further tutorials.

== Locating the Model Textures the Hard Way==

At the beginning, you only know how the [[Model]] looks and what its called. A somewhat difficult task will be, finding out which files are tied to the model so that you can edit them.

'''Note:''' You may want to read it once, to understand alternative ways.

First and foremost, you are looking for DDS Files. How DDS Files are referenced by an Item you see in Game is a long list of database references.

A quick rundown on references we need to be aware of

#A DDS File is referenced by the Material Properties of a [[Model]]
#A [[Model]] is then referenced by the "ItemVariation" type of files. In our example, the sub "clothing_variation.gda"
#The different Clothing Variations are then referenced by the Item Type made via the Toolset
#The Item Type is lastly referenced by the Game, when choosing which gender and race this item is worn. And then displays the final version in your game.

-----

To track back to the DDS File, you need to run up this list in reverse. Starting up our example, the mages apprentice robe, as it is worn by human females.

#Open up the Toolset and in the Resource Palette on the upper right click on "Items" (appears as a sword icon). Now comes guessing where this piece is to be found there. These Items are pretty well sorted though, it is to be found under _global / Clothing / Mage Robes / Unique. In the following list you see the ResourceName followed by ItemName "gen_im_cth_mag_app (Apprentice Robes)". Any Item can be found in the "Item" Category. Doubleclick that entry to look inside.
#In the listing of information that appears to the left of the item, note that the "Base Item Type" is "Clothing", which is branching off into the Item Variation. The robe has a "Item Variation" called "Robe, Apprentice". Variation in mind, onto the next step.
#Open up the "ItemVariations.xls" File located under "(dragon age install directory)/tools/Source/2da/rules". It has many pages, locate page "clothing_variation" since we know our "Base Item Type" is of "Clothing". In there, locate the Row called whatever Item Variation your Item had. "Robe, Apprentice" has Namestrings followed by "rob" "app" "a".
#With these 3 Strings, and Dragon Age's [[Naming conventions|Naming Scheme]] you can find the [[MMH]] Main Modelfile.
#At the end of MMH file (extract, open and Expand All with the toolset), is the reference to the material object filename (page up two or three times from the end of the file).
#And inside the [[MAO]] File (open with Notepad) is the references to the Textures Filenames.

Spend a little time browsing through these files, and the naming convention will become clear. The armor prefixes are a compound of a "race" letter -- h, d, e, q, k(for children) and p (for person, or humanoid) -- and a gender letter -- m, f or n. Chest models are by necessity both race and usually gender specific, while textures will map to any model with the correct UV map, so usually begin with "p" and may or may not be gender specific. Once you understand the prefixes, the textures can usually be located quickly, with the item variation code followed by the part code (where applicable) followed by the texture code.

(There are some anomalies: for instance Ancient Elven Armor is listed in the toolset as Medium Armor E, but is in fact heavy armor so has an item variation code of "hvye" (it also has no tint map, being a one-off piece), but such cases are not too hard to track down once you understand the overall schema.)

== Extracting the Texture from the Package ==

Model textures are located in two "texturepack.erf" [[ERF]] packages, corresponding to high resolution and medium resolution textures. These packages can be found in the (dragon age install directory)\packages\core\textures\ folder. For example, the packages might be:

<pre>C:\Program Files\Dragon Age\packages\core\textures\high\texturepack.erf
C:\Program Files\Dragon Age\packages\core\textures\medium\texturepack.erf</pre>

Drag and drop these ERF Files onto the Toolset to browse and extract their content. If you have the Name, finding the Files will be easy. The Files will be in both "high" and "medium" and the quality setting in the game will decide which to choose. To make it compatible enough, taking them all may be neccessary.

Incidentally, high and medium texture versions are only required for certain model types. For example, heraldry and props only have one texture, and these can be found in

<pre>C:\Program Files\Dragon Age\packages\core\data\textures.erf</pre>

To prepare for extracting the textures, we must create a directory mimicking the structure of the Dragon Age packages folder. To do this, create a new folder named "textures" in a convenient location (for example, on your desktop). Inside this folder, create two new folders, named "high" and "medium". The "high" folder will be where the high-resolution textures are extracted to, and the "medium" folder will be where the medium-resolution textures are extracted to.

For this tutorial, we are interested in the mage's robes. To locate the textures of the mage's robes, scroll down to "pf_rob_appa_0d.dds" in one of the two texturepack ERFs. In each texturepack.erf, select all of the image files prefixed with "pf_rob_appa" (from "pf_rob_appa_0d.dds" to "pf_rob_appa_0tl3.dds"). For the high-resolution texturepack.erf, extract these images to the "textures\high\" folder just created. Extract the medium-resolution textures to the "textures\medium\" folder.

The Suffixes for Texturefiles are describing their Formats, which is described under [[Textureformats]].

To extract one of the textures, right-click on it and select "Extract Resource."

== Editing the Textures ==

At this stage, if we wanted to edit the existing robe textures, we could do so by changing these files. See [[Textureformats]].

Once this has been done for all of the robe textures (in both the "High" and "Medium" folders), we'll be ready to override the default textures in Dragon Age.

== Overriding the Existing Textures ==
[[Image:Demo-retexture.jpg|thumb|The end result: reskinned default mage robes.]]

Comment : this section doesn't agree with the guidance on [[Compatibility]]. Surely textures should be placed in the module's texture folder?

To override the existing textures, copy the "textures" folder containing the modified textures, and paste this folder into the Dragon Age override folder. The override folder is found in:
*Documents\BioWare\Dragon Age\packages\core\override\
for Windows Vista and 7, and in a similar location on Windows XP.

So, after pasting in the modified textures, the structure of the override folder should look like this:

*Documents\BioWare\Dragon Age\packages\core\override\
**textures
***high
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds
***medium
****pf_rob_appa_0d.dds
****(...)
****pf_rob_appa_0tl3.dds

== Further Tutorials ==

[[Tutorial: Creating recolors of existing items]] - A way to change the tint of the new texture

== Related Links ==

[[Texture Formats]] - Texture formats in detail.

[[Art Resources]] - Broad topic of Art Resources, which textures are a part of.

[[category:tutorials]]
[[Category:Textures]]

High-Level Character Generation

2010-12-22T09:44:09Z

Gaxkang55: /* Editing the module_core */

Note: This is a draft. Let me know on the BSN forum thread if these don't work or I'm unclear on what must be done.

BSN thread: http://social.bioware.com/forum/1/topic/71/index/5020925

==Introduction==
In the Awakening and post-Awakening DLC, anyone who created a new character may have noticed that the character generation screen didn't start at level 1. With this tutorial, custom modules made by players will be able to have similar funtionality.

==Creating the scripts==
First, it is very important that you DUPLICATE the important core scripts. By creating your own scripts, you won't have to worry about screwing the official campaign or other modules.

The scripts that must be duplicated for this tutorial:
- module_core
- sys_chargen_h
- sys_chargen

If you already have duplicates of these for other systems/tutorials (such as the background tutorial), make your edits in those files.

When you duplicate the files, make sure that the names are unique while still naming their purpose for easy editing. For example, you might add a module-specific prefix:
- scar_module_core
- scar_sys_chargen_h
- scar_sys_chargen

==Editing the sys_chargen_h file==
The first thing you want to do is avoid duplicate functions, as this confuses the compiler. You won't need or want to edit every function, so at the top of the file place another include:

#include "sys_chargen_h"

For this tutorial, you can delete everything except the "Chargen_InitializeCharacter" function. (Leave any functions that you may have edited, but don't forget to integrate them when necessary.)

Next you need to create a new name for this function. I suggest the prefix you used for the script files:

scar_Chargen_InitializeCharacter

Near the top of the function you should see a group of lines that look like this:

// -------------------------------------------------------------------------
// 2. Set Creature to Level and Experience 0
// -------------------------------------------------------------------------
SetCreatureProperty(oChar,PROPERTY_SIMPLE_LEVEL,1.0f,PROPERTY_VALUE_BASE);
SetCreatureProperty(oChar,PROPERTY_SIMPLE_EXPERIENCE,0.0f,PROPERTY_VALUE_BASE);

Set the level and XP to the appropriate values for your starting level. (You can give less XP, forcing a character to gain that extra XP before leveling. This does not affect companions.)

You also need to find this group:

// -------------------------------------------------------------------------
// 6. Set up points available to distribute (skills only on humanoids)
// -------------------------------------------------------------------------
if (IsHumanoid(oChar))
{
SetCreatureProperty(oChar,PROPERTY_SIMPLE_SKILL_POINTS, 1.0, PROPERTY_VALUE_BASE);
}
SetCreatureProperty(oChar,PROPERTY_SIMPLE_ATTRIBUTE_POINTS, 5.0, PROPERTY_VALUE_BASE);
SetCreatureProperty(oChar,PROPERTY_SIMPLE_TALENT_POINTS, 2.0, PROPERTY_VALUE_BASE);

And set the values to the appropriate level (or give more/less that usual for certain modules.)

==Editing the sys_chargen file==
Now that the include file is created, open the sys_chargen file. Make sure that you have both chargen includes. For example:

#include "sys_chargen_h"
#include "scar_sys_chargen_h"

This will keep normal functions from breaking.

Find and replace all "Chargen_InitializeCharacter" functions with your custom function. This will start your character at the appropriate level.

There is a bug that occurs during "Quick-Start" unless another step is taken. Find all instances of "AL_DoAutoLevelUp". (There should be two in an unedited file.)

The function that causes the problem looks like this:

AL_DoAutoLevelUp(oChar, TRUE, TRUE);

Either set both trues to falses or copy/paste the other function to this space.

==Editing the module_core==
The home stretch. Now we have to associate the module chargen script with our custom script.

Near the bottom of an unedited script, you should find:

// -----------------------------------------------------------------
// Handle character generation events sent by the engine.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END) || nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"sys_chargen.ncs");
}

Switch the script handling the event to your custom script.
===An alternative view===

Editing the module_core script is almost certainly a bad idea, and is probably not even what was intended. But to be crystal clear, this code should be placed in your own module script (see next section), with appropriate modification (depending on how you have defined your event variables in that script). For example, if your module script initialisations are:
<dascript>event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
int bEventHandled = FALSE;</dascript>

then you will need:
<dascript>default:
{
if ((nEventType >= EVENT_TYPE_CHARGEN_START && nEventType <= EVENT_TYPE_CHARGEN_END) || nEventType == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"scar_sys_chargen.ncs");
bEventHandled = TRUE;
}
break;
}</dascript>

==Calling the custom module script==
For those who don't know, a module script now must be associated with the module itself. This is done through [File->Manage Modules->Poperties]. Make sure you have your module selected before you hit properties.

Underneath the module name, there should be a parameter named "Script". Enter the browser and select your custom module_core script. Once you're finished eidting the module, click OK.

==Final steps==
Unless you already have the function in your module_core, you need to actually run character generation.

Under "EVENT_TYPE_MODULE_START", add these lines:

PreloadCharGen();
StartCharGen(GetHero());

==Export and Test==
Make sure you save each file along the way, and compile all scripts once finished. Export the scripts and play your module. You should begin character generation at the appropriate level.

High-Level Character Generation

2010-12-22T09:39:30Z

Gaxkang55: /* Editing the module_core */

Note: This is a draft. Let me know on the BSN forum thread if these don't work or I'm unclear on what must be done.

BSN thread: http://social.bioware.com/forum/1/topic/71/index/5020925

==Introduction==
In the Awakening and post-Awakening DLC, anyone who created a new character may have noticed that the character generation screen didn't start at level 1. With this tutorial, custom modules made by players will be able to have similar funtionality.

==Creating the scripts==
First, it is very important that you DUPLICATE the important core scripts. By creating your own scripts, you won't have to worry about screwing the official campaign or other modules.

The scripts that must be duplicated for this tutorial:
- module_core
- sys_chargen_h
- sys_chargen

If you already have duplicates of these for other systems/tutorials (such as the background tutorial), make your edits in those files.

When you duplicate the files, make sure that the names are unique while still naming their purpose for easy editing. For example, you might add a module-specific prefix:
- scar_module_core
- scar_sys_chargen_h
- scar_sys_chargen

==Editing the sys_chargen_h file==
The first thing you want to do is avoid duplicate functions, as this confuses the compiler. You won't need or want to edit every function, so at the top of the file place another include:

#include "sys_chargen_h"

For this tutorial, you can delete everything except the "Chargen_InitializeCharacter" function. (Leave any functions that you may have edited, but don't forget to integrate them when necessary.)

Next you need to create a new name for this function. I suggest the prefix you used for the script files:

scar_Chargen_InitializeCharacter

Near the top of the function you should see a group of lines that look like this:

// -------------------------------------------------------------------------
// 2. Set Creature to Level and Experience 0
// -------------------------------------------------------------------------
SetCreatureProperty(oChar,PROPERTY_SIMPLE_LEVEL,1.0f,PROPERTY_VALUE_BASE);
SetCreatureProperty(oChar,PROPERTY_SIMPLE_EXPERIENCE,0.0f,PROPERTY_VALUE_BASE);

Set the level and XP to the appropriate values for your starting level. (You can give less XP, forcing a character to gain that extra XP before leveling. This does not affect companions.)

You also need to find this group:

// -------------------------------------------------------------------------
// 6. Set up points available to distribute (skills only on humanoids)
// -------------------------------------------------------------------------
if (IsHumanoid(oChar))
{
SetCreatureProperty(oChar,PROPERTY_SIMPLE_SKILL_POINTS, 1.0, PROPERTY_VALUE_BASE);
}
SetCreatureProperty(oChar,PROPERTY_SIMPLE_ATTRIBUTE_POINTS, 5.0, PROPERTY_VALUE_BASE);
SetCreatureProperty(oChar,PROPERTY_SIMPLE_TALENT_POINTS, 2.0, PROPERTY_VALUE_BASE);

And set the values to the appropriate level (or give more/less that usual for certain modules.)

==Editing the sys_chargen file==
Now that the include file is created, open the sys_chargen file. Make sure that you have both chargen includes. For example:

#include "sys_chargen_h"
#include "scar_sys_chargen_h"

This will keep normal functions from breaking.

Find and replace all "Chargen_InitializeCharacter" functions with your custom function. This will start your character at the appropriate level.

There is a bug that occurs during "Quick-Start" unless another step is taken. Find all instances of "AL_DoAutoLevelUp". (There should be two in an unedited file.)

The function that causes the problem looks like this:

AL_DoAutoLevelUp(oChar, TRUE, TRUE);

Either set both trues to falses or copy/paste the other function to this space.

==Editing the module_core==
The home stretch. Now we have to associate the module chargen script with our custom script.

Near the bottom of an unedited script, you should find:

// -----------------------------------------------------------------
// Handle character generation events sent by the engine.
// -----------------------------------------------------------------
if ((nEvent >= EVENT_TYPE_CHARGEN_START && nEvent <= EVENT_TYPE_CHARGEN_END) || nEvent == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"sys_chargen.ncs");
}

Switch the script handling the event to your custom script.
===An alternative view===

Editing the module_core script is almost certainly a bad idea. This code should be placed in your own module script (see next section), with appropriate modification (depending on how you have defined your event variables in that script). For example, if your module script initialisations are:
<dascript>event ev = GetCurrentEvent();
int nEventType = GetEventType(ev);
int bEventHandled = FALSE;</dascript>

then you will need:
<dascript>default:
{
if ((nEventType >= EVENT_TYPE_CHARGEN_START && nEventType <= EVENT_TYPE_CHARGEN_END) || nEventType == EVENT_TYPE_PLAYERLEVELUP )
{
HandleEvent(ev, R"scar_sys_chargen.ncs");
bEventHandled = TRUE;
}
break;
}</dascript>

==Calling the custom module script==
For those who don't know, a module script now must be associated with the module itself. This is done through [File->Manage Modules->Poperties]. Make sure you have your module selected before you hit properties.

Underneath the module name, there should be a parameter named "Script". Enter the browser and select your custom module_core script. Once you're finished eidting the module, click OK.

==Final steps==
Unless you already have the function in your module_core, you need to actually run character generation.

Under "EVENT_TYPE_MODULE_START", add these lines:

PreloadCharGen();
StartCharGen(GetHero());

==Export and Test==
Make sure you save each file along the way, and compile all scripts once finished. Export the scripts and play your module. You should begin character generation at the appropriate level.

Talk:Reskinning an item tutorial

2010-12-15T11:30:56Z

Gaxkang55: /* Complete nonsense */ new section

Thanks for the tutorial on reskinning an item!

One question: How do I ''recolor'' a texture? The colors that the characters are wearing in-game seem to have nothing to do with the colors of the textures in the .dds files.

The main mage robe texture file, pf_rob_appb_0dl2.dds, has very little color, and if I recolor it, as you'd expect, nothing happens. And if I look at pf_rob_appb_0t.dds, it's intense shades of red, blue, and green, which seem designed to tell the game where to put various colors, rather than which colors those are. So where do the specific colors come from?

I've recolored a lot of files for ''The Witcher,'' so I know how to recolor a .dds file. But in ''The Witcher,'' you get whatever color you've made the texture. Where are the colors stored for ''Dragon Age''?

My mage has an orange-and-green set of robes, and I'd like a different color scheme.

Thanks!

Corylea
:You'll want to read up on the [[Material Tint System]] and check out [[Tutorial:_Creating_recolors_of_existing_items|this tutorial]] and [[Tutorial:_Understanding_Tints:_Overriding_Defaults_&_Creating_New_Ones|this tutorial]] on tinting. [[User:Nezroy|Nezroy]] 18:00, 26 February 2010 (UTC)

Where are the files for the Blood Dragon Armor called?

What program do you use to open the ERFs?
---Skyintheeye
:The toolset can open ERFs. Just use the File->Open command and locate the ERF to open. Then right-click on a file in the list and select "Extract Resource" (or alternatively you can use "Extract All Resources" to dump the contents of the entire ERF somewhere). [[User:Nezroy|Nezroy]] 18:01, 26 February 2010 (UTC)

== Complete nonsense ==

This "tutorial" states "In this File is a hidden reference to the MAO Material file." referring to the MMH file. Rubbish. The material object filename is towards the end of the MMH. This, and what follows, is seriously misleading. Will fix when I get some time. --[[User:Gaxkang55|Gaxkang55]] 11:30, 15 December 2010 (UTC)

Talk:Creating a custom placeable from a model tutorial

2010-12-11T12:13:20Z

Gaxkang55: Created page with 'This was never going to work without changing the name the material object file in the MMH. Have now fixed. ~~~~'

This was never going to work without changing the name the material object file in the MMH. Have now fixed. [[User:Gaxkang55|Gaxkang55]] 12:13, 11 December 2010 (UTC)

Creating a custom placeable from a model tutorial

2010-12-11T12:09:14Z

Gaxkang55: /* Edit your MMH and PHY files */ Added line on material object reference in the MMH.

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

__TOC__

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

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

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

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

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

Create your [[GDA]] file using Excel Processor and put it in Dragon Age/packages/core/override. See [[compiling 2DAs]] for details on how.

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

==Extract model files==

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

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

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

== Edit your MAO file ==

Open the MAO file using a text editor like Notepad.

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

== Edit your MMH and PHY files ==

Launch the Toolset.

Open the new MMH file. Change MMH_NAME to match your new MMH file name. Towards the end of the MMF is a field for material object, which needs to be changed to the name of your new MAO file. Save and close the MMH file.

Open your new PHY file.

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

Close your toolset.

== Put files in override folder ==

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

== Create your custom placeable ==

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

Follower tutorial

2010-12-11T11:59:17Z

Gaxkang55: /* Step 3: Create package GDAs and reference them in you 2DA_base extension */ equipment mask line

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

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. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
(Note: Be aware if you use the name UT_HireFollower_Fixed you may end up finding your include file conflicting with someone else who has named it the same in their include.)

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

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

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

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

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

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

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

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

====Dog talents don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots.

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

====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)
{
UT_HireFollower(oFollower);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
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())));
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.

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

2010-12-11T11:50:15Z

Gaxkang55: Added line on portraits gda

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

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. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
(Note: Be aware if you use the name UT_HireFollower_Fixed you may end up finding your include file conflicting with someone else who has named it the same in their include.)

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

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

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

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

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

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

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

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

====Dog talents don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots.

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

====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)
{
UT_HireFollower(oFollower);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
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())));
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.

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

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

2010-12-11T10:59:21Z

Gaxkang55:

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

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. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
(Note: Be aware if you use the name UT_HireFollower_Fixed you may end up finding your include file conflicting with someone else who has named it the same in their include.)

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

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

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

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

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

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

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

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

====Dog talents don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots.

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

====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)
{
UT_HireFollower(oFollower);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
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())));
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.

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

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

2010-12-04T16:59:00Z

Gaxkang55: addition of Alternative Approach section

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

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. For now the best/easiest approach to take might be to make a copy of UT_HireFollower in an include file and rename it something like UT_HireFollower_Fixed, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
(Note: Be aware if you use the name UT_HireFollower_Fixed you may end up finding your include file conflicting with someone else who has named it the same in their include.)

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

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

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

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

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

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

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

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

====Dog talents don't work====
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots.

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

====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)
{
UT_HireFollower(oFollower);
SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0);
AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero())));
SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE);
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())));
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.

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

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

User:Gaxkang55

2010-12-04T16:53:10Z

Gaxkang55:

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

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

User:Gaxkang55

2010-12-04T16:36:42Z

Gaxkang55: Created page with '== 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 perfe...'

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

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

Talk:Follower tutorial

2010-10-21T09:38:17Z

Gaxkang55: /* Dog equipment slots */ new section

great tutorial. my only problem is: my companion, Erik has different skills and doesn't seem to follow his autolevel template. --[[User:Mono0x32440|Mono0x32440]] 17:46, 25 February 2010 (UTC)

== Follower's Portrait ==

I cannot figure out how to change the default grey backgrounded portrait for the new followers. It would be nice to have pose and background options.

== Dog equipment slots ==

Mention should be made of the fact that a dog follower needs to have the appropriate equipment slot mask. I will make the addition to the text if no-one has any objections/suggestions in a couple of days. --[[User:Gaxkang55|Gaxkang55]] 09:38, 21 October 2010 (UTC)