Talk:Gun Spread Formula


Revision as of 00:40, 29 December 2008 by SnakeChomp (Talk | contribs) (Clearer Formatting: You assume to much and here is proof)

Clearer Formatting

I think we can make this page a bit clearer if we simplify the formula by merging the Base/Mult pairs in the variables section. So we'd do something like:

Skill Factor (SF) = fGunSpreadSkillBase + (fGunSpreadSkillMult * RelatedSkillValue)

And then in the formula you could just plug in SF instead of (SB + (S * SM)), which will reduce the length of the formula by ~half, as well as making it easier to understand visually.

Another guideline we could use is UESP: UESP Damage Formula

I have to go out for a bit but when I come back I'll make a mockup on my user page so we can decide which works better

--Quetzilla 21:43, 21 December 2008 (UTC)

I agree the formula is a bit unwieldy. I didn't put it in a <code> tag because that style of formatting messes up when it spans multiple lines. It makes sense to separate it into logical fragments, such as (ISB + ISM) and (CrB + CrM) and etc.--SnakeChomp 22:33, 21 December 2008 (UTC)
Okay, I've complete my mockup of how I think we could improve the page:
This is intended just for the first two sections of this page rather than the whole thing. I've put the formula itself first as that way the essence of how the settings affects things can be comprehended before seeing all the details about the settings themselves
I've left the formula as is, but split up into into 3 stages to aid in understanding. It may not be as comprehensive to see it separately, but I think it will be more helpful to new users looking at the information than the previous method.
Also, is it possible that WeaponMinSpread is just added onto the total spread, rather than the Max() function being used? I imagine that when the other values aren't trivial (skill < 20 for example), the min spread may just be hard to discern.
--Quetzilla 00:17, 22 December 2008 (UTC)
It is definately possible that the min spread is simply added in after the perk multiplier, but its hard to scientifically test that as the observations of spread differences can be subjective. I'll update the formula page based off the new format.--SnakeChomp 03:25, 22 December 2008 (UTC)
Actually I lied, I'll see if I make some tweaks to the example page you made but I'll wait on changing the actual one.--SnakeChomp 03:49, 22 December 2008 (UTC)
I updated the formatting, take look and see what you think.--SnakeChomp 20:27, 24 December 2008 (UTC)
  • ArmFactor needs to be named ArmPenalty or something similar. 'Factor' implies that it is multiplied by something but it is not. I chose Factor and Penalty in my mock up specifically.
  • The initial part that builds up the formula needs a clearer walkthrough in common human terms to go along with the formulas. Also, it should really be in reverse order from this, more how I did in the mock up. The purpose of the page is to illustrate to the reader how the game arrives at the spread that is observed in the game, thus it is important to start from the beginning rather than the end.
  • The parts that say 'fSomeSetting = X.X' need to be clarified to show that they represent the default values and not hard coded constants.
  • Parts where the formula is X + Y * A should be formatted as X + (Y * A). You and I know how PEMDAS works but not everyone reading the page does, and it also serves as a visual aid in understanding the formulas presented
--Quetzilla 23:06, 24 December 2008 (UTC)
I attempted to remedy these concerns with a few changes.
  • Renamed formula components to indicate the intent of the component (Bonus vs Penalty)
  • Removed the first formula box, making note of the minimum weapon spread in a new section below the formula instead.
  • Changed "fFoo = 1" to "fFoo default value: 1" to hopefully indicate these are not constants
I feel it is appropriate to assume that readers have basic mathematical knowledge, so I will leave formulas as they are. This purpose of this page is to document a mathematical formula, after all.
--SnakeChomp 01:04, 25 December 2008 (UTC)
Bonus/Penalty is good. I think the defaults part would look better this way:
  • fGunSpreadIronSightsBase: 1.0 (default)
I think the explanation of the formula itself still needs work, which I might take a crack at later. Do you have a reason for not including the parentheses as I mentioned? They aid comprehension regardless of whether the reader understands PEMDAS or not, and the only downside I can say is possibly that they look ugly, but that can be fixed with formatting.
--Quetzilla 01:31, 25 December 2008 (UTC)
They are unnecessary because the information they provide is redundant? The UESP damage formula page you linked to earlier doesn't include them? I could list several reasons, but this is just a philosophical disagreement. I doubt either of us is going to change our minds. Is something so insignificant really worth the effort to debate? Please just leave it as is.--SnakeChomp 03:09, 25 December 2008 (UTC)
Would you be opposed to doing it this way:

SkillBonus = fGunSpreadSkillBase + fGunSpreadSkillMult*ActorSkillValue

And, it's not a philosophical disagreement at all -- it's a matter of making sure the information is as clear to the user as it can be. All of the boldness and bullet point stuff on the page is 'redundant', and yet it can't be said to be uneccessary. Speaking as a user of these pages, anything that helps to make it immediately obvious what the text/formula means is beneficial.
--Quetzilla 03:24, 25 December 2008 (UTC)
I am continuing this discussion on principle. You claim that the boldness and bullet points are redundant; they are not. Boldness aids in navigating what would otherwise be a wall of text, and the bullet points provide structure to what would otherwise be a wall of text with bolded parts. Both properties help to guide readers through the document and make it easier to find where the one specific component of the formula is defined. Furthermore, you assume that readers will understand what having parenthesis in a formula means. If you assume that, then you must also assume they know about the basic order of operations, because they cannot know what parentheses do without this basic understanding. Therefore I maintain that there is no reason to add them in this instance, nor would there be a reason to remove them if they were already there, as they happen to be on the Weapon Damage Formula page. There is an argument to keep the syntax standard across the formula pages, but honestly, there are more important things that deserve attention.--SnakeChomp 05:51, 25 December 2008 (UTC)

Glancing through it

  • You should be able to fit all of the individual components (i.e., IronSightsBonus) on a single page (no need to scroll) if you remove the default information. The default information is still important, but they can all be placed together as a walkthrough of the formula, as a formula complete with numbers below the top one (not sure if it can be formatted correctly), or as a separate page/section. The last option is not that unusual - the default potion strength information was placed on UESP while the detailed, game setting formula was placed on the CS.
  • The bold type calls a lot of attention to the word - to the point that it's harder to focus on the rest of the equation. Indenting should be enough, maybe bold the game settings:

IronSightsBonus = fGunSpreadIronSightsBase + fGunSpreadIronSightsMult

This value is 0 unless aiming with iron sights (holding the right mouse button with the default control scheme)

CrouchBonus = fGunSpreadCrouchBase + fGunSpreadCrouchMult

This value is 0 unless the actor is crouched (sneaking)
  • The wording for the Walk and Run penalties is a bit confusing. However, ArmPenalty isn't :) ArmCondition makes the equation a bit easier to understand (especially since the equation is already confusing and isn't the intuitive = Base * Mult).
  • I can't play the game yet (card on the way!), so it's unclear just what spread is - is it the chance to miss, does it only apply to scatter weapons like shotguns, does it stray with a chance to hit someone else or is it like Morrowind where a shot connects but "doesn't do any damage"?

--Haama 07:57, 28 December 2008 (UTC)

Spread is effected in the game world as the ability to hold the gun straight. If spread is high, the player's gun wobbles around on the view. The lower the end result spread, the more stable the gun is on the screen (still wobbles, but the degree of wobble is lowered). In combat, the effect is that when the player fires the gun, the gun isn't pointed directly at the crosshair, and is thus more likely to miss the target. The effect matters more when the target is at range, as if the target is close, the deviation from the crosshair won't matter as much.
--Quetzilla 10:08, 28 December 2008 (UTC)
Haama, in response to your suggested formatting, it is incorrect to say that the value of IronSightsBonus is 0 unless you are using iron sights. Only the value of fGunSpreadIronSightsMult is 0 when not using iron sights. fGunSpreadIronSightsBase always uses the value of the game setting. If this was not the case you would never have any spread unless you were trying to aim more carefully using iron sights because IronSightsBonus is multiplied with the result of (almost) all of the other calculations. And just to be clear, "using iron sights" is just like using the zoom-in marksman perk in oblivion. While zoomed you are using iron sights and otherwise you are not.
It would be possible to instead say that "The fGunSpreadIronSightsMult value is 0 unless..." in your explanatory line to correct that, but I feel the loss of default values takes away from understanding the formula. I know I am a biased observer because I derived the formula, but for someone seeing it for the first time I think it helps to know that "When I'm just standing there doing nothing then IronSightsBonus is 1," which you can only know if you know the default values.
Also, maybe a note should be made at the top of the page explicitly instructing people to ignore the variable names because they are meaningless. The formula is only confusing if you read the page thinking that "variables named base should do X and variables named mult should do Y." The names themselves have no bearing on their use in the formula. It is the formula itself that dictates how variables are used.
--SnakeChomp 17:12, 28 December 2008 (UTC)
Actually, ALL of the variables follow the base+mult archetype, (as can be seen in the way I set up the mockup for which the new formatting is somewhat based on) it's just that BGS took some leeway with what kind of related value affects the Mult.
The Base+Mult set up is very simple, and the purpose is to allow the devs to influence the affect of any particular variable on a result by changing the values of the base vs the mult. It's no mistake that in every factor/penalty in the formula, there is a set of values which results in the base+(mult*value) equaling 0 or 1 (depending on how the value is meant to affect the formula).
edit: more specifically in response to Haama's suggestion, this is a result of not using the names I had originally suggested, as 'Bonus' can lead to thinking of the variable as additive, when in fact it's multiplicative, and this would be clear if the variables had retained the original names with the word Factor in them.
--Quetzilla 23:37, 28 December 2008 (UTC)
I see now that this page is missing a clear explanation that a value of 0 is the best result from this formula and values higher than 0 are worse. Without this information it is not immediately clear what the words "Bonus" and "Penalty" mean in the context of this equation.
I chose names like "Crouch Bonus" specifically because when you are crouching you have less weapon spread, or in other words you gain bonus accuracy while crouching, hence the "crouch bonus". "Bonus" is being used to convey the result the user will observe, it is not meant to indicate how the variable is used in the equation.
Also, don't forget that this isn't the only formula page. Among all the formula pages, there are three known cases where the base + mult * value style does not hold. On the Weapon Damage Formula page you have WeaponDamage * fDamageSkillBase + ActorSkillValue * fDamageSkillMult, and on this formula page you have fGunSpreadWalkBase * (IsWalking || !IsMoving) + fGunSpreadWalkMult * IsWalking and (fGunSpreadRunBase + fGunSpreadRunMult) * isRunning. (Note that your mockup page is incorrect when it describes the WalkFactor and RunFactor.) Instead of trying to explain what things like foo * (IsWalking || !IsMoving) mean, I tried to use regular sentences to say that certain values are 0 in certain situations. In looking at the mockup page using a foo * IsWalking style again, it doesn't seem so unreasonable to do it this way, but I am a programmer in my day job, so things like that make perfect sense to me. I cannot really know what makes more sense to non programmers. I think it's safe to say that fGunSpreadWalkBase * (IsWalking || !IsMoving) would require an english explanation for non programmers to understand it.
--SnakeChomp 03:40, 29 December 2008 (UTC)
indenting for clarity:
I hadn't looked at the weapon damage formula page, but looking at it now, I can tell you that it's wrong in terms of the example you listed above:

WeaponDamage * fDamageSkillBase + ActorSkillValue * fDamageSkillMult

should be

WeaponDamage * (fDamageSkillBase + (fDamageSkillMult * ActorSkillValue))

According to your formula, weapon damage as listed in the GECK is cut in half, and then (skill*0.5) is added to the damage. If that were true, then at 100 skill, each weapon would do damage equal to: BaseWeapDmg/2 + 50! Which is obviously wrong. When you use my formula above, you discover that the full damage formula becomes:

BaseWeaponDamage * ConditionFactor * SkillFactor

Where each Factor is a proper base/mult pair.
This is how Bethesda sets up their formulas, so that you have a base value and then you add or multiply related values, where each value is a base/mult pair. Gun Spread is just confusing because the aim is a lower value, rather than higher in the case of weapons, and we don't have a concrete way of measuring the exact final spread to be 100% confident that the formula is correct, such as in this case:

fGunSpreadWalkBase * (IsWalking || !IsMoving) + fGunSpreadWalkMult * IsWalking

where I'm not 100% sure that that's actually true, but I'm taking your word on it because I'm too lazy to test it.
--Quetzilla 04:47, 29 December 2008 (UTC)
Do you have any proof that either of my formulas are wrong other than by assuming what variables do because of their names? Do your own tests if you don't believe the formulas. I keep repeating that the base and mult names are not used consistently as their names would logically lead you to believe and I'm not saying it because I'm bored. I'm saying it because I tested the formulas without assuming anything about how the variables are used. Here is a test you can do.
Set fDamageSkillBase to 0, fDamageSkillMult to 1, use a 10mm pistol at 100% condition on a character with 50 small guns skill. Observe that the weapond damage shown in the pipboy is 5. That is because (0.66 + 1 * 0.34) * (9 * 0 + 5 * 1) = 5. (Note that the skill value is divided by 10 before being used by the formula as explained on the weapon damage formula page. The fact that you missed this part means the formula page should be improved to make this part more obvious.) If the formula was as you suggest, the result would be (0.66 + 1 * 0.34) * (9 * (0 + 5 * 1)) = 45, and that is not what is observed in game. This is why you should never assume that a variable does something because it is named a certain way.
To measure the gun spread, set fGunSpreadRunBase to 0 and fGunSpreadWalkBase to 5. Observe the results with a 10mm pistol while stationary, walking and running. You will have a very small spread while running and a very huge spread while walking or when not moving at all.
It is entirely possible my formulas are wrong, but don't accuse them of being wrong just because they look wrong due to the names BSG choose for the game settings. If you think they are wrong, try them out and prove they are wrong.
I must say that it is frustrating to say the same thing over and over. If you are too lazy to test your theories, don't accuse mine of being wrong.
--SnakeChomp 05:40, 29 December 2008 (UTC)

Formula still needs work

Current Forumla:

Gun Spread = PerkModifiers((AB + AC * AM) + (ISB + ISM) * (CrB + CrM) * (CB + C * CM + SB + S * SM) * (WB + WM + RB + RM))

I think this is still inaccurate particularly this part:

(CB + C * CM + SB + S * SM)

If this is true, then when S (skill) == 100, with default values, that whole part of the equation collapses to 0. That part is multiplied by everything else in the equation except the ArmCrippled influence, but if the arm is not cripple then that is 0 as well, which would result in 100 skill completely eliminating spread, which isn't what I observe in the game. 100 skill would also eliminate any effect of crouching or iron sights, which doesn't seem to be true either.

Also, this formula doesn't take into account the Spread value set on the Weapon Object in the GECK at any point, that I can see.

I have heard that a weapon skill of 100 is indeed supposed to remove weapon sway, but I haven't checked it myself. I'll take a moment to do that, but consider my next statement to see if that describes the behavior you see.
As for the weapon spread on the weapon form, I think there is a max() function that is compared with the value of the formula and the weapon minimum spread chance. Even with the formula resulting in a value of 0. So the real result would be max(min wepaon spread, formula), therefore you never actually have 0 weapon spread, you only ever have something like 0.5 spread as specified on the weapon form (the 10mm pistol has 0.5 spread)--SnakeChomp 22:18, 21 December 2008 (UTC)
Just did a quick test, and indeed, with a weapon skill of 100 using a weapon with 0 spread, there is 0 spread. Using a weapon with a non zero spread, there is still spread equal to the spread value of the weapon form. I'll add this to the formula page.--SnakeChomp 22:22, 21 December 2008 (UTC)
Personal tools