Package In-Place Update

[cruiser_forever]

Hey Developers,

We’re happy to announce another upgrade to our Packages system. Behind the scenes, a package instance update will now use a brand new algorithm.

External references to objects in the package will remain valid after the update as long as the instance that has been referenced continues to exist. This works even if you move the referenced instance within the package tree hierarchy! Below is an example of a rope constraint that keeps working after a package in-place update.

Please note that the in-place update feature requires some new metadata to take effect. It will not make use of the new algorithm if your package was not published/republished after November 3rd, 2022, but will begin to work when newer versions of your packages are published.

Shoutout to our team for making this happen @strange_times, @cruiser_forever, @brienneofthetarth.

Thank you.

[local_ip (jmk)]

It would be great if a package instance’s attributes could also be kept when the package updates.

[LuaBearyGood]

Would be nice to be able to configure the behaviour for how a package interacts with attributes,

e.g. Our analytics system we want as a package, but we want a different data version ID for each game.

Rn we are having to have a module in the package which stores a dictionary off all the place ids using the package and their respective version but it would be much nicer if we could just have it as an attribute on the package.

[iGottic]

I disagree. Attributes intentionally are not kept to introduce a level of customizability for each one; because people already do this, making that change would be game-breaking.

@LuaBearyGood

Would be nice to be able to configure the behaviour for how a package interacts with attributes,

This is a better approach

[metatablecatmaid (metatablecat)]

My issue with the package system thats its difficult to script around, and distribution of packages is difficult. This issue is mainly around open source libraries, while I would generally publish to GitHub, there’s a few reasons why a user may want to stay on the Roblox platform.

1. Rojo can be finnicky to set up, and it isn’t a perfect solution
2. There isn’t a correct way of storing non-script instances, model.json, .rbxmx?
3. Updating is difficult, since updates wont be tracked in game.

4. InternalSyncService requires patching the executable, and it can only handle scripts/folders

If Roblox allowed a package distribution system, this could be changed to just fetching a library as a package from the creator marketplace, that can automatically be updated, or kept on a versioned version.

If I had any quick fixes for packages it would be the following:

• Allow plugins to import packages (this should be easy, just unlock InsertService:LoadPackageAsset/LoadPackageAssetAsync
• Create a new sort on the creator marketplace that allows us to search packages, AND, make it possible to make packages public

oh and please make attributes save in packages :plead:

[DEVLocalPlayer (LocalPlayer)]

I love packages, I hope you keep updating them 'cause sometimes I struggle while using them.

[SubtotalAnt8185]

This is pretty cool, but what if the reference was part of another package? Let’s say you have two packages with references to each other. If you update one package, will the reference persist?

[tnavarts]

@SubtotalAnt8185

This is pretty cool, but what if the reference was part of another package? Let’s say you have two packages with references to each other. If you update one package, will the reference persist?

Two packages can’t reference eachother without at least one of the two being modified. Leaving a modified state by discarding the changes will naturally discard the reference.

[local_ip (jmk)]

@iGottic

Attributes intentionally are not kept to introduce a level of customizability for each one;

Yes, that’s the reason I said this. Each package instance should have its own attribute values. The attribute names and their types should always match with the root package instance, but the values should vary per package instance. Updating the root package should only update the attribute names and types, not their value. This means each package can have a level of customizability with a standard schema

[Blafert]

Good stuff! Always glad to see the packages being better to use.

[nidbahn]

Does this also fix the bug where packages caused Studio to think there was a change made to the place but there wasn’t?

[SelDraken]

I would like to know this as well, it seems you cant get too close to the screen, because if you even breathe on studio, it thinks a change has been made.

[GeneralRelish]

These issues should have been resolved with the release of Improved Workflows. If you are still running into this issue, please file a bug.

[GeneralRelish]

oh and please make attributes save in packages :plead:

Attributes should already be saved in the Package and changing them constitutes a Package change. Are you seeing something different?

[metatablecatmaid (metatablecat)]

It appears that they are saving now, there was a time when they didn’t, though I haven’t used packages in a while so that may have changed.

[GeneralRelish]

Yes, we had a few bugs re: this but all should be resolved now.

[alphawolvess]

I agree with keeping our attribute data as well. Whether you have to toggle something to allow the feature doesn’t matter.

[alphawolvess]

I’ve had an issue where the attributes did not apply with a package until I fiddled with it. The issue may have been that I made a Folder a package, containing several instances with attributes

[DarthChadius]

Can this bug be closed now then?

Changing/Adding Attributes Does Not Count as Change to Package

Hello, this is still happening and can be quite annoying. I think this should be addressed rather quickly as developers may end up having lots of work and core functionality not saved as they do not know that the package hasn’t detected new changes.