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