Jump to content

Aleos

Development Manager
  • Content Count

    730
  • Avg. Content Per Day

    0
  • Joined

  • Days Won

    67

Aleos last won the day on March 4

Aleos had the most liked content!

Community Reputation

499 Excellent

About Aleos

  • Rank
    Deviling

Profile Information

Recent Profile Visitors

11,366 profile views
  1. 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!
  2. 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!
  3. 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.
  4. 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.
  5. Implemented in Git Hash: ac558d7.
  6. 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.
  7. 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.
  8.  hello good morning

    how to change acid demo with thanatos card in weapon and the formula of thanatos card can you help me

    if (def1 > 100) def1 = 100;
      ATK_RATE2(wd.damage, wd.damage2,
       attack_ignores_def(wd, src, target, skill_id, skill_lv, EQI_HAND_R) ?100:(is_attack_piercing(wd, src, target, skill_id, skill_lv, EQI_HAND_R) ? (int64)is_attack_piercing(wd, src, target, skill_id, skill_lv, EQI_HAND_R)*(def1+vit_def) : (100-def1)),
       attack_ignores_def(wd, src, target, skill_id, skill_lv, EQI_HAND_L) ?100:(is_attack_piercing(wd, src, target, skill_id, skill_lv, EQI_HAND_L) ? (int64)is_attack_piercing(wd, src, target, skill_id, skill_lv, EQI_HAND_L)*(def1+vit_def) : (100-def1))
      );
      ATK_ADD2(wd.damage, wd.damage2,
       attack_ignores_def(wd, src, target, skill_id, skill_lv, EQI_HAND_R) || is_attack_piercing(wd, src, target, skill_id, skill_lv, EQI_HAND_R) ?0:-vit_def,
       attack_ignores_def(wd, src, target, skill_id, skill_lv, EQI_HAND_L) || is_attack_piercing(wd, src, target, skill_id, skill_lv, EQI_HAND_L) ?0:-vit_def

     

    change to increase damage when I'm using GR CARD IN ARMOR IS DECREASE ;D

    how to activate incantation card effect with thanatos card

     

    thank you

  9. *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.
  10. No, the script defines are exactly the same so you shouldn't have to worry about updating any custom scripts of yours.
  11. 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!
  12. EXPIRED

    Adds support for the guild skill: Guild Storage Expansion Includes option to choose between current rAthena guild storage or official. Requires client 2013-12-23 or newer.
  13. 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.
  14. 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.
  15. Aleos

    Achievement

    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: 100 This achievement will require these 10 monsters to be killed (in no order).
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.