For Adopt Me, we have an automated workflow that involves saving a place file, and then a tool parses it and reserializes all of our map assets as rbxm files. We then use these for building with Rojo, which lets us do things like automatically deploy changes. We attempt to do some basic file diffing so that not every Roblox change causes all of our model files to reserialize, as it would make source control really annoying. This normally works fine, or I can make it work fine with minimal issue.
Recently, a change happened that caused some values of Part.CustomPhysicalProperties to reset to Default, which has triggered over 200 different rbxms to serialize in our files. I was able to observe this due to specialized tools I have that display rbxm files as YAML. Diffing a before and after reveals that some values of Part.CustomPhysicalProperties have been changed from a value back to just be Default:
This image shows values of Part.CustomPhysicalProperties as they appear in the rbxm file and rendered in a human-readable format.
This is unexpected behavior because it has caused our rbxm diffing to fail, and is causing other engineers on my team to have to manually parse what files have actually changed from a list of 200+.
This happens without any betas enabled or any FFlag overrides. I believe it started today, though there is a chance it started happening on Friday and nobody on my team noticed. It definitely did not happen before Thursday though.
Expected behavior
My expectation is that Roblox does not randomly alter the contents of properties between save and load.
We have a change to custom properties in advance of an upcoming release - adding Acoustic Absorption as a property. We are investigating why enabling that support impacted other physical properties. For the time being we’re rolling back support in the file format for this new property, while leaving the property available in the next hour. Please let us know if this fixes your workflows.
Thanks and sorry about Defaulting your properties!
What’s the approximate rollout time for the change being reverted? If it’s too long I might need to wait until tomorrow to let you know whether it’s been resolved.
Was any conclusion reached here? We are now experiencing with Jailbreak the same problem as described in initial post. With same Rojo/rbxm setup as described in initial post.
EDIT: nevermind, updating to latest Rojo & Lune resolved! Thank you Dekkonot for your contributions there
I had a long back and forth with Roblox over this and as of Rojo 7.6 this should be fixed. It was also fixed in Lune 0.10.4 if you use Lune.
It’s really our fault as Rojo devs because we weren’t as strict with validating input as we should have been and rather than erroring we read data incorrectly. We now read it correctly and also error when the data is wrong.
I can give a TL;DR on the change Roblox made to PhysicalProperties if you’d like but I suspect it’s not very interesting to you or others who read this thread.
@badcc thanks for the report and sorry for the trouble. As @Dekkonot says, this should not be an issue with the latest version of Rojo. If you haven’t already, could you please try upgrading to the latest?
