Playtester

You can set this in your skill_db, just read the explanation at the top.

So if the player is a super player he should be able to chain combos however he wants? If guess you can get group_id via: int pc_get_group_id(struct map_session_data *sd); So for example... uh... case MO_CHAINCOMBO: if(!sc) return false; if(sc->data[SC_BLADESTOP]) break; if(sc->data[SC_COMBO] && (pc_get_group_id(sd) > 0 || sc->data[SC_COMBO]->val1 == MO_TRIPLEATTACK)) break; return false; Like this maybe?

It's not a bug, Tarot Card of Fate can dispell FCP. case 3: // THE HIGH PRIESTESS - all buffs removed { status_change_clear_buffs(target, SCCB_BUFFS | SCCB_CHEM_PROTECT); break; }

Not defined any exp table for Novice maybe?

Group ID?

Is it so hard to press Ctrl+F and then enter that text to find it? Or just search for AL_BLESSING to see whereever it applies. As I said it's the block that is for all normal status changes without special rules. case AL_INCAGI: case AL_BLESSING: case MER_INCAGI: case MER_BLESSING: if (dstsd != NULL && tsc->data[SC_CHANGEUNDEAD]) { skill_attack(BF_MISC,src,src,bl,skill_id,skill_lv,tick,flag); break; } case PR_SLOWPOISON: case PR_IMPOSITIO: case PR_LEXAETERNA: case PR_SUFFRAGIUM: case PR_BENEDICTIO: case LK_BERSERK: case MS_BERSERK: case KN_TWOHANDQUICKEN: case KN_ONEHAND: case MER_QUICKEN: case CR_SPEARQUICKEN: case CR_REFLECTSHIELD: case MS_REFLECTSHIELD: case AS_POISONREACT: case MC_LOUD: case MG_ENERGYCOAT: case MO_EXPLOSIONSPIRITS: case MO_STEELBODY: case MO_BLADESTOP: case LK_AURABLADE: case LK_PARRYING: case MS_PARRYING: case LK_CONCENTRATION: case WS_CARTBOOST: case SN_SIGHT: case WS_MELTDOWN: case WS_OVERTHRUSTMAX: case ST_REJECTSWORD: case HW_MAGICPOWER: case PF_MEMORIZE: case PA_SACRIFICE: case ASC_EDP: case PF_DOUBLECASTING: case SG_SUN_COMFORT: case SG_MOON_COMFORT: case SG_STAR_COMFORT: case GS_MADNESSCANCEL: case GS_ADJUSTMENT: case GS_INCREASING: case NJ_KASUMIKIRI: case NJ_UTSUSEMI: case NJ_NEN: case NPC_DEFENDER: case NPC_MAGICMIRROR: case ST_PRESERVE: case NPC_INVINCIBLE: case NPC_INVINCIBLEOFF: case RK_DEATHBOUND: case AB_RENOVATIO: case AB_EXPIATIO: case AB_DUPLELIGHT: case AB_SECRAMENT: case AB_OFFERTORIUM: case NC_ACCELERATION: case NC_HOVERING: case NC_SHAPESHIFT: case WL_MARSHOFABYSS: case WL_RECOGNIZEDSPELL: case GC_VENOMIMPRESS: case SC_DEADLYINFECT: case LG_EXEEDBREAK: case LG_PRESTIGE: case SR_CRESCENTELBOW: case SR_LIGHTNINGWALK: case GN_CARTBOOST: case KO_MEIKYOUSISUI: case ALL_ODINS_POWER: case ALL_FULL_THROTTLE: case RA_UNLIMIT: case WL_TELEKINESIS_INTENSE: case RL_HEAT_BARREL: case RL_P_ALTER: case RL_E_CHAIN: case SU_FRESHSHRIMP: case SU_ARCLOUSEDASH: clif_skill_nodamage(src,bl,skill_id,skill_lv, sc_start(src,bl,type,100,skill_lv,skill_get_time(skill_id,skill_lv))); break;

Sorry, as I said I can give you hints but if you want more complex code solutions you should probably learn to understand the code yourself or hire a coder.

It's complex, I don't really have time for this. You'll need to try around yourself in the source code. You could try change: int battle_check_target( struct block_list *src, struct block_list *target,int flag) This one is called for flag = BCT_ENEMY. You will want to write it so that it returns true if the monster can attack another monster. I don't really know more about it either.

"or sniper" or "of sniper"? Anyway, there are tons of possibilties to modify damage, depends on how the damage should work... Generally you find everything in battle.c static struct Damage battle_calc_weapon_attack(struct block_list *src, struct block_list *target, uint16 skill_id, uint16 skill_lv, int wflag) At any point in that function after: wd = battle_calc_skill_base_damage(wd, src, target, skill_id, skill_lv); // base skill damage You modify the damage. If it's a normal attack then skill_id is 0.

Yeah is a bit more complex to do because Blessing and Agi have some special rules like you can offensively cast them too. Usually Blessing and Agi end up here: clif_skill_nodamage(src,bl,skill_id,skill_lv, sc_start(src,bl,type,100,skill_lv,skill_get_time(skill_id,skill_lv))); break; But that is used for all other status change skills too, so you need to split them away from that. And do an implementation that looks a bit more like the code you quoted above. if( sd ) party_foreachsamemap(skill_area_sub, sd, skill_get_splash(skill_id, skill_lv), src, skill_id, skill_lv, tick, flag|BCT_PARTY|1, skill_castend_nodamage_id); But this code should only be called when having link status, so something like: struct status_change* sc = status_get_sc(src); if(sd && sc && sc->data[SC_SPIRIT] && sc->data[SC_SPIRIT]->val2 == SL_PRIEST) With that info you should be able to code it together yourself.

How do you want to modify it?

I don't think those are general rAthena issues, though, so they will probably be labelled invalid if posted on github. If skills would just disappear, it would have been reported much earlier. Chain Crush Combo is working fine too, just tested. So I cannot confirm any of these issues. Must be caused by some customization. Try to use latest rAthena from Github and then slowly apply your changes until the bug starts to occur to see what causes it.

aDelay is the delay between the attacks. aMotion is the time the monster needs after an attack before it can start moving again.

That's very possible, but you need to change the code: case TK_HIGHJUMP: { int x,y, dir = unit_getdir(src); //Fails on noteleport maps, except for GvG and BG maps [Skotlex] if( map[src->m].flag.noteleport && !(map[src->m].flag.battleground || map_flag_gvg2(src->m) ) ) { x = src->x; y = src->y; } else if(dir%2) { //Diagonal x = src->x + dirx[dir]*(skill_lv*4)/3; y = src->y + diry[dir]*(skill_lv*4)/3; } else { x = src->x + dirx[dir]*skill_lv*2; y = src->y + diry[dir]*skill_lv*2; } clif_skill_nodamage(src,bl,TK_HIGHJUMP,skill_lv,1); if(!map_count_oncell(src->m,x,y,BL_PC|BL_NPC|BL_MOB,0) && map_getcell(src->m,x,y,CELL_CHKREACH) && unit_movepos(src, x, y, 1, 0)) clif_blown(src); } break; I'm not sure if it works but maybe it's sufficient to change the last parameter in the unit_movepos call to "1".

It wouldn't say "Skill has failed" if you still had aftercast delay. Doesn't it say that because you have no Spirit Sphere or are not in Fury Mode when trying to use it again? If you want a no delay with 4 cards you should put 25% reduction per card.

bonus2 bAddEle,Ele_Ghost,x; Increases damage on Ghost element by x%. Could add that to Ice Pick script. There's no bonus for "Less damage when being attacked by a specific weapon" yet, though.

Well the main problem I see is that if you just take the renewal database you will have all monster stats completely different to what pre-renewal had. Even if you somehow converted the stats. So the first question is, do your players really want that? All monster stats changed from what they are used to? Like Desert Wolf becoming one of the hardest monsters in the game? Renewal stats go also along with a lot of spawn changes so it wouldn't make much sense to use renewal monsters stats without the renewal spawns too. You wouldn't need to do them one-by-one though. Learn to use a spreadsheet program, then you could write a formula and apply it to all lines. Or as you said change the code so you do the calculation when reading in the database files. But first you probably want to clear up if you really want to use (converted) renewal stats on all monsters. Edit: The next problem would be the drops, they drop renewal items what should happen with those? Some drop rates are also too extrem in pre-renewal like Banaspaty dropping Elunium to 15% on 1x rates. That would totally ruin the pre-re economy. It's better to think about each monster individually.

You have to write your own mob entries for new mobs instead of using the re file. See my reply here:

McDonalds

That's because in renewal VIT has no effect on piercing damage. In re piercing damage is basically just ignoring DEF. Not a bug.

Yes, you can't just use the renewal monster stats with pre-renewal. Instead use pre-renewal mob_db and then slowly copy over the monsters that are only in the re file and give them appropriate stats for pre-renewal. That includes reducing their DEF (you can use the attached converter to find out a comparable pre-renewal DEF value), reducing the level (reduce by ~30), increasing the ATK and increasing the Base Exp and Job Exp (base more than job). prerenewal.zip

How much DEF does the status window show for the target with both armors? -50 DEF wouldn't have much of an effect if your DEF is already 0 anyway and you have 300 VIT.

99% sure you are using the renewal database on a pre-renewal compile.

If it was a problem with the vit, then the damage should also be low without ghostring armor. I tested myself right now and it works fine. Normal damage - 200 Vs. Ghostring - 50 Vs. Ghostring with Fire Elemental Converter - 200 (In pre-renewal.) Are you testing in renewal or pre-renewal?

Used elemental converter?