Using text files OR SQL should both work fine, and I also agree with MD regarding usage of clientr. flags so that the SQL or DB don't need to be parsed as frequently.
Using an SQL library you'd use requestsql2(). Using a textfile you'd use savelines/loadlines or savevars/loadvars.
Either way, you can "cache" the information onto a DB for faster access via creating a new TStaticVar and loading the variables into it. For example, in a textfile DB, assume:
guild_lol.txt:
admins=Restraint,khortez
members=jimbo69,lolguy420
Doing:
PHP Code:
temp.guildInfo = new TStaticVar();
guildInfo.loadVars("guildfolder/guild_lol.txt");
the following is now true:
PHP Code:
guildInfo.admins == {"Restraint", "khortez"};
guildInfo.members == {"jimbo69", "lolguy420"};
You can easily pass this information to the client if you want to:
PHP Code:
temp.passToClient = guildInfo.saveVarsToArray(false);
triggerClient("gui", this.name, passToClient);
On the clientside:
PHP Code:
function onActionClientside(info) {
temp.guildInfo = new TStaticVar();
guildInfo.loadVarsFromArray(info);
}
makes for easy display of guild member information in GUIs.
The guild information can be cached on the serverside (ie, left as a TStaticVar that isn't a temp. and thus isn't garbage collected) so that the textfile does not need frequent I/Oing. For example:
PHP Code:
const directory = "localguilds/guild_%s.txt";
temp.guildName = "lol"; // placeholder, it'd be accessed via a var
temp.guildInfo = this.guild.(@guildName) = new TStaticVar();
temp.file = format(directory, guildName);
guildInfo.loadVars(file);
In this scenario, you can easily interact with the information in this function using "temp.guildInfo" (or just "guildInfo" for short). The information will be saved long-term, though, via "this.guild.lol" variable. "Long term" here is subjective:
A this.'ed new TStaticVar() will not last forever; particularly, NPC server restarts will delete it, and sometimes it seems to be deleted randomly. However, you can simply re-initialize it if it doesn't already exist from the text file. The text file (or SQL database, if you so chose) would need writing-to in realtime, but would only need reading once a day or less (depending on frequency of NPC server restarts -- depending on the frequency that the TStaticVar *poof*s).
Furthermore, this is a trade-off between memory and processor. As more guilds are accessed in a day, their staticvar's will be held for longer periods of time. The result is that more memory must be allocated to hold them. On the flipside, accessing the text or SQL database to parse it every single time is more of a hit on processor. Your loyalties are for you to decide on this one, but I would take the memory hit over the processor one, generally. (Also: any guilds not accessed since the last NPC server restart (or less) will not have their info allocated to memory anyway)
Finally, for player-specific clientside business, I would also use a clientr. as MD suggested. Sure, it opens up the potential that an admin sets your attributes right as you change guilds, but consider the following:
1. High Rarity: That's a fringe case. It isn't often that an admin will set your atts during the exact time you change guilds.
2. Low Damage: The damage is that you will be flagged in the wrong guild clientside
until you next restart your client, at which point, upon your next onPlayerLogin, the server would re-sync your flags. You could mitigate this damage further by verifying players are actually in the guilds they attempt to tag-up for on the serverside (which you might consider doing for security reasons anyway!). You can probably use onPlayerNickChanges() for this, though I have never personally used that function.
3. High Convenience: The advantage of convenience outweighs the minor disadvantage. If you, for example, wanted to get a quick list of guilds the player was in on the clientside for a GUI display, nothing would beat out the convenience of having a flag like:
PHP Code:
clientr.guilds == {"lol", "chips"}
If you are still starting out in GS2 or at least these deeper aspects of it, I would recommend making a textfile DB first. While it's, I feel, unarguably inferior to SQL for this purpose, it will be easier to learn and the functions you learn will go a long way towards other aspects of Graal (such as using .loadlines/.savelines to edit levels), while learning SQL is more of a hassle (IMO) and harder to troubleshoot (also IMO).
Two huge advantages of SQL over textfiles would be:
1. Parsing: the ability to rapidly parse the database. For example -- if you wanted to find out every guild a player was in, SQL makes this easy.
2. More player information: You can include stuff like guild join dates, player comments (for some sort of guild profile system), "rights" if you were making a complicated "guild bank" or "guild rights" system, etc.
02-22-2015, 11:15 PM
Hybrid Mode
