CD Key Character Protection

[Legacy_EzRemake]

               I know an awesome set of scripts have been written to bind player characters to CD Keys, and while I don't have a reason to not use it, I wanted to try to develop my own, mostly for the sake of learning and solidifying my understanding.

I'm wondering if my following basic scripts would be enough to protect people's characters?

On enter of an area or trigger, checks to see if PC has a storage item, and if not creates the item in the inventory and writes the player's CD key to the item

void main()
{
    object oPC = GetEnteringObject();
    string sKey = GetPCPublicCDKey(oPC);

if (!GetIsPC(oPC)) return;

if (GetItemPossessedBy(oPC, "Storage")!= OBJECT_INVALID)
   return;

CreateItemOnObject("storage", oPC);

object oStorage = GetItemPossessedBy(oPC, "Storage");

SetLocalString(oStorage, "CDKey", sKey);
FloatingTextStringOnCreature("CD Key Bound To Character!", oPC);
}

Then we have the on client enter, which checks to make sure that the current CD Key matches the one stored on the characters storage item. If the item doesn't exist, it assumes it is a first log, otherwise it does the check. If the check fails, the player is kicked.

void main()
{
    object oPC = GetEnteringObject();
    string sKey = GetPCPublicCDKey(oPC);
    object oStorage = GetItemPossessedBy(oPC, "Storage");
    string sCDKey = GetLocalString(oStorage, "CDKey");

    if (GetItemPossessedBy(oPC, "Storage")== OBJECT_INVALID){
        FloatingTextStringOnCreature("First Time! Registering CD Key!", oPC);
        return;
        }

    if(sKey == sCDKey){
        FloatingTextStringOnCreature("CD Key Authenticated!", oPC);
        }
    else{
        BootPC(oPC);
        }
}

I know it is very simple, but is it effective? I've tested it by myself and it seems to work. What would the disadvantages to using this be, other than not being able to store multiple keys?
               
               

               

                     Modifié par EzRemake, 01 octobre 2013 - 06:34 .
                     
                  

            

[Legacy_Lightfoot8]

               Major disadvantage to me would be that you are protecting the character and not the players account.
So every time a player logs on with there Player name you have No idea if it is she same person or someone else.     It is better to protect the Player account in my book then to protect just single characters in that account.
               
               

               
            

[Legacy_FunkySwerve]

               I'd suggest that, if you want to hone your skills with your own script, to just use the posted one in the General forum sticky as a basis. There's plenty of room for improvement in it, especially if you're using NWNX databasing. The table structure I used is pretty klunky because it's designed for plug n play use by builders. Consider, for example, using a separate table for the playername-key bindings, skipping the 'PlayernameKey' appelation entrely, and just doing columns playername, keys, last ('last' being for last modified date). You might or might not need another column for 'adding' depending on how you do it.

Most publicly-posted scripts have lots of room for improvement like that, and using one as a basis can help you avoid some not-too-obvious pitfalls.

Either way, recoding our bindings to a new setup is on my long-term todo.  I coded the original a looooong time ago, when I wasn't yet comfortable with MySQL, so I used the default table packaged with NWNX. Works great for people in that position, as a result, but also has lots of room for improvement. Another possibility is something I've been toying with in my head for a while now - one of my big non-development NWN timesinks is allowing playings access to their old playernames after a long absence (usually by setting the 'tag' column to 'Adding'). In such cases, chances of theft are more remote, since other players have likely not seen the name around. If you were to add another DATE field tracking last login (or have one in another table you could join), you could check against last login and auto-admit, given enough passage of time...not entirely problem free, but a place to start thinking.

Funky