As a Roblox developer it is currently too hard to have plugins save Instances to a place in a transparent and unobtrusive manner. As plugins become more powerful, there are more and more of them that require Instances be saved or stored for later access. This has lead to using services such as ServerStorage or Geometry for these Instances. Unfortunately, storing Instances in ServerStorage can clutter the service, and using a service like Geometry is not ideal because it is not visible to the Explorer (and it is not the intended use of the service).
If a PluginStorage service were added, it would solve this problem and allow developers to store Instances from plugins while also keeping them in a centralized and unobtrusive location. This would give plugin developers a clear place to store their created Instances, and would make the game hierarchy cleaner.
Right now, I’m storing plugin data in ServerStorage. This is a problem, since, like OP said, this adds a lot of clutter (esp. if you have a lot of plugins doing the same thing).
ServerStorage is also a dangerous place to store plugin data since it’s affected by studio’s undo/redo. For my Brushtool plugin, I had to give users the ability to do a manual save + an autosave every 30 seconds just in case the user accidentally undoes a save. If the user saves and exits studio without manually saving, then they risk losing data if it isn’t autosaved. There’s also the risk of users/other plugins accidentally messing with the data and breaking the plugin.
Lastly, since stuff in ServerStorage are loaded when the server starts, this can increase server start times.
(There would have been another problem with MeshParts and Unions stored in ServerStorage being replicated to the client even if they’re never used, but this has been fixed recently.)
This would be an amazing feature to have. I currently store prefabs for my plugins in the Geometry service and it feels so weird to use a container like that just so I don’t have to let people using my plugin see their containers fill up with objects that are temporary.
Would love to see Roblox give us a service like this!
Massively support. A lot of plugins are filling up my ServerStorage which is annoying as a developer, and it’s very frustrating as a plugin developer to not have a clean place to manipulate and store instances without getting in the way of the user.
One thing that I think should be explicitly stated: The PluginStorage should replicate if you are in TeamCreate, just like ServerStorage does. It should save into the place files, just like ServerStorage does. We want the same behavior so nothing breaks if we switch from ServerStorage to PluginStorage, just give us a new container for the sake of organization and plugin usability.
Definitely need this, even though plugins have their own container,
They do not save between places. It would also be a useful place to parent plugins to, since the parent property doesn’t lock.
Having to parent stuff to either ReplicatedStorage or ServerStorage creates a problem where Instances could get left behind when you save. I believe this is what the Archivable property is for, but it’s not a clean solution.
And as boatbomber said, it’s just better organisation.
I wrote an Instance serialiser yesterday kind of for this purpose (had a plugin idea, but no way to store Instances across places), but obviously with large Instances (like models), it can take a little while to serialise, and would take up a lot of space on the user’s computer in the settings.json without compression (which adds even more time onto the process)–also relies on the HttpService to get a copy of the client dump, which is undesirable.
The binary model files take up barely any space, so they’d be a great solution for saving Instances.
If Roblox wants plugin development to become more popular and accessible, this feature is a must have in my book. Developing on Roblox is great because it conceptualizes the process of game development through ‘building blocks’. Games are made by adding objects together, cloning them, moving them and giving them behavior. Moreover, Roblox is the only platform where graphical artists are called builders in the community, because this is how people approach development in Roblox: through building blocks.
Plugins however, take the complete opposite direction and offer no support for this ‘building blocks’ workflow. If you want to save an instance, you better serialize it. Worst thing about it? Only very few developers on Roblox actually know what ‘serialization’ means.
This feature would make it so much easier to create certain plugins, such as:
A plugin that lets you save and load lighting pre-sets in place files.
A plugin that stores prefabs in an interface for easier access than keeping your assets floating somewhere in your place file.
A plugin that allows you to create UI more easily by letting you drag and drop UI components / pre-sets into your UI windows.
‘Level builder’ plugins created to speed up the development process of your game by stitching together assets into your world.
I’ve lost my entire library of 50+ models in Brushtool due to this issue, twice. It is a massive headache for me as both a plugin user, and a plugin developer not to have a protected storage service exclusively for Studio that is not affected by undo history, because I also have to worry about problems like this affecting my plugins.
I have a bunch of garbage in my ServerStorage because of plugin nonsense, one of which is there because of the previous issue. Brushtool (very popular), TagList (very popular), and _MPlacer (my own plugin) are all plugin folders. Common and Storage are the only two folders here that are important to my game, but are actually not important to gameplay; they’re storage for things like AnimSaves, old character models, props and models actively in use or for use occasionally, and deprecated / archived code. There’s 45k instances under ServerStorage and none are used for gameplay. This is 20% of all of the instances in my game under Workspace, ReplicatedStorage, ServerScriptService, and ServerStorage. This is ~200 MB of unused instances on the server, and for games even larger than mine with more significant plugin and misc. development storage, this is likely much higher, or they’re forced to split into different files which is much less convenient. Keep in mind also that my Brushtool library is a quarter of the size it used to be.
With respect to the feature request, to be more accurate, we need a Studio-only service (e.g. StudioStorage) for plugin data and non-gameplay storage that does not get loaded in live games, and finer control over whether or not an instance subtree is affected by undo history in Studio, so we can have plugin-controlled folders that are managed separately from the game hierarchy, be it via a PluginManagedStorage service, or a property.
Want to bump this in support. This would benefit both game developers and plugin developers immensely.
Every post above this basically spoke for me, I dislike having ServerStorage be cluttered by plugins because they don’t have anywhere else to go (besides going inside of more obscure services, but this is not ideal either).
Bumping this because I DEFINITELY want to see this added to Studio. I use various plugins that store models (including Brush Tool) in ServerStorage or other services. Having a PluginStorage service would help with cleanliness and prevent loss.
It’s still unfortunate that this is not a feature yet. It’s really sucks that ServerStorage is still needed for some things, my plugins output things such as settings backups and I have to do it in game.ServerStorage.Plugins.ExperiencersInternational.auroraSuite etc which isn’t ideal.
Having a PluginStorage instance would make it a lot easier for me to store information.
Having a centralized space for plugin data would be useful for both users and plugin developers. Currently, it is dangerous and inconvenient to store data in server storage. Existing plugins could move a folder from Server Storage to Plugin Storage. It’s crazy that this thread was created in 2019 and still no sighs about this feature or even a response from roblox staff.
