Drop FEAT hardcoding

Description

When ability was first created, it was made backwards compatible with
FEAT by making 'FEAT' a Category of the ability structure. However, FEAT
is hard-coded into the system design. KILLSHOT, a non-d20 system, has a
Feat Tab, even though it has no "feats". Any system that doesn't support
the concept of a feat, still displays it. As such, since Tom brought up
it's nasty embedded facts, I'd like to propose the following (with room
for amendments based upon code input):

(1) All tags with 'FEAT' in them will be deprecated (VFEAT, AUTO:FEAT,
FEAT:, ADD:FEAT, PREFEAT
(2) To be consistent, removing the FILE TYPE "FEAT" should be considered
for removal and converted to ABILITY.
(3) All tags from (1) will be converted to proper ABILITY
(ABILITY:FEAT|AUTOMATIC,VIRTUAL,NORMAL|x, ADD:ABILITY or part of
ABILITYPOOL, PREABILITY)

Most of this should be fairly easy for conversion.

Environment

None

Activity

Show:
Li-aung Yip
July 26, 2015, 10:06 PM
Li-aung Yip
July 27, 2015, 6:34 AM

The documentation `docs/listfilepages/globalfilestagpages/globalfilesother.html#ABILITY` mentions -

"Note: This tag WILL NOT activate a CHOOSER inside of a feat. You must use ADD:FEAT to activate a chooser inside of a feat being granted."

I don't know what this means.

Li-aung Yip
July 27, 2015, 7:56 AM

- I've had a go at revising the documentation [1] based on the list of tags you mentioned ( VFEAT, AUTO:FEAT, FEAT:, ADD:FEAT, PREFEAT ) plus other files that looked obvious. However there are still a lot of dangling references to the FEAT family of tags, some of which I don't know how to resolve (see the above comment, for example.)

[1] https://github.com/PCGen/pcgen/pull/398

Tom Parker
July 27, 2015, 12:16 PM

Not activating a CHOOSER is the difference between a direct addition (ABILITY: token, or old VFEAT) versus an ADD: token. The ADD: can take a list and lets you select (usually one) of that list. So ADD:FEAT is replaced by ADD:ABILITY (since it needs to stay an ADD) - and the text should read "inside of an ability being granted" as well. If you really want gory details on that I can find an old thread on _experimental about it (from perhaps 4 years ago)

As far as wider changes, I'm afraid this will be VERY wide ranging.

I would advise searching the entire docs folder for instances of VFEAT:, AUTO:FEAT, FEATAUTO: (since some of those are still around - ugh), PREFEAT:, ADD:FEAT: and FEAT: ... you'll want the colons in the search to keep you somewhat sane

The items in the output tokens (either outputsheetpages folder or navtokenindex.html) shouldn't be changed (different code) - the rest probably need to be individually checked to see if they require updates. It seems lots of the classes and other docs do refer to the now deprecated tokens, so those should be updated as well as part of the cleanup. I can provide some more explanation if necessary.

Li-aung Yip
July 27, 2015, 1:41 PM
Edited

I did search for instances of the FEAT tags in the documentation; the number of hits is intimidating.

A large number of the hits are in things like the list file classes, which are very old and outdated in other ways as well. I am tempted to call those a loss and re-write from scratch. (That would be a separate unit of work to this, though.)

Assignee

Andrew Maitland

Reporter

Tom Parker

Labels

None

Theme

None

Dependent Data

None

Subtype

None Taken

Epic/Theme

None

Pending User Input

None

Components

Affects versions

Priority

Minor
Configure