Having tests done by Roblox be opt-in, with a sub-category in announcements for that here on the forum, would be great. That said, the forum is limited in numbers. With an opt-in system, no matter where the people are found, the amount participating in those tests would be far less than current.
Respectfully, can we trust Roblox to communicate about tests in subjects like in the OP, discovery, etc.? How might Roblox “do better next time”?
I want the betterment of Roblox overall in the long-term but I wonder if that is negatively impacting people in the short-term. I could be impacted and just not know as an average developer. Maybe I’m making this more of a concern than it needs to be.
Our issues stem purely from “StepContacts”, because we run enemies on the server. We only have a capsule collider for them and have turned off “CanTouch” for every part in the entire game because we don’t use touched events.
Whether we have 2 players, or 30, servers still seem to begin throttling after ~50 mobs.
(Checked using workspace:GetPhysicsThrottling)
The specific placeid is: 14819490378
(Note: this is a subplace of a universe, the start place is the main menu)
If I wanted to test how things would behave on the different frequencies, would a server script that hangs the server until certain frames (like a frame limiter) provide the same results? or does it behaves different?
I appreciate the effort put in to better the platform. I don’t currently have a way to measure the impact this has on my game. A method to opt-in or otherwise reliably test large changes such as this would be very useful. Similarly, once the impact is determined, an option to opt-out might be necessary as some have requested already.
That’s a great idea, thank you for proposing it. We don’t have a public setting for that yet. If we decide to go in that direction, we’ll provide the developers with the relevant tooling.
So after pages of people asking for improved servers, with some even willing to pay for better servers, Roblox decides to make servers worse without even informing anyone until someone submits a bug report. What a joke, an insult even
In my communities specifically this change is not a welcome one. I’ve been getting bug reports constantly about slow connection speed and slow server handled items like killstreaks and vehicles for the last few hours.
Many things like handling remote events and moving objects server-side rely on the best speed possible, and in a competitive game like ours 30 FPS isn’t near quick enough.
Hello. I am in complete disbelief. By reducing the server framerate to 30 or 10, this completely defeats any genre of games that need quick server reaction time, fast refresh rates and games that are based on accurate calculations. All FPS and military genre games, for example, need to have their server refresh rate at 60 fps exactly to run properly and avoid double bullets, or for accurate hit detection sanity check in due time.
Battlefield 4, for example, had the ability to have server running at up to 120hz. Having server run at 30 or even 10 is completely unacceptable for any games whatsoever apart from maybe RP games. How exactly are we meant to make Roblox the next hit platform with professional games when new limitations are thrown at us ?
if something like this is considered, I would believe that by default you could have the decreased frequencies but that an option should be available for developers to manually increase it.
This would make games that require fast server validation awful to play.
Fighting games, FPS games, RPG games, and many other types of games need the server fast in order to properly update for players. Imagine a bullet hitting someone in a FPS game and having an extended delay between it hitting them on your client, and the server actually doing something and making them take damage. It would feel awful.
Further more for timed inputs or other fast paced games, some code might break entirely that relies on the servers refresh rate to update in time.
If you’re looking for a way to improve the servers, deliberately limiting them is not a good option.
Maybe have a built in system to detect when a server isn’t using all of its resources, and throttle it back down to 30 with an option to disable server throttling in workspace. (key point, an option to disable, having the server constantly throttle back and fourth on a game that needs it sounds like hell)
Either or, this change only really has a negative impact on developers, and would make some genres of game start to become harder/impossible to create.
(Also please maybe make an announcement first? It’s a little disheartening knowing game breaking changes can just appear out of the blue sometimes)
I do understand why you guys would want to squeeze in as much power efficiency from the servers as possible however entirely forcing experience servers to run at 30-10 fps (without even a warning) isn’t the way to go. I’m not sure why you guys believe that making such drastic changes without even notifying anyone would not affect anyone. 9/10 times something happens.
That being said, I do like the idea of having server framerates be reduced HOWEVER the framerate reduction should be something done ONLY by experience developers! I don’t think i would mind if i could lower the server framerate in some lighter and simpler experiences however i would also want more demanding and fast-paced experiences to use a high framerate to ensure reliability. I believe adding a MANUAL framerate slider in like ServerScriptService would be best!
Would be good if devs get an advantage for using lower server update rate. A lower framerate is objectively worse for us devs, since we don’t pay the server bills (directly).
If it’s not incentivized, nearly no dev would use it. There’s simply no reason for us to deliberately choose a lower update rate.
A good motivation would be reduced profit percentage cut, but I’m just dreaming now .
Anyways, some users report issues with animations being stuck in an intermediate state. For example being partially sitting/partially standing up.
Can’t say with 100% certainty that it’s due to this, but started occuring yesterday, so most likely due to the latest Roblox update.
Shipping this without telling anyone is crazy. Roblox experiences across the board rely on physics and frequent code updates, both of which suffer heavily from this change. This should have been a survey, then it should have been opt-in with an announcement post.
This is such an obviously bad way to handle this experiment that I find it difficult to explain why. I can’t put myself in the mindset of someone who thinks this is an appropriate way to test a hypothesis. It’s such an obvious mishandling. Any developer could have told you how this would impact games.
Limited the server to 20 FPS, task.wait() goes below 0.05 but task.wait(.01) doesn’t even task.delay is affected so i guess every yielding function behaves like that, at least when limiting server FPS, would be better if they provide a way to test the different frequencies if they really go through with this idea (I personally hope it doesn’t happen)
We have stopped the experiment, and the vast majority of you should no longer experience any issues related to the experiment within the next few hours. The issue will be fully resolved for all in the next few days. Please let us know if you still encounter problems.
We apologize for the inconvenience and thank you for your patience.
For context, we started an experiment on Wednesday to test different server framerate values on RCCs. We tried values of 20, 30, and 45 FPS on small cohorts of RCC instances. This experiment aimed to explore opportunities to improve our hosting resource utilization to offer more capabilities to the developers’ community.
We have received a lot of constructive feedback from the community since the experiment started, and we are grateful to everybody who provided it. We will be better about communicating these experiments proactively in the future and welcome any feedback on the matter.
Thank you for the swift responses and commitment to improving communication over such things in the future. I’m sure that a lot of developers understand where engineering is coming from regarding these changes but they are not a right fit for the Roblox platform at this time, I feel.
I personally would not be opposed to another such experiment in the future if it means better server infrastructure and relaxing costs where required (that can then be delegated to other important areas) but if there’s no input for developers here at all, be it to configure their own server framerates or to even finance better servers themselves, this is a dangerous thing to do unannounced.
I hope that internal Roblox culture will get better at providing developers notices, tooling and alternatives FIRST before performing any backwards-incompatible changes. The platform has been crippled multiple times because of this happenstance and that can lead to time, money and audience loss for developers and the platform together. First-class citizens to Roblox need to be better respected.
Since some of our experiences have been part of this experiment, would you be able to share the summary of the results? I.e. what this means for developers based on what was learned, and explain a little more about expanding capabilities?
Im very intrigued by this, hoping we can get better performance on our train simulator. These types of games are notoriously expensive.
While my experience doesn’t seem to have been affected by this, I am absolutely baffled that no one involved in this experiment threw up a single red flag about how this was implemented.
It seems pretty obvious that this would’ve fundamentally broken a number of fast-paced games.
How does something like this get to the point of being pushed live without anyone realizing what the obvious end result would be??
This was egregiously beyond the point of “we need to do better.”
.
even task.delay is affected so i guess every yielding function behaves like that, at least when limiting server FPS, would be better if they provide a way to test the different frequencies if they really go through with this idea (I personally hope it doesn’t happen)