Hi! It’d be extremely useful for those of us who use version control software like Git to track and collaborate on changes to Roblox projects using .rbxmx files if the referent attributes in every single instance did not change every single time the same instances are exported to .rbxmx files.
The issue lies in that it’s hard to spot the actual changes to assets since there’s thousands of referent attribute changes in each patch involving .rbxmx files.
I figure that these identifiers are generated at export time and not kept in memory which might make them difficult to preserve, in which case I wonder if there’s a good way to work around this issue? We get a lot of this for example when trying to merge .rbxmx changes to Building Tools by F3X, which is an open-source project:
A good solution would be to generate references deterministically. A number based on the order instances appear in the tree would be great, since it would be compatible with the binary rbxm format.
Unfortunately, this makes instance additions/removals causing ripple effects on the resulting file as all instances after the change are renumbered.
What’s strange is that we have added the GUID-like referents a few years ago specifically to solve the ripple effects, but it seems like in some cases it might be causing more harm than good. @GigsD4X, can you provide specific repro steps on what sequence of actions causes the resulting rbxmx file to have different referents?
Hadn’t thought of that. Upon further investigation, XML references do appear to be preserved across saves and loads. I think the problem is that these references are destroyed when the data is saved in binary format.
If his workflow involves, say, opening building-tools.rbxl in studio and exporting the plugin objects to building-tools.rbxmx, then the references will be different each time he loads the place file. This could be solved by saving the place file as building-tools.rbxlx instead.
I tend to use a dedicated place published on Roblox as a workspace, and opened through the Edit button, to work on and test changes. Afterwards, I usually export the objects as .rbxmx files, and publish the place and close Studio.
This seems to be the case that Anaminus described above, so it’s probably possible to work around it by loading from the same .rbxmx file at the beginning of each Studio session. If anything, there’s a case where if there’s a different copy of the same asset in the place (e.g. for comparing behavior between different versions while testing) it seems to change the ScriptGuid properties of script instances in the most recently inserted copy, but it’s also possible to work around this by inserting any testing copies after the working copy.
To review changes in cases where the referents are all changed, I currently filter referent lines from diff output, then allow them to be changed when merging, since it’s tricky to fix them reliably. Changes coming from outside sources might not follow such a specific workflow to prevent this issue, so those are the problematic cases that may persist.
We get a lot of this for example when trying to merge .rbxmx changes to Building Tools by F3X, which is an open-source project:
