Loading ...
Sorry, an error occurred while loading the content.

Re: Disable a race

Expand Messages
  • FerretDave
    Ah, that probably scuppers my method then... After I d copied the standard race, to make all my variants, I was going to modify the standard race to add that
    Message 1 of 8 , Mar 9, 2012
    • 0 Attachment
      Ah, that probably scuppers my method then...

      After I'd copied the standard race, to make all my variants, I was going to modify the standard race to add that PREtemplate to make it non-selectable, thus I'd only end up with my variant races on display.
      (hence the JIRA for VISIBLE on races).

      If any copy is going to receive the mods made to the original after its copied, then that causes issue.
      Though I suppose I could .MOD the original to add the PRETEMPLATE first, and then copy and .CLEAR the PRETEMPLATE from the copies?

      Is there any value in discussing having COPY *not* link back to the original? I.e make it work the way I thought it did, or does this referential link back exist for a specific reason?

      My reasoning behind always refering back to the RSRD version via .COPY, rather than actual cut&paste copying of the RSRD version was for forward compatibility, to ensure that it was always using the latest capabilities.
      Since I started this type of homebrew when abilities were just being setup, my thought was if I'd have copied this race before abilities existed, I'd have to re-copy that race again to make use of abilities, and in future, would I have to re-copy yet again to keep my homebrew up to do date with the latest capabilities? Whereas by using .COPY, you can add whatever fancy tags you like to the 'standard' datasets, and my homebrew immediately benefits from that too.

      Saying that, I don't expect something major like abilities to come up again for a while, so an actual cut&paste&rename of each race into my homebrew may just be the way forward anyway.

      PCC's including PCC's: This is probably worth a seperate thread...
      These are certainly easier to maintain than including the referenced lst files directly, and make groupings a whole lot easier to sort out (adding a sourcebook to a campaign involves just one PCC, rather than a whole list of LSTs).
      By including PCCs rather than LSTs, I retain the RANK ordering, which while I perhaps still do with defining lots of LSTs, I need to ensure I keep the original order. Its losing clarity of what is being included though.

      Again, with my original concept of 'forward compatibility', if in a future version the RSRD.PCC ends up adding a bunch of extra .LST files (like when abilities were added in) if my campaign pcc is only including specific lst files directly, rather than the PCC, then I lose out on that, and either miss out on info or get errors due to missing definitions.

      I suppose the issue is that there are multiple ways of doing anything, and there's often good reasons for each variation.

      Didnt the 'save sources' option in the GUI previously create a PCC that referenced PCC's? (I thought that's how I'd created my first campaign PCC's). It now saves the lst file references from those PCC's instead, am I misremembering this saving PCC's before, or was there a reason for it to change?

      Cheers
      D
      --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@...> wrote:
      >
      > Hi Dave,
      >
      >
      >
      > On 3/8/2012 6:55 AM, FerretDave wrote:
      > > Greetings,
      > >
      > > --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@> wrote:
      > >>> Is there a way to disable a race completely? Other than '.FORGET'?
      > >> Race.MOD <> PRETEMPLATE:1,SomeEvilTemplate
      > > PRETEMPLATE - that'll do it, thanks.
      > >
      > >>> <SNIP>
      > >> .COPY requires the original race, if you 'Forget' the race, then the Program dutifully forgets it,
      > >> hence the unconstructed reference.
      > > Ah, I thought it was a true copy, rather than a reference back to the original.
      > > I havent checked fully, but I've made several .COPYs of each race (racial variants for Forgotten Realms), and then .MOD'd each of these variants, if I .MOD a copy or the original, is that going to have any effect on any other .COPYied versions? I.e are my changes on one copy going to end up propogated through the rest of the copies?
      >
      > Base Race.COPY=New Race 1
      >
      > New Race 1.MOD <all new changes>
      >
      > Base Race does not get <all new changes>
      >
      > However,
      > Base Race.MOD <Some Other Changes>
      >
      > New Race 1 is granted <Some Other Changes>
      >
      > If you then have
      >
      > New Race 1.COPY=New Race 1b
      >
      > New Race 1b has Some Other Changes + New Changes
      >
      > So, to have any given race stay exactly as you want, it is better to create the new race 1 and new
      > race 1b as their own entries.
      >
      > >>> It looks like OUTPUTNAME is not used (for race) in the GUI (is OUTPUTNAME *only* for OS output?), so I cant .MOD the original race to change its name in the GUI.
      > >> Yeah, it would appear the new UI completely ignores the OUTPUTNAME.
      > > JIRA'd
      > >
      > >>> Using !PRECAMPAIGN was one thought, but as I've got PCC's including PCC's, looks like I can't guarantee that being fixed to the current source either (I create seperate PCC's for each game group, specifying just the sources used in that one group, most of which then include the PCC that's redefining the races...
      > >> I wouldn't do that - sounds like a big mess, and PRECAMPAIGN only works for the originating pcc, not
      > >> children pccs by reference.
      > > you wouldnt use PRECAMPAIGN, or wouldnt use multiple PCC's ?
      > > I need to group together various sources, as one ref allows some books while another doesnt (but does allow some others too), so I don't want to be reselecting a variety of sources each time around, just want to select the one 'campaign' file specifically for that game.
      >
      > You can use multiple PCCs, I wouldn't use PRECAMPAIGN as a sort of filter mechanism, it's designed
      > to make sure that you can only load sets that will work together - i.e. have a CORE rule set, and
      > not load a conflicting set. Though your mileage will vary as we only set those up for obvious cases.
      >
      > If you want Campaign Dave 1a, and then Campaign Andrew, or Campaign of the Bog Men Adventures - then
      > make a pcc file that only loads the files for that campaign. We have the capability for relative
      > paths for that very reason ;) Homebrew folder is made for that very reason. I'd point out that
      > loading pcc files is acceptable from other pccs, but be aware you'll likely see a bunch of
      > unconstructed errors that are false, if you load the files direct, you'll only get legit errors.
      > Hence, take the time to have each file loaded. It makes debugging and fine tune control much easier.
      >
      >
      >
      > >
      > >
      > >>> Could VISIBLE be made usable on races? is that an appropriate way forward?
      > >> You can try VISIBLE:NO, not sure what error message you might get till you try. It'll either work,
      > >> or it won't. I happen to know Skills don't see VISIBLE:NO as a valid entry.
      > > I tried it, didnt work, not valid entry. JIRA'd
      >
      > Well, let's think about this, other than hiding races from being selected, when are you ever going
      > to hide a race? I'm not sure you'll get much traction with having a visibility filter for races. I'd
      > being calling that a low priority in the grand scheme of things. There are easier methods that allow
      > you to remove races from selection as I've already pointed out.
      >
      > >
      > >> If I was going to do it myself, and really didn't want the original race, I'd use my homebrew files,
      > >> place in all the races properly (full entry instead of using the .COPY method and FORGET the other
      > >> race, or exclude that file. Multiple solutions exist.
      > > This approach is essentially what I'm migrating *from* ! The old CMP sources redefined the wheel, and I'm rebuilding my copies to use the RSRD as a base - so I immediately gain the benefits of the abilities etc defined for the standard races.
      > > So by having a Wild Elf and a Sun Elf each as a copy of an RSRD Elf, with a .MOD for the minor variations, I have the bare minimum code in my homebrew and will always get the latest fixes/updates for the 'standard' Elf included in my version.
      >
      > I suggest simply copying the elf entry and redoing what changes you need. Those new things are
      > simply 'ABILITY:Special Ability|AUTOMATIC|Ability Name for the Elf 1|Another Elf Ability 2|etc.
      >
      > >
      > >
      > >
      > >> Cheers,
      > > Cheers
      > > Dave
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      >
      > --
      > Andrew Maitland (LegacyKing)
      > Admin Silverback - PCGen Board of Directors
      > Data 2nd, Docs Tamarin, OS Lemur
      > Unique Title "Quick-Silverback Tracker Monkey"
      > Unique Title "The Torturer of PCGen"
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • Andrew
      Hi Dave, So, you want to have all the latest and greatest from each version, but you don t want the originating race to be available. Well, here is a simple
      Message 2 of 8 , Mar 9, 2012
      • 0 Attachment
        Hi Dave,

        So, you want to have all the latest and greatest from each version, but you don't want the
        originating race to be available. Well, here is a simple solution - adapt it however you'd like:

        Original Race.MOD <> PREVARGTEQ:AllowedCampaign,1
        // Original Race now requires AllowedCampaign of 1 (which he lacks, poor fella)

        Original Race.COPY=Other Race
        // Well bugger, now the variants get it... why'd we do that?

        Other Race.MOD <> DEFINE:AllowedCampaign|1
        // Yay! The variants are freed from the shackles of the original race.

        Rinse, repeat for any other variants.

        Let me say this, Order of Operations is at LOAD TIME. I don't know where the list is, but it
        specifically has Process .COPY > .MOD > .FORGET > .REMOVE etc... and that happens in a specific
        order. Trying to have something happen in a particular way dealing with that is a good way to get a
        headache.

        Save Sources just happens to save All my selections, I haven't noticed any forwardref issues. When I
        mention direct reference is best, this is years of experience in doing what you are trying to do.

        Anyways, hope the above solution solves your issue.

        Cheers,

        On 3/9/2012 8:01 AM, FerretDave wrote:
        > Ah, that probably scuppers my method then...
        >
        > After I'd copied the standard race, to make all my variants, I was going to modify the standard race to add that PREtemplate to make it non-selectable, thus I'd only end up with my variant races on display.
        > (hence the JIRA for VISIBLE on races).
        >
        > If any copy is going to receive the mods made to the original after its copied, then that causes issue.
        > Though I suppose I could .MOD the original to add the PRETEMPLATE first, and then copy and .CLEAR the PRETEMPLATE from the copies?
        >
        > Is there any value in discussing having COPY *not* link back to the original? I.e make it work the way I thought it did, or does this referential link back exist for a specific reason?
        >
        > My reasoning behind always refering back to the RSRD version via .COPY, rather than actual cut&paste copying of the RSRD version was for forward compatibility, to ensure that it was always using the latest capabilities.
        > Since I started this type of homebrew when abilities were just being setup, my thought was if I'd have copied this race before abilities existed, I'd have to re-copy that race again to make use of abilities, and in future, would I have to re-copy yet again to keep my homebrew up to do date with the latest capabilities? Whereas by using .COPY, you can add whatever fancy tags you like to the 'standard' datasets, and my homebrew immediately benefits from that too.
        >
        > Saying that, I don't expect something major like abilities to come up again for a while, so an actual cut&paste&rename of each race into my homebrew may just be the way forward anyway.
        >
        > PCC's including PCC's: This is probably worth a seperate thread...
        > These are certainly easier to maintain than including the referenced lst files directly, and make groupings a whole lot easier to sort out (adding a sourcebook to a campaign involves just one PCC, rather than a whole list of LSTs).
        > By including PCCs rather than LSTs, I retain the RANK ordering, which while I perhaps still do with defining lots of LSTs, I need to ensure I keep the original order. Its losing clarity of what is being included though.
        >
        > Again, with my original concept of 'forward compatibility', if in a future version the RSRD.PCC ends up adding a bunch of extra .LST files (like when abilities were added in) if my campaign pcc is only including specific lst files directly, rather than the PCC, then I lose out on that, and either miss out on info or get errors due to missing definitions.
        >
        > I suppose the issue is that there are multiple ways of doing anything, and there's often good reasons for each variation.
        >
        > Didnt the 'save sources' option in the GUI previously create a PCC that referenced PCC's? (I thought that's how I'd created my first campaign PCC's). It now saves the lst file references from those PCC's instead, am I misremembering this saving PCC's before, or was there a reason for it to change?
        >
        > Cheers
        > D
        > --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@...> wrote:
        >> Hi Dave,
        >>
        >>
        >>
        >> On 3/8/2012 6:55 AM, FerretDave wrote:
        >>> Greetings,
        >>>
        >>> --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@> wrote:
        >>>>> Is there a way to disable a race completely? Other than '.FORGET'?
        >>>> Race.MOD <> PRETEMPLATE:1,SomeEvilTemplate
        >>> PRETEMPLATE - that'll do it, thanks.
        >>>
        >>>>> <SNIP>
        >>>> .COPY requires the original race, if you 'Forget' the race, then the Program dutifully forgets it,
        >>>> hence the unconstructed reference.
        >>> Ah, I thought it was a true copy, rather than a reference back to the original.
        >>> I havent checked fully, but I've made several .COPYs of each race (racial variants for Forgotten Realms), and then .MOD'd each of these variants, if I .MOD a copy or the original, is that going to have any effect on any other .COPYied versions? I.e are my changes on one copy going to end up propogated through the rest of the copies?
        >> Base Race.COPY=New Race 1
        >>
        >> New Race 1.MOD <all new changes>
        >>
        >> Base Race does not get <all new changes>
        >>
        >> However,
        >> Base Race.MOD <Some Other Changes>
        >>
        >> New Race 1 is granted <Some Other Changes>
        >>
        >> If you then have
        >>
        >> New Race 1.COPY=New Race 1b
        >>
        >> New Race 1b has Some Other Changes + New Changes
        >>
        >> So, to have any given race stay exactly as you want, it is better to create the new race 1 and new
        >> race 1b as their own entries.
        >>
        >>>>> It looks like OUTPUTNAME is not used (for race) in the GUI (is OUTPUTNAME *only* for OS output?), so I cant .MOD the original race to change its name in the GUI.
        >>>> Yeah, it would appear the new UI completely ignores the OUTPUTNAME.
        >>> JIRA'd
        >>>
        >>>>> Using !PRECAMPAIGN was one thought, but as I've got PCC's including PCC's, looks like I can't guarantee that being fixed to the current source either (I create seperate PCC's for each game group, specifying just the sources used in that one group, most of which then include the PCC that's redefining the races...
        >>>> I wouldn't do that - sounds like a big mess, and PRECAMPAIGN only works for the originating pcc, not
        >>>> children pccs by reference.
        >>> you wouldnt use PRECAMPAIGN, or wouldnt use multiple PCC's ?
        >>> I need to group together various sources, as one ref allows some books while another doesnt (but does allow some others too), so I don't want to be reselecting a variety of sources each time around, just want to select the one 'campaign' file specifically for that game.
        >> You can use multiple PCCs, I wouldn't use PRECAMPAIGN as a sort of filter mechanism, it's designed
        >> to make sure that you can only load sets that will work together - i.e. have a CORE rule set, and
        >> not load a conflicting set. Though your mileage will vary as we only set those up for obvious cases.
        >>
        >> If you want Campaign Dave 1a, and then Campaign Andrew, or Campaign of the Bog Men Adventures - then
        >> make a pcc file that only loads the files for that campaign. We have the capability for relative
        >> paths for that very reason ;) Homebrew folder is made for that very reason. I'd point out that
        >> loading pcc files is acceptable from other pccs, but be aware you'll likely see a bunch of
        >> unconstructed errors that are false, if you load the files direct, you'll only get legit errors.
        >> Hence, take the time to have each file loaded. It makes debugging and fine tune control much easier.
        >>
        >>
        >>
        >>>>> Could VISIBLE be made usable on races? is that an appropriate way forward?
        >>>> You can try VISIBLE:NO, not sure what error message you might get till you try. It'll either work,
        >>>> or it won't. I happen to know Skills don't see VISIBLE:NO as a valid entry.
        >>> I tried it, didnt work, not valid entry. JIRA'd
        >> Well, let's think about this, other than hiding races from being selected, when are you ever going
        >> to hide a race? I'm not sure you'll get much traction with having a visibility filter for races. I'd
        >> being calling that a low priority in the grand scheme of things. There are easier methods that allow
        >> you to remove races from selection as I've already pointed out.
        >>
        >>>> If I was going to do it myself, and really didn't want the original race, I'd use my homebrew files,
        >>>> place in all the races properly (full entry instead of using the .COPY method and FORGET the other
        >>>> race, or exclude that file. Multiple solutions exist.
        >>> This approach is essentially what I'm migrating *from* ! The old CMP sources redefined the wheel, and I'm rebuilding my copies to use the RSRD as a base - so I immediately gain the benefits of the abilities etc defined for the standard races.
        >>> So by having a Wild Elf and a Sun Elf each as a copy of an RSRD Elf, with a .MOD for the minor variations, I have the bare minimum code in my homebrew and will always get the latest fixes/updates for the 'standard' Elf included in my version.
        >> I suggest simply copying the elf entry and redoing what changes you need. Those new things are
        >> simply 'ABILITY:Special Ability|AUTOMATIC|Ability Name for the Elf 1|Another Elf Ability 2|etc.
        >>
        >>>
        >>>> Cheers,
        >>> Cheers
        >>> Dave
        >>>
        >>>
        >>>
        >>> ------------------------------------
        >>>
        >>> Yahoo! Groups Links
        >>>
        >>>
        >>>
        >>>
        >> --
        >> Andrew Maitland (LegacyKing)
        >> Admin Silverback - PCGen Board of Directors
        >> Data 2nd, Docs Tamarin, OS Lemur
        >> Unique Title "Quick-Silverback Tracker Monkey"
        >> Unique Title "The Torturer of PCGen"
        >>
        >>
        >> [Non-text portions of this message have been removed]
        >>
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >

        --
        Andrew Maitland (LegacyKing)
        Admin Silverback - PCGen Board of Directors
        Data 2nd, Docs Tamarin, OS Lemur
        Unique Title "Quick-Silverback Tracker Monkey"
        Unique Title "The Torturer of PCGen"


        [Non-text portions of this message have been removed]
      • FerretDave
        Greetings, Thanks Drew, this var method works well enough. I say well enough (sorry!) as while it gets my race shown in red, I can still actually select it and
        Message 3 of 8 , Mar 9, 2012
        • 0 Attachment
          Greetings,
          Thanks Drew, this var method works well enough.
          I say well enough (sorry!) as while it gets my race shown in red, I can still actually select it and use it... I guess that's a bug?

          Another possible bug is that it doesn't seem possible to .CLEAR a PRETEMPLATE ? Or at least, I couldn't figure the syntax...

          Thanks again, and I'll move from PCC inclusion to direct LST inclusion as and when I notice any errors crop up from it (none so far!)

          Cheers
          D


          --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@...> wrote:
          >
          > Hi Dave,
          >
          > So, you want to have all the latest and greatest from each version, but you don't want the
          > originating race to be available. Well, here is a simple solution - adapt it however you'd like:
          >
          > Original Race.MOD <> PREVARGTEQ:AllowedCampaign,1
          > // Original Race now requires AllowedCampaign of 1 (which he lacks, poor fella)
          >
          > Original Race.COPY=Other Race
          > // Well bugger, now the variants get it... why'd we do that?
          >
          > Other Race.MOD <> DEFINE:AllowedCampaign|1
          > // Yay! The variants are freed from the shackles of the original race.
          >
          > Rinse, repeat for any other variants.
          >
          > Let me say this, Order of Operations is at LOAD TIME. I don't know where the list is, but it
          > specifically has Process .COPY > .MOD > .FORGET > .REMOVE etc... and that happens in a specific
          > order. Trying to have something happen in a particular way dealing with that is a good way to get a
          > headache.
          >
          > Save Sources just happens to save All my selections, I haven't noticed any forwardref issues. When I
          > mention direct reference is best, this is years of experience in doing what you are trying to do.
          >
          > Anyways, hope the above solution solves your issue.
          >
          > Cheers,
          >
          > On 3/9/2012 8:01 AM, FerretDave wrote:
          > > Ah, that probably scuppers my method then...
          > >
          > > After I'd copied the standard race, to make all my variants, I was going to modify the standard race to add that PREtemplate to make it non-selectable, thus I'd only end up with my variant races on display.
          > > (hence the JIRA for VISIBLE on races).
          > >
          > > If any copy is going to receive the mods made to the original after its copied, then that causes issue.
          > > Though I suppose I could .MOD the original to add the PRETEMPLATE first, and then copy and .CLEAR the PRETEMPLATE from the copies?
          > >
          > > Is there any value in discussing having COPY *not* link back to the original? I.e make it work the way I thought it did, or does this referential link back exist for a specific reason?
          > >
          > > My reasoning behind always refering back to the RSRD version via .COPY, rather than actual cut&paste copying of the RSRD version was for forward compatibility, to ensure that it was always using the latest capabilities.
          > > Since I started this type of homebrew when abilities were just being setup, my thought was if I'd have copied this race before abilities existed, I'd have to re-copy that race again to make use of abilities, and in future, would I have to re-copy yet again to keep my homebrew up to do date with the latest capabilities? Whereas by using .COPY, you can add whatever fancy tags you like to the 'standard' datasets, and my homebrew immediately benefits from that too.
          > >
          > > Saying that, I don't expect something major like abilities to come up again for a while, so an actual cut&paste&rename of each race into my homebrew may just be the way forward anyway.
          > >
          > > PCC's including PCC's: This is probably worth a seperate thread...
          > > These are certainly easier to maintain than including the referenced lst files directly, and make groupings a whole lot easier to sort out (adding a sourcebook to a campaign involves just one PCC, rather than a whole list of LSTs).
          > > By including PCCs rather than LSTs, I retain the RANK ordering, which while I perhaps still do with defining lots of LSTs, I need to ensure I keep the original order. Its losing clarity of what is being included though.
          > >
          > > Again, with my original concept of 'forward compatibility', if in a future version the RSRD.PCC ends up adding a bunch of extra .LST files (like when abilities were added in) if my campaign pcc is only including specific lst files directly, rather than the PCC, then I lose out on that, and either miss out on info or get errors due to missing definitions.
          > >
          > > I suppose the issue is that there are multiple ways of doing anything, and there's often good reasons for each variation.
          > >
          > > Didnt the 'save sources' option in the GUI previously create a PCC that referenced PCC's? (I thought that's how I'd created my first campaign PCC's). It now saves the lst file references from those PCC's instead, am I misremembering this saving PCC's before, or was there a reason for it to change?
          > >
          > > Cheers
          > > D
          > > --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@> wrote:
          > >> Hi Dave,
          > >>
          > >>
          > >>
          > >> On 3/8/2012 6:55 AM, FerretDave wrote:
          > >>> Greetings,
          > >>>
          > >>> --- In PCGenListFileHelp@yahoogroups.com, Andrew <drew0500@> wrote:
          > >>>>> Is there a way to disable a race completely? Other than '.FORGET'?
          > >>>> Race.MOD <> PRETEMPLATE:1,SomeEvilTemplate
          > >>> PRETEMPLATE - that'll do it, thanks.
          > >>>
          > >>>>> <SNIP>
          > >>>> .COPY requires the original race, if you 'Forget' the race, then the Program dutifully forgets it,
          > >>>> hence the unconstructed reference.
          > >>> Ah, I thought it was a true copy, rather than a reference back to the original.
          > >>> I havent checked fully, but I've made several .COPYs of each race (racial variants for Forgotten Realms), and then .MOD'd each of these variants, if I .MOD a copy or the original, is that going to have any effect on any other .COPYied versions? I.e are my changes on one copy going to end up propogated through the rest of the copies?
          > >> Base Race.COPY=New Race 1
          > >>
          > >> New Race 1.MOD <all new changes>
          > >>
          > >> Base Race does not get <all new changes>
          > >>
          > >> However,
          > >> Base Race.MOD <Some Other Changes>
          > >>
          > >> New Race 1 is granted <Some Other Changes>
          > >>
          > >> If you then have
          > >>
          > >> New Race 1.COPY=New Race 1b
          > >>
          > >> New Race 1b has Some Other Changes + New Changes
          > >>
          > >> So, to have any given race stay exactly as you want, it is better to create the new race 1 and new
          > >> race 1b as their own entries.
          > >>
          > >>>>> It looks like OUTPUTNAME is not used (for race) in the GUI (is OUTPUTNAME *only* for OS output?), so I cant .MOD the original race to change its name in the GUI.
          > >>>> Yeah, it would appear the new UI completely ignores the OUTPUTNAME.
          > >>> JIRA'd
          > >>>
          > >>>>> Using !PRECAMPAIGN was one thought, but as I've got PCC's including PCC's, looks like I can't guarantee that being fixed to the current source either (I create seperate PCC's for each game group, specifying just the sources used in that one group, most of which then include the PCC that's redefining the races...
          > >>>> I wouldn't do that - sounds like a big mess, and PRECAMPAIGN only works for the originating pcc, not
          > >>>> children pccs by reference.
          > >>> you wouldnt use PRECAMPAIGN, or wouldnt use multiple PCC's ?
          > >>> I need to group together various sources, as one ref allows some books while another doesnt (but does allow some others too), so I don't want to be reselecting a variety of sources each time around, just want to select the one 'campaign' file specifically for that game.
          > >> You can use multiple PCCs, I wouldn't use PRECAMPAIGN as a sort of filter mechanism, it's designed
          > >> to make sure that you can only load sets that will work together - i.e. have a CORE rule set, and
          > >> not load a conflicting set. Though your mileage will vary as we only set those up for obvious cases.
          > >>
          > >> If you want Campaign Dave 1a, and then Campaign Andrew, or Campaign of the Bog Men Adventures - then
          > >> make a pcc file that only loads the files for that campaign. We have the capability for relative
          > >> paths for that very reason ;) Homebrew folder is made for that very reason. I'd point out that
          > >> loading pcc files is acceptable from other pccs, but be aware you'll likely see a bunch of
          > >> unconstructed errors that are false, if you load the files direct, you'll only get legit errors.
          > >> Hence, take the time to have each file loaded. It makes debugging and fine tune control much easier.
          > >>
          > >>
          > >>
          > >>>>> Could VISIBLE be made usable on races? is that an appropriate way forward?
          > >>>> You can try VISIBLE:NO, not sure what error message you might get till you try. It'll either work,
          > >>>> or it won't. I happen to know Skills don't see VISIBLE:NO as a valid entry.
          > >>> I tried it, didnt work, not valid entry. JIRA'd
          > >> Well, let's think about this, other than hiding races from being selected, when are you ever going
          > >> to hide a race? I'm not sure you'll get much traction with having a visibility filter for races. I'd
          > >> being calling that a low priority in the grand scheme of things. There are easier methods that allow
          > >> you to remove races from selection as I've already pointed out.
          > >>
          > >>>> If I was going to do it myself, and really didn't want the original race, I'd use my homebrew files,
          > >>>> place in all the races properly (full entry instead of using the .COPY method and FORGET the other
          > >>>> race, or exclude that file. Multiple solutions exist.
          > >>> This approach is essentially what I'm migrating *from* ! The old CMP sources redefined the wheel, and I'm rebuilding my copies to use the RSRD as a base - so I immediately gain the benefits of the abilities etc defined for the standard races.
          > >>> So by having a Wild Elf and a Sun Elf each as a copy of an RSRD Elf, with a .MOD for the minor variations, I have the bare minimum code in my homebrew and will always get the latest fixes/updates for the 'standard' Elf included in my version.
          > >> I suggest simply copying the elf entry and redoing what changes you need. Those new things are
          > >> simply 'ABILITY:Special Ability|AUTOMATIC|Ability Name for the Elf 1|Another Elf Ability 2|etc.
          > >>
          > >>>
          > >>>> Cheers,
          > >>> Cheers
          > >>> Dave
          > >>>
          > >>>
          > >>>
          > >>> ------------------------------------
          > >>>
          > >>> Yahoo! Groups Links
          > >>>
          > >>>
          > >>>
          > >>>
          > >> --
          > >> Andrew Maitland (LegacyKing)
          > >> Admin Silverback - PCGen Board of Directors
          > >> Data 2nd, Docs Tamarin, OS Lemur
          > >> Unique Title "Quick-Silverback Tracker Monkey"
          > >> Unique Title "The Torturer of PCGen"
          > >>
          > >>
          > >> [Non-text portions of this message have been removed]
          > >>
          > >
          > >
          > > ------------------------------------
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          >
          > --
          > Andrew Maitland (LegacyKing)
          > Admin Silverback - PCGen Board of Directors
          > Data 2nd, Docs Tamarin, OS Lemur
          > Unique Title "Quick-Silverback Tracker Monkey"
          > Unique Title "The Torturer of PCGen"
          >
          >
          > [Non-text portions of this message have been removed]
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.