Client. vs Clientr.

[wild8900]

Hey this is probably a really stupid question but Ive never been too sure.
From what I know, clientr. variables are more secure but you can only change them serverside, usualy with triggeractions (pain in the ass). But Im told client. variables can be edited clientside.

I was thinking of using some values in client. vars, should I? Its quicker and doesn't use triggeractions. Less lag right?

[Codein]

Well, first you should weigh up what you're using them for. If it's information you wish to be kept secure.

What are you storing in it? Then maybe I can help you decide what prefix to use.

[Angel_Light]

If you are storing gralats or or money you should use clientr. also if you arn't invoking an action on a x/y you should use triggerserver, not triggeraction.

[Chompy]

Well, as Codein said, it depends on what you are making. Clientr is often used for security, ie storing MD5 encrypted passwords for comparision or if you don't want it to be edited clientside.

Should provide more info tho

[Twinny]

Think of it this way: What don't you want hackers changing with a memory editer . If it's something like a flag saying your radio is playing then client.radio =1 is fine. If it's something like your characters expierence, clientr.exp would be more appropriate. If it's important: clientr. it.

[DustyPorViva]

Ya, less important things that wouldn't effect gameplay if hacked is what you'd use client.vars for. Things that would give benefits for the player if they were able to hack them are for clientr.vars, like a speed var for your movement, damage vars, and so on.

[cbk1994]

Just a note, for things which you need client. for, but you need secure, I would use base64encode() and base64decode() ... would work best if you did it a certain number of time such as this:

PHP Code:

function encodeText( text )
{
  temp.t = text;
  for ( temp.i = 10; temp.i < 10; temp.i ++ )
  {
    temp.t = base64encode( temp.t );
  }
  return temp.t;
}
function decodeText( text )
{
  temp.t = text;
  for ( temp.i = 0; temp.i < 10; temp.i ++ )
  {
    temp.t = base64decode( temp.t );
  }
  return temp.t;
} 


I've used this for gun systems and such where you need to store things that change on the dot (such as ammo), yet need to be hard to hack. For HP or experience, clientr all the way.

[Codein]

Originally Posted by cbkbud

Just a note, for things which you need client. for, but you need secure, I would use base64encode() and base64decode() ... would work best if you did it a certain number of time such as this:

PHP Code:

function encodeText( text )
{
  temp.t = text;
  for ( temp.i = 10; temp.i < 10; temp.i ++ )
  {
    temp.t = base64encode( temp.t );
  }
  return temp.t;
}
function decodeText( text )
{
  temp.t = text;
  for ( temp.i = 0; temp.i < 10; temp.i ++ )
  {
    temp.t = base64decode( temp.t );
  }
  return temp.t;
} 


I've used this for gun systems and such where you need to store things that change on the dot (such as ammo), yet need to be hard to hack. For HP or experience, clientr all the way.

I could think of ways to make ammo serversided, which includes a way to overcome the initial client - server lag.

A smart game hacker could use the lead that servers use base64 encoding. If the hacker was worth his salt, he'd easily find the the amount of times you've base64 encoded a value and then decode it from there. I had an example in my head on how I'd get round but a) It's lost now and b) I'm not sharing it publicly.

My idea was this:

Say if you have your finger on the shoot button, a temp variable would count how many bullets have been shot and then after you release the button, it'd subtract this amount from your clientr.ammo. I don't know how practical it is though. Also, this way, it doesn't matter who's shooting and who's not. It might cause a bit more lag than you'd want for the whole server but definitely less lag than taking off the ammo every time a projectile is launched/fired and definitely more secure than client. flags. Maybe a combination of my idea and base64 encoding so that hackers can't just hold down the ammo button and find the address for the client variable.

I'm not sure though, just a thought.

[Skyld]

Originally Posted by Codein

I could think of ways to make ammo serversided, which includes a way to overcome the initial client - server lag.

A smart game hacker could use the lead that servers use base64 encoding. If the hacker was worth his salt, he'd easily find the the amount of times you've base64 encoded a value and then decode it from there. I had an example in my head on how I'd get round but a) It's lost now and b) I'm not sharing it publicly.

I wrote this encryption example a while ago for this sort of problem.

[Codein]

Originally Posted by Skyld

I wrote this encryption example a while ago for this sort of problem.

Ah, perfect. Now there's no need for my serverside ammunition, which'd cause unecessary in light of a secure clientside ammunition method. I didn't notice it on your wiki, of which I often read. Not lately though, I've noticed most of the links are underlined in read, meaning they don't exist.

[cbk1994]

Originally Posted by Codein

I could think of ways to make ammo serversided, which includes a way to overcome the initial client - server lag.

A smart game hacker could use the lead that servers use base64 encoding. If the hacker was worth his salt, he'd easily find the the amount of times you've base64 encoded a value and then decode it from there. I had an example in my head on how I'd get round but a) It's lost now and b) I'm not sharing it publicly.

My idea was this:

Say if you have your finger on the shoot button, a temp variable would count how many bullets have been shot and then after you release the button, it'd subtract this amount from your clientr.ammo. I don't know how practical it is though. Also, this way, it doesn't matter who's shooting and who's not. It might cause a bit more lag than you'd want for the whole server but definitely less lag than taking off the ammo every time a projectile is launched/fired and definitely more secure than client. flags. Maybe a combination of my idea and base64 encoding so that hackers can't just hold down the ammo button and find the address for the client variable.

I'm not sure though, just a thought.

I was just giving an example of a way to do it. Obviously you would want something better. I was thinking on Skyld's example he posted below, but I couldn't find it.

Originally Posted by Skyld

I wrote this encryption example a while ago for this sort of problem.

That's the one, I searched all over the wiki and couldn't find it. Shouldn't you add it to the official wiki, seeing as you are kinda the leader of the GST in a way, and uh ... that's sorta your job ... adding things to the wiki ... Can't just expect normal players to do it.

[coreys]

Really I don't like to use clientr. flags to "store" information, really. I use it as a reference of sorts, I like to store important information like a players HP, money, etc, in objects and files and reflect those to clientr. flags so that they can be easily read.

But, like I've said before, I've come across an odd problem where clientr. flags can be set clientside.

[Chompy]

Originally Posted by coreys

Really I don't like to use clientr. flags to "store" information, really. I use it as a reference of sorts, I like to store important information like a players HP, money, etc, in objects and files and reflect those to clientr. flags so that they can be easily read.

But, like I've said before, I've come across an odd problem where clientr. flags can be set clientside.

Yeah, before I experienced that with movement systems that used and battle systems, if someone setted clientr. clientside with a wnpc, they are stored locally at the player. And when you like, press s and a trigger will be sent, and that clientr. string that is stored locally will be sent..

Dunno if this is fixed or all, because using objects and comparison serverside fix insexure stuff like that..

[napo_p2p]

Originally Posted by Chompy

Yeah, before I experienced that with movement systems that used and battle systems, if someone setted clientr. clientside with a wnpc, they are stored locally at the player. And when you like, press s and a trigger will be sent, and that clientr. string that is stored locally will be sent..

You don't need to send clientr. flags through triggers in the first place...

However, I also use a system where important values are stored in objects and reflected to clientr. flags. Just seems more secure.

[Chompy]

Originally Posted by napo_p2p

You don't need to send clientr. flags through triggers in the first place...

However, I also use a system where important values are stored in objects and reflected to clientr. flags. Just seems more secure.

Yes, but I did that sometime in 05-06, gs1

Now I use objects and clientr flags.