then let you use them to simplify your actual distribution:
Outfit = MySpecialOutfit|VerySpecificGroup
This approach has few advantages and disadvantages:
✅ it does simplify the actual distribution, when you need to target complex group
✅ it lets you negate complex filter, basically it's a workaround to make a NOT(A+B) or NOT(*wildcard) which are otherwise not supported.
✅ it runs complex filters once when evaluating keywords, this reduces overhead of otherwise evaluating the same filters for each entry.
📛 it distributes one-use keywords that stick to NPCs and don't provide any value after initial distribution.
📛 it creates lots of dynamic forms that are actually not needed because of ⬆️.
📛 it piles up list of keywords, making other filters that look for matching keywords take more time than they'd need.
Not bad but could be better 😄 as we're trying to reduce heavy usage of Keywords.
We definitely want to preserve all the good stuff that keywords bring, but avoid those downsides.
So, the solution is to extract this use case of Keywords and implement it as a dedicated entry.
Welcome, Filter!
To achieve the same results we could define a reusable filter:
It then can be used in other entries exactly as you'd use Keyword in this case:
Outfit = MySpecialOutfit|VerySpecificGroup
Internally, Filter's results will be stored inside NPCData so that they'd be evaluated once per distribution cycle for each NPC. This let's such complex filters to run only once per distribution. This is not exactly the same as with Keyword approach, but lack of other disadvantages outweight this difference.
Another common misuse of Keyword entries is to define certain set of filters and make it a "framework" for others to use.
Few examples:
All_Key - SPID Keyword Framework
RMB SPIDified
and to be honest my own NPCs Learn Skills & Spells would be doing it 😄
What they do is offer advanced conditions, like
Keyword = VerySpecificGroup|StringFilters|FormFilters
then let you use them to simplify your actual distribution:
Outfit = MySpecialOutfit|VerySpecificGroup
This approach has few advantages and disadvantages:
✅ it does simplify the actual distribution, when you need to target complex group
✅ it lets you negate complex filter, basically it's a workaround to make a NOT(A+B) or NOT(*wildcard) which are otherwise not supported.
✅ it runs complex filters once when evaluating keywords, this reduces overhead of otherwise evaluating the same filters for each entry.
📛 it distributes one-use keywords that stick to NPCs and don't provide any value after initial distribution.
📛 it creates lots of dynamic forms that are actually not needed because of ⬆️.
📛 it piles up list of keywords, making other filters that look for matching keywords take more time than they'd need.
Not bad but could be better 😄 as we're trying to reduce heavy usage of Keywords. We definitely want to preserve all the good stuff that keywords bring, but avoid those downsides. So, the solution is to extract this use case of Keywords and implement it as a dedicated entry.
Welcome, Filter!
To achieve the same results we could define a reusable filter:
It then can be used in other entries exactly as you'd use Keyword in this case:
Internally, Filter's results will be stored inside
NPCDataso that they'd be evaluated once per distribution cycle for each NPC. This let's such complex filters to run only once per distribution. This is not exactly the same as withKeywordapproach, but lack of other disadvantages outweight this difference.