Will I have to click this every time I open a script in a package or will this get changed in the near future? My entire project is nested in packages across multiple places so having to click this every single time I open any script is going to be very annoying.
5 Likes
Really happy that we can publish experiences without publishing the packages now. That happened to be an incredibly workflow damaging blocker especially when keeping development copies of a place. I’ve had to delve into some bad workarounds without this feature available.
The best workflow would be having the same package assets in both the live and development areas but only shipping finished changes from the development copy to the live. Since changed packages couldn’t be published, we always had to ship changes in parallel which defeats the purpose of a development copy because the live version would carry a potentially broken feature.
A number of my experiences have switched back and forward between using packages and not; they’re a powerful feature but this quirk blocked us on a lot of fronts especially when we do a lot of iteration. One of my experiences stopped using packages and started using a MainModule to inject changes between the development and live versions which is not a practice I support at all.
Thanks! 
3 Likes
This is exquisite, I love the changes done to packages recently
1 Like
THIS. Exactly. It’s just about the only problem with packages. We need a button to push a package change to all owned places.
3 Likes
Definitely a welcome update, my team uses packages extensively and this should really help.
However, this pop-up is going to get really annoying, really quick. Can we disable it, or get a “don’t show again” option?
5 Likes
Nice to see. Hoping to someday see these as a valid parallel to Unity’s prefabs.
Tragically I still cannot use packages because they are not compatible with my workflow. I lock the parts in my game’s static map which means I need to unlock the entire map to make any changes to it (since it is in a folder). I need to lock these parts to prevent unintentional edits during gameplay with the build tool, especially by moderators who have a less restricted build tool. This results in every single package registering a change, which is a horrible mess to fix and not worth the trouble.
Without improvements to studio to let me hold a key to select locked parts anyway, and to have better control over what the lock tool unlocks (e.g. ignore folders and only target models, target specific parts, etc), I will continue to be unable to use this entire feature.
2 Likes
i personally dont know how to use Packages in studio, or why we should use them over models or .rbxm files
someone pls explain
2 Likes
Does it works across games from different groups?
1 Like
Love the update… A suggestion would be to a merging system for packages. Where when updating all packages, if you have a modified package, it will not delete the modified stuff but merge the new stuff with the modified stuff.
2 Likes
Does this mean the “Publish Whole Game” feature will return? It used to allow you to publish every place in your game at once.
From what I recall, it was removed due to this now-nonexistent Package permutation limitation.
The publish API has an extremely low throttle limit for this use case and cannot be properly automated.
1 Like
Is it possible in the future to have it so for example, I have an items list and I make a change like add a new item or change an item’s stats and I’ve got multiple games sharing this package, will the package be updated on all the games without having to go to each game and publish the changes?
1 Like
Improved Packages is just the first of many Packages related features that are in the pipeline.
A suggestion would be to a merging system for packages. Where when updating all packages, if you have a modified package, it will not delete the modified stuff but merge the new stuff with the modified stuff
We’re researching ways to enable this workflow as talked about at this year’s RDC for Package Interfaces which showed off procedural generation of a tree but the same system could be used for property changes like recolouring a car.
Interfaces enable the package author to ensure forward and backwards compatibility, where the interface can remain stable while the underlying implementation changes.
The challenge with merging is that you can get into a situation where you apply a property onto a package instance sub-part which when upgraded to vN+1 no longer exists OR a scenario where your intent doesn’t come across after a package upgrade.
An interface would work around this limitation because the package author publishing vN+1, would “know” that a subpart no longer exists, and can ensure that things are seamless for any package consumers.
Example
Imagine a White Car Package with no spoiler in vN
You recolour the car by changing every exterior panel to Red.
The Car Package gets upgraded to vN+1, but this new version has a spoiler.
You would end up with a Red car with a White spoiler.
If you have an interface where you can set CarColour=Red in vN, then when the Car gets upgraded to vN+1, the package author can ensure intent is maintained/forwards compatibility by setting the interface values to:
Interface
-CarColour=Red (your value in vN)
-SpoilerVisible=False (new interface value in vN+1)
Car.Spoiler.Colour=$Interface.CarColour
Car.Spoiler.Visible=$Interface.SpoilerVisible
2 Likes
Does it update the package automatically across multiple places without me having to go through every single one and publish them one at a time? That is a feature I’d like to have as some games have multiple places and pushing out updates can be a real pain.
3 Likes
Enabling PackageLink.AutoUpdate should fix this issue.
1 Like
There’s still no way to mass update and publish in a single operation as we’re worried about the implications of enabling such a workflow: Mass update and publish without verifying that the package actually works correctly in all of the places first is a very potentially disruptive operation without any easy way to undo it if something goes wrong.
We’re still on the fence but aware that it’s a popular request and considering something like a “publish whole universe” option.
As Subtotal notes above, there is a relatively low friction option right now in enabling autoupdate, such that you simply have to open each place, do a quick check that everything still works, and hit publish.
3 Likes
Just want to add that I would love an option for my places to self-publish when packages are updated. As @MonkSaru pointed out, if I have a game with many places, publishing can be a real pain. I understand the caution around enabling such a workflow. However, if I have a careful loading sequence that all my places follow, I believe the benefit of such a feature would easily outweigh any self-imposed risks… Especially if this auto-publish feature is opt-in for individuals who would prefer that workflow.
3 Likes
Thank you for this! Our game POOH! uses these heavily for our UI, Assets, and etc. across our universe!
2 Likes
Fixed the link in this reply…
I desperately want to be able to use packages but they are too messy with the way they interact with locking/unlocking. Using packages would allow me to bulk update entire forests and avoid breaking instancing. I have written command bar scripts to mass update cloned assets in my game map literally hundreds of times by now.
3 Likes
Do you actually need to lock / unlock the packages as part of your workflow or do you just have to unlock them while doing edits to their contents? (could you give some detail on the workflow)
1 Like
I unlock the whole map when doing map work. The map is in a folder and the lock tool affects the whole hierarchy at once. I need to be able to grab and drag package models around + duplicate them to build the world, so they need to be unlocked for me to do that, but I need them locked in gameplay. Packages in my case would be used for reusable map props like trees and plants.