Working together to build an Open Roblox Platform

This sounds awesome! I’m excited for this to release!

2 Likes

What’s the benefit of using cloud-based Luau execution over something like Lune?

2 Likes

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 :sweat_smile:

1 Like

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?

2 Likes

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.

2 Likes

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!

1 Like

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.

2 Likes

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.

6 Likes

Amazing! I’ve been waiting for these kinds of updates :smiley:

Can’t wait to properly try out the script execution on RCCService! :slight_smile:
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?

2 Likes

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.

11 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

2 Likes

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!

8 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.

1 Like

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

1 Like

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.

3 Likes

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

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

2 Likes

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.

4 Likes

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

1 Like

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.

1 Like

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:

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.

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.

2 Likes