I was gonna make something like this but nic.
You can use Roblox’s API dump directly:
- Fetch the current version hash of Roblox Studio from the following URL:
https://setup.rbxcdn.com/versionQTStudio - Fetch the latest API dump by replacing
<HASH>in the following URL with the retrieved version hash:
https://setup.rbxcdn.com/<HASH>-API-Dump.json
rbxcdn.com isn’t filtered by Roblox, so it’s okay to make requests to from Studio.
7 Likes
Awesome, thanks man! I didn’t realize that domain even existed. I thought the only official site was http://setup.roblox.com/versionQTStudio. I thought it was very strange how it wasn’t possible to make HTTP requests to. I guess I should have looked around more. I’ll go ahead and give the plugin an update within the next few days to support the online API now that I can utilize the official source.
BTW, thanks so much for your old scrapes, I based the early versions of this around it as a placeholder API to test functionality and performance. It was a great help because it was the only API source I could find that seemed very dependable!
Does this save scripts? If so your a life saver.
This is pretty neat along with all the options to chose from. I Believe something like this already exist made by Sleitnick but without the extra options Object-to-Lua Serializer
Isn’t this just the same as Codify by @cxmeels?
Either way, this definitely has some unique features.
1 Like
it isn’t really.
This overall has more customization than codify. You can’t include attributes in codify like with this plugin.
1 Like
I’m not entirely sure what you mean when you say “save scripts” but it does create a ModuleScript when the Output Setting is set to “ModuleScript”. The ModuleScript will be created under the same parent as your selection.
You can save it locally by right clicking the ModuleScript and then clicking “Save to File” or alternatively if you want to save to the cloud you can click “Save to Roblox”.
To address those other plugins, I should preface this by saying I haven’t tested either of those plugins and that I’m only basing this off of their DevForum posts/glancing at their provided demos:
- In sleitnick’s Object-to-Lua Serializer from what I could tell, it seems like it’s a proprietary format used only to replicate instances through executing the module function.
The core functionality is extremely different than Instance to ModuleScript Converter. Instance to ModuleScript Converter does not support replicating instances. It only supports the gathering and formatting of the instance data. (See Limitations for more info.)
Click to view Object-to-Lua Serializer Demo
- In qsqrl’s Codify, it seems that the data is formatted to create a list of variables for a normal script format (again for replicating instances), rather than an array of data formatted for a ModuleScript.
Click to view Codify Demo
The core intended functionality of the Instance to ModuleScript Converter is to convert all of the instance data into a module format that can be digested by other scripts. Whether that be replicating instances, making inventory systems, creating player data, making player stats, etc. What you do with the module data is up to your creativity and your use-case but you still have to make scripts on your own to digest the modules. This plugin simply converts instances into a ModuleScript format, converts modules into visual folder directories, and nothing more.
This plugin should be extremely useful for making DataStores or creating data references that may be required by other scripts. For example, if I were to use the regular script formatting from Codify, I would need to copy each of those variables to every single script which would be very tedious and create extreme clutter. Whereas when utilizing modules, I can just reference all of the variables from a single ModuleScript using require().
Personally, I use the plugin to convert folder directories into playerdata modules and inventory modules as it’s much easier to edit attributes on a folder/tool than it is to navigate a massive array with multiple subtables. It’s also much easier to use the integrated value pickers from the Properties window (Colors, NumberSequences, Booleans, etc.) rather than having to type them all out manually.
This plugin also includes quite a bit of customizable settings to include/exclude certain data in the converted module as well as a few formatting settings to make it versatile for multiple use-cases.
not at all! just plop the generated code into a ModuleScript, and return the root instance (which should be sufficient). tabulating those instances could be added if that’s something people want though
however, this plugin does do the whole instance to data structure thing, which is nice for those that like to use ValueBases to store player data (I’m assuming this is what the “DataStore Compatibility” toggle is). it’s not something that will be added to Codify, since that’s not what Codify is for
offline mode is also something I don’t plan to offer. Codify will fetch the API for your currently installed version of Roblox Studio on first use, and will reuse that data. in this sense, Codify can run offline after a first use, but I don’t plan on integrating a full API into Codify for offline use, as the API does change between versions
exporting to pastebin is also a nice touch. that’s been on Codify’s to-do list for a while (export to Github Gist), but not yet implemented
fwiw, Codify supports this too. there’s many formatting options available to match your preferences and coding style
in terms of properties, Codify only exports those that differ from the default settings. this helps reduce the length of the generated code snippets by excluding properties that don’t need to be assigned to, because they already match their default values
attribute support is something I can add to those frameworks that support it, again, if that’s something people would like to see added
based on the screenshots of this plugin, I do have a little feedback for you:
-
increase the contrast between the background and checkboxes/buttons. they’re a very similar shade and when they’re not selected, it’s pretty difficult to distinguish where the clickable area actually is
-
swap out the buttons for “Mode” and “Output method” for actual dropdowns (with an arrow icon to indicate that they’re dropdowns). they currently look like they’re either buttons or text boxes, and as a user, I wouldn’t know what to type into them, so I’d probably leave them at their default settings to avoid messing anything up
-
add hints below each of the configuration options. this explains more to the user about what each option does. a couple of the options (“Support Location Types” and “DataStore Compatibility”) are a little vague, and could do with a concise explanation so that users can easily decide if they want to enable/disable them
2 Likes
Thanks for the UI feedback!
-
I went ahead and darkened the button color to have a higher contrast from the background. (Previously a 2% difference, now 8%.)
-
You can rest assured, the end user can’t mess up any of the conversion settings. The option fields are entirely made up of TextButtons, which change when clicked, requiring no manual input from the end user.
-
The wording with “Support Location Types” is a bit confusing so I have renamed the setting to “Include Object Variables”.
The “DataStore Compatibility” setting is pretty straight forward. Modules/tables are either DataStore compliant or they aren’t. DataStores only allow string, numbers, and booleans. As the name of the setting implies, when enabled, the converter will translate and reformat any non-compliant type (CFrames, Colors, Objects, Enums, NumberSequnces, etc.) to be compatible with DataStores.
GitHub Gists was very appealing to me as well given how well structured, more flexible, and better accessible it is over Pastebin, though ultimately I decided it was unnecessary for my ModuleScript conversion plugin since it would just add major complications. As far as I can tell from their API Documentation, I believe they only allow HTTP Post requests with attached files, which Studio’s HttpService:PostAsync() function does not support (data is formatted in string).
From my understanding, it would require developing and hosting an API to receive post data from Studio, then it would need to decode that data and convert it into a lua file format, then send another formatted HTTP Post with the attached file. It would also need to include a function in the API to remove Gists after a certain timeframe as to not take up storage space. All that effort just to make a Gist seems like too much for a simple Studio plugin in my own opinion.
I would always recommend HttpService:RequestAsync over Post/GetAsync. RequestAsync includes the ability to specify the HTTP method (e.g. POST, GET, PUT, DELETE, HEAD, and so on…).
in regards to authorising a user to post gists on their behalf, you can use GitHub’s Device Flow authentication, which presents a code to a user that they enter in a web browser, and returns the authentication token back to your app
you don’t need to delete the gist after a specific time period; there’s no storage limits on Gists, and the user can just delete it when they’re done
glad to know you updated the contrast and wording though! 
1 Like
While RequestAsync has more advantages than PostAsync by allowing specific HTTP methods, PostAsync has worked exactly as needed so far since I have only been making post requests. Thanks for the recommendation! I’ll be sure to engage RequestAsync in the future.
The complication I specified with GitHub Gists was the use of files, which neither PostAsync nor RequestAsync support. As far as I could tell by looking through their documentation, in order to post to Gists I would still need to make/host my own API to convert string data into lua files and it would then need to send another post request with the attached converted file to GitHub. This is why I chose Pastebin over Gists as it decodes PHP formatted string natively in their API instead of requiring attached files.
When I noted that the API should remove Gists, it was just a suggestion as to how I would operate it. I just wouldn’t want to take up unnecessary space on their servers. When creating Modules for directories thousands of instances big, the file size can reach upwards of 20+ MBs with multiple conversion options enabled. That could end up taking a lot of server space if many people use it over a long enough period of time.
1 Like
Is there a way to post to github or gisthub instead of pastebin and using JSON instead of php?
This plugin does not support Github Gists, only Pastebin. You can review my reasoning in this reply from earlier in this thread.
Click to view quote.
This plugin has the Pastebin Output Method for convenience. Pastebin is used to host modules temporarily so the user can download/copy/share it. Any modules uploaded to Pastebin automatically expire 1 hour after posting.
For most use cases, I suggest using “ModuleScript” as your primary Output Method when using this plugin since it creates the module directly into Studio. The only drawback to this Output Method is the size limit of your conversion, which all plugins are limited by. (Roblox ProtectedString Write Limit:195 Kilobytes)
If you’re asking about different output formats, all output formats with this plugin are formatted for Roblox ModuleScripts in Lua. When being posted to Pastebin, the Lua data is converted into PHP only so their API can digest it. Once it is successfully posted with their API, it is converted back into its original raw Lua format. The PHP format is only for the API backend. Here is an example of a module uploaded to Pastebin.
If you’re asking if it’s possible to post to Gists on your own outside of this plugin, you would have to curl your own HTTP Request outside of Studio with these parameters/formatting alongside whatever attached files you are trying to upload.
Could you clarify what your use case might be? I might be able to provide a better answer.
I prefer using Github and Gist rather than PasteBin.
I’d use this for keeping a list of Items, Weapons, etc updated automatically in code, so I don’t have to manually do it every time a change is made. I’m using this for DFlag and FFlag feature in my game, currently I use Gist for that but I have to manually edit the file every time there is a change.
Perhaps I could try using PasteBin but can I do the same with it andhow often is the change reflected? Gist updates every 5 minutes
The key here is for me to make changes from any device from anywhere using a browser.
Perhaps this is outside of your plugin’s scope
but how would I read the file from Pastebin, I’m not sure if you covered that in the OP
It appears Pastebin can have pastes read using their Scrape API but only for whitelisted IPs (which I’m pretty sure Roblox’s HTTP Service is not). Also, all conversions uploaded by this plugin expire after 1 hour as to not fill up non-pro users posting limits of 10 total active unlisted pastes.
If I understand correctly, you fetch the Gist data from your game using HTTP requests to GitHub and change variables in your JSON table remotely and what you want is to easily convert instances from Studio into a JSON format instead of having to type out each variable manually every time you add/remove a variable? Unfortunately, as I mentioned in my earlier replies, I don’t believe the plugin can natively upload to GitHub due to Studio’s inability to attach files to HTTP requests.
This converter doesn’t currently have an option for JSON formatted data, only Lua formatted for ModuleScripts. However, I can implement a conversion option that creates a JSON script alongside the ModuleScript but it will have the same limitations as the ModuleScript (195 Kilobytes) which you can then copy and paste to GitHub Gists.
To clarify, even though this proposed option would provide formatting for JSON, the process would not be automatic. You would still need to access Studio and use the converter to make new JSON scripts since this converter is not a passive plugin, it requires user selection and button activation.
Would that plugin option help apply the converter for your use case?
I think my use case is out of your plug-in’s scope. I’ll have to make a solution of my own 
Thank you so much for your replies and effort!
I’ll definitely try out your plug-in and provide feedback!
Yes
1 Like
I went ahead and added support for JSON formatted modules.
You should now be able to create a JSON formatted array from any directory/instance you want!
Once converted, just copy and paste the JSON data from the script into Github Gists or your preferred API data host.
Note:
- Since the output script is formatted in JSON instead of Lua, the Script Analysis window will notify of a bunch of Syntax Errors for every JSON module. I would suggest deleting each JSON module after you have transferred its data, that way the Script Analysis flags/alerts disappear.
- Needless to say but I’m going to clarify this anyways for anyone that happens to utilize this Output Method: JSON encoded modules cannot be read from or used as game scripts since they aren’t formatted in Lua. Doing so will result in an error.
I think I may have found a solution for you. Instead of fetching all of your info from Gists, you can have your game read directly off of its DataStores. Now that DataStores have API functionality through OpenCloud, you can read and change DataStore values remotely through your own tools/web services.
Currently, sleitnick is working on an API handler for easy remote editing. You can view his demo here.
Although it hasn’t been released yet, I think it will be the best/easiest option for keeping settings, lists, configurations, arrays, stats, etc. updated in your DataStores without having to open studio to make changes.
I’m quite exited for his release because I already combine his normal DataStore Editor plugin with the ModuleScript Converter plugin to handle most of all of the DataStore entries/syncs for my games. Soon that combination will be even more powerful by being able to change those DataStores on the fly. 