Points by SteamID

[Angry Jonny]

Hi, guys. I found ulx command to give points by name. Can somebody remake it for steamid, please?

Code: Lua

1. function ulx.givepoints( calling_ply, target_ply, points )
2.                
3.         target_ply:PS_GivePoints(points)
4.         ulx.fancyLogAdmin( calling_ply, "#A gave #i points to #T", points, target_ply )
5.  
6. end
7. local givepoints = ulx.command( "Utility", "ulx givepoints", ulx.givepoints, "!givepoints" )
8. givepoints:defaultAccess( ULib.ACCESS_ADMIN )
9. givepoints:addParam{ type=ULib.cmds.PlayerArg }
10. givepoints:addParam{ type=ULib.cmds.NumArg, min=1, max=10000, default=100, hint="points", ULib.cmds.optional, ULib.cmds.round }
11. givepoints:help( "Give points for PS to players" )

Edit by Megiddo: Fixed code block

[iViscosity]

Not sure if it will work right off the bat, as I'm not familiar very much with PS and how it accepts targets, but just try target_ply:SteamID():PS_GivePoints(points)... maybe that will work..

[roastchicken]

I'm pretty sure he wants a way to specify the SteamID iViscosity. There's no reason to get the player's SteamID if they're online.

That being said, I'm pretty sure this isn't posible. Pointshop 1 (by _Undefined, I assume that's the pointshop you're using) uses PData which indexes by UniqueID. UniqueID is only available while the player is online, so you can't make it work with arbitrary SteamIDs. The only possible solution I can imagine is creating a table that links SteamIDs with UniqueIDs.

[Bytewave]

Not sure if it will work right off the bat, as I'm not familiar very much with PS and how it accepts targets, but just try target_ply:SteamID():PS_GivePoints(points)... maybe that will work..

Can't do that. You'd just be trying to call PS_GivePoints() on a string.

The only possible solution I can imagine is creating a table that links SteamIDs with UniqueIDs.

Which is a problem, because unique IDs do have collisions in some cases.
<grumble>Why did garry have to roll his own unique ID system when SteamIDs are 100% unique already???</grumble>

[roastchicken]

Yep. UniqueID's are terrible. I wish Garry or some other dev would just bite the bullet and phase them out. Make a native UID/SID table and just map UniqueID to SteamID.

[Bytewave]

Yep. UniqueID's are terrible. I wish Garry or some other dev would just bite the bullet and phase them out. Make a native UID/SID table and just map UniqueID to SteamID.

But because we're so far down the line, you'd break backwards compatibility.
UniqueID has its purposes, but not so much anymore. SteamID32/64/3 are guaranteed to be unique, but SteamID64 is the only one of those that is numeric, and it's 64-bit (though, really, that matters very little these days).  UniqueID is already used in so many places that it'd be difficult to change it. UTime even uses UniqueID, iirc, but don't quote me on that.

I am an advocate of depreciating UniqueID now that much better alternatives exist. But it can't be stripped entirely.

/ot

edit: The same issue of collisions exists with a global redirect table. Don't forget that.

[roastchicken]

Why doesn't a redirect table work? UID->SID64. Net messages might break, but that's easy enough to fix. I can't think of anything else where the size of SID64 vs UID would matter. Sure, collisions still exist. But it's still better than keeping UID.

It would have been nice if Garry hadn't made UID in the first place, but we can't change the past. It might not be the most graceful change and there may be some bugs that are caused by it, but the same thing happened (on a larger scale, I believe) with the shift to Garry's Mod 13.

With all that said, I highly doubt the devs will do anything about Unique IDs. Oh well, I can hope.

[Bytewave]

Why doesn't a redirect table work? UID->SID64. Net messages might break, but that's easy enough to fix. I can't think of anything else where the size of SID64 vs UID would matter. Sure, collisions still exist. But it's still better than keeping UID.

It would have been nice if Garry hadn't made UID in the first place, but we can't change the past. It might not be the most graceful change and there may be some bugs that are caused by it, but the same thing happened (on a larger scale, I believe) with the shift to Garry's Mod 13.

With all that said, I highly doubt the devs will do anything about Unique IDs. Oh well, I can hope.

A redirect table won't work because of the collisions issue.
CRC32 is highly prone to collisions--it's made for verifying message integrity over lossful network streams, not storing unique data.
Plus, how do you make a redirect table? Do you iterate over every possible SteamID? What if the spec changes for SteamIDs? Do you do it dynamically?
A redirect table would only end up being a cache of sorts anyway.

Another issue with the redirect table is that databases will expect numeric values for UIDs, not string values, which is what the UID is constructed from (see the wiki page). So the redirect table would have to map SID64 to UID, which isn't too impossible... until you realize that they're both numbers, and how would you tell them apart? Which one of these is a UID? Which one is a SID64?

There would be plenty of bugs. Addons like UTime use UniqueID internally, and changing that would break the entire UTime database without going through and updating every record to SID64, which you cannot do without having the players online. And there's no way you're going to get every player ever to join your server, and you likely won't want to reset your entire UTime database, especially with a larger community.

We're so far down with how long UID has been in the game that it would be detrimental to remove it now. Perhaps following some major release, sure, but do you see a major GMod release down the pipeline anywhere?

[roastchicken]

A redirect table won't work because of the collisions issue.
CRC32 is highly prone to collisions--it's made for verifying message integrity over lossful network streams, not storing unique data.

Collisions exist already, without a redirect table. A redirect table can't make the collision problem any worse.

Plus, how do you make a redirect table? Do you iterate over every possible SteamID? What if the spec changes for SteamIDs? Do you do it dynamically?
A redirect table would only end up being a cache of sorts anyway.

I was thinking of just storing the UniqueID and SteamID64 of every player that joined. I guess 'cache' might be a better word for it.

Another issue with the redirect table is that databases will expect numeric values for UIDs, not string values, which is what the UID is constructed from (see the wiki page). So the redirect table would have to map SID64 to UID, which isn't too impossible... until you realize that they're both numbers, and how would you tell them apart? Which one of these is a UID? Which one is a SID64?

Why do you need to be able to tell them apart? If you're unsure, try using it to visit a Steam profile (http://steamcommunity.com/profiles/<SID64>); if it doesn't work, it's not a SteamID. As for doing it programmatically, there are functions to convert between the two SteamID formats and I'm pretty sure they just return false if it's not the correct format.

There would be plenty of bugs. Addons like UTime use UniqueID internally, and changing that would break the entire UTime database without going through and updating every record to SID64, which you cannot do without having the players online. And there's no way you're going to get every player ever to join your server, and you likely won't want to reset your entire UTime database, especially with a larger community.

The whole idea with a redirect table is to, well, redirect. Player:UniqueID() would just return the player's SteamID64.

We're so far down with how long UID has been in the game that it would be detrimental to remove it now. Perhaps following some major release, sure, but do you see a major GMod release down the pipeline anywhere?

I think the pros outweigh the cons, but I agree that the developers would probably only make a large change like this in a major release. Maybe in GMod 2, if they ever make it.

[Bytewave]

Collisions exist already, without a redirect table. A redirect table can't make the collision problem any worse.

But it can't make it any better, which is the whole point.

I was thinking of just storing the UniqueID and SteamID64 of every player that joined. I guess 'cache' might be a better word for it.

Collisions would be an issue, again. What if two players have the same UniquieID? How do you account for that?

Why do you need to be able to tell them apart? If you're unsure, try using it to visit a Steam profile (http://steamcommunity.com/profiles/<SID64>); if it doesn't work, it's not a SteamID.

That's a whole lot of HTTP requests if you're doing that in code.

As for doing it programmatically, there are functions to convert between the two SteamID formats and I'm pretty sure they just return false if it's not the correct format.

They can't distinguish typically. There is no "correct format" for an incremented number.

The whole idea with a redirect table is to, well, redirect. Player:UniqueID() would just return the player's SteamID64.

Code: Lua

1. database:query("SELECT * FROM players WHERE `uniqid` = " .. ply:UniqueID() .. " LIMIT 1")

now fails every time.

I think the pros outweigh the cons, but I agree that the developers would probably only make a large change like this in a major release. Maybe in GMod 2, if they ever make it.

Pros outweigh the cons only when you don't account for backwards comparability.
At this point, they have no choice but to deprecate now and remove in a major release should they remove it. It's been in the game too long for it to be viable and non-breaking to remove it now.

[roastchicken]

But it can't make it any better, which is the whole point.

I think of it as more of a stepping stone in the right direction, to ease into the removal of UniqueID.

Collisions would be an issue, again. What if two players have the same UniquieID? How do you account for that?

You don't. Again, I'm not trying to circumvent the current problems of UniqueID. I can't do that with a collision table. It's going to have the same problems UniqueID had before.

That's a whole lot of HTTP requests if you're doing that in code.

As for doing it programmatically, there are functions to convert between the two SteamID formats and I'm pretty sure they just return false if it's not the correct format.

They can't distinguish typically. There is no "correct format" for an incremented number.

I'm 99.9% sure that neither UniqueID nor SteamID64 are incremented numbers. Normal SteamID, sure. STEAM_0:0:1 still has a large number (76561197960265730) for its SteamID64. As for UniqueID, you mentioned CRC which is a hashing function (i.e. is not incremented).

Code: Lua

1. database:query("SELECT * FROM players WHERE `uniqid` = " .. ply:UniqueID() .. " LIMIT 1")

now fails every time.

Okay, I guess a lot of systems that increment by UniqueID will fail. But PData should still work, which I guess is a plus.

Pros outweigh the cons only when you don't account for backwards comparability.
At this point, they have no choice but to deprecate now and remove in a major release should they remove it. It's been in the game too long for it to be viable and non-breaking to remove it now.

The reason I suggest a redirect table is so that there isn't a huge jump where all the systems that use UniqueID fail. I understand that a large percentage of those that use UniqueID by itself instead of PData will now fail, but at least they'll have something to fall back on instead of having a million different UniqueID to SteamID/64 tables for each addon that used UniqueID in the past.