Playtester

Just try around a bit. Basically "regen" is the normal regen and "sregen" is the sitting regen.

Just open the rAthena project in Visual Studio and search for the Aegis name e.g. "SM_RECOVERY" and you find everything related to it in the source code.

On a simular request I saw someone suggested to use mapflags and then do % damage adjustments like for GVG/WoE. But I'm not too familiar with that. I'd probably just change the source code to reduce the damage at some point. Probably in battle.cpp "battle_calc_attack" after the type-specific calls but before any no damage checks.

Are you running your server in renewal after all? Because that's the renewal defense code. There is not a single function that calculates VIT_DEF at the moment, but it's basically calculated right above the code you quoted. It uses DEF2 from status.cpp as input. Just search for "def2" in that file (calculation depends on bl type).

On the script page there is a "Support" button which brings you to the support thread for this script. Maybe try to ask there. Akkarin is still around (he's the admin of rAthena actually).

I personally would start with pre-renewal, just check out latest rAthena and enable PRERE, compile. For client you can always use the latest client for which there is a diffable executable (and usually can just get the latest data.grf from kRO). I would recommend just starting with the most recent available because diffing the executable is the hardest and most annoying part of setting up a server, so you only want to do it once and not later again if you want even newer content. Tools like WARP already offer quite some modes and tricks (e.g. to remove the doram selection screen). The advantage of starting with PRERE is that you already have all the mechanics work like PRERE and you could already just launch your server in alpha mode. Then slowly start adding renewal content. Since this is a long process that can take years, it's better to do it slowly one after another. If you started with Renewal, you'd have a long phase were you wouldn't even have a working version, so you'll probably lose motivation before you're even down reverting all renewal mechanics back to pre-re. So yeah, my recommendation is to start with pre-renewal. I think on rAthena we already did it so that even in PRERE all the renewal maps are available and you can warp to them with the warp atcommand. Now the work starts. The best thing is probably to start small. Just pick a single renewal map you want to make accessible. You will need to find add the warps from and to the location. You can take them from existing renewal NPC files, but don't blindly copy the complete file because you'll add warps to locations you don't support then. I guess copying or loading the file but commenting out the warps you don't want yet is the best way to go about it. Same strategy should work with NPCs on that map, but might want to remove the scripts for all NPCs you don't want yet (if you keep the file location as it is and then link to it from the pre-re scripts_main file you can easily restore the deleted NPCs just using TortoiseGit Diff or a similar tool). Now you want to add all the database stuff needed for that map: Items, monsters, etc. These you can't simply copy over from renewal as the stats there have a different meaning, you will need to rebalance the items. I don't think automatically converting items in any form will result in a balanced item. You'd need to look at similar items in renewal and decide for a suitable value. For monsters, you can actually convert some values mathematically. I never wrote a converter for it, but it could certainly be done. For example if you look at HORN_SCARABA (2083): Attack: 886 Attack2: 91 Defense: 135 MagicDefense: 20 Defense 135 in renewal means 23% damage reduction. Which is the same as 23 DEF in pre-renewal. MagicDefense 20 in renewal means 15% damage reduction. Which is the same as 15 DEF in pre-renewal. So you would want to put this instead: Attack: 886 Attack2: 91 Defense: 23 MagicDefense: 15 Next problem is the attack. As you know, in pre-renewal Attack is minimum ATK and Attack2 is maximum ATK. But in renewal Attack is physical ATK and Attack2 is magical ATK. This could also automatically be calculated, you just need Level, STR and INT on top of Attack and Attack2. From renewal "Attack", "Level" and "STR", you can actually calculate both minimum ATK and maximum ATK. From renewal "Attack2", "Level" and "INT" you want to calculate the pre-renewal INT as that determines MATK in pre-renewal. But you only really need to do that if the monsters actually has any magical spells. Otherwise you might just want to leave the original INT value as it is. Also consider the "Level" as well. If you keep max level 99 on your server, then monsters have level 130+ will have too high HIT/FLEE, which might make them unbalanced on your server. I just improved my old helper tool to convert those numbers. It's attached. prerenewal_v2.zip

Not sure about Renewal, but in Pre-Renewal the damage of Auto-Blitz gets divided by number of targets, whereas actively using it doesn't.

Depending on how your server rates are that can be easy to do or a bit harder. The setting affects the drop rate directly when killing a monster and inside the drop rate function (mob.cpp, mob_getdroprate) you don't have access on the item info. But if you for example always want the card drop rate to be unmodified (also by other on-dead effects), you could just not call the mob_getdroprate function for cards. if (it->type != IT_CARD) drop_rate = mob_getdroprate(src, md->db, md->db->dropitem[i].rate, drop_modifier, md); else drop_rate = md->db->dropitem[i].rate; For example like this. You would need to do the same modification in atcommand.cpp, ACMD_FUNC(mobinfo), otherwise the "monsterinfo" atcommand would show a fake higher card drop rate (note that here the item data is called id and not it).

Official servers have a drop penalty on level difference, but many private server remove that "feature". I only play on pre-renewal servers so not sure how many there are that actually have a drop penalty.

It's basically is the max of both values. So if aDelay is 76ms and aMotion is 384ms, then the delay between the attacks is 384ms. Basically "aDelay" determines the time a monster has to wait until it can attack again. "aMotion" determines the time a monster cannot do anything at all after an attack. If aMotion is higher than aDelay, the monster has to stand still until it can attack again (aMotion). If aDelay is higher than aMotion, then the monster can already move again after aMotion milliseconds, but still cannot attack until after aDelay milliseconds. Divine Pride currently has incorrect ASPD display because it only considers aMotion, not aDelay. So you cannot get the aDelay value from Divine Pride at all. I notified Dia, he will fix it on Divine Pride.

1) You add the numbers together that you want it enabled for. For example if you only want Heal and Sactuary to be boosted by this bonus, then you would put "3" (1+2). If you want everything to be affected from that list you put 1+2+4+8+16+32+64+128+256=511. 2) If you are running renewal, you can define the exp and drop penalty here: https://github.com/rathena/rathena/blob/master/db/re/level_penalty.yml

If the config files are enough then I recommend using them. If you want a special implementation, you'd need to modify the source code. The right position in the code depends a bit on how you want to modify it.

The condition for a status change is in status_get_sc_def: if (skill != nullptr && skill->skill_type == BF_MAGIC && // Basic magic skill !skill->inf2[INF2_IGNOREGTB] && // Specific skill to bypass ((skill->inf == INF_ATTACK_SKILL || skill->inf == INF_GROUND_SKILL || skill->inf == INF_SUPPORT_SKILL) || // Target skills should get blocked even when cast on self (skill->inf == INF_SELF_SKILL && src != bl))) // Self skills should get blocked on all targets except self return 0; If you really changed the skill used to "misc" then the status should never be blocked by GTB. Even easier would be to just use the "IgnoreGTB" flag. If it still doesn't work, then maybe it's already blocked in skill.cpp by something. Easiest is to just debug it. Put a breakpoint on the line I quoted above (first line) and see if it even reaches that code when you use the scroll.

The "0x" in front of the number is the indicator that the number is in hex by the way.

Need more info. You want to increase BB's range? In PVP only?