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.

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.

In pre-renewal armor gives 0.7 DEF per refine. I strongly advice against increasing this as this allows players to reach 100 DEF which makes them immune to all damage which is super exploitable. Unless you also change the code on how damage reduction works. It do be in pre-re/refine.yml though: Body: - Group: Armor Levels: - Level: 1 RefineLevels: - Level: 1 Bonus: 70 If you want the DEF to be displayed as a fake value that counts "1" per refine even if it really is just 0.7 (like Aegis does), you'd probably need to add something like "clientdef" to the base_status struct and then calculate that in parallel to def with adjusted refine bonus.

Can't you just remove this part of the code in skill.cpp? // bugreport:4888 these songs may only be dispelled if you're not in their song area anymore case SC_WHISTLE: case SC_ASSNCROS: case SC_POEMBRAGI: case SC_APPLEIDUN: case SC_HUMMING: case SC_DONTFORGETME: case SC_FORTUNE: case SC_SERVICE4U: if (!battle_config.dispel_song || tsc->getSCE(status)->val4 == 0) continue; //If in song area don't end it, even if config enabled break;

I can probably look it up for you, but I'd need to know what your previous account was.

Sharp Shooting is a special case. It just deals fake critical damage, which only ignores DEF/FLEE but does not actually count as critical damage. So it neither deals max damage nor is increased by "The Paper" card. Try to test against a monster with very high DEF or FLEE, there you will see the difference. This is official behavior.

I'd put it in void skill_consume_requirement(map_session_data *sd, uint16 skill_id, uint16 skill_lv, int16 type) Under type type&2 section. Maybe it's easier if you set the skill in the db to consume all 3 items but then put an exception here that the third item is not consumed under certain conditions.

Renewal or pre-renewal? Existing code for pre-renewal should already work as you described. If you applied changes to the code, just revert to latest rAthena.

The targeting of renewal songs is defined in: static int32 skill_castend_song(struct block_list* src, uint16 skill_id, uint16 skill_lv, t_tick tick) It's pretty self explanatory, just set flag to what should be targetted by the skill. You can see that it default to BCT_PARTY, with a few dances and songs having a different target. You can just look up the BCT flag definition and find what each flag means: BCT_NOONE = 0x000000, ///< No one BCT_SELF = 0x010000, ///< Self BCT_ENEMY = 0x020000, ///< Enemy BCT_PARTY = 0x040000, ///< Party members BCT_GUILDALLY = 0x080000, ///< Only allies, NOT guildmates BCT_NEUTRAL = 0x100000, ///< Neutral target BCT_SAMEGUILD = 0x200000, ///< Guildmates, No Guild Allies BCT_ALL = 0x3F0000, ///< All targets BCT_WOS = 0x400000, ///< Except self and your master BCT_SLAVE = BCT_SELF|BCT_WOS, ///< Does not hit yourself/master, but hits your/master's slaves BCT_GUILD = BCT_SAMEGUILD|BCT_GUILDALLY, ///< Guild AND Allies (BCT_SAMEGUILD|BCT_GUILDALLY) BCT_NOGUILD = BCT_ALL&~BCT_GUILD, ///< Except guildmates BCT_NOPARTY = BCT_ALL&~BCT_PARTY, ///< Except party members BCT_NOENEMY = BCT_ALL&~BCT_ENEMY, ///< Except enemy BCT_ALLY = BCT_PARTY|BCT_GUILD, BCT_FRIEND = BCT_NOENEMY,

Depends on what knockback you mean. The 1 cell knockback? Probably could just be removed it in skill_db.yml, but not 100% sure if it isn't hardcoded without checking. If you mean the official gutter line bug that sometimes monsters get knocked back 5 cell and only hit once, you can disable that in skill.conf.

bAtkRate only works in renewal by default, it's even documented: But your solution to make it work in pre-re seems fine to me.

Looks like you're sending a wrong movement packet to the client. Maybe you defined the wrong packet version when compiling. It needs to match with the client version you're using. See instruction here: #ifndef PACKETVER /// Do NOT edit this line! To set your client version, please do this instead: /// In Windows: Add this line in your src\custom\defines_pre.hpp file: #define PACKETVER YYYYMMDD /// In Linux: The same as above or run the following command: ./configure --enable-packetver=YYYYMMDD #define PACKETVER 20211103 #endif

Only if the server owner is willing to send you their server source code.

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.

It's normal that Lord Knights have more HP than Paladins. Lord Knights have the highest HP factor. Anyway, if you don't want to specify HP/SP for 999 levels, I recommend you don't use the HP/SP tables, you can comment out the define pointed out by Mice and then use job_stats.yml instead. Just be aware if won't use the official values then anymore, not even for level 1-99. - Jobs: Knight: true Knight2: true MaxWeight: 28000 HpFactor: 150 SpIncrease: 300 - Jobs: Lord_Knight: true Lord_Knight2: true MaxWeight: 28000 HpFactor: 150 SpIncrease: 300 - Jobs: Baby_Knight: true Baby_Knight2: true MaxWeight: 28000 HpFactor: 150 SpIncrease: 300 For example if you want to reduce Knight HP you need to reduce the HpFactor here from 150 to a lower value. You could set it to 110, then they have the same base HP as Assassin.

You find the skill in skill.cpp here: https://github.com/rathena/rathena/blob/master/src/map/skill.cpp#L4942 I think the chances are kinda self-explanatory. Currenty number 21 to 30 are assigned to Priestess Card, so 10% chance.

It's a problem with the stat display in the client, since you're using a renewal client. In a pre-renewal client it would display as 14~17. It means your Min MATK is 14 and Max MATK is 17. The rod gives +15% MATK, which applies to both minimum and maximum damage. That's why it becomes 16~19. You could check if there's a diff for the executable to change it to the pre-renewal display style.

Took me a while to figure this out, but you could set the skill to have its cast time not being influenced by status changes by adding this to skill.yml: CastTimeFlags: IgnoreStatus: true The only downside is that it also makes Suffragium not work.