Re: Modding ABILITYCATEGORYs
- --- In PCGenListFileHelp@yahoogroups.com, Tir Gwaith <Tir.Gwaith@...>
> Which means all abilitycategory.lst files get loaded, .MOD'd, etc.This sounds simple, but is very different from how we load data
> FIRST, then move on to start loading all other files.
today... thus will require us to move around processing in order to
ensure that behavior (which brings up risks of breaking other things
that make assumptions based on the current order - such as the
assumption that STATs are pre-built.) Not saying it can't be done,
but it's work and we need to evaluate the impact of that change.
> [Parent "Special Ability" being removed from GameMode]Me either, but I didn't notice the reference in the game mode until a
> doesn't really make sense to me.
few days ago.
> (For that matter, the GameModeI suspect we'd want to change this to a variable at some point?
> references a specific Data object - Uncanny Dodge - which gets weird
> for a GameMode..)
> Penalties of dereferencing besides slowness in recalculation are? ITo the user, processing time. Memory, too, but that's minor. To me,
> can guess, but I think I'd rather have it spelled out so I'm not
> making bad assumptions.
I have to rethink processing Abilities from the Ability LST file,
since it's currently indexed by AbilityCategory. I have to think if
indexing by a reference is a problem or not. I'm honestly not sure
given the 5 minutes of thought I've given it so far :)
> > Either way, this issue needs to get resolved in order to even be ableNeat idea, but this might be harder than just making everything
> > to define how a .MOD/.COPY/.FORGET etc. would behave.
> Personally, I'd leave the Parent's un-moddable, and allow the
> Child-nodes re-definable.
changeable. Of course, this concept also interacts with the whole
"let's split ability categories into the multiple separate functions
they perform" (This is the whole category/pool discussion/FREQ
- I would venture a guess that these were added the following reasons:
ADD:FEAT usage - Homebrews likely still use this method
UI - Clean Look for older versions
Overlap of Uses - Any new 'wizard' feat can just add the TYPE:Wizard
to be included in the Old and New systems
Seemed like a good idea at the time.
Andrew Maitland (LegacyKing)
Admin Silverback, PCGen Board of Directors
Data Chimp, Docs Tamarin
Unique Title "Quick-Silverback Tracker Monkey"
Michael W. Fender wrote:
> Accessing archive from "Tir Gwaith"...[Non-text portions of this message have been removed]
> Archive found in file
>>> I'll let higher up have final say from there :p However, I still have to
>>> question whether a FReq for cleaning up unneeded Wizard types should be
>>> made. If they're not needed anymore with the ItemCreation and Metamagic
>>> feats, should we leave them be or get rid of them before they actually do
>>> cause a problem?
>> Not needed anymore.. Ok, I'm going to have to ponder that a bit. I
>> now see we added TYPE:Wizard to all the ItemCreation and Metamagic
>> feats. Makes it a bit like the MSRD type set-up, and I'm not exactly
>> sure why that was done, unless it was someone's idea of help on the UI
>> side. We've done that with a number of Equipment TYPEs....
> What I understood from what Eddy was saying, the only purpose of it was to
> have feats with the 'Wizard type show up as a "Wizard Feat". Such as for
> CHOOSE or ADD tags. Using it with an ItemCreation/Metamagic type feat is
> pointless now, and with other LST files, this does not seem to be the standard
> as those feats are listed as only ItemCreation/Metamagic, no Wizard.
- --- In PCGenListFileHelp@yahoogroups.com, Andrew Maitland
>Just FYI, I am updating my lst files to 5.15 (from .12 or so)
> Yes, that would be a FREQ.
> Might as well go the full mile if you're going to freq this:
> Add .MOD to ABILITYCATEGORY
> Add .CLEAR to ABILITYCATEGORY
> Add .COPY to ABILITYCATEGORY
> Does that cover your foreseeable needs?
> Let me know if this is what we want.
I have a .MOD on All Automatics Proficiencies and got the same error
as the OP.
Under the .MOD documentation there is this entry:
CATEGORY=Mutation|Weak Immune System.MOD
Modifies an ability of the category Mutation, which is called Weak
Immune System. Another ability of the same name, which belongs to
another category, would not be affected.
I changed mine into this format and the pcgen lst loader no longer
complains about the .MOD.
CATEGORY=Special Ability|All Automatic Proficiencies.MOD
Havent tried it yet but at least the loader in 5.15.9 thinks this
works. Some of the functionality may already be there.
- Accessing archive from "taluroniscandar"...
Archive found in file
> --- In PCGenListFileHelp@yahoogroups.com, Andrew MaitlandI have the same thing for Touch spells. It works perfectly fine now.
> <drew0500@...> wrote:
> > Yes, that would be a FREQ.
> > Might as well go the full mile if you're going to freq this:
> > Add .MOD to ABILITYCATEGORY
> > Add .CLEAR to ABILITYCATEGORY
> > Add .COPY to ABILITYCATEGORY
> > Does that cover your foreseeable needs?
> > Let me know if this is what we want.
> > ---------
> Just FYI, I am updating my lst files to 5.15 (from .12 or so)
> I have a .MOD on All Automatics Proficiencies and got the same error
> as the OP.
> Under the .MOD documentation there is this entry:
> CATEGORY=Mutation|Weak Immune System.MOD
> Modifies an ability of the category Mutation, which is called Weak
> Immune System. Another ability of the same name, which belongs to
> another category, would not be affected.
> I changed mine into this format and the pcgen lst loader no longer
> complains about the .MOD.
> CATEGORY=Special Ability|All Automatic Proficiencies.MOD
The worst crime you can commit against another human being is to make them