I agree that there should be some sort of licensing agreements and jurisdiction overseeing that people respect these licenses. If it’s a super complex system and people are monetizing it against your terms, then you should have the right to request some sort of action be taken.
3 Likes
No no, we used module scripts so we could hide the code and cancel the script if they kept using it without paying the subscription.
Also, already tried having leaked assets taken down; seems Roblox only sticks to the policy for outside companies/people.
Personally, I’m far too distrustful of black-box code to use it in my game.
The notion of having top-developers use code which they cannot see or fully manipulate is quite scary, when you consider the serious implications behind it. I would strongly oppose the creation of a private packages feature.
1 Like
I recently set up a system to insert all of the scripts in my game across many places using InsertService. I’m going to keep relying on this until the auto-update functionality for this comes out. Any ETA on that? Would love to use it, but it’s still not practical for me just yet.
6 Likes
This is going to be useful for a future game of mine, but I’m going to wait for mass-update before I do anything serious with this.
I’m interested in knowing when we’ll get universe-level scripts.
Edit: NO THEY’RE CANCELLED 
https://developer.roblox.com/resources/Roblox-Platform-Roadmap
9 Likes
What! Damn it. Those were going to be so good.
3 Likes
It’s not the same 
salivates
This is great stuff! Packages are the way of the future.
Not in this first release - Access Permissions is what would allow you to do that.
Here’s what we’re thinking as far as levels:
- Use Access: These people can insert copies into their games & update their copies to the latest version
- Edit Access: These people can publish their changes as new versions to the cloud (includes use access)
(I updated the description in the original post - thanks!)
5 Likes
Sadly, we had to turn this feature off temporarily, as we’ve discovered some issues with uploading assets.
We’re working to fix these issues and will keep this post updated with the latest info!
Update:
The issues have been resolved and the Packages feature is now live again!
11 Likes
Ha, I was about to post that it appeared to be back! Thanks for fixing it so quickly, keep up the awesome work.
2 Likes
Here’s a suggestion to the packages system: Allow converting of Models to Packages, without the model needing to have a primarypart or needing to be up-to-date with their position. This a great thing for re-used maps on different places. However it is a burden when you want to upload pick ups as Packages, then they all want to move to their “saved” location, otherwise not allowing you to update your place.
EDIT:
Nevermind, it seems this has been implemented already. I was going off of my experience with uploading my framework and it notifying me that changing the position would require an update for the Package. My apologies! 
Any plans to add a tab for these in the develop pages soon?
The is a great new feature! I plan to use packages so that all the places in my game can share a common code base. The auto update feature, when it becomes available, will be really useful for this.
I’m already doing this, and can attest to its efficiency!
Not only has this helped me by allowing for more efficient code re-utilization, it has furthered my development skills by helping me write efficient code that can be used across a limitless range of scenarios.
2 Likes
So effectively, you could have a script tell a package which version to use and say, for example, on a certain date, have that package update to the latest version and the game would change to suit it without any manual updates?
hmm
1 Like
I can’t say I’m particularly fond of floating point errors triggering new package versions:
20 Likes
Try setting a primary part in that model - the “New Package” doesn’t trigger if you have a primarypart I believe.
You can’t create a package without setting the PrimaryPart, and setting the PrimaryPart of the parent model makes no difference.