• 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

Conditional bootstrapping?

barrelv

Well-known member
Does anyone have an example of how to conditionally bootstrap things based on a drop-down selection? I'm getting stuck on what has to happen inside of the containerreq section. For example, this doesn't work in the least.

Code:
  <bootstrap thing="skArchery">
    <containerreq phase="Setup" priority="5000">
    compare("Archery",field[arSelect1].text)=0
    </containerreq>
  </bootstrap>

In the system I'm working on, you can pick your combat skill when you add certain careers. So if someone picks "Highwayman", I need them to be able to then decide if they should have the Archery or Pistol skill as a starting skill.
 
not sure if it's different in the authoring kit, but when I'm doing conditionals like that in Pathfinder I assign a tag based on each selectiong (if statements using field[usrChosen1].chosen.tagis[XXX.XXX]) and then check for the tag in the conditional.
 
I think I'm mis-understanding it. So what are you applying the TAG to? the thing you want to bootstrap? or the container you're bootstraping to?

still having a lot of problem with this. I just might be going about it completely wrong. and it's one of the last things I need to finalize.

Is there some other method I should try?
 
For the rule you're describing, I don't think conditional bootstraps are the best way to handle that. Personally, I'd add a "Career Skill" table - that table doesn't use a candidate expression on the table, it instead uses a candidate field on the hero. The career you add sets up that field's expression, based on the skills it offers.

Then, the user will open that table, see only those skills offered by the career they picked, and pick one of them.
 
I think I'm following you.

Does this table have to be outside of the existing table_dynamic table that I'm using to add the Career? For example it would have to be another table below the career pick table that would appear when things got populated by the career choice?
 
Correct, you can't have one table inside another, so it'll need to be separate.

Although there's now a new option if there's never going to be a career that gets to choose more than one skill - chooser_tables can now be placed inside the pick templates that are used in a table_dynamic.
 
There are a few that can pick a few things. Some get a starting skill and a starting weapon choice. And there's at least one where it's "Pick 2 of these 4 skills"
 
So sounds like the chooser isn't going to work, since that is for cases where there's always exactly one of something, like choosing a race. Sounds like separate tables will be the way to go.
 
... that table doesn't use a candidate expression on the table, it instead uses a candidate field on the hero. The career you add sets up that field's expression, based on the skills it offers.

Can you offer some clarification here?
 
First, get a basic table set up that offers a choice of all the skills in the game.

Then, take a look at what can be defined in a table: http://hlkitwiki.wolflair.com/index.php5?title=TableDynamic_Element_(Data)

You want to set a candidatepick="actor" and set candidatefield = a text field on the hero.

Then, you want to set up a script on your Career component that can fill in that text field on the hero with an expression that restricts the table to only those skills allowed by this career.
 
Since I think we've hit a wall in what I think is a follow-up thread for this project, could you please give me more detail about what "career skill" means in rules terms for this game?

I need to fully understand the rule you're trying to implement before I can recommend the best way to go about it.
 
okay, here's the full rule breakdown:

When you start a new character in Iron Kingdoms, you pick 2 careers. Things like "Pistoleer" and "Explorer". In terms of skills, these two careers have a list of skills you can purchase as the character advances, as well as predefined starting ranks in certain skills.

For certain classes, such as an Explorer or Soldier, you get to choose what your starting skills will be. For example, an Explorer gets to choose 1 Military skill from a defined list of 4. A Soldier gets to choose 2 from the entire list of Military skills.

Other classes do not. A Pistoleer, for example, starts with Pistols at rank 1. But, if he's also a Soldier and picks Pistols as his starting skill for Soldier, he now has 2 ranks of Pistol.

Now, to make things really messy, a character will get additional careers later during advancement and these careers *do not* provide skills levels, either automatically (like with the Pistoleer) or with choice (like the Soldier).

Does that make sense?
 
So there's a defined number of career skills that can ever be chosen for any character (and that defined number is reasonable - 4 is what I think I'm reading)?

That may mean that candidate fields become reasonable again - there'd simply be four different expressions stored on the hero.
 
Also, "Career skill" means "add 1 free rank to this skill"? In that case, would it work to have the user add skills to the skill list, and then use a drop-down to select which one gets the bonus on the career?
 
Also, "Career skill" means "add 1 free rank to this skill"? In that case, would it work to have the user add skills to the skill list, and then use a drop-down to select which one gets the bonus on the career?
so an original thought I had was to have the original 2 careers bootstrap every skill they allowed the hero to take at level 0 and then use a menu drop-down to increase the prereq skills.
 
So there's a defined number of career skills that can ever be chosen for any character (and that defined number is reasonable - 4 is what I think I'm reading)?

That may mean that candidate fields become reasonable again - there'd simply be four different expressions stored on the hero.

maybe - but careers can be added in any order. so a Pistoleer/Soldier is exactly the same as a Soldier/Pistoleer. not sure how the career would know which of the four lists to write the restrictions to.

I'm going to ponder on Skills and Careers for a few days while working on this like weapons and spells and combat stats.
 
So, for now I have the following process that seems to be work.

  • The career bootstraps every skill that it allows the Hero to use
  • The skills bootstrap with a 0 minimum instead of a 1
  • I have a Menu_Array on the Career screen that points to an array attached to the career object
  • I'm using "foreach pick in hero where "Skill.?" to cycle through the skills attached to the hero for a matching name to the current selection in the menu_array and increase that skill's min value by 1

the only major drawback I've ran into is that as you switch from one skill to another in the menu array, it adds the min value every time, which means you end up over-spending your skill points. It's an easy problem to fix, just click the back-arrow to get back to the right number per skill. But any suggestions here would be appreciated.
 
Back
Top