Right now, if I want to create a module, I have to set up something to move everything into the correct folders..
ie: Shared content in Replicated Storage, Server stuff in ServerScriptStorage, and client stuff in StarterGui or whatever…
I’d like a new Service called ModuleService or something along those lines where we can put a folder into it and in that folder we can set up the structure and the game will virtually move those elements into the correct services on compile. This way everything for that module can be together and help organize more complex systems in games.
What is the usecase exactly? Why would modules not be in their desired organization from the get-go?
Also, I’m wondering if this comes down to personal preference, could you instead make a “Modules” folder in ServerStorage or ReplicatedStorage? This preference seems to niche and non-functional to be implemented as a new service.
Lets say you have a fully complete Inventory system.
You have server-side code you don’t want to expose to the client. You have shared module scripts, and you have gui and clientside code.
That requires the use of 3 to 4 different storage locations. So if you want to copy it to another experience, you have to remember those 3 or 4 different spots where the files are located and copy them to their respective spots.
My idea is that there is a virtualization service, ModuleService, which lets you create a single folder called InventorySystem or whatever, then add in the ReplicatedStorage, ServerScriptStorage, StarterPlayerScripts, StarterGui services to that folder, and put your files in there.
Copying the system to a new game is as simple as copying a single folder from ModuleService into the new experiences ModuleService.
Then why does this need an entirely new service for something so hyper-specific? Your problem would be better solved asking for a property on instances like a ReplicationContext, which would be far more versatile and not limited exclusively to programming use cases.
What bothers me more is that packaging system is not designed to support different locations either.
Goal of packages is joining components related to one feature into one bundle; which is not possible because of Roblox experience design and packages design.
Updating packages to be sort of experience wide to contain instances from different places (Workspace, ReplicatedStorage, name it) would solve the same issue.
Because bundling a package and then having to move them manually, and then updating them happens in so many different locations when it could be in a single location.
Exactly! I wanted to bundle up my stuff for my other games but can’t so its basically moving stuff from multiple locations, unpacking it to those locations, and it is just a hassle.