Playtester

The setting is commented out because the default value is different for pre-renewal and renewal. If you leave it commented out it will use the correct default value depending on whether you compiled on pre-re or renewal. Renewal clients have trouble displaying traps, has nothing to do with this setting. As far as I know traps are now invisible in renewal, so they don't really bother to properly show them on renewal clients anymore. Need to use 2021 or older client for them to display properly.

You could do that via code changes. Or alternatively, you could just change the required exp in the job_exp database file.

Die Balance war zu Pre-Renewal Zeiten einfach viel besser. Alles hatte irgendwie einen Wert. Und Klassen haben sich gegenseitig ergänzt. Pre-Renewal ist nicht unbedingt an den Inhalt gebunden. Man könnte auch den ganzen Renewal Content überarbeiten und für Pre-Renewal balancen. Dann hat man das beste von beiden Welten. Kriegt aber leider kaum einer richtig hin.

On current rAthena, implementing the old behavior is actually pretty simple. Find this code in skill.cpp: sg->limit = DIFF_TICK(tick, sg->tick) + (sg->unit_id == UNT_CLUSTERBOMB || sg->unit_id == UNT_ICEBOUNDTRAP ? 1000 : 0) + // Cluster Bomb/Icebound has 1s to disappear once activated. (sg->unit_id == UNT_FIRINGTRAP ? 0 : 1500); // Firing Trap gets removed immediately once activated. sg->unit_id = UNT_USED_TRAPS; // Change ID so it does not invoke a for each in area again. } And change it to: sg->limit = DIFF_TICK(tick, sg->tick) + (sg->unit_id == UNT_CLUSTERBOMB || sg->unit_id == UNT_ICEBOUNDTRAP ? 1000 : 0) + // Cluster Bomb/Icebound has 1s to disappear once activated. (sg->unit_id == UNT_FIRINGTRAP ? 0 : 1500); // Firing Trap gets removed immediately once activated. unit->range = -1; } This makes most traps work like previously. If you also want this system for Landmine you need to do the same change there (just replace setting of UNT_USED_TRAPS with setting of range to -1). Behavior might change in the future, but currently setting range to -1 does the trick because the calling code handles removing the trap then.

If you really want to restore that bug you can probably just remove the fix for it: if (skill_id == SN_SHARPSHOOTING || skill_id == MA_SHARPSHOOTING) bflag &= ~(BDMG_CRIT); // Sharpshooting just ignores DEF/FLEE but damage is like a normal attack

I don't have a script solution, but I tried around a bit in src. In battle.cpp in the battle_damage function, if you find: if (src) sd = BL_CAST(BL_PC, src); and replace it with: if (src) { sd = BL_CAST(BL_PC, src); unit_data* ud = unit_bl2ud(target); if (src->type == BL_PC && target->type == BL_PC && ud != nullptr && ud->target_count >= 2) status_change_start(target, src, SC_DECREASEAGI, 10000, 10, 0, 0, 0, 10000, SCSTART_NOAVOID); } It's kinda working. However, it only counts autoattackers, not players that use skills on the target. If there are already 2 auto attackers and someone attacks with skill, they also get cursed, though. Would be easier to do if we had the official system of counting attackers that adds them to a list and then deletes them after 3000ms again.

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.

Maybe you should elaborate what you mean with "Frost switch".

Probably can be accomplished by just defining RENEWAL_EXP: /// Renewal exp rate algorithms /// (disable by commenting the line) /// /// Leave this line to enable renewal item exp rate algorithms /// While enabled a special modified based on the difference between the player and monster level is applied #define RENEWAL_EXP Then set up level_penalty.yml in db/import.

I never used it but if you compile rAthena it should generate a "yaml2sql" project. That should be it, no?

Not sure if I fully understand. Do you want GTB to block buffs like Blessing and Assumptio or do you NOT want them to be blocked?

My suggestion would be to change this: sc_def = status->mdef*100; To: sc_def = status->mdef*100 + status->luk*30; That makes 300 Luk result in 90% resist, plus -30% fixed reduction, so even if the base chance is 300%, you would fully resist it. Alternatively you could change both sc_def and sc_def2 like this: sc_def = status->mdef*100 + (status->luk*100)/3; sc_def2 = status_get_lv(bl)*10 - status_get_lv(src)*10; This would remove the fixed reduction from luk, but makes sure you have 100% resist at Luk=300.

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.

Well as you can see in the code, you need to be a Taekwon (not a job beyond that), your base level needs to be above taekwon_ranker_min_lv (player.conf) and you need to be in the famerank (top 10 usually which you can see with /taekwon).

Works for me in default pre-re rAthena. Here is the check logic: #define pc_is_taekwon_ranker(sd) (((sd)->class_&MAPID_UPPERMASK) == MAPID_TAEKWON && (sd)->status.base_level >= battle_config.taekwon_ranker_min_lv && pc_famerank((sd)->status.char_id,MAPID_TAEKWON)) If you are level 375 then your server has customized the levels, maybe they also changed the required level for the ranker bonus.