ROBLOX being open sourced friendly would go so hard
That’s exactly what this means!
Luau introduced require by string behavior and we are working on supporting a subset of this behavior in the Roblox engine. Essentially - allowing you to require a ModuleScript with a string path. We’ll share more details when they are ready, there’s some complexity in making this work we want to get right.
Researching: Open-sourcing more Luau code written at Roblox with the goal to one day also accept contributions in select areas
This would be huge and I can’t wait for a future where this is possible.
So like a way where I can add a plugin to Studio and then do like… local ExamplePluginAPI = require("PluginName") ExamplePluginAPI.HideWindow()
? That would be really cool!
I would love it if this feature request was considered: User Studio CLI Flags.
As @Dekkonot says under the post, it’s a request that’s specific to the needs of Rojo (that’s not to say people won’t have more creative uses). However, I think it’s important that features that improve the development workflow for external tools are considered!
Absolutely thrilled by this. These types of workflows allow us to scale very large and work on different things very rapidly.
- We would have to maintain a standalone product separate to our existing core offering of Studio, Client and Cloud
- Many challenges already solved by our core products (such as engine versioning) would need to be solved in a different way
Personally, I don’t fully understand this point since internally there is already a CLI for Roblox. Though I think it’s held together with duct tape, but it exists because internally Roblox works on things very similarly to projects that utilize external tooling, given the creation of the CLI and Rotriever.
It seems like it’d be a pretty good win-win situation to make it an official and public thing, but guess not.
As for versioning, is it that terrible to potentially have a headless CLI of the Roblox engine that could get outdated? I imagine in most cases, either the tool updates itself like Roblox already does or CI pipelines would download the absolute latest version from somewhere.
The Roblox engine is innately online, and requires authentication to work predictably.
I get it, but man it would be so so nice to have at least something and just slap your cookies through it and it just works. An API key would be more complicated I figure. Unfortunate. Hopefully someday
This is INSANE, I’ve always wanted to be able to contribute to the engine. Im pretty sure that outside contributors would be able to increase the development rate of the engine incredibly by allowing them to give feedback for new and existing features and suggest improvements and thanks to open sourcing of the engine also implement the requested feature for you.
Now I wonder… are you also planning on accepting feature requests and prioritize them depending on the demand for that feature? I find that there are many great feature requests that (in my opinion) should have a much higher priority and should be attempted to be implemented ASAP.
Talking about new features, i have to admit that I found the features that have been announced at this year’s RDC quite lacking compared to last year’s RDC. The only features that really excited me at this year’s RDC were the Server Authority for Competitive games, Occlusion Culling and Luau file syncing as well as being able to run Luau via open cloud. This list could have been a lot longer if priorities were put on the right features by making polls on which features they want to see ASAP for EVERYONE, yes not only selected people.
Thank you for taking your time to read this and im looking forward to your reply.
Well currently I link github and roblox studio using the open cloud api allowing you to use the mobile version of github and different mobile ide’s to actually add code (due to only 1 of the same name it just uses the unique id’s for the objects name) With this it would be useful as then I could hopefully look at the rbxmx structuring and then implement a game to XML editor where it can convert a live game into the rbxmx format so people who say had f3x building tools could then publish these building changes. It could also then be used for proper syncing between the code editors on github
We need more open sources tutorials for performance. for scripting, lighting, texture etc
I still really want to see stable public specs of Roblox’s binary formats, and a stable basis for serialization that doesn’t require interaction with cloud APIs or the engine directly.
In an ideal world, the API Dump would be sufficient enough to describe all interactions with the engine in Luau. In reality, there are a lot of manual edge cases and hard coded backwards compatibility quirks which make this difficult.
The work has effectively fallen on the community to correct in our implementations rather than Roblox. This is prominently displayed in the issue logs for rbx-dom.
Holy shucks. I opened the documentation and it looked HOT AND SEXY. A like cannot describe how much time this would save with typing ergonomics instead of indexing and the way this could cosmetically encourage using modules.
So glad to hear it is being worked on to port to Roblox.
Sounds great for Roblox game developers!
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?
im noticing a severe lack of gpu shaders come on guys, every device in the past 10 years has a dedicated gpu
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.
Exciting to hear that news! looking forward to it!
This sounds awesome! I’m excited for this to release!
What’s the benefit of using cloud-based Luau execution over something like Lune?