Forking packages at run time

Hopefully we’re all familiar with packages by now. If you aren’t, feel free to head over to the Roblox Packages article on the Developer Hub.

I have a simple question regarding packages. As this is not documented or specified anywhere, I’ve brought it over to a topic here. I could just test it myself but a second opinion would be helpful.

Currently in a game I’m developing, I use a folder hierarchy to set up a data template. When data is pulled from a DataStore, it modifies this template instead of setting up a hierarchy based on what data is saved. An example of my folder hierarchy is pictured below, though truncated as just a brief view of what it looks like should be enough for context.


What I’d like to do is convert this data template into a package so that every game will receive the same template, without me needing to confirm in every single place whether something’s right or not. The issue I’m running into is that I copy this template for different players and configure it later. So if I copy the template package, I have another package.

I’m thinking that destroying the PackageLink is enough to get by in terms of forking the package, but will this present any potential issues? I know that deleting a PackageLink precompile forks a package, but I’m not quite sure if the same goes for a running server.

Will destroying a PackageLink to fork a package at run time present any issues? Is this enough to fork a package? Is there any concerns I should hold?

1 Like

Didn’t go as well as I was hoping.

Deleting the PackageLink at run time resulted in the folder hierarchy remaining a package, albeit with unsaved changes. This didn’t seem to adversely affect my game since unsaved changes to packages only affect Studio, but I’m not sure if that holds for running games.

Some other methods I’ve thought about in regards to this issue. Each of them are equally as viable in practice and I don’t know if any of them are better, but perhaps I’m just overthinking it. In the end, none of them see any major performance hits and it’s only a matter of comfort to me as the game’s developer whereas the method of data setup is invisible to the players.

  • Creating the folder hierarchy at run time. I would have a copy of a ModuleScript which would be converted into a package. This ModuleScript would be responsible for creating and returning a folder hierarchy for the data structure. Considering I’d like to adopt a library-based hierarchy, this would be a good bet. The ModuleScript, however, will not contain any session data itself - it will only be responsible for creating the folder hierarchy.

  • Copying the contents of the package into a new folder. When a player joins, a new folder is created with their UserId and assigned to them as their data hub. The contents of the packaged data template are then copied into that folder. Easily an interesting use of packages where packages act as a zipped file for elements, which is then extracted into a fresh directory. I would much prefer to do this over fully modularising my data creation structure.

I’ll update the thread if I find anything else related to what was posed in the OP.

By adjusting the hierarchy of the package, it becomes a trivial issue to solve. I would recommend using the following hierarchy:


Then, all you need to do is clone PackageData and you’ll be free to do what you want with it.

1 Like

Had a feeling I was overthinking it. This accomplishes what I’d like while maintaining a package form. Thankfully, the converted package is a folder, so just a quick shift should do the trick. I’m changing the solution to this. Thanks for pointing that out.

I’ll keep the other solutions up if they ever have any use, but this should do it for me completely.


What a charm of organisation that’s become.

1 Like