This is certainly a step in the right direction, and I applaud you and the entire team at Roblox for taking it.
Several developers in this thread have mentioned that what they would like to see is an opening of Roblox’s .rbxm binary format, and while I’m all for that I’d like to add the following:
A lot of the tools mentioned here serve the singular purpose of integrating with the common developer ecosystem. All programmers of all types are using open-source or open-protocol version control systems like git, and Roblox may be one of the few major platforms where this still can’t be done reliably. Tools like Wally are used by developers because Roblox still forces us to require libraries by absolute path, instead of having proper import and update systems, and the ability to require by library name.
We can all make this process easier by integrating Roblox with these tools, instead of trying to re-invent the wheel with built-in custom source control, or packages; which have been a great addition to builders, but feel like a step-back to programmers with prior experience with established tools.
Making Roblox a collaborative ecosystem where developers can build open source code that can easily be integrated can be the greatest leap this platform has ever had in my 15 years of experience with it.
+1 for this. Roblox is, in effect, the largest studio on the platform because it uses its own platform internally; so it’s had to solve unique, platform-specific problems to a professional standard. Would be very helpful to developers and also demonstrate Roblox’s commitment to empowering developers.
I did not understand all this because I am an Arab and I do not know how to speak English, but I know a little bit, but I understood this speech like my name
I understood that the files are easy and greatly developed
Something I’ll add to the conversation as someone who has been observing the relationship between Roblox and its power user community for a long time.
There’s always been a major disconnect between product leadership and what’s in the best interest of both Roblox and its developer community. Unofficial tools like rojo came into existence because product was insistent on all infrastructure and systems used by developers being built in-house with all of the backwards compatibility nuances and scuff hidden underneath flashy UX products. The resulting dynamic was the community having to navigate through this scuff ourselves, reverse engineering the specs by hand, and writing thousands of lines of code to interop with Roblox’s existing formats.
Now granted, the situation is a bit more nuanced and complicated. Roblox’s formats are not super friendly or stable in their current form. It has been an upkeep nightmare to create software that inter-ops with these formats. Given the limited engineering resources to clean up these problems, I can’t say I blame Roblox for focusing more on product and user experience rather than the actual toolset needs of external developers.
Far as I see it though, the time for excuses has passed. This problem is not going away, and I’d rather see Roblox develop flexible public specs for their file formats that take inspiration from what the community has built so far. You shouldn’t need a computer science degree to create software that interops with the engine. Not everything has to be in-house developed, all we ask for is a stable flexible spec to build upon.
Undertaking everything I’ve done over the years personally has lead to burnout, both on my part and from talented engineers like lpg, who wanted Roblox to take this direction all along while he was working at Roblox. Instead… we got packages, and those have been sitting in a weird limbo for the past 2-3 years without any stable conflict resolving for modified package forks. Roblox tried to add their own merge conflict resolver for drafts in studio, and it’s just like… why? Does it really need to be an in-studio thing when it could just use industry standards like git?
If Roblox really wants to be the metaverse platform, it needs to open its guts up for people to build upon and stop running from these existing file spec problems. I trust the new blood at Roblox will know what to do, I just hope leadership is willing to listen this time.
Adding onto this, I think this is a great opportunity for Roblox’s Product team to get aligned with the DevRel team about best practices and strategy around how to communicate about product updates and features, and furthermore how to talk about actually following through on them. It seems like, in the past, communication has always just been laying out plans and not detailing their execution, which leads to a lack of follow-through and product features therefore becoming dead-on-arrival or facing backlash because it’s not clear how they fit into the bigger picture.
Additional communication around why Rojo is a taboo topic and the lack of official support for it would also be pretty great.
If you open a Roblox Model (RBXM) file in Studio (drag/drop into Workspace), and export the root node of your model instead as a Roblox Model as Xml (RBXMX) then you can open it and edit it in any text editor. The same is true of a place AKA “Level” file (RBXL / RBXLX).
The main difference between the XML form which is human readable and editable vs the compressed binary form is the size of the files. We store them compressed by default to save space and bandwidth because Roblox stores millions of these files in the cloud, but the engine code to load the files works with either form, and Studio will happily do the conversion for you.
I think they’re aware, what he’s looking for is an official public documentation spec for both formats, or a newer format that Roblox is comfortable making public.
To add to the above, RBXMX is functionally useless for games of a respectable size because the file size becomes absurd and load times also become absurd.
Technically, if the compression wasn’t so prevalent, rbxm can be viewed with a hex editor (lol)
Obviously, you’d need to what you’re looking for and what to do to get said data out of it but hey thats what you get with binary formats
I thhk they’re asking for a simple way of actually understanding the format itself with a spec document (for working with), as they stated if the spec was known, we would’ve discovered the 0x1D RCE years ago
Myself just wants a native way to either decompress chunks (pure lua impls are slow), or a way to insert an RBXM in-engine from a binary stream
I think having an option where you can choose to create the game with team create would not be a bad idea though; it’s kind of a hassle having to enable team create from game settings every time.
It does not mean, however, that it should be enabled by default or forced. Many users have stated a plethora of reasons as to why team create is not reliable/is not sustainable for a bunch of workflows and it should be disabled by default. Especially collaborative script editing.
You should be able to choose these settings WHILE creating the game; a watered down interface of game settings should be shown during the place creation process. I heavily appreciate that Roblox listened to the community and rolled back this update.
With all due respect, did you read this post before you responded to it? Your response shows a critical misunderstanding of what jitlua is asking for and it’s disrespectful to them to respond like this.
Jit, myself, and everyone else who’s mentioned a file spec know that there’s two different file formats and what the differences between them are. We aren’t stupid nor are we children. Some of us have written codecs for both file formats from scratch despite Roblox’s lack of support for that. All we are asking is that Roblox give us the resources we need to do that better.
If you don’t know how to respond to this or don’t understand what we’re asking for, please don’t and let someone who does know respond. It’s insulting to have a request so wildly misinterpreted like this.
I think it would be really cool if there was a live Q&A every month or so. This would be an easy way to find out what us developers want while also being able to share the company’s viewpoint on the topic, rather than 50 people making identical posts ranting about how Roblox won’t give us what we want.
I believe this was a thing at one point through something called “Town Halls”, however I’ve only heard rumours of it last spring with a few top developers and I’m not sure if it even happens anymore.
Thank god.
The employee who conceived that it would be a worthwhile idea to even make Team Create enabled as the default should be thrown out of the window of Roblox HQ. We must address the elephant in the room regarding the thought process behind the implementation of this feature; a large majority, if not the majority of developers’ workflows include making new baseplates for a variety of reasons, often for specific assets. It blows my mind that this wasn’t even taken into consideration before this feature left the drawing board. This shows the sheer lack of understanding of developers’ workflows.
With that being said, thank you for making an effort to bridge the communication gap.
I don’t think you need to be so aggressive about it. Honest mistakes happen and writing aggressive paragraphs about how someone made one on a news post about an attempt to repair communication with us hits completely and utterly wrong. This is a two-way street.
That is so true!
Every time there’s a new feature, I feel as though the thread always, in a sense, is full of cliffhangers. @tnavarts is the when it comes to bridging the Developer-Roblox communication gap.
when it comes to bridging the Developer-Roblox communication gap.