Roblox Client Tracker: a weekly diff of what changed in the Roblox client

What the repository is, and how it produces its data

The Roblox Client Tracker is an unofficial change tracker which aims to provide detailed diff logs for changes to Roblox's engine. The way it works is by datamining builds of Roblox Studio retrieved from their CDN, using various publicly discovered developer channels of Roblox, and the data analysed and presented in the repository is generated using publicly reverse engineered Roblox protocols and file formats. That is a precise description of the method, and it is worth noting what follows from it. The repository is a machine output, not a curated document, and the primary language listed for the project is Assembly, which is the language of the client being disassembled rather than of the tooling. The backend console application which drives the repository lives in a separate repository, RCT-Source.

The API dumps, and the difference between them

Three files cover the scripting surface, and they are not redundant. API-Dump.json is a JSON version of Roblox's API Dump, containing more data than the original, and it can be read into a data tree by most programming languages using a JSON parser. It is extracted with the -API flag passed to the Studio executable. Full-API-Dump.json is a more complete version of the normal JSON dump, including all classes and enums omitted from the normal dump, plus other differences such as Default values on some properties, extracted with the -FullAPI flag. API-Dump.txt is a readable version of the JSON dump, generated from a separate API Dump Tool project rather than extracted directly, and the repository also ships a Mini-API-Dump.json alongside these. For anyone working with Roblox internals, the Full dump is the more useful of the two, since the omitted classes are usually the ones that are awkward to work with.

The manifest files, and the URLs that produce them

The manifest files are the part that describes what is actually in a client build, and they are fetched over plain HTTP from the setup CDN. rbxPkgManifest.txt describes which zip files should be fetched from Roblox's Amazon S3 bucket, and it can be fetched at the version and GUID address or at the channel variant of it. rbxManifest.txt describes almost every file expected to be extracted from those zip files, and every two lines correspond to a local file path and the MD5 checksum expected of the file extracted to that path. Its URL includes a GUID placeholder, so the actual address has to be assembled with the version and GUID values from the version files. rbxManifest.csv and rbxPkgManifest.csv are CSV versions of the two text manifests, made to be easier to read from GitHub, which is a small concession to the fact that the text files are large and a diff view of them is not pleasant.

The package manifest format, decoded

The format of the package manifest is documented, and it is a good example of a reverse engineered file layout being written down properly. The file starts with a line describing the version for the package manifest schema, and after that version, information about each file is listed sequentially.

File.ext
MD5 Checksum
Compressed Size
Decompressed Size

So a file entry is four lines rather than one, which is why the manifest says every two lines of the other manifest correspond to a path and a checksum. The alternative URL for the manifest, with the FileName placeholder at the end, covers the case where you already know which single file you want rather than the whole index.

The files that reveal how the client is built

Four files in the repository are about the internals rather than the API. CppTree.txt is a sorted list of undecorated C++ symbol names that could be extracted from the executable, which is the closest thing to a map of the client's internal structure. DeepStrings.txt is a sorted list of dumped strings from the Studio executable, where the project notes there is some garbage in it but most of it should be legible. FVariables.txt is a sorted list of fast variables, which the project explains are used by Roblox to toggle changes to the engine remotely on multiple platforms without having to redeploy the client, which makes them the single most operationally interesting file in the set. And LuauTypes.d.luau is a manually declared set of Luau types created by engineers at Roblox, which are baked into RobloxStudioBeta.exe.

Shaders, plugins, resources and the rest of the tree

RobloxShaderData.csv maps all of Roblox's known shaders and which graphics APIs use them, with a mapped name and a shader type for each. The rest of the top level shows the scope of what gets extracted. There are directories for BuiltInPlugins and BuiltInStandalonePlugins, LuaPackages, CompiledPackages, QtResources, shaders, studio-svg-textures, textures, translations, avatar, configs, api-docs and scripts, plus ReflectionMetadata.xml and RobloxStudioRibbon.xml for the client's reflection data and its ribbon interface. The presence of the translations and QtResources directories is the sort of detail that makes the repository useful for localisation and platform work rather than only for API research.

The version files, and how two builds are told apart

Two small files identify the build, and the format of one of them is worth reading closely. version.txt describes the current version of Roblox Studio and is formatted as major revision, version, patch, and then a component described as the Perforce changelist version multiplied by 1000 plus the number of commits in that version, with the changelist part struck through in the description because it is no longer available. version-guid.txt describes the current GUID version of Roblox Studio, and the GUID is the second half of the placeholder in the manifest URLs, so these two files together are what you need to build a download address. There is also a version-history.json, which is what makes the repository a tracker rather than a snapshot, since the weekly diffs are the actual product here.

Editorial conclusion

Roblox Client Tracker fits a Roblox developer who wants to know what changed in the engine this week, especially someone writing a native module or a tool that depends on internal behaviour, because the dumps are generated from the shipped Studio build rather than described in a changelog. It does not fit a player or a Roblox web developer, since the data is about the internals of the desktop client and none of it is a supported interface. It also does not fit anyone who needs the data to be a stable contract, because the whole point is that these files change every week and the project is explicitly an unofficial change tracker. Before you build a tool on top of it, diff two consecutive weeks first, and read the version file format carefully, because the build number encodes the Perforce changelist and the commit count, which is how you tell two builds apart.

Frequently asked questions

Official sources

1. Issues
2. MaximumADHD/Roblox-Client-Tracker on GitHub
3. README