Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)
-   -   Databases and text file usages (https://forums.graalonline.com/forums/showthread.php?t=134269874)

khortez 02-22-2015 11:15 PM

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.

Elk 02-23-2015 03:22 AM

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

khortez 02-23-2015 04:40 AM

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

MysticalDragon 02-23-2015 07:06 AM

Quote:

Originally Posted by khortez (Post 1734867)
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.

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.

Cubical 02-23-2015 02:11 PM

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

khortez 02-23-2015 04:39 PM

Quote:

Originally Posted by MysticalDragon (Post 1734895)
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.

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.

cbk1994 02-24-2015 05:45 AM

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.

Quote:

Originally Posted by khortez (Post 1734918)
But I could use a mixture of different methods? IE: clientr. + DB/textfiles?

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.

khortez 02-24-2015 03:23 PM

Quote:

Originally Posted by cbk1994 (Post 1734969)
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

MysticalDragon 02-24-2015 03:55 PM

Quote:

Originally Posted by khortez (Post 1734991)
Ah, I think I understand that. Thanks everyone

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

Tim_Rocks 02-24-2015 04:07 PM

Quote:

Originally Posted by MysticalDragon (Post 1734992)
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.

khortez 02-24-2015 06:29 PM

Quote:

Originally Posted by Tim_Rocks (Post 1734993)
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

Tim_Rocks 02-24-2015 07:24 PM

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.

scriptless 02-25-2015 02:49 AM

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

cbk1994 02-25-2015 05:26 AM

Quote:

Originally Posted by MysticalDragon (Post 1734992)
Don't use DB NPCs to store guild data, later on you will regret that decision.

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.

khortez 02-26-2015 12:23 AM

Quote:

Originally Posted by scriptless (Post 1735025)
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 :)

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


All times are GMT +2. The time now is 08:01 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.