Haste opcode clarifications

[CamDawg]

In the BG opcodes list, haste (16) is described as "Increases the movement rate of the targeted creature(s)." This is incorrect as it also doubles APR. I would instead suggest "Doubles the movement rate and doubles Attacks Per Round (APR) of the targeted creature(s)."

In the IWD opcode list, it says of haste (16) "Applies the Haste effect to the targeted creature(s).". Since I don't think 'Haste effect' is defined anywhere, I would suggest using the same verbiage as BG, above, for clarity.

BG2 and EE use this in the haste (16) listing:

Quote

Applies the Haste effect, in the style specified by the 'Type' value.
Known values for 'Type' are:
0 Normal Haste
1 Improved Haste
2 Speed haste without attack bonuses

Same problem as IWD, in that we've never defined what 'Haste", normal or improved, actually does. For clarity I suggest

Quote

Applies the Haste effect, in the style specified by the 'Type' value.
Known values for 'Type' are:
0 Normal Haste - double the movement rate and one additional Attack Per Round (APR)
1 Improved Haste - double the movement rate and doubles APR
2 Speed only - double the movement rate, no change to APR

 

[kjeron]

Let's go full wall of text (EE's):

0    :    Normal Haste
- (+1 APR, Rounded Down)
- Displays Portrait Icon STATDESC[38|"Haste"]
- Maintains STATS[155|IMPROVEDHASTE] to '0'.
- Maintains STATS[185|ANIMATION_ONLY_HASTE] to '0'.
1    :    Imporved Haste
- (Double APR)
- Displays Portrait Icon STATDESC[110|"Improved Haste"]
- Maintains STATS[155|IMPROVEDHASTE] to '1'.
- Maintains STATS[185|ANIMATION_ONLY_HASTE] to '0'.
2    :    Weak Haste
- (APR Rounded up)
- Displays Portrait Icon STATDESC[38|"Haste"]
- Maintains STATS[155|IMPROVEDHASTE] to '0'.
- Maintains STATS[185|ANIMATION_ONLY_HASTE] to '1'.

(All) Maintains [STATE_HASTED] on the target:
- Every active source of [STATE_HASTED] is counted against every active source of [STATE_SLOWED],  with the higher of the two  determining which state is functional, or neither if they are tied.
-- Haste Sources: Base State, Opcode:16 (Haste), Opcode:317 (Haste Alternate).
-- Slow Sources: Base State, Opcode 40 (Slow), Opcode 78*10 (Disease Slow), Opcode 78*13 (Disease Contagion).
- If STATS[155|IMPROVEDHASTE] is non-zero, effective APR is doubled, to a maximum of 10.
- Else, if STATS[185|ANIMATION_ONLY_HASTE] is non-zero, effective APR is rounded up, to a maximum of 5.
- Else, effective APR is increased by 1, then rounded down, to a maximum of 6.
- Doubles the creatures movement rate.
- Increases the creatures animation speed and the animation speed of Opcode[#140] effects. 
- Reduces the creatures Round timer used by Attacks, Modal abilities and "Auto-Pause: End of Round" in half(6s->3s). 
- Attacks per Round still cycle over a 2-Round period, but the displayed value reflects Attacks Per (6 seconds).
- Aura-Cleansing timer remains unchanged(6s).
- The frequency timer for the following opcodes is reduced to **%, (if greater than 1s):
- Opcode[#25], Poison 
- Opcode[#78], Disease 
- Opcode[#98], Regeneration 
- Opcode[#232], Spell: Cast on Condition 
- Opcode[#272], Use EFF File (at Frequency)

** : It's not consistent, but mostly around 30%, may be rounding issues with the timer:
Disease 1 per 2 seconds for 24 seconds deals 33 damage (36%)
Disease 1 per 3 seconds for 24 seconds deals 22 damage (36%)
Disease 1 per 4 seconds for 24 seconds deals 20 damage (30%)
Disease 1 per 6 seconds for 36 seconds deals 20 damage (30%)
Disease 1 per 8 seconds for 24 seconds deals 10 damage (30%)
Disease 1 per 8 seconds for 32 seconds deals 15 to 19 damage (26%) to (21%)
Disease 1 per 10 seconds for 30 seconds deals 10 damage (30%)
Disease 1 per 12 seconds for 24 seconds deals 5 to 8 damage (40%) to (25%)

[lynx]

Updated upstream: add more of these details, merged bg1 with a warning, softly redirected iwd version and added iwd2 research todo.

Thanks!

[Guest Spellcaster]

Reading what I think is the updated upstream you're referring to, Lynx, I was misled into thinking that Poison/Disease/Regeneration/etc effects would be capped at 1 tick per second max; can't tick faster. I knew something was amiss I've seen faster ticks, so I came here to see what's up. Here's the misunderstood text:

Quote

- increase frequency of application of poison, disease, regeneration, Cast on Condition and Use EFF File (at Frequency), but not below 1s

Reading Kjeron's post above, this should probably be reworded to make it clearer that (if I read that correctly), only those effects that tick at most once per second (and not faster) will get their frequency increased. (damage roughly tripled, according to Kjeron tests on Disease and one I made on Poison using SW1H38.ITM, which led to 28 damage over 30s instead of 10 over 30s)

Then again, I'm not sure if this "if greater than 1s" note has concrete consequences in game. Are there effects that can tick faster than once per second when Haste isn't involved? Movement rate bonus (126) doesn't speed that up. If there's none, then all Poison/Disease/Regen/etc effects have their tick rate ~tripled, in practical terms. Might be worth being more precise than "increase frequency of implication" then, because triple is a lot

[Guest Spellcaster]

*application

On a side note, are we sure normal haste doesn't flat out double attacks per round and/or casting speed in the original edition of BG1? I seem to remember the level 3 haste spell doing more, and being more similar to Slow than it is in BG2.

[Jarno Mikkola]

1 hour ago, Guest Spellcaster said:

*application

On a side note, are we sure normal haste doesn't flat out double attacks per round and/or casting speed in the original edition of BG1? I seem to remember the level 3 haste spell doing more, and being more similar to Slow than it is in BG2.

Yes.

The character animation doesn't matter, only the subjective numbers does, and the subjective number is +1 attacks per round, up to max of 5.

[lynx]

Please submit a pull request with the proposed wording fix, for whatever you're certain of.

[Guest Spellcaster]

I could do that, but would need some confirmations from Kjeron (hopefully he'll see this): I think he's pulling his information from assembly. I can decipher assembly but don't know which tools to use or how to use them confidently to locate what I seek in a large executable, so I can't be certain enough for a pull request without clarification

Instructions on how to do that on my own would be great. But meanwhile, to be able to make that pull request my questions would be:

1/ What does "if greater than 1s" exactly mean in

Quote

The frequency timer for the following opcodes is reduced to **%, (if greater than 1s)

2/ Aren't timers unable to tick faster than once per second without haste? What would be the purpose of this if, then?

3/ What are modal abilities? Is it only things like Turn Undead and Stealth, or do innate abilities and item abilities count?

Quote

- Reduces the creatures Round timer used by Attacks, Modal abilities and "Auto-Pause: End of Round" in half(6s->3s).

4/ How are modal abilities affected by the "creature round timer" going 6s --> 3s ? It seems that a Dorn's Turn Undead ability ticks once every 6s even under haste (BG2EE 2.5.16.6), so... no real effect? They keep ticking the same way in absolute time regardless of round duration?

5/ How is Spell cast on condition (232) affected by this? It doesn't really tick, they get by event. Could it mean that, should the event be fired in very rapid succession [1], such a spell would be able to trigger ~3 times more often under haste? Or is the haste effect supposed to affect effect #232 only when used with condition #10 "Unknown (every round)"?

Use EFF File on condition (272) has time-related conditions like "Once per second", so this question does not extend to effect #272.

 

Thanks! Yes, that's quite a few questions.

 

[1] Like being surrounded by many critters with many attacks per round and a "Target hit" condition with a Self target.

[Guest Spellcaster]

6 minutes ago, Guest Spellcaster said:

It doesn't really tick, they get by event.

*It gets triggered by event. Sorry for the double double post.

[lynx]

2) I don't know which timers you mean, but in general they can tick tick by tick. AFAIK the poison opcode does limit it to a second, but as you know haste and slow affect time itself.

3) No, modals are the abilities that need to fire repeatedly and have dedicated buttons.

 

[kjeron]

3 hours ago, Guest Spellcaster said:

I could do that, but would need some confirmations from Kjeron (hopefully he'll see this): I think he's pulling his information from assembly.

LOL....No, it's all in-game observation.

3 hours ago, Guest Spellcaster said:

1/ What does "if greater than 1s" exactly mean in

2/ Aren't timers unable to tick faster than once per second without haste? What would be the purpose of this if, then?

Those effect trigger once per (x seconds).

If they trigger exactly once per 1 second, with Haste it will trigger twice as often (once per 0.5s).

When they trigger once per (x>1 seconds), with Haste the trigger interval is reduced to the percentages I listed (about to 30%), up to tripling their number of triggers over a given duration.

Quote

3/ What are modal abilities? Is it only things like Turn Undead and Stealth, or do innate abilities and item abilities count?

4/ How are modal abilities affected by the "creature round timer" going 6s --> 3s ? It seems that a Dorn's Turn Undead ability ticks once every 6s even under haste (BG2EE 2.5.16.6), so... no real effect? They keep ticking the same way in absolute time regardless of round duration?

Turn Undead, Stealth, Bard Song, Shaman Dance, Find Traps ... though it appears I was wrong about them, it only affects Stealth, or more importantly the Stealth Cooldown, not sure what happened.

Quote

5/ How is Spell cast on condition (232) affected by this? It doesn't really tick, they get by event. Could it mean that, should the event be fired in very rapid succession [1], such a spell would be able to trigger ~3 times more often under haste? Or is the haste effect supposed to affect effect #232 only when used with condition #10 "Unknown (every round)"?

Trigger conditions 1-6, 8-9, 13-15, and 18-21 are normally checked once per round.  Haste/Slow affect their check frequency the same as the other listed opcodes.

Edited October 23, 2020 by kjeron

[Guest Spellcaster]

Oh drat, I was under the impression that you and Bubb from Beamdog forums worked at a level lower than NearInfinity. The amount of in-game tests required to outline game mechanics in such a thorough and fine-grained way is huge! Especially since EE seems to require rebooting the game for changes made to many file types, whereas original edition works fine with just reloading a save file to pick up changes in most cases. Though EE's C:Exec() and C:Eval() are handy additions.

Did you make yourself productivity mods or something? It would be useful if I was able to significantly increase the speed at which I can test stuff. Gather more data without spending more time.

Quote

Trigger conditions 1-6, 8-9, 13-15, and 18-21 are normally checked once per round. 

Thanks! Since my last post I've done a couple tests, once per round translated to 4 times per round with Use EFF file on condition (272) according to The Brick (ohnhamm1.ITM) modified to provide console feedback each time the EFF triggers. (20 triggers over 30 seconds, 40 over 60s)

I see that your result would say a x3.33 factor on ticking rate rather than my x4 one, for the 1 trigger per round case. I'm using a physical clock to measure this, since using an effect that runs out after a set amount of time in order to rely on the game clock is not very flexible or productive when you have to restart the game all the time.

Basically I'd like to verify that it is pointless to try and describe in simple terms how the various "amount of ticks per unit of time" cases encountered in game will be affected when haste comes into play.

Thanks for the replies :)

 

PS: Okay for original edition BG1, I'll trust that I dreamt normal haste doubling spell casting speed :)

Can't test any way.

[Guest Spellcaster]

Disclaimer: I'm quite unlikely to do a pull request, sorry, I am focusing on the Fandom Wiki and the higher level of accuracy and thoroughness of IESDP would require further tests for me to feel satisfied. Still putting results here.

 

So I spent some time testing and it appears there's an easy way to describe how much the Haste effect speeds up the various cases available in game. This was tested *only* on BG2EE 2.5.16.6, and *only* (but extensively) with normal haste. Movement rate bonus (126) has no effect, with or without Haste. For all five effects listed by Kjeron, in their sub-configurations that involve time, we have the following multiplier apply to ticks per unit of time:

• Effects that tick once per second or more: x2
• Effects that tick once per 2 or 3 seconds: x3
• Effects that tick once per 4 to 7 seconds: x4
• Effects that tick once per 8 to 15 seconds: x5
• Effects that tick once per 16 to 31 seconds: x6
• Effects that tick once per 32 to 63 seconds: x7
• etc.

Cast spell on condition (232) uses conditions such as Time of day is 'Special' (13), Target in range 4' (8) and Target in range 10' (9). These seem to trigger approximately every 100 AI tick, or once every 6⅔ seconds. The factor they receive with Haste is x2.

Basically, except for the special case above, the multiplier grows by one on each power of two of the seconds value.

 

###############

Finally, I checked the original BG1 very quickly, and while casting speed is not increased by Haste indeed, the spell doesn't seem to grant an extra attack. This was *only* tested on a mage with 1 attack per round: It didn't grow to 2. Not enough to describe a behaviour but enough to point at an inaccuracy in the current IESDP.

Thanks for this awesome resource that is IESDP, by the way!

[Guest Spellcaster]

I forgot one thing. The way extra ticks from Haste are spread is not even. If an effect ticks once every 60 seconds, Haste will boost that to 7 times every 60 seconds. But the first tick will occur at the 30s mark. The second at 45s, third at 52.5s, etc. The next tick happens in the middle of the remaining duration. In the example used here, 4 out of 7 ticks will happen within the last 4 seconds.