Storage that exists in studio only

As a Roblox developer, it is currently too hard to store parts, scripts, etc. that should neither exist workspace, server storage nor replicated storage.

If Roblox is able to address this issue, it would improve my development experience because many times we would try out models or things like maps, props, or even scripts. If we want to backup and don’t want them exist in workspace, we currently have to move them into ServerStorage. But this would increase unnecessary memory/space for a server. Even so in ReplicatedStorage where they would be replicated to clients.

I know of Archivable property. But when we set a part Archivable=false, the next time we open up the project in studio, that part is totally gone. Doc says this property will make studio not save this part at all.

7 Likes

What if you just publish them as a model or package, or just have a separate place where you put testing stuff.

2 Likes

I know it is not what it currently is, but imagine the ‘ReplicatedStorage’ and ‘ServerStorage’ exists in separate place, and you have to publish and import to make changes. It would be very hard to work with this workflow.

I would find this very useful, as I currently have a folder of archived assets to use later, such as skyboxes that are not currently in use, and other various models (for quick access).
I put them in ServerStorage so it will be loaded onto the sever, which is the minimum currently. I would love some sort of archive or “backpack” to store unused things in. Scratch (the block coding site) has a backpack feature similar to this which is very helpful.

1 Like

Trying to understand the problem better.

Can you expand on under what workflows package asset would cause issues here ?

1 Like

made from artist:
ServerStorage.Model_Take1
ServerStorage.Model_Take2
ServerStorage.Model_Take3

game designer
move Model_Take1 into workspace, add scripts. play. not feel good
move Model_Take1 back into ServerStorage
move Model_Take2 into workspace, add scripts. play. maybe take1 is better
move Model_Take2 back into ServerStorage
move Model_Take1 into workspace. no need to add script again. play. good but lacking
take some parts from within Model_Take3 and copy it into Model_Take1. play. good

These are easy. just moving and renaming things. as long as the outcome is pleasing to both the artist and game designer. no need back and forth between them to make change in the other place and reexport and reimport the assets.

Could you explain how to improve productivity with the package asset workflow in this particular situation?
The current workflow is fine. but it is just a slight matter that the ‘ServerStorage’ is used to store all those backups and will exist in the server.

Basically what I get from this is that you want a storage container for Instances that will not exist outside of Roblox Studio.

I do not see a use case for this personally. Most developers use different places: one is a production and the other is development. I don’t exactly know how Roblox’s servers work but I would also assume that having those assets destroyed at the beginning of a server could also work.

Something like this maybe:

local RunService = game:GetService("RunService")
local CollectionService = game:GetService("CollectionService")

local TAG: string = "STUDIO_ONLY"

for _, instance in CollectionService:GetTagged(TAG) do
	instance:Destroy()
end

This may be of us to you too.

of course we have dev and production. dev is another experience that we develop, publish to test (privately), and then “publish as” into the production experience (which is public)

it has nothing to do with the original request. because the production will have exactly everything as-is from the dev experience. including all the backups within ServerStorage

having yet another ‘Asset’ experience or place just to store things and then import export between the dev/production experience is error-prone. and i doubt the ‘most’ quantifier you used.

yes and no. if they don’t exist in the first place, then there is no need to tag them and remove them

If we could have inventory that we can store items there like tools to make it better for managing tools for an example a treasure chest model with inventory of gems and gold in there

I believe they are proposing the introduction of a new Studio Storage feature, available only in the studio, where you can store any assets needed for future development. Currently, storing unused assets alongside actively used assets that are ready for production can be confusing and frustrating. Moving them to another studio place or publishing them as a package is also an option, but these solutions can be inconvenient as well.

For example, let’s say you’ve finished working on the next update and have some free time to start preparing for a future update or event. You create models, icons, scripts, etc., but don’t need them immediately. Storing all these assets in a Studio Storage instead of the Replicated/Server Storage, which only contains actively used assets, would be more efficient and less confusing. This would be a private Storage location where you can temporarily store assets until the time comes to actively use them in your experience. (This could also be useful for storing prototypes in an early development state, until you review them)

5 Likes

Just make a script that destroys the folder(s) when the game starts.

Mark as solution if helpful.

Is there a reason why you couldn’t just save these assets to your group? Where they aren’t taking up memory or storage to that particular game? I don’t get what issue you are having here? If you don’t want them stored in the game but don’t want them in the live game but also don’t want to take up memory/storage just save them as a model to the group…

Yeah, this was already suggested, and it could be used until something like this is added, but it goes against the want of the request which is for this to be costless for runtime, and this still goes against the server initialization time and the initial memory usage, though It’s unlikely that these will be much of an actual issue for somebody.
I’ve seen games that struggle with server initialization times pretty bad though.

1 Like