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.
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.
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
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.
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).
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).
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.
this one is a needed one finally
That’s exactly what I’d be excited for!
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.
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.
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.)
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)
Adding onto this:
In our experience people would get their account deleted, hacked or lose access to them and ask us to just move the data to another account instead.
Previously we were manually checking if device identifiers matched with both accounts to verify if they were actually owned by them and later moving that data to their new account.
We did this because Player appreciation is critical in small experiences.
This change made it so we have to jump more hoops to verify if these accounts were actually owned by said parties.
Developers should have access to such unique identifiers, these privacy concerns way surpass the functionality said identifiers allow developers.
Picture this: An experience could link a well-known scammer’s alt-account to their main account and warn its players before trading items between.
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.
Fingerprinting is definitely a privacy violation because it allows you to build a profile of a person. It might even be illegal in some cases if you aren’t careful, especially wrt young children who have very powerful data protection laws and rights.
It isn’t a problem when Roblox does alt detection because Roblox can take all the necessary steps to avoid infringing on data protection regulation for kids, and can safely encapsulate all of that away from devs who might not be aware of such limitations.
Updating retargeting cache so it doesn’t cache procedural rig modifications. This could result in broken looking animation in some experiences.
animations in our game are ruined atm, LowerTorso / Root movement is messed up.
this only happens in studio and not in-game, and seeing this is the only animation-related fix in the past week, and the fact it’s not live yet made me suspect this might be the culprit of this sudden change.
any ideas on how to fix this issue? we are using a skinned rig (motor6ds, no bone instances) and we don’t use procedural animations
wondering if this is related here…started impacting live game(s)
The animations in our game messed up out of nowhere. The left cat is the animation we’re getting, and the right one is what it should look like (and what it looks like in AnimationEditor). I’ve tried everything (stopping all animations in a character and just playing the animation, and it’d still happen). I don’t know how but the right cat is playing correctly. But when I use that same cat as a StarterCharacter I get the problem of the left cat (even though it’s the same cat). I genuinely don’t understand what’s going on, it is clearly an issue from roblox’s end, I’ve tried older versions of my game and this problem still happens. The animation hasn’t changed or been replaced at all.
PS: Reuploading animation didn’t work. I’ve anchored and uncollided the rig and it’d still do the same thing, so it’s not a result of physics. Pretty much i’ve tried everything to see if something was interfering with the animation (stopping other animations playing at the same time, anchoring, collisions, etc…). It simply does not play the same animation that you would see on the Animation Editor, and it looks like the root / LowerTorso movement is messed up