Playtester

It's possible but it requires quite some coding. Basically you'd need to add a variable in the md to the link to a sd (or bl). Then send all the "clif" information that involves the md only to the player linked to the sd / bl in the md data. Also all attack and damage commands from other sources then need to be ignored, otherwise other players could still damage it with AoE effects.

If it crashes you probably have a syntax error in the file. Make sure you used spaces instead of tabs and the number of spaces is correct. That's the most common mistake I make. Looks like you put too many spaces before the script part.

Hmm this also works for me. I tried vs. Medusa and with Evil Druid Card or Medusa Card, I never get petrified. The code is also in place in status.cpp: case SC_STONE: case SC_STONEWAIT: case SC_FREEZE: // Undead are immune to Freeze/Stone if (undead_flag && !(flag&SCSTART_NOAVOID)) return 0; break; You could debug there and check why it doesn't reach the "return 0" part in your test case. For Medusa Card the could would be in status_get_sc_def: // Item resistance (only applies to rate%) if (sd) { for (const auto &it : sd->reseff) { if (it.id == type) rate -= rate * it.val / 10000; } if (sd->sc.data[SC_COMMONSC_RESIST] && SC_COMMON_MIN <= type && type <= SC_COMMON_MAX) rate -= rate*sd->sc.data[SC_COMMONSC_RESIST]->val1/100; } Note: That if you set undead_detect_type to "race", then of course Evil Druid Card doesn't protect you from Stone (has nothing to do with mobs, though). Medusa card would work either way.

Works fine for me.

Red is deleted lines and green is added lines, yes. But I honestly don't recommend manually updating things and rather learn to work with diff files or just keep rAthena up-to-date, because many fixes are not just one commit but also have follow-up fixes. You will really want to merge all fixes done to rAthena. Usually it shouldn't be too hard, as said even if you have local changes, you can stash them, then pull and then stash pop and you have your custom changes back in (only if the same line was changed you need to do manual merging). Maybe you can try it in a local copy.

Going by this and your previous posts, I assume you checked out rAthena exactly at the moment where we were reworking the status changes. I strongly recommend you update to latest rAthena. (Stash your own changes -> Pull from master -> Pop your own changes).

Why want to make GTB even more powerful than it already is? Anyway, you would need to add some special rules to status_get_sc_def in status.cpp. GTB currently only blocks status changes that come from magic skills. 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; This is the current GTB logic. To make it so that Coma is blocked even on physical attacks you could do for example: (skill->skill_type == BF_MAGIC || type == SC_COMA)

Hi all, as of today's commit (https://github.com/rathena/rathena/commit/d3cc0c56563769aafd78c976d6e76d83dbf6df88) rAthena will include the pre-renewal jRO Brasilis monster values in YAML format. If you want to use the bRO values instead (lower ATK), I've attached a YAML file in the original post to overwrite these. I also corrected the ATK values for jRO in my original release as they were just guessed before and now they use the official values (but that release only works for rAthena 2013-2016).

I'm not familiar with GvG maps, do I need to warp to a specific map? Or do I need to run a command to enable it on the map?

Probably outdated rAthena? mob_db was converted to YAML fairly recently (16 Feb 2021).

It's normal that Stone Curse (from the Stone Curse spell) has an incubation time of 5 seconds. During this time you can still walk but not use skills. Blessing on Stone Curse should be working, but you need to cast it after the incubation time (Blessing will then not be applied and instead it heals the stone status). Status Recovery on frozen works for me.

Maybe your rAthena is outdated. This flag was added on February 1st 2022: https://github.com/rathena/rathena/commit/3deb3e204852f169c84e5ea9399e8a1e5129a71e

You could for example check for the Soul Link status change and if you don't have it just call skill_attack directly, otherwise call map_foreachinrange as for other splash skills.

Adding the flag as qtdan described is the easiest solution. If this is a bug in the emulator and it should not make targets immune to GTB, then that's usually more an indication of that it shouldn't be a magic spell in the first place (maybe misc?). Though changing the damage type often requires to also move the skill's code to another function (might not be needed for no-damage skills though).

Yeah basically you need to edit skill.cpp, but the change should be minimal if you have a different skill that works similar already. Basically open skill.cpp in Visual Studio and make Ctrl+F, make sure you select to search only in this document so you don't get too many results. Then you first search for the skill you want to change to understand how it works. You don't want to change anything about its effects, you just want to change how often it calls "skill_attack" (you want to call it once for each enemy in the area instead of just the target). So if you search for AM_ACIDTERROR in skill.cpp and check where it calls skill_attack you will find it in a long lists of single target skills: [...] case AC_CHARGEARROW: case MA_CHARGEARROW: case RG_INTIMIDATE: case AM_ACIDTERROR: case BA_MUSICALSTRIKE: case DC_THROWARROW: case BA_DISSONANCE: case CR_HOLYCROSS: [...] You will want to remove it here. Now you search for a skill that you want it to behave like. For example MG_FIREBALL. Then you find a larger list of skills, it's even commented as "Splash skills": //Splash attack skills. case AS_GRIMTOOTH: case MC_CARTREVOLUTION: case NPC_SPLASHATTACK: flag |= SD_PREAMBLE; // a fake packet will be sent for the first target to be hit case AS_SPLASHER: case HT_BLITZBEAT: case AC_SHOWER: case MA_SHOWER: case MG_NAPALMBEAT: case MG_FIREBALL: case RG_RAID: #ifdef RENEWAL case SN_SHARPSHOOTING: #endif case HW_NAPALMVULCAN: case NJ_HUUMA: case ASC_METEORASSAULT: You just need to add your skill here ("case AM_ACIDTERROR:"). Now it works like a splash skill. The code below looks a bit scary because devs put way too many exceptions in there, but you can just ignore this unless you want your skill to have a unique handling unlike normal splash skills. Most of the other things you can just define in the skill_db.yml If you wonder how this section works, basically it will first be called without a flag: if( flag&1 ) {//Recursive invocation So this will be false and it goes into the else: } else { In the else it then calls a sub function for all units in the area: // recursive invocation of skill_castend_damage_id() with flag|1 map_foreachinrange(skill_area_sub, bl, splash_size, starget, src, skill_id, skill_lv, tick, flag|BCT_ENEMY|SD_SPLASH|1, skill_castend_damage_id); This will in the end loop back to the same function again for each valid target, except now it has "flag&1" and will just call skill_attack for that target instead.

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

Not familiar with that diff (you're better off asking on WARP Discord), but I can tell you that you cannot just use any executable, first of all you need one that's not encrypted, so you kind of rely it being provided by the Nemo/Warp project, because Gravity now encrypts their executables. Second, if you take a too modern executable, some of its feature might not be supported in rAthena yet. Using older ones should be fine though as long as you adapt PACKETVER in packets.hpp.

I created an issue on Steel Body on the bug tracker too: https://github.com/rathena/rathena/issues/6910

You can use Status.yml to define special properties of status changes: - Status: Steelbody Icon: EFST_STEELBODY DurationLookup: MO_STEELBODY States: NoCast: true CalcFlags: Def: true Mdef: true Aspd: true Speed: true Opt3: SteelBody: true For example you can use the flag "NoSave", so that a status change is removed on logout, similar to how it is defined for Devotion: - Status: Devotion Icon: EFST_DEVOTION DurationLookup: CR_DEVOTION Flags: NoSave: true RemoveOnChangeMap: true OverlapIgnoreLevel: true Note: Endow is not remove on logout on official servers so that's correct. However, I can confirm that Steel Body should be removed, but isn't.

Just a quick heads up, your original reports are fixed on the emulator now: https://github.com/rathena/rathena/commit/3b9c28aa464b8adb3decb5357725e1f705c8517e

There's one more thing, right now the transition from SC_STONEWAIT to SC_STONE can also be resisted. That also needs to be fixed by making it unavoidable. We are also checking an issue in renewal right now. I recommend you just wait for the next update though otherwise you'll run into merge conflicts.

You're perfectly right, I will forward that one as well. Good thinking!

I assume this "Shadow Cross" is a new 4th job class? Your file doesn't contain this class at all, so it uses the official values from the emulator. You will need to expand your job_status.yml with the new jobs.

It's a small error in the rework on the Stone SC. In status.cpp this part: case SC_STONE: case SC_FREEZE: // Undead are immune to Freeze/Stone if (undead_flag && !(flag&SCSTART_NOAVOID)) return 0; break; Needs to be changes to: case SC_STONE: case SC_STONEWAIT: case SC_FREEZE: // Undead are immune to Freeze/Stone if (undead_flag && !(flag&SCSTART_NOAVOID)) return 0; break; I'll forward this to Aleos so he can fix this directly on the emulator.

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