• 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

Granting Advanced Rogue Talents to an archetype

S

shatterjack

Active member
I'm working on an archetype that gets access to regular Rogue Talents at level 6, and advanced talents at level 14. The first part was easy enough, since I've done it before. But advanced talents are proving to be tricky; I can see the talents in the selection menu, but can't (legally) choose them because of the "Rogue level 10" requirement.

I see that the Archaeologist archetype is able to select advanced rogue talents without a problem, so I figured copying and modifying it should do the trick. But even when I carefully clone the Archaeologist by hand (scripts, tags, bootstraps, the lot), the copy archetype can't pick advanced talents.

I tried a side-by-side comparison of characters made with the Archaeologist and my copy of it, and the only difference I could find was a tag called Hero.ClsErLevOv. I'd never seen or heard of this tag before, but I tried adding it through the new copy anyway; no dice.

So how does the Archaeologist access advanced talents? And how can I do the same for another archetype?
 
If you make a copy of an advanced talent and look at the pre-requisites, you'll see that it calls a procedure, like so:

Code: 
        var classcheck as string
        var levels as number

        classcheck = "Rogue"

        call LevPreReqs

        validif (levels >= 10)

Here is the relevant bit of the procedure:

Code: 
    ~Rogue
    elseif (compare(classcheck,"Classes.Rogue") = 0) then

      ~Alchemist (Vivisectionist)
      if (#hasarchetype[arAlcVivis] <> 0) then
        levels += #levelcount[Alchemist]
        endif

      ~Bard (Archaeologist)
      if (#hasarchetype[arBrdArchA] <> 0) then
        ~we gain advanced talents at 12 (effective level -= 2)
        levels += maximum(#levelcount[Bard]-2,0)
        endif

      ~Gunslinger (Buccaneer of the Black Powder)
      if (#hasarchetype[arRPBuckBl] <> 0) then
        levels += #levelcount[Gunsling]
        endif

      ~Inquisitor (Thieftaker)
      if (#hasarchetype[arRPThieft] <> 0) then
        levels += #levelcount[Inquisito]
        endif

      ~Ninja
      levels += #levelcount[Ninja]

      ~Rogue Creature
      if (#hastemplate[tmRogue] <> 0) then
        levels += #totallevelcount[]
        endif

      ~Slayer
      levels += #levelcount[Slayer]

      ~Witch (White-Haired Witch)
      if (#hasarchetype[arWhiHaiWi] <> 0) then
        ~we gain advanced talents at 18 (effective level -= 8)
        levels += maximum(#levelcount[Witch]-8,0)
        endif

      ~Druid (Nature Fang)
      if (#hasarchetype[arDrdNFang] <> 0) then
        ~we gain advanced talents at 12 (effective level -= 2)
        levels += maximum(#levelcount[Druid]-2,0)
        endif

Now unfortunately you can't change how one of our procedures works, but you can copy and replace the advanced talent to modify the pre-req.
 
Hmm. That would be a fine solution if I were just trying to get my own table running, but this is intended for a community package. I would assume it's not good form to go messing with core elements like that, especially since later updates from LW could wipe out the changes.

That snippet did give me an idea, though. I tried adding instances of Classes.Rogue to the hero in one of the arch's eval scripts. That seemed to do the trick.

Still, I suspect if the solution were really that simple you would have suggested it in the first place. So am I right in thinking that this will have undesirable consequences? HL doesn't seem to be adding actual rogue levels from these tags, but perhaps the hero would end up qualifying for feats that he shouldn't or something?
 
The problem is I think that when PF released it didn't seem like they were going to go all crazy having ways for other classes to take so many talents from other classes. There was precedence for feats in the CRB because of Eldritch Knight which counts as fighter for feats so they have the CountAsFt.? tags and have the #featlevelcount[] macro to count that stuff, but when archetypes started allowing everything to be all over the place, it may have already been too late for a CountAsCA.? tag to be implemented. I've wished for somethig like that many times in my work.

And I've always wondered what was in that procedure, and now I know *yay*
 
Eh, I would advise against adding Classes.Rogue to your hero to get around the pre-req. Many things which use the #totallevelcount[] macro will count those extra tags and as a result anything dependant on that macro will be thrown off. The only way you might be able to swing that is if you replaced X number of existing Classes tags with an equal number of Classes.Rogue tags, but that would throw off anything which was looking specifically for the old class tags.

If you don't want to do the replacement thing (and I can see why you might want to avoid that), I guess you could add an eval script which counted the levels of the archetyped class, foreached through all custom special abilities which are Advanced Rogue Talents, and applied the "thing.skipprereq" tag to them. It wouldn't stop the validation warning shown when you are choosing which talents to add, but once added in defiance of the warning at least they won't show as invalid. The disadvantage of that method would be that it might clear things that shouldn't be. For example, a rogue talent which needed something else for it's pre-reqs than just rogue levels would never report the 2nd requirement as failed under this method.
 
Last edited:
AndrewD2 said:
The problem is I think that when PF released it didn't seem like they were going to go all crazy having ways for other classes to take so many talents from other classes. There was precedence for feats in the CRB because of Eldritch Knight which counts as fighter for feats so they have the CountAsFt.? tags and have the #featlevelcount[] macro to count that stuff, but when archetypes started allowing everything to be all over the place, it may have already been too late for a CountAsCA.? tag to be implemented. I've wished for somethig like that many times in my work.

And I've always wondered what was in that procedure, and now I know *yay*
Click to expand...

Yeah, the general trend in PF recently has been to mix different classes together, which is something which introduces extra work for us.

And there may be some news soon related to procedures, so keep an eye out for that.
 
Alright, I'll be honest, when the new releases are announced the first place I really look is the Data File Authoring section of the announcement to see what new goodies we get.
 
Aaron said:
Eh, I would advise against adding Classes.Rogue to your hero to get around the pre-req. Many things which use the #totallevelcount[] macro will count those extra tags and as a result anything dependant on that macro will be thrown off. The only way you might be able to swing that is if you replaced X number of existing Classes tags with an equal number of Classes.Rogue tags, but that would throw off anything which was looking specifically for the old class tags.
Click to expand...
Ah, yes, that's what I was afraid of.

Aaron said:
If you don't want to do the replacement thing (and I can see why you might want to avoid that), I guess you could add an eval script which counted the levels of the archetyped class, foreached through all custom special abilities which are Advanced Rogue Talents, and applied the "thing.skipprereq" tag to them. It wouldn't stop the validation warning shown when you are choosing which talents to add, but once added in defiance of the warning at least they won't show as invalid. The disadvantage of that method would be that it might clear things that shouldn't be. For example, a rogue talent which needed something else for it's pre-reqs than just rogue levels would never report the 2nd requirement as failed under this method.
Click to expand...
This seems better. At least this way I'm limiting the "damage" to advanced rogue talents, instead of anything and everything that counts rogue levels. Thanks, Aaron.
 
You must log in or register to reply here.
Back
Top