[PSX/PC] Natural Max HP/MP Tool - Highwind (v1.0)

[codemann8]

I've created a program called Highwind that utilized the game's RNG and awkward probability to help assist any player reduce the number of game resets needed when aiming for natural max HP and MP.  Discussion and inception of this program originated at GameFAQs. However, due to topics getting locked after inactivity, I've decided to move discussion to this site, which seems like a suitable home for a project like this.

The code and .exe is located on GitHub. Highwind (v1.0)

Here's a chart showing some statistics on estimated resets for each character:

[b]Char[/b] | [b]Min[/b] | [b]Max[/b] | [b]SR[/b] | [b]HR[/b] | [b]Diff[/b]
Cloud | 143.66 | 852.78 | 623.23 | 512.69 | 110.54
Barret | 96.82 | 760.13 | 665.28 | 579.49 | 85.79
Tifa | 144.5 | 819.45 | 655.96 | 538.09 | 117.87
Aeris | 288.37 | 979.61 | 763.95 | 691.99 | 71.96
Red | 708.9 | 2167.33 | 1615.66 | 960.36 | 655.3
Yuffie | 153.7 | 928.57 | 747.2 | 650.19 | 97.01
Cait | 289.29 | 1910.44 | 1335.67 | 1033.6 | 302.07
Vincent | 719.61 | 1253.58 | 1180.64 | 1160.92 | 19.72
Cid | 1438.96 | 2668.25 | 2007.4 | 1589.87 | 417.53

Min - The path with the lowest amount of estimated resets
Max - The path with the highest amount of estimated resets
SR - Standard Resets - If you accept the first safe value
HR - Highwind Resets - If you only accept GREEN values
Diff - The difference between SR and HR

The overall difference adds up to over 60 hours worth of resets saved!

How do you use Highwind?

[list type=decimal]
[*]First, all that is needed is the executable (*.exe), found in /FFVIIHighwind/bin/x64/Debug/, however, this should be placed into a directory of some kind that you have 'write' permissions for, there are some cache files that are created in the same directory as the program to save yourself from constant recalculation.
Upon opening, you can click each Character to see all the paths available in the tree window.
[*]You can start by entering in your Characters' Level, HP, and MP in the boxes on the top and then hitting Set, this will refresh the tree to that node and will show you the possible values you can get during the next Level Up. Hitting Clear will reset that Character and the tree will show Lv 1.
[*]The tree will show you the Level of the Character, followed by the HP and MP value, followed by the chance of hitting that value, followed by two estimated amount of game resets required (the first one if you follow Highwind's advice, the second one if you don't). For example, one node in the tree may say: Lv 83 (7307 / 814) 4.3% chance [541.92 - 850.46 resets].
[*]The "safe" values are color coded (Green to indicate a good value, Yellow to indicate a not-good but not the worst value, Red to indicate a bad value). Basically, if it's green definitely accept the value, if it's red definitely reject the value, if it's yellow you can consider accepting it ONLY if you've reset less times than the indicated amount, but it's recommended to reject all yellows as well, but you can see the estimated resets that will result.
[*]When you've decided to accept the value the game gave you, select that node and hit Set, this will re-structure the tree and display it accordingly.
[*]Optionally, you can hit Simulate after selecting any value in the tree and it will simulate 10k times, comparing "smart" vs "normal" strategies. Smart strategy is only accepting green and optional yellow values, normal strategy is accepting ANY safe value.
[/list]
Future updates:
Ability to track each character's EXP and always know which character will level up next, this was something I solved by using a spreadsheet I made.  I plan to combine this spreadsheet with Highwind.  I discuss this more in detail here.

I'm sure this OP will be updated as I make changes along the way.

 

[codemann8]

How does this work?

Well, in reading the Party Mechanics Guide by Terence, on GameFAQs, you will find that the game increases HP and MP during each level up but there is a specific calculation that occurs.  First, it is noted that there is a random element to the generated outcome.  A random value 1 thru 8 is generated (for both HP and MP, but separately) and it is used in determining the outcome.  Also, it is noted there that there is a "curve" system in the calculation so you are penalized later if you increase your HP or MP too fast and too early.  It was because of this "curve" system that it was determined that there is a certain level for each character in which it was possible to NOT achieve the max HP or MP, this was referred to as the Safety Level.  From that point on, you must consult the Safe Value Chart in order to verify whether your HP and MP values are safe.  Then, later on, it was determined that during the 1-8 random number generation for both HP and MP, it is NOT possible for an 8 and 8 to result, meaning that you CANNOT max both HP and MP during the same level-up.  Because of this, AbsoluteSteve included a new Safe Value Chart in his Walkthrough Guide that combines both HP and MP values that are safe, since both HP and MP cannot be maxed independently.

So I came along and asked the question why an 8-8 scenario is impossible.  I found out it was due to the way the game generates the random numbers for these stat upgrades.  Apparently, there is a lookup table built into the game with 256 pre-defined values.  A random number from 0 to 255 is then generated and it uses that to pick out a value from that lookup table and that number is used to calculate the 1 thru 8 value for each HP and MP, and no value in that lookup table generates a 8-8 case.  In fact, neither does a 4-6 or 6-4 case.  More over, it was found that the resulting outcomes are very oddly scattered and have ranging probabilities.  Some cases hit 1/256 times, some cases hit 9/256 times.  Here is the chart indicating the disparity of the chances of hitting:

 |  |  |  |  |  | [b]MP[/b]
 |  | [b]1[/b] | [b]2[/b] | [b]3[/b] | [b]4[/b] | [b]5[/b] | [b]6[/b] | [b]7[/b] | [b]8[/b] | [b]Tot[/b]
 | [b]1[/b] | 2 | 4 | 5 | 8 | 1 | 7 | 5 | 1 | 33
 | [b]2[/b] | 2 | 3 | 6 | 5 | 2 | 8 | 2 | 4 | 32
 | [b]3[/b] | 6 | 3 | 2 | 2 | 4 | 4 | 2 | 8 | 31
[b]HP[/b] | [b]4[/b] | 9 | 6 | 2 | 4 | 1 | 0 | 6 | 4 | 32
 | [b]5[/b] | 3 | 6 | 2 | 3 | 6 | 2 | 5 | 5 | 32
 | [b]6[/b] | 3 | 3 | 5 | 0 | 7 | 4 | 2 | 8 | 32
 | [b]7[/b] | 4 | 3 | 4 | 7 | 3 | 5 | 4 | 2 | 32
 | [b]8[/b] | 3 | 4 | 6 | 2 | 8 | 2 | 7 | 0 | 32
 | [b]Tot[/b] | 32 | 32 | 32 | 31 | 32 | 32 | 33 | 32 | 256

You will find it interesting also that if you look at the column and row totals, they are almost all exactly 32/256 chance, giving each independently the feeling that they are an even 1/8 chance.  However, the combination of the two are horribly uneven.  Once I found out about this uneven distribution, I realized that there must be a way to utilize these probabilities to your advantage, reducing the amount of resets needed to achieve the max stats.  In my practice up to that point, I was finding myself struggling with Aeris on one level, I must've reset the console over 100 times.  I ended up going back to an earlier save and getting a different value, and I was able to continue with about 20 resets instead.  I later found out the scenario I was up against was a 2/256 chance the first time but 7/256 chance the second time after going down a better path.

The 2 things I needed to solve was:

[list type=decimal]
[*]How do I accurately calculate the estimated number of resets required for each character?
[*]How do I figure out how to improve that?
[/list]
The answer to those questions are surprisingly simple and very hard to poke holes at.

At first, I was relying on running simulations.  I'd run 10,000 simulations of leveling up each level and comparing the resulting HP and MP to the Safe Value Chart, if it's not safe, try again, if it is safe, continue to the next level.  I'd keep track of the total resets and at the end of the simulations I'd average it out.  This was the first metric I was using to determine good vs bad paths.  Two problems ensued, one, simulating takes a long time (about a minute) and must be done individually on each possible safe value (the whole safe value chart would take hours if not days to complete) and two, simulating could only simulate whether a value is safe or not, there was no good logic that I could use to tell it to reject a value.

I later found out that if you were to start at the bottom (Level 99) and work your way towards the beginning, adding up the resets thru each level.  Assuming the max HP and MP at Level 99, there is only one possible value for Level 99.  That value itself would of course be 0 resets because you're already there.  From there you move to the previous level and find it's "parents".  In this case, every character only has one Level 98 value as well, you'll also find that the value you need is a 8-7 case, which means the HP value and the second highest MP value.  Looking that up in the chart, the odds of hitting that is 7/256.  Doing a little bit of math, you can find the number of resets needed:

Code: [Select]

probability = 7;resets = (256 / probability) - 1;

In this case the estimated resets is 35.57 resets.  Why subtract 1 from the equation?  Because a 256/256 chance should equal 0, also, we're counting resets, not trials.

Next we move to Level 97, and the levels after that, always looping thru all the safe values for that level and calculating the estimated resets and adding to the previous resets from the higher level.  There will eventually be scenarios where there are multiple safe values as you move up this safe value tree. In this scenario, each combination should have an estimated reset count on them.  The math should be the same except the the probability of hitting ANY of those values is simply by summing each of the possible probabilities.  Now, each of the safe values may all have different estimated resets, so which of them should be used to add to the resets for the parent?  The answer is all of them, in fact, it's a weighted average based on the different probabilities of each value.  After repeating this calculation up all the levels till you get to Level 1 (or Level 6 for Cloud), you will get your estimated resets, running a simulation at any level can confirm those numbers.

That's a long-winded way of explaining my simple answer to question 1 above, but more simply it's working backwards adding up the weighted averages of resets at each level.

So, how to improve on this?

After all, the goal is to BEAT that number.  The goal is to mathematically put you in better position and probability to achieve the max stats.  The answer on how to solve this is also simple.  If you have 7 possible safe values, if you remove 1 of them, does the weighted average lower the estimated resets, or increase it?  Keep in mind, when you remove a value, the chances of getting a safe value, of course, will reduce your probability of getting a safe value, but it's possible that the extra resets on this level might be worth it if it means saving you resets further down the road.  In Highwind, values that cost you more resets are notated in RED, these should always be passed on, if a value costs you more resets but regarded as a lateral move (no gain), the value will be notated as YELLOW, meaning you could (although not recommended) accept the value, but know that it may cost you more down the road, the simulations can prove that.  Also, YELLOW values should definitely be treated as RED values if you've already reset more times than the number indicated for that value when you hover your mouse over it.  Lastly, values that are always good are notated as GREEN.  Each value, in Highwind, will show you two reset values, the first value is if you follow GREEN values only, the second is if you accept ANY value.  The overall calculated results are shown above in the previous post.

If anyone has any questions about the math or anything else, please ask away.

 

[codemann8]

I've made a change to the logic behind what constitutes a RED vs YELLOW value.  Previously I had an arbitrary threshold of 3 resets to indicate that YELLOWs are not as bad because it only costs you less than 3 resets more.  I've changed the logic to something that's a bit more "smart" than a simple fixed 3 reset threshold.  If a given level is estimated to cost 18 resets and you happen to get a YELLOW value on your first try, it's possible that it wouldn't be a terrible idea to accept that value considering you're looking at roughly 18 more resets to get your GREEN value.  When you hover over any YELLOW value, it will indicate the number of resets you should NOT exceed if you want to accept the value.  That is, if you've reset more times than the amount indicated, definitely DO NOT accept the value, treat it as RED.  I will still ALWAYS recommend only accepting GREEN values.  Simulating the new smarter YELLOW logic still results in more resets (although only just a small handful more) than if you stick with GREEN, although it is much better than accepting YELLOW values from the previous YELLOW logic.