RPTools
[Feature]: Token property "Feature sets"
Describe the Problem
There is a lot of duplication between different token property types in most people's setups. It can be tiresome to compose big long lists of properties that share some features but not others. If you then need to modify a property you are required to go find every preoperty set you included it in and modify it accordingly.
The Solution you'd like
Essentially allow multiple Token Property Types to be assigned to a token under a collection.
Example: Define some property types.
- Stats
- Player skills
- Monster features
- Magic stuff
Then define a group
-
Wizard, contains
- Stats
- Player skills
- Magic stuff
-
Beast, contains
- Stats
- Monster features
Alternatives that you've considered.
No response
Additional Context
No response
I love the idea, this kind duplication bothers me so much.
Define some property types. ... Then define a group
With your examples, what would it look like when I try to assign a type to a token? Would I only be able to choose from Wizard or Beast, or would Stats, Player skills, and Magic stuff also be options for selection?
Probably all of them as there may be a need to add or remove features on-the-fly and the groups are really there as a convenience method of packaging common sets. Macros might be entertaining when it comes to getTokenType. Easy if there's only one or there is a superset, otherwise there might need to be a hasTokenType
Probably all of them as there may be a need to add or remove features on-the-fly and the groups are really there as a convenience method of packaging common sets. Macros might be entertaining when it comes to getTokenType. Easy if there's only one or there is a superset, otherwise there might need to be a hasTokenType
I suspect that there would need to be a function option to truly "remove" a property group, else the property values will persist (like they do now).
I would also go a step further and consider states and bars in these groupings as well. So that they can be associated with the properties. (e.g. if you have stats you have all the states a PC/NPC might have: confused, drunk, blind, blotto. If you have object properties (which might just be simpler like damage/condition) you could have states like damaged, broken... Bars kind of come along with states. It would make the state right click menu easier to navigate if you have lots of types.
I would also add another property of property types... Does the property category show up in the map explorer, so if I make a doors, traps, objects property (or property group) I could chose to have those show up in the map explorer under the appropriate parent node so I can find them faster.
Love the idea, but this may need groups assigned in a certain priority list - there's nothing stopping two groups from containing the same property name. They could be arranged in an order so the group with higher priority supercedes the lower priority group.
Love the idea, but this may need groups assigned in a certain priority list - there's nothing stopping two groups from containing the same property name. They could be arranged in an order so the group with higher priority supercedes the lower priority group.
No need, if both groups contain the same property name, they contain the same property name... flags for the stat sheet should just be an or of the two sets of permissions. Getting into things like priority is just going to make things more complicated for little to no benefit
No need, if both groups contain the same property name, they contain the same property name...
And if they have different default values do they get the first or last default in the list?
No need, if both groups contain the same property name, they contain the same property name...
And if they have different default values do they get the first or last default in the list?
Complain and don't let the user do it would be my preference. Keep things the user has to manage simpler, keep what we have to take into account when we change how tokens work simpler.
Or save it until we split tokens and their underlying representation