Joined: 3/18/2006
Posts: 971
Location: Great Britain
Thanks FatRatKnight for your PM. Your advice was extremely useful.
I think I have some more information.
I'm not sure if this is complete, but I seem to have found something substantial perhaps.
My theory
Address 2E38 changes value from 0 through to 7 every 4 frames. This means 2E38 can be 8 values. There are also 8 addresses preceding this address which I believed were somehow the RNG. Coincidence? I think not!
I think 2E38 arrives at a number and that number corresponds to one of the preceding addresses. The game then checks this address for a 'critical hit value' and if all is well then it equals a critical hit.
So far it makes sense!
addresses
2e35 = 2
2e36 = 3
2e37 = 4
2e30 = 5
2e31 = 6
2e32 = 7
2e33 = 0
2e34 = 1
2E38 = randomises 0 through 7 [in other words, it's going to randomly pick one of the above addresses and check to see what value it has. It may have a value for critical/miss/x amount of hp]
If address 2E38 value is 7 then it means the game will check the value in address 2e32. If 2e32 has a critical hit value, then there will be one...
critical hit values, so far:
1,184, 230=(81hp)
7=(80hp)
15,41=(77hp)
129,163=(78hp)
227=(79hp)
250=(82hp)
hp refers to the amount of damage the critical inflicts
When I plug these values into my theory they become true.
The evidence seems to suggest this is true. But I'm not 101% sure :p
There is also another part of the RNG which I have not put into my theory yet... but that's only one address and 1 byte. Maybe I can find a role for that later.
It works so far, in the sense that I can predict when a critical hit will happen without having to try manually on every frame.
Or maybe I'm completely wrong :)
I need to make some sort of script to automate the critical hit prediction. It still takes a while to look at the RAM and decide when the next critical hit is possible...
It works so far, in the sense that I can predict when a critical hit will happen without having to try manually on every frame
(95% of the time, very rarely it fails, no doubt it's the other 1 byte addresses messing with something)
Does this make sense? Perhaps someone with experience of RNGs in games can say if this is plausible or not?
What you've shown makes sense, as far as it goes. Disassembly might still be useful here; even if you don't trouble yourself with the opcodes, you can still breakpoint those 1-byte addresses and learn about other addresses used in the same functions (and which thus influence or are influenced by the mysterious RNG bytes.) Figuring out what those addresses are for then gives you a broader picture of what's going on.
I don't recommend doing that, though- if your disassembly is generally reliable at this point, then going ahead with the TAS seems best. You probably wouldn't want to spend another weekend decoding that last 5%, only to find that the algorithm drastically changes later on, or doesn't work with Deathblow, etc.
antd wrote:
Thanks FatRatKing for your PM. Your advice was extremely useful.
Surprised by this, I am not. :)
Also, FatRatKnight, I want to apologize for volunteering your assistance without your knowledge, or permission. That was a bit thoughtless on my part. :/
Argh, I should have seen this earlier. Yes, FF7 uses tables rather than a PRNG as such. In fact, I think the tables are saved in the save files. If not, they're in kernel.bin.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Yes, I still need to read up on opcodes and such. I think I could learn a lot about the games mechanics.
LagDotCom wrote:
Argh, I should have seen this earlier. Yes, FF7 uses tables rather than a PRNG as such. In fact, I think the tables are saved in the save files. If not, they're in kernel.bin.
How can I access them/it? I know you can access the PC version kernel.bin, but maybe it isn't exactly the same as PSX...
Thanks FatRatKing for your PM. Your advice was extremely useful.
I was expecting "helpful" or "fairly decent" or even a "pretty good", but if you did find it to be "extremely useful", then I have explained it a lot better than I thought I did. You made progress, in any case, so whatever the case, the RNG is much closer to being cracked. ... Hopefully.
Dromiceius wrote:
Also, FatRatKnight, I want to apologize for volunteering your assistance without your knowledge, or permission. That was a bit thoughtless on my part. :/
Actually, I now realize I'm not being asked to work out the whole thing alongside everyone here (I think)... I'm just being asked for advice. In any case, I accept your apology and throw in a "don't worry about it" for good measure.
I didn't think I'd be famous enough to get a request already... I'll stick around in case further help from me is desired.
I looked up the Battle Mechanics FAQ at GameFAQs in order to get a somewhat better feel around here. I'm not sure how helpful it will be, but at least I know something about how damage is calculated.
I'm fairly certain that the PSX and PC kernel.bin files are identical. If you want to do some prodding in the game files, take a look at the documents on qhimm.
Terence's mechanics FAQs are amazing for FF7, so yeah I'd advise those.
Critical hit = your luck - target luck = %chance to critical, IIRC. Nothing fancy.
I think it's best referred to as an algorithm. We want the code, not just the logic.
Anyway, how's it going, antd? If you're still trying to get inside kernel.bin you might try Daemon-tools. Though, unless I'm very much mistaken, all you'll find in there is a less intelligible version of what the debugger gives you.
I need to make some sort of script to automate the critical hit prediction. It still takes a while to look at the RAM and decide when the next critical hit is possible...
when 2E38 or 2E32 are generated? Sometime these RNG aren't generated in same time than you confirm your action... you might need a similar program like memory watch that would tell what are the foward value for the next bunch of frame, for better confort while TASing.
Would it be possible to get a program going like the one used for dragon warrior which told what would happened on every frame if you attacked then, so you could just go down the list and pick the optimal frames to attack on?
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
does PCSX support lua ? If not it might be a good idea to try to implement that. It would be easier to make some custom scripts.
Unfortunately, mz already said he's not doing that a page or two ago. I don't blame him, since that would probably be a lot harder than it seems for an emulator as complicated as PCSX.
He was right about hacking a bot into the emulator, though- it's shouldn't be that difficult for any competent C coder... provided you can actually compile and run the emulator on your platform.
Nudge-nudge wink-wink. :p
But I wouldn't call myself competent with C and with emulator in general.
Sorry to hear that... but maybe I can entice you anyway?
Or somebody?
I may have been overstating when I said "competent". Really, you probably wouldn't need more than a passing familiarity with C, especially if you're already a pro with C# or some other language.
By the looks of it, you'd need some memory addresses (which Antd probably has already) and a handful of emulator functions in order to carry out some naive bruteforcing, which is surely good enough for the purposes of TASing. mz posted an example earlier that had some of the functions one would need.
Assuming the "doframeadvance" and "dosendkey" functions exist in some reasonable form, it wouldn't be much more complicated than using Lua:
const int MAXENEMIES = I dunno... twelve?;
int enemystarthp[MAXENEMIES];
if(key = DOBRUTEFORCEKEY)
{
for(int attempts = 0; attempts < 8; ++attempts)
{
bool IHITAGUY = false;
for(int i = 0; i < 4*attempts; ++i)
doframeadvance();
//We did the manipulation (by waiting) so send the command to attack
dosendkey(CONFIRM_BUTTON);
//read all the enemy HP values
for(int i = 0; i < MAXENEMIES; ++i)
enemystarthp[i] = psxMs8(ENEMYHPADDR*(HPOFFSET*i));
//check enemy HP every frame; wait for an enemy to get hit
int frameswaited = 0;
while(!IHITAGUY) {
doframeadvance();
if(frameswaited++ > idunno500maybe?) break; //in case we miss
for(int i = 0; i < MAXENEMIES; ++i) {
if(enemystarthp[i] > psxMs8(ENEMYHPADDR*(HPOFFSET*i))) {
IHITAGUY = true;
break;
}
}
}
}
}
Of course, there'd have to be some more logic for things I didn't account for, like enemy HP being set to 0xFFFFFF on death, or whatever. Also, for the function to be useful, you'd need to track the greatest difference between initial and final enemy HP values, and finish the function by advancing the appropriate number of frames and sending the confirm key one more time. Setting the speedmode would be smart, too.
Also, 8 attempts (8*4 frames = 1/2 second) is a conservative amount of time to wait to manipulate a critical, compared to AxeMan's FF1 run DQ, etc.
Edit: Also, that code above is probably full of ridiculous mistakes.
Still, this seems pretty doable.
I don't have a lot of time on my hand. But I will try if I can find the time, to take a look at this. If the function DoFrameAdvance, DoSendKey, SaveState, LoadState are done (I could probably modify some code to make them work) then I could made some automatic function to bruteforce the combat.
And I don't want to create much hope with this, because I have very little time (and very little motivation). But I'd like to give back to this community.
Anyway I'll see by the weekend if I can make something out of this.
In the meanwhile, if someone can point me out what I would need to edit the Source Code.
Which IDE or compiler should I use for this ? I'd prefer tools on Windows 7, but I can use Ubuntu if it's only available on Ubuntu (I really prefer Windows 7, the setup is better for programming).
Which IDE or compiler should I use for this ? I'd prefer tools on Windows 7, but I can use Ubuntu if it's only available on Ubuntu (I really prefer Windows 7, the setup is better for programming).
Ach, I wish it compiled under Linux, or I'd have done this myself.
Much thanks for making the attempt, ZeXr0.
The project builds under the GNU toolchain rather than MSVC. You'll need to install MinGW. Judging from the Makefile, it's expecting GCC in the 3.X.X range, which I believe comes with the installer.
The installer should also provide you with an x-terminal. Hopefully, running make in the term will build cleanly.
You can compile PCSX and any of its plugins using GCC v4.x.x or v3.x.x, and MSVC 2005 or newer. You should use the source code from the SVN, since it has some changes by adelikat and others that make it much easier and faster to compile.
It should compile for Linux with some minor changes, since the -RR changes are very few and PCSX was originally working on Linux too.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Ah. You're right. I just assumed from the makefile that Linux support was kaput, since it assumes win32. I'm up to linker errors now. Doesn't look like this will take too long.
I see... There's a separate makefile for Linux. Built it, but it's not finding any plugins yet. I'll have to fix that later and then try botting.
While you guys are talking about working the crit formula, which I wont pretend to understand, I'm curious as to the actual route plan of the run itself.
I believe it is possible to skip Cosmo Canyon altogether, although it might cause problems further into the game. This also has a two-fold problem - less exp from Gi Nattak (which can fall easily to either a Phoenix Down or an Elixir), and the inability to learn Death Sentence before Disc 2, which is mainly a concern for Tifa's Powersoul (gives x4 damage in Death Sentence status) before the Curse Ring is obtained. You also miss out on Gravity materia iirc, which is only useful in a couple of places (the Icicles you have to fight are weak to Gravity, as is Rapps if you do the Wutai subquest). Speaking of Gravity, Barrett's Mindblow only works on stuff that is weak to Gravity, which means the majority of bosses will only lose MP naturally or to Magic Hammer.
I'm not expecting to have too much given away, although I am curious about the possible route plan itself.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
The route will be the same as the Speed Run guide. Unless new things are found.
I have some questions regarding the beginning of the game.
Should I manipulate a potion drop after the first battle?
How far should I go to manipulate level-up stats / Max HP? (you can see that manipulating stats costs time)
Level-up Stats4 frames slower / original stats / 8 frames slower
I think it's worth losing 4 frames in order to get the better stats (str and luck in particular). There are other possible stat combinations. You can get different stats by delaying the final attack of the battle +4 frames
I showed the +8 frame stats just to show how they can differ
It is definitely worth waiting the extra 4 frames to manipulate the additional Strength and Luck. The additional Strength may be required to reduce the number of attacks by 1 later in the run on a different enemy, and the Luck makes getting crits easier, since as mentioned, the crit % chance is determined by the difference between your own Luck and the enemy's Luck.
It would be worth testing later battles to see what sort of required stats you may need for eliminating a turn or attack, and rather than manipulating for highest value it would be easier on you to aim for that slightly lower minimal threshold instead. This of course may require more luck manipulation in the long run.
4 frames slower / original stats / 8 frames slower
I think it's worth losing 4 frames in order to get the better stats (str and luck in particular). There are other possible stat combinations. You can get different stats by delaying the final attack of the battle +4 frames
I showed the +8 frame stats just to show how they can differ
