You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Filter = VerySpecificGroup|StringFilters|FormFilters|LevelFilters|Traits
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 withKeyword
approach, but lack of other disadvantages outweight this difference.The text was updated successfully, but these errors were encountered: