adding more player.variables

[Prozac]

let's say i want to add another variable to the player
called player.foo
and the value of foo can be any string integer or array.

how would i go about doing this?
and doing this so that the new player attribute can only be modified
from a serverside command?

i imagine it's something about joining a class or a database npc,
could anyone please point me in the right direction?

[napo_p2p]

What is wrong with clientr. and client. flags?

[Prozac]

client. and clientr. flags could be altered by staff who have edit player attribute rights and if the staff go corrupt, they could change the client and clientr.values even without npc control to cheat or frame other players for cheating.

player.variables would not be changable with rc. for the kind of systems i want to script, i want to know how to make them as secure and hack-proof as i can... if you know the history of some graal playerworlds, i used to run Sanstrata, which aparently in some languages means "please hack me" and i have no desire to go through that hell again.

[Yen]

Take away edit attributes, problem solved.
clientr. is the most hack-proof you can get.

player. variables already exist, but they're just like a global variable attached to the player's client; any NPCs can read them from the clientside.
Or maybe they don't exist, so they take on the characteristics of a variable with no prefix. Who knows?

[Rick]

player.somevar are still shown in edit attributes, only they don't have a prefix. They are good for not being distributed to the client.

[Prozac]

perhaps my post was not clear,
i want to create a new player.variable that can only be edited serverside, but read clientside or serverside.

[napo_p2p]

Originally Posted by Prozac

perhaps my post was not clear,
i want to create a new player.variable that can only be edited serverside, but read clientside or serverside.

And Rick was saying that player.variable will still appear in the flags of a player's attributes. So, you can create them, but they don't necessarily have the functionality that you want.

[Rick]

Originally Posted by Prozac

perhaps my post was not clear,
i want to create a new player.variable that can only be edited serverside, but read clientside or serverside.

player.clientr.variable is what you want.

[contiga]

I think there should be more flags to be read clientside tho.. like: player.kills / player.deaths somehow can't be read clientside....! Or inside
for ( i: players)
{
would i.clientr.somevar return nothing... sux cuz a lot of triggeractions to do it via serverside, back to clientside would cause lag.. O_o
}

[Rick]

Originally Posted by contiga

I think there should be more flags to be read clientside tho.. like: player.kills / player.deaths somehow can't be read clientside....! Or inside
for ( i: players)
{
would i.clientr.somevar return nothing... sux cuz a lot of triggeractions to do it via serverside, back to clientside would cause lag.. O_o
}

clientr variables are not shared with other players.

[napo_p2p]

Originally Posted by Rick

clientr variables are not shared with other players.

Are client. variables shared? (Not in a position to test it right now).

[Yen]

Originally Posted by napo_p2p

Are client. variables shared? (Not in a position to test it right now).

No.

[jake13jake]

The ability to create shared variables would be good.

[Yen]

Originally Posted by jake13jake

The ability to create shared variables would be good.

attr[] works gewd.
I have my system hold every player's HP and MP percentage in attr[4], so other players can access it. :O

[jake13jake]

Originally Posted by Yen

attr[] works gewd.
I have my system hold every player's HP and MP percentage in attr[4], so other players can access it. :O

Yea, I have to store that a player is paused in an attr var, and also the player's spar rating.

I'm probably going to try to save all this inaccessible info into one attr var.
like

player.attr[4]= "rating="@player.rating@"/"@player.ratingd@",paused="@player.paused;

ALTHOUGH, it would be SOO much easier if you could just define public read-only flags in the serverops.