A package keeps thinking I changed it, when I didn't

Every time I open a place of mine that features this package:
image
https://www.roblox.com/library/2644717037/NPCBusts

It somehow thinks I changed it. I’m not 100% sure how to replicate this. It seems to wonk out when I enter play mode or use undo (even though I haven’t even modified the package).

Important Notes:

  • Undoing the changes to the package does nothing and the game still thinks it is updated

  • It starts sometimes when I use play mode, or use undo, or move it to a different place in the hierarchy

  • The only way to solve this issue is to update the package for no reason or to delete and readd said package

  • The contents of this package are various NPC models with humanoids used for a ViewportFrame UI

  • The PackageLink is set to AutoUpdate

  • This is the only package I use that is affected by this bug

  • The player does not spawn, I use LoadCharacter (potentially relevant?)

Update

14 Likes

Hi @cloakedyoshi, thanks for reporting! We will look into it.

[InternalTicket#21619]

10 Likes

Thanks! Any updates? This bug is still occurring and is slowing down my development.

4 Likes

Hi @cloakedyoshi, we are still looking into the issue.
In the meantime, I suggest to break large package into smaller ones. E.g. One NPC per package and then publish all the NPCs as a single package. Another suggestion would be refrain to use JointInstance (e.g. weld) if there is an alternative choice. Hopefully these methods will mitigate some of the pain.
Thanks for your patience!

5 Likes

Thank you for the update!

Some important info:

4 Likes

I’ve found that using Humanoid objects in a package can cause some weird behavior. JointInstances have actually always been completely fine for me. Are the Humanoid objects necessary for you to use them in the ViewportFrames? Have you tried removing them?

2 Likes

I have also had the same issue when I was trying to save a package with a humanoid so this is probably the problem.

1 Like

I took your advice of breaking a large package up into several smaller ones, but it just makes it worse.

It thinks various aspects have changed when they haven’t. Even worse, these packages lack humanoids/welds.

New Packages:
https://www.roblox.com/library/4757219272/SquareWindow
https://www.roblox.com/library/4757239502/WallWindow

Is it possible that it’s a floating point error with rotation/position?
On further testing, this seems very likely.

3 Likes

I can now 100% confirm that it is a floating point error with position and rotation.

Repro:

  • Make and use a package with a scale including or exceeding two decimal points for either movement, scale, or rotation
  • Rotate the package, move it, and clone it in the workspace several times
  • Studio thinks you’ve changed it, when in reality you have not

This makes packages extremely inconvenient and borderline unusable.
Please let me know if you would like additional information.

This also means that @billlipeng’s earlier suggestion to make small packages within bigger packages does not work, as it creates of chain of packages that apparently were changed (when in reality it is a floating point error).

9 Likes

Thanks for providing so much details!

Breaking a large package into smaller ones will mitigate the issue. E.g. separate scripts out of models with 3d parts, and script package will work fine.

This issue is in our pipeline. I’ll keep you posted.

8 Likes

Sadly your suggested fix still just makes it worse. :frowning:

  1. Studio thinks the smaller packages have changed, I disregard the change, it still thinks something is different.
  2. Instead, I publish the change. Studio is happy, now I have to update the package this package is inside of.
  3. I update the larger package, all is well - then suddenly if I move it or rotate it, it may not be. It thinks the little package has changed again.
  4. Repeat steps 1-3 over and over until eventually the Studio beast is sated or I give up.
2 Likes

This is happening to me too, it essentially makes the package system unusable for my needs. Please fix! This is so important for my games release. :slight_smile:
https://i.gyazo.com/89beffb572b1a202142ff11c1afabf3f.mp4

5 Likes

Adding you to a DM with two people on the packages team.

I just realized this was my other packages post. This is likely still the floating point error, my bad.

3 Likes

having this issue with 2 of my packages
Edit: Changing the parent also changes the package

3 Likes

I don’t know if it helps, but it’s likely a floating point error. If you ensure everything is greater than one decimal point it makes it a lot less painful.

That said, would love to get an update on this. It’s been interrupting my workflow for over nine months.

2 Likes

I experienced similiar issue recently.

Try to check if you have “Animator” or “HumanoidDescription” objects within your packages (removing them fixed the issue for me).

You can also check if your package contains something like this:

2 Likes

The only fix for this I can think of is automatically adding some sort of “Object” into the PackageLink object which would be working as relative point for whole package. So when you move the whole package around the map, relative position of each of it’s descendants to the packagelink object stays the same until you modify one particular part.

I think it would also be cool to allow some easy “customization” in packages - eg allow “Configuration” object in PackageLink and if any of it’s descendants was changed, it wouldn’t affect the state of package.
To make it easy to implement updates, there could be a “DefaultConfiguration” folder (read-only unless you’re package maintainer, rewritten when updating package) and the “Configuration” one anyone can configure.

CC: @billlipeng

3 Likes

Hi, we just released a fix yesterday. Can you please check if this issue is still reproducible? If it is, can you please share the minimums steps to reproduce the bug? Thanks!

8 Likes

YES! THANK YOU SO MUCH!
Tested it in all use cases what it’s broken in the past, and works perfectly now.

What was the cause? :o

4 Likes

@billlipeng
The fix appears to not work for packages containing humanoids. If anything the fix made it worse for them. :scream:

2 Likes