You’re wrong.
For C/C++ you can use this:
typedef long long int64;
int64 myVariable = 9223372036854775807;
For Java you can just use the long type:
long myVariable = 9223372036854775807;
4 Likes
I thought Roblox Staff would delete the UserId because I have been seen numbers very very big, but at least roblox can actually improve it and not cause errors and bugs.
What about just having the first 3 digits of your username and ten a random 10 digit number as your UserID? Or just removing it all-together? The thing about removing it all together is that some games rely on userid as names are changable… maybe make names that were changed identifiable by any of their previous usernames or their current?
1 Like
I was thinking about int type, not long.
1 Like
Okay, thanks for letting me know 
Quick question to any staff out there, was this updated at all related to the downtime yesterday? It seems to be related, can anyone confirm this, and did it change anything?
1 Like
Just as a note, you cannot print numbers as high as 2^50 in the current Output Window, but I do expect that to change with the new one.
Will this affect a banned players list? that rely on Username:ID
This change shouldn’t affect it because no user ID will be changed.
Your ban list should rely on the ID unless you want to specifically ban a username.
If the ban list is dependent on the ID, the player will still be banned even if they change their username.
It seems like there is some confusion as to what this will and will not do, so here is an example of exactly what is happening.
Instead of a maximum number of this:
01111111 11111111 11111111 11111111 = 2^31 (The first bit is reserved)
This equals numbers up to: 2,147,483,648
We have this instead:
011111 11111111 11111111 11111111 11111111 11111111 11111111 = 2^53(The first bit is reserved)
This equals numbers up to:
9,007,199,254,740,990
This means it shouldn’t affect anything you do with UserIDs because the number is exactly the same. Here’s an example:
01111111 11111111 11111111 11111111 = 2,147,483,648
000000 00000000 00000000 01111111 11111111 11111111 11111111 = 2,147,483,648
000000 00000000 00000000 10000000 00000000 00000000 00000000 = 2,147,483,649 <--will happen soon
The only problem comes from converting a higher bit number to a lower bit number which can only happen, typically, if you’re making webcalls and the receiving end is expecting a 32bit number. For those that are running UserIDs through an algorithm, you shouldn’t need to worry since, like shown, it is the same number.
TL;DR
You don’t need to do anything unless you’re expecting a 32bit number as a UserID in a webcall. If you are, then you need to start accepting numbers up to 54bits (I wouldn’t wait on this, since Roblox is expecting the numbers to surpass the current threshold between late December and January).
Kudos to them for giving enough time before the holidays to deal with this for the developers this affects!
7 Likes
Update:
New users will now have UserIDs over 2.2 billion. Please let us know if you see any issues around this.
24 Likes
Is there going to be any taking down of the millions of spam accounts? And if you did, could you use those userIDS, and make the UserID amount less? Sorry if this sounds weird.
1 Like
There’s virtually no reason to clear off old UserIds and assign new users them. This is based off of a nonexistent problem and has been recounted several times in this thread why it’s simply not necessary to do or desirable either. UserIds are fine to continue going up incrementally from here.
As for this, this isn’t related to what the thread is discussing. Report those accounts through the appropriate venues.
7 Likes
Great to hear roblox is growing. I think this is probs for the best, though it may lag certain games that use datastore. But I can’t think of any obvious drawbacks or ideas to get around. A question is, would this affect shirt ids/ decal ids, game ids and model ids etc?
It would be cool to have a live Player ID count that constantly documents the highest ID, just for fun.
1 Like
This is awesome, thanks so much for the warning this time. External services like RTrack could suffer from a change like this, luckily I don’t think there will be any problems as RTracks ids are always stored as 2^53.
5 Likes
No, it won’t. That’s not how datastores, or for that fact, lua works.
No, they’re on a different system and have already gone above 32 bit. There was an announcement about this quite a while back.
4 Likes
Wait a minute,
I was messing around in studio and trying to fix an old game
I was going to make a verification thing where it does
local EEE = p.UserId + p.UserId / 4
and it does it both clientside and serverside.
This would mean my system would not work on 32bit devices if I am correct
It would have to deal with numbers over the 32bit integer limit which would screw over my newest iPad.
Will this mess up systems like I am talking about with this update?
1 Like
why the crazy oddly specific number of 2147483648?
1 Like
Because computers work in a binary way (0 and 1s), it’s a 2 number-based system meaning that you only have the option to pick either 0 or 1. Roblox’s UserID worked as a 32-bit system meaning that it can compute up to 32 0s or 1s at once. And because binary operates differently than the decimal number system (which is a 10 number system), we can convert those bits into real numbers, giving you the exact number which is 2147483647.
3 Likes
Was there any reason to store IDs in signed ints in the first place? I can’t imagine that many people having negative user IDs.
2 Likes