Certain properties reset to a previous value when in Team Create

[EmeraldSlash (Rio)]

(Last edit 2020/04/01)
I have found that when in a Team Create session, certain properties will sometimes reset themselves to a previous value for unknown reasons. This issue used to happen only when I was with in the server with other developers, however now it appears to happen at anytime.

For example, I copy a button (with an icon ImageLabel with an image of a sword on it) then I change the image property of its icon ImageLabel so that it now shows an apple. A few minutes later, I look back and see that the icon has been reset back to the original image, the sword.

Others have reported this occurring with transparency too, however I have not seen this myself. Properties like text in my experience have not been affected.

When the reset happens, it resets all affected properties on all of the objects. Undoing back to before the properties were set by the developer and then redoing (which should theoretically re-do the changes made by developer) does not work, either, and just applies the value it was reset to. Publishing, autosaving, and closing and reopening the place do not seem to fix the issue.

This happens across multiple different computers and networks, although they are all running Windows 10. It has been consistently happening since I first reported this bug in Dec '19.

Here is some example output of when this issue occurs (from a command).

local lastChange = 0
local i = game.StarterGui.Menus.Overlay.ImageLabel
i:GetPropertyChangedSignal("Image"):Connect(function()
   print("Image changed to", i.Image, "after", tick() - lastChange, "seconds")
   lastChange = tick()
end)

Image property was set to another image (not listed) 136 seconds ago.

After those 136 seconds, it was changed to gradient, and then Floor Decal, both of which were images that were previously used in this ImageLabel. The new image property (not listed) was not restored. It seems a single sync is giving two conflicting results with itself as well as not being the same as what was most recently set.

[Hexcede]

So based on your description of the issue it seems that this could be one of these issues (and maybe not a bug):

1. Property changes aren’t replicating to the TC server (TC servers work very similar to a non filtering server) and your TC client is getting these properties rereplicated (this is probably what’s happening if it immediately appears for the copied item)
2. They are properly replicating but you are not saving/publishing your changes (File > Save to Roblox will save changes without publishing them to live games meaning you can continue working and eventually publish)
3. This is really a bug (which I’m sure a moderator will probably have some idea based on FFlag changes. Not to say that the way TC saving/replicating works is confusing)

Here’s some more info on how TC works which I’ve observed (which may help you or others understand how it works):

• When all studio members disconnect the TC server will eventually shut down (meaning it must be started again when connecting and any changes that weren’t saved can’t be recovered remotely)
• When you make property changes they should be replicated to other TC members similar to how non filtering servers would work. If the server makes a change you should see that as well as when the server authorizes a change.
• If some kind of desync occurs it can be hard to diagnose since there is physically no access to the TC server (although fun fact this may be possible with some hacky corescript modding using the dev console’s code endpoint but that would be considered an exploit since in TC you cannot locally load CoreScripts)

Hopefully this will help you diagnose the issue. Additionally can you provide some kind of repro if possible? (Preferably by attempting this in a new baseplate TC with only you)

If you can’t get a consistent repro an inconsistent one is better than nothing since others may be able to encounter this on their own through trial and error.

[EmeraldSlash (Rio)]

@Hexcede

• Property changes aren’t replicating to the TC server (TC servers work very similar to a non filtering server) and your TC client is getting these properties rereplicated (this is probably what’s happening if it immediately appears for the copied item)
• They are properly replicating but you are not saving/publishing your changes (File > Save to Roblox will save changes without publishing them to live games meaning you can continue working and eventually publish)

These are both still bugs. Re-replication = bug (this bug is unlikely unless the replication sync frequency is low since it does not happen straight after I change something). Changes to specific properties not being stored automatically like with every other property = bug.

I am attempting to reproduce it in an empty place now, but so far I can’t get it happening. Perhaps it requires somebody else to be in the team create server.

[Hexcede]

Actually re-replication would not technically be a bug in this case this would simply be due to desync which could be for any number of reasons (e.g. your client lagged). This is sort of intended behaviour and this is exactly why local instances can exist in live servers.

The second bullet there is just how TC works. If you don’t save your content before an auto save it just won’t be saved. I suppose it would make sense for the TC server to autosave before shutting down (which it may do) but I know for a fact that this does not always happen. I’ve lost a few minutes of work before due to that (thankfully remote autosaves are every 5 minutes I believe so this doesn’t effect too much).

Additionally if it requires a second person this could actually be interference between your client and their client. If their client becomes desynced and they trigger a resync somehow this will cause the issue you’re having.

[EmeraldSlash (Rio)]

@Hexcede

Additionally if it requires a second person this could actually be interference between your client and their client. If their client becomes desynced and they trigger a resync somehow this will cause the issue you’re having.

This makes sense. In the place where I am experiencing this the worst my partner is idle in the Team Create. The low frequency of resets could mean that every few minutes or something their client is syncing with the team create server, and for whatever reason they are not receiving any of my changes and are being given more authority than I am as to the state of the place. Still really weird though.

[Hexcede]

That is weird! I’ll do some testing when I have some time to just to see if I can catch the issue and possibly figure out exactly what’s going on. Additionally a staff member may know what’s going on here (especially since like I said before they are usually familiar with FFlag changes)

[DarkLizz (Kitty)]

I agree, based on the data you provided, it is likely a sync/desync issue across clients. Unlike an online shared system such as Google Docs, Team Create interaction works a lot like how Roblox games work. You have Servers and Clients. Changes are all modified in the Client, and propagated to the server, back to the clients. It is likely that there is some disconnect or some break in synchronization between both your changes. It doesn’t seem that roblox locks individual parts when other players are modifying, and saving across. While if you were, say editing a script, you will see (… Editing). This locks this version of the script so that others cannot override the current changes in place until the developer is done working on the script. To my belief, it requires an interaction between 2 or more players on the same server, is my guess, to emulate your situation.