Follower tutorial
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
Contents
- 1 Prepare Creature, char_stage and Party Picker m2DAs
- 2 Create Party Plot
- 3 Add Plot Flags to Party Picker Event Intercept
- 4 Create a Level Up Template
- 5 Create a New Hire Function Include
- 6 Include Function In Your Hire Script and Call It
- 7 Common Follower Problems & FAQ
- 7.1 Why don't my followers gain XP?
- 7.2 When I choose followers from the Party Picker, they spawn into the area but do not join
- 7.3 My followers don't have skill trees!
- 7.4 My followers don't have a class
- 7.5 Dog talents and equipment slots don't work
- 7.6 Isn't there an easier way to do this?
- 7.7 What if there are more than three potential followers?
- 7.8 How do I turn off sustained abilities when a follower is dismissed?
Prepare Creature, char_stage and Party Picker m2DAs
Follow the same steps to create your follower creature, char_stage and Party Picker m2DAs as you did in the basic follower tutorial.
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:
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:
#include "utility_h" #include "wrappers_h" #include "plt_bc_create_party" //make sure you include your own plot, not mine void main() { event ev = GetCurrentEvent(); int nEventType = GetEventType(ev); switch(nEventType) { case EVENT_TYPE_PARTYMEMBER_ADDED: { object oFollower = GetEventObject(ev, 0); SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); //Ensures follower appears at PC's location. if (GetTag(oFollower) == "bc_party_miera") { //You must explicitly test for your follower's tag. WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, TRUE); //Make sure you use your own flags! } break; } case EVENT_TYPE_PARTYMEMBER_DROPPED: { object oFollower = GetEventObject(ev, 0); if (GetTag(oFollower) == "bc_party_miera") { WR_SetPlotFlag(PLT_BC_CREATE_PARTY, PARTY_MIERA_IN_PARTY, FALSE); //As above, but set false. } } } }
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:
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:
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.
We decide we'd prefer Flame Blast, so we find it in columns B&C and copy both cells:
Then we select the cells we want to replace in columns D&E and paste over them:
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!):
The ID should be very high to avoid conflicts. I've arbitrarily chosen 50,000+ here. Carefully note the ID you've chosen for your character, you will need it later.
Set the Label and Worksheet to be the name of your autolevel template worksheet (ALCharactername if you've been following this).
Set the PackageIDForAI to be 0, it shouldn't be needed for followers.
When you're done, use ExcelProcessor to make GDAs of both spreadsheets and copy them to your module's export folder.
FOR AUTOLEVEL TO WORK AFTER RECRUITING:
Look in packages.xls.
There is a column called LevelupTable. That links to a corresponding AL* table. For instance, row 81 is for Leliana. Her LevelupTable value is 258. If you look that up in 2DA_base, you'll see it links to ALLeliana.
(alternatively, you could try packages_base.gda)
Create a New Hire Function Include
This section is probably only relevent if you have a specific need to override the functionality of player_core.
Many vital steps of follower addition happen inside an event in player_core. Followers tend to be extremely buggy (no skill tree, for example) if this event does not fire.
However, that event is not very flexible. In order to control it to our requirements, we need to replicate its functionality inside our own script. This is probably much safer than messing with player_core directly!
Create a new script file, naming it something like hireCustomFollower_h. We will be including this wherever we want to hire a follower.
Paste in the following script:
#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); string sTag = GetTag(oFollower); if(sTag == "bc_party_miera") { nTable = 50143; } else if(sTag == "bc_party_jysavin") { nTable = 50144; } else if(sTag == "bc_party_geldual") { nTable = 50145; } else if(sTag == "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 is not specified, checks package 2DA for a value if(nMinLevel == 0) { 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(); } }
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:
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; }
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:
#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(); }
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!
Common Follower Problems & FAQ
Why don't my followers gain XP?
There is a bug in UT_HireFollower. Make a copy of UT_HireFollower in a function of your own, then make the following change:
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, TRUE);
to
WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, bPreventLevelup);
When I choose followers from the Party Picker, they spawn into the area but do not join
You need to intercept the EVENT_TYPE_PARTYMEMBER_ADDED event and set the follower to FOLLOWER_STATE_ACTIVE. See Simple Follower Creation earlier in this document.
My followers don't have skill trees!
If a follower hasn't been through an initial chargen/autolevel event (via player_core/sys_autolevel_h) then the skill tree doesn't show. You're probably trying to be clever and get around UT_HireFollower without going all the way (see monster function above ^_^).
My followers don't have a class
GetCreatureCoreClass() seems flaky under some conditions. It's best to explicitly set the class yourself; this is why class is currently a mandatory argument to hireCustomFollower()
Dog talents and equipment slots don't work
Symptoms: dog talents appear on the talents screen but remain greyed out on level up. Warrior talents appear in the quickslots. Equipment slots are for humans, not dogs.
Line 78 of packages_base in packages.xls (Dog) should have the LevelUpTable column set to 257 which is the ALDog table.
The EquipmentLayout 2DA needs a new entry for the follower:
ID=same as partypicker 2DA Tag=follower tag AvailableEquipmentSlots=794624 Layout=2 EnableWeaponSets=0
If the creature is not using the appearance "Dog, Party Member", it needs a new appearance line in APR_base. Most of the entries can be copied from the standard appearance (e.g. Wolf), but
MaxScaleLevel=-1 DefaultArmor= AppearanceRestrictionGroup=1
Otherwise, it won't be able to progress beyond a specified level. The player will receive an unwanted set of armour when the it is hired, and it won't be able to use Marabi crunch items. You may also need to tweak PERSPACE and/or BumpLevel if excessive clipping occurs.
Isn't there an easier way to do this?
Possibly. There is a way of recruiting a follower by setting a plot flag. However I don't understand it, and I expect it still doesn't allow custom autolevel templates, full control over specialisations etc. There's still a fair bit of stuff hardcoded for the core followers, I'm not sure putting a custom follower through the same process as Al, Leli et al will have good results.
The next section answers this question, up to a point.
What if there are more than three potential followers?
This example handles larger numbers of followers, and doesn't force the player to use the party picker unless the party is already full.
The prefix zzz, used throughout, can be replaced with whatever 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.
// 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; }
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.
// PARTY HIRE PLOT SCRIPT // // This is called in conversation when a party member is hired for the first time. // If the party is full, the party picker is displayed, which forces the PARTYMEMBER_ADDED // module event. // // The flag value is never referenced, because the code is common for all party members. #include "events_h" #include "global_objects_h" #include "utility_h" #include "sys_rewards_h" #include "log_h" #include "utility_h" #include "wrappers_h" #include "plot_h" #include "zzz_h" // A header containing the zzzPartyMemberID function #include "plt_zzzpt_hired" #include "plt_zzzpt_party" int StartingConditional() { event eParms = GetCurrentEvent(); int nType = GetEventType(eParms); // GET or SET string strPlot = GetEventString(eParms, 0); // Plot GUID int nFlag = GetEventInteger(eParms, 1); // Plot flag object oParty = GetEventCreator(eParms); // Plot table owner object oFollower = GetEventObject(eParms, 0); // Conversation owner (if any) int nPlotType = GetEventInteger(eParms, 5); // Plot type int bIsTutorial = GetM2DAInt(TABLE_PLOT_TYPES, "IsTutorial", nPlotType); int bIsCodex = GetM2DAInt(TABLE_PLOT_TYPES, "IsCodex", nPlotType); int nResult = FALSE; // return value for DEFINED GET object oPC = GetPartyLeader(); plot_GlobalPlotHandler(eParms); // any global plot operations, including debug info if (nType == EVENT_TYPE_SET_PLOT) // actions -> normal flags only { int nValue = GetEventInteger(eParms, 2); // 0=Clear 1=Set int nOldValue = GetEventInteger(eParms, 3); // Current flag value if (nValue) { if (GetArraySize(GetPartyList(oPC)) < 4) { // Code from UT_HireFollower with level up bug fixed SetAutoLevelUp(oFollower, 2); SetGroupId(oFollower, GetGroupId(GetHero())); WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE, TRUE, 0, FALSE); // End of code from UT_HireFollower AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE); } else { WR_SetFollowerState(oFollower, FOLLOWER_STATE_AVAILABLE, FALSE); SetEventScript(oFollower, RESOURCE_SCRIPT_PLAYER_CORE); SendPartyMemberHiredEvent(oFollower, TRUE); // SetPartyPickerGUIStatus(PP_GUI_STATUS_USE); // ShowPartyPickerGUI(); } } } else // EVENT_TYPE_GET_PLOT -> defined conditions only { switch(nFlag) { } } plot_OutputDefinedFlag(eParms, nResult); return nResult; }
We still need to handle the party picker events in our module event script:
// PARTY MEMBER ADDED - Allow XP gain. Come here, follow me, flag as party member. case EVENT_TYPE_PARTYMEMBER_ADDED: { object oFollower = GetEventObject(ev, 0); SetLocalInt(oFollower, CREATURE_REWARD_FLAGS, 0); AddCommand(oFollower, CommandJumpToLocation(GetLocation(GetHero()))); WR_SetFollowerState(oFollower, FOLLOWER_STATE_ACTIVE); WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), TRUE); break; } // PARTY MEMBER DROPPED - flag as not party member. case EVENT_TYPE_PARTYMEMBER_DROPPED: { object oFollower = GetEventObject(ev, 0); WR_SetPlotFlag(PLT_ZZZPT_PARTY, zzzPartyMemberID(oFollower), FALSE); }
When we need to refer to a particular follower explicitly, we can still do so - for example, the flag ZZZPT_PARTY_GODWIN will tell use whether Godwin is currently in the party or not.
How do I turn off sustained abilities when a follower is dismissed?
Please note: The 1.04 DA:O patch is bugged and removed/broke several features of the toolkit, if you are using it please follow these steps to re-enable them as one is required for the script below to compile.
There is a potential exploit in what we've done so far. If a follower casts a sustained spell like Flaming Weapons, it affects all party members. When the follower is dismissed, the remaining party members continue to benefit from the spell.
We can prevent this by deactivating modal abilities before opening the party picker. Add these snippets to the module event script:
#include "ability_h" void zDeactivateModalAbilities();
and
The function looks like this:
// Deactivate party's modal abilities void zDeactivateModalAbilities() { object oPC = GetHero(); object[] oFollowerTable = GetPartyList(oPC); object oFollower; int nPartySize = GetArraySize(oFollowerTable); int[] nAbilityTable; int nAbilityCount; int nAbility; int i = -1; int j; while (++i < nPartySize) { oFollower = oFollowerTable[i]; nAbilityTable = GetAbilityList(oFollower); nAbilityCount = GetArraySize(nAbilityTable); j = -1; while (++j < nAbilityCount) { nAbility = nAbilityTable[j]; if (Ability_IsAbilityActive(oFollower, nAbility)) if (Ability_IsModalAbility(nAbility)) Ability_DeactivateModalAbility(oFollower, nAbility); } } }
If other ways of dismissing party members are permitted, the same function can be used.
