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!
2 Likes
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:Runstarts a simulation, but it doesnât mimic the actual behavior of Studio when you pressRun.
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
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.
2 Likes
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.
3 Likes
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.
1 Like
This is an interesting question. Right now we are just thinking of creation/edit time support.
1 Like
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
2 Likes
Iâve passed this along to the relevant team - canât promise anything more than that, but itâs on their radar at least.
5 Likes
This Beta has shipped!
3 Likes
Thank you so much dude, if you can notice me anything related Iâd be glad!
2 Likes
An early preview of this is now available in Studio as an opt-in feature.
1 Like