Skyrim talk:Combat

Archives
Archive 1: Nov 2011 - Mar 2012
Archive 2: Nov 2011 - Apr 2013
Archive 3: Apr 2013 - Apr 2015

Reach for Unarmed CombatEdit

Logic would dictate that the reach for a fist attack would be dagger or less (0.7). Can someone confirm this? — Unsigned comment by 174.17.156.108 (talk) at 01:53 on 13 July 2015‎

Reach for unarmed is actually 1. Silence is Golden^{Break the Silence} 21:56, 28 September 2016 (UTC)

BrawlingEdit

Healing and Mage Armour spells are allowed in brawls. Tested in Skyrim Special Edition 1.3 Radavvadra (talk) 00:36, 2 December 2016 (UTC)

Yes, this page was terribly outdated since the Unarmed Combat page was created. I've removed the offending paragraph as proper details are found on the new page. Silence is Golden^{Break the Silence} 01:19, 2 December 2016 (UTC)

Power Attack Stamina FormulaEdit

Is this still accurate? fStaminaAttackWeaponBase is 20. Where does the 40 come from? Does anyone know the formula as it pertains to GMST variables? Would be nice to have this added, as well.

Edit: According to this [1] the formula is actually:

(11*fStaminaAttackWeaponMult+1*fStaminaAttackWeaponBase)*fPowerAttackStaminaPenalty

fStaminaAttackWeaponMult=1, fStaminaAttackWeaponBase=20, fPowerAttackStaminaPenalty=2

I tested this without perks and a one-handed weapon with 11 weight. It produces the desired results (62). When I try this with a two-handed weapon with a weight of 25, I get 90. So I am not sure how weapon weight factors in. I assume the Perk value just multiplies the total.

Edit2: It could be (weight*11*fStaminaAttackWeaponMult+[1*fStaminaAttackWeaponBase])*fPowerAttackStaminaPenalty. Tests with all Steel weapons confirm it. Stamina use for dual-wield =0.5 per attack is also confirmed.

Artaios (talk) 05:21, 10 February 2017 (UTC)

ANSWER: the 40 comes from fStaminaAttackWeaponBase=20 * fPowerAttackStaminaPenalty=2

(weight * fStaminaAttackWeaponMult + 1 * fStaminaAttackWeaponBase ) * fPowerAttackStaminaPenalty

= ( weight * 1 + 1 * 20 ) * 2

= ( weight + 20 ) * 2

= 2 * weight + 40

— Unsigned comment by 23:54, 31 January 2017 (talk • contribs) on 91.8.77.200

Stagger research via disassemblyEdit

Looked into this on request. Findings below.

StaggerEffect passes its effective magnitude to a function which computes some sort of "rough stagger magnitude." That function uses one of two subroutines, TESV_00599C30 or TESV_00599FD0, to do the bulk of the math; it decides based on (unidentified) actor state flags on the target.

Calculation by subroutine TESV_00599C30(actor1, actor2)

Pretty sure the actors are the caster and target, respectively.

x is a multiplier depending on actor2's current weapon -- that is, one of fStaggerShieldMult, fStagger1WeapMult, or fStagger2WeapMult, or 1.0 if the actor is unarmed.

y is an unknown value obtained from the result of Actor::Subroutine006E1860. This subroutine accesses some AI process-related object (don't let that confuse you; even the player has an AI process; they're just not AI-driven) and retrieves a pointer; if there's no AI process on the NPC or the obtained pointer is null, then y is zero.

a is actor1's Block actor value, multiplied by fStaggerAttackMult and added to fStaggerAttackBase.

b is actor2's Mass actor value, multiplied by fStaggerMassMult and added to fStaggerMassBase.

z is initially 1.0. The following actor values are multiplied into it based on actor2's state: fStaggerRecoilingMult; fStaggerRunningMult; fStaggerBlockingMult.

The result of this calculation is: max(fStaggerMin, b * a * z * x * y).

Calculation by subroutine TESV_00599FD0(actor1, actor2, Arg3, Arg4)

Arg3 is a null pointer for StaggerEffects. Arg4 is the StaggerEffect's effective magnitude. Computation is as follows:

Set b to actor2's Mass actor value. If actor2 is the player, multiply fStaggerPlayerMassMult into b.

If Arg4 is zero, then we set it to a value I haven't been able to identify, computed from actor2 and Arg3.

Set a and d to fStaggerMassMult * b + fStaggerMassBase. If a is non-zero, then set a to 1.0 / a; otherwise, set it to 1.0.

Set b to max(0, (b - fStaggerMassOffsetBase) * fStaggerMassOffsetMult).

Multiply Arg4 into d.

If a check that I don't understand passes, multiply actor1's BowStaggerBonus AV into d.

Subtract b from d.

The result of this calculation is: d.

As such, the magnitude of a StaggerEffect scales the result of the second calculation, whenever that is the calculation used.

So one of those two calculations runs. Then, the game checks whether the result is less than zero. If so, it does a whole buttload' o' stuff I don't really care about, in order to come up with a valid value going forward. Either way, we end up with some acceptable result, and this result is passed to a function on the target actor, which I've labeled Actor::Subroutine006BD700RelatedToStagger.

The value that gets passed into that is modified by Mod Target Stagger and Mod Incoming Stagger perks, and then clamped to the range of [0, 1]. If it's zero, we abort. Otherwise, we continue: the value is written into the target's animation graph (we set the value of graph variable staggerMagnitude), and we also set the graph variable staggerDirection by comparing the actors' positions and the caster's heading. We do some stuff with "actions" (not an engine component I understand) and potentially update the target's ActorState flags (based on conditions I can't identify).

Therefore the magnitude of a Stagger-archetype magic effect is capable of influencing the "stagger magnitude" passed into the target actor's behavior graph, depending on which magnitude calculation is used. There are multiple stagger anims, and clearly the magnitude and direction graph variables decide which to use. I still don't know why the game engine uses one calculation or the other. The UESP editor who requested this research conducted several tests on their own first, and couldn't get spell magnitude to actually change anything, so the first of the two calculations may be more common.

DavidJCobb (talk) 02:58, 21 March 2018 (UTC)

Looking back at this now, I'm 90% sure that the first calculation is used when the actor under attack is blocking. The flag being checked is definitely related to blocking, but I'm unable to discern its exact meaning. (The obvious line of investigation would be to see how the IsBlocking function works, but that actually checks animation state. I found the flag for GetWantBlocking, and it's not this flag. However, this flag gets checked in conjunction with IsBlocking in multiple places, and some no-longer-blocking animation events clear this flag.) DavidJCobb (talk) 22:23, 29 February 2020 (GMT)

The BowStaggerBonus check was something I misread initially. It's actually a weapon type check. Makes sense. It also appears that I misread part of the calculation used for blocking: we divide one of the values. The calculation for the stagger induced by a blocked attack, then, should be:

  float stagger_amount;
  //
  float defend = (defender's Block actor value) * GMST:fStaggerAttackMult + GMST:fStaggerAttackBase;
  float attack = (attacker's Mass  actor value) * GMST:fStaggerMassMult   + GMST:fStaggerMassBase;
  float weapon_mult;
  switch (attacker's weapon type) {
     case one-handed:
        weapon_mult = GMST:fStagger1WeapMult;
        break;
     case two-handed:
        weapon_mult = GMST:fStagger2WeapMult;
        break;
     case shield:
        weapon_mult = GMST:fStaggerShieldMult;
        break;
     case unarmed:
        weapon_mult = 1.0;
        break;
  }
  float state_mult = 1.0;
  if (defender is recoiling)
     state_mult *= GMST:fStaggerRecoilingMult;
  if (defender is running)
     state_mult *= GMST:fStaggerRunningMult;
  if (defender is blocking) // animation check
     state_mult *= GMST:fStaggerBlockingMult;
  //
  float unknown = attacker->TESV_006E1860()->unk24;
  //
  stagger_amount = max(GMST:fStaggerMin, (defend / attack) * state_mult * weapon_mult * unknown);

The calculation for non-blocked hits, and for magic effects, might be trickier to figure out. DavidJCobb (talk) 12:50, 18 March 2020 (GMT)

Power attack timeEdit

Is there a way to calculate how long it takes to perform a power attack for a given weapon? The reason I ask is that it might be useful to be able to compare the DPS of standard versus power attacks.

Zzedar (talk) 16:38, 12 September 2018 (UTC)

Mentioning DaggerfallEdit

I tried adding that Daggerfall was another game in the series that had underwater combat while Skyrim didn't, but it got reverted. Why? So what if Daggerfall plays differently than Morrowind through Skyrim? It's still a main installment in the series, and the first TES game to have the ability to use weapons while in the water. How is that not notable? And if it's so taboo to mention Daggerfall on a Skyrim page, why is it that the entry right above the one I tried to edit still has a reference to Daggerfall? 24.167.247.114 04:59, 27 January 2019 (UTC)

Morrowind, Oblivion, and Skyrim share so many similarities that differences are notable, so much so that we have an entire page dedicated to the main differences, General:Differences Between Morrowind, Oblivion, and Skyrim. It isn't notable to mention any differences to Daggerfall or Arena, as well as any of the other spin-offs because there are so many differences. I reverted your first addition without doing anything about the other note because I simply didn't see it, that is no reason to start going down the path of "if thats wrong then everything else should be wrong too". Your second addition is still on the page, you simply don't see it yet because of caching affecting users without accounts differently to those with accounts. Silence is Golden^{Break the Silence} 12:58, 27 January 2019 (UTC)

If this were a series like Fallout, where the early games really did have a radically different play-style and perspective than the later games, I would agree. But that's hardly the case with The Elder Scrolls. The basic formula is still there, but with a lot of tweaks between games. If Arena and Daggerfall happen to share a common game mechanic with the later games, then by all rights, I should be able to mention it. Daggerfall has underwater combat, and so do Morrowind and Oblivion; Skyrim is actually the only main game since Arena to not have that feature. And don't you think it's ironic how we're not only listing the differences in games based on how similar they are, but when someone actually tries to find similarities with the earlier games, they get swept under the rug? 24.167.247.114 17:56, 27 January 2019 (UTC)

I have to agree with the anon on this point. Including Daggerfall emphasizes to the reader how unusual it is that such a long-lived fixture of the series was removed. I don't see any real reason that the addition of such a small blurb should be opposed besides the fact that it wasn't there already.--Rook (talk) 19:48, 27 January 2019 (UTC)

I agree as well. The biggest difference between Daggerfall and Morrowind is the game world. The gameplay is more different from Morrowind than Morrowind's is from Oblivion, but not to the extent that it isn't relevant. Arena is debatable but I think it gets a pass for being in the main series along with the other four. —Dillonn241 (talk) 14:50, 28 January 2019 (UTC)

Attack Speeds in the Creation Kit are bases/inaccurateEdit

The attacks speeds shown for the weapons in the creation kit is closer to a base speed rather than a true speed. I'm currently running through writing up my documentation and making a video that proves that each attack-type has an attack speed modifier "SkilletBorne" is the name, I'll have it uploaded to google drive and youtube shortly - I'll edit or respond to this with the video proof as soon as I can.

Essentially, Right-Handed Attacks are +12% faster than the creation kit shows, Left-Handed are equal, Dual Attacks are -45% slower and Two-Handed weapons are +25% faster than expected.

One of the easiest verified results for peer review is to record video of 10 swings of The Longhammer and any generic Mace in the Right-hand and sync the first attack on video - they should be the same speed according to the creation kit, however I found The Longhammer to beat the Mace by the duration of a full swing. Equally, try a Mace vs a Battleaxe - the battleaxe is still slower, but by a speed difference of -0.03 attacks per second. — Unsigned comment by 185.101.161.209 (talk) at 15:22 on 17 June 2021 (UTC)