Instead of using the regular Status Effects, change to use PF2e's Conditions. And instead of using Active Effects, use PF2e's Effect items. Rather than create brand new, PF2e-specific behaviors, I just repurposed the existing ones since they were more-or-less functionally equivalent.
This includes a bunch of reorganizing/refactoring to have separate implementations based on the system. This separation should help with the eventual system-specific filtering, but we'll have to see if it works later on. This adds a "base" implementation for the four Region Behaviors and creates separate Core and PF2e implementations that extend those classes. I also decided to use a mixin for some of the shared functionality between the Status Effect and Active Effect behaviors. Not necessary, but I already had some shared functions so it made sense.
kaelad02
commented
1 week ago
Instead of using the regular Status Effects, change to use PF2e's Conditions. And instead of using Active Effects, use PF2e's Effect items. Rather than create brand new, PF2e-specific behaviors, I just repurposed the existing ones since they were more-or-less functionally equivalent.
This includes a bunch of reorganizing/refactoring to have separate implementations based on the system. This separation should help with the eventual system-specific filtering, but we'll have to see if it works later on. This adds a "base" implementation for the four Region Behaviors and creates separate Core and PF2e implementations that extend those classes. I also decided to use a mixin for some of the shared functionality between the Status Effect and Active Effect behaviors. Not necessary, but I already had some shared functions so it made sense.