Haru

Which is why we have a specific anti-maya-purple-cheat feature in Hercules, that prevents the server from sending the position of hidden or cloaked people altogether.
Your screenshot shows that you're able to see *yourself*. That's because the client always knows where *you* are (for obvious reasons).
You should try with enemy units (mobs, or PvP/GvG enemies), and you'll see that - even if you trick your client into thinking that they never hid or cloaked, it still won't show any of their moves.

Which is why we have a specific anti-maya-purple-cheat feature in Hercules, that prevents the server from sending the position of hidden or cloaked people altogether.
Your screenshot shows that you're able to see *yourself*. That's because the client always knows where *you* are (for obvious reasons).
You should try with enemy units (mobs, or PvP/GvG enemies), and you'll see that - even if you trick your client into thinking that they never hid or cloaked, it still won't show any of their moves.

Which is why we have a specific anti-maya-purple-cheat feature in Hercules, that prevents the server from sending the position of hidden or cloaked people altogether.
Your screenshot shows that you're able to see *yourself*. That's because the client always knows where *you* are (for obvious reasons).
You should try with enemy units (mobs, or PvP/GvG enemies), and you'll see that - even if you trick your client into thinking that they never hid or cloaked, it still won't show any of their moves.

The warnings you show don't seem to be a problem. The plugin should still compile.
 
Line 150 and 155 are two lines that are the same as path.c in Hercules (and they cause a warning in your plugin because of different compiler settings -- you can disable sign comparison check warnings in your VS solution)
Line 501, 566, 567, 568, 569, 570, 571 are recommending the use of a Microsoft-specific function instead of a standard function. For obvious reasons, we can't do that.
 
You can either silence or ignore those warnings. The warnings we generally silence are:
- 4018
- 4100
- 4800
- 4996
(or at the very least, 4018 and 4996 in this case).
 
If there's any other issues that prevent the plugin from working correctly, please let me know.

Hey everyone! I think it's time to add some more 'liveness' to our main page by bringing in more servers to register with us! For this, I'm offering free ad spots for a whole free month!
 
If you visit our ad page, you'll notice I have two advertisement spots labeled. One being Kafra's Bulletin and Kafra's Cover. For new servers that are going to be listed, I'll be giving them a spot (server owner chooses) in Kafra's Bulletin for a full 30 days for free*! 
 
* Terms & Guidelines
Before getting your ad listed with us, there are a few guidelines a server owner must adhere to:
[*]Ad Dimension: 700 x 90 [*]Your server must be newly listed with us [*]You must have a 24/7 up server [*]Must follow our Server Owner Rules [*]You must have a link on your server's homepage that redirects users to review your site on Midgard-Community [*]You must email us at [email protected] with the following criteria (taken from our ad spot): [*]Your username registered here at Midgard-Community [*]You must show your server’s banner (As an attachment or as a link) [*]Name of Advertisement section(s) (names are listed below) [*]Target URL (i.e. landing page) [*]and, the spot you are going to choose for that specific advertisement section (i.e. from review listing, review listing: low rate, etc).



I will only be accepting the first 25 newly listed servers! This will be a first come first served basis. Please check the availability down below for available spots.
 
Availability
To keep track of available spots, here is the current list:
[*]Review Listing (Lists all servers) – (5 / 5) Slots Available [*]Review Listing: Low Rate – (5 / 5) Slots Available [*]Review Listing: Mid Rate – (5 / 5) Slots Available [*]Review Listing: High Rate – (5 / 5) Slots Available [*]Review Listing: Super High Rate – (5 / 5) Slots Available

What is Midgard Community?

- Midgard Community is a Ragnarok Online community that provides various information regarding the world of Ragnarok. We have a Ragnarok Server Listing service that provides space for server owners to list their Ragnarok Online Private Server with us. We provide a download system to the Ragnarok Community which houses multiple files that range from NPC sprites, Class Sprites, Palettes, Maps, Items, Monsters, Cutins/Illustrations, Models, etc. !

 
Does Midgard Community have a Database?

- Midgard Community provides both a Renewal and Pre-Renewal database for our community. Unfortunately, the database is not integrated with the main site. In both databases, you'll find information regarding various Ragnarok items, monsters, and maps. We also have various calculators and informational tables.

 
What is Midgard Community's Download system?

- The download system found in Midgard Community's forum houses tons of files that range from NPC sprites, Class Sprites, Palettes, Maps, Items, Monsters, Cutins/Illustrations, Models, etc. In order to get any files from the system, you must be an active member in the forum. The plan for the download system is to be the #1 stop to get files for a server owner's Ragnarok Server.

 
API (Application Programming Interface)

- As suggested by a member of the community, I've worked diligently with a fellow friend on implementing an API for Midgard's database. When you send a request for either an item or monster, you'll get different structured outputs returned back to you depending on what you've searched for.

 Item

 


Monster
 


However, not anyone can fetch what they want. When you create an account through the main site, if setup, there will be a token assigned to your username. You will need this token in order to fetch data from the database.
 
Required Fields:
api_key id (Item / Monster ID)  
​Optional Field:
type - If no type is given, you'll directly get an item. To get monster, set Type's value to 1.
 
Site Links & Information
Homepage: http://www.midgard-community.com Forums: http://www.board.midgard-community.com Download System: http://www.board.midgard-community.com/files/ Pre-Renewal Database: http://www.database.midgard-community.com Renewal Database: http://www.database.midgard-community.com/renewal

Mumbles: see my reply in the pull request. It actually becomes easier with .@select, as you don't even need to use the @menu variable.
 
Garr: but using labels is even worse than using a switch, and makes the script less readable. If several options lead to the same result, their case labels in the switch can be grouped together without break in between, if you don't wish to use select. Or, nobody forces you to use a switch, and you can use if/else conditions if you prefer.
 

switch (select("a:b:c:d:e")) {case 1:case 2:case 4: mes "a, b and d lead here."; break;case 3: mes "this is c."; break;}// and e does nothing Or
 

.@choice = select("a:b:c:d:e"));if (.@choice == 3) { mes "this is c.";} else if (.@choice < 5) { mes "a, b and d lead here.";}// and e does nothing

Before deciding on the line length (I'm personally for 80, but I'm still fine with 120), I think we should check if limiting it to 80 would cause issues with some scripts (too many indentation levels, or too many NPC headers too wide to fit, since those can't be split into multiple lines, and need to be an exception to the line-length rule, and would cause horizontal scrolling regardless)

I disagree. It makes it unclear at first sight that the block is related to that specific if statement, and it uses too much vertical space unnecessarily. (For the same reason why I dislike excessive amounts of empty lines inside functions, in general. The less lines of code you can fit in your screens, the harder it becomes to understand what a function does.)In some (very few) cases it's necessary to use it, so it needs to be kept in the documentation (perhaps also noting that it is deprecated and it should not be used unless strictly necessary.) 
An example where it is necessary is when you want to set a variable from another npc:
set getvariableofnpc(.foo, "My Other NPC"), 1;

what keys do I have to put in? 
If you don't want to make them up, you can use the keys from any working client (you can find them in src/map/packets.h). Refer to the list posted by KeyWorld to know which ones can be safely used.
 
Do I have to make up those keys?
 
Possibly not. Generate your own keys only if (1) you know exactly how the algorithm works; (2) you are not Gravity; (3) you know how to generate strong keys.
I do not have any recommendations, as I don't have an algorithm to generate strong keys. I'm only able to recognize some classes of weak keys, but some keys I consider strong, may have other weaknesses. Just use keys from other client versions, since both I and KeyWorld have tested them with over 10 million iterations.
 
Do I have to use three different ones?
 
This is not strictly necessary.

what keys do I have to put in? 
If you don't want to make them up, you can use the keys from any working client (you can find them in src/map/packets.h). Refer to the list posted by KeyWorld to know which ones can be safely used.
 
Do I have to make up those keys?
 
Possibly not. Generate your own keys only if (1) you know exactly how the algorithm works; (2) you are not Gravity; (3) you know how to generate strong keys.
I do not have any recommendations, as I don't have an algorithm to generate strong keys. I'm only able to recognize some classes of weak keys, but some keys I consider strong, may have other weaknesses. Just use keys from other client versions, since both I and KeyWorld have tested them with over 10 million iterations.
 
Do I have to use three different ones?
 
This is not strictly necessary.

Out of the current, unmerged, branches:
 
- rathena : It's being kept for historical reference, but it is no longer updated now that rAthena is on GitHub (it'd be pointless and it'd make our repository even larger)
- zones : It was already there before I joined, so I know very little about it. I believe it's a dropped project favor of the HPM interfaces. Ind perhaps knows more about it than I do...
- bcrypt : Stalled until further notice. Gepard is on hiatus, and he's the branch author, even though I have contributed to it as well. I can consider resuming to work on it myself if there's enough demand, but there are some performance concerns that need to be solved/mitigated. It would also require a rewrite of the authentication (and brute-force mitigation) part in control panels or other third party software before being usable.
 
There are also other branches being developed, but they're not part of the main repository yet because they're not mature enough (some of us have branches in their own GitHub fork of the repository)
 
 
Edit: I forgot to mention, none of those branches has its history set in stone yet, so they should be only used if you know to recover your working copy from a history rewrite (rebase, etc)

Try importing the mob_db table. It is used by the character view page to retrieve info about pets.

We need to pull this change from upstream (paypal issue description in the commit message): https://code.google.com/p/fluxcp/source/detail?r=1133

We need to pull this change from upstream (paypal issue description in the commit message): https://code.google.com/p/fluxcp/source/detail?r=1133

We need to pull this change from upstream (paypal issue description in the commit message): https://code.google.com/p/fluxcp/source/detail?r=1133

The reported filename may be incorrect. I just committed a patch that should lead to less misleading error reports (and now shows Unknown when it doesn't have a clue, rather than simply showing the last parsed script). 
If it appears upon player login, it might not be related to any script at all. Doublecheck your SQL database (char_reg_num_db) to see if you have leftovers of a variable named 'zeny', and remove them.
This might now have anything to do with case sensitivity at all, but rather item name constants. If you have an item whose AegisName is 'Zeny' (guessing it's coming from a certain extended shop patch), change it to something else ('Zeny_' or 'Zeny_Token' are good options there). It's complaining because if you have an item with Zeny as AegisName, it'll never know if you want to use the item ID or the player parameter, in cases such as this:if (Zeny < 10000) { mes "You don't have enough money."; close;}

Item DB file structure overhaul
 
Hello~! Uguu~?!
We noticed that the Item Database file format, unchanged for years, is less than optimal (read: terrible)
The file is really hard to read (is it the fifteenth or the sixteenth zero? No wait, that line has an extra comma!!) Whenever you merge an update, if you had a customized entry, you're sure to encounter large conflicts that won't be trivial to solve How do we fix it?
We're switching to a brand new, modern, file format, making use of the libconfig library we're already using for other configuration files.
It uses libconfig. This means the parser is more solid and, perhaps not faster, but surely easier to maintain, with simpler code. And the file format is something you're already used to, since it's the same as many other configuration files we use! Empty fields and the long sequences of those hard to count commas are gone! You just specify the fields you need, and the others can be completely skipped. The item_db2 entries can be left incomplete and set to inherit the original item_db entry. If you have a custom script for your Knife[3], you can just write the script in your item_db, and let it read the other values from the item_db, so that if we update them, you get the update automatically Item scripts can be split into several lines, so they can made easier to read, especially the long ones. We can finally add more fields (to support new features) to the file at any time, easily and without having to edit all the lines (or force you to edit all the lines of your custom item_db2)! Pre-Renewal and Renewal Item databases now use the same format. This also means that you can make use of the min/max level feature in both renewal and pre-renewal (of course, pre-renewal servers will ignore the Matk field, if you specify it, since it's meaningless there) What does it look like?
 
Each entry follows this structure:
{     // =================== 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) }, Here's a Red Potion in the old format:
501,Red_Potion,Red Potion,0,50,,70,,,,,0xFFFFFFFF,7,2,,,,,,{ itemheal rand(45,65),0; },{},{} And here's the same Red Potion in the new format:
{     Id: 501     AegisName: "Red_Potion"     Name: "Red Potion"     Type: 0     Buy: 50     Weight: 70     Script: <" itemheal rand(45,65),0; "> }, Not convinced yet it's easier to read? Okay, let's try a Poison Bottle:
678,Poison_Bottle,Poison Bottle,2,5000,,100,,,,,0xFFFFFFFF,7,2,,,,,,{ if(Class==Job_Assassin_Cross) { sc_start SC_DPOISON,60000,0; sc_start SC_ATTHASTE_INFINITY,60000,0; } else percentheal -100,-100; },{},{} changes to:
{     Id: 678     AegisName: "Poison_Bottle"     Name: "Poison Bottle"     Type: 2     Buy: 5000     Weight: 100     Script: <"         if(Class==Job_Assassin_Cross) {             sc_start SC_DPOISON,60000,0;             sc_start SC_ATTHASTE_INFINITY,60000,0;         }         else percentheal -100,-100;     "> }, Better, isn't it!? Let's now try a Jellopy:
909,Jellopy,Jellopy,3,6,,10,,,,,,,,,,,,,,{},{},{} Count the commas! Did I miss any? An extra comma you say? No, I don't want to count them, thanks...
{     Id: 909     AegisName: "Jellopy"     Name: "Jellopy"     Buy: 6     Weight: 10 }, Not even a comma!
Now, help me read what this item does?
13307,Krieger_Huuma_Shuriken1,Glorious Shuriken,4,20,,0,55,,1,0,0x02000000,7,2,34,4,80,1,22,{ bonus2 bAddRace,RC_DemiHuman,95; bonus2 bIgnoreDefRate,RC_DemiHuman,20; bonus bMatkRate,15; autobonus "{ bonus2 bSkillAtk,NJ_HUUMA,100; bonus2 bSkillAtk,NJ_ISSEN,100; }",50,10000; bonus bUnbreakableWeapon,0; if(getrefine()>5) { bonus2 bAddRace,RC_DemiHuman,(getrefine()-3)*(getrefine()-3); bonus2 bIgnoreDefRate,RC_DemiHuman,5; } if(getrefine()>8) { bonus5 bAutoSpellOnSkill,NJ_ISSEN,AL_HEAL,10,1000,1; bonus4 bAutoSpellOnSkill,NJ_HUUMA,NPC_CRITICALWOUND,2,200; } },{},{} {     Id: 13307     AegisName: "Krieger_Huuma_Shuriken1"     Name: "Glorious Shuriken"     Type: 4     Buy: 20     Atk: 55     Range: 1     Job: 0x02000000     Loc: 34     WeaponLv: 4     EquipLv: 80     View: 22     Script: <"         bonus2 bAddRace,RC_DemiHuman,95;         bonus2 bIgnoreDefRate,RC_DemiHuman,20;         bonus bMatkRate,15;         autobonus "{ bonus2 bSkillAtk,NJ_HUUMA,100; bonus2 bSkillAtk,NJ_ISSEN,100; }",50,10000;         bonus bUnbreakableWeapon,0;         if(getrefine()>5) {             bonus2 bAddRace,RC_DemiHuman,(getrefine()-3)*(getrefine()-3);             bonus2 bIgnoreDefRate,RC_DemiHuman,5;         }         if(getrefine()>8) {             bonus5 bAutoSpellOnSkill,NJ_ISSEN,AL_HEAL,10,1000,1;             bonus4 bAutoSpellOnSkill,NJ_HUUMA,NPC_CRITICALWOUND,2,200;         }     "> }, Which one did you find easier to read? Old or new format?
 
Want to see an example that specifies both min and max levels? Here you go:
{     Id: 2819     AegisName: "Swordman_Manual"     Name: "Swordman Manual"     Type: 5     Buy: 0     Weight: 100     Job: 0x00000001     Upper: 47     Loc: 136     EquipLv: [1, 12]     Refine: false     Script: <"         bonus bMaxSP,100;         skill SM_BASH,1;         skill SM_PROVOKE,1;         skill SM_MAGNUM,1;     "> }, Okay, one last example. Let's try to make an item_db2 entry for a Pupa Card that gives a bonus of 1000 HP rather than just 700.
{     Id: 4003     Inherit: true     Script: <" bonus bMaxHP,1000; "> }, Done. No need to rewrite the name, location, prices... those are already in the item_db!
 
But... I have several custom items, do I have to manually convert all of them...?
 
Of course you do! No, I'm kidding, don't hate me
 
It's true that you need to convert your item database to the new format, but we can do it for you!
Go to http://haru.ws/hercules/itemdbconverter/ and paste (or upload) your item_db2.txt (or even your item_db.txt if you have custom entries there), press the Convert button, wait a few seconds and you're done! It's already converted for you. Easy, isn't it? Don't trust us? No, no, we don't need your custom items, you can sleep safe... But if you still don't want to paste anything on a website... well, we have provided the source code of the converter script! It's in the 'tools' folder of the Hercules repository. All you need is a Perl interpreter (and if you're running Linux or Mac OS, on either your server or your own computer, it's almost certain that you already have that). All you have to do is run it (example: perl tools/itemdbconverter.pl < db/item_db2.txt > db/item_db2.conf), and your item database will be converted in a split second! What if I was using SQL item databases?
 
Well... Then you won't have to worry about the txt databases, unless you were creating the items in txt, then converting them to sql (if you're not doing this, maybe you should consider it, you know? It's easier to create and manage them in txt even if you use the sql version!)
 
If you were converting your custom item databases from the txt version to sql through the db2sql plugin, there are good news for you! We just updated the plugin, and now it's able to create a .sql script rather than just inserting the entries into your database. This means that you can create the SQL entries in your own computer, without even needing a database (just a copy of Hercules), without risking to slow down your server, and then upload them whenever you want.
 
And if you're relying on the .sql scripts we provide... well, there are still good news for you! Outdated item_db.sql files are a thing of the past now: those scripts will get updated automatically after every commit by our HerculesWS API bot, exactly like the HPM Hooks!
 
As a final note, now the pre-re and re databases share the same structure in SQL as well! no more column mismatch if you're trying to import into your Renewal server an item that was meant for pre-renewal.
 
If you have data already imported to your item_db2 SQL table, it'll be updated to the new table format through the regular upgrade sql mechanism (just run the provided script in the sql-files/upgrades folder). Please note that the script requires MySQL 5.0 or newer -- if you're still on MySQL 4.0, please open it in a text editor, read the comments and run the provided queries manually.
 
I have this event item entry that came with an old script I downloaded...
 
No worries, you can get it converted. Use the same script (or the provided web page) you'd use to convert an entire item database, it'll work just fine even for an item or two!
 
Special thanks
To Ind, for bringing up the idea and pushing it forward until it was implemented. And for his awesome work on the HerculesWS API and database converter plugin. To Yommy, for the original idea, and for some invaluable help finalizing the actual database format. Links~u!
Main commit. Removed redundant item_db2_re.sql (now both have the same structure). db2sql plugin update. item_db2 inheritance. item_db2 SQL upgrade script.

Yep, it's slower because it does more operations, since it needs to swap values from two arrays instead of one~

Yup, I think so too (decreasing readability but oh well, if a script is performance-critical)  
Ah I just noticed an error in the script. In the do/while condition, there's a .@gap > 10 that should be .@gap10 > 10 (I had to introduce that extra gap10 variable because of some checks that were getting messed up because of the division by 1.3, and forgot to update it through the script.Not so much compared to today's standards, it's a late-2009 iMac with an i7-870 cpu... But it still works reasonably well Yes, this is certainly true. As keyworld said, they compile to different assembly, and the for one calls more jump commands.With some luck, we might be able to get an even faster implementation. Just theoretical right now, but there's something in the works That's to avoid affecting the original array, and let the function work on a local copy when it does the swaps.Hmm, I see. Then how about, instead of using the .@output array as index, you sort @inventorylist_id, and whenever you do one swap on it, you do the very same swap on @inventorylist_amount as well? 
Here's two examples (untested, sorry if there's any error). First one sorts in place *both* the original arrays, so you just need to print @inventorylist_id[.@i] and @inventorylist_amount[.@i]. Second one should be what you wanted, it doesn't sort the original arrays at all, and only returns the array of sorted indices, so that you need to print @inventorylist_id[ .@output[.@i] ] and @inventorylist_amount[ .@output[.@i] ]:
 
http://upaste.me/5c1c8f
(changing the for() to while() is left as an exercise to the reader )
 
//Edit: did I ever say I hate IPB's broken bbcode parser?

Here's some optimizations to those functions, as well as an iterative, bottom-up implementation of mergesort.
 
http://upaste.me/20dc8e
 
This is how they perform on my Hercules copy, using 1000-element arrays:
 
Mergesort (recursive):
[Debug]: script debug : 0 110000001 : time used -> 131 milli-secondsMergesort (bottom-up):[Debug]: script debug : 0 110000002 : time used -> 89 milli-secondsCombsort:[Debug]: script debug : 0 110000003 : time used -> 98 milli-secondsFor question 2: what about a parallel array of indices, that you swap when you swap the main one?

Here's some optimizations to those functions, as well as an iterative, bottom-up implementation of mergesort.
 
http://upaste.me/20dc8e
 
This is how they perform on my Hercules copy, using 1000-element arrays:
 
Mergesort (recursive):
[Debug]: script debug : 0 110000001 : time used -> 131 milli-secondsMergesort (bottom-up):[Debug]: script debug : 0 110000002 : time used -> 89 milli-secondsCombsort:[Debug]: script debug : 0 110000003 : time used -> 98 milli-secondsFor question 2: what about a parallel array of indices, that you swap when you swap the main one?

HPM Data Check
I begin by thanking ai4rei for bringing this to our attention HELLOOOO, WHAT?! This introduces automatic data integrity insurance between plugins and the core, allowing the core to reject loading plugins whose data structures mismatch those in the core thus preventing potential crashes and loose data read/write, it goes a long way towards making this issue being inexistent. In short: its a feature that enables the core to reject "outdated" plugins, "outdated" meaning that a data struct used by the plugin has been modified in the core while the plugin was not recompiled to reflect the change. It is smartThanks to Haru's design the feature is able to identify the files which the plugin relies on, therefore even if data structs in the core have been modified the plugin will only fail load if its a data struct from a file it actually includes Changes: Hello Plugin Developers!
Plugins are now required to include the HPMDataCheck file, plugins without it will not pass loading validation, to include use: #include "../common/HPMDataCheck.h"it should be the last file included, if it isn't the last it'll render the plugin uncompilable (intentionally). ...and thats it, it stands on its own afterwards. Also in & Thanks to Haru
the HPMHookGen has been updated so that the data HPMDataCheck relies on is always up to date HPMHookGen has been sped up. New Possibilities
Thanks to HPMDataCheck enabling the core to know which files the plugin relies on there are many enhancements we can (and intend to) add, for example, drop GET_SYMBOL entirely and have the core load the interfaces automatically Special Thanks to
Haru ai4rei Link'u
HPMHookGen Update Commit

MEGA UPDATE: NEMO 2.0 has been released. Please check the first post for more details.

Item DB file structure overhaul
 
Hello~! Uguu~?!
We noticed that the Item Database file format, unchanged for years, is less than optimal (read: terrible)
The file is really hard to read (is it the fifteenth or the sixteenth zero? No wait, that line has an extra comma!!) Whenever you merge an update, if you had a customized entry, you're sure to encounter large conflicts that won't be trivial to solve How do we fix it?
We're switching to a brand new, modern, file format, making use of the libconfig library we're already using for other configuration files.
It uses libconfig. This means the parser is more solid and, perhaps not faster, but surely easier to maintain, with simpler code. And the file format is something you're already used to, since it's the same as many other configuration files we use! Empty fields and the long sequences of those hard to count commas are gone! You just specify the fields you need, and the others can be completely skipped. The item_db2 entries can be left incomplete and set to inherit the original item_db entry. If you have a custom script for your Knife[3], you can just write the script in your item_db, and let it read the other values from the item_db, so that if we update them, you get the update automatically Item scripts can be split into several lines, so they can made easier to read, especially the long ones. We can finally add more fields (to support new features) to the file at any time, easily and without having to edit all the lines (or force you to edit all the lines of your custom item_db2)! Pre-Renewal and Renewal Item databases now use the same format. This also means that you can make use of the min/max level feature in both renewal and pre-renewal (of course, pre-renewal servers will ignore the Matk field, if you specify it, since it's meaningless there) What does it look like?
 
Each entry follows this structure:
{     // =================== 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) }, Here's a Red Potion in the old format:
501,Red_Potion,Red Potion,0,50,,70,,,,,0xFFFFFFFF,7,2,,,,,,{ itemheal rand(45,65),0; },{},{} And here's the same Red Potion in the new format:
{     Id: 501     AegisName: "Red_Potion"     Name: "Red Potion"     Type: 0     Buy: 50     Weight: 70     Script: <" itemheal rand(45,65),0; "> }, Not convinced yet it's easier to read? Okay, let's try a Poison Bottle:
678,Poison_Bottle,Poison Bottle,2,5000,,100,,,,,0xFFFFFFFF,7,2,,,,,,{ if(Class==Job_Assassin_Cross) { sc_start SC_DPOISON,60000,0; sc_start SC_ATTHASTE_INFINITY,60000,0; } else percentheal -100,-100; },{},{} changes to:
{     Id: 678     AegisName: "Poison_Bottle"     Name: "Poison Bottle"     Type: 2     Buy: 5000     Weight: 100     Script: <"         if(Class==Job_Assassin_Cross) {             sc_start SC_DPOISON,60000,0;             sc_start SC_ATTHASTE_INFINITY,60000,0;         }         else percentheal -100,-100;     "> }, Better, isn't it!? Let's now try a Jellopy:
909,Jellopy,Jellopy,3,6,,10,,,,,,,,,,,,,,{},{},{} Count the commas! Did I miss any? An extra comma you say? No, I don't want to count them, thanks...
{     Id: 909     AegisName: "Jellopy"     Name: "Jellopy"     Buy: 6     Weight: 10 }, Not even a comma!
Now, help me read what this item does?
13307,Krieger_Huuma_Shuriken1,Glorious Shuriken,4,20,,0,55,,1,0,0x02000000,7,2,34,4,80,1,22,{ bonus2 bAddRace,RC_DemiHuman,95; bonus2 bIgnoreDefRate,RC_DemiHuman,20; bonus bMatkRate,15; autobonus "{ bonus2 bSkillAtk,NJ_HUUMA,100; bonus2 bSkillAtk,NJ_ISSEN,100; }",50,10000; bonus bUnbreakableWeapon,0; if(getrefine()>5) { bonus2 bAddRace,RC_DemiHuman,(getrefine()-3)*(getrefine()-3); bonus2 bIgnoreDefRate,RC_DemiHuman,5; } if(getrefine()>8) { bonus5 bAutoSpellOnSkill,NJ_ISSEN,AL_HEAL,10,1000,1; bonus4 bAutoSpellOnSkill,NJ_HUUMA,NPC_CRITICALWOUND,2,200; } },{},{} {     Id: 13307     AegisName: "Krieger_Huuma_Shuriken1"     Name: "Glorious Shuriken"     Type: 4     Buy: 20     Atk: 55     Range: 1     Job: 0x02000000     Loc: 34     WeaponLv: 4     EquipLv: 80     View: 22     Script: <"         bonus2 bAddRace,RC_DemiHuman,95;         bonus2 bIgnoreDefRate,RC_DemiHuman,20;         bonus bMatkRate,15;         autobonus "{ bonus2 bSkillAtk,NJ_HUUMA,100; bonus2 bSkillAtk,NJ_ISSEN,100; }",50,10000;         bonus bUnbreakableWeapon,0;         if(getrefine()>5) {             bonus2 bAddRace,RC_DemiHuman,(getrefine()-3)*(getrefine()-3);             bonus2 bIgnoreDefRate,RC_DemiHuman,5;         }         if(getrefine()>8) {             bonus5 bAutoSpellOnSkill,NJ_ISSEN,AL_HEAL,10,1000,1;             bonus4 bAutoSpellOnSkill,NJ_HUUMA,NPC_CRITICALWOUND,2,200;         }     "> }, Which one did you find easier to read? Old or new format?
 
Want to see an example that specifies both min and max levels? Here you go:
{     Id: 2819     AegisName: "Swordman_Manual"     Name: "Swordman Manual"     Type: 5     Buy: 0     Weight: 100     Job: 0x00000001     Upper: 47     Loc: 136     EquipLv: [1, 12]     Refine: false     Script: <"         bonus bMaxSP,100;         skill SM_BASH,1;         skill SM_PROVOKE,1;         skill SM_MAGNUM,1;     "> }, Okay, one last example. Let's try to make an item_db2 entry for a Pupa Card that gives a bonus of 1000 HP rather than just 700.
{     Id: 4003     Inherit: true     Script: <" bonus bMaxHP,1000; "> }, Done. No need to rewrite the name, location, prices... those are already in the item_db!
 
But... I have several custom items, do I have to manually convert all of them...?
 
Of course you do! No, I'm kidding, don't hate me
 
It's true that you need to convert your item database to the new format, but we can do it for you!
Go to http://haru.ws/hercules/itemdbconverter/ and paste (or upload) your item_db2.txt (or even your item_db.txt if you have custom entries there), press the Convert button, wait a few seconds and you're done! It's already converted for you. Easy, isn't it? Don't trust us? No, no, we don't need your custom items, you can sleep safe... But if you still don't want to paste anything on a website... well, we have provided the source code of the converter script! It's in the 'tools' folder of the Hercules repository. All you need is a Perl interpreter (and if you're running Linux or Mac OS, on either your server or your own computer, it's almost certain that you already have that). All you have to do is run it (example: perl tools/itemdbconverter.pl < db/item_db2.txt > db/item_db2.conf), and your item database will be converted in a split second! What if I was using SQL item databases?
 
Well... Then you won't have to worry about the txt databases, unless you were creating the items in txt, then converting them to sql (if you're not doing this, maybe you should consider it, you know? It's easier to create and manage them in txt even if you use the sql version!)
 
If you were converting your custom item databases from the txt version to sql through the db2sql plugin, there are good news for you! We just updated the plugin, and now it's able to create a .sql script rather than just inserting the entries into your database. This means that you can create the SQL entries in your own computer, without even needing a database (just a copy of Hercules), without risking to slow down your server, and then upload them whenever you want.
 
And if you're relying on the .sql scripts we provide... well, there are still good news for you! Outdated item_db.sql files are a thing of the past now: those scripts will get updated automatically after every commit by our HerculesWS API bot, exactly like the HPM Hooks!
 
As a final note, now the pre-re and re databases share the same structure in SQL as well! no more column mismatch if you're trying to import into your Renewal server an item that was meant for pre-renewal.
 
If you have data already imported to your item_db2 SQL table, it'll be updated to the new table format through the regular upgrade sql mechanism (just run the provided script in the sql-files/upgrades folder). Please note that the script requires MySQL 5.0 or newer -- if you're still on MySQL 4.0, please open it in a text editor, read the comments and run the provided queries manually.
 
I have this event item entry that came with an old script I downloaded...
 
No worries, you can get it converted. Use the same script (or the provided web page) you'd use to convert an entire item database, it'll work just fine even for an item or two!
 
Special thanks
To Ind, for bringing up the idea and pushing it forward until it was implemented. And for his awesome work on the HerculesWS API and database converter plugin. To Yommy, for the original idea, and for some invaluable help finalizing the actual database format. Links~u!
Main commit. Removed redundant item_db2_re.sql (now both have the same structure). db2sql plugin update. item_db2 inheritance. item_db2 SQL upgrade script.