[3.03] Confident aim still bugged

[Loren Tyr]

The Confident Aim loading bug still persists in the current 3.03 (.1047) release: https://forums.obsidian.net/topic/87873-303-confident-aim-loading-damage-bug/

 

As noted, this appears to be a loading-specific problem (as it doesn't stack, doesn't happen directly after leveling up and taking CA, it didn't happen when reverting back to 3.02, etc.; see link), and upon some further testing I suspect that the 1.2 multiplier is incremented by one and becomes 2.2 instead; ie. the minimum base damage becomes the old maximum, and the maximum becomes the old minimum x 2.2. This is as at least consistent with the observed base ranges for different weapons

(since these were done by hitting my own NPC lot and observing the minimum/maximum (corrected for multipliers to get base range), they likely didn't quite reach the exact lower and upper bounds). In square brackets are full range if the above theory is correct, as well as the range it should have if CA worked as intended.

 

Dagger:

- without CA: 9 - 13

- with CA: 13 - 19.3 [ theorized = 13 - 19.8, intended =  10.8 - 13 ]

 

Mace:

- without CA: 11 - 16

- with CA: 17 - 23.8 [ theorized = 16 - 24.2, intended = 13.2 - 16 ] 

 

Sabre:

- without CA: 13 - 19

- with CA: 19 - 28.3 [ theorized = 19 - 28.6, intended = 15.6 - 19 ]

 

Hunting Bow:

- without CA: 10 - 15

- with CA: 15.1 - 22 [ theorized = 15 - 22, intended = 12 - 15 ]

 

Arquebus:

- without CA: 24 - 36

- with CA: 36.4 - 50.6 [ theorized = 36 - 52.8, intended = 28.8 - 36 ]

 

Unarmed seems to be completely unaffected by Confident Aim (no conversions either), but it might be that it's not intended to. 

 

Anyway, obviously this makes Confident Aim quite overpowered. Mean base damage is increased by about 48% (whereas if it worked as intended this would only be about 8%, and wouldn't increase the upper bound on it), which is then further amplified by every damage multiplication effect. As shown, it essentially gives for example a Dagger the base damage range of a Sabre.

[Loren Tyr]

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. 

[Sking]

Hey Loren, 

 

I added an issue. We will hope for a fix for a future patch.

 

I got your back

-Sking

[Jojobobo]

Well this was in the beta bug reporting, so why wasn't this fixed in the first place? In fact, I mentioned it separately in the announcements of the beta update to give it extra coverage, and you devs still ignored it.

 

I guess I'll have to wait another three months to continue with a character I sank around 45 hours solo and on PotD. Cheers, all this was greatly appreciated.

 

But thanks for "having our backs".

Edited July 12, 2016 by Jojobobo

[Aurelio]

I'm also a bit surprised and disappointed that the live patch is the same as beta (not to mention with missing translations as usual), when more bugs were reported and said being fixed. So you could have release the beta patch to live way sooner.

Edited July 12, 2016 by Aurelio

[Jojobobo]

Yeah, practically a whole month sooner while all of us were suffering with the stacking bug. This is bull****.

[Baladas]

Obsidibug strikes again.

But is OK, they "hope for" a fix in some patch in the undefined future.

Why so surprised?

Edited July 12, 2016 by Baladas

[Blades of Vanatar]

Really makes fighter unplayable. What gives???? This should be an easy fix.

[Baladas]

Really makes fighter unplayable. What gives???? This should be an easy fix.

For Obsidibug nothing is an easy fix.

[Gs11]

Is it possible that someone who knows how to change the code could use some modding way from mods section or nexus,github and apply this change, so that it coud be fixed, as @Loren Tyr tracked the issue? Does it regard whole dll changes or maybe just  change to confidentaim.unity3d?

 

Or tell me if confident aim works in previous version, if so, what specific version  would  it be?

Edited July 29, 2016 by Gs11

[Loren Tyr]

The .unity3d is fine, it's the loading code that needs to be changed. So that would indeed require changing the .dll. Should theoretically be doable since it is a quite self-contained issue and essentially involves just swapping one compound assignment operation for another, but I don't know how difficult that would be in practice. 

 

Not sure how far back you would have to go actually. For whatever reason Confident Aim always seems to have had some issues, I think it wasn't working at all (the minimum part, at least) in 3.02; but maybe that goes back further than that.

[Tomedro]

Hi, im just curious, has anybody created a fixed dll or a mod yet?

[Loren Tyr]

Not yet as far as I know. To fix it properly requires editing the executable, not sure how straightforward that would be. And since it'll be fixed in the next patch it doesn't seem worth it to figure that out (given that IEMod exists, it must be possible though). I did test a more straightforward work-around editing the asset files, which does more or less work (see here: https://forums.obsidian.net/topic/81559-apparent-bug-ancient-memory-gets-ditched-as-soon-as-you-cast-your-1st-invocation/?p=1834917 )

Edited August 22, 2016 by Loren Tyr

[Sking]

We have a fix for this in our next patch. No date yet, sorry.

 

- Sking

[Tomedro]

@  Loren Tyr

Thank you for the link. Unfortunately this doesnt work for me. I searched for the entry after 222 and 9 (DE 00 00 00 09 00 00 00) in the fightertable, edertable and confidentaim itself and edited it. Did I miss something?

 

@ Sking

So there will be another Patch in the (near) future? I heard rumors that 3.03 was the last patch forever.

[Loren Tyr]

Not sure what you're using to edit it, I use the Unity Asset Bundle Extractor: https://7daystodie.com/forums/showthread.php?22675-Unity-Assets-Bundle-Extractor. On page one of the thread I linked to Livegood gave a good explanation of how to actually change things in the assets (it's a bit finnicky). 

 

See attached screenshot, that's the value that I changed to 0.2. This is in the fighterabilityprogressiontable.unity3d file. Keep in mind though that this is probably only going to make a difference if you take Confident Aim after you have made this change (and saved/reloaded). In existing savegames with Fighters that already have Confident Aim it isn't going to change anything. Though for those, it does work if you respec. I just tried it on Eder with pre-existing Confident Aim. I changed the fighterabilityprogressiontable file, respec'ed Edér, leveled back up to level 3 to take Confident Aim again, quicksave, quickload, damage is precisely in the range it is supposed to be.

 

Fixing the edertable and confidentaim files doesn't appear to be necessary. I expect the first is only used for auto-level, and the second isn't directly used at all (perhaps as a fallback). Enemies with Confident Aim have it embedded in their own asset files, so they presumably don't use the separate confidentaim file either. 

[Tomedro]

I didnt know I had to respec. It works just fine now.

Thank you very much

[AlphaMagnum]

Does this bug affect enemies? I remember saving and loading causing enemies to stack deflection to infinity, but can I avoid this issue by simply not taking confident aim?

[Loren Tyr]

Not entirely sure, but given the way the bug works I would expect that it doesn't initially but will do if the map the enemy is on was loaded previously in that save game; I don't know if it would happen in all cases either though, depends a bit on the area loading model (ie. whether future enemies for that map are loaded in one go or only with the map, etc.)

 

Either way, it's not nearly as debilitating as the earlier stacking bug with deflection. That was a save/load issue that stacked every time, allowing the stats to get out of control badly upon repeated save/load in that map. This present bug is load-only, so even if and when it does affect an enemy it can't spiral out of control in that way. They'll be unusually strong, but not prohibitively so (and won't get even stronger if you reload).

 

Finally, this will be fixed in the 3.04 update. Definitive release date is still pending, but should be in the reasonably near future (see also here: https://forums.obsidian.net/topic/88805-304-update-on-our-next-patch/?p=1843639)

Edited September 20, 2016 by Loren Tyr