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.
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.
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!
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.
I can make feature requests for these separately, but in yes. In essence there’s two main concepts here:
The ability to run Studio without the UI, since it’s a lot of overhead we don’t need for automation
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:
You can’t pass information in and out of Studio easily.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
