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.
My only assumption is that the feature was developed to protect other channels which need to be private (I remember seeing quite a few videos on unreleased features, abusing channels to gain access) and Roblox saw it as an opportunity to protect these channels too.
This privating was probably influenced by the funny debug menu that people publicly blabbered about, which then spread to Bloxstrap’s Discord server, General channel got deleted because people wouldn’t just STFU and then they decided to show everyone else and the news spread like wildfire.
People are not fun
Thankfully we still have some channels, and even a channel (zavatarteam/zavatarteam2) we have to rely on currently to get stability for Roblox on Linux all because of the current situation with crashes, extreme performance issues, stuttering, etc. Issue not isolated to Linux either! It’s affecting all of Roblox’s userbase, as shown in:
The mega thread
Channel change fixed issue
Some people on the devforums have also confirmed the channel change fixed the crashing.
Changing deployment channels to zavatarteam2 fixed it for people who run Roblox under a compatability layer, and some report that it’s fixed it for Windows users as well! (although not many people are communicating that it is, please do )
Now imagine, a build that didn’t break was deployed but was locked away, keep in mind that no real solution has even been discovered yet for this wide spread issue!
As they say, “it’s never one thing”; there are many reasons, some of which likely aren’t publicly brought to much attention now… (Very sorry about win64, to you know who)
Just to add, especially with a team/group like ours, one’s entire view on something can be changed soley by looking at different perspectives.
For me, it seems the more sources of different exposure I’m given, the more I seem to be able to logically process something from my own decision making, which is important in trying to form a personal response without soley impulse.
Additionally, we suppressed all usage of avatarteam for a reason, no idea why y’all started endorsing usage of alternative CI-purposed channels knowing the intent of auth being forced in the first place.
we were told to not talk about that debug menu but I think bloxstrap general chat actually got closed after a certain fella spammed a fflag (which got reported on the devforum and is gone now)
I think the flag you’re talking about was the funny goofy physics FPS flag that @matboff reported but the bug report was set to public and the flag was leaked and indexed by Google.
Yes, and right before got closed I remember someone kept spamming them (which no mod was there at the time) I really think that was just the final straw lol
I think it would be great if Roblox provided us with a public endpoint to retrieve changes to the developer accessable classes, methods, and functions, so that projects like Rojo could still prepare to adjust things ahead of the releases.
I think perhaps we are asking for the wrong thing by asking that non-production channels be kept open. I’ve thought about it, and I think there’s a compromise to be reached but I’m fairly certain it will never be allowing us unrestricted access to development builds.
Instead, we should probably make feature requests for what we needed these channels for. There’s a very real chance that things could work out for a lot of the use cases provided they were disconnected from the concept of “give us access to development builds of Studio”.
I know Roblox doesn’t support Linux officially, but like my other Linux friends said, this makes the future unpredictable for us and makes it extremely difficult to react before changes get pushed to LIVE. Please at least give us something to work with so we can prepare ahead of time.
Currently to fix Roblox crashing after 15 minutes, I (and many others including Non-Linux Users!) are forced to use zavatarteam2.
Please allow us some way to be able to help not only ourselves whenever there’s an issue, but also help the engineers by seeing what’s going on in the development build, and report any issues.
I (and most likely everyone else who’s participated in this thread) would like an actual explanation as to why this has happened other than “security”. We understand that there’s more going on behind the scenes. We would just want to know why you’ve actually done this.
Late reply but this is a major issue for me too. If I run into a breaking bug with my client tracker I have to get it fixed before it hits production because a lot of tools depend on my files being up to date. This will force me to drop everything and immediately address it during the middle of a work week. I might be able to quickly work around it but otherwise I’d have to scrape out whatever thing is broken and mess up the GitHub diffs. This sucks.
Issue not isolated to Linux either! It’s affecting all of Roblox’s userbase, as shown in:
The mega thread
)