UESP Forums

If anyone knows how these stats are calculated or can tell me where the hex code is located, I would appreciate it.

(Using v1.06 from Anthology - DOSBox v0.74-3-3)

A Mages starting Health is 25+d6, according to the manual. If you re-roll the stats for the Mage you will quickly see a low of 24 and a high of 31. This matches what is expected. 25 + 6-sided dice role (0-5).

EDIT - a standard d10 die will be numbered 0-9 (different players count 0 as 0 or 10) Further testing with the Mage class, I rolled 24 on two occasions (very rare). I neglected to account for the Health modifier that Endurance causes. On the rolls of 24, the Health modifiers were (-1). This means my Health was 25 + d6 (which rolled a 0) = 25. Then the health modifier 25 -1=24. This does not account for the values when rolling for a Thieves class, nor does it account for the heavy middle weighting mentioned later.

While accounting for a possible (0) roll, clears up much when rolling for Health, this conflicts with UESP information on rolling for Endurance. Endurance is calculated as 37+4d6+racial/gender modifier. If d6 is 0-5, then a max 4d6 roll would be 4X5=20. The maximum racial/gender modifier is (+10) for Redguards or Male Nords. So the MAX endurance you could roll would be 37+20+10=67, however, I'm rolling 68 and 69 with a male Nord. The most likely explanation for the discrepancy is a conflicting usage of "d6". I don't believe the endurance calculation is written in some manual from back in the day, but determined by later players who examined the code. It's possible that endurance is based on a standard die (1-6) while Health calculations are basing their rolls off of the d10 which started with 0, so to make it uniform they started all of them with 0. (Technically only the actual d10 started with 0.)

However, if you try this with the Thief, things don’t add up. A Thieves starting Health is 25+d10, according to the manual. So, we should expect values in the range of 25-34. However, when re-rolling stats for the Thief, you quickly see values larger than 35. In my testing, I’ve found the range to be 25-39 making the starting Health 25+d15. The other thing I discovered was that rolling a 25 or 39 was VERY difficult.

EDIT - D15 is an odd number. It took over 700 re-rolls to roll anything that would = 25; [25, 24{-1 Health modifier}, 26{+1}, 27{+2}]. There were several hundred more before I started keeping track. It seems more likely that this is D16 with a ridiculously low probability of hitting the highest/lowest.

I experimented using the Warrior which has a starting Health of 25+d20 (EDIT- needs more testing as this is not uniform with 0 being an option. It was also written before I was taking the Endurances Health modifier into consideration.), both according to the manual and also my testing. The range of rolls you get are between 26-45, however, rolling a 26 or 45 felt nearly impossible. So, I did a comparison between two online d20 dice rollers and Arena using 50 rolls each. For each set, the average time a number was rolled was 2.5. That matches the expected; 50 rolls divided by 20 options = 2.5 times each number can be expected to appear. The mode (the most common number of times a number appeared) for the online rollers was 3, while for Arena was 2. That’s still about right. It’s a small sample size (only 50 rolls). Most of the time, out of 50 rolls, you will see most numbers come up 2 or 3 times.

In a very basic statistical view, Arena appears to be calculating the same as an average d20 dice roll. However, this is not true in reality. With a dice roll you have an equal chance of rolling any of the 20 numbers. In Arena, the middle is weighted heavily and the extremes are weighted very light. You are VERY likely to roll a +8-13, but the higher or lower from that range, the less likely you are to see it. Online, the numbers that didn’t roll at all, rolled the most, or rolled an average amount of times are scattered throughout the numbers of 1-20. In Arena, however, 8-13 are rolled ~5 times, while 14-20 were rolled 1 or 2 times, and on the low end 1-4 were rolled 0 times and 5-7 were rolled an average of 3 times.

This was only one test of 50 rolls for Arena, but I had previously rolled hundreds of times and noticed this pattern, which is why I decided to do a formal test. Also, although 1-4 were rolled 0 times during my test, I did record rolling a 1 during other testing. It can be assumed that all the values are possible, but some are unlikely.

The table for starting health rolls is at address 0x42001 in the UNP-decompressed executable file. It contains these values:



This seems to be consistent with the table at http://en.uesp.net/wiki/Arena:Classes#Class_Tables.

Now, I don't completely understand what the code is doing, so the following explanation could be wrong. But I think the algorithm to calculate starting health works something like this:

Say the class-specific die has n sides. If n is 8 or smaller, generate a random number from 0 to n-1.

Otherwise, if n is greater than 8, keep adding 1 to it until it's a multiple of 5 or 6 (don't add anything if it's a multiple already) to obtain a new number. Then roll the corresponding amount of d5s or d6s that could theoretically reach that number (except zero is included, so it's more like d6-1 or d7-1). If the result is greater than the original n, repeat this process until it's at most n.

Once the random number is obtained, add it to your heal mod. If the result is zero, set it to 1. Add 25 to get the final starting health.

So for a Mage, the starting health should be 24 + d6 + heal mod, + 1 if equal to 25.
For a Thief, the starting health should be 22 + 3d6 (ignoring 18) + heal mod, + 1 if equal to 25.
For a Warrior, the starting health should be 21 + 4d6 + heal mod, + 1 if equal to 25.

Finally, the heal mod is added to your health a second time when character generation is complete, so if you naturally rolled a non-zero heal mod, it could end up being applied twice.

(I probably should have checked the OpenTESArena wiki before writing this up, as it already contains most of this information under Character Generation. However, the roll algorithm on that page has a check to see if n is a multiple of 4, which I think is a mistake.)

Wow, thanks for that explanation, @ArgonianAccount! I'm not sure I follow all of it, but that's because the logic they used for n>8 seems needlessly complicated.

Thanks @ArgonianAccount. It's going to take me a bit to process that, but it is EXTREMELY helpful to me.

Could you also direct me to the OpenTESArena wiki?

I located a post that had some info and then mentions that they were putting the rest on the wiki, but every time I try to look I seem to only find general updates and completion/needs work notices for OpenTESArena and not anything from the original game.

I had completely forgotten about programs like UNP. That was fun. Running UNP through DOSBox on a Mac. I like to overly complicate my life. Actually it was pretty easy. Thank you SO MUCH for giving me the address in the file. I would have never found it on my own. I used this to verify that v1.06 and v1.07 were identical. I didn't expect a difference, but I'm a completionist and now I "know".

These values correspond to my testing and confirm that the Thieves group of classes do not match the values in the manual. I saw the chart on UESP, but when I read the title of "Hit Die", I associated that with attack, and neglected to read the details.

Okay - so this appears to be the mechanism for generating a random number of a given "d" value. Someday I'd like to know why they were not able to (or chose not to) generate random numbers from a pool larger than 8. But when I consider machine language and bits and bytes, "8" becomes a common factor. I'll have to do some testing to see if this method accounts for the heavy weighting of middle values. (Try rolling a "d" value under "5" for a Barbarian!)

Is the "n-1" ...actual? I ask because I've now come to the conclusion that a d8 is neither 0-7, nor 1-8, but rather 0-8. (At least from an external view of the final value presented.)

I assume this is an approximation for creating health stats using only d6's rather than a description of how the code is actually processed. Otherwise, I need to ask; How are the starting values determined for the classes in your example? (Mage-24 / Thief-22 / Warrior-21)

From an observational approach, I have evidence that for a Thief with a starting value of 25 and a roll of d14, you can roll anything from a 0-14. The highest I have recorded is a 40 (with recorded +1 Health modifier) and the lowest being a 26 (with a +1 Health modifier) or 25-39.

On a masochistic side note: I videoed rolling apx. 100 times for each gender and race for the Thief class. Of the 16 sets, only 2 generated a "0" roll (26 +1health mod) and 11 generated a "14" (39 with 0 modifier or 40 with +1 etc.). That doesn't sound that bad, but I rolled a "14" many times but only rolled a "0", twice out of 1600 rolls. But the result is the same and confirms the pattern. "0" is possible, but becomes less probable with increasing "d" value.

The wiki page I mentioned is at: github . com/afritz1/OpenTESArena/wiki/Character-Generation

I would have added it to my last post, but I don't have the ability to post external links yet.



The game is able to generate random numbers up to any desired size, so I think they used this method for the weighting effect it provides. Or maybe it was a general influence from tabletop games.

One thing that I forgot to mention earlier is that in the n > 8 case, if n is a multiple of both 5 and 6, then 6 takes priority.



The range is from 0 to n-1 inclusive for values of n <= 8. The random number is obtained as the remainder of a division by n, so it must be less than n. Only when n > 8 does the range also include n.



Those values are just the number of dice rolled subtracted from 25, to offset their 1-based nature and simplify the example. (The actual game doesn't do this; it uses 0-based random numbers.)

Thank you so much for taking the time to walk me through this. I really appreciate it and I hope my questions are not too much of a bother. I really just want to understand and get passed some of my initial confusion.

I'm sorry, but I need a little hand holding for this one. I'm reading this as contradictory and I'm not sure what I'm overlooking or doing wrong.
So if this is a physical die with 8 literal sides and I want to generate a random number of the 8 sides but start counting at "0", then my 8 sides include "0" through "n-1" or "8-1" or "7". (I'm drawing this out so hopefully you can show me where I'm getting tripped up.)
This is where I feel confused. I read "0 to n-1" as "0-7". But "inclusive for values of n<=8, I'm reading as "0-8" (n=8; n-1=7; 0-8 are values less than or equal to 8 )

My confusion aside; I believe I understand what you are telling me. Specifically in the game mechanics, when a die roll is specified that is d8 or less. (ex: Mage=d6, Healer-d8), you will begin with a random number starting at 0-5 (for Mage) or 0-7 (for Healer). If, however, the "d" value is greater than "8", then you keep adding "1", until it is divisible by "5" or "6". (I realize, I'm simply repeating you. I'm trying to restate it to be sure I'm getting it correctly.) So a d10 (Bard) is already divisible by "5 and d12 (Acrobat) by "6". For the Bard (d10), I roll two d5 dice. However, unlike my roll for d8 which was 0-7 (n-1), My d5 dice are full sets of 0-5 (including "0" and "n")

For a d14 (Thief), I add 1 to make it a d15 and divisible by 5 and roll three d5 dice (0-5). If however I roll greater than my d# (my "n" number of sides, or 5-5-5), then I roll again until the result is in the range of 0-14.

This works because the dice are not physically 5 sided and include 0's. Otherwise the smallest number you could roll would be "3"; (1-1-1).

This {(0 through n-1) for d8 or d6}, but {(0 through n) for higher d's}, would explain why my Thief (d14) rolls have produced values of (0-14), but my Mage (d6) results so far have only produced (0-5).

Thank you for this. This also helps to explain the formula used on the Character Creation page for stats.
This works if the dice are 1-6, but then it doesn't match how a d6 is used when determining Health stats. If you consider that this is equivalent to a 41 + D20 + racial/gender modifier, where D20 is 0-20); then it now matches the manuals usage of "d" rolls as well as the calculations you have described.

Unless I totally trashed the above information, I think I understand now. Again - Thank you so much for taking the time to walk me through this and help make this so much clearer for me. ....and save me from another 2000 re-rolls.

I think you've pretty much got it, but I now see I could have worded some parts better.

When I said, "The range is from 0 to n-1 inclusive for values of n <= 8", what I meant was, "When n <= 8, the range is from 0 to n-1 inclusive." Does that make more sense?

@ArgonianAccount - I think your wording was fine, I was just over thinking it. I'm curious now. Why do you believe the check for n equal to 4 is a mistake on the OpenTESArena wiki?
-------------------------------------------------------------

The below information is mostly here for me to work through it, but if anyone sees where I’m misinterpreting or misunderstanding, please correct me.

The formulas on the OpenTESArena Wiki are as follows: Under “Player stats” we have “Health on generation”

For the function “Roll” we find that under "Character Generation"

Some reference anchors:

• “=“ is used to apply a value to a variable [ex: Health = Roll(..parameters). If you roll a 7, “Health” is now equal to “7”]
• “<-“ used exclusively in the “Roll” function and is the same as above. Sets/assigns a value to a variable. I’m not certain what programming language this is, but this appears to be the general idea. In the first line for the “roll” function we see “function roll(n) <-“ Where it appears that it is saying that the function’s value will be returned by the formula below.
• “->” on the other hand appears to be a marker of connection. Sort of like items in a specific folder. (ex: npcData->maxHealth. “maxHealth” is the variable, but it specifically belongs to the group “npcData”. npcData->maxHealth and npcData->Class)
• “==“ This is used in IF statements to compare if the two variables are equal to each other.
• “mod” this returns the remainder after dividing a number by a value. So in the statement “if test mod 6 == 0”; if we are starting with “d14”. “test” is now equal to “14”. We take 14 and divide by 6. It can only go in twice as a value of “12” and leaves a remainder of “2”. We then are asking is “2” equal to “0”. Since the answer is “no”, we skip the rest of the line that starts with “then”, and we go to the next test, “else if”. So in this fashion we are trying to find a value that can go into our d# equally (leaving a remainder of “0”). “Can 14 be divided equally by 6; no; how about 5; no; how about 4; no…”. If the final answer is “no” then the last “else” adds 1 to our number. “test” currently = 14, so, “test <- test + 1” means we take the variable “test” and now make it equal to (<-) “test +1” or “14+1”. From now on, “test” now equals “15”
• “throwXdY” This one is kind of fun. I believe this is another function, but I didn’t find the actual formula. However, the term itself “throwXdY” is generic for throwing “X” amount of dice, that have “Y” number of sides. So if we go back up to our variable “test” which now equals 15, the “while” and “do” statements are going to send us back up the the “while true” section and we test it again. “Can 15 be divided equally by 6; no; Can 15 be divided equally by 5; yes”. With a “yes” answer we continue the line past the “then” statement. Well then…variables X and Y are now equal to (<-) “test” divided by 5 and 5. So X=3 (test/5 or 15/5), and Y= 5. Now we can escape our “while” loop and we find the next line “value <- throwXdy(X,Y)”. Our variable “value” will now equal the sum roll of X number of Y sided dice. Or 3 dice, each with 5 sides. The next line “while value > n” makes us throw the dice again if the value is greater than “n” which was our starting “d14”.

Now that was lengthy, but it was so I can point out that there isn’t anything in the ROLL function that mentions n-1. If the d value is d8 or d6 then the function only executes the second line. “if n <= 8 then return rnd(n).” If "d8” is less than or equal to 8; then return a random value based on “8”. (EDIT: or rather based on "6" if "d6, etc.) Whether that is 0-8, 0-7, or 1-8 depends on how the “RND” function operates. My point is simply, according to this function, a d8 is not treated differently than a d10 (in terms of range), which is unlike how I was describing in my previous reply.
------------------------------

The “Health on generation” appears to do the following:
1. Determine the “health” variable and assign a value using the “roll” function”.
2. Add the “BonusHealth” (based on Endurance values) to the “health” variable.
3. If health equals “0” (meaning your roll value was “0” and your “BonusHealth” was “0”, then add “1” to health. So “health” now equals “+1”
4. According to a note above this code; “25” is then added to the final result.

This really seems unnecessary but results in spreading out the lowest values so that “rolling a “0” is even less probable.

Actual Roll / Actual Bonus / Health(roll)+Bonus / (Health=1 if "0") / +25 | percieved roll
......0................-1....................-1.....................-1.............24.|........0
......0.................0.....................0......................1.............26.|........1
......0.................1.....................1......................1.............26.|........0
......1................-1.....................0......................1.............26.|........2
......1.................0.....................1......................1.............26.|........1
......1.................1.....................2......................2.............27.|........1

(EDIT: further testing shows instead of saying "If Health=0 then Health=1"; it matches the game output better if you state, "If Health<1 then Health = 1". See later post where this is addressed more fully.)

This will probably be my last comment on this topic except to respond to any further conversation.

Without an ability to explore and understand the original code, all of my external testing backs the way that ArgonianAccount first described the process and my later comment which attempted to explore and put it in my own words.

From an external experience, when rolling for Health, the following can be expected:

• d6 and d8 will see a random result of 0-5 and 0-7 respectively
• d10 and greater will see a random result from 0 to the maximum "d" value.
  
  • EX: d10=(0-10), d18=(0-18), d30=(0-30)
    
• The greater the "d" value, the less probable it will be the result is a high or low value.
  
  • The probability of rolling a "0" with "d10" is 1 out of 36. (1 out of 10 with physical dice)
    
  • The probability of rolling a "0" with "d14" is 1 out of 215.
    
    Exploded view of d14 as example of others
    
    • 0 (1/215)
      
    • 1 or 14 (3/215)
      
    • 2 or 13 (6/215)
      
    • 3 or 12 (10/215)
      
    • 4 or 11 (15/215)
      
    • 5 or 10 (21/215)
      
    • 6 or 9 (25/215)
      
    • 7 or 8 (27/215)
      
  • The probability of rolling a "0" with "d20" is 1 out of 1,296. (The odds of rolling a YAHTZEE)
    
  • The probability of rolling a "0" with "d30" is 1 out of 16,807 (Correction: 16,805)
    
  • d6 and d8 are the exceptions.
    
    • d6 has a 16.6% chance of rolling any value 0-5 (1 out of 6 ).
      
    • d8 has a 12.5% chance of rolling any value 0-7 (1 out of 8 ).
      
  The next two come from examining the code at OpenTESArena, but the probability of this occurring is so low, it may never be noticed.
• Rolling a "0" is slightly reduced for characters with "0" Endurance bonus
• Rolling a "2" is slightly increased for characters with "-10" Endurance bonus

-----------------------------------------------------------------------------------------------------

The code presented on OpenTESArena appears to be pseudo code to represent what is happening rather than specific coding information. The various uses of "random" functions points to this.

d# = (0 through # /or/ 0 through #-1 /or/ 1 through #)?
I've collected values from d6,d8,d10, and d14 that indicate a "0" roll.

The code from OpenTESArena indicates that d6,d8 use one function for rounding and the rest use another. Because the second function GREATLY reduces the likelihood of rolling the highest value, it should be easier to roll the highest with d6 or d8. This, however, is untrue. I've rolled the highest with d14 many, many times. I have NEVER rolled the highest with d6 or d8.

It is also not possible that both sets of random functions roll with n-1. To roll for d10, the functions calls for rolling 2 d5's. If they are 0-4 then the highest possible roll is "8". This does not match the possible values in Arena.

The only conclusion (barring further information) is that the random function "rnd()" used for d6 and d8 uses (0 - n-1), while the second random function "throwXdY" uses (0 - n)

One final note
While I can see no benefit to that little process that adds "+1" if your initial Health is at "0" (before the "25" is added); I can tell you the obvious end result. -- You will never have a roll where your initial Health is equal to 25. The lowest it will ever be, will be 24 with a -1 health modifier; or 26 with a +1 health modifier.

P.S. @ArgonianAccount -- I agree with your comment about the use of d4's in the code at OpenTESArena. The only one it would be used for is d16, but if you simply run two more iterations, you can use d6's. The use of 4 d4's rather than 3 d6's, completely upsets the weighting progression. Unless it can be shown to be an "actual" part of Arena's code, it is a superfluous and counterintuitive option.

The <- assignment syntax resembles Haskell, OCaml, or F#. I'm not familiar with any of those, so I don't know how consistent the rest of the code is with any of them, but Haskell was around when Arena was originally programmed, whereas F# might be the more likely suspect if it's new code from OpenTESArena.

Sorry, I meant to reply to this earlier.



The function that tests for integer multiples looks something like this:



It starts by checking if n is a multiple of 6, and if so then if returns the two values n and b+1. (Those values then get passed into a function that generates n random numbers, each in the range [0, b+1).) Otherwise, it decrements b and tries again with b == 5. However, when b is decremented a second time, it fails the 'b != 4' check, and so the outer loop runs again with b == 6 and n incremented by one. I think that check was misread as exiting the loop after doing 'n mod 4', which never actually gets a chance to run.

@SeaGtGruff - The main reason I called it "pseudo" code was because of all the various "random" functions that were doing the same thing. It's possible that different authors re-created their own versions, but it seemed....messy. Their downloadable source code looks very organized, though I don't think these functions are a part of that code as of yet. They just feel, to me, more like work-boards rather than copies or finished code.

@Argonian Account - With your code on the "multiple_test"; that's pretty clear. Though I can see how I could accidentally overlook that it drops out before actually running d4's. I realized last night that I can actually prove whether or not it uses d4's. Four d4's or three d6's have finite possibilities as well as specific and distinct probability maps. So I could just run some sets and compare the probability map Arena produces.

ARENA-500rolls

d6 6-6-6 (0-6)...............d4 4-4-4-4 (0-4)

Roll#.....%rolled..................6-6-6%......%diff...............4-4-4-4%........%diff
0...........0..........................0.29..........N/A.................0.16.............N/A
1...........1.2.......................0.88..........36...................0.64.............88
2...........2.4.......................1.75..........37...................1.6...............50
3...........2.6.......................2.92..........11...................3.2...............19
4...........3.8.......................4.37..........13...................5.6...............32
5...........6.2.......................6.12..........1.....................8.32.............25
6...........9..........................8.16..........10...................10.9.............17
7...........7.8.......................9.62..........19...................12.8.............39
8...........11.4.....................10.5..........9.....................13.6.............16
9...........12.2.....................10.8..........13...................12.8..............5
10.........10.4.....................10.5..........1.....................10.9..............4
11.........8.4.......................9.62..........13...................8.32..............1
12.........7.2.......................8.16..........12...................5.6................29
13.........7.4.......................6.12..........21...................3.2................131
14.........3.8.......................4.37..........13...................1.6................138
15.........3.4.......................2.92..........16...................0.64..............431
16.........2.8.......................1.75..........60...................0.16..............1650

It's pretty clear Arena isn't using d4's here. Though the d6 map comparison isn't as clear as I would like it to be. The differences at "1" and "2" could possibly be explained by that funky "+1 if 0" thing, but it's still a little off. But "16" !?! It doesn't match at all. I would really like to know what that "throwXdY" function is doing and why it is different from rolling for d6 and d8.

Follow up / clarification:

The code from ArgonianAccount clarifies why, when rolling for "d" values above 8, the random function uses "0 - max". (EX: d8 = random(8) runs 0-7; while d16 = random(17) runs 0-16 because "+1" is added to the value; {b+1})
I was focusing on whether d4 was used and overlooked that this part of my questioning was already answered with this.

I was still questioning why 16 was rolled WAY more often that it statistically should. I went back to the raw data and realized that this was because of the first set of 100. In that first set, "16" was rolled 70% more often than average. If I eliminated that first set, the next four sets were statistically "equal" to rolling three dice. It was an outlier. In that first set we won the lottery; although actually, it had an even better chance of happening than someone winning the lottery. But I'm a stickler; and you can't just throw numbers out because they don't fit what you expect. Besides, that first set was with a male character and the next four I ran with a female. So...I'm convinced it is an outlier, but I'm gonna run one more set with a male Dark Elf just to prove it was a fluke. .....Yeah....while not as high as the first one it was higher than all the sets with a female and actually "raised" the difference from matching a 3xd6 dice roll. So are males rolling "16" more often? Do I just pick and choose which data I like? ----I don't want to prove a point...I want to know the truth...even though I already suspect what the result will be. So I ran more sets so I would have 500 male and 500 female. 1000 rolls and the data is whatever it is.

RESULT:

• no real difference between male/female
• matches a 6-6-6 roll within reason
  
  Why does it still differ?
  
  • "0,1, and 2" are slightly affected by another function mentioned in earlier comments.
  • even practical rolls (3 physical dice) will not match theoretical random statistics "perfectly".
  • computer generated "randomness" is not "true" randomness. Though it's possible to create "essentially" true random numbers, it really wouldn't have been necessary. "Close enough" is "good enough".
  • Although "16" is rolled an unusually high amount of times, computer generated random numbers and natural variation is enough to account for the difference.
• matches the code on OpenTESArena as long as you add ArgonianAccount's correction and additions.
• Finally rolled a "0". Roll #961.

NOTES:

• "0" appears "less" often and "1" and "2", appear "more" often than normal.
• If the first set of 100 is thrown out, the %diff at "16" become "2")

Arena - 1000 rolls

Roll#.....%rolled...............%diff from 3xd6
0...........0.1.......................66
1...........1.3.......................48
2...........2.3.......................31
3...........2.5.......................14
4...........4.9.......................12
5...........6.0.......................2
6...........7.4.......................9
7...........9.6.......................0
8...........10.6.....................1
9...........11.9.....................10
10.........18.0.....................3
11.........9.1.......................5
12.........8.4.......................3
13.........5.8.......................5
14.........4.6.......................5
15.........2.7.......................8
16.........2.3.......................31

EDIT: This post is rendered moot and incorrect by the post following.

OpenTESArena's wiki at page-"Player stats" section-"Health on generation" has the following:
If Health=0 then change it so Health=1.

Earlier I created a chart that would display the outcome given the various possibilities

Actual Roll / Actual Bonus / Health(roll)+Bonus / (Health=1 if "0") / +25 | percieved roll
......0................-1....................-1.....................-1.............24.|........0
......0.................0.....................0......................1.............26.|........1
......0.................1.....................1......................1.............26.|........0
......1................-1.....................0......................1.............26.|........2
......1.................0.....................1......................1.............26.|........1
......1.................1.....................2......................2.............27.|........1

We actually rolled "0" three times and "1" three times, but after this correction it will appear as if we rolled "0" less than normal, "1" a normal amount of times, and "2" more than normal.

However, this does not match what happens when we compare a 1000 rolls in Arena to statistical probablility.

Arena - 1000 rolls

Roll#.....%rolled...............%diff from 3xd6
0...........0.1.......................66
1...........1.3.......................48
2...........2.3.......................31

Arena rolls "0" far less than normal and "1" and "2" more than normal.

This leads to the conclusion that the code at OpenTESArena would benefit from one small change. Instead of stating "If Health=0 then Health=1", it would match Arena better if it stated "If Health<1 then Health=0"

This would lead to the following change in the chart of possibilities.

Actual Roll / Actual Bonus / Health(roll)+Bonus / (Health=1 if <1) / +25 | percieved roll
......0................-1....................-1......................0.............25.|........1
......0.................0.....................0......................1.............26.|........1
......0.................1.....................1......................1.............26.|........0
......1................-1.....................0......................1.............26.|........2
......1.................0.....................1......................1.............26.|........1
......1.................1.....................2......................2.............27.|........1

Now it matches what happens in Arena. "0" is rolled far less than normal and "1" and "2" are rolled more than normal.

Hacking the System:
Main points: I found code locations along with those listed on OpenTESArena that allow me to test the starting stats in a more controlled fashion. Proving OpenTESArena is correct on that Health bonus and my last post is bunk. Just as HEALTH has a +1 if =0 bonus, it appears that all the other stats have a general +1 bonus.
----------------------------------------------

Okay, so my last post is bunk. OpenTESArena is correct for that weird HEALTH bonus if = to "0". If the Health Mod + the Health stat (before adding the 25) is equal to "0" then it adds "1". This means if you roll a "0" and your Health mod from Endurance is "-1" then the value is "-1" and it does not receive the plus "1". Because the chances of rolling a "0" AND having a health modifier of "-1" are so low, you are not likely to notice without getting into the code and controlling some of the variables.

Thus:
(decompressed code)

Class order:

Mage, Spellsword, Battlemage, Sorceror, Healer, Nightblade, Bard, Burglar, Rogue, Acrobat, Thief, Assassin, Monk, Archer, Ranger, Barbarian, Warrior, Knight

Race order:

Bretons, Redguards, Nords, Dark Elves, High Elves, Wood Elves, Khajiit, Argonians

Gender order:

Male, Female

Stat order:

STR, INT, WIL, AGI, SPD, END, PER, LUC

Hit Die for Classes:

starting at 0x42001

Code:

060C0A 0608080A 0A080C0E 080E1012 1E1412

2-digit (byte); convert Hex to Decimal; 06,0C,0A = 06,12,10; ORDER: Class.

Hit Die for Stats:

located at 0x1715D

Code:

14

2-digit (byte); convert Hex to Decimal; 14 = 20.

Health Bonus:

located at 0x1655B

Code:

19

2-digit (byte); convert Hex to Decimal; 19 = 25.

Starting Stats per Race:

starting at 0x39D63

Code:

4D 80806666 4D66664D 80806666 4D666666 4D4D6680 8066664D 4D4D8080 80666680 4D4D4D66 80666666 4D666666 66668080 804D8080 66666666 804D6666 6666664D 80806666 4D66664D 80666666 4D806666 66668080 4D664D66 66666666 66666666 664D8066 4D668066 664D6680 4D668066 66668080 4D664D66 66666666 666666

2-digit (byte); convert to Hex - gives value from 0-255; divide by 2.55 and round; 4D hex2dec=77 /2.55=30 (STR for Breton Male); ORDER: Race,Gender,Stat.
These are listed on UESP in a table as 0,+10,-10 with a formula (37 + 4d6 + racial & gender modifier). In the code the values are 4D,66(80),80 which convert to 30,40(50),50. The STAT die is d20 which is rolled as 4d5. This and the UESP code match the Codex Scientia tables starting on page 23, with a few exception. (EDIT: small correction above)

Armed with this information I can change it so all the starting stats are the same value which allows me to test the dice rolling mechanism while viewing 8 rolls at a time. I can also ensure that that the Endurance stat gives a specific Health Bonus. (This made it easier to test with a "-1" Health bonus and determine that it isn't affected by that formula; (If Health=0, then Health=1). This means if the Health bonus is "+1" it will appear as if you never roll a "0" and if the Health bonus is "-1" it will appear as if you never roll a "1" and be tremendously difficult to roll a "0".

Health Dice -vs- Stat Dice:
Health Dice have been shown that you can roll a 0. But because of the way it switches to multiple dice for D# over "8", d6 and d8 will roll 0-5 and 0-8 respectively; while d10 through d30 will roll 0-10 and 0-30. The higher d-rolls have 1 extra "side". A d6 is a 6-sided die with values (0-5). A d10 on the other hand is an 11-sided die with values (0-10).

Stat Dice appear to use the same mechanism for rolling. It includes the same break between d8 and d10 and rolls multiple dice for the upper values. It also appears to add "+1" to the value. A d6 will give you rolls between (1-6). This appears normal until you test d10 which will give you rolls between (1-11). It appears to me that this is the same mechanism as Health Dice where d6 is 6-sided, but d10 is 11-sided, but (+1) is added to the final result. ...I have not yet found the code that makes this difference.

Health=1 if Health=0:

located at 0x1655B(0x17196)

Code:

01

2-digit (byte); convert Hex to Decimal; 01 = 1.
This is the location that adds "+1" if your roll plus your Endurance Health bonus is equal to 0. (EDIT: corrected address)

I still can't figure out why the Stat dice roll is different than the Health dice roll. Finding a simple hex "01" that is added to the dice roll would account for the difference, but I can't find one that does that. It's like trying to find a needle in a hex stack. I don't know how to test the program like a debugger where you can watch the memory and operate one instruction at a time to see what is happening. I'm literally just looking for "01" and then changing it to "06" and seeing what happens. I found the above Health modifier while looking for my hypothesized Stat modifier.

I can prove it's different - I just can't show "why" it's different. If anyone can has any ideas...that would be great. I've about exhausted my current abilities.

I've just been using DOSBox debug builds to step through the game, but it can be a little fiddly. Whenever I want to find some value in memory, I have to create a dump file containing the whole memory and search through that, then locate that address in the debugger. And then there are segment registers to deal with as well.

I think the '0x1655B' in your last post might have been the result of a copy-paste typo. In version 1.06 (decompressed), the '1' byte appears to be at 0x17196 for health, and there's another one at 0x171C0 which I assume is for stats.

There's also an extra '0x19' value for Health Bonus at 0x16560. The first value seems to be added to your maximum health, and the second gets added to current health.

Thanks for catching that. I copied the block from my previous post but forgot to change the location info.

Thanks for the information. I'll have to take some time to do some testing. Currently I can't see what 0x171C0 is effecting. I may have changed something that is interfering with it or prevents it from causing it to show up as a change in my results.

I found another one to play with. I've changed my understanding about that "if Health=0 then Health=1" thing so many times that I'm just going to preface this by saying "I don't know"..."but it seems". It seems that I was half right. It seems that the code does this; "If Health <1 then Health =1"

If Health<1:

located at (0x17191)

Code:

01

2-digit (byte); convert Hex to Decimal; 01 = 1.
Anything less than this value will be changed to "1" (the value set at 0x17196)

At least that's what it seems to be doing under my current testing. However, it doesn't seem to go into effect if the value is negative. It's like it is saying "if Health equals a (positive) number less than 1 then...".

I've noticed some other quirks that don't match what I expect, so I need to be careful of jumping to conclusions between what "looks" to be happening, and what is "really" happening.

Visually speaking, changing the value at these locations doesn't affect the visible health or stat value shown right after character creation or at the start of the game in the dungeon. I changed these to 00,02,66 (0,2,40) and started from a clean file with only this value changed. They perhaps affect the values during later gameplay.

Testing Conditions:

• Decompressed Arena.exe (1.06)
  (You can play the decompressed file without re-compressing it. At least to the starting dungeon - without any obvious changes from the original.)
• Female, Breton, Acrobat
• Original test - only changed single byte and observed multiple stats at creation and in starting dungeon.
• Thorough testing
  
  • Stat Die = d10 (0x1715D)
  • Acrobat Class Die = d10 (array starting at (0x42001)
  • Race Stats (ST,INT,WIL, etc.) = 40 (array starting at (0x39CF3)
    
    • Exception - END = 25 (#40) to maintain Health bonus of -1
  • Health Starting value = 25 (unchanged default)

Under these conditions the results were as follows, regardless of changing either of the above listed bytes.

• Stats (excluding END) 41 through 51 (+1 through +11)
• Health (current & max) 24, 26 through 34 (+0 through +10)
  25 is missing from the list because a roll of 1 plus the Endurance bonus of -1 = 0; which causes it to be changed to 1 before adding the 25 making the final value 26
• Changing the byte at 0x17196 from 1 to 5 results in:
  
  24,26, 30 through 34 (lots of 26's; If Health roll + END bonus is <5 (excluding negatives; 0-4)...then Health=1+25)
• Changing the byte at 0x17191 from 1 to 50 results in:
  
  24, 26 through 34, 75 (If Health roll + END bonus is <1 (excluding negatives; 0)...then Health=50+25

NOTE: Because a d10 uses 2d5, there is less than 3% chance to roll the lowest or highest value. You may have to re-roll many times to see these values.

EDIT: Information on this post is invalid - The odd results were cause by a bug in the way I was creating my character. The next post corrects the information.

I've been testing the Health gain when you gain a lvl of experience. So far it seems similar to the roll for stats. However, testing this takes much longer and I've not yet come across any odd sided dice. (For stats rolls using greater than d8 you get one additional side. ex: d10 gives 11 possible results.) So far a d6 results in 1-6 and a d10 results in 1-10. If your Health is 25 and you are a mage with a d6 and a +1 Health bonus from Endurance; at lvl 2 your Health will be Health(25) + END bonus (+1) + d6 (1-6) resulting in {27..32}.

The reason I bring this up is because those two bytes that affect the initial Health (If H = 0 then H=1), also affect what's added to health during a level up - but not in the same way. Truthfully - I'm not really sure what they are doing. During initial health roll, "0x17196" appears to be the "+1" and "0x17191" appears to be the "if<1" But changing these and testing the LVL health gain, I get weird results

Health = 26; Dx = d3; END bonus = +0
NO CHANGE to the two bytes - after lvl-up result is 27, 28 or 29
Change only (+1 byte) to 0, 2 or 8 and the result is the same; 27, 28, or 29
Change the (<1 byte) to 0 or 2 and the result is the same; however change it to 8 and the result is 27, 29-35. (values that occurred during limited testing)
Changing both bytes to 8 and I get; 27-29; and 37 (also limited testing but was heavy on the low end and not spread out like the test before.)

I really have no clue what's going on here for the lvl up with these bytes. It's possible that while it seems consistent and obvious what they do for the initial stat roll, that it's just a coincidence, and rather than values, I'm messing with the math functions. These are not values that are changed from 0x01 regardless of class, race, or gender. It would be helpful to point to them as a means of certainty in describing what is happening, but either way it doesn't change what actually occurs.

My last post isn't valid. The way I was creating my characters was activating an unusual bug.



Changing these values does NOT affect the Health increase during level-up.