[Misiur]

Hi guys! I'm writing something and wanted to ask you for opinion. Almost all servers for some reason (maybe Godfather legacy "style" "guide") keep player data like this:

pawn Код:

enum pInfo {
    // (...)
    Float:pHealth,
    pInt,
    pVW
    // (...)
}

new PlayerInfo[MAX_PLAYERS][pInfo];

pInfo grows to enormous sizes and it's hard to navigate. Additionally you have to remember to put "p" in front of the property you want when accessing PlayerInfo.

Now this is my idea:

pawn Код:

#define Player.%0[%1][%2] Player%0[%1][E_PLAYER_%0_%2]

enum E_PLAYER_META {
    E_PLAYER_Meta_username[MAX_PLAYER_NAME + 1],
    E_PLAYER_Meta_salt[SOME_SALT_SIZE_CONSTANT],
    E_PLAYER_Meta_password[256 + 1]
}

new PlayerMeta[MAX_PLAYERS][E_PLAYER_META];

enum E_PLAYER_STATUS {
    Float:E_PLAYER_Status_health,
    Float:E_PLAYER_Status_armour,
    E_PLAYER_Status_interior,
    E_PLAYER_Status_vw
}

new PlayerStatus[MAX_PLAYERS][E_PLAYER_STATUS];

// Accessing:
strcpy(Player.Meta[playerid][username], "New_Username");

if (Player.Status[playerid][health] < 50.0) // blah blah

First of all, yes, the "UPPER_Title_lower" is ugly. Long enum field names are on purpose to avoid collisions. But as you can see with simple macro it's even easier than remembering "pHealth" and friends.
One problem which arises is sizeof second dimension (present when doing anything with strings). But I require Zeex's compiler, so that's not an issue.
Second problem would be rare cases where you want to access enum field by offset, say for copying with memcpy or clearing with memset. Then Player.Meta[playerid][0] would turn into invalid PlayerMeta[playerid][E_PLAYER_Meta_0]. Ideas are welcome, probably something with detecting character with macros.

What are your thoughts guys? Do you see any additional problems?

[Paulice]

Pretty neat, but imo seems like a personal preference. I start my enums with the array name (or part of it) to keep it unique and it does not bother me.

The point that matters is if you're comfortable and know your way around.

[Vince]

I'm not a fan of custom syntax. At all. Pawn sadly isn't an object oriented language but pretending like it is and inventing your own custom syntax IMO won't do any good either.

I usually only keep things in memory that need to be accessed very frequently. Everything else goes straight into the database.

[Misiur]

That's an interesting aproach. So, say, you have "Fishing skill" - you grab it from the DB every time somebody fishes? I guess I've seen too much raven's remixes to even consider that an option. Thanks for your input!

[Paulice]

Quote:

Originally Posted by Misiur That's an interesting aproach. So, say, you have "Fishing skill" - you grab it from the DB every time somebody fishes? I guess I've seen too much raven's remixes to even consider that an option. Thanks for your input!

That seems like a horrible approach.

[Misiur]

One case I think it would suck, would be standard /stats command - you'd have to construct a massive query with lots of joins/unions.

[Marricio]

Quote:

Originally Posted by Paulice That seems like a horrible approach.

Not really, if you use MySQL properly you could remove a lot of workload from the SA-MP server. Considering PAWN is one-threaded, the possibility of running large data queries in a different entity allows a large gamemode with a vast amount of data run smoothly.

[TheCman]

AIUI, the OP never mentioned databases... He was merely proposing a preprocessor-based syntax for player data.

I personally dislike it - but I'm using Python instead of pawn for my actual scripts nowadays, that surely doesn't help.

EDIT: What I mean is that your system is way too involved - but the concept of (seemingly) being able to use "health" and "money" without shadowing anything is cool. I'd implement it with PVars if I were you - many of the user status variables are going to be useful in other filterscripts. Actually I say "if I were you", but I developed something rather similar for my own GM back in the day.