Use LocalPlayer():SteamName() instead of Nick()

[Edned]

Hello, I was wondering if it was possible to change the way that ULX broadcasts the chat commands and stores bans in DarkRP. For example, if someone changes their RP name it will use their RP name and not their steam name when broadcasting messages in chat such as "Admin RP Name" has Banned "Other guy's RP Name" for etc.
It's really annoying because I would rather it use the SteamNames rather than RP Names.

Thank you in advance!

[Megiddo]

I'm fairly certain there would be no way to figure out the player's "real" name without making some kind of Steam API call. That's the danger of overriding functions like DarkRP does.

[Edned]

There is
There's actually a variable with the player's SteamName in called "SteamName()".
Here is a snippet from my Scoreboard row:

Code: [Select]

fetch = function( ply ) return ply:SteamName()I was wondering if I could use SteamName() instead of Nick() for ULX somehow?

[JamminR]

EdNed, are you absolutely sure SteamName is a Gmod lua function from Gmod itself, and not another addon's (including your scoreboard??)
Though the wiki isn't always up to date, I can't find it on the Gmod Wiki.
http://wiki.garrysmod.com/index.php?title=Special%3ASearch&profile=advanced&search=SteamName

Additionally, to be honest, I believe the request you're making goes 'against' what most people want to see when commands come across the echo and logs.

[MrPresident]

SteamName() is not a gmod lua function.
As far as I know, there is no way to get a Steam community name for a player without doing some fancy http fetch calls using the steam API.

[Edned]

Sorry, I forgot to mention that it was a built-in DarkRP function; located here: http://wiki.darkrp.com/index.php/Functions/Player/Shared/SteamName

[Megiddo]

In general, we try to generalize ULX to any/all gamemodes. We rarely do something that only applies to a non-standard gamemode. Especially given the questionable choice of misrepresenting a player's name in the first place, adding this would go against many of our development principles. Sorry, but we simply cannot support something like this.