[Phil25]

I have quite a bit of plugins managing different things with players - are they admins, donators, are they in the Steam group, are they in Friendly mode, have they joined via the favourites tab (and a bunch of my map-specific booleans), etc.

If I want to check for a certain player property in a different plugin, for example, if they have joined via the favourites tab, I'd have to create an .inc file for that specific plugin which is a lot of work for something that small. Checking the first three is a breeze since I can just check their flags, but there's only so many custom ones out there.

TL;DR Here -> Which brings me to my question: Is there an official way of setting certain properties of an (player) entity just for the sole reason of something else reading from it?

I was thinking of using some "unused" property of a player entity such as m_hOwnerEntity or m_flNextAttack or [TF2] m_nCurrency (while not in MvM). But I think simply setting the name of the player entity to a flags number would be the best solution.

Another question: I have not been playing around with bitwise operations before, so please correct me if any of this is wrong:

PHP Code:

#define FLAG_NONE            0
#define FLAG_FRIENDLY        1
#define FLAG_JOINEDBYFAV    2
#define FLAG_BONUSSTAGE        4
#define FLAG_ARENASTAGE        8
#define FLAG_DUELCONTESTANT    16

new iPlayerFlags[MAXPLAYERS+1] = {0, ...};


OnArenaEnter(client){

    iPlayerFlags[client] |= FLAG_ARENASTAGE;

}

OnArenaExit(client){

    iPlayerFlags[client] |= ~FLAG_ARENASTAGE;

}

bool:IsClientInBonusStage(client){

    if(iPlayerFlags[client] & FLAG_BONUSSTAGE)
        return true;
    
    return false;

} 


Thanks for reading and any help; and a happy New Year to all!

[Miu]

Originally Posted by Phil25 But I think simply setting the name of the player entity to a flags number would be the best solution.

Maps use targetnames as the main method of saving information about players AFAIK, and plugins sometimes use them for workarounds

Originally Posted by Phil25 TL;DR Here -> Which brings me to my question: Is there an official way of setting certain properties of an (player) entity just for the sole reason of something else reading from it?

I don't think lazy hacks really have official implementations by nature

Originally Posted by Phil25 PHP Code: iPlayerFlags[client] |= ~FLAG_ARENASTAGE;

You want iPlayerFlags[client] &= ~FLAG_ARENASTAGE; if you're trying to remove the flag

[Phil25]

Thanks for the help. I am aware that some maps and plugins may use this but not in my case. I just want the best and simple solution for my small problem and such workaround seems like the best option. This is all for closed environment which is only a single server with a single map.

[psychonic]

Tying the data to the entity property, especially for player-specific data, seems unnecessary in addition to potentially bringing breakage.

If you're referencing the player entity by index anyway, you're only introducing extra inefficiency by doing a native call to retrieve the data, rather than indexing an array local to the plugin like in your example above.

Your bitwise operations look fine.

[Phil25]

Originally Posted by psychonic If you're referencing the player entity by index anyway, you're only introducing extra inefficiency by doing a native call to retrieve the data, rather than indexing an array local to the plugin like in your example above.

I guess the best solution would be to have a seperate plugin managing all that and having every other include that plugin. That would also bring some extra functionality such as forwards.

[psychonic]

Originally Posted by Phil25 I guess the best solution would be to have a seperate plugin managing all that and having every other include that plugin. That would also bring some extra functionality such as forwards.

I completely missed the part about wanting to share the information with other plugins. That makes perfect sense as to why you'd consider using an entity property now.

You could indeed just has a plugin that manages the state, and then provide natives and forwards from that. It gives you much more flexibility in the future as well, should you need to store more values than a single bitfield, in addition to avoiding the other pitfalls with stomping on the game's own fields.