Aleos

So long yaml-cpp, hello rapidyaml! As of Git Hash: d1b7061, rAthena has transitioned from using yaml-cpp as the 3rd party tool for parsing YAML files to rapidyaml (or ryml). What this means: The yaml-cpp library gave us a great start into the world of yaml, but as we made more conversions of our databases from CSV to YAML, the load time began to grow. The ryml content is parsed into a single index-based array which is not like any standard STL. On average, ryml parses YAML at about ~150MB/s on Linux and ~100MB/s on Windows (vs2017). Compared to yaml-cpp, ryml is in general between 10 and 70 times faster! An optimization was also made to itemdb_searchname1 function which reduced its complexity to constant. Item database parsing function also has reduced complexity to linear complexity. This results in reduced loading time in debug mode to a fifth compared to using yaml-cpp! What this means to developers: Overall testing and usage of rAthena is much faster, in debug and release modes. We’ve kept our YamlDatabase class the same! This means that over 99% of the structure from using yaml-cpp carried over to ryml in terms of source side work. The YAML files themselves require no updates or changes! Other than that, enjoy the extra speed! Thanks to @Lemongrass, @Secrets, and @nitrous for their help in getting this implemented! PS: I realize I posted this on April 1st, but I can guarantee this update is quite the contrary!

It's not fully the STL fault in this case, but yaml-cpp. We have a pull request open (Pull: 5997) which we are working on migrating to ryml which has a significantly faster parse time.

MobDB -> YAML! As of Git Hash: 7992e08, rAthena's monster database has been converted to YAML! Sorry for the delay of this post! What this means: The monster database being in YAML format means that the database is now much more human-readable, just like the item database. This allows for quick review, modification, and addition of monsters without having to memorize the CSV format or use any third party tools. The parser now also has much better error handling when reading monsters into memory so tracking down those pesky typos is a thing of the past! The update combines mob_race2 and mob_drop databases into the mob_db so there is much less searching around multiple databases when doing anything with monsters! The Mode field has been adjusted. rAthena will now be following the Aegis format of utilizing AI and Class to define monster modes. Don't fret, the Mode field is still fully supported for any custom monster modes! A detailed document with the AI and Class values can be found in doc/mob_db_mode_list.txt. Each monster can now be classified with multiple RaceGroups. Before a monster was limited to a single group, but that is a thing of the past! As with any YAML conversion we have provided an option in the CSV2YAML tool built right into rAthena! Just build the CSV2YAML tool within Visual Studio or via Make and run the executable. The tool will provide you with general steps and convert your custom monsters right on over to the YAML format! Following suit with the item database conversion, the monster database will still support SQL! Simply continue to utilize the YAML2SQL tool which can convert the YAML monster database into SQL format. This allows servers who utilize SQL to continue with this method. What this means to developers: Pull Requests can be reviewed much quicker and much more simpler. Identifying the actual change to the monster and easily verifying said change without having to count commas! Comparing monster data to Aegis becomes easier for the AI and Class as it's easy to identify immediately what the monster's mode should be without having to count the custom mode bits in rAthena. Additional features being added to the monster database no longer requires the development of a side database. A vast majority of the monster data is now part of the mob_db structure and can continue to grow in this format! As already seen with the Green Aura for MVP update from kRO. Redefined Import System: Now that the mob_db is in YAML format, the adjustment of monsters is much simpler. If a change is being made to an monster only the parts that are being changed have to be defined in the import. Below are some examples: Adjusting Scorpion attack to 1000. - Id: 1001 Attack: 1000 Allow Amon Ra to walk and adjust the Yggdrasil Berry to a Diamond at 80% drop rate. - Id: 1511 Modes: CanMove: true MvpDrops: - Item: Diamond Rate: 8000 Index: 0 Check out the mob_db documentation for further details! Thanks to @Lemongrass, @nitrous, and lukasrmattos for their help!

ItemDB -> YAML! As of Git Hash: 04cfe17, rAthena's item database has been converted to YAML! What this means: The item database being in YAML format means that the database is now much more human-readable. This allows for quick review, modification, and addition of items without having to memorize the CSV format or use any third party tools. The parser now also has much better error handling when reading items into memory so tracking down those pesky typos is a thing of the past! The update combines item_avail, item_buyingstore, item_delay, item_flag, item_nouse, item_stack, and item_trade databases into the item_db so there is much less searching around multiple databases when doing anything with items! As items are no longer defined in a single row, this means the flat file has grown in size. To ease the on load text editors for people's computers who may not have the horsepower we split the items as they are in game via Consumables, Equipment, and Etc. The Job restriction for items has been cleaned up so that custom masks don't have to be made and removes a horrible restriction for those adding custom classes to their servers. Now it's as easy as defining the EAJ_* constant... and that's it! The item combo system has had a massive cleanup in the background. We no longer do sketchy memory management and manipulation with a move to use standard libraries provided by C++11! As with any YAML conversion we have provided an option in the CSV2YAML tool built right into rAthena! Just build the CSV2YAML tool within Visual Studio or via Make and run the executable. The tool will provide you with general steps and convert your custom items right on over to the YAML format. No muss, no fuss! Something that was brought up in the Pull Request was the support for SQL. Many people were against the move to YAML because the support for SQL was compromised. Well, we are happy to say that SQL is still supported and isn't going anywhere! We've developed a new tool, YAML2SQL, which can convert the YAML item database into SQL format. This allows servers who utilize SQL to continue with this method. We've also gone a step further and provided a SQL View which will create a new compatibility table without breaking support for your Control Panel/databases. The SQL View is optional though once the Control Panel/database is setup to utilize the new table. The new and fuller item data in this table also provides much more detail to the item database than ever before! You can read more details in our README! What this means to developers: Pull Requests can be reviewed much quicker and much more simpler. Identifying the actual change to the item and easily verifying said change without having to count commas! Additional features being added to the item database no longer requires the development of a side database. A vast majority of the item data is now part of the item_db structure and can continue to grow in this format! Redefined Import System: Now that the item_db is in YAML format, the adjustment of items is much simpler. If a change is being made to an item only the parts that are being changed have to be defined in the import. Below are some examples: Adjusting Red_Potion weight to 10 and increasing the heal rate in the script. - Id: 501 Weight: 100 Script: | itemheal rand(100,120),0; Remove the Thief classes from being able to equip the Cap. - Id: 2226 Jobs: Assassin: false Rogue: false Thief: false Add a stack limit of 10 to Meat for inventory only. - Id: 517 Stack: Amount: 10 Inventory: true Check out the item_db documentation for further details! Thanks to @Lemongrass, @Capuche, and @Cydh for their help!

That would be the best place to start, yes. This is if you don't have access directly to kRO or an Aegis server with the content you're testing for.

The data on DP is valid data from Aegis. Other parts of the data that weren't gathered through Aegis leaks are gathered through replays. Depending on the server you choose in the top right it will display the appropriate results from that location. iRO Wiki DB is specific to iRO and is severely out dated compared to kRO, let alone iRO is well known for customization or feature picking parts out of kRO. iRO also went through a revamp recently to where they should be more aligned with kRO. Reading a couple posts on their recent updates though shows they are still feature picking parts. But overall I would use iRO Wiki DB has a 4th or 5th source. RMS is essentially rAthena data. Whether yC has tools that combine data from other emulators now I'm not sure (and I doubt this part). In the past RMS was using eAthena data and then started using rAthena data.

Implemented in Git Hash: ac558d7.

I've pretty much completed this a while ago. The only problem is after talking with some people who have been testing these on kRO, they have stated more has changed than what is listed in their changelog. I may end up just opening a PR and incrementally update each skill as more information is collected. I personally don't have time to test each skill on kRO.

That's because Hercules doesn't have it properly implemented. (See Git Hash: 842e30e). Using progressbar in an item script isn't something I would suggest as there is a bit of logic behind it that will break any bonuses after the progressbar if the player walks.

*skill_damage {<skill_name>,<caster>,<SKILLDMG_PC>,{<SKILLDMG_MOB>,{<SKILLDMG_BOSS>,{<SKILLDMG_OTHER>}}}} Enables skill damage adjustment on a map. All adjustments in 'db/skill_damage_db.txt' for 'Map' type 16 will be applied. This mapflag can also be used to adjust the damage of one skill by a percentage: - skill_name: Name of the skill in 'db/(pre-)re/skill_db.txt' (ex. SM_BASH). To adjust all skill damage, write "all" (without quotes). - caster: the groups for which the adjustment takes effect. (bitmask) BL_PC = Player BL_MOB = Monster BL_PET = Pet BL_HOM = Homunculus BL_MER = Mercenary BL_ELEM = Elemental - damage: percent adjustment rate (between -100 and 100000). SKILLDMG_PC = against player SKILLDMG_MOB = against normal monster SKILLDMG_BOSS = against boss monster SKILLDMG_OTHER = against other (homunculus, mercenary, pet, elemental) You can set a mapflag and then use "all" as the skill name so it adjusts all skills.

No, the script defines are exactly the same so you shouldn't have to worry about updating any custom scripts of yours.

Mapflag System Refactor As of Git Hash: a942853, rAthena Mapflag System has been refactored for the future! Features: Perhaps the biggest benefit to this update is how easy it is to add new mapflags. Adding a new boolean mapflag is as easy as defining a new enum value in the mapflag enum and creating a script constant! That's it! More complex mapflags can be added to the setter with their own unique checks if required. Everything is now consolidated to reduce redundancy that was all over the place which made adding new mapflags painful. There are now getter and setter functions source side when interacting with mapflags. Renamed mapflag nosumstarmiracle to nosunmoonstarmiracle. Some things that are somewhat minimal but help memory utilization: Mapflag pvp_nightmaredrop values are now stored as a vector. Mapflag skill_damage values are now stored as a vector. The global map index are now stored as a vector. Thanks to @Lemongrass for a lot of help and @Secrets for tips! Don't forget to leave comments and testing results! Thanks!

Even if it's a generic response, we don't manage Gravity or their client updates/features. Common users don't necessarily need to be using unsupported software. A quick Google search returns this. So if it was added back then you'd need some version dated after that post.

Windows XP has gone EOL ages ago and Microsoft has even stopped LTS for it years ago (around 2016). Your users should consider seriously updating as there are many security threats posed by using an unsupported operating system. There are options for you to use an older RO EXE but you may lose some features that are released in there depending on the version you choose. I'm sorry but those are your only two options.