Better ATTR's

[Hezzy002]

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

*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]

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]

Originally Posted by cbk1994

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.

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.

Originally Posted by cbk1994

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.

[cbk1994]

Originally Posted by Hezzy002

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.

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

[Mark Sir Link]

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.

[Crow]

Originally Posted by Mark Sir Link

cannot store arrays

Quite sure I've been doing that before.

[xXziroXx]

Originally Posted by Mark Sir Link

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]

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]

Originally Posted by Mark Sir Link

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.

[Mark Sir Link]

Originally Posted by xXziroXx

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]

Originally Posted by Mark Sir Link

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]

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]

Originally Posted by fowlplay4

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.

Originally Posted by fowlplay4

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.

Originally Posted by fowlplay4

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).

[fowlplay4]

Originally Posted by Hezzy002

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.

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]

Originally Posted by fowlplay4

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.

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]

Originally Posted by Hezzy002

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?

[Mark Sir Link]

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.

[Hezzy002]

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]

Originally Posted by Hezzy002

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.

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]

Originally Posted by fowlplay4

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.

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.