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

Bug Reports Studio Bugs
,
#4

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!

6 Likes
#5

Thank you for the update!

Some important info:

5 Likes
#6

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?

3 Likes
#7

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

2 Likes
#8

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
#9

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
Make packages more like Unity's prefabs
#10

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
#11

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
#12

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
#13

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
#14

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

3 Likes
#15

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
#16

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
#17

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
#18

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
#19

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
#20

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

2 Likes
#21

Can you please share the minimums steps to reproduce the bug?

4 Likes
#22
  1. Have a package with several R15 characters in it, including humanoids
  2. Publish your place
  3. Open your place
  4. The package thinks something has changed and won’t let you revert the package or publish the place until you publish the package

That said, it can be as little as one R15 humanoid.

3 Likes
#23

I cannot reproduce this on my end. Is this 100% reproducible on your end? Can you provide a screen recording for it? Thanks!

4 Likes