I understand that this announcement focuses on enhancing the Luau ecosystem and integrating external tools. but, since we’re discussing a more flexible and open platform, does this potentially pave the way for supporting other lower-level programming languages in the future by making more of the Roblox engine accessible via APIs, for example?
3 Likes
im noticing a severe lack of gpu shaders 
come on guys, every device in the past 10 years has a dedicated gpu
7 Likes
I wasn’t going to reply initially, but I’m not sure I can resist Roblox making any of these claims after the second paragraph, especially to end with a “promise”, that you already consistently break. I simply do not understand this nothingburger announcement post. If you were actually working to make a “Open Roblox Platform”:
- You would still be able to create your own built-in plugins without internal mode
- 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.
- You wouldn’t be using “developer efficiency” as a constant excuse for these some changes. If the platform focused on being “open”, that shouldn’t be a problem.
- RobloxScriptSecurity/LocalUserSecurity would have been used less, not more.
- 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.
- Instead of the idea of “Open Cloud” existing as a base, we would be using BEDEV2 APis directly with API keys. You also do not release documentation for those APIs (in OpenAPI spec), as you did with BEDEV1 APIs.
- You would not be trying to remove FFlags in the client. In addition, the excuse of cheating is pretty poor, most of these flags aren’t usable for cheating just from the flag directly, the problem is usually from clients having complete control over physics simulation over parts they own, such as their character. (Note how most shared “cheating” flags usually start with “DebugSim” or “Sim”)
- You wouldn’t have stopped putting FFlags in public release notes.
- 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)
- Luau File Sync would’ve already existed in the same way it does “internally”, such as .rbxp files
I could keep going in other more specific ways, but this is already getting long for a reply.
Roblox loves to state they love feedback, but when it’s feedback like this, suddenly it isn’t viable feedback to interact with.
Make no mistake, Roblox is becoming a more closed black box platform, not some open platform. Or maybe we have different definitions of “open”. Either way, this announcement is extremely triggering to even read. Please make announcements about new and useful features in the future, not complete random PR posts announcing literally nothing. This is a forum for developers, not a corporate blog feed for investors.
15 Likes
Exciting to hear that news! looking forward to it!
2 Likes
This sounds awesome! I’m excited for this to release!
1 Like
What’s the benefit of using cloud-based Luau execution over something like Lune?
1 Like
I feel like there are many really exciting things here but I am too uneducated in these matters to understand
Can someone dumbify this for me 
Something I’ve wanted with open cloud is the ability for studio plugins to interface with it, idk how you’d do the oauth though, studio API to help us and return the token?
1 Like
We talk a bit about the importance about serialization in the original post, and my reply above.
Our view is to make real progress here, we need to tackle the complexity in serialization that comes from how our engine implements non conventional properties today.
If we provide a stable Lua property interface for everything, then serialization (like you alluded to) becomes a much more reasonable problem for Roblox or the community to solve in a way that suits their use cases.
We would like to get to a world where the community does not need to ‘correct’ anything, but as I’m sure you can imagine this is going to take time.
Like I said in my reply above as we start to firm some of these things up, we will share a write-up with more detail on this topic. Looking forward to having a robust conversation with the community about solutions then.
1 Like
Thanks for the clarification.
This isn’t something that’s planned / we’re working on at the moment, but I want to learn more about the use case.
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 agree this is a clear gap in Open Cloud, and we’re keen to help teams migrate off cookie auth.
In the original post we hint at ‘Supporting integration between file-based code libraries and Roblox Packages with distribution on the Creator Store’. We aren’t quite ready to talk about solutions here yet - but part of what we’re thinking about is how to provide a great experience for uploading packages or models automatically, from outside of Roblox Studio.
Nothing we’re ready to talk about yet, but will follow up with more detail in the not too distant future.
1 Like
Great question! The short answer is they are different tools for different jobs, and the choice will depend on what you need.
Lune is a standalone runtime for Luau. It’s used to run Luau code. When it comes to manipulating creations, Lune supports emulating Roblox APIs and does not run the Roblox engine itself.
We think Lune is awesome, but we’re pretty excited about the use cases exposing the full power of the Roblox engine to external tools will unlock. We expect both tools will play an important role in the ecosystem.
We’ll talk a little more about this in our Beta feature announcement in the near future.
5 Likes
Amazing! I’ve been waiting for these kinds of updates 
Can’t wait to properly try out the script execution on RCCService! 
Lets just hope everything is setup properly both for safety and accessibility.
Also, will we ever get access to ThumbnailGenerator on RCCService from Open Cloud?
1 Like
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.
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.
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.
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.
I would love for this to happen too, and so would some people at Roblox. Like the announcement says:
“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.
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.
9 Likes
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
1 Like
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!
3 Likes
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.
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
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.
2 Likes