Skip to content

[(BG2) Engine Bug] Attacks per round bonuses (0824) (ToBEx10)

CamDawgCamDawg Member, Developer Posts: 3,438
edited September 2012 in Fixed
This one's a bit difficult to describe, but it's a problem with how the engine handles opcode 1, attacks per round bonus. From the IESDP (emphasis mine):

#1 (0x001) Stat: Attacks Per Round Modifier [1]
Parameter #1: Key Modifier
Parameter #2: Type
Description:
Alters a characters Attacks per Round, by changing the Key by the modifier value specified by the 'Key Value' field, in the style specified by 'Type' field.
Key     Attacks Per Round
0 0
1 1
2 2
3 3
4 4
5 5
6 0.5
7 1.5
8 2.5
9 3.5
10 4.5
Known values for 'Type' are:
0 Cumulative Modifier -> Key = Key + 'Key Modifier' value
1 Flat Value Modifier -> Key = 'Key Modifier' value
2 Percentage Modifier -> Key = (Key * 'Key Modifier' value) / 100
3 Cumulative Modifier -> Same as 0

NB. When this opcode is stacked, the values of the Key Modifier are stacked, not the number of attacks.

The problem comes with effects stacking. Since it's the key value that's being added, a bunch of effects can push the value from 5 to 6 resulting in a drop from 5 attacks per round to 1/2 attack--exactly what happens with Melf's Minute Meteors gets crossed with Boon of Lathander. Melf's sets attacks to five (sets key=5) and then Boon gives a bonus of one attack per round (key+1), resulting in a Boon'd, MMM-wielding cleric-mage to throw a meteor every other round (key=6). We worked around this in BG2FP by disallowing casting MMM when under the influence of Boon or Offensive Spin, but it's a nonsensical hack edit: BG2FP worked around this by splitting the ApR bits of Boon/OS into a separate spells and blocking those spells when wielding MMM, which is wonky but functional.

My question is whether we can modify the opcode to behave more sensibly. In hindsight the key value would have been laid out linearly so that 1 = 0.5apr, 2 = 1apr, 3 = 1.5apr ... 10+ = 5apr and spells that added a full attack per round would just go key+2. It'd be trivial to adjust any BG/BG2 spells to use the new convention, however, this would break all sorts of mod stuff.

At the least would it be possible to prevent the key value from crossing over from 5 to 6?
Post edited by Bhryaen on
«1

Comments

  • BoasterBoaster Member Posts: 622
    edited May 2012
    As a Warrior, if you have two items that grant Attacks per Round bonus the game will provide up to 4 Attacks per Round, even if the two items add +½ Attacks per Round each.

    Additionally, items which subtract Attacks per Round have no effect.
  • deratiseurderatiseur Member Posts: 264
    edited September 2012
    When we want to use the #1 effect, there is an annoying thing :
    When this opcode is stacked, the values of the Key Modifier are stacked, not the number of attacks.
    And the key modifiers are :
    Key Attacks Per Round
    0 0
    1 1
    2 2
    3 3
    4 4
    5 5
    6 0.5
    7 1.5
    8 2.5
    9 3.5
    10 4.5

    So, if a pj with 1 attack/round gain 1 attack/round, no matter, it will have 2 attacks/round
    But if the same pj with 1 attack/round gain 1/2 attack/round, in fact in game he will have 7 attacks/round

    Can you fix this please ?
    Post edited by Bhryaen on
  • BoasterBoaster Member Posts: 622
    Also, subtracting Attacks per Round via Item has no effect. Or especially if you set Attacks per Round to 1 or 0.5 on a Character who is equipped with an item that already boosts Attacks Per Round will be uneffected. This is especially true for Warriors.
  • sarevok57sarevok57 Member Posts: 6,002
    is this from mods? because all the attack per round items in the bg series work 100% correctly, even the gauntlets of extraordinary weapon specializarion give +0.5 attacks per round, and it actually only adds the half, and if you normally have 1 attack per round, and wield 2 weapons that give an attack per round each it gives you 4 like it should ( one for the first weapon, two because the first weapon gives you +1, three because of wielding two weapons, and then four because it the off hand weapon's +1 attack, a.k.a. a swashbuckler using scralet ninto-jo +3 and belm +2, 4 attacks per round, and give him the mits of extraordinary weapon specializarion, 4.5 attacks per round)
  • BoasterBoaster Member Posts: 622
    Okay... I just did some testing.

    When you try to set Attacks per Round with a Fighter to just 1 (say for example you have created an item that's uber good, but limits attacks to one per round) via an item, the Attacks per Round bonus via Level will factor in after the items.

    So if you have a Level 7 Warrior that is wearing an item that sets Attacks per Round to 1, the Warrior will act 1.5 Attacks per Round with that item.

    So the question is: how do we override the Attacks per Round via Level bonus with Fighters?

    Level 7 Warrior
    Item sets Attacks per Round to 1.
    Actual Attacks per Round is 1½.

    Perhaps we need additional item modifier flags that determine if it's before or after level modifications.
  • sarevok57sarevok57 Member Posts: 6,002
    why do you want to set the attacks per round lower?
  • smeagolheartsmeagolheart Member Posts: 7,964
    why do you want to set the attacks per round lower?
    Agree: it's a class benefit for not being able to use magic basically, why deprive a warrior of that?

  • sarevok57sarevok57 Member Posts: 6,002
    unless again its for modding purposes for items and such?
  • BoasterBoaster Member Posts: 622
    Modding.

    "(say for example you have created an item that's uber good, but limits attacks to one per round)"
  • sarevok57sarevok57 Member Posts: 6,002
    @Boaster, ah i see, yeah i know squat about modding, vanilla is fine with me :) (except for the fixed proficiency tables for bg II )
  • SethDavisSethDavis Member Posts: 1,812
    @CamDawg - Just to confirm, if I cast MMM, then cast Boon I should be attacking significantly slower than if I had not cast boon?

    As it stands I attack at the same speed (or maybe a bit faster) with boon on.
  • CamDawgCamDawg Member, Developer Posts: 3,438
    edited July 2012
    @SethDavis
    Have you already applied these fixes on your local build or are you on 0709?

    I was able to replicate this in 0709, though I imported melfmet.itm (not in 0709) and scrla5.itm (MMM scroll) from a patched (but not Fixpacked) ToB install. Created a cleric of Lathander, dualed to mage, cast MMM (5 ApR) followed by Boon (0.5 ApR). The same happens if you first cast Boon (2 ApR) followed my MMM (0.5 ApR). These will be noted on the character record and you can verify them in game.
  • SethDavisSethDavis Member Posts: 1,812
    @CamDawg - yup, those fixes made it in. are they a satisfactory fix for this?
  • CamDawgCamDawg Member, Developer Posts: 3,438
    Oh yeah, they're just a bit of a hack.
  • BhryaenBhryaen Member Posts: 2,874
    Merged two threads dealing with Effect 1 items...

    Thanks @deratiseur for the chart. :-)
  • Ascension64Ascension64 Member Posts: 560
    This is reported in TobEx:10.
  • Avenger_teambgAvenger_teambg Member, Developer Posts: 5,862
    It would be so much better if the engine stacked this effect better.
  • TanthalasTanthalas Member Posts: 6,738
    @CamDawg

    The fixes from here don't actually fix the Attacks per round bonuses bug you describe here right? It just fixes the Boon of Lathander and MMM problem?
  • CamDawgCamDawg Member, Developer Posts: 3,438
    Yeah, I can't do anything to fix actual opcode behavior, just work around it. If the opcode itself is fixed we can drop a big chunk of those MMM/Boon/OSpin fixes.
  • TanthalasTanthalas Member Posts: 6,738
    Ok, then I'll drop @SethDavis ' name here.

    Apparently, the bug is with the Opcode behaviour itself so you need to test it with something else than MMM and Boon of Lathander.
  • CamDawgCamDawg Member, Developer Posts: 3,438
    edited August 2012
    And just a note that if we do get the opcode behavior to work correctly, we'll need to patch just about every spell and item that uses it. I can knock something together, but I'm not going to bother if we can't/won't mess with the opcode. :)

    If we are, ideally the key table would be laid out as

    0 0
    1 0.5
    2 1
    3 1.5
    4 2
    5 2.5
    6 3
    7 3.5
    8 4
    9 4.5
    10+ 5

    So an item that grants bonus ApR would need to increase the key by two instead of one, but that's something I can code fairly easily--just give me a heads up that it'll happen. We'll also have to add something in the BGEE modder's notes that the behavior has changed.
  • BhryaenBhryaen Member Posts: 2,874
    Does that require any special rework of all ITMs presently using that opcode by its more glitchy format? Or would it be safer to create a new one, leaving the glitchy one there in case modded ITMs are set up with it in their own way? I suppose if it hasn't really been working there can't be too many ITMs using it in the glitchy range anyway.
  • Avenger_teambgAvenger_teambg Member, Developer Posts: 5,862
    CamDawg said:

    And just a note that if we do get the opcode behavior to work correctly, we'll need to patch just about every spell and item that uses it....

    It is possible to handle the stat differently, internally, while keeping . GemRB does that.
  • CamDawgCamDawg Member, Developer Posts: 3,438
    Bhryaen said:

    Does that require any special rework of all ITMs presently using that opcode by its more glitchy format? Or would it be safer to create a new one, leaving the glitchy one there in case modded ITMs are set up with it in their own way? I suppose if it hasn't really been working there can't be too many ITMs using it in the glitchy range anyway.

    Yeah, but a WeiDU regexp will identify and knock all of those changes out fairly quickly.

    CamDawg said:

    And just a note that if we do get the opcode behavior to work correctly, we'll need to patch just about every spell and item that uses it....

    It is possible to handle the stat differently, internally, while keeping . GemRB does that.
    If there's a better way to do this and preserve backwards compatibility, go for it.

  • WispWisp Member Posts: 1,102
    ToBEx also solves this internally.

    #1 (0x001) Stat: Attacks Per Round Modifier [1]
    TobEx fixes this effect opcode so that stacking this opcode stacks the number of attacks, not the key. The transformation is done internally, so that the key value is still stored in the effect.
  • AndreaColomboAndreaColombo Member Posts: 5,533
    Which brings up another interesting question, on which @CameronTofer may be able to shed some light: are there plans to implement ToBEx fixes that haven't made it in yet? And what about the non-fix features? I remember Trent said those would be a feature-by-feature call, but he wouldn't mention any ETA. Are they planned post-ship?

    I'm just very curious :)
  • SethDavisSethDavis Member Posts: 1,812
    @CamDawg - I wouldn't count on it making it in (they spread the code that does this pretty thin) but I'm trying to change the way the code handles this now. So conditional heads up
  • CamDawgCamDawg Member, Developer Posts: 3,438
    @SethDavis If it doesn't make it, that's fine. The only place this really falls down is with Melf's Minute Meteors, which we've already hacked around.
  • TrentOsterTrentOster Administrator, Developer Posts: 433
    Ah, Infinity, where you can always count on multiple versions of the same code to show up spread out all over the place.

    -Trent
  • SethDavisSethDavis Member Posts: 1,812
    edited August 2012
    Well, there is some terrifying stuff in the check weapon stats code, but I think I got it all. The scale now goes up from 0 by 0.5 until a value of 5 as in @CamDawg's table above (which they didn't bother making! it's all math and logic everywhere >.< and the haste! oh the haste!)

    Small problems being that all the items/effect need to be redone and characters now have a default number of attacks of 1/2. Not sure where to change that.
Sign In or Register to comment.