Playtester

mmo.h
#ifndef INVENTORY_BASE_SIZE #define INVENTORY_BASE_SIZE 100 // Amount of inventory slots each player has #endif #ifndef INVENTORY_EXPANSION_SIZE #if PACKETVER_MAIN_NUM >= 20181031 || PACKETVER_RE_NUM >= 20181031 || PACKETVER_ZERO_NUM >= 20181114 #define INVENTORY_EXPANSION_SIZE 100 // Amount of additional inventory slots a player can have #else #define INVENTORY_EXPANSION_SIZE 0 #endif #endif #ifndef MAX_INVENTORY #define MAX_INVENTORY ( INVENTORY_BASE_SIZE + INVENTORY_EXPANSION_SIZE ) // Maximum items in player inventory (in total) #else #if MAX_INVENTORY < ( INVENTORY_BASE_SIZE + INVENTORY_EXPANSION_SIZE ) #error Your custom MAX_INVENTORY define is too low #endif #endif Be aware that this number shouldn't exceed 480.
No idea on what's needed client-sided.

It's because equipping a new item included unequipping the previous item. Without the armor your HP is halved. Then you equip a new armor that increases your MaxHP, but your normal HP stays the same. This is how it officially works.
You could of course recode the system to increase your HP when your MaxHP increases, but it's not that simple and might also be exploitable.

You don't want to compile both pre-renewal and renewal functionality so using forks like this is way more efficient.
Also you just need to uncomment #define PRERE to have pre-renewal. So it's just a one-line change.

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.

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

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.

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.

I would assume in status.cpp:
void status_calc_misc(struct block_list *bl, struct status_data *status, int level)
// Flee stat = status->flee; stat += level + status->agi; status->flee = cap_value(stat, 1, SHRT_MAX); Change formula to whatever you want. 50% AGI would be:
// Flee stat = status->flee; stat += level + status->agi/2; status->flee = cap_value(stat, 1, SHRT_MAX); Luk does not increase flee in pre-renewal anyway. Perfect flee you find as Flee2.

I would assume in status.cpp:
void status_calc_misc(struct block_list *bl, struct status_data *status, int level)
// Flee stat = status->flee; stat += level + status->agi; status->flee = cap_value(stat, 1, SHRT_MAX); Change formula to whatever you want. 50% AGI would be:
// Flee stat = status->flee; stat += level + status->agi/2; status->flee = cap_value(stat, 1, SHRT_MAX); Luk does not increase flee in pre-renewal anyway. Perfect flee you find as Flee2.

I would assume in status.cpp:
void status_calc_misc(struct block_list *bl, struct status_data *status, int level)
// Flee stat = status->flee; stat += level + status->agi; status->flee = cap_value(stat, 1, SHRT_MAX); Change formula to whatever you want. 50% AGI would be:
// Flee stat = status->flee; stat += level + status->agi/2; status->flee = cap_value(stat, 1, SHRT_MAX); Luk does not increase flee in pre-renewal anyway. Perfect flee you find as Flee2.

You need to recalculate the renewal def to pre-renewal def through a formula if you want it to result in the same % damage reduction.
For example 214 DEF and 134 MDEF in Renewal is the same as 32 DEF and 52 MDEF in pre-renewal.
I've attached a tool with which you can convert all the values you want.
prerenewal.zip

Your refine.yml seems pretty old, are you sure you don't get errors when started map server about outdated files?
I can't spot any error in the file like lacking armor bonus at level 10 but it's clearly outdated (only 6.6 def bonus on +10 instead of +7). And this is version 1 while the current source code would expect version 2. So maybe your server version is old and has this as a bug that's already been fixed or you updated your server and it expects version 2 but you are still using version 1.

Technically that makes you load renewal items, but you should put /re/ before /pre-re/, otherwise all pre-renewal items will be overwritten by renewal stats which would be really bad.
Also, you will need to edit most of the items in the files first. For example you need to recalculate the DEF, change weapon level 5 to a different weapon level, etc.
It's honestly cleaner to go step-by-step and copy a few renewal items into import/item_db.yml and adjust them so they fit pre-renewal.

Lemongrass already fixed this here: https://github.com/rathena/rathena/commit/aae930198d1bf1c491444a55bb028af2a147ad41
Just update rAthena to latest and it should be fixed.

On a sidenote, this was a bug on the emulator which is fixed now:
https://github.com/rathena/rathena/commit/64f10ed10bfb174709f3a0ed0abe93be20d64cf5

The way I'd go about it is use the existing Cooldown functionality. The Cooldown is stored per skill, but you could just make Skill B and Skill C also store their cooldown as "Skill A".
And then just block Skill B and Skill C when there's a Cooldown for "Skill A".
All the code you need would be in skill.cpp.
You could for example take a look at WL_RELEASE because that actually fetches the Cooldown from another skill (the preserved skill) and applies it.

Okay I searched for a while and figured out the root cause is the config change that came with the commit above. It also affects pre-renewal.
You will need to find battle.conf config file and change:
// Who should have a baseatk value (makes str affect damage)? (Note 3) enable_baseatk: 0x29F Back to:
// Who should have a baseatk value (makes str affect damage)? (Note 3) enable_baseatk: 9  

Or if you want pre-renewal ASPD (but still everything else from renewal?), then you could just copy the pre-re/job_db1.txt to re/job_db1.txt.

Yes, that's what you wanted, no? Not being able to spam skills anymore when using 3rd party tools.
If you want cast time, that's possible too but not as easily. However, I want to note that if you want to avoid 3rd party hacks, I recommend using my first suggestion to set that setting above to 600. Then even with 3rd party tools you can't cast the spell more than once every 600ms.
If you add a small cast time to all skills, then 3rd party tools get even more exploitable as the aftercast delay will be even lower for all the skills. If you still want that, you will have to edit skill.cpp:
// return final cast time time = max(time, 0); Change to e.g.:
// return final cast time time = max(time, 500); Then all skills have a cast time of 500ms minimum.

Try removing the self-collision part in skill.cpp:
// Self-collision if(bl->x >= min_x && bl->x <= max_x && bl->y >= min_y && bl->y <= max_y) skill_attack(BF_WEAPON,src,src,bl,skill_id,skill_lv,tick,(flag&0xFFF)>0?SD_ANIMATION:0); Damage you can set in battle.cpp:
case KN_BOWLINGBASH: case MS_BOWLINGBASH: skillratio += 40 * skill_lv; break; Change it to:
case KN_BOWLINGBASH: case MS_BOWLINGBASH: skillratio += 100 + 80 * skill_lv; break; For double damage.

Well the resist does not affect the base duration which is different for each skill. But if you want 12 seconds to be reduced to 4-5 seconds then try:
case SC_FREEZE: sc_def = status->mdef*100; sc_def2 = status->luk*10 + status_get_lv(bl)*10 - status_get_lv(src)*10; tick_def = 6000 + status->mdef*40; tick_def2 = status_src->luk*-10; // Caster can increase final duration with luk break;  

Well if you want to do it properly and only want to change the duration and nothing else, then you have to do the math.
How much % reduction should each point in LUK give so that at 320 LUK, you have 100% resist?
100%/320 = 0.3125%
Unfortunately that's an odd number the program can't properly work with in its current state. You could give 0.31% reduction per LUK, then at 320 LUK you'd have 320*0.31% = 99.2% reduction.
So for example for freeze, you could put something like:
case SC_FREEZE: sc_def = status->mdef*100; sc_def2 = status->luk*10 + status_get_lv(bl)*10 - status_get_lv(src)*10; tick_def = status->luk*31; tick_def2 = 0; break; See the luk*31? There I define that each point in LUK should reduce the duration by 0.31%.
Keep in mind that MDEF will now only reduce the chance but not the duration anymore.

It's not a bug, you don't see meteors falling if they would fall on an LP cell. That's how it works on iRO as well.

You can define the boost of SPEARQUICKEN in status.c for pre-renewal:
#ifndef RENEWAL_ASPD case SC_SPEARQUICKEN: val2 = 200+10*val1; break; #endif There's no easy way to make it work differently depending on weapon type, though.

If you want to limit the total bonus you could do that in pc.c:
case SP_SUBRACE: // bonus2 bSubRace,r,x; PC_BONUS_CHK_RACE(type2,SP_SUBRACE); if(sd->state.lr_flag != 2) sd->subrace[type2]+=val; break; For example:
case SP_SUBRACE: // bonus2 bSubRace,r,x; PC_BONUS_CHK_RACE(type2,SP_SUBRACE); if(sd->state.lr_flag != 2) { sd->subrace[type2]+=val; if(sd->subrace[type2] > 90) sd->subrace[type2] = 90; } break;