Open ericrosenbaum opened 6 years ago
Thanks for documenting this @ericrosenbaum. Given @kchadha's work on SB3 save / load we should probably chat about this soon. :-)
Will there be future cases where an extension will need to save global or sprite-specific state info?
Probably! I say make the extension system as powerful as possible. One example use case I can think of is for a physics extension, remembering a sprite's gravity. Or for an extension that adds custom reporters, there would be plenty of state needed to keep everything linked together correctly. Or for an extension that types text on the stage on a pen-like layer, remembering what text was last left on the stage
From discussion this is something we would like to support, but this will not be ready for initial release. Moving to backlog.
Should the SB3 file format include state information used by extensions?
There are some examples of "global" (i.e. non-sprite-specific) state used by extensions that we will need to save and load, for compatibility reasons. This includes:
For sprite-specific state (now handled by the "custom state" mechanism), it seems to generally not be saved in 2.0 (such as pen color and size, instrument, volume, etc).
So the question is, do we need SB3 to be able to save and load global or sprite-specific state?
We can handle the legacy saved state for tempo and videoAlpha by adding them to the stage (I did this for the tempo). The SB3 format will presumably need to include these.
Will there be future cases where an extension will need to save global or sprite-specific state info?