Legacy:Uniquely Identify A Player

This page is concerned with how you can identify players uniquely. It is a work in progress, so please look for gaps in the information here and, if you can find time, do small experiments to check and discover facts.

Introduction

Within the game, each connected player has a single PlayerController created. Thus, if you do a forallactors on the PlayerControllers then you get all the players who are present. But what if you want to hold on to information about a particular player after they quit, for instance Sweavo/MutYouDontQuitThatEasy attempts to hold your score until the end of the current game, even if you quit and rejoin.

GetPlayerIDHash()

PlayerController((TeamPlayerReplicationInfo(X).Owner).GetPlayerIdHash()) will return the player's CD Key, or GUID. These are intended to be unique for every installation of the game. There are a few exceptions/caveats.

Stolen IDs

Looking at the Admin forums, there are cases of very unscrupulous individuals managing to steal the CD Keys of legitimate users. In these cases the admins are not sympathetic to the victim because there is no way to tell whether that person is really the victim or the perpetrator.

GUID 5857a730b66505da430f3bef2b845c38

Although each installation CD has its own unique GUID, the game is deliberately set up to switch GUID to this particular value if the player changes certain settings. See DeveloperMode for an explanation. It's best to simply not allow this GUID on your server. The player will get their own GUID back when they restart their client.

Multiple players using one installation

It's not uncommon for relatives or roommates to connect from different computers at one location using the same copy of the game. Usually this results in one player showing up as "Player" in the game. As a coder wishing to uniquely identify players you have a choice of what to do here:

• Refuse a connection to a session whose GUID matches a GUID that is already playing
• Identify players by GUID appended with an integer which is 0 for the first session, 1 for the next, etc. This is not straightforward to do, but could lead to offering multiple profiles to a player with a given GUID
• Ignore the problem. I don't recommend this as you will get "race conditions" where Player1a joins, Player1b joins, and both alter their account in some way. Whatever player quits last will keep their changes and the other will lost theirs.