PDA

View Full Version : adding more player.variables


Prozac
04-16-2006, 02:49 AM
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
04-16-2006, 03:21 AM
What is wrong with clientr. and client. flags?

Prozac
04-16-2006, 03:36 AM
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
04-16-2006, 04:36 AM
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
04-16-2006, 08:05 AM
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
04-16-2006, 07:35 PM
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
04-16-2006, 10:47 PM
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
04-17-2006, 12:53 PM
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
04-17-2006, 05:47 PM
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
04-17-2006, 09:32 PM
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
04-18-2006, 02:13 AM
clientr variables are not shared with other players.

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

Yen
04-18-2006, 02:59 AM
Are client. variables shared? (Not in a position to test it right now).
No.

jake13jake
04-19-2006, 05:12 AM
The ability to create shared variables would be good.

ApothiX
04-19-2006, 03:40 PM
Hrm, if you can't trust your staff not to delete all of a player's attributes, should that person really be staff on your server?

Prozac
04-19-2006, 06:11 PM
player.clientr.variable
thanks! i will try it out.

one of the downsides of the internet in general, and interactions with other people, is that there are no physical consequences to being a jackass.
of all the time's i've been a server admin or higher on graal in the past 5 years or more, of the 50 to 75 people that have been my staff, and of those who i thought i could trust with rw levels/* rights, about 25% of them turned out to suprise me by deleting levels and hacking whichever server it was.

So spread out having anything from your levels deleted, to your account locked out of a server that you paid for and the hacker refusing to give it back to you, essentially the bastard stealing your money (happened last year, issue was quckly resolved) thus over a half decade and up to 18 different people shocking you by becoming traitors and theives, and you learn to hold everyones actions under a magnifying glass and be quite stingy with what rights you give people.

so now i:
1. always make backups at least once a month
2. watch out for people who ask to be co-owner whom i never even hired or heard of
3. tend to ignore people who constantly ask to be staff, have submitted their work, and its not up to par, but they still ask, and they piss and moan about not being staff
4. give propper thanks to the staff i have and watch closely if they ask for more to do at their current staff level, or how often they ask for more rights weighed against how much they have shown themselves to be dedicated to the success of the server
5. check with the people on the servers that person who this person says they worked for and see what kind of fellow this applicant is

Yen
04-19-2006, 06:19 PM
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
04-19-2006, 07:42 PM
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="@[email protected]"/"@[email protected]",paused="@player.paused;

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