Hi there! I’m the guy running Roblox-Client-Tracker and a few other cool open-source projects.
Since about 2015 I’ve been harmoniously live-tracking changes to Roblox. It’s been a rich set of somewhat live data that helps fill the information void on the cool things Roblox is currently working on for the engine.
Recently it was brought to my attention that Roblox is introducing some new parameters to the API that fetches information from channels:
While this project can continue with zcanary and zintegration closed, it’ll be stuck lagging behind the 2 week rollout and things won’t be as interesting and continuous. I’m of the mindset that early power users feedback in the community is useful and it’s not harmful for us to poke around with these builds.
In the 7-8 years I’ve been running this, I don’t feel my shenanigans have been perceived as a harmful thing, more a white-hat testament to my passion about Roblox and the cool stuff you guys do behind the scenes.
I totally understand wanting to cut off the people who are brute-forcing channel names to find hidden builds outside of zcanary and zintegration, but if by any chance you guys are considering a cut-off for these two channels as well, I would be grateful to see this cool niche avenue preserved.
I agree! I think it also provides anyone genuinely interested in what Roblox is working on to have general info, without Roblox having to formally announce any set-in-stone changes.
These changes being public gives the ability for people like you, not a Roblox employee, to give some level of insight onto anything that may or may not be planned for the production engine in the future. In-turn, Roblox is in no way liable for anything like that if it’s changed last minute, doesn’t make the “final cut”, etc.
For anything that needs to be explicitly internal in development, Roblox already usually uses dedicated channels that aren’t meant to be public; private channels would still be useful for this!
It doesn’t seem to do more harm than good (If any harm at all!). I personally use the client tracker to see what tools I will get to experiment and help Roblox bug test in the future.
Please keep it up!
I’m pretty sure these channels were useful for when Roblox was adding the WorldRoot:Blockcast() method. I know they’re actively working on others, but developers wouldn’t have been able to provide early input if these channels were never a thing.
I’ve personally never really used these 2 channels for anything, but I know the significance of these trackers are high, especially when Roblox Developers would like to know what may impact them in the future, or find out what cool new features they could use if they make it out of these channels and into LIVE releases.
I don’t think Roblox closing these channels is a smart decision, but that’s just me.
This tracking genuinely gives us info every week about what Roblox is up to. Changelogs aren’t very exciting, but every week I usually pop in to see the API diff!
This information is genuinely useful because I can use that knowledge to make maybe-plans (e.g. oh, Roblox is adding shapecasting so I should prepare for that when I make a new hitbox system for melee combat).
Welp, they did it, they shut off access. And they also patched my technique for getting access to studio internal. This is a pretty big middle finger to power users, but one that I unfortunately saw coming from a mile away.
Roblox is locking down most channels including zIntegration and zCanary channel later this week. We began testing this last week which is why you may have already been affected.
zIntegration and zCanary are internal tools that were never meant to be exposed publicly. We understand this may have led to some of the community to rely on them for a “sneak peek”. Unfortunately, we need to close this gap due to security. Among other benefits, this will increase internal developer efficiency, bringing you more features faster.
We always appreciate feedback on new features from the community. We hope that the creator roadmap can provide a more official avenue to give everyone an idea of what is coming and we encourage the community to use Studio Beta to preview changes and cool features. We are also open to feedback about how to make the change log better.
I’m not sure that anybody was looking for this. AB testing is incredibly annoying as I’m usually on the late end of every rollout ever. Just please add a release channel switcher instead of locking things down further.
Howdy,
For Rojo we have to maintain a list of properties and their data types or our users suffer. I used the API dumps from zCanary and zIntegration to alert me of new properties ahead of time. My ability to respond to Roblox’s changes has been harmed by the closure of these channels.
I would very much appreciate if nothing else forewarning on API changes every week, rather than having to see them as they happen. I mean internal properties too; I need to know the gritty details to maintain things properly. A lot of the ecosystem around Rojo would be improved if this were kept and released by Roblox, since we would be able to be in lock-step instead of a few weeks behind.
This is admittedly a pretty silly statement. With all due respect, how is this supposed to “increase developer efficiency”? I also can understand the security concerns of having it public, but is there a reason why can’t this be discussed with developers directly then?
Let’s not say the creator roadmap is a replacement either, it really only provides long-term plans in extremely vague, nearly useless wording. A few words and a date that usually continuously gets pushed back does not provide any vision at all. You can get more vision by toggling feature flags in Studio before release, than anything you can get anything out of that roadmap.
Like above, I am interested in more about this. I’ve been on Roblox since 2012 and I have been employed professionally in the Software Engineering industry for nearly 3 years. Given the changes locks down the upcoming potential releases of Roblox… “increase internal developer efficiency” literally makes no sense to me. I would have thought these builds would be automatically built with no engineer intervention, or be needed anyway for QA. Security I get - but please clear up this point. Right now, it feels like a generic PR point to lock down a feature a small group of power users heavily relied on.
Ultimately it doesn’t matter much, at most it puts a 1-2 week delay on seeing what’s rolling onto production.
I’m more just confused over why it matters now and not the hundreds of other times we were discovering things early. I was tipped off to it being related to PlayStation leaks, which were going to be discovered no matter how hard you tried to hide it given the iterative rollout nature of Roblox features.
It’d be cool if we could at least have access to nightly/canary builds of studio for us to catch important breaking changes in our code while we wait for Roblox to finish building a proper open source standard for manipulating their DOM. There are legitimate reasons for needing to know ahead of time when Roblox is making a breaking change, regardless if it’s internal or janky or what have you.
This just feels like a step backwards. I imagine they’ll take away the ability for us to edit FFlags and snoop Studio’s web traffic through fiddler next too, all in the name of security of course. They took away custom built-in plugins and studio internal access for that same reason. Because everything must be what is intended for all end users to see, surely no one can possibly have a legitimate need for escalated privileges.
The only good thing I could see of this is if Roblox plans to make their updates more continuous instead of weekly. Roblox’s launch on PlayStation would have gone well regardless of whether it leaked early or not.
Respect the folks who went above and beyond to shape the new developer ecosystem’s direction.
Well, to be fair, ‘private channels’ have been in the works for quite some time, being documented ‘publicly’ on the clientsettings API docs even for a few months prior IIRC. (That being shown below)
It’s likely that the reason Roblox didn’t opt for some of the “simple” suggestions you could probably come up with pretty quickly (like putting random chars in front of channel names to prevent general brute-forcing over S3) would actually require completely reworking internal tooling related to the utilization of these deployment channels regardless, which would’ve probably been more trouble than it’s worth as opposed to just fixing it all over-time for a more permanent solution. I’m sure folks on these teams do put thought into these decisions, lol.
Though, fetching deployment info on specific channels w/ forced auth on clientsettings being implemented does suck for production (“LIVE”) as ‘legacy’ version file endpoints /version (WindowsPlayer), /versionQTStudio (WindowsStudio64), /mac/version (MacPlayer), and /mac/versionStudio (MacStudio) are no longer being updated on the setup bucket which broke RDD due to CORS restricting us from accessing clientsettings locally, directly.
That’s true. I don’t understand it and I don’t “play” with this, but I know it was possible.
Roblox should make a voluntary program for users who want to take part in AB Tests, perhaps with a new tab in the settings to turn on/off a specific test. It’s better than selecting random players who won’t provide feedback or even notice the tests.
This is highly inconvenient to the Roblox on Linux community. We were relying on ZIntegration and ZCanary to predict new regressions and incompatibilities with Wine before they were pushed to production.
These new restrictions essentially mean we’re flying in blind; Roblox can completely break their compatibility with Linux in one update and we have no way of predicting it. We can only file a bug report with Roblox Engineers after it already breaks.
This removal creates a large gap. It’s essential for us to be able to do some kind of testing in a staging channel ahead of LIVE, as it’s the only way for us to catch these regressions in a timely manner.
Roblox should seriously consider providing its community with some kind of public “staging” channel, where we’re capable of preparing for changes ahead of time. Or at the very least, give trusted community members access to these channels…
Roblox doesn’t (and shouldn’t need to) to provide QA for Linux (an unsupported platform) or community tools like Rojo, but please, allow us to do our own QA. Rojo is a critical development tool for most major developers. Grapejuice/Vinegar allow an entire community to use Roblox Client and Roblox Studio. Suddenly cutting off their avenues of doing QA and catching regressions before they happen is awful and actively hurts everyone relying on these tools and programs.
I have to disagree. Having access to the development channels early allows me to find possible breaking changes with any code that I’ve written ahead of time.
I know Roblox has a commitment to backwards compatibility but without knowing ahead of time, I’m now jumping in blind not knowing if a feature is going to be dropped.
Also. If you’re going to patch out Internal Mode, please first ask developers why they were using it (besides to look cool). I had a few reasons myself.
Genuinely puzzled. Hasn’t Byfron cause incompatibilities with using Wine already, or has the community found a solution to work around with the sandboxing?
Likely, the only way the community will ever give feedback is if they’ve experienced it and had access to it. I don’t mean to complain, but some Roblox updates may not be on the creator roadmap may bring controversies and the community will be able to feedback earlier before the damage is done. I cannot give an example, but it will be for the case. Locking it down forces it to be inaccessible, therefore, developers and players do not get to have a say on what they suggest whether modifications or removal of this and that.
You do know and aware of what you’re going to do next by preventing the community from accessing.
This is often more viable than selective user testing. Selective user testing would rather select alt accounts and users with little knowledge in providing constructive critiques on features at all to rather leak and do nothing than give feedbacks on improving.
Developers, if not selected for testing purposes, also wouldn’t be able to access to earlier improve their code for Roblox’s next update which may only lead to broken codes within the next update and so little amount of time to fix before player base starts falling.
Yes. Hyperion’s release initially did not work with Linux. We caught this partially because of access to the staging 64bit client channel. Nowadays, the issue has been fixed, but every so often we still have a few hyperion-related hiccups. Thanks to zcanary and zintegration, we were able to predict these hiccups and inform both Roblox engineers and our users. This reduces a lot of downtime and buys us more time for fixes on our part, wine’s or Roblox’s.
With this change, we no longer have that luxury. Any potential issue which pops up will instantly prevent all Linux users from using Roblox, without any warning. Now we can only react to breaking changes, instead of detecting them in advance and having some preparation time.
Of course, exploit developers can use the channels to predict changes as well (likely what Roblox is referring to with their security argument), which is why I suggest allowing limited access to certain trusted users. This could potentially be done via some sort of contract, giving Roblox a legal option in case of any abuse.
Realistically, only a handful of individuals and projects have a real need for access to these channels, so why not provide an opportunity for earning it?
As much as the community wants to volunteer to maintain Rojo, Vinegar and other important community tools, we need some sort of way to predict whenever Roblox decides to change their internals… otherwise our tools and solutions suddenly become much less reliable and agile to said changes.
Roblox needs to seriously start considering their power user and tooling community and provide avenues of communication.
