Graal Forums - Better ATTR's

Graal Forums (https://forums.graalonline.com/forums/index.php)

- NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)

- - Better ATTR's (https://forums.graalonline.com/forums/showthread.php?t=134264016)

Hezzy002

07-27-2011 07:33 AM

Better ATTR's

After finding out that there was a 223 character limit on attributes, and a limited amount of them available for use, I decided to write my own system for handling cross-client communications in the same way that attributes work.

This basically lets you set variables like "player.test = 10; player.shareVar("test");" on the client, then on any OTHER client, use findPlayer or whatever other method to get that player's object, and get the value of the same variable! "player.chat = findPlayer("Hezzy002").test;" will print 10, just as it was set! ;)

The variables are stored permanently in an SQL database as well, and are reproduced on login.

Installation:

1) Create a new SQL DB named crossplayer
2) Add the crap below to your server, make sure if you change the weapon or DBNPC names you change any references to that name.

DBNPC

Crossplayer-Control

PHP Code:


		
			
public function addSharedVariable(target, flagName, value) {
  if (flagName in target.getStaticVarNames()) {
    echo(target @ " tried to modify a protected variable (" @ flagName @ ")");
    return;
  }
  
  target.(@flagName) = value;

  reqsql2("crossplayer", 
    "INSERT OR REPLACE INTO '" @ target.account @ "' (name, value)
    VALUES ('" @ flagName @ "', '" @ value @ "')", false);
  
  temp.packet = null;
  temp.packet.add(target.account);
  temp.packet.add(flagName);
  temp.packet.add(value);
  
  for (pl : allplayers) {
    if (pl == target) continue;
    pl.triggerclient("gui", "-System/Client/Crossplayer", temp.packet);
  }
}

public function shareVars(target) {
  reqsql2("crossplayer", 
    "CREATE TABLE IF NOT EXISTS '" @ target.account @ "' (
    name TEXT PRIMARY KEY,
    value TEXT
    )", false);

  for (pl : allplayers) {
    if (pl.levelname == null) continue;
    
    temp.req = reqsql2("crossplayer", "SELECT * FROM '" @ pl.account @ "'", true);

    temp.vars = temp.req.rows;
    temp.packet = null;
    temp.packet.add(pl.account);
    for (temp.v : temp.vars) {
      temp.toks = temp.v.tokenize();
      temp.packet.add(temp.toks[0]);
      temp.packet.add(temp.toks[1]);
    }
    target.triggerclient("gui", "-System/Client/Crossplayer", temp.packet);
  }
  
  temp.table = reqsql2("crossplayer", "SELECT name FROM sqlite_master WHERE type='table' AND name='" @ target.account @ "'", true);
  
  if (temp.table != null) {
    //Send my own to everyone else
    temp.req = reqsql2("crossplayer", "SELECT * FROM '" @ target.account @ "'", true);
    temp.vars = temp.req.rows;
    
    temp.packet = null;
    temp.packet.add(target.account);
    for (temp.v : temp.vars) {
      temp.toks = temp.v.tokenize();
      target.(@temp.toks[0]) = temp.toks[1];
      temp.packet.add(temp.toks[0]);
      temp.packet.add(temp.toks[1]);
    }
    
    for (pl : allplayers) {
      if (pl == target) continue;
      pl.triggerclient("gui", "-System/Client/Crossplayer", temp.packet);
    }
  }
}

function reqsql2(db, query, waitfor){
  temp.req = requestsql2(db, query, waitfor);
  
  if(req.error != ""){
    echo(req.error, query);
  }
  
  if(!waitfor){
    return;
  }
  
  if(!req.completed){
    waitfor(req, "onReceiveData", 60);
  }
  return req;
}

Weapon NPC (A buffer to handle triggerclient's)

-System/Client/Crossplayer

PHP Code:


		
			
function onActionServerside(varName, value) {
  FindNPC("Crossplayer-Control").addSharedVariable(player, varName, value);
}
//#CLIENTSIDE
function onActionClientside(temp.packet) {
  temp.target = findPlayer(temp.packet[0]);
  temp.max = temp.packet.size();
  temp.i = 1;
  while (temp.i < temp.max) {
    temp.target.(@temp.packet[temp.i++]) = temp.packet[temp.i++];
  }
}

Join this simple class to the player

Crossplayer-Class

PHP Code:


		
			
//#CLIENTSIDE

public function shareVar(varName) {
  triggerserver("gui", "-System/Client/Crossplayer", varName, player.(@varName));
}

3) Ensure everyone is joined to the player class and is given the weapon NPC.

QUICK EXAMPLE:

PHP Code:


		
			
//#CLIENTSIDE
function onPlayerChats() {
  if (player.chat.tokenize()[0] == "/setsharedvar") {
    player.(@player.chat.tokenize()[1]) = player.chat.tokenize()[2];
    player.shareVar(player.chat.tokenize()[1]);
  } else if (player.chat.tokenize()[0] == "/readsharedvar") {
    player.chat = findPlayer(player.chat.tokenize()[1]).(@player.chat.tokenize()[2]);
  }
}

Saying "/setsharedvar foo bar" will set player.foo to "bar". Then, saying on any other client, "/readsharedvar Hezzy002 foo" will show you the value of Hezzy002's player.foo value.

Thanks! It's helped me alot in development on my server, and I hope it helps out you guys too :D

*This is my first contribution, so please point out anything that I've done wrong. It's not a complicated script but I find it very useful. I'm not sure if there's more optimization that can be done or not, I did some optimization where I form it like a packet to handle multiple, instead of spamming the account name over the server and wasting bandwidth.

Let me know if you're going to use this for something, it'd be nice to know that something I wrote is floating out there being useful to other people!

cbk1994

07-27-2011 08:55 AM

Player attributes aren't limited to 223 characters, RC just cuts them off there. You could rewrite this system using player attributes with no issues as long as you made sure staff never edited a player's attributes with RC.

Something about creating a table for each account feels wrong. I wonder if there's really any benefit in doing that over having a well-indexed table with an "account" column in addition to the "name" and "value" columns.

Hezzy002

07-27-2011 09:11 AM

Quote:

Originally Posted by cbk1994 (Post 1660541)

In my testing I couldn't get attrs to display more than 223 characters if I tried to access it from the clientside portion of a script on another player, maybe it was just the way I tested it or something, can anyone confirm? Dunno.

Quote:

Originally Posted by cbk1994 (Post 1660541)

Something about creating a table for each account feels wrong. I wonder if there's really any benefit in doing that over having a well-indexed table with an "account" column in addition to the "name" and "value" columns.

Having a table for each account is a lot more efficient than throwing them all into a huge DB and having to search for the account out of a list.

Mark Sir Link

07-27-2011 09:41 AM

setting player.attr[3] to some massive string (10k) on the serverside and echoing the length clientside is always returning 223. I imagine there is a limit for it clientside since that data is being passed to all players in the same players level.

attributes array is also really inflexible, cannot store arrays, and apparently stumbles if you try to store something like 255_255_255, truncating it to just 255.

cbk1994

07-27-2011 10:04 AM

Quote:

Originally Posted by Hezzy002 (Post 1660542)

You're right, I thought you meant player attributes as in player flags, not the attr array.

Crow	07-27-2011 11:37 AM

Quote:

Originally Posted by Mark Sir Link (Post 1660543)

cannot store arrays

Quite sure I've been doing that before.

xXziroXx

07-27-2011 12:39 PM

Quote:

Originally Posted by Mark Sir Link (Post 1660543)

cannot store arrays

Yes it can.

Example:

PHP Code:


		
			
// Array stored in an attribute
this.attr[10] = @{ "foo", "bar", "baz" };

...

//#CLIENTSIDE

this.chat = this.attr[10].tokenize(",")[0];  // Equals "foo"

Mark Sir Link

07-27-2011 12:49 PM

I guess I should have been more specific, if you store an array of integers it will truncate the rest.

PHP Code:


		
			
function onCreated(){
 temp.p = findplayer("Mark Sir Link");
 p.addweapon(this.name);
 p.attr[17] = {1, 5, 8};
 echo(p.attr[17]); //echoes 1,5,8
}

//#CLIENTSIDE

function onCreated(){
  player.chat = player.attr[17]; // 1
}

xXziroXx

07-27-2011 02:21 PM

Quote:

Originally Posted by Mark Sir Link (Post 1660550)

I guess I should have been more specific, if you store an array of integers it will truncate the rest.

That's why you do

PHP Code:


		
			
p.attr[17] = @{1, 5, 8};

instead of

PHP Code:


		
			
p.attr[17] = {1, 5, 8};

and then reads it as a tokenized string on clientside to pretend that it is an array.

fowlplay4

07-27-2011 07:46 PM

There's probably something you can be doing different if you need more than 233 characters of data in an attr.

You're committing an SQL Atrocity (Search Google: "new table for each user") by creating a new table of data for each player, and aren't really gaining any kind of performance boost by doing that at all.

SQL just seems really overkill for this. I.e:

PHP Code:


		
			
function onPlayerLogin(pl) {

  this.shared.(@pl.account).clearvars();

}



function onPlayerLogout(pl) {

  this.shared.(@pl.account).clearvars();

}



public function addSharedVariable(target, flagName, value) {

  // ... other code 

  this.shared.(@target).(@flagName) = value;

  

  // Packet...

  temp.packet = {};

  temp.packet.add(target.account);

  temp.packet.add(flagName);

  temp.packet.add(value);

 

  // update players

}

Hezzy002

07-27-2011 08:51 PM

Quote:

Originally Posted by fowlplay4 (Post 1660592)

There's probably something you can be doing different if you need more than 233 characters of data in an attr.

I'm fixing a poor design choice that affects the end-user experience, that's all. I don't particularly need more than 223 characters of data in an attr, but having attributes stored in an array and accessing them by integer isn't very good self-documenting code, unless you create an enumeration or wrapper to give them identifiers or something, but why bother when this solution is more elegant for the scripter? <- Big fan of self-documenting solutions.

Quote:

Originally Posted by fowlplay4 (Post 1660592)

You're committing an SQL Atrocity (Search Google: "new table for each user") by creating a new table of data for each player, and aren't really gaining any kind of performance boost by doing that at all.

I think most of that out there is misinformation in this case. Most of it points toward general-purpose use, and yeah it looks like it's a poor choice for that. But in this case, I'm definitely cutting out a few comparisons on SQLite. I'm not sure if SQLite builds a hash table every time you add a value, and then links all the similar values to a single hash value, but either way, this method would cut down on at least one step since I need all the values in the table. Otherwise, it'd have to link tons of values to a single hash, or if SQLite isn't as efficient as it should be, tons of string comparisons.

Quote:

Originally Posted by fowlplay4 (Post 1660592)

SQL just seems really overkill for this. I.e:

PHP Code:


		
			
function onPlayerLogin(pl) {

  this.shared.(@pl.account).clearvars();

}



function onPlayerLogout(pl) {

  this.shared.(@pl.account).clearvars();

}



public function addSharedVariable(target, flagName, value) {

  // ... other code 

  this.shared.(@target).(@flagName) = value;

  

  // Packet...

  temp.packet = {};

  temp.packet.add(target.account);

  temp.packet.add(flagName);

  temp.packet.add(value);

 

  // update players

}

That's how I initially handled it, then I added SQL for the sake of keeping them in an organized database that's able to be saved across sessions without resorting to file hackery or cheap tricks. These are just as permanent as client strings. I would've only written to the SQL database once, when the player logs out, but I wasn't sure how reliable onPlayerLogout was (i.e. if timing out/disconnecting unintentionally still fired the event).

Mark Sir Link

07-27-2011 09:16 PM

Quote:

Originally Posted by xXziroXx (Post 1660556)

That's why you do

PHP Code:


		
			
p.attr[17] = @{1, 5, 8};

instead of

PHP Code:


		
			
p.attr[17] = {1, 5, 8};

and then reads it as a tokenized string on clientside to pretend that it is an array.

it resulted in truncating to 1 anyway, I tried virtually everything leading into this

xXziroXx

07-27-2011 09:26 PM

Quote:

Originally Posted by Mark Sir Link (Post 1660603)

it resulted in truncating to 1 anyway, I tried virtually everything leading into this

On clientside:

PHP Code:


		
			
temp.myArrayFromServerside = this.attr[17].tokenize(",");

this.chat = "My array has" SPC temp.myArrayFromServerside.size() SPC "entries and [1] equals '" @ temp.myArrayFromServerside[1] @"'!";

fowlplay4

07-27-2011 09:53 PM

Quote:

Originally Posted by Hezzy002 (Post 1660601)

You really aren't making it easier for SQL though. It's still going to have to do that exact same check if the table exists.

Your table should just be:

account
flag
value

add an index to account and you're good to go.

Your attempt at making it more efficient by giving each account their own table is actually much more in-efficient.

If you have 10 people online and you call shareVars on one person, you're calling around 12+ queries (and triggers too) in one call.

If you made your table properly, you could use one query to get everyone's flag and variables. I.e:

SELECT account, name, value
FROM flags
WHERE account IN ('account1', 'account2')

Package the result up and send it to your client.

Hezzy002

07-27-2011 11:06 PM

Quote:

Originally Posted by fowlplay4 (Post 1660606)

That's true, I hadn't thought about that case. I'll modify it, then. I don't see any problem with the triggers, it's no different than sending a packet, isn't it?

fowlplay4

07-27-2011 11:46 PM

Quote:

Originally Posted by Hezzy002 (Post 1660619)

That's true, I hadn't thought about that case. I'll modify it, then. I don't see any problem with the triggers, it's no different than sending a packet, isn't it?

The triggers are fine, misread what was happening.

Personally, I'm not a fan of making everyone's "better ATTRs" accessible to everyone all the time rather than when they're needed.

Rather than using a hack to get around the limitations of an ATTR it's probably better to make your system work without having to sync a significant amount of data.

Can you explain the situation where you need it to work like this?

Hezzy002

07-28-2011 12:25 AM

Quote:

Originally Posted by fowlplay4 (Post 1660630)

It's for convenience, just like ATTR's are. A caching system for the client to have data available about other clients for whenever it's needed, instead of having to wait for the server to respond. Right now it's not being used for any kind of massive data that would extend past 223 bytes (and it never will be, I agree that some data should never be sync'd with all players and should be available upon request) but accessing something like pl.nicknameColor, pl.red/pl.green/pl.blue/pl.alpha/pl.rotation/pl.strechx/pl.stretchy, pl.sysHealth, pl.sysMagic, or pl.sysAlliance (For a server that doesn't use a standard interface) is a lot prettier than pl.attr[1], or even pl.attr[NICKNAME_COLOR]. It's a lot more self-documenting and preferable for a server that has multiple scripters.

Mark Sir Link

07-28-2011 12:36 AM

I believe attrs are only sent to other players within the scope of players array unless otherwise defined in the server ops, dunno if anyone thinks/knows otherwise.

could limit it to that and allow for a global scope (added column to table?) if you really wanted and I think that would come closer to matching attr as they currently are.

fowlplay4

07-28-2011 12:38 AM

Quote:

Originally Posted by Hezzy002 (Post 1660641)

The consequences of using the system seem to far outweigh the benefits of being able to use a variable directly.

You can easily hide the "ugly" code related to the player attr with a class, and write common accessors and mutator functions.

pl.getNicknameColor() is just as self-documenting than pl.nicknameColor.

Hezzy002

07-28-2011 03:52 AM

Quote:

Originally Posted by fowlplay4 (Post 1660643)

There are no "consequences", though.. The server is experiencing no more strain than if you were to use attrs, they're handled in exactly the same way, just natively in <insert language Graal's servers are written in> instead of GS2, and considering that it hardly uses any CPU resources, it would be bound at most by the lookup speed of the server's drives and so would attrs..

Other than that, the syntax is better than attr's, it requires less work to get it to be self-documenting, it's easier for the scripter, it doesn't require casting to a string to work correctly with things like arrays, there's no 223 character limit, and you can use more than 30 should you desire to. I don't see any of the consequences you're talking about, period.

I mean, I could be wrong, what consequences are you talking about?

fowlplay4

07-28-2011 06:11 AM

Quote:

Originally Posted by Hezzy002 (Post 1660666)

The syncing is automatically done by the server, and doesn't require you to sync the data with everyone. There is a server option that allows you to do that however.

The limitations of using an ATTR can be avoided with a proper design, and writing functions to retrieve and parse the information from it.

If the data is too large, it should be requested as needed not loaded ahead for convenience.

Class: player_shared_data

PHP Code:


		
			
//#CLIENTSIDE



function setHealth(hp, mp, maxhp, maxmp) {

  // Store health in attribute

  player.attr[4] = hp SPC maxhp SPC mp SPC maxmp;

}



// Retrieve HP from Attr

function getHP(pl) {

  return pl.attr[4].tokenize()[0];

}



// Retrieve MP from Attr

function getMP(pl) {

  return pl.attr[4].tokenize()[2];

}



// Retrieve Stats from Attr

// Store Stats in Object for Easier Access

function updateStats(pl) {

  temp.tokens = pl.attr[4].tokenize();

  if (temp.tokens.size() == 4) {

    pl.hp = temp.tokens[0];

    pl.maxhp = temp.tokens[1];

    pl.mp = temp.tokens[2];

    pl.maxmp = temp.tokens[3];

  }

}

Usage:

PHP Code:


		
			
this.join("player_shared_data");

//#CLIENTSIDE

function onCreated() {

  // Give Random Health to People

  temp.hp = int(random(0, 5));

  temp.maxhp = 5;

  temp.mp = int(random(0, 5));

  temp.maxhp = 5;

  setHealth(temp.hp, temp.mp, temp.maxhp, temp.maxmp);

  // Wait a sec...

  sleep(1);

  // Loop through Players

  for (temp.pl: players) {

    // Update Player Health Variables

    updateStats(temp.pl);

    // Show HP and MP on Players

    temp.pl.chat = format("HP: %d/%d MP: %d/%d", temp.pl.hp, temp.pl.maxhp, temp.pl.mp, temp.pl.maxmp);

  }

}

Other scripters then just need to join the class to the script they need it in, and call the functions you defined. You can then easily document in that script what attribute is being used for what and how.

Code that's documented is much more valuable to other scripters than code that is just written a way that self-documents itself.

If the server can do it on it's own, let the server do it for you instead of re-creating the wheel.

Hezzy002

07-28-2011 06:34 AM

Yeah mate, I know you can do that, but this is my way of doing it and you still haven't told me any consequences for using my system. I'm interested in those severe consequences that are bothering you so much, because if they bother someone with so much experience in GS2, then they should bother me too. Can you just state them and maybe I can rectify them? I like my system because I hate limits and I'm sure you do too.

fowlplay4

07-28-2011 07:05 AM

Quote:

Originally Posted by Hezzy002 (Post 1660679)

I just believe it's a hack for something that doesn't needed to be hacked.

You have to handle the entire synchronization process with your own scripts, and the more players you have on the server the more unneeded strain is going to placed on the server, and the changes to the variables your synchronizing will only be as efficient as your system that syncs it.

The limit is there to prevent people from doing terrible things, and if your system needs to break it there's probably a better way to do it. So a system that lets you break the limit is only going to allow those terrible things to happen. I.e: Syncing massive amounts of useless data.

Your system needs the ability to only sync to clients that need it instead of just everyone regardless if they need it or not.

Hezzy002

07-28-2011 08:15 AM

Quote:

Originally Posted by fowlplay4 (Post 1660680)

The synchronization process is ridiculously negligible in my eyes, unless GS2 has the most hilariously slow VM I've ever seen, and I'm not sure but the limit is probably imposed for technical reasons, like the size of a packet or maybe something legacy related, because I've noticed Graal's got a lot of problems related to previous versions. Personally, I don't plan on syncing massive amounts of useless data, but that's up to the dude using it.. I really should also add a method to remove them, mark flags to not save after login, and share only to local players, maybe only share if the client has a certain flag set, too. That would be ideal.

All times are GMT +2. The time now is 11:05 PM.