EffectLib has been seeing extensive modification in the last several days thanks to my own private experiments behind the scenes.
Mind you, I'm attempting to keep as much of EffectLib's API consistent as possible between releases. This doesn't mean I'll be fully rewriting this library again and again like I've done over the last few years, but I am not attempting to make the whole operation backwards compatible.
EffectLib 2.0-2.2 included quite a few changes that actually fully change the build process for the library. Among them, I migrated some of EffectLib's behavior over into StdLib, and made EffectLib dependent on StdLib 2.2.
2.3 so far is a pure feature upgrade. At the moment, my private build of the library includes some new functionality that will make using the structures much easier without actually forcing the user to modify them.
active -> state
I've removed effect.active in favor of effect.state. Effect.active was a simple yes/no boolean value that would only tell you whether the effect was still in the target's effects list. I actually ran into a situation where I needed to know whether an effect was canceled or whether it expired naturally. This prompted a sweeping overhaul of how effects report their current state. Effects now provide information about how they were removed, and not just whether they are still running.
I also ran into a situation where I needed to work out when an effect had actually ended, so effects now store their end_time in a new variable upon removal. This makes working with effects as sort of dead-man switches possible, as well as using them for things like action progress and spell chargeup possible to boot.
I just finished working in a new preprocessor declaration that effectlib will look for in order to determine what /effect inherits from. If this flag is declared, the /effect type will potentially wind up being an /obj child type rather than a /datum child type. This allows developers to actually give effects visual appearances so that they can be displayed in statpanels, grids, or on screen if the developer so wishes.
I'm still mulling over a better way to handle ticker effects. Currently the first tick happens the instant that an object has been added to the target, and ticks have a minimum separation of a single tick. I'm going to be doing away with both of these limitations by doing some better math to work out when the next tick actually should happen. This will also have the added benefit of allowing ticker effects to save and restore in between ticks, and still have the number of ticks passed over the object's two lifetimes stay perfectly aligned to the time and separation specified by the developer.
This is an open call for feature requests or questions about EffectLib. I want to have more to push before 2.3 gets dropped, and I want to make it as user-friendly as possible, so I'm definitely open to any suggestions about my direction with this library.
Copyright © 2019 BYOND Software. All rights reserved.