Plugin.build vs startup_system

[aekobear]

I created a plugin which automates the loading of TextureAtlases and animation of TextureAtlasSprites. At first, I used a startup_system to load the atlas, but after some experimentation, I was able to move the entirety of the system into the plugin's build function by using resource_scope to access the AssetServer.

Is there a meaningful distinction between what should go into build vs a startup_system? What consequences might I encounter if I try loading atlases directly in build()

My initial incentive was to put the logic in build so users of my plugin could put sprite creation logic in any startup stage without worrying about whether the atlas has already loaded

[james7132]

Plugin::build is blocking. Startup systems are run in parallel (if possible). Building plugins should be as fast as possible, so deferring heavy lifting to startup systems is probably best.

[aekobear]

Makes sense, thank you! Is there any etiquette on wrangling plugin startup systems into their own stages, or exposing them so the user can order their own systems if necessary? Or should I just throw my startup_system into StartupStage::PreStartup and have users always setup their sprites in a later stage?

[alice-i-cecile]

For now, toss them in PreStartup, expose public labels. This is a broader problem (#2160), that #4391 starts to address.