Improved Visibility of Package State and Actions

[desserts_yumyum]

[Update] July 15, 2024

@desserts_yumyum

Hi Creators,

We have rolled back the changes to address an issue where Explorer reserves space on the right, truncating instance names. We will update this post once the issue is fixed and the feature is available again. Thank you for your patience and understanding.

---

Hi Creators,

We aim to enable easy reuse and iteration of content across your experiences and teams through Packages. Today, we’re announcing several improvements that aid discovery of Package actions and Package states as you’re working in Studio. Improved icons in Explorer will clearly show package state, and package actions will be available from the 3D viewport context menu. We’ve also fixed a bug where packages shared with you didn’t show up in Toolbox. We are gradually rolling out the feature over the next two weeks, and all Studio users will see the changes by late July.

What is a Package?

For those of you not familiar with Packages, a package is an asset you can create by grouping together instances in a place. For example, it can be a collection of 3D instances that form a Car object, or a collection of scripts that form a code library.

With a package, you can continuously update the content of all of its copies from one place. You can also share it with your collaborators to co-edit or use. It’s a great way to distribute and reuse content across your experiences and places. For example, let’s say you want to build out a forest landscape. You can:

1. Create a placeholder block (e.g. red block below) that you group into a model or a folder. Convert the model or folder into a package, and place them around your world.

2. Pick one of the package instances and design your tree. Once the tree looks good, publish the changes as a new version of your package.

3. You can update all package instances to receive the latest version. Now, all the red blocks change immediately into your tree!

You can read more about packages here.

---

What’s New With Packages?

Improved visibility of package state

A package can be in different states, depending on whether it has a new version to update to. We’ve made it easier to track these states on the package instances inside the Explorer. You will now see a Link icon and tooltips on the right side of a package instance:

Package Icon	Package State	Meaning
	Package auto-updates are off	This state indicates that the instance in the Explorer is a package, and that it doesn’t have auto-update functionality turned on.
	Package auto-updates are on	When a package has auto-update on, any new versions of a package will be automatically applied to the package instance. Updates happen only when the place containing the packages has been opened.
	Package update available	This state means that a new version of the package is available. You can choose to update the package instance to the latest version.
	Package has unpublished changes	If you edit the content of a package instance, it will enter into a “modified” state. This means that there are unpublished changes that only this package instance has. If there is a new package update, you can choose to keep your customized modifications or override with the new update’s contents.
	Package auto-update is disabled	This state means that the package instance has auto-update on, but you’ve made unpublished changes unique to this instance. If there is a new package update, auto-update will be blocked. It will enter into the state below.
	Package update is available but there are unpublished changes	This state means that your package instance has been modified but also has a new update. You can choose to update to the latest version or keep the existing modifications. Packages with unpublished changes will never automatically update. Auto-update is blocked so that your customized edits don’t get overridden without your confirmation.

Example Scenario

Let’s walk through the above example scenario again to see how package state will be reflected in the Explorer:

1. You have six “Tree” packages in your place. They are just red block placeholders for now.
   

2. You pick one package instance and design it into a real tree (highlighted in blue in the image below). The package instance you’re editing enters into a “Package has unpublished changes” state.

3. Once the tree looks good, you publish the changes as a new version of your package. You can see that the rest of your package instances now have a “Package update available” state.

4. You choose to update all package instances to the newest version. Once a package is on the latest version, it’ll return to its default state.

Package actions available in the 3D viewport context menu

Previously, you could only see package actions – such as create, publish, or update packages – by right-clicking on the package instance inside Explorer. We have heard your feedback that this is difficult to discover. You can now right-click directly on an object you’re editing in the 3D viewport and find package actions available in the context menu there.

All packages you have access to appear in Toolbox

We’ve fixed a bug that was impacting visibility of some packages in Toolbox. Now, inside Toolbox > Inventory, under “My Packages,” you can see:

• Packages that you own

• Packages owned by a friend that you have Edit or Use permissions to
  
  

• Packages owned by a Group can be found under Toolbox > Creations, under “Group Packages”
  
  

  

---

What’s Next

We have more package workflow improvements coming later this year:

• Ability to enter version notes at time of publish, so that you or your collaborators can keep track of the changes made in each version
• Enable easy distribution of OSS code libraries to the Roblox asset system and to Creator Store via Package publish API

---

Please comment below for any feedback or questions! Many thanks to the wonderful team that worked on this feature: @strange_times, @eugenekim159, @ameowth07, @CurbM0nkey, @EndlessSashimi, @MrMark2u, and @yipiokay

[kingerman88]

Will we ever get the ability to publish a package and have the package update in all places without needing to publish each individual place? Similar to the LinkedSource script feature that got sunsetted.

[atom1779 (Dash)]

Well… this will make using large amounts of the exact same assets unnecessarily easy

[xChris_vC (Chris)]

Support for this if it doesn’t mean publishing the entire place, it should solely update the package to the latest.

Obviously don’t want an unfinished script to be accidentally pushed because someone published a package update.

[Scopetag (Scope)]

I get the convenience of this being in place, but I have my doubts with security concerns arising from this.

[desserts_yumyum]

publishing a package will update the package instances at edit time in Studio and it won’t publish the place

[au_tk]

Packages have been in place for a while, from what I understand this just introduces icons corresponding to each state. (I swear there were three icons of different colored dots that already did this, but I use a custom icon pack so I’m not sure. Even if there was these are more specific.)

[RedBeardedJoe]

It has a Toggle for Auto Update but i dont know if it will without opening up the Place or not but for me i dont want it Update everything all the Time but for those i will just use the Model and not turn them into Packages i wish Textures we use per World can be used in other worlds so we dont have to add them the same way each time

[PixelatedCafes_lol (BeanDevelops)]

Very useful feature! Will try to use in the future.

[metatablecatmaid (metatablecat)]

I think what they’re asking for here is the ability to do an update on packages, and if AutoUpdate is true, not having to publish each place to have those changes replicated.

This might already be the current behaviour, but when I was using packages back in 2020, it definitely wasn’t.

[devSparkle]

One of the big issues we still face is, because of how locked-down PackageLink instances are, it’s impossible to sync them externally through tools like Rojo.

Opening up the instance, giving us an API, and allowing us to set PackageId would be a great way to sync assets and ensure our relatively large development team (up to 70 in a single project) can get to work efficiently, and cooperatively.

[desserts_yumyum]

hi @kingerman88 @metatablecatmaid we’ve definitely heard the pain of having to go publish each individual place to make package changes available in production. We’re brainstorming how we can improve this workflow without increasing the risk of unintended or untested changes making their way into live games. We’re still early in our thinking here, so feel free to DM me if you have any thoughts or feedback.

[desserts_yumyum]

Auto-updates kick off when the place containing these packages are open (or opened) in Studio. It’s a useful feature for when there are many instances of the same object that you want to iterate quickly on altogether

[metatablecatmaid (metatablecat)]

oh how i yearn for a CreatePackageLink method (because package links themselves should be read only imo)

[desserts_yumyum]

hey @devSparkle I’d love to learn more about your external workflow here you’d like to have for packages. We’re working on an API for creation of packages, and we want to do more here - can you DM me so we can continue chatting more about your API needs?

[bvetterdays (roman)]

Love this feature as a whole. Very helpful if you have scripts (usually modules) you want to use across multiple games without having to go through and update it in each one when you want to make a change.

Just hope this hasn’t caused the issue below and doesn’t have to be rolled back as a result, as the flag seems related :

Explorer being over truncated

Yup, the flag is ExplorerPackageIconColumn2

[ChiefWildin]

This is cool, but I feel like what we really need is the ability to merge package updates and pending edits. If I add a script to a package, and then one of my coworkers publishes a change with a new part to it, I should be able to merge that without having to copy my script out, pull their change, put my script back in and publish. It should just pull the new part in. If there are conflicts on properties or whatnot, there should be a conflict resolution window (similar to the current diff window) that asks me what I want to keep. That is the final missing piece imo for packages.

[Tanks_altNum1]

Idk about the rest of the community but i feel the awkward truncating is really annoying so i made a poll

how do you feel about the truncating?

Community Feedback

• I like it
• I dislike it

[glaqss (ITSupportGlaqss)]

Regarding changes to the explorer as I was told to redirect my complaints here

Absolutely hate this change as I like to have the viewport be as big as possible.

It should be at least turned off as a default behavior (have a setting for it) or be removed entirely.
I myself was very confused as to why my explorer was behaving in the way pictured, and it made studio unpleasant to work with, I thought this was a bug.

HOW TO OVERRIDE

This behavior is triggered by the FFlag ExplorerPackageIconColumn2. To override this I downloaded Roblox Studio Mod Manager, opened it and clicked the Edit Fast Flags button, waited for it to download the files required for what it does, and then entered the FFlag in the search field, selected the FFlag and clicked Override.
After that, I launched it from the mod manager and that worked.

Comments on the updates to packages

The updated icons look great! One complaint i have though is that they may easily be misunderstood, so I suggest adding some kind of alt-text to the icons when they are hovered over to make sure that they aren’t misunderstood.
The updates to the rest of the stuff looks fine.