Recent change to .rbxm and .rbxmx breaks developing pipeline

Help and Feedback Platform Usage Support
, , ,
#1

In today’s studio update there was a change to .rbxm and .rbxmx file formats (changed MeshId to MeshContent and TextureID to TextureContent). It looks there is no backward compatibility, so we have an issue with our development pipeline.

Our development pipeline:

  1. Get required assets from the development place using lune (assets such as entire workspace as service and all descendants)
  2. Save assets as .rbxm or .rbxmx
  3. Build game with our source code and saved assets using rojo
  4. Publish the built game through Open Cloud API

Currently, with such pipeline MeshId and TextureId Properties of objects not saved at all, completely breaking entire game.

Looking into what’s happened, we discovered that such properties don’t save in .rbxmx file. At least they won’t until rbx-dom update.

Moreover, haven’t found other way to save workspace as .rbxm or .rbxmx:

  • Roblox Studio doesn’t allow to save services as files
  • Open Cloud API currently doesn’t support instance downloading

So for now we cannot continue our development. And even when all open-source tools update (rojo, lune, rbx-dom), we will be forced to update all of them locally.

I suggest to add a backward compatibility for these properties so it won’t cause development problems.

7 Likes
#2

Having the exact same issue here, if anyone knows a workaround please let us know as we also cannot continue our development.

#3

Sounds frustrating for sure, but likely not a bug. Maybe @tnavarts can jump in here. He usually gives insight on things in #updates:release-notes.

I hope your issue gets fixed!

#4

We rolled out a change migrating the storage and serialization of these properties to the corresponding *Content properties.

Currently planning to temporarily roll back the change that switches the engine to writing *Content instead of *Id.

We’ll make an announcement and set a date before we roll it out again. We’ll at least give community tools a chance to update to support Content properties.

We have to make this change, but should have announced it prior. Sorry about that.

5 Likes
#5

Change is currently rolling back. Things should go back to normal for you in about an hour from now.

You will need to restart Client, Studio, or TeamCreate servers after the rollout has finished for the change to be picked up.

The engine will continue to support reading either property, but will switch back to writing the legacy ContentId properties until we roll this change out again.

We’ll also attempt to contact the owners of these open source libraries and work with them to support Content property serialization.

4 Likes
#6

Hi, that’s me.

If you need to contact Rojo’s devs (we maintain rbx-dom which is used by Lune, Rojo, and Argon) directly, you should be able to through a few people. Probably the most convenient is @DevelopmentDeadline or @itsFrank17 but others would work.

Warning for changes to serialization like this would be great. We’d welcome any assistance with implementing (de)serialization for them but even just advanced notice helps.

#7

Thanks!

Writing up an announcement post now. I’ll DM you and the people you mentioned and file issues on github for the projects I know about.

I’ll try to include a quick description of the xml/binary formats for the Content type in the announcement if nobody stops me. We still consider it implementation defined and subject to change at any time, but we don’t want to make anybody’s life harder than it needs to be if we can help it.

1 Like
#8

Believe me, we’re not strangers to things changing unexpectedly. Any attempt at getting it publicly documented are good and welcome, but if not we’ll work it out (or get told by someone else) and add it to our spec file for other people like we always have.

1 Like