Hola! Here’s the release notes for 611.
89 Likes
still gonna have to use fflags because i have an uncommon refresh rate, kinda inconvenient that it cant be custom and unlimited
24 Likes
This is great but will this affect scripts that already use task.wait() or is it just a custom Input value? I don’t want to realize all my parts are spinning/moving faster usual
Edit : or just scripts using task.wait() running faster than usual too
19 Likes
WHOA!!! They’re raising the allowed FPS cap!? Is this real life!?
20 Likes
Server “framerate” is still 60Hz, so task.wait() will run the same there for now.
On client, if you raise your framerate cap, task.wait() will adjust to match.
This is specifically task.wait()–if you use something like task.wait(1), then it will still wait a full second.
You should not assume that task.wait() will take the same amount every time–even ignoring raising of the framerate cap, it will run slower if the user’s device is slower.
task.wait() returns the time that it took to run. Please use this for stuff like part spinning:
-- BAD! This will spin faster at higher framerates (which have always been possible through external programs),
-- and will spin slower when the user's device is slower.
while true do
task.wait()
part.CFrame *= CFrame.Angles(0, math.rad(1), 0)
end
-- Good!
local AMOUNT_TO_SPIN_PER_SECOND = math.rad(10)
while true do
local delta = task.wait()
part.CFrame *= CFrame.Angles(0, delta * AMOUNT_TO_SPIN_PER_SECOND, 0)
end
40 Likes
Finally.
On this topic, is there a reason why these pre-selected values are the only options and not additional ones based on your monitors? For example, 165hz/170hz monitors are becoming quite common, and I’d either need to run at a lower 144hz or waste resources at 240hz. 75hz and 90hz also exist, and so do custom overclocks (I’ve had a laptop at 70hz before).
In general, consistent wait times without an explicit value should never be assumed. They can change at any time or be system-dependent. Especially for the RunService events, you risk your scripts running faster, or more importantly slower on systems, than you designed for. Delta times or elapsed time should always be used with task.wait() (no numbers given) or RunService events.
17 Likes
I mainly only use task.wait in server scripts not in local scripts and I haven’t seen an issue before
6 Likes
Appreciate the fact that we can now change framerate settings, though i have to ask. Why wasn’t this made an option developers can work with rather than just players? I understand if this was just some really quick change that was just done for the sake of being done already but still. I believe developers should be the one in control of the framerate cap rather than just players.
8 Likes
Hope there are more options like 75/90/120/165/180/200/300/360
or a slider might be a good idea, with vysnc or gsync as an option, with buffering options as well
19 Likes
You should never assume the frame rate of players, and there is never a good reason for an arbitrary cap on player framerates anyway
7 Likes
Everything fun until you think to yourself, “i have a low-end computer, how am I going to test my experience with high-end computers”
Good work, Roblox Staff!
4 Likes
It would be great if we could adjust the value ourselves, I have my monitor set to 120Hz because the 144Hz is no longer working properly, and it would be wasteful to run at 144Hz where 24 frames will be thrown out each second. Unlimited option would be nice as well.
7 Likes
Do you really publish EVERY release?
And in the ‘About Studio’ it says its the version ‘0.611.[idk]’ I think. Yes, 0.611, is Roblox still on beta? 
(obviously just kidding)
3 Likes
Better yet:
local last = os.clock()
while true do
task.wait()
local new = os.clock()
local delta = new-last
part.CFrame *= CFrame.Angles(0, delta * AMOUNT_TO_SPIN_PER_SECOND, 0)
last = new
end
The time returned by task.wait() is the time since the function call. So, if the code between the invocations of task.wait() takes longer then the speed will decrease. Heartbeat:Wait() could also be used here as that returns the time since the previous time the event fired. (Also, it seems like you meant to use math.rad because math.deg(10) is about 573 radians per second or over 91 rotations per second)
At least a full second, it shouldn’t be assumed that task.wait(1) will wait exactly one second either.
6 Likes
It’s not really about assuming anyones framerate, more like offering developers actual control over their games. I didn’t specifically mean everyone would cap the framerates at low values, i just mean i believe developers themselves should be in charge of the clients framerate.
4 Likes
Bring the script change * indicator back please! Or at least let us keep it as an option
7 Likes
Kind of pointless unless you can adjust the framerate on other devices. (mobile, ipad, console, etc)
I’m staying with austin’s fpsunlocker until roblox outperforms him.
4 Likes
The framerate setting is available on all platforms, though I’m not actually sure what the expected highest framerate on the best devices are.
13 Likes
The block optimizations, is this only for parts with part.Shape = "Block"?
Only for primitive blocks?
168 bytes saved per block instance?
6 Likes