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