Support; would be really handy for a project I had in mind!
Oh my god yes. This is what many-place games need to be truly viable.
2 Likes
I support. I just ran into a problem were this would be perfect. Now Iâm doing a huge workaround.
http://devforum.roblox.com/t/cross-server-instance-database/40553
Please. 
I realize this is not a general solution, but it may help some of you until we get this feature. Hereâs what I did to solve this dilemma for my project:
Publish the same place file to all 3 places in universe.
Check the PlaceId on server start to determine which place in the universe is running, and set a global âgame contextâ value (adventure/pvp/trading). Also delete instances not necessary for the context.
Each module that would behave differently under the context can check the context variable and behave accordingly.
This way, I never have to open any other place file, and every change I make is instantly reflected across the entire universe when uploaded.
2 Likes
This is currently solvable and personally I prefer this method to having some weird container that is distributed to all places in a Universe.
You can use InsertService to insert games as well as models, this means you can distribute similar content by having a single place containing it all.
A script such as follows should work quite effectively.
local GAME_STORAGE_PLACE_ID = 0
local stuff = game:GetService'InsertService':LoadAsset(GAME_STORAGE_PLACE_ID)
for _, service in pairs(stuff:GetChildren()) do
for _, child in pairs(service:GetChildren()) do
child.Parent = game:FindFirstChildOfClass(service.ClassName)
end
end
It will distribute all content into their respective containers. You might need to add a special case for certain services such as StarterPlayer thoughâŚ
4 Likes
That causes the same problem using a shared model does â I have to go out of my way to open up the shared storage instead of just unfolding an entry in the explorer.
Sharing assets between scenes is a core component of any reputable game engine and should not need to be individually built by every developer who needs it on ROBLOX, especially with hacks. This should be an official, painless-to-use feature.
Yes, but a container such as GameStorage seems weird to me since it does not reflect what is in the game file. If we imagine a universe as a file structure it is somewhat like.
Places
1818
Workspace
...
1717
...
Images
img.png
Then logically GameStorage belongs somewhere above the place itself. So I am opposed to the given implementation. I think no matter what the content is going to need to be separate from each place file.
2 Likes
How so? The files I sync between MegaSync (like Dropbox/OneDrive sync) are on all of my computers and are hosted on the cloud â itâs not tied to any of the individual computers, but it still shows up in My Documents on each of them. Using your logic that shouldnât make any sense, but it seems perfectly reasonable to me.
Maybe you feel funny about it because youâre interpreting this as a single storage space that all of the places pull from? Itâs not. These are spaces in each game that the central cloud space receives updates from and then pushes out to the other places, much like the MegaSync synced storage.
Hello!
I donât really feel like itâs good idea
- There can be problems with replication on teamcreate servers. If two would run in one time there can be just some sort of errors, issues etc.
Surely, it would be really complicated - Itâs not that neccessary. You can just use InsertService and loading items into ReplicatedStorage.
EXAMPLE:
local GameStorage = Instance.new("Folder", game:GetService("ReplicatedStorage")) -- Creating a holder
GameStorage.Name = "GameStorage"
local AssetId = 0 -- Asset id containing a folder with instances inside
for _, child in pairs(game:GetService("InsertService"):LoadAsset(AssetId):GetChildren()) do
child.Parent = GameStorage
end- I think linkedsource requiring with
local Module = require("Module")sounds better at least for me.
Other solution
I think that making some sort of universe services such as âScriptStorageâ and âObjectStorageâ would make itâs job.
They would run like standard scripts on the start - normal script on the server side and localscripts on client side.
You could see them in the âGame Explorerâ and it would apply to all the places of the universe.
You could insert only folders and scripts to âScriptStorageâ and all the instances to âObjectStorageâ.
Also you would be able to load use them in script (on both sides) with
local ObjectStorage = game:GetObjectStorage()
local ScriptStorage = game:GetScriptStorage()Scripts in the âServerStorageâ would be also able to load modules
local Module = require("../Modules/ExampleModule")Also changes made by the game scripts wouldnât replicate to the cloud (wouldnât save globally).
Tell me what do you think about that.
Thanks for your opinions. 
It is not possible for two TeamCreate servers to run at the same time. TeamCreate is for working together, so everyone is in a single server.
As mentioned previously, LinkedSource is not appropriate because it can only link scripts, and InsertService is not appropriate either because assets do not update automatically, it is not possible to organize assets, and it requires a dummy script to load them in.
This is exactly whatâs being suggested except scripts/objects are separated in your suggestion.
Actually one server runs per one PLACE, when the GameStorage should replicate for GAME (However thats how I understand your idea).
InsertService loads the newest version, so scripts would update on server start (I think same as it would work in your idea). About LinkedSource - you could just create one linked script which would load other modules.
Not really. Iâm suggesting holding it in the âGame Explorerâ thing which doesnât require the multi-place service duplicating (while live-editting (teamcreate) it would be really really hard / not even possible to do), it would be just held in the universe.
Youâre right â sorry, I misunderstood you. This would not be a problem as changes would be replicated from server -> client in all the places as they already do within a single TC server. There would be a problem with non-TC places as they are not built to receive updates from ROBLOX servers, so they would have to be a mini-TC of sorts where you connect to the GameStorage when you load a place (kind of like how you connect to a database when opening SQL Server Studio).
Thatâs the problem. It loads at runtime â not in Edit. If I have a tree model stored in InsertService, how do I know which positions to insert it to? Do I store location in a config script? Thatâs a lot more painful to use than positioning the trees when theyâre already in the game. No, LinkedSource would still not work â I need to sync instances, so I would either have to use InsertService at some point (which is not a good solution) or just not sync the asset. Current hacks to workaround the problem are not enough â the OP wouldnât have 67 likes otherwise.
Alright⌠But the GameStprage couldnât be LIVE UPDATTED on all the servers. About InsertService - you can do an algorithm which would sort it. Also u can make it so it checks current model version - live editting.
Live servers: It isnât. They download the current contents once they spin up and donât sync after that. Changes made in live servers do not save.
In studio: Yes it could. This functionality is already shown possible with TC.
Again, as mentioned earlier InsertService is not an appropriate solution, and is why the OP has do many likes.
Sorry, but I dont think so. Each place has got itâs own teamcreate server settuped. If you edit more places than one which belong to one game - more than one TC server is running. If the GameStorage would apply to all places in the universe then there is not any already made system for live updating. It would need creation and I doubt it will be easy. Neither for live updating on single server - yeah. This one is already made.
Is this what the Scripts folder is for under the game explorer?
Kind of, but it only is for script sources/raw images (no adjustments to ImageLabels/etc), and it can only be used with LinkedSource/Image properties â I canât, for instance, store a chair or iterate over the contents of the game explorer.
The game explorer was a good first step, but it is largely inadequate for the needs of syncing assets between places in a game.
2 Likes