a thought on fixing NextDelay for v1.11

[Crystalion]

As I don't have a PhrozenKeep forum account, iirc, and am not in the habit of posting there I thought I'd be lazy and mention this slight code mod that just popped into my head for alleviating most of the idiosyncratic foobar of NextDelay.

Since I'm assuming an expert/modder level of readership for this post I'll not recap the basics of NextDelay or why it horks the usage of some skills (at least in combination) badly. The majority of Lurkers will not find anything of interest in this post, therefore (edit: perhaps the "edit" comment at the very end is of some general interest).

There is probably code somewhere that looks (very) roughly like this...

If currentAttack(NextDelay) then
....If currentTargetBeingCheckedFor"Hit"(NextDelay) then
........"bail" on check as if target doesn't exist (i.e. no-hit & auto-pierce so we effectively jump way down)
....endif
....we'll continue checking (below) currentTarget to hit it and, if we hit it (later?) we will
....set currentTargetBeingCheckedFor"Hit"(NextDelay) = currentAttack(NextDelay)
endif
continue checking

and elsewhere, per frame, each (target) thing gets its NextDelay value decremented (to zero)

Here's my inspiration for altering the logic a little bit (one conditional added):

If currentAttack(NextDelay) then
....If currentTargetBeingCheckedFor"Hit"(NextDelay) then
*.......If currentTargetBeingCheckedFor"Hit"(NextDelay) <= currentAttack(NextDelay) then
............"bail" on check as if target doesn't exist (i.e. no-hit & auto-pierce so we effectively jump way down)
*.......endif
....endif
....we'll continue checking (below) currentTarget to hit it and, if we hit it (later?) we will
....set currentTargetBeingCheckedFor"Hit"(NextDelay) = currentAttack(NextDelay)
endif
continue checking

If it isn't obvious this means that when a big NextDelay comes in, like the 25 frames for a ShockWeb hit, further ShockWeb hits continue to be blocked that frame and until the 25 frames (decrement) passes.

However, a new behavior is that all smaller NextDelay attacks succeed *and* set their NextDelay factor as the current blocktime. This continues to preserve the timing for "groups" of NextDelay but does two things in the player's favor:

1. Your nova won't miss just because the target is atop a ShockWeb etc.
2. some slow effects (such as ShockWeb) will hit more often when other *NextDelay* attacks hit the target

I consider #1 to be a good remedy in all cases.

I consider #2 to potentially be too beneficial to the player, *if* there were a lot of very short NextDelay attacks that could be readily applied to targets (e.g. in an insidious attempt to make a turkey spell like ShockWeb actually worth something). However my recollection of the actual skills involved and NextDelay numbers for them suggest to me that the downside of #2 is very minimal (but I'm perfectly willing for some analyst reading this to point out an egregious counter-example).

Yes, I understand that this is a hack. It is just an educated guess on my part that it is a "better hack" than the current one (the whole NextDelay foo exists because the coding is useful, simple and "efficient").

p.s. of course #2 would be too beneficial to the monsters, *if* it happened to be the case that monsters are using high NextDelay attacks vs. the Player and thus shielding the player from other attacks (as per my faux PvP suggestion that you have a "hostile" assassin throwing ShockWebs on you all the time to protect you from various monster attacks). But again, my educated guess is that this is rarely a significant factor, in practice.

edit: as the game stands, I believe a baba doing a Battle Command or Orders yells grants everyone it successfully applies to 4 frames of immunity to NextDelay Attacks. For example, this suggests you might be able to (with lucky timing) negate a nova. Similarly I believe these yells could fail to take hold on you with unlucky timing (the player to be blessed is suffering from a NextDelay countdown from something else). Doing a simple mod to bump BC or BO NextDelay up to 50 or so would make this easy to verify.