Openkore.com

Some time ago Bibian and isieo where talking about migrating some tables from "tables" folder to SQLLite Database.

So. I've checked that Idea, and came out with a Tech Design and Draft Database file.

TechDesign:
DB <-- Main Holder package for all the databases (Text or SQLLite, no metter).
DB::CommandsDescription <-- Holder for all the Console Commands
DB::Directions <-- Holder for all the data (like "directions.txt")
DB::Elements <-- Holder for all the data (like "elements.txt")
DB::Emotions <-- Holder for all the data (like "emotions.txt")
DB::EquipTypes <-- Holder for all the data (like "equiptypes.txt")
DB::HairColor <-- Holder for all the data (like "haircolors.txt")
DB::Item <-- Holder for all Item's
DB::ItemTypes <-- Types of Item's
DB::Maps <-- List of all Map's
DB::Monsters <-- List of all Mob's
DB::NPC <-- List of all NPC
DB::Portals <-- List of All portals
DB::Sex <-- name say by itself (May-be a list of all free p*rn sites??? just joking)
DB::Skills <-- List of all Skills
DB::SkillsSp <-- Map of SP usage for every Skill

All those packages will have fixed API:
Get(ID or keyword) <-- Get a record
Set(hash) <-- Set a record
Import(string filename, bool rewrite) <-- Import FileName to DataBase
Export(string filename) <-- Export DataBase to Filename

See attachment file for DB Draft.
Please Note, that it need more Improvements to work fine.

Its probably better if more people can give their input for this.

My input is that SQLite is stupid and persistent databases through associative arrays are much easier. But then again since when did you guys care about my input? I mean It's not like I've been doing this kind of data access for-fucking-ever.

You guys seriously need to forward think about code maintainability. Not about making the code structure look pretty and organized (and enterprisey).

table "item" need add column "price" and "weight" for autobuy.
It is necessary to add support of additional tables, as on different servers different npc, monsters, and deltaHP monsters.

Click wrote:table "item" need add column "price" and "weight" for autobuy.
It is necessary to add support of additional tables, as on different servers different npc, monsters, and deltaHP monsters.

Price is determined serversize and so is weight, we can't fill that data ourselfs cause it can differ on every server... so i would just not add those columns

ps: easier doesnt always mean better >_>

I haven't seen the code implementation yet, but the way the proposed scheme is presented, it looks like some sort of database abstraction layer where we can plug in whatever kind of database we like. In fact, it's probably even possible to write another layer that will translate from SQL into some random access text file.

Is a server c in non-standard weight and the non-standard price of purchase of meat at standard npc? They on all servers identical, and each user can make for the server, the table. The price and weight is the important parametres for shortage avoidance zeny, overweight at purchase, bulk-purchases and cyclings at purchase.

from what i know, it can recompile the current table files into sqlite and it can generate normal txt files again so that we can do version control.

I was reading
How do I redefine a builtin function, operator, or method?
and
overload

According, to what i've read, we could make it compatible with old style.
But that will be "Black Magic", and can cost us a very unreadable code (except that I dunno about sharing blessed variables that use overloaded operators).

kLabMouse wrote:I was reading
How do I redefine a builtin function, operator, or method?
and
overload

According, to what i've read, we could make it compatible with old style.
But that will be "Black Magic", and can cost us a very unreadable code (except that I dunno about sharing blessed variables that use overloaded operators).

well, if stuff is properly documented, we shouldn't have that problem.

i'll probably merge this with trunk after we got reviews from all the key people, then i'll release a beta version