Anisotropic Defixation

I think you should leave gimmick features like rankings and myriad of custom modes for later, most important aspects would be the ability to queue and join through in-game menu and with atcommands.

Who thought it's a good idea to let players easily change size of mobs?

Oh, thanks! No idea how I missed that part.

If there a way to do this? Teleport party members of the player triggering the call but only those currently on the same map.

It actually isn't supposed to ignore DEF now either and only benefits from ranged damage % effects, not racial or elemental cards. You're placing the formula in the wrong block, and without battle->calc_cardfix2 it's going to ignore reductions. In battle.c, move to where CR_SHIELDBOOMERANG formula is (line 4769) and place this below: case RK_DRAGONBREATH:case RK_DRAGONBREATH_WATER:{ wd.damage = ((status_get_hp(src) / 50) + (status_get_max_sp(src) / 4)) * skill_lv; RE_LVL_DMOD(150); if(sd) wd.damage = wd.damage * (95 + 5 * pc->checkskill(sd,RK_DRAGONTRAINING)) / 100; wd.damage = battle->attr_fix(src, target, battle->calc_cardfix2(src, target, wd.damage, s_ele, nk, wd.flag), s_ele, tstatus->def_ele, tstatus->ele_lv); wd.flag |= BF_LONG|BF_WEAPON;}break; Move to line 4301 and add this before flag.weapon = 0: case RK_DRAGONBREATH:case RK_DRAGONBREATH_WATER: Move to line 3005 and replace: if(sc->data[SC_FOGWALL]) { if(flag&BF_SKILL) { //25% reduction if ( !(skill->get_inf(skill_id)&INF_GROUND_SKILL) && !(skill->get_nk(skill_id)&NK_SPLASH) ) damage -= 25*damage/100; } else if ((flag&(BF_LONG|BF_WEAPON)) == (BF_LONG|BF_WEAPON)) { damage >>= 2; //75% reduction } } with: if(sc->data[SC_FOGWALL] && skill_id != RK_DRAGONBREATH && skill_id != RK_DRAGONBREATH_WATER) { if(flag&BF_SKILL) { //25% reduction if ( !(skill->get_inf(skill_id)&INF_GROUND_SKILL) && !(skill->get_nk(skill_id)&NK_SPLASH) ) damage -= 25*damage/100; } else if ((flag&(BF_LONG|BF_WEAPON)) == (BF_LONG|BF_WEAPON)) { damage >>= 2; //75% reduction } } Move to line 2662 and replace: if( sc->data[SC_LKCONCENTRATION] ) skillratio += sc->data[SC_LKCONCENTRATION]->val2; with: if( sc->data[SC_LKCONCENTRATION] && (skill_id != RK_DRAGONBREATH && skill_id != RK_DRAGONBREATH_WATER)) skillratio += sc->data[SC_LKCONCENTRATION]->val2; In skill.c, move to line 2792 and remove both DB entries, add this block below: if( sd && src != bl && damage > 0 && ( dmg.flag&BF_LONG && (skill_id == RK_DRAGONBREATH || skill_id == RK_DRAGONBREATH_WATER)) ) { if (battle_config.left_cardfix_to_right) battle->drain(sd, bl, dmg.damage, dmg.damage, tstatus->race, tstatus->mode&MD_BOSS); else battle->drain(sd, bl, dmg.damage, dmg.damage2, tstatus->race, tstatus->mode&MD_BOSS); } Move to line 4231 and replace: case RK_DRAGONBREATH_WATER:case RK_DRAGONBREATH:{ struct status_change *tsc = NULL; if( (tsc = status->get_sc(bl)) && (tsc->data[SC_HIDING] )) { clif->skill_nodamage(src,src,skill_id,skill_lv,1); } else skill->attack(BF_MISC,src,src,bl,skill_id,skill_lv,tick,flag);} break; with: case RK_DRAGONBREATH_WATER:case RK_DRAGONBREATH:{ struct status_change *tsc = NULL; if( (tsc = status->get_sc(bl)) && (tsc->data[SC_HIDING] )) { clif->skill_nodamage(src,src,skill_id,skill_lv,1); } else skill->attack(BF_WEAPON,src,src,bl,skill_id,skill_lv,tick,flag);} break; For skill_db entries: 2008,9,6,2,3,0x42,1:1:1:2:2:2:3:3:4:4,10,1,no,0,0,0,weapon,0, RK_DRAGONBREATH,Dragon Breath5004,9,6,2,1,0x42,1:1:1:2:2:2:3:3:4:4,10,1,no,0,0,0,weapon,0, RK_DRAGONBREATH_WATER,Dragon Breath - Water For skill_cast_db entries: //-- RK_DRAGONBREATH2008,0:0:0:1000:1000:1000:1500:1500:2000:2000,2000,0,0,15000,200,500//-- RK_DRAGONBREATH_WATER5004,0:0:0:1000:1000:1000:1500:1500:2000:2000,2000,0,0,13000,200,500 You may also want to add exceptions to Neutral Barrier to not block it from both inside and outside if you have coded that part yourself as it isn't in the current Hercules version.

kRO, iRO and jRO all use different enchanting systems for those boots, the script provided by exneval seems to be using iRO's version? You can just adjust things as you see fit.

Not true, there are servers with fully working instance, information isn't hard to get as iRO has the instance.

I wish this issue gathered more attention, it's pretty big.

Looks like the extra HP/SP comes from the base 1 VIT/INT, need to figure out a good way to remove this bonus.

It doesn't looks like the values are entirely correct, while the entries are accurate, it looks like something is adding up to those values in game. Perhaps Novice HP/SP? For example: Level 150 Rune Knight (non-trans) is supposed to have: 14883 HP 460 SP Those are the entries in job_db.conf and they're correct, however, the values in-game are: 15031 HP 469 SP It isn't a big deal but it would be nice to have 100% accurate values.

Is there a way to add multiple levels to those skills? I modified skill_db for them to have two levels, modified skillinfolist to allow selection of level and for them to have two levels as well. Then I added skill_lv conditions to src entries in order create different sets of stuff based on skill level selected. However, while the level selection arrows show up, I can't select the skill level. Using them with @useskill and selecting level works perfectly fine though. Thanks!

Yeah I know, but there must be a way to make it work. Also, the same applies to homunculus.

Using 20140115. I'm experiencing a couple of issues after raising the caps: 1. Aura won't show at level 175, only 160. I know this is old but I haven't found any solutions or hex edits. 2. Job EXP bar won't show anythng past job level 50, as if you're capped already. Any help is appreciated.

Can't wait to see something better than the shitty eAmod BGs.

skill_require_db: 8028,0,0,20:25:30:35:40,0,0,0,99,0,0,mh_fighting,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 //MH_SONIC_CRAW#Sonic Claw# to 8028,0,0,20:25:30:35:40,0,0,0,99,0,0,none,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 //MH_SONIC_CRAW#Sonic Claw# then 8036,0,0,20:25:30:35:40,0,0,0,99,0,0,mh_grappling,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 //MH_TINDER_BREAKER#Tinder Breaker# to 8036,0,0,20:25:30:35:40,0,0,0,99,0,0,none,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 //MH_TINDER_BREAKER#Tinder Breaker#

Is there a way to completely prevent interaction with NPCs and movement when a shop window is open and other similar cases? Basically just one NPC at a time, always.

Bump, this is pretty important.

Any update on this? It keeps breaking so GvG mapflag set though scripts or command doesn't enable GvG related stuf. It goes like this: Boot the server, everything's working, PvP-specific skills and gear aren't working in castles since WoE isn't active. WoE begins, GvG mapflag is applied and now all that stuff can be used. WoE ends, GvG mapflag is turned off, now this is where it breaks, the next time WoE starts, mapflag won't properly apply and all WoE-specific stuff will be disabled since maps are treated as normal zones. Setting it manually with @mapflag doesn't work either. Only solution is to reload scripts or reboot and having to do this after every WoE isn't exactly desirable.

Issue is there's no dump, the crash isn't even detected and recorded, map server just dies while console happily continues to go on, saving things without even reporting it.

Oh I mean that it doesn't report anything at all since the issue seems to be deep one.

Is there a better way to debug?

It isn't even out yet and they're already shooting themselves in the foot with retarded practices and corporate greed.

Figured it out. For whatever reason, mh_fighting, mh_grappling and spirit sphere reqs from skill_require_db are being pulled from the owner and not the homunculus, setting requirement to none and cost to 0 does the trick since her skills have them declared in src anyway. This hasn't happened with older versions though and I couldn't figure why.

Figured it out, for whatever reason the genetic itself needs to have spirit spheres in order to use her skills, they aren't consumed though. Complete nonsense.

Nevermind, the issue is back and seems incosistent as hell, sometimes she's able to use skills and combos just fine, most of the times she won't.