As a Roblox developer, it is currently impossible to read or fork the built-in plugins as we were originally able to do. This is because they are now encoded in a way that Roblox Studio cannot parse when trying to insert.
This is a big loss because the built-in plugins were a treasure trove of reference material that could be learned from, especially for plugin developers. They showed how to implement complex systems and solutions for weird edge cases that simple sample projects and tutorials never could. Most importantly, code from these plugins could be forked and repurposed in developer-created plugins.
In particular, a really exciting point about the Lua Draggers was that they could be forked without much difficulty to allow developers to customize their building experience without having to re-implement complex dragging logic from scratch. That’s no longer possible without digging up an old version of the plugin files.
If Roblox is able to address this issue, it would improve my development experience because I’d be able to continue learning to make better tools for the platform.
I support this. Even if the full source plugins are no longer bundled with Studio, keeping them downloadable somewhere is invaluable to plugin developers. It’s a major loss to plugin creators who used built-in plugins as a reference for their own implementations.
In terms of the file implementation, the RBXM serialises its code in a compression format known as zstd. Studio can already read this.
The issue is actually that the source code is a compiled bytecode, which Studio cant read. Max’s client tracker has started dumping the compiled bytecode again from these plugins in the .luac format.
Aside from using existing tools as a reference, being able to fork built-in plugins allows developers to make minor changes or fixes quickly without having to rely on the update gods to make the tools better.
Context: The plugins which ship with Studio are now are pre-compiled to bytecode and don’t include the source code at all in order to speed up Studio load time, so there’s a good reason they can’t be edited in Studio.
I’m looking into what we can do about this. Given the ever increasing amount of studio functionality delivered as plugins it was unsustainable to include the entire source only for it to never be used outside of a very small number of users forking it. But as you point out there’s benefits to having them available in some other way.
In the meantime, here’s the most recent Dragger/DraggerFramework code if you need it: DraggerFramework.zip (395.5 KB)
It’s great to hear that Roblox Studio plugins are finally releasing their source code or at least trying.
If you can release the source code for plugins will you post it on the Roblox GitHub? I believe that Roblox used to have a repository containing source for Roblox Studio Plugins called Studio Tools but it was left unmaintained before being archived and a majority of the plugins how are broken.
The best approach is to have an archival location on a public GitHub repo, or distribute them through the setup program with a launcharg like --includeBuiltIns, though I’ll let you guys come up with something
I strongly agree. As an inexperienced programmer I used these plugins as ways of understanding of how to do things and I would take small snippets out to use for my own work and it’s a shame it’s no longer possible.
Having them available on GitHub or distributing them through launch arguments would both make me happy.
We would LOVE to have this at hand. You cannot believe how much I struggle on the daily with unintentionally laggy default plugins. My camera lag has gotten even WORSE after many updates have passed.
With Luau Libraries available for use, will the built-in plugin code or the libraries used to make them be released? I believe that the open sourcing is starting with libraries with no dependencies, and working up from there.
I know that there’s security risks and work needs to be done to clean up and remove non-public facing code from the plugins, but being able to fork and use them as a starting point, or modify behaviour is a big time save (and I still go back to old versions of the built in plugins for starter code!)
I’m still curious if there’s any attempts to open source these plugins.
There’s decompiled samples now (thanks Max) but since that comes from bytecode, we lose comments and the source code might be impure (luau optimisations, bad opcode mappings etc.)
If theres internal files blocking this, surely a finely tuned .gitignore could fix that
I 100% support this. In my eyes there is no reason for making the plugins unreadable.
It would also support the developer team because problems are able to be diagnosed a lot easier by normal users, since they have the plugin source.
For some of the code which would be broadly useful for developers, yes. The idea is that it should be shared, though no specific timeline on getting that to happen. Other code was only available because it happened to be that way thanks to the way the tech was set up, and that code won’t return to being available.
For example, the code driving the Game Settings dialog is no less internal and proprietary than random C++ code in the engine itself and it’s unlikely that it would ever be made available. However some of the shared UI components depended on by it have a high likelihood of eventually becoming available.
Still no update on this? The plugins still use the engine is very interesting ways, and I’m really excited to learn how the AI-related plugins work, especially the Material Generator and Assistant plugins.
