Forums » Suggestions
New plugin event: PLUGINS_LOADED
Please add a new event that will trigger when the plugin load sequence has finished so that we can accurately perform additional actions at this time.
+1
+1
But why limit it to plug-ins? I'd rather see INTERFACE_LOADED after the interface is done loading (including loading of plug-ins).
But why limit it to plug-ins? I'd rather see INTERFACE_LOADED after the interface is done loading (including loading of plug-ins).
+1
Yes, please please PLEASE!!
I'm tired of using a combination of PLAYER_ENTERED_GAME, ENTERING_STATION, and HUD_SHOW to accomplish the same thing.
Yes, please please PLEASE!!
I'm tired of using a combination of PLAYER_ENTERED_GAME, ENTERING_STATION, and HUD_SHOW to accomplish the same thing.
meridian, perhaps I'm not following what you're after, but this either happens before the plugin loading sequence starts and is therefore useless to us, or it happens on HUD_(SHOW|HIDE).
HUD_SHOW doesn't get called if the player starts in a station (as Keller indicates).
I guess what I'm requesting is a single event triggered after both the interface and all plug-ins have finished loading. I'm not sure what order things happen in and didn't want to assume that the interface has been completely loaded when all plug-ins are.
I guess what I'm requesting is a single event triggered after both the interface and all plug-ins have finished loading. I'm not sure what order things happen in and didn't want to assume that the interface has been completely loaded when all plug-ins are.
The way I'd see it would be that PLUGINS_LOADED would be fired when the plugins have completed loading, but before anything else (which we're currently using PLAYER_ENTERED_GAME to perform and is 1) confusing, 2) not clear when this event fires in relation to others), and INTERFACE_LOADED would fire right before you would enter a station (but before ENTERING_STATION) or your ship in space (also before HUD_SHOW).
The 2 new events would give us a way to do some data housekeeping before things start getting complex.
Of the 2, if I could only get 1, I'd ask for PLUGINS_LOADED, as this is a cleaner event and we wouldn't have to do so many weird things to handle resets and interface reloads as we do now, but INTERFACE_LOADED would be a common event when entering either a station or your ship in space.
The 2 new events would give us a way to do some data housekeeping before things start getting complex.
Of the 2, if I could only get 1, I'd ask for PLUGINS_LOADED, as this is a cleaner event and we wouldn't have to do so many weird things to handle resets and interface reloads as we do now, but INTERFACE_LOADED would be a common event when entering either a station or your ship in space.
We'll take a look at this, in between other priorities.
What things do you need to do after your plugin is loaded? Communicate to other plugins? That's the only thing I can think of that you'd need to do.
As for INTERFACE_LOADED, I don't know when you want to have it be generated. I can add something for when ReloadInterface is complete, but interfaces aren't 'loaded' when a player enters a station or space. Using ENTERING_STATION and HUD_SHOW. Or do you need your plugins to be told before the main UI code is told so you can set up things before the interfaces are made visible? If that's the case, then maybe some sort of priority system should be implemented. However, it'd be possible to have a problem where plugin A depends on B and B depends on C and C depends on A.
I'll add PLUGINS_LOADED for the next update.
As for INTERFACE_LOADED, I don't know when you want to have it be generated. I can add something for when ReloadInterface is complete, but interfaces aren't 'loaded' when a player enters a station or space. Using ENTERING_STATION and HUD_SHOW. Or do you need your plugins to be told before the main UI code is told so you can set up things before the interfaces are made visible? If that's the case, then maybe some sort of priority system should be implemented. However, it'd be possible to have a problem where plugin A depends on B and B depends on C and C depends on A.
I'll add PLUGINS_LOADED for the next update.
I've got one that uses the functions of another plugin (DevKit) to provide detailed debug info without duplicating lots of DevKit's code.
Thanks, raybondo.
It's a semi-essential step if we want to be able to write plugins that can rely on other plugins. Rather than having to register multiple events and set flags when certain task are completed, we can rely on the fact that when all plugins have finished loading, the PLUGINS_LOADED event will trigger. From there we can take care of any additional setup that one or more plugins may need to accomplish due to requests from later plugins in the load order. For instance, I've wanted to write a plugin that allows other plugins to register an options button which is then populated into a central location, but knowing when to populate the list of buttons isn't exactly clear in the current environment.
I really would like to eventually see some sort of priority system put in place, where each plugin can describe it's dependancies and either load necessary plugins out of order, or just fail to load if the required plugins aren't available. Like you say, this could eventually get into some sort of circular dependancy hell, but that should be fairly easily avoidable by either placing the onus of avoiding these things on the plugin writers, or by keeping track of the plugin load stack and failing the entire thing if you eventually reach a point where the plugin to be loaded matches one that's already on the stack.
It's a semi-essential step if we want to be able to write plugins that can rely on other plugins. Rather than having to register multiple events and set flags when certain task are completed, we can rely on the fact that when all plugins have finished loading, the PLUGINS_LOADED event will trigger. From there we can take care of any additional setup that one or more plugins may need to accomplish due to requests from later plugins in the load order. For instance, I've wanted to write a plugin that allows other plugins to register an options button which is then populated into a central location, but knowing when to populate the list of buttons isn't exactly clear in the current environment.
I really would like to eventually see some sort of priority system put in place, where each plugin can describe it's dependancies and either load necessary plugins out of order, or just fail to load if the required plugins aren't available. Like you say, this could eventually get into some sort of circular dependancy hell, but that should be fairly easily avoidable by either placing the onus of avoiding these things on the plugin writers, or by keeping track of the plugin load stack and failing the entire thing if you eventually reach a point where the plugin to be loaded matches one that's already on the stack.
How I've traditionally gotten around the dependency thing is by a convolution of declare
declare ("plugin", plugin or nil) and by using lazy loading for all features and screens. I haven't tested the scheme under all conceivable scenarios, but it's worked so far.
Nevertheless, this is why I'm supporting the use of the 2 functions.
Ray,
What we'd like with INTERFACE_LOADED is what you outlined. Something which fires immediately before either the station interface or the HUD comes up. Up to now, we've been using a combination of ENTERING_STATION and HUD_SHOW to accomplish the same thing, but the INTERFACE_LOADED event would be very effective if one wishes to add dynamic elements to either interface. So I supposed the correct answer would be firing the event immediately before you'd fire either ENTERING_STATION or HUD_SHOW.
declare ("plugin", plugin or nil) and by using lazy loading for all features and screens. I haven't tested the scheme under all conceivable scenarios, but it's worked so far.
Nevertheless, this is why I'm supporting the use of the 2 functions.
Ray,
What we'd like with INTERFACE_LOADED is what you outlined. Something which fires immediately before either the station interface or the HUD comes up. Up to now, we've been using a combination of ENTERING_STATION and HUD_SHOW to accomplish the same thing, but the INTERFACE_LOADED event would be very effective if one wishes to add dynamic elements to either interface. So I supposed the correct answer would be firing the event immediately before you'd fire either ENTERING_STATION or HUD_SHOW.
Keller, how would the proposed INTERFACE_LOADED event deal with the HUD, in-ship PDA, and Station Interface? Would it need to distinguish between more than just "ship" and "station" (possible return values)?
Probably because I haven't worked much with modifying the PDA or HUD, I still fail to see the usefulness of such a singular event, except possibly as a means to try and avoid display jitter as controls are added/rearranged. Avoiding display jitter in my mind is a far stronger selling point for such an addition, since the events that you and ray already listed seem like they should be otherwise sufficient. To this end, as you suggest, it should probably fire right before HUD_SHOW. But instead of before ENTERING_STATION, it should probably fire before SHOW_STATION.
As ray already alluded to, the name INTERFACE_LOADED seems to be a bit of a misnomer. Maybe something closer to it's purpose could be come up with.
Probably because I haven't worked much with modifying the PDA or HUD, I still fail to see the usefulness of such a singular event, except possibly as a means to try and avoid display jitter as controls are added/rearranged. Avoiding display jitter in my mind is a far stronger selling point for such an addition, since the events that you and ray already listed seem like they should be otherwise sufficient. To this end, as you suggest, it should probably fire right before HUD_SHOW. But instead of before ENTERING_STATION, it should probably fire before SHOW_STATION.
As ray already alluded to, the name INTERFACE_LOADED seems to be a bit of a misnomer. Maybe something closer to it's purpose could be come up with.
FYI that PLUGINS_LOADED is released now. Feel free to continue the discussion/feedback on here for Ray, with INTERFACE_LOADED or whatever.
I had been thinking that it should include the object about to be displayed, although now thinking about, I can think the efficacy might not be there for a generic "I'm about to display an interface" kind of event.
Inc, noted. It'll be very helpful now that the PLUGINS_LOADED event is in place. I doubt I'll be doing a massive rewrite of the plugins I have which could make use of it, but that would definitely be on the long term list of things to do, as it would streamline a lot of initialization code.
Inc, noted. It'll be very helpful now that the PLUGINS_LOADED event is in place. I doubt I'll be doing a massive rewrite of the plugins I have which could make use of it, but that would definitely be on the long term list of things to do, as it would streamline a lot of initialization code.