Health System
 

im creating a health system for my server, and i was wondering, how do you make sure that when you damage a player that you can tell you killed them. this is what i have so far. I only spent a couple of minutes, and i was wondering, can anyone help me? i am not to good at scripting. and the server is gonna have a ranking system ( like ranks for each class. ) and class system. im still working on everything, because i have no staff xD

Well, you could just do
And have a timeout check for clientr.dead in the clientside part of the script, and if it equals 1, then freeze the player or w/e for when hes dead.
And btw, you need to set the clientr. flags serverside.

Edit: I worded it wrong, sorry

Jazz, i meant how do i find the player whos im attacking. like if i attack some player, how would i make them get hurt.
this is what i have so far:

Well, you can't access other player's clientr. flags tho..

So, instead of checking for a player clientside, you would simple do a triggeraction()

Then if a player is hit (not the one swinging the sword), you check in.. for example 'onActionHit()' and in there, set anis and trigger serverside to remove some of their health

i don't understand what you mean...

Take your onCreated function and move it to the serverside. Also for important flags like that, regardless of the fact that they are clientr. it' a good idea to base64encode them when you're finished with testing.

For checking if a player will die:

temp.dmg = 5; //replace 5 with desired damage
if ( clientr.hp - temp.dmg <= 0 ) //If this is true the player will die.
clientr.hp -= temp.dmg;

He means to send a triggeraction when you press S, and then have it detect it, probably something like this:

No, you don't need to be encoding clientr. flags.

You shouldn't use a timeout either...

All it takes is one corrupt staffer, especially when it's being stored where he's storing it.
Maloria had problems with staffers leveling up the first time simply by editing clientr. flags and not being caught, and could have easily prevented this with encryption.

That's what they get for putting the actual value where RC could easily edit it.

I don't even think the MUD system was available back in that day. And callstacks definitely weren't. Even so, there were better places to store it back then then in an available clientr. var.

If you're that paranoid, encode it ... but why?

If someone wants to they can delete the whole server with access to a single level. base64encode would be incredibly easy to break anyway.

Just don't give any staff edit attributes.

That was not the problem. Anyone with access to a single test level can edit clientr flags if they are not encoded. Not everyone with a single test level has access to delete the entire server. It has nothing to do with edit attributes.

Callstacks also solve this problem, but back then callstack access was not available.

Also, there are ways to use base64encode that are more difficult to break then simply saying var = base64encode(var).

Solution: not to hire someone that resonates as corrupt!

Haha, in a perfect world right =p

Skyld made an encryption example, look around.
Not true. Their brother could get on. Or you yourself could be corrupt. I think the only solution is suicide.

True, I saw it. I would probably use it to say...encrypt my insecure clientr. variables so said staffer's brother doesn't come on and start adding people tons of experience/max hp.

Paranoid one. clientr variables don't need encryption. Just focus on a system of detecting cheating. Much easier.

How about you just use clientr vars for reading and not for storing? Much simpler.

Uh, hello in there?

Changes like that are logged in logs/rclog.txt

Exactly. I wouldn't use clientr. variables to store things such as experience or health power.

Again, I'm talking about scripts that edit clientr. variables, not editing attributes via RC.

Either way, if you want to store important information the old fasion way, and then not secure it, be my guest. Your data, not mine. Again, I wouldn't even store this sort of information in a clientr. in the first place.

Good for you >.<

Encryption is a tool in that box. No one said you have to keep your data secure. If you want to bank on cheat detection methods because writing an encryption that takes 6-7 lines is too hard or isn't worth your time, it's your data.

Ideally, you shouldn't have to worry about staff even making scripts to edit clientr variables.

Ideally, yeah. ;[
But unfortunately after what happend on Maloria I don't think that if you're gonna store this sort of thing in a clientr. variable, that it's worth the risk of leaving it decryted.

Ideally, only server administrators should have access to RC on classic servers and all other staff should work on Dev servers.

Yeah. Though, one of the people editing clientr. flags on maloria back in the GS1 days was a department Chief. =(
So ideally everyone's data NPCs would be scripted securely. :p

Department Chiefs aren't server administrators. Believe me, I know all about the history of Maloria. I have first-hand experience.

Lol, Ol' West isn't even classic and that's how we do it.

You forget that someone scripts the encryption, and, face it, more scripters are corrupt than any other group of developers ;)

Atleast the ones I've seen.

Actually, I was always more worried about level designers. But that was probably do to the fact that on almost every project I work on, I almost never hire another scripter to work on the project besides my self.

So if scripters are corrupt and you want a good solid encryption system, the only solution seems that only servers created by a scripter would solve this issue since a server creater probably wouldn't screw the economy up or cheat on the server that he/she created.

At least, I know I wouldn't.

Except that generally levelers don't know much code except the basics -- hide(), show(), sleep(), drawunderplayer(), message(), etc.

clientr.exp += 20;
That's all they have to know how to write lol. What's awesome is it's just those types of people who you're normally protecting from. People who only know how to do simple commands aren't going to bother trying to decode your protected data, even if it's a simple one line encryption.