What faster or better? - Printable Version

What faster or better? - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP Scripting and Plugins (https://sampforum.blast.hk/forumdisplay.php?fid=8)
+--- Forum: Scripting Help (https://sampforum.blast.hk/forumdisplay.php?fid=12)
+---- Forum: Help Archive (https://sampforum.blast.hk/forumdisplay.php?fid=89)
+---- Thread: What faster or better? (/showthread.php?tid=246044)

What faster or better? - Nexotronix - 02.04.2011

What faster or better?

PVars or arrays like PlayerInfo[MAX_PLAYERS][pInfo] ...?

Re: What faster or better? - admantis - 02.04.2011

PVars are slower yet easier to use and have global connections with other scripts.

Re: What faster or better? - aircombat - 02.04.2011

PVars are easier

Re: What faster or better? - DRIFT_HUNTER - 02.04.2011

PVars are slower than pawn variables but like the admantis say they got connections with other scripts and they are easy to use

Re: What faster or better? - PowerPC603 - 02.04.2011

If you need variables to be used across several scripts, use PVars.
Otherwise, use pawn variables.

Also PVars can lead to mistakes when you have spelled the variable wrong.
Somewhere, you use this:

pawn Код:

SetPVarInt(playerid, "Mony", GetPlayerMoney(playerid));

Somewhere else you use this:

pawn Код:

new cash = GetPVarInt(playerid, "Money");

This won't generate any error or warning in pawn, but it's a mistake you'll regret.
After you gave a player some money with the first line (SetPVarInt), the player didn't receive it, because of the "mony" variable being spelled wrongly.

If you would have used this instead:

pawn Код:

enum TPlayerData
{
    PlayerMoney, // Holds the money of this player
    PlayerScore // Holds the score of this player
}
new APlayerData[MAX_PLAYERS][TPlayerData];

This code sets up an array which holds the money and score for each player.
If you would have done this somewhere:

pawn Код:

APlayerData[playerid][PlayerMony] = 5000;

You'll get an error from the compiler, because the variable "PlayerMony" doesn't exist.

Personally, I like to use Pawn variables instead of PVars.
You avoid problems like the above situation and if you structure it properly, you have a clear overview of all the player-variables, because they're listed in one big enum.

When using PVars, they can be created everywhere in the script. That makes it hard to find them all, unless you pre-define them somewhere (like in the OnPlayerConnect callback).

Re: What faster or better? - Nexotronix - 16.04.2011

Thank you all for help!

Re: What faster or better? - Calgon - 16.04.2011

I'd just like to add a few comments to this thread, because a few people have missed this out:

PVars are convenient - yes, but the lookup speed is also slower.

I'd suggest using normal arrays/enums for player variables, however you should use PVars for variables that aren't always going to be in use, say that you put a player in a DM arena, you want to track where they are, but not all players are going to be there, you should use PVars, here's a quick example of what I mean:

pawn Код:

stock PutPlayerInArena(playerid) {
    // This function was created for the purpose of this thread.
    SetPlayerPos(playerid, 0, 0, 0);
    SetPlayerInterior(playerid, 0);
    SetPVarInt(playerid, "Arena", 1);
    return 1;
}

CMD:sawnoff(playerid, params[]) {
    if(GetPVarInt(playerid, "Arena") != 0) // We're tracking if the player is in the arena. If a PVar doesn't exist, it'll return 0.
        return SendClientMessage(playerid, 0, "You can't do this while you're in the arena!");
        
    // Giving the player a sawn-off shotgun with 500 ammo (example from wiki)
    GivePlayerWeapon(playerid, 26, 500);
    return 1;
}

Basically, what I mean is - not everyone will be in the arena, so using is a lot more convenient - but you're also saving memory, because that variable won't always be in use so it won't always be declared, unlike arrays/normal variables.

Re: What faster or better? - Scenario - 16.04.2011

What Calg00ne said. I use PVars in my scripts, but not for data which is always being retrieved and changed.