Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)
-   -   Client. vs Clientr. (https://forums.graalonline.com/forums/showthread.php?t=78194)

wild8900 01-02-2008 10:59 PM

Client. vs Clientr.
 
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 01-02-2008 11:00 PM

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 01-02-2008 11:02 PM

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 01-02-2008 11:04 PM

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 01-02-2008 11:41 PM

Think of it this way: What don't you want hackers changing with a memory editer :p. 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 01-03-2008 12:15 AM

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 01-03-2008 01:47 AM

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 encodeTexttext )
{
  
temp.text;
  for ( 
temp.10temp.10temp.++ )
  {
    
temp.base64encodetemp.);
  }
  return 
temp.t;
}
function 
decodeTexttext )
{
  
temp.text;
  for ( 
temp.0temp.10temp.++ )
  {
    
temp.base64decodetemp.);
  }
  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 01-03-2008 02:25 AM

Quote:

Originally Posted by cbkbud (Post 1367747)
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 encodeTexttext )
{
  
temp.text;
  for ( 
temp.10temp.10temp.++ )
  {
    
temp.base64encodetemp.);
  }
  return 
temp.t;
}
function 
decodeTexttext )
{
  
temp.text;
  for ( 
temp.0temp.10temp.++ )
  {
    
temp.base64decodetemp.);
  }
  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 01-03-2008 02:33 AM

Quote:

Originally Posted by Codein (Post 1367767)
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 01-03-2008 03:12 AM

Quote:

Originally Posted by Skyld (Post 1367770)
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 01-03-2008 06:28 AM

Quote:

Originally Posted by Codein (Post 1367767)
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.
Quote:

Originally Posted by Skyld (Post 1367770)
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 01-05-2008 06:25 AM

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 01-05-2008 04:30 PM

Quote:

Originally Posted by coreys (Post 1368167)
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 01-05-2008 10:00 PM

Quote:

Originally Posted by Chompy (Post 1368214)
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 01-05-2008 10:21 PM

Quote:

Originally Posted by napo_p2p (Post 1368283)
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.


All times are GMT +2. The time now is 01:20 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.