Fast stupid question about uniqueID

UniqueID will be different on different servers, or if you go with a another IP?

UniqueID is like a steamid, it is per steam user.
You can read about it here.

-snip-

mistook uniqueID for just ID

Please don’t make things up, you’re going to cause confusion if anybody decides to believe you.

Not made up, just a mistake so kek yourself and type status in console.

That’s ok then buddy I forgive you, it’s weird that the two should have similar names.

Why would you use UniqueID over the player’s SteamID?

I read it, it does not say that it’s permanently

[editline]29th August 2014[/editline]

I’m not, just it useful to know.
E.G. I has ACCOUNT table in db where have all data of player: steamid, steamid64, name, uniqueid, avatar, location, etc…

Exactly UniqueID i need to export PointShop items and points from playerinfo table to my own table, but in playerinfo it saved by uniqueID. Understand my pretty English :slight_smile: ?

I’m asking what the benefit to it is, why does pointshop use uniqueid and not SteamID. It just seems easier to use uniqueid.

On my server i has CommunityID, it just primary id of account. Starts from 1 at this moment ~20k accounts

From what I know, UniqueID is also much more taxing than using just a SteamID or EntIndex (of course, if you’re trying to save info then you should use the SteamID, but still.)

Per usual, correct me if I’m wrong.

That’s the way to do it if you use MySQL. Have an accounts table which links to a characters table via accountid which in turn links to items, vehicles, etc tables via characterid.

I’m almost done writing the database query generator for the unlimited link generator. Linking 2 is already done.

– Pointshop may use unique id because of how playerpdata is stored. It is <uniqueid>[<column_name>] which is a little annoying: https://dl.dropboxusercontent.com/u/26074909/tutoring/database/converting_sv_db_to_mysql.lua.html

Why would you use the AccountID (Steam64 I’d imagine?) instead of the actual SteamID. Is there a reasoning behind this? I’ve always used the SteamID and I’ve never really had any issues with it.

This is from a post in 2013:

That’s all ply:UniqueID() is. It should never change across servers since it’s just using your SteamID.

I believe someone has stated in a different thread that ply:UniqueID() is not cached, meaning it is performing roughly that same operation above every time you call it.

If you end up using it in your projects, you should probably only run it once and store the value somewhere so you don’t keep calling ply:UniqueID() again.

As you see from the post above, the number starts from 1 and goes up, and the user has 20k accounts now meaning 20,000 should be the highest number.

So, the account id would just be an auto increment primary index named accountid or userid or whatever. steamid would be a unique field. characterid would be a primary auto index in the characters table, and characterparent which links to accounts table via userid could just be named userid, or character parent or whatever.

So when you link the tables a.accountid=b.characterparent WHERE a.steamid=“STEAM_0:1:1234” … you’re not using a unique id anywhere, you’re using the auto increment id ( although a unique id could be used in the query in the where field to get the account which then can link to other tables just by id, but I don’t like using unique id unless it is necessary, read converting the SV.DB to MySQL - and filling in data as it is known )

DON’T USE IT, it’s slow as fuck and not reversible out of gmod

Would it be better to use SteamID64()? Since it returns a string, but I believe it’s always a digit number.
I was going to move from using UniqueID indexed tables, to SteamID64. Since I keep hearing that the ID could/has changed between servers.

Yes use SteamID64. It is still a number and it isn’t a one way hash so you can reverse it and see who it belongs to. Also I actually benchmarked UniqueID recently and the overhead on it is no more than a millisecond every time but it’s still bad to use as I’ve been told that CRC32 can run into hash collision issues the more you use it.

Also you can just cache the result of UniqueID to make it plenty fast.



hook.Add( "PlayerAuthed", "uid_cache", function( ply, _, uid )

	ply.UIDCache = uid

end )

local Player = FindMetaTable( "Player" )

function Player:UniqueID()
	return ply.UIDCache
end