• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Bootstrapping a minion

F

frumple

Well-known member
I am trying to implement a class special that bootstraps a minion. The problem is that when I load the class the minion is boostrapped even though the class special that bootstraps occurs at a later level.

I figured I could put a condition on the race of the minion being bootstraped via something like this:

Code in the class:
Code: 
First/40
if (hero.childfound[IDofCLASSSpecial].tagis[Helper.SpcDisable] <> 0) then

 perform hero.assign[Custom.BootMin]

endif

then on the minion race have the following condition
Code in racial special:
Code: 
First/45
hero#Custom.BootMin

However this is not working. ideas?
 
Umm. That is not what I am looking for. I am looking for an example of conditionally bootstrapping a minion, not a feat. :)

I am finding that minions are much more complex. Looks like the code I wrote above does work, but it prevents the race that is designated aas the minion from being bootstraped. The minion itself is not affected. So I guess what I am looking for is a way to make the minion live/nonlive depending of the number of levels I have in a class.
 
Last edited:
I was saying if you want to bootstrap the minion at a later level, using count:Classes.WHATEVER >= X would make it bootstrap at a later level.
 
If your bootstrap condition is on the minion race, then it's looking at the tags in the hero context of the minion, not the master, but you're assigning your Custom tag to the hero context of the master.
 
But getting rid of the race on the minion doesn't remove that character from the dashboard - all it would do would be to remove the race.
 
Re: tag on race
Yeah, I just figured that out. :/ I guess I need a way to make the minion live/not-live. I see there is a field on the minion tab called "Minion Live Field." I have been playing with this, but can't seem to get it to work.

Re: what I mean by minion
Kind of, but this particular minion follows different rules than your typical familiar. The class gets multiple familiar, but they do not follow the same rules for multiple familiars as is implemented for classes/archetypes like the broodmaster, etc. These guys have most of their stats fixed as 1/3 of the character's. I figured it would be easier to manually calculate all the modifications necessary for the familiar that trying to "hack" the arcane familiar class.
 
Why do you need to control the live state, then? If the user doesn't want that familiar, they simply won't add it.
 
It gets auto added. The class automatically gets these "familiars" (it is a specific race type, the user doesn't have a choice of the matter) at 1st, 9th and 17th levels pf the class.

My problem is that all three get added immediately. I want the first to show up at 1st level, the 2nd at 9th and the last one at 17th.
 
Don't auto add them. Add an eval rule that complains if the user hasn't added enough familiar choices for that particular level.
 
The issue is that these minions are familiars in name only. They do not follow the established rules for familiars and multiple familairs, i.e. the ArcFamiliar class or MultiFamiliar. Because of this I am adding via this method since making a new kind of familiar class is not an option (since we don't have access to the code that makes familiar classes).

The rules these minions follow (which would normally be part of the familiar class if they were typical familiars) are implemented as scripts on the race. I did it this way because only this one particular custom race is used as a "familiar" for this class.

I am adding the minion to the character as part of three separate class specials that is made active at the specific level.

Everything is working except that the class loads up all three minions at 1st level. I need the minions to be live only if its associated class special is "active," not grayed out.
 
My suggestion still stands - use the multi-familiar option, but let the user add each new familiar at the correct level - don't bootstrap the three familiars.
 
I've tried doing that. It doesn't work in this case due to the differences between how these guys work and the typical multiple familiars.
 
Could you please give me more information than "doesn't work"? I'd like to figure out if there's a better way to handle this, but I don't know enough about what you're trying to accomplish.
 
Sure. The issue as I see it is two fold.

1) Since each familiar is 1/3 of the character's HD, saves, etc. the usual method of assigning levels in a multi-familiar doesn't work. In some ways they are simplier than the usual multi-familair. Each one needs to have exactly 1/3 of the character's class levels (min 1) rounded down. Either there are not enough class levels to assign or to few. I guess this can be gotten around if there was a way to change the maximum number of levels assigned as well as force the number we need.

2) These guys do not use the cArcFamil class. They have their own progression and calculations of BAB, HP, etc. that is quite different than the standard arcane familiar. Ideally, I would approach this my making a new familiar class and a new multi-familiar handler just for these guys, but since that code is closed and can't be selected in the editor I have no idea how to do this even in raw XML.
 
1) The number of levels a multi-familiar can be assigned can be modified by adjusting the CompClAdj field. Just calculate the difference between the level and (1/3 the level, rounded down, min 1) * 3, and add or subtract that difference so that the total familiar levels to be assigned comes out correctly.

2) You'll need scripts that can overwrite almost everything about it. You need scripts to calculate 1/3 of everything anyway, so it's not much harder to overwrite the familiar information while you're setting those 1/3 values.
 
Mathias, is there a way to turn off the error that the levels assigned to all Familiars is less than your total familiar level? I am getting the level assignment right, but I cannot satisfy that error.
 
You must log in or register to reply here.
Back
Top