Loren Tyr

That's not really an exception, though. All weapon bonuses stack, with each other and with bonuses from other sources. It's just that as AndreaColombo pointed out, they generally apply only to the weapon they originate from. There's an implied "when attacking with this weapon" clause tacked onto them, so there is never anything to stack. But that doesn't apply to bonuses to other stats not (directly) related to attacking, like defense scores, ability scores, skills, health, endurance, etc.

It does affect spells. Please stop posting incorrect bug reports.

Personally, I'd leave them as is. Maybe not all of them are top-tier picks, but to say they suck is nonsense (and besides, not every talent can be at the top of the list anyway). They're perfectly useful to increase spell availability (especially if you don't like a narcoleptic resting scheme in your gameplay), and I expect there are plenty of people who do use them. Aside from that, turning them into additional spell mastery (or adding a spell mastery talent) would devalue the spell mastery you get as an automatic class talent, which would be undesirable as well I feel. In terms of adding more spell-related talents, it might perhaps be more interesting to have some that improve the effects of spells in some way; either individually or at a group level (akin to Weapon Focus etc.), giving them longer durations or whatever.

Glad it worked, would've been slightly embarassing if I had caused you to buy them and it still didn't work Anyway, I suspect that somehow in Steam or even earlier in the update process some WM2 files got mixed into the non-WM version. Which would also explain why Steam file validation doesn't work, since as far as the Steam system knows the files on people's system are exactly what they're supposed to be. So Obsidian will need to sort out the 3.03 files on their end to fix it. @wconnery: looks like exactly the same issue, indeed. Also Form of the Delemgan + Hiravias and no WM2. The problem happens when you try to add him to your party, I assume? Did you get PoE via Steam, or something else. In any case, you could take Rontu's route and buy WM1+2, but maybe just wait for a response on an ETA on when this will be fixed from the Obsidian devs first. If the problem happens when adding Hiravias, what you could try as well in the meantime is to turn companion auto-leveling off and then add him, he'd start as level 1. Then you could level him manually, maybe that'd work. I'd strongly advise saving a copy of your savegames in a separate folder first though, just in case something does get messed up by this. And if you can't level him up to level 7 yet, I would also test it by using the console to temporarily give yourself enough experience for level 7 (that's when he would get Form of the Delemgan, in WM2). Would be a shame if you played on from there and still ran into trouble when he hits level 7 naturally.

I tried your save game, I got the same crash. Adding Durance to your party fixes it, though.

I have an inkling I know what's going on. In both Rontu's (his own thread) and Sawbonz output log the game tries to load Form of the Delemgan right before it goes the way of the null pointer and dies. Given that this is a WM2 druid spell and at least Rontu doesn't have WM installed, that seems a bit problematic (not sure whether it is possible to tell from the log file whether Sawbonz has WM2, but I would thus expect he doesn't either). This suggests that in the 3.03 update somehow the non-WM games got at least some WM character or class definitions mixed in, at least for the Druid. Presumably this would be fine if (in this case) Hiravias was already in the party, since his definition would already be in the save file. But if he was added to the party through the Party Composition menu or when moving to the second floor of Brighthollow, he likely would be constructed from scratch from the game files, leading to the game trying to load a Form of the Delemgan object that doesn't exist in their installations and failing / crashing to main menu. Edit: in luxferressum's thread on the same Brighthollow bug, the output log shows something very similar. There it's Litany against Minor Afflictions (I assume in conjunction with Durence being out of party and on the second floor of Brighthollow), also a WM2 spell. Though he does indicate having WM 1 and 2 installed, but it still seems rather unlikely to be just coincidental. Then again, when I load his save game I get the same crash when going to second floor Brighthollow, which I don't with Rontu's or any of my own (though in my own, Durance is out of party but not yet at level 7; LaMA works fine when I level him up, though).

@Sawbonz and @Rontu23: just taking an ever so slightly wild stab in the dark here, but would I be correct in saying that neither one of you has White March 2 installed?

Hmm, since the save games themselves clearly aren't affected, it sounds like there is some kind of corruption in the game files. It is possible that when you uninstalled not all files were actually removed. You could try using the "Validate game files" (or something to that effect) option in Steam if you haven't already; I wouldn't expect it to find anything but it doesn't hurt to try. Beyond that, I would be inclined to completely uninstall the game and manually delete any remaining traces of the game; in particular the C:\Program Files (x86)\Steam\steamapps\common\Pillars of Eternity folder, but also the save game folder (copying its contents elsewhere for later use, obviously) and any game folders in the C:\Users\[your user name]\AppData subfolders (it keeps some stuff in the Local or LocalLow folders, I think). Then, reinstall the game from scratch, hopefully that would result in a completely clean (and working) install. I'm just wondering whether there is some way to also check and ensure that Steam really redownloads all files, rather than using some locally cached install files it squirreled away somewhere. I'll check on that tonight.

Generally speaking it should work in the opposite direction, yes. Highest bonus should prevail. But the Horn is the one with the "only when > 50% Endurance" +2 Intellect, right? It probably goes wrong because it isn't an unconditional bonus, I suspect the stacking system isn't quite able to deal with that properly.

That first save game, that had the bug for you? Because I loaded it just now, and had no trouble booting characters out or adding Hiravias...

And if you save that old save game in a new save slot and load that? Does it still work then, or does that make the bug reoccur?

Yes. I'm well aware. I have repeatedly asked you what values you were seeing (before DR). You must have made a note of them, given that based on those values you concluded that the Doemenel talent wasn't working. Here's what I observered for Eder (+48% damage, assorted bonuses) wielding Firebrand (20-30 base, +45% damage, +100% on crit). - Expected damage range on crit: 58.6 - 87.9 - Observed crit damage on 10 consecutive hits: 86 69 59 72 68 79 61 71 64 68 Same, but adding the Doemenel talent, +30% more on crit: - Expected damage range on crit: 64.6 - 96.9 - Observed crit damage on 10 consecutive hits: 92 90 92 82 85 67 93 68 91 70 In other words, clearly the talent works fine.

What happens when you add a new hireling? Does that work properly, or can't you do that either?

Not sure whether there are too many enemies who have it, but in any case it would be high but not insurmountably so. Effectively, CA currently adds a flat multiplier of about 1.5 to Fighter weapon damage (well, and the graze-to-hit bonus, of course). That's a lot, but it's hardly game breaking like the 3.02 stacking bug. So in that regard the main issue is more that you cannot really take it for your own Fighters anymore, as it would be far too powerful (in my view). Also note that it is a loading bug, so expect it won't apply to enemy fighters if you haven't saved and loaded in that area yet.

Except that you didn't specify any values. You just specified a range, which you apparently got by simply multiplying the base damage range by 1.5. My question, which I'm slightly tired of repeating, is: how did you check this? You are claiming that the Doemenel talent does not add the additional 30% damage on a critical hit. How do you know this? What steps did you take to come to this conclusion? Because the critical damage range isn't explicitly shown anywhere. The additional damage is not explicitly noted in the combat log either. So the only way to check this for a particular character + weapon/spell would be to (correctly) compute what the damage range is supposed to be according to the game descriptions, repeatedly hitting something with that weapon/spell, noting the actual damage done with those attacks, and checking whether this is consistent with the range they are supposed to fall into. Did you do this? Because I'm rather inclined to doubt it. For Firebrand ('fiery sword') for example, the base damage is 20-30 damage. It has an inherent +45% damage, and on crit gets +100% for a total of +145%. This gives it an effective damage range of 49 - 73.5. If we add the Doemenel talent the crit bonus goes to +130% damage, the total bonus to +175%, and the damage range would be 55 - 82.5. Some testing will show that damage indeed falls in these ranges, confirming that the Doemenel talent indeed works.

Critical hits just give a +50% damage bonus (same with duration), just like grazes give -50% damage. They are no different from other +X% damage effects. Hence, in this case, the bonus is 15 + 20 + 50 = 85%.

Hmm, I guess I'll have to permanently avoid Confident Aim then... pity. Especially since it is such an easy fix (replacing a single '+' character with a '*' character in the code should do it).

I ask again: how did you test this? Which character, what where the other damage modifiers, what was the DR on the target, and what where the damage values? Because as I said, I just tried it and the results I get confirm that it does work: damage values are consistent with the predicted damage range with the +30%, with multiple values that would be impossible if the +30% was not added. So either the issue is specific to your game, or it's actually working in your game as well and you're just not testing it properly. Absent a clear description of how you are testing it, I'm strongly inclined to believe it's the latter.

Scion of Flames does add the 20% damage, it just isn't shown in the combat log (only some damage bonuses actually are, really). It works like any other +X% damage modifier, when doing another +20%. So for example, a Fan of Flames (base: 30-42) with 15 Might (+15%), Scion of Flames (+20%) and a Critical Hit (+50%) will get a total bonus of +85% for a damage range of 55.5 - 77.7 (prior to DR, of course).

That doesn't answer my question: how did you actually verify that this wasn't exactly the damage range used? Because I just tried it with Firebrand (the 'fiery sword'), and it works fine. Since it is a general CritHit bonus, it will thus work for Fan of Flames as well. So what's your data? What did you try to test this, that led you to the conclusion that it didn't work? How many times did you hit what target, what where the relevant other damage modifiers and DR, and what were the resulting damage values?

By the way, is interrupt duration affected by the victim's DEX as well? Or is that just a flat increase in recovery time?

As MaxQuest's figures show though, the gain in attack speed is pretty much independent of other attack speed modifiers: all else being equal a 20 DEX character will attack about 25% more often than a 10DEX character. The fixed offset 5s (ish) delay obviously spoils the math a little bit especially at the lower end of the attack duration spectrum, but even then the differences are fairly marginal (eg. for a dagger it drops to about 22.5% at zero recovery I think; fast weapons are 20 frames (+ delay) attack duration, right?).

Given that the increase in crit multiplier isn't explicitly shown in the combat log, how did you verify that it doesn't work?

Having dug around a bit in the code, the bug seems relatively straightforward to trace. Confident Aim applies a multiplier of 1.2 to ModifiedStat of type WeapMinDamageMult. In the StatusEffect.ApplyEffectHelper function this multiplier is applied to the WeaponDamageMinMult member variable of the CharacterStats class (which defaults to 1). In the AttackBase class this WeaponDamageMinMult multiplier is applied to the Minimum variable of the DamagePacket (if using a weapon; this is presumably also where 'unarmed' gets skipped over, it gets lumped in with all other non-weapon damage). As this multiplier is set to 1.2 by Confident Aim (if not otherwise modified), this indeed results in the desired 20% increase in the minimum damage. This Minimum later gets used in the DamagePacket.RollDamage function, which crucially does not check whether Minimum < Maximum (nor does the RNG function it feeds into; though mathematically it would be redundant anyway). Anyway, that's when the Confident Aim effect gets applied directly, ie. when leveling up the character. The same WeaponDamageMinMult variable is also set by the CharacterStats.Restored() function, which I am assuming gets called when loading a saved game. I have the relevant bit of code as if (num31 != this.WeaponDamageMinMult) { this.WeaponDamageMinMult = num31; } I expect that there is a bit of mangling going on here by being run through the disassembler, but it should be recognisable enough (the if-statement also seems a bit redundant, but anyway...). This value 'num31' is a local variable which gets referenced exactly twice more in this function: float num31 = 1f; ... case StatusEffect.ModifiedStat.WeapMinDamageMult: num31 += statusEffect2.CurrentAppliedValue; goto IL_1019; } Thus, it gets initialized to 1 and is then later incremented by the StatusEffect parameter value. This gets washed through some potential modifiers in the CurrentAppliedValue getter, but that wouldn't do much in this case. So the parameter value will be the 1.2 from Confident Aim, which means 'num31' indeed ends up as the predicted 2.2. And as noted above, the RollDamage function doesn't check whether MIN < MAX, so a [MIN, MAX] base damage range is flipped into a [MAX, 2.2 x MIN] damage range and Confident Aim becomes way to powerful upon loading a saved game. Which can be fixed by substituting '*=' for '+=' in the above code fragment. Which cannot possibly be too much effort to still do, I would think.

Presumably they will just update the 3.03 entry here: https://forums.obsidian.net/blog/7-pillars-of-eternity-support-blog/ (that was originally posted for the 3.03 beta)