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

Bug Reports Studio Bugs
,
#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
#24

Sure. Basically I just open a place where I have packages with humanoids in them, and it thinks they’ve changed. Reverting the package to a “previous” state also doesn’t solve it.

A package that experiences it if it helps:
https://www.roblox.com/library/3189985193/SentryUnit

#25

I see this same issue frequently, and it it makes packages very untrustworthy.
My solution is to practice good modeling hygiene (however these I can’t prove any of these work).

  1. When I position packages, don’t place them where they intersect with other Objects.
  2. I resize items in packages to whole number increments, rather than by dragging to arbitrary decimal numbers.

Also, and more importantly. I use disposable “dummy” copies of my packages in my game layout, and then my code swaps these out for the real package. This way, I can disconnect the dummy from the package, and it doesn’t matter if it gets corrupted.

3 Likes
#26

Very interesting ideas for how to work around this bug, I appreciate the insight.

  1. I would guess intersecting packages with objects would likely cause the system to think it’s changed. Regardless, this practice is something I always do, but for some reason I still experience it.
  2. Sadly sticking to whole numbers isn’t always feasible - especially for R15 NPCs. I’ve done this for non-NPC packages and it works fairly well though. Back before some of the fixes, moving/rotating a package on a decimal scale could end disastrously.

For your dummy packages, are you referring to InsertService? I’m curious as to how you make this work with visualizing things.

#27

I place a positioner (CAT in the image below) in Studio. The positioner is a Model, that contains a block called Positioner, and a model called Dummy. At runtime, I delete Dummy, and use Positioner as the location to place a clone of my model that I am inserting. If this doesn’t make sense, let me know.

function module.addModel(props)
local defaultOffsetConfig = {
    useParentNearEdge = Vector3.new(0, 0, 0),
    useChildNearEdge = Vector3.new(0, 0, 0),
    offsetAdder = Vector3.new(0, 0, 0)
}

local parentFolder = props.parentFolder or workspace
local positionerModel = props.positionerModel
local templateName = props.templateName
local offsetConfig = props.offsetConfig or defaultOffsetConfig
if not positionerModel then
    return
end
local dummy = Utils.getFirstDescendantByName(positionerModel, 'Dummy')
if dummy then
    dummy:Destroy()
end

local positioner = positionerModel.Positioner

local cloneProps = {
    parentTo = parentFolder,
    positionToPart = positioner,
    templateName = templateName,
    fromTemplate = true,
    offsetConfig = offsetConfig
}

local newItem = Utils.cloneModel(cloneProps)
return newItem
end

local newReplicator =
    AddModelFromPositioner.addModel(
    {
        parentFolder = parentFolder,
        templateName = 'LetterKeyReplicatorTemplate',
        positionerModel = positionerModel,
        offsetConfig = {
            useParentNearEdge = Vector3.new(0, -1, 0),
            useChildNearEdge = Vector3.new(0, -1, 0),
            offsetAdder = Vector3.new(0, 0, 0)
        }
    }
)

image

2 Likes
#28

Hello there, I have been experiencing this with the packages I have, it’s been happening with 2 models:
1st: It’s full of accessories, when I started changing it once, it always needs me to update it.
2nd: I think I added a viewportframe and a model inside that has bones, which is why it’s always thinking I haven’t published yet. I do not know if this still keeps happening as it only happens to me once for this 2nd type of bug.

2 Likes
#29

I still experience it with the package full of humanoids I mentioned in the OP, so it’s totally possible. I figure it’s probably some sort of floating point error with NPC pieces and accessories.

#30

Thank you for bringing up this issue. We are looking into it and will have a better solution to fix the modification issue in packages with humanoids.

3 Likes