Databases and text file usages
 

It was mentioned that using DB NPCs and text files were better to save information like guilds rather than using clientr flags. Is the usage between the two preference?

IE: Choosing DB over text files or clientr.

And what are all the advantages of using the two methods?

Just looking to get the most information out of these methods that I can. Thanks for any assistance.

i guess clientr isnt as easy to control as txt :0 as client flags are stored individually within player attributes... has a better structure and the source to read is only one then, instead of having the flags all scrambled over accross different accounts

DB NPCs?...

Sorry for any confusion, I just mean databases.

Edit: just to say I've never used text files before, so getting into them is new for me. And I'm just getting the hang of using Databases

Honestly, its faster to store them in clientr. variables. But the choice really comes down to what features you plan to add? Do you plan on having GUI Profiles, where you can look up other guilds or are you only storing personal data? You could use a combination of both really, cache the information from SQL and store it on the player for a faster process.

text files are wack, store everthing in .bmp images and code your own OCR.

Wouldn't even know where to begin with SQL(never used it/learned it before). But I could use a mixture of different methods? IE: clientr. + DB/textfiles?

Hmm, I'll just make this part easy and say I really wouldn't know the best method then lol. I do plan on adding a lot of features.

Imagine you wish to find a list of all players in a certain guild. If you store the guild as a clientr variable (like clientr.guild=Vimes), then if you wanted to list all players in Vimes, you need to search every player who has ever logged on to the server. (This is impractically slow for most uses.)

If you store it in a text file or DB NPC, you could instead store an array guild.Vimes=cbk1994,Seeya and easily get that list.

You could, but beware problems which might result in inconsistent data between the two. Imagine you open a player's attributes via RC, they join a guild, then you save their attibutes. The DB NPC will have been updated, but not the player flags. Having a single source of data helps to keep things consistent and prevent subtle bugs.

Ah, I think I understand that. Thanks everyone

Don't use DB NPCs to store guild data, later on you will regret that decision.

Yeah, use SQL. Works wonders for guild related system. It's convienant especially when players are offline. If you want to edit a players rank, remove them, or send invites. Just update a row in your SQL database.

If SQL is the best way.. My only question would be, where would I begin learning it? Chompy gave me his source. but if anyone has other sources Id be happy to look at them all

Honestly, setting it up is really easy. I'd lookup SQLite and take tutorials on it. There's not a lot that's different other than syntax. I'm sure others here have really great resources to provide.

Basically you should do what Tim just said. Thats great advice since graal uses sqlite. However if you want you can go to youtube and watch a few video tutorials. Then head over the W3 School's and look up query examples. You would be surprised how much even those of us who know this stuff have to constantly look back at references. As long as you kinda get the idea of how it works you should be fine. If you want, for extra credit you can look up advanced sql techniques such as the logic data modeling that I learned about a few years ago and theres plenty of other optimizations you can do however just the basics will work very well with graal :)

Perfect is the enemy of the good. Even better to design your code so you can swap out the implementation easily, should you want to, in the future.

will do the best i can. though i wish the information wasn't such a pain to reach. learning to code in itself is an animal, especially with information in every which way. and then there's SQL... but regardless the advice and help from everyone is much appreciated. i'll do what i have to to get what i need done

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:
the following is now true:
You can easily pass this information to the client if you want to:

On the clientside:

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:

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:

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.

I'd use SQL.

Create a table for guilds (storing owner account, name of guild, guild ID etc) and a table for members (guild id, members, leader, rights etc). Link the Guild ID together as primary keys for faster results.

If you don't know SQL, please research it. Otherwise you're going to have issues.

So much information at once. Nice to see. in any case thanks guys. yeah i'll look into these methods. will just get my feet deeper into GS2 and then play around with SQL to get a better feel. still some things i don't know just yet

bump due to relevance