Things are mutually exclusive within a table, but not later

[Mathias]

Here's what I'm trying to enter:

A thing adds the following:
Skill A
Skill B
Skill C or Skill D
skill E or Skill F

a different version of the same thing adds:
Skill A
Skill B
Skill C
Skill D or Skill E

I've got the fixed skills working (bootstrap them with an autotag that tells a <list> statement to show them in this table as well as the general skill table).

I can generate a candidate tag expression (placed in a herofield) that correctly offers skills C-F in the first case, or skills D-E in the second case. My problem is getting it to keep the user from selecting both C and D.

I've tried writing a candidate expression checking the count of a tag, I've tried a denytag expression (please add more description to the needtag/denytag section of the wiki).

I know a pre-req could prevent one item from being selected if the other was selected, but it's legal to buy the skill(s) not taken later in character creation.

I could also get around this by having multiple choosers, but I think it looks better to display all the skills granted by this thing in one table.

 

[rob]

Let me make sure I'm understanding the problem. You have a compset from which various things are derived. Each of these things represents a profession, race, or something similar. You also have a separate compset for skills. Each thing from the Profession compset dictates the set of skills that can be chosen as part of that profession. Correct?

If you are using a single list for selection, there is no reasonable way to enforce separate mutual exclusion rules. With some hassle, you could enforce it in the code, but the result would be confusing for users. If you saw a list with options C thru F in it, then chose C, and D mysteriously disappeared, wouldn't you think something was wrong? For distinct exclusions, you really should use separate portals.

In the example you present, it looks like the list of options is relatively short for each selection. And only one from the list can be chosen. If that's the case, then you're better off using menus. Each menu would present a different set of choices for the user to pick from. The one drawback with menus is that all skills would need to be bootstrapped onto every character.

If your game is like 4e or Runequest, all skills always exist on all characters, and all the user is doing is choosing which ones get appropriate bonuses. However, if the game is like Savage Worlds, characters don't have skills unless they buy them. If that's the case, then you have to play a little game to have things work the way you want.

In this method, you'll define a "ShowMe" tag that indicates that a skill should be made visible. By default, no skill has the tag, so it's not visible. Then, for any skill that is bootstrapped by a profession, you would assign the tag. This could be done via an Eval script on the Skill component, which checks if the skill is bootstrapped (via "isroot") and assigns the tag. For skills selected via a menu, you would need a separate script on the Profession component. This script would check each menu field and assign the tag to any skills that are selected (via the "ischosen" test and the "chosen" transition).

The last thing you'd need to do is make sure that the skills shown to the user for the character possess the "ShowMe" tag. This is easily done via the List tagexpr.

Since all of this can be done via component scripts, the amount of work isn't all that much. Individual skills don't need to know about any of this stuff, except in one situation. If a skill has its own Eval script to apply some effect, it will need to verify that the "ShowMe" tag is on it before actually applying the effect. This entails being careful with your script timing. However, since the component scripts key on information that is *not* modified via scripts, they can be scheduled very early. That way, their effects are in place long before you need an Eval script on a skill to do anything that tests the tag's presence.

Hope this helps!

P.S. I plan on writing a whole section in the wiki that discusses the needtag/denytag mechanism. Sadly, there just aren't enough hours in the day to get everything done and writing coherent documentation is a slow process for me. It gets even slower when on mind-clouding muscle relaxers, which I have to take for my neck problem.<sigh>

 

[Mathias]

Thanks. I'll go with multiple choosers/menus, and I was going to need the sort of ShowTag behavior you describe for advancement anyway (The career chosen determines the advance costs for skills, etc., and there's no skill groupings or patterns to simplify it).

A question about the way the ShowTag would behave - what about the skills with domains - the first instance of each skill gets bootstrapped automatically, and hidden until needed, but say I assign an advance cost tag to a skill with a domain, and the user wants to buy 2 different versions of the same skill - do I have to worry about finding both with a foreach loop, or can I just assign the correct tag to the unique ID of the skill?

 

[rob]

If each profession is added via a table, you won't be able to use choosers within the table. Menus are your only option for use within a table.

You should probably be handling advancements using the provided mechanisms that are designed for just that purpose. The Kit has a variety of mechanisms built into it that allow you to associate advancement selections with existing selections. This makes it possible to have three distinct Knowledge skills and separately advance each of them. I recommend taking a look at the code within the files "advancement.core", "form_advance.dat", and "thing_advances.dat" in your new game system where they were automatically placed. These files show how this stuff works.

I'm planning to write up more info on this stuff in the weeks to come, but there's so much to cover. Ugh.