This is a split board - You can return to the Split List for other boards.
You're browsing the GameFAQs Message Boards as a guest. Sign Up for free (or Log In if you already have an account) to be able to post messages, change how messages are displayed, and view media in posts.
I committed some changes that now can Simulate a given player going for Max HP/MP 10000 times. There are two routines for this, the default (SimulateMaxSafeOnly) is where you keep trying until you get the first safe value, the other (SimulateMaxBetterSafe) is a set of rules determining when you should attempt to pick another value even when it is safe. The second routine is something I may look to get a little help with if someone is willing to dive in. I'm using Vincent as my example since he has the smallest/fastest tree, the SimulateMaxSafeOnly routine seems to average around 1180 resets. And no matter what logic I put into SimulateMaxBetterSafe, the result stays around 1180. It's possible that the underlying MinPath and MaxPath heuristics I used aren't as useful as I thought, and might need adjusting. The main problem is that the min and max pathing only considers one path and it doesn't consider that there are multiple combinations that are very similar at each level, so the estimated resets are much higher than reality.
The reason I dove into this endeavor was because I was working on Cid (around Lv50) when I reset my game probably 50 times, after a bit of math, I found out that only one combination of HP/MP would be safe. After getting frustrated, I went back to an earlier save, tried getting a different safe value for the previous level for Cid, and it turned out it was for the better, cause instead of trying to get one combination the first time, there were instead four combinations now, and I proceeded to get a safe value pretty quickly. After Erzfreund posted his table I was able to work out the actual probability I was looking at, turned out that the first run I was looking at a 2/256 chance while after going down a different path it was a 33/256 chance. This is what led me down this road, I feel like there has to be something to it.
FYI, I did fix the min/max heuristic to be very much more accurate, I was looking at the whole thing backwards, now it simply takes the probability of hitting any safe value, not just the probability of hitting the one value. The Min and Max for Vincent is now 719 - 1253 resets which is right on the money, 1180 resets was the average during simulation.
However, I could still use some help coming up with a good heuristic to determine when you should re-attempt a level. I think it's quite easy, as a human, to see when it's smart to do so, but I'd like to find a calculation that can help prove out its usefulness.
Cool stuff and thanks for making it open source.
WingedMasamune showed his progress with Aeris in this thread. How did he do in comparison?
For Aeris, her estimated probable restarts range from 288-980 and the average in actual practice is 761 resets. WingedMasamune had a pretty good run with 594 resets.
(edited 1 month ago)
Sorry for the long delay, I haven't had a lot of free time lately, plus I'm simultaneously working on a perfect game file as well and damn Cid took 145 resets on a 2/256 chance for one level, ugh, only 45 more levels to go...
However, I didn't want this topic to get archived just yet so I thought I'd bump it. Eventually once this thing is proved out a bit and after I combine it with the functionality I that's available in that spreadsheet I made (the one that helps gamers track all their characters' EXP growth, I'll create a new topic for it, but I'll continue to use this one as discussion. I have though, definitely made a lot of improvements to the tool, it runs a heck of a lot faster:
1) If you load a character, it stays in memory so if you switch to another character and come back, it's already there.
2) The first time you run the program, the initial tree building takes a little bit of time, a minute or two, but once the tree files (*.hpmp) are generated, the program uses those files instead which is super fast.
3) I combined the 2 simulation sequences so you can see the two simulation results side-by-side; although the 2nd one (the "smart" one) still needs some thought put into it (I'll get to that later), the 1st is the default (basically simulating what everyone does today, keep trying until you get a safe value)
4) A status bar on the bottom to indicate when the program is "thinking", so you know it's actually doing something
5) Memory, when you exit the program and reopen, it will remember all your characters' levels/values that were set.
A pre-built *.exe is included in the project for people who want to just run the tool, the rest of the code is also available:
Also, I figured I'd drop a few data points I've found during the course of this project; filesize of the *.hpmp files that are generated (in KB, indicating the size of the trees), the minimum, maximum, and likely probable resets. The likely probable resets was from running normal simulations and averaging the number of resets. Notice the filesizes compared to the probable resets, it seems the larger the tree, the lower amount of resets, the smaller the tree, the bigger amount of resets. This is likely because smaller trees mean fewer options, less likelihood of hitting a safe value (not always true of course). Sorry about the dashes, that seems to be the only way for it to align the text column properly on GameFAQs:
As for the "smart" simulation logic mentioned earlier, this is the key to finding better paths to take, the Simulate button is really just a debug feature that if someone or I finds the right set of logic to calculate this, then that can later be incorporated to a part of the standard program, alerting the user when it's smart to roll the dice instead. The main problem I'm having is that this cannot be solved be a simple min/max path calculation, because it's multi-dimensional. Currently, it's a single dimensional calculation, simply using probable resets as the one dimension. Not only should we be concerned with the minimum and and maximum probable resets, but also the probabilities of both of them AND everything in between. If anyone has any ideas on solving that portion, it would greatly help, and I would definitely give credit where it is due. Cheers, community.
Ok, a little update on this tool. I added a little feature that really helps out a lot. If you select a node on the tree and click Simulate, it will Simulate the number of resets it will take to get the max from THAT point in the tree to the end and it will add that number to the text on the nodes of the tree. This helps when determining whether to pass on a safe node, it's the best metric to use to date. If one node is 40 resets less than the one you got and has a 3.51% chance of hitting (about 27 resets), it's likely better to attempt to hit that value instead. Things get interesting when multiple nodes have better simulated resets, you can combine the probability and factor that into your decision. If it's only better by a few resets, I usually don't bother, nor do I ever do lateral moves (trading for a node that gets 20 less resets but will likely take 20 resets to get there).
Eventually, I'd like to find a way to 'calculate' the simulated resets rather than actually simulating it ad hoc. Once I find that calculation, it should be easy to incorporate it into a better min/max algorithm that can actually tell the user statistics on their value (and inform them whether to roll the dice again or not, and give them a sense of how valuable it is). Currently, it's too exhaustive to simulate every node 10000x and perform a min/max on it, but you can at least see the default simulation (as if you were simply looking at the standard safe value chart and resetting only based on that) and base your decision on that.
I can already tell how useful this is so far. On Red XIII, I've already saved myself hundreds of resets over the course of just 3 level ups. Of course, you can't tell that from the safe value charts by default. But I'm beginning to see why this helps a lot. On Vincent, for instance, it seems that because of the path I've taken for him, I'm set up way better to achieve it faster. I'm seeing that I'm down to having to hit exactly one HP and exactly one MP value, when the safe value chart shows a little more than just one value, which in itself sounds bad, but using this tool, it seems to utilize the "curve system" to its advantage. I'm at a point in my path where no matter what, I'm guaranteed the same MP value for the 1-8 random choice (because the calculation caps the amount of gain if you're too far away from your base amount for that level). So basically I'm left to a 1 out of 7 or 8 chance for the HP, which is better than the standard 2.78% 8-7 scenario. Eventually, Vincent's chances will start approaching that 2.78% near the end, but you get to enjoy the benefit of better odds until then. I highly suspect Red XIII will show the same strategy. Other characters, like Tifa and Cait Sith, enjoy the benefit of having the ability of hitting 2 MP values for a good number of levels.
I can't wait to present my actual numbers at the end. I currently have Cloud and Aeris at Lv76, they are both locked in my party (before TOTA) but I plan to continue on once I max Lv99 for Aeris as I want to start collecting other new materia. I've mastered 2 copies of all the materia I've gathered already, along with 20x mastered All's.
I guess it was only a matter of time before someone made an app to make the grind more efficient.
Great work, hope you can finish it sometime soon.
the brave do not fear the grave
@__digitek__ Keep an eye on this next few days. I've found the secret sauce I was looking for. I found a way to save yourself over 300 resets mathematically for Red XIII alone! But I feel there's a little more that can be squeezed out of it yet. There's still a little bit more to put together before I push the update. Also, I've renamed the program to Highwind. It seems it's somewhat tradition to name these things after things in the game instead of something functional.
Add user to Ignore List after reporting