Well, backward campability should be a big point in a community project like this, but maybe that's just my opinion. And forcing people to completely rewrite their tools, isn't nice, too. Adding a field to an existing converter logic is much easier than rethinking the complete logic. I really don't know if the advatages of this update are bigger than the disadvantages. For me personally there are no advatages, so you maybe understand why I'm grumbling.
I'm perfectly fine with backwards compatibility, whenever it doesn't slow down development or force developers to use hacks and workarounds to introduce new features.
Actually, it's been discussed since May 2013.
Can't find a topic. Please send me a link via. PM.
Done~
There's a reason not to do that. We'd be back to a hard to read file format (the import scripts). I personally find it pointless to have the item db in SQL (other than for control panels and such), because, well, it's an info that gets read once on server startup, and cached in any case. SQL is useful if you only need to look up parts of it (like a control panel does), but quite pointless (and an annoyance to keep up to date) if all you need is to SELECT * on server startup.
If one of the two formats were to go away, to me it'd be SQL. But it's gonna stay, mostly for Control Panel purposes.
That's the point. Think of the possibilities of SQL. You would be able to change data while server is running and this not just temporary. You could even create completely new data structures if required for a script. at runtime. (You can do this know, but not when dropping SQL.) Wouldn't whis be an advantage? "Hard to read".. Well, there are many many tools which make it easy to create SQL statements if you don't like typing them, that's not a valid reason in my opinion.
You can't really change the data while the server is running (without reloading the database), but then you can reload the txt version in the same exact way (and possibly even faster than the SQL version).
I don't really understand the 'create new data structures' part. If you mean creating other SQL tables, sure, but it has nothing to do with the item database. If you mean adding fields to the database -- no, you can't do that, since the code that reads from the database is compiled to the server (both for the txt and the SQL version), so you have at the very least to recompile and restart the server.
Also, no matter how you format a SQL statement, it can never become as clean and easy to read as the new item database format. It'll always be a bunch of fields next to each others.
I wish there is also overhaul in
Mob db file structure
this is next on the hit list
It indeed is
I like the idea how you guys changed the item database file structure just for the sake that us server owner and you guys as a developers wants a readable format. In my point of view I can only see:
{ // =================== Mandatory fields =============================== Id: ID (int) AegisName: "Aegis_Name" (string, optional if Inherit: true) Name: "Item Name" (string, optional if Inherit: true) // =================== Optional fields ================================ Type: Item Type (int, defaults to 3 = etc item) Buy: Buy Price (int, defaults to Sell * 2) Sell: Sell Price (int, defaults to Buy / 2) Weight: Item Weight (int, defaults to 0) Atk: Attack (int, defaults to 0) Matk: Magical Attack (int, defaults to 0, ignored in pre-re) Def: Defense (int, defaults to 0) Range: Attack Range (int, defaults to 0) Slots: Slots (int, defaults to 0) Job: Job mask (int, defaults to all jobs = 0xFFFFFFFF) Upper: Upper mask (int, defaults to any = 0x3f) Gender: Gender (int, defaults to both = 2) Loc: Equip location (int, required value for equipment) WeaponLv: Weapon Level (int, defaults to 0) EquipLv: Equip required level (int, defaults to 0) EquipLv: [min, max] (alternative syntax with min / max level) Refine: Refineable (boolean, defaults to true) View: View ID (int, defaults to 0) Script: <" Script (it can be multi-line) "> OnEquipScript: <" OnEquip Script (can also be multi-line) "> OnUnequipScript: <" OnUnequip Script (can also be multi-line) "> // =================== Optional fields (item_db2 only) ================ Inherit: true/false (boolean, if true, inherit the values that weren't specified, from item_db.conf, else override it and use default values)}, 35 lines of code if it's a complete code, 3 lines of mandatory code excluding braces. In my item_db.txt i have 8.3k lines of code and I'm still using the old format, converting it will increase the line and yes parsing is not that fast.
I agree it's readable. Format is good but line consuming. Parsing is not that fast. Size of file increase.
Even if file size increases, I have actually benchmarked it and the parse time decreases. Loading and parsing the old format 1000 times (test done on db/pre_re/item_db.txt) takes 95603ms (average of 93 milliseconds each time), while loading and parsing the new format 1000 times (test done on db/pre_re/item_db.conf) takes 57390ms (so an average of 57 milliseconds).
The tests were done respectively on the latest revision before the item db update appeared (7d0a63b72f93c05b302c08cfb19d5651cef1cdb8) and the latest revision (d1a635a06f5152b51d0879176f011b5c6e45431c), so they are even biased towards the old version, since it had less features back then (BindOnEquip didn't exist, so it was reading one less field.)
Line count isn't relevant to the parse time. The new parser probably uses a more optimized file reading approach (through libconfig), and doesn't need to unnecessarily read fields that are set to their default values (file is bigger, but it actually contains less data.)
If a higher line count disturbs you this much, you can flatten the entire database to ONE line, and it will still work. Make sure you add a semicolon after each value.
This is a perfectly valid item database, if one is that crazy:
item_db: ( { Id: 501; AegisName: "Red_Potion"; Name: "Red Potion"; Type: 0; Buy: 50; Weight: 70; Script: <" itemheal rand(45,65),0; ">; },{ Id: 502; AegisName: "Orange_Potion"; Name: "Orange Potion"; Type: 0; Buy: 200; Weight: 100; Script: <" itemheal rand(105,145),0; ">; },)(but I refuse to understand why anyone would want that)
you didnt even put a single bit of effort into trying to figure it out by yourself
Read the first post, it is briefly explained there. You need a perl interpreter and some (very little) ability to run a command from the command-line.
