That list of points that Garsino posted was originally written by me as an explanation for why the PVar system was created.
Quote:
Originally Posted by Y_Less
So can properties, and they've been in SA:MP since 0.1.
|
And that's exactly where the idea for PVars came from. Pawn properties have a big limitation though: you can't easily use them as arrays. In SA-MP's case, you can't easily bind them to a particular player id. And even if you could, you would have to write extra code to reset these every time a player joined/parted the server.
The real power of PVars is that it makes dealing with player data extremely simple. When a player joins the game and logs in, you can get a list of their PVars from a database or file and load them. During gameplay you can update their PVar values, which might include things like player stats etc and use those values for your script logic. You can even add new PVars to their list during gameplay. When the player exits the server, you can dump all of their PVars (I created an example function Util_CreatePVarList() in test_cmds.pwn, which comes with the server) back to the file or database. Now you have a system for persistent player data storage which requires a lot less code than creating fake structs with enums or constantly querying a database.
Not all data in your script is player-specific. In these cases you have no use for PVars. PVars weren't actually designed for that purpose. PVars were created to store player-specific information that you would want to save and share across scripts. Anything related to player stats is a good example.
There is something missing though. Even though I created a function to dump the list of a player's PVars to a string, I didn't create the opposite function to load the player's PVars from a string. The whole system might have made a little bit more sense if I had done that.
There is a performance tradeoff for using PVars over arrays in pawn, but that tradeoff is nothing compared to what would happen if you had a poorly designed player data storage system that relied on querying a database or reading from files.
If you look back at the some of the first SA-MP scripts that had persistent player data, like GF, you'll see that using fake structs and .INI files eventually becomes a big mess which requires a lot of extra script just to store and retrieve player information. If you want to add something new to the player data, you have to go and update the enum, update the .INI data saving/loading procedures, make sure that information is reset when the player join/exits the server.
PVars can make the above very easy. Are your PVars loaded/saved when the player logs in and leaves the server? Want to create a new experience level?
pawn Code:
SetPVarInt(playerid, "fishing_level", 100);
That's all you have to do. If a player didn't have any fishing experience and you did:
pawn Code:
GetPVarInt(playerid, "fishing_level");
it would just return 0. So basically you've defined a new persistent player stat with a single line of code.
