Working together to build an Open Roblox Platform

[Dekkonot]

@moo1210

I simply do not understand this nothingburger announcement post.

Hi! I’m not a Roblox employee so I can reply freely to this in a way that Roblox staff can’t. I’m also in a position where I know a lot about the things you posted about and thus can provide some realistic responses. If I ignore a point, it’s because it doesn’t apply here since this is post is from a specific team and not Roblox leadership.

@moo1210

You would still be able to create your own built-in plugins without internal mode

This is a security choice. You may be smart enough to not just put a random plugin someone wrote into the BuiltInPlugins folder. Other people aren’t, and the APIs that a BuiltInPlugin has access to are easily abused.

This is, incidentally, the same reason I was given for no debugger access from plugins (yet): being able to set local values is a valuable part of the debugger but unrestricted access to a setlocal function effectively allows RCE.

@moo1210

You wouldn’t have introduced bytecode into RBXMs, enabling you to hide source code of CorePackages and Built-In plugins without continuing to ship source code, preventing custom modifications for most users.

While this decision is outside the control of this team (aka you’re yelling at nothing because they can’t change this), the reason that Roblox’s builtin plugins are precompile is exactly the same reason that you’d precompile anything: it takes time for code to compile.

When large parts of Studio’s functionality are written with Luau, you really cannot waste the time it’d take to compile and then load those plugins. This is a significant enough problem that there’s now Studio setting to just outright stop loading the builtin plugins because they take too long to load. It would be much worse without precompiling them.

In regards to the source code though I’d love it if it was open source. It wouldn’t be terribly usable since everything relies upon locked down APIs, but it’d still be nice to have.

@moo1210

You wouldn’t have started with releasing the new “luau-execution-session-tasks” API (you refer to it as “Luau code in the engine via Open Cloud”), we would be using a headless RCC directly. David also referred to this API as “RCC As A Service” at RDC, I think that phrase alone speaks for itself. Plus, roblox-cli already exists, internally.

roblox-cli kinda sucks and you don’t want it. “Ships at a distance” and all that, but the reality is that roblox-cli as far as I know doesn’t even have a codeowner internally.

Otherwise yes I am with you completely. I think the Luau execution API is disappointing and I would rather we have something else. But I also have talked extensively with the team behind it and I begrudgingly accept their reasonings, which DevelopmentDeadline listed above.

@moo1210

You would be making more things open source. Luau along with a couple of more random projects (see: items like nomad-driver-iis) on GitHub is the only major piece of code you’ve open-sourced that isn’t already dependent on another open-source project. Some people could argue Luau is dependent on Lua 5.1, but I’m looking at an angle where there’s code Roblox actually wrote. (In other words, converting existing JavaScript projects to Luau doesn’t count in my view, see the existing copyright headers/license for the actual creator)

I would love for this to happen too, and so would some people at Roblox. Like the announcement says:

@DevelopmentDeadline

Researching: Open-sourcing more Luau code written at Roblox with the goal to one day also accept contributions in select areas

“Researching” here is code for “I don’t want to promise anything because it’s not something that’s guaranteed” but I suppose you think it’s corporate doublespeak. I can’t really blame you except say that I know it isn’t.

@moo1210

Luau File Sync would’ve already existed in the same way it does “internally”, such as .rbxp files

Their internal file sync sucks and you don’t want it. Ask people who have used it daily if you want but it’s… not amazing. Especially not compared to other solutions like Rojo and Argon.

The original alpha version of Luau file syncing? Also not amazing. It’s good that it was scrapped, even though it means that things have been delayed. I’m very happy that people at Roblox actually listened to feedback on it rather than releasing a bad product.

---

This reply has gone on long enough, so I won’t keep going too much longer. What you should take away from this is that things are never as simple as you want them to be.

Almost all of the things you listed are decisions made by other teams, historical decisions, or something that requires e.g. legal approval. You have to temper your expectations. People are doing the best they can.

I’m happy to talk about this more in DMs if you want to have an actual back and forth on why I feel the way I do, but let’s not clog up this thread any more than we have.

[c1rcuitbent]

Will the CoreScripts ever be open-sourced again?

Making a pull request or issue is way easier than making a bug report that can take years before being patched

[BlueLegindDev (BlueDev)]

Hi thanks for informing Open Roblox Platform project. Things are going great right now. The focus on integrating third-party tools, higher-quality API docs, and a cohesive Luau eco-system are things that our community really does need. I am excited to see how the Beta builds with Lua code running in it will improve our workflow. I appreciate the time and efforts you have put on getting feedback from the community and look forward to further updates as this project evolves. Once again, thank you!

[metatablecatmaid (metatablecat)]

iirc the CoreScripts repo was a mirror and Roblox didnt accept submissions on it

i could be totally wrong here though because I wasn’t around the OSS space when that existed.

[c1rcuitbent]

i remember seeing PRs on it huh

but still github issues are easier than devforum bug reports since people usually dont ignore issues like they ignore bug reports

[nezuo]

They are two separate feature requests. My feature request (User Studio CLI Flags) is just intended to pass information to plugins when opening a place. It’s not asking to control studio without a GUI.

[Maximum_ADHD]

That all looks good! Sorry for throwing my hat in the arena without thoroughly reading through everything that was said beforehand

I look forward to seeing what comes of this and hope I can provide some useful input!

[Dekkonot]

@DevelopmentDeadline

I see this feature request: User Studio CLI Flags . It sounds like your alluding to more than just starting Roblox Studio without GUI, but also being able to control Studio without GUI. This feels like two separate feature requests. If you have any clarifications on the things you’d like plugins to be able to do in Studio that they can’t do currently, please let us know!

I can make feature requests for these separately, but in yes. In essence there’s two main concepts here:

1. The ability to run Studio without the UI, since it’s a lot of overhead we don’t need for automation
2. The ability to control Studio via CLI. This can be bypassed to some extent using plugins and scripts, but a lot of things can only be done via the UI right now.

My example is that I’d like to write a script to run tests in Studio. It is ridiculous if I have to send multiple HTTP requests to do this, since I have Studio on my system locally. So, my natural inclination is to try and run it via CLI… While this is possible, it doesn’t work for testing for a few reasons:

1. You can’t pass information in and out of Studio easily.
2. You can’t mimic the behavior of “Run” via Plugin. RunService:Run starts a simulation, but it doesn’t mimic the actual behavior of Studio when you press Run.

These are both solvable problems, but it would be awesome if they were both easier. I’m less focused on a headless tool and more focused on a version of Studio that I can actually use with external scripts, since it’s silly how many hoops we currently have to jump through to use Studio automatically.

Remotely, it’s a different story of course, but locally? Please I just want to use the thing I already have installed and that people already use for development.

[c1rcuitbent]

wasn’t there a -script studio flag or was that removed?

[DidiSharkYiatCraft (Shark)]

Does this also have the potential for the possibility for offline editing in studio? I think it would be an amazing feature, and could help developers a lot in situations where the internet or power is down.

[moo1210]

@Dekkonot

Hi! I’m not a Roblox employee so I can reply freely to this in a way that Roblox staff can’t. I’m also in a position where I know a lot about the things you posted about and thus can provide some realistic responses. If I ignore a point, it’s because it doesn’t apply here since this is post is from a specific team and not Roblox leadership.

It sounds like you’re describing the Community Feedback program here, which is under an NDA.

Most of your post is saying this is for “security” but to me, this sounds more like obfuscation. Were people really just “putting builtin plugins in their folder”? Does Roblox have any telemetry data or feature requests to suggest this? It seems like a very far-fetched claim. The only instance of this I can think of is when they’ve suggested doing it themselves, to rollback a broken build of one of those plugins.

Either way and at the end of the day, you have to have “Internal Mode” or be a “Soothsayer” (legitimately or not), and I use these features daily that you state “suck”. Accessing this is not exactly that hard and possible in multiple different ways. I come across the internal mode banner on social media infrequently. When I use these features, RBXP files and InternalSyncService work fine for me, but you could argue that Rojo is preferential in certain various ways. It’s already common place.

Roblox literally fired the original creator of Rojo, while he provided a statement later saying he was labeled “ringleader of engineering dissent”. Colorful word for whose tools we talk about and use here.

Have you used absolutely any of these features or are you just talking out of your mouth here? Is this what they’re pushing in CFP?

Also:

@Dekkonot

I’m happy to talk about this more in DMs if you want to have an actual back and forth on why I feel the way I do, but let’s not clog up this thread any more than we have.

I have no problem talking about my view in a public forum when they’re making an announcement post telling us that they’re making things more open, while they proceed to do the polar opposite. Otherwise, I would have just stayed quiet as usual, the DevForum kind of sucks now compared to many years ago. I’m mostly talking into a void here, but this thread is not being clogged up by someone saying they’re doing the opposite, that’s just honest feedback. If Roblox loves feedback so much, none of what I’m saying should hurt that much.

@Dekkonot

Almost all of the things you listed are decisions made by other teams, historical decisions, or something that requires e.g. legal approval. You have to temper your expectations. People are doing the best they can.

I also understand Roblox is a business, and a public one with investors now after IPOing looking to drive profits and most of this is a non-concern for them. My expectations are already tempered knowing none of this is a priority for how they operate. But, if Roblox is going to say their end goal is to do the opposite in this colorful borderline announcement, I will absolutely speak up about that.

Also, to correct myself on removing FFlags, a new channel called “ZEnableZstdForClientSettings” that was conveniently privated after I posted this, suggests they’re just putting it behind a compression algorithm. Again… this is exactly what I’m talking about and how Roblox operates trying to remove or obfuscate features. I’m also not sure how they don’t think someone will post an editor on GitHub. Do they not remember how they got into this “mess” (as in for them, people editing FFlags) in the first place?

TLDR: I understand Roblox is a SaaS company and virtually none of what I’m talking about is a priority. I do not believe security through obscurity is security. But, that doesn’t mean I don’t use these features that you state suck, and will speak up about that.

[Dekkonot]

@moo1210

It sounds like you’re describing the Community Feedback program here, which is under an NDA.

I am not. While I am technically a member of that program, I’ve used it I think three times ever because most of what’s discussed in it isn’t really of interest to me. I am under NDA for a few things but nothing that I talked about in this post, obviously.

No, most of my knowledge just comes from experience and talking to engineers over the years. I was in a Discord server with the engineer that implemented signing for built-in plugins, as an example, so I was able to ask him questions about why directly.

@moo1210

Were people really just “putting builtin plugins in their folder”? Does Roblox have any telemetry data or feature requests to suggest this? It seems like a very far-fetched claim. The only instance of this I can think of is when they’ve suggested doing it themselves, to rollback a broken build of one of those plugins.

You may not realize it, but prior to builtin plugins being precompiled (aka: they were still easily modifiable), Roblox implemented signing of them. This is the main thing stopping you from loading them, and it was implemented specifically to combat people dropping outdated or malicious plugins into Studio. Yes, this was something that actually happened. It’s stupid that people fell for it but you must remember that a large portion of Roblox’s audience are literally children, so they fall for dumb things all the time.

@moo1210

Roblox literally fired the original creator of Rojo, while he provided a statement later saying he was labeled “ringleader of engineering dissent” . Colorful word for whose tools we talk about and use here.

You lack critical context for this, but I won’t get into it. The important part is that the leadership that fired him is no longer at Roblox (I have verified this with other engineers). I won’t post anything else about that here because it’s not relevant to this discussion and hasn’t been for years.

@moo1210

Have you used absolutely any of these features or are you just talking out of your mouth here? Is this what they’re pushing in CFP?

It may not be obvious but I’ve been around the block a few times. I’m a long-time veteran of this platform and I’ve used more garbage tools than you can possibly imagine. Hell, I used precursor tools to Rojo, including one I wrote. I don’t know what they’re “pushing” in the CFP program but it’s rather insulting to suggest I got my opinion from someone else rather than forming it on my own.

To directly answer your question: Yes, I have used their internal script syncing tool and it is bad. Downright terrible, even, compared to the alternatives. It being released publicly wouldn’t have won anyone’s favor.

@moo1210

Also, to correct myself on removing FFlags, a new channel called “ZEnableZstdForClientSettings” that was conveniently privated after I posted this, suggests they’re just putting it behind a compression algorithm. Again… this is exactly what I’m talking about and how Roblox operates trying to remove or obfuscate features. I’m also not sure how they don’t think someone will post an editor on GitHub. Do they not remember how they got into this “mess” (as in for them, people editing FFlags) in the first place?

I can’t tell if you actually believe this or you’re just being disingenuous. I’m going to let you simmer on why someone might want to compress data that’s sent to clients from a server. If you can’t figure that one out on your own, I don’t know what to tell you.

[moo1210]

This feels like it’s becoming far too opinionated. Frankly, I do not care about you being a long-time veteran of the platform at all, this isn’t the talent hub. Just interested in speaking mostly history here. Agree to disagree, but you being a “veteran” doesn’t change anything I said.

Also, your reason for compressing a local file that’s already typically a {} by default on most clients (you could argue mobile clients have some, but they’re pulled from the CDN and will be instantly overwritten if you change it, talking about flag overrides here) is telling me you have no idea what you’re talking about. Again, do you use literally any of this tooling in your workflows? It doesn’t sound like you know what you’re talking about.

Are you going to describe for everyone what exactly is so bad, crap, and downright terrible about these tools or continue to talk nonsense? This isn’t reassuring me if that’s what you think it is, I already expected them not to respond to anything I said.

[Siydge]

@DevelopmentDeadline

Enabling external tools to run Luau code in the engine via Open Cloud, with full access to creations

Will this strictly be for within Roblox Studio, or will we be able to do this through external programs, such as say, I as a developer wanted to have a program that communicates to the Roblox Client a flight-sticks and throttle’s inputs through to a Roblox clientside Script to handle the information, something the Roblox Engine cannot access naturally, as long as the user runs the external program?
If so that would be awesome for allowing developers to provide additional support that may be for edge-cases, i.e. the example of a HOTAS controller being supported for a specific game. It’d open up the modularity and opportunities that developers can explore, perhaps someone wants to offload high performance tasks to an program designed specifically to compute the task, or they want to access certain features such as raytracing cores to apply better lighting, or you want to add additional VR tracking points. Just a few ideas of many.

[DevelopmentDeadline]

@Siydge

@DevelopmentDeadline

Enabling external tools to run Luau code in the engine via Open Cloud, with full access to creations

Will this strictly be for within Roblox Studio, or will we be able to do this through external programs, such as say, I as a developer wanted to have a program that communicates to the Roblox Client a flight-sticks and throttle’s inputs through to a Roblox clientside Script to handle the information, something the Roblox Engine cannot access naturally, as long as the user runs the external program?

This is an interesting question. Right now we are just thinking of creation/edit time support.

[DevelopmentDeadline]

@DidiSharkYiatCraft

Does this also have the potential for the possibility for offline editing in studio? I think it would be an amazing feature, and could help developers a lot in situations where the internet or power is down.

Whilst it’s true that Studio Script Sync will make it easier to edit your code offline, as @skywise84 mentioned in the Creator AMA last week, we are not currently planning offline support in Roblox Studio. Creator AMA (RDC 2024) with Nick and Tian [September 19, 2024] - #130

[PureBigMadBoatMan]

I’ve passed this along to the relevant team - can’t promise anything more than that, but it’s on their radar at least.

[DevelopmentDeadline]

@DevelopmentDeadline

We announced this at RDC and plan to ship a Beta by the end of the year, focusing first on enabling automated testing

This Beta has shipped!

[Beta] Open Cloud Engine API for Executing Luau

Hello Creators! Starting today, your tools are able to headlessly run Luau scripts in a Roblox place, within the Roblox engine, via Open Cloud! As we spoke about recently in our Vision for an Open Roblox Platform, this beta is one of the first steps in our plan to ensure external tools have access to the full power of the Roblox engine. The power of Open Cloud is now extending beyond just its own APIs and into the Luau APIs exposed by the Roblox engine and the millions of lines of Roblox Luau …

[nicogamer12357 (ImNicoReal)]

Thank you so much dude, if you can notice me anything related I’d be glad!

[DevelopmentDeadline]

@DevelopmentDeadline

• Supporting out of the box workflows for iterating on file-based content, starting with Luau scripts
  • We plan to ship an early preview for Luau File Syncing before the end of the year.

An early preview of this is now available in Studio as an opt-in feature.

[Early Preview] Studio Script Sync

Today, we’re sharing a very early preview of the new file syncing approach for Scripts we announced at RDC. Our goal is to provide built-in support in Studio for working on your code as files, allowing you to use your favorite IDE and plugins in any Roblox project. We want to share our progress as we go As some of you may know, we first announced Studio Script Sync at RDC in 2023. However, we weren’t satisfied with the initial version. It aimed to simplify code-as-file workflows but fell sh…