Add feature type to feat items

[arbron]

Similar to how armor, weapons, and tools can be grouped into subtypes, features would benefit from categorization:

• Background Feature
• Class Feature
• Species Feature
• Feat (actually feats, not just short for "features")

Some of these could get subcategories such as:

• Channel Divinity
• Defensive Tactics
• Eldritch Invocation
• Fighting Style
• Hunter's Prey
• Ki Abilities
• Metamagic Options
• Superior Hunter's Defense

This would be especially helpful for any more automated systems for granting features. When a fighter gained a fighting style, a system could search all compendium packs for any type that matched the Fighting Style type and present a dynamic list of options to the player.

[arbron]

From @Merudo:

Currently, the Foundry 5e system doesn't distinguish whether a feature is a feat, a class feature, a racial feature, or a background feature.

I suggest that an extra drop-down option "Feature Type" be added to the "Details" page of features, allowing the classification of features.

Some of the advantages would be:

• Custom character sheets could group features by their type
• Character Advancement scripts & modules could easily find available feats, including homebrew feats, when an ASI is gained
• All around easier type moving & organizing feats through scripts or modules

[arbron]

Originally in GitLab by @playest

I have identified the following categories:

• backgrounds (Acolyte, ...)
• class features (Spellcasting, Divine Domain, Ki, ...)
• creature/monster/npc features (Amphibious, Mucous Cloud, ...)
• feats (true "feats" like Inspiring Leader)
• racial features (Dwarven Resilience, Darkvision, ...)

And maybe:

• subraces (Hill Dwarf, ...), could also just be (a folder) in race feature
• subraces features (Dwarven Toughness, ...), could also just be (a folder) in race feature
• subclasses (Champion, ...), could also just be (a folder) in class features
• subclass features (Improved Critical, Remarkable Athlete), could also just be (a folder) in class features
• subfeatures (maneuvers, eldritch invocations, ... things that can be chosen from a feature basically), it could also be put with their parent feature

Anything I missed?

Having two fields parentFeature and parentFeatureName (or parentFeatureId), could also (instead?) be interesting.

[arbron]

Originally in GitLab by @Merudo

I have identified the following categories:

• backgrounds (Acolyte, ...)
• class features (Spellcasting, Divine Domain, Ki, ...)
• creature/monster/npc features (Amphibious, Mucous Cloud, ...)
• feats (true "feats" like Inspiring Leader)
• racial features (Dwarven Resilience, Darkvision, ...)

I would add something like "Supernatural Gifts". It would include Boons & Charms (DMG page 227-228), as well as adventure-specific bonuses such as the Dark Gifts from Curse of Strahd.

[arbron]

Subclasses are going to be their own item types as well as races and backgrounds, so those will be handled separately.

[arbron]

Originally in GitLab by @iaguastalli

@arbron while I agree that subclasses (and any sub- actually) should not be part of this, I am not convinced subclasses should be a type itself, but just another Class item linked to a parent class somehow.

[arbron]

Originally in GitLab by @playest

I kind of agree with @iaguastalli, there is so much simililarity between class and subclasses that they should have a lot in common. Which doesn't mean that it can be a different type, just that the code should almost be exactly the same.

[arbron]

Implementation wise, I feel that making subclasses just classes would lead to more code written to get around things like level and hit dice calculations that assume that each class is actually a class. Plus any modules that assume that every class is actually a class will have to be rewritten to take not-class classes into account.

If subclass is implemented as its own type, everything just keeps working. The biggest things that would be to be changed would be an adjustment to _computeSpellcastingProgression to check for the spellcasting value in a classes subclass in addition to the class itself.

Basically, subclasses as classes would be a much bigger programming task than subclasses as their own item type.