- Popular Post
Aleos
-
Posts
732 -
Joined
-
Days Won
73
Content Type
Profiles
Forums
Downloads
Jobs Available
Server Database
Third-Party Services
Top Guides
Store
Crowdfunding
Posts posted by Aleos
-
-
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: 1000Allow 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: 0Check out the mob_db documentation for further details!
Thanks to @Lemongrass, @nitrous, and lukasrmattos for their help!
-
3
-
2
-
1
-
-
- Popular Post
- Popular Post
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: falseAdd a stack limit of 10 to Meat for inventory only.
- Id: 517 Stack: Amount: 10 Inventory: trueCheck out the item_db documentation for further details!
Thanks to @Lemongrass, @Capuche, and @Cydh for their help!
-
6
-
12
-
2
-
2
-
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.
-
2
-
-
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.
-
1
-
-
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.
-
1
-
-
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.
-
3
-
-
*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!
-
6
-
1
-
1
-
Perhaps the biggest benefit to this update is how easy it is to add new mapflags.
-
19 minutes ago, Ai4rei said:
Thank you very much for this microsoft-support-staff-esque answer. Actually I consider it quite rude if services dictate what kind of OS or browser its users have to use, just because they have incompetent devs.
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.
-
1
-
1
-
-
You need to specify the count along with the mob ID.
- ID: 400041 Group: "AG_BATTLE" Name: "Legendary Killing Part 1" Target: - MobID: 1086 Count: 1 - MobID: 1115 Count: 1 - MobID: 1150 Count: 1 - MobID: 1159 Count: 1 - MobID: 1112 Count: 1 - MobID: 1583 Count: 1 - MobID: 1492 Count: 1 - MobID: 1046 Count: 1 - MobID: 1252 Count: 1 - MobID: 1418 Count: 1 Reward: ItemID: 32609 Amount: 10 Score: 100This achievement will require these 10 monsters to be killed (in no order).
-
Sorry, but I don't see the benefit to adding full support of Ragnarok Zero. We are already months/years behind renewal and adding this on top of our limited staff resources would just not work out well. Although it's still available for users to go about and get the information and release it for public.
The link you provided above only adds support for the Ragnarok Zero clients, which I'm not against for that but could lead to differences in the future.
-
2
-
-
Please keep support questions in the support section. Moving topic.
I suggest you check out the rAthena Wiki so that you can familiarize yourself with making sure you have what you need.
-
Please keep your support questions to the support section. Moved topic.
-
You shouldn't have to touch anything in those files. I would revert all the changes you made in packets.h and go to src/custom/defines_pre.h and add:
#define PACKETVER YYYYMMDD
Change the date to what you're using that is supported by rAthena. If you leave packet obfuscation enabled server side (it's on by default) then when you diff your client make sure you do not select the option to disable packet obfuscation.
You should be fine from there.
-
I've updated the CentOS wiki page with steps on how to get version 5.
-
1
-
-
The script.c warnings were fixed in Git Hash: 43949b8. The libconfig warnings are of no concern.
-
1
-
-
These are just shadow warnings, nothing major from stopping you from running a server.
To get these warnings suppressed you need to make sure your G++ is version 5 or newer. Make sure you run
./configure
after you update your G++.
-
- Popular Post
- Popular Post
Achievement System
As of Git Hash: 7f5411d, rAthena now supports the Achievement System!
Thanks to @Luxuri, @Nova, @Lemongrass, and @Tokei for their help with information and implementation! Thanks to all the users who helped test the PR and report issues on the feature!
Basic Information- Requires client 2015-05-13 and higher.
- Includes Title System which is integrated into the Achievement System.
- Rewards are given through the RODEX System.
- Added new atcommand reloadachievementdb.
- Added new script commands achievementinfo, achievementadd, achievementremove, achievementcomplete, and achievementexists.
TODO
- Confirm Achievement Level EXP 8-20.
- Confirm Old Money Pocket Zeny amount.
- Figure out how AG_CHATTING, AG_EAT, AG_HEAR, and AG_SEE work on official servers.
-
19
-
1
-
Packet Database Overhaul
As of Git Hash: f0ab8d2, the packet database has had a complete overhaul!
Thanks to @Lemongrass for his work on it!
What does this mean?- The clientinfo.xml client version value will be ignored from now on.
- The src/custom/defines_pre.h and src/custom/defines_post.h are there for people their own packets, set PACKETVER, and set custom Packet Obfuscation keys without having to modify the default header files.
- By setting PACKETVER the server will configure everything else on it's own from now on.
- Custom Packet Obfuscation keys use the following format:
#define PACKET_OBFUSCATION_KEY1 <key1> #define PACKET_OBFUSCATION_KEY2 <key2> #define PACKET_OBFUSCATION_KEY3 <key3>
- The shuffled packets and official obfuscation keys are in their own header files for easy lookup.
- Adds support for a lot of missing clients and features for almost all clients from 2016 and 2017.
- Dropped atcommand reloadpacketdb and script command is_clientver.
-
7
-
1
-
RODEX Support
As of Git Hash: 58776da, rAthena now supports the RODEX System!
Thanks to @Lemongrass for getting it applied to rAthena!
What is RODEX?- RODEX (RO Delivery Express) is the replacement of the Mail System within RO. (Read more here)
- Requires PACKETVER 20150513 or newer.
- All mailbox NPC are disabled as RODEX is accessible through the client.
-
Basic configurations can be found in conf/battle/misc.conf with more configurations in conf/char_athena.conf.
- mail_return_days and mail_delete_days are defaulted to 15 days for when an unread message is returned and another 15 days for when that returned message is finally deleted.
-
As with the previous mail system, zeny and items can be sent through RODEX.
- RODEX supports up to 5 attached items now, as opposed to 1.
- A tax of 2,500 zeny per item (misc.conf::mail_attachment_price) and a tax of 2% zeny when sending zeny (misc.conf::mail_zeny_fee).
- Players are given a default of 100 mail stamps a day. (misc.conf::mail_daily_count)
-
14
Transitioned from yaml-cpp to rapidyaml
in Development News
Posted
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!