[GXLZPGX]

ID System v1.00

What is this?

As coders, you might have ran into a few problems in the past with the current ID system, which works, but to an extent.

Ex. You have 3 players in a server. Each player assigned a specific ID based on when they joined.

Player 1: ID 1
Player 2: ID 2
Player 3: ID 3

Now let's say Player 2 disconnects, and you're left with the original first and third player. Their ID's will stay the same, but there will only be 2 players, so:

Player 1: ID 1
Player 2: ID 3

See the problem? Now, with this new system, I'm not sure exactly what YOU might use it for, but for me, it was necessary when flipping through the players in order.

Ex: Round 1, player 1 received 150 HP. Round 2, player 2 received 150 HP, etc.

Well if I'm flipping through their ID's, and I get to ID 2 (when player #2 disconnected and there IS no player in that slot, it creates ID problems, which are unneeded)

Why not just skip that ID if the player doesn't exist?

Basically, I want a fair system. With the current system, if a new player joins, they would take the second slot, even though the first and third person were the original two. Which would basically give Player 3, which is ID 2 (now that they've taken the ID 2 because it's available), 150 HP, though they haven't waited as long as ID 3 has.

How EXACTLY does it work?

This system fixes the problem by reassigning ID's (not literally). It creates a new variable to hold new ID's.

Example of the system:

Player 1: ID 1
Player 2: ID 2
Player 3: ID 3

Player 2 disconnects, ID's are now:

Player 1: ID 1
Player 3: ID 2

Converting player 3 to player 2 (technically, because we are switching his ID)

Player 2 reconnects:

Player 1: ID 1
Player 3: ID 2 (Technically player 2 now)
Player 2: ID 3 (Now officially player 3)

I apologize if any of this is confusing.

Code Preview

PHP Code:

/* Bullet Proof ID System by Shadow (aka GXLZPGX) */

#include <amxmodx>

#define PLUGIN    "Bullet Proof ID System"
#define AUTHOR    "Shadow"
#define VERSION    "1.0.0"

new cPlayers;
new aID;
new eID[33];
new pID[33];

public plugin_init()
{
    register_plugin(PLUGIN, VERSION, AUTHOR)
    
    //deathmsg
    register_message( get_user_msgid( "DeathMsg" ) , "pDeathMsg" );
    
    //check id
    register_clcmd( "say /id", "pCheckID" )
}

public pCheckID(id)
{
    new menu = menu_create("\r[ID List] \wPlayers", "menu_handler");
    
    new iPlayers[32], iNum, tempid;
    new szName[32], szTempid[10];
    
    get_players(iPlayers, iNum);
    
    for( new i = 0; i < iNum; i++ )
    {
        tempid = iPlayers[i];
        
        get_user_name( tempid, szName, charsmax(szName) );
        num_to_str( tempid, szTempid, charsmax(szTempid) );
        
        new szMenuItem[64];
        formatex( szMenuItem, charsmax(szMenuItem), "%s \rID: %i", szName, eID[tempid] )
        
        menu_additem( menu, szMenuItem, eID[tempid], 0 );
    }
    
    menu_display(id, menu, 0);
}

public menu_handler(id, menu, item)
{
    if( item == MENU_EXIT )
    {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }
    
    new data[6], szName[64];
    new access, callback;
    menu_item_getinfo(menu, item, access, data,charsmax(data), szName,charsmax(szName), callback);
    
    new tempid = str_to_num(data);
    
    if( is_user_alive(tempid) )
    {
        pCheckID(id)
    }
    
    menu_destroy(menu);
    return PLUGIN_HANDLED;
}

public client_putinserver(id)
{
    aID++;
    pID[aID] = id
    eID[id] = aID;
    cPlayers++;
}

public client_disconnect(id)
{
    set_task( 0.1, "pNewIDs" )
    cPlayers--;
}

public pNewIDs()
{
    new iPlayer[32], iNum, nID;
    get_players( iPlayer, iNum )
    
    aID = 0;
    
    for( new i = 0; i < iNum; i++ )
    {
        nID = iPlayer[i];
        
        aID++
        pID[aID] = nID;
        eID[nID] = aID;
    }
} 


[xPaw]

Basically, I want a fair system. With the current system, if a new player joins, they would take the second slot, even though the first and third person were the original two. Which would basically give Player 3, which is ID 2 (now that they've taken the ID 2 because it's available), 150 HP, though they haven't waited as long as ID 3 has.

The problem is that author of "150 HP" feature is dumb, and doesn't reset timers/features/bools upon player disconnect.

This is absolutely redundant.

[GXLZPGX]

Originally Posted by xPaw The problem is that author of "150 HP" feature is dumb, and doesn't reset timers/features/bools upon player disconnect. This is absolutely redundant.

I'm not actually setting the players health to 150 in this topic, this topic simply shows you what you can do with the new system.

[xPaw]

Originally Posted by GXLZPGX I'm not actually setting the players health to 150 in this topic, this topic simply shows you what you can do with the new system.

I was referring to your example. Is there any REAL use with your new system?

[GXLZPGX]

Originally Posted by xPaw I was referring to your example. Is there any REAL use with your new system?

I'm expecting people to create their own uses for it. It is simply up to coders to use this to whatever advantage they seek necessary.

[xPaw]

Originally Posted by GXLZPGX I'm expecting people to create their own uses for it. It is simply up to coders to use this to whatever advantage they seek necessary.

I don't see any advantage in your system.

[GXLZPGX]

Originally Posted by xPaw I don't see any advantage in your system.

I wouldn't call it an advantage, just an improvement on something that needs to be more organized. Removes gaps between players and their ID's.

For example, those who like to select random players will no longer have to use a filter to check if the ID actually belongs to anyone, removing the need to check if there is a player with that ID such as what is needed in this code:

PHP Code:

public SelectRandomPlayer()
{
    new iPlayers[32], iNum, id;
    get_players( iPlayers, iNum )
    
    id = iPlayers[random(32)]
    
    if( !IsPlayer(id) ) //if they aren't a player
    {
        SelectRandomPlayer() //Forced to run again because there isn't a player with that ID
    } else {
        //do what you need to if there is a player with that ID
    }
} 


Small things like that which make your code easier to navigate through. They can now use something along the lines of:

PHP Code:

public SelectRandomPlayer()
{
    new rPlayer = pID[random(cPlayers)] //chooses a random connected player. rPlayer being a random player, cPlayers being the players currently connected.
    
    //do what you need to do to the ID, because you know for a fact it already exists.
} 


Removes the middle man, making your code easier to read. The only thing you may need to do is create a filter to check if they are a bot or not, depending on whether or not your code requires it to be an actual player.

[Emp`]

Originally Posted by GXLZPGX I wouldn't call it an advantage, just an improvement on something that needs to be more organized. Removes gaps between players and their ID's. For example, those who like to select random players will no longer have to use a filter to check if the ID actually belongs to anyone, removing the need to check if there is a player with that ID such as what is needed in this code: PHP Code: public SelectRandomPlayer() {     new iPlayers[32], iNum, id;     get_players( iPlayers, iNum )          id = iPlayers[random(32)]          if( !IsPlayer(id) ) //if they aren't a player     {         SelectRandomPlayer() //Forced to run again because there isn't a player with that ID     } else {         //do what you need to if there is a player with that ID     } }  Small things like that which make your code easier to navigate through. They can now use something along the lines of: PHP Code: public SelectRandomPlayer() {     new rPlayer = pID[random(cPlayers)] //chooses a random connected player. rPlayer being a random player, cPlayers being the players currently connected.          //do what you need to do to the ID, because you know for a fact it already exists. }  Removes the middle man, making your code easier to read. The only thing you may need to do is create a filter to check if they are a bot or not, depending on whether or not your code requires it to be an actual player.

You are not using get_players to its full potential.

PHP Code:

public SelectRandomPlayer()
{
    new iPlayers[32], iNum, id;
    get_players( iPlayers, iNum )
    
    id = iPlayers[random(iNum)]

    //do what you need to
} 


This would still allow you to easily use the flags with get_players.

[GXLZPGX]

Originally Posted by Emp` You are not using get_players to its full potential. PHP Code: public SelectRandomPlayer() {     new iPlayers[32], iNum, id;     get_players( iPlayers, iNum )          id = iPlayers[random(iNum)]     //do what you need to }

iNum is just a count of players, if I'm correct, but correct me if I'm not. Therefor you'll run into the same problem I gave an example of in the original post, which is you will have gaps between it, and you will still have to check if that ID is still in use.

[Emp`]

Originally Posted by GXLZPGX iNum is just a count of players, if I'm correct, but correct me if I'm not. Therefor you'll run into the same problem I gave an example of in the original post, which is you will have gaps between it, and you will still have to check if that ID is still in use.

get_players fills the array with player ids.

Eg. if connected players are: 1, 3, 4, 6

new iPlayers[32], iNum;
get_players( iPlayers, iNum );

//iNum = 4
//iPlayers[0] = 1
//iPlayers[1] = 3
//iPlayers[2] = 4
//iPlayers[3] = 6