the server is probably not up to date yet or your client is not
2 Likes
No; it’s reporting as 651 and the issue persists after restarts.
4 Likes
It seems like this update changed the behavior of os.clock(), to return the time since the Roblox instance has been running, rather than the CPU time as it was before. This behavior caused our whole 50k CCU game to break 
would appreciate a warning next time!
10 Likes
for plugin autocomplete they said
1 Like
This caused my systems to break as well. I would appreciate if they gave us an alternative, rollback or workaround. My game doesn’t run without it.
2 Likes
Sorry about the inconvenience this change caused. We took some measures to detect places that might be impacted before making the change, but our detection wasn’t perfect.
Our documentation for the function (os | Documentation - Roblox Creator Hub) says the following:
Returns elapsed time in seconds since an arbitrary baseline with sub-microsecond precision. This function is useful for comparing durations between two events that occur on the same computer, and is the best option for benchmarking.
Therefore relying on a particular baseline from which the time is measured is relying on undefined behavior.
Still, we understand that given the large number of experiences out there it is possible a small number could be impacted by the change. So again, we are sorry for problems we introduced, but we needed to roll this change out fairly quickly for various reasons.
7 Likes
I understand the reasons for it, especially given the privacy intrusions it’s allowed for earlier, but I’d have appreciated if there was any heads-up or notice sent to creators beforehand. Would have been less spooky for us to try and figure out 
6 Likes
Just curious: what exactly was os.clock being used for? I’m assuming that the server instance starts some seconds later than the CPU clock does.
1 Like
The way it worked allowed for user fingerprinting. A game that used it could easily identify alts as long as they didn’t restart the computer between switching accounts. The changes to os.clock has patched this, which is good (but annoying for those relying on it) since it is a privacy invasion. It also grouped together different people using the same computer (ex: siblings).
10 Likes
Not quite. We are thinking about scripts that can run at edit time (but are not plugins), though! These would allow you to do things like bundle relevant place tooling with the place itself, or include scripts with a model (i.e., parametric stairs).
7 Likes
To allow for easier development of plugins (scripts that are intended to go into plugins won’t run outside of them), as well as to enable us to unify plugin scripts’ behavior with normal script behavior, but without breaking existing experiences. Examples of some fixes include the enabled/disabled property working with plugin scripts, as well as them now properly restarting when cloned (within an Actor, for instance). Relatedly, if we can fix autocomplete of the plugin global, it will likely happen under the Plugin RunContext.
8 Likes
this one is a needed one finally
1 Like
That’s exactly what I’d be excited for!
2 Likes
Pretty inconvenient patch for most experiences.
I used to rely on os.clock to identify alt accounts of those who were exploiting and issue a 24 hour ban (longer bans could cause false-positives) on the fingerprint and use it in conjunction with the BanAPI alt detection.
Now I have to wait for Roblox to fix their alt detection, frustrating.
7 Likes
What if you wanted this?
This is a good thing, the new alt detection barely works. I don’t see why this is a privacy invasion; the new alt detection attempts to do the same thing. Here’s an obvious use case multiple developers used.
Also, this had no prior warning (from what I heard) and developers had no prior warning that this change would take place, breaking entire games.
1 Like
Why do you want that?! 1 person doing something to get banned should never warrant an unrelated person being banned as well.
This “exploit” to get reproducible hardware ids allows you to form groups of accounts that share systems. It can be a privacy concern to know alts (ex: popular YouTuber has a no-name alt nobody knows to avoid being swarmed) and relatives (ex: siblings who share computers, or public computers in schools/libraries/stores). Remember that this isn’t just for use with banned users; you can track this for anyone (and I assume many did to catch alts of banned users from previous sessions).
While this hopefully didn’t happen, because these hardware ids worked between games, multiple games could have shared these to link different accounts (again, ex: siblings) together even if they never played the same game.
(All of this might also be against section 11 of the Terms of Use, by the way. I never got a clear answer for this because that is a legal question, and my contacts could not give legal answers.)
3 Likes
Trust me, I know devs who would ban entire households if they had the option.
I don’t even know why I even sent that since it was pretty obvious lmao. This doesn’t give you hardware ID’s.
It’s still unfortunate this got removed since now there’s zero way to know if someone is alt-farming or actually ban alts (since the ban API sucks lol)
2 Likes
play stupid games, win stupid prizes
But seriously, never rely on hacky methods to create systems such as that. I’m pretty sure fingerprinting users might even be a breach of the rules but don’t quote me. For something as low level as that function it’s never a good idea to rely on certain behavior especially when it could change depending on platform or device.
5 Likes