Is it possible to loop through the tags in a tag group?

[Mathias]

As I mentioned in my previous post, advance costs in the Dark Heresy game are set by the Career and Career Ranks your character chooses. Unfortunately, there are generally 15-20 individual advances that are given a price at each rank. Currently, the game supports advancement up to rank 8, and within each career, there are very often choices of the rank you will take when you level up. So, that means that I have something approaching 100 ranks to enter before I've gotten every career entered. Each of those ranks has 15-20 tags to assign. A script on each rank with 15-20:

 
perform hero.childfound[tPiLas].assign[Advance1.200]

lines is going to be very hard to debug and maintain.

Okay, now my question: I'm thinking that I cound create tag lists on each career. The tags can be chosen easily in the editor with taglists. There are a maximum of 4 advances for any one thing, and all the costs so far are 100, 200, 300, or 500. That's 16 lists, but it's better than the script. For example: AdvA200.tPiLas would be the advance I listed above. Then, write a script on the component that loops through all the Adv? tags on the rank, parses them, and assigns the tag to tPiLas if it exists on the hero. I'm thinking that I could use haschild[str] to make sure that the child exists, and firstchild[str] to get to it.

[rob]

You can *not* generally "iterate" through tags. The only way to do that would be to use the "tagids" target reference and then parse the string that is returned. However, I think this would be a difficult solution to implement.

I would recommend a completely different approach to the various career paths and ranks. I would define each rank as a distinct entity. I would then bootstrap onto that entity all of the valid advances for that rank. If a rank allows an advance to be taken multiple times, it will require some special handling, which I'll discuss below.

None of these rank entities would ever be shown to the user. Instead, they would remain invisible, but they would control what advances are available to the user for selection.

Each of these rank entities would possess a ContainerReq tagexpr (actually, the attaching thing would possess the tagexpr). This tagexpr would ensure that the rank is not accessible to the character until enough XP are earned to show it.

Here's where things start to get interesting. :-) All of things that are bootstrapped into the entities must be *shadowed* into the hero. This is a mechanism we haven't documented yet, but it's in use within the WoD, d20, and M&M data files. When a pick is shadowed from a gizmo into the hero, HL behaves as if the pick exists in *both* places. So by shadowing the picks into the hero, the hero will then gain *all* of the advances that live within the gizmo.

I'm sure you're now wondering why all of them would be added automatically to the hero. The hero is supposed to *select* them.

The key is that advances that are bootstrapped via entities must behave as if they have *not* been added to the hero. This can be achieved through the use of a single tag. If you have a "Helper.Chosen" tag (or something comparable), you can assign that tag to advances that are actually chosen for the hero. If that tag is not assigned to a particular advance, the scripts that operate on the advance must behave as if the advance is not selected - i.e. probably just bail out.

Since characters in Dark Heresy can choose from all ranks they've gained access to thus far, this approach will add all the various possible advances to the hero. Once they are added, it is easy to create a single dynamic table where the user can select from all the various advances. Instead of having the table list "things", you would instead have it list "picks". These picks would consist of all the picks for advances that have been added to the hero via the gizmos and have not yet been chosen for the hero.

When you use a pick-based table, a new pick is added that is based on the same thing that the selected pick derives from. This is how advancements work in World of Darkness, with the various merits that have already been added to the character being presented for increase. These newly added picks would be assigned the "Helper.Chosen" tag mentioned above. This could be done via the "autotag" mechanism of the table.

You now have all of the valid advances that *can* be selected on the hero, but without the "Helper.Chosen" tag, so they don't actually have any effect on the hero. You also have a table where the user can easily select advances from this list and add them to the hero. Lastly, you'll have advances on the hero that have been selected, and those will possess the "Helper.Chosen" tag so they can apply their effects.

There are only two things left to be dealt with. The first is identifying an advance that has already been added to the character and omitting it from the list presented by the table. Each advance that is added by the user must assign an identity tag to the hero. You can then use the "denytags" mechanism on the table to omit from the list any advance that has already been added by the user.

The second is how to handle an advance that can be selected multiple times at a particular rank or across ranks. There are only three instances of this that I can see: Minor Psychic Power, Psychic Power, and Sound Constitution. These will need to be handled specially. There are a couple of different solutions, but I don't really like either of them at this point. I'll need to think about this a bit further and probably talk to Colen to see if he has any brilliant ideas. But the above ought to give you a highly maintainable solution for just about everything, and we'll sort out the rest soon.

Hope this helps....

[Mathias]

I had another idea later in the evening after I posted my question - using the same AdvA200.tPiLas sort of tag I described in my previous post, replace all the CanAdvance and IsAdvance tags with those (or add them on for a very large set of tags on the hero). Each rank would forward its set of tags to the hero, and those tags would be used to control whether something was available for selection as an advance, and calculate the cost for that advance.