Indeed, the major plugin update is not even out the door yet. But this is a better system for many reasons.
Rather than using experimental decorators, plugins will go back to using a usePlugin syntax. This offers numerous benefits.
Less annoying syntax (decorators require a lot of syntactic salt).
No more forgetting to add a field to decorator interface.
Don't have to worry about building the interfaces at all...
Passing parameters into the plugins is a lot easier.
Eliminates the need to extend GameInstance. Just instantiate a GameInstance and call usePlugin multiple times to rock and roll.
Eliminates risk of naming conflicts with competing plugins, especially during updates.
Plugins could potentially communicate with one another using getPlugin.
Restores ability to use private fields in the GameInstance as well as in plugin classes.
If additional behavior is required for a specific game, a new plugin can simply be created for that game. The developer could even do different plugins for server vs client!
The downsides are manageable.
Plugin access to core functionality can be managed because the plugins will have access to the core GameInstance.
Indeed, the major plugin update is not even out the door yet. But this is a better system for many reasons.
Rather than using experimental decorators, plugins will go back to using a
usePluginsyntax. This offers numerous benefits.GameInstance. Just instantiate aGameInstanceand callusePluginmultiple times to rock and roll.getPlugin.GameInstanceas well as in plugin classes.The downsides are manageable.
GameInstance.