Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
if lolo26 is right, and the run will be 7+ hours, it would probably be preferable to use absolutely everything at our disposal to get the time down. That is just a long, long time to be watching, and the only hope to have people be interested enough to watch the whole tas would be to get the time as low as possible.
Joined: 4/2/2008
Posts: 103
Location: The Netherlands
Twelvepack wrote:
That is just a long, long time to be watching, and the only hope to have people be interested enough to watch the whole tas would be to get the time as low as possible.
I don't think that necessarily holds for a run that long. One thing that really helps is audio commentary, as illustrated by SDA. But other than that I'd say the only way to keep the viewer's full attention (except over a span of many days) would be to beat each boss in a new, interesting way.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
I am now thinking of occasionally using Cait Sith's Slots.
Some situations may arise that require too much luck manipulation. In such a situation it may be impossible (not impossible, but will take too long to be feasible) to follow the optimal strategy. I will probably use slots in these cases.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
mz wrote:
Also, GarlandTheGreat's run is pretty useless... He writes values to RAM whenever he feels like.
I guess I'm just not very updated, but I didn't know this. How did he do that? That's a little sad, I thought his movies were pretty good. So they're basically done by writing stuff to RAM to get good luck and such?
How did he do that? That's a little sad, I thought his movies were pretty good. So they're basically done by writing stuff to RAM to get good luck and such?
Here's what he says on the description of the first segment of his "Near-Perfect Speed Run":
This is a demonstration of how fast Final Fantasy VII can be beaten legitimately. I'm playing this on an emulator and I play on 1/s speed, use save states (and cheats in rare cases) for maximum luck manipulation, but everything I do can be done in the regular version.
What's even funnier is that he originally called this a "Tool-Assisted Speed Run", and he used cheats because he thought we normally use cheats to produce these movies...
As far as I know, he only uses cheats to get high luck, but I've only watched the first few segments.
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.
Joined: 4/2/2008
Posts: 103
Location: The Netherlands
As far as I know he only did it during the guard scorpion battle.. it would have been better if he hadn't, but since he isn't playing in frame advance anyway it's not like he'll effect the RNG anymore than it's already being effected by 'sloppy' play.. so it doesn't bother me much. However, it's great to see a proper TAS of this, and it's looking great so far (glitches didn't bother me at all)
I'm just wondering what graphics Plugin is best for Final fantasy 7.
Unfortunately, it doesn't appear I have a good enough one, because the In Battle Status Screen and stuff doesn't show up for the characters at the bottom, it's just a big black blank space.
First someone needs to submit a run, then it needs to be good enough to be published, and then maybe a decision on that will be made.
Not a bad question, but considering this thread has been dead for some time, I'm not holding my breath for a run being produced. It certainly wouldn't be a very fun one to TAS, I'd think.
GarlandG's run may have battle strats somewhat unnecessary for a TAS but I wouldn't go slating a run and guide that set a benchmark for running the game under sub-10 for PSx. Some things worth noting though that could be taken advantage of in a TAS that he couldn't in his completed and test runs:
-Critical hits at max possible chance (saves having to buy grenades and sidetrack en route throughout the early part of the game).
-The lift in the ShinRa building can be used to avoid any fights on the way up (incredibly low proabability of getting all the safe flaws, but then this could be luck manipulated).
-As seen in the WIP most of the encounters can be removed bar some that would get you to a lowest level required to fight some of the bosses.
-in Gold Saucer GP boosting can be done by luck manipulating the 3D Boxing game in (is it Wonder Square?) should you need some of the items obtained by exchanging points.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Hmm, I have time to work on this now. However, I need your help.
I'm wondering how to find the relevant RAM addresses for critical hits.
I have a test battle where I've marked down which frames are criticals, misses etc. So I can use that battle for RAM comparing etc. since I know when each type of attack is available.
I now have time to work on my FF7 run. It would save time if I could devise some sort of formula to calculate when a critical hit is possible.
In battles there are 4 frames which constitute an attack type.
For example:
attack on frames: 1-4 = critical hit
attack on frames: 5-8 = miss
attack on frames: 9-13 = normal attack (40HP)
I also know that the pattern repeats itself after 65536 frames. So, we know that frames 1-4 are critical hits. 65536+1 = 65537
Frames 65537-65540 will be critical. The pattern repeats like this.
The only problem is, I don't know when a critical hit will happen. In battles, I will have to keep trying each 4frame set to see if there will be a critical hit. This takes a long time, and I think it's possible to defeat this problem with RAM watching + some sort of formula.
Can anyone help to devise a way so that I can know when each critical hit is available?
I think something like this has been done with past FF games on SNES...
I would like to know how it is done.
Glad to hear you've been working on this, antd. I hope I can provide some answers.
antd wrote:
The only problem is, I don't know when a critical hit will happen. In battles, I will have to keep trying each 4frame set to see if there will be a critical hit. This takes a long time, and I think it's possible to defeat this problem with RAM watching + some sort of formula.
You're correct that you need both a RAM address and a formula. From what you've reported, the RAM address (the RNG- random number generator) in this game is 2 bytes, and advances every four frames. If the RAM tools allow it, you'll want to search for values "not equal to previous" every four frames until you see some address (or possibly a set of addresses, but let's hope not) whose value changes to another random number every fourth frame. With a little luck, that's the RNG you're looking for.
Now you need the formula. There are a few ways to get this. The way I'd do it to run the game in a debugger, setting a breakpoint on the enemy HP being written, and backtracing up to the point where the damage/critical-ness is determined.
There is another method, but I've only heard about it from FatRatKnight. IIRC, he uses trial and error (i.e., statistics) to infer the critical hit formula. I could venture a guess at how he does that, but you'd probably want to ask FatRatKnight himself.
If you need clarification on any of the above, go ahead and ask.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Dromiceius wrote:
With a little luck, that's the RNG you're looking for.
I have 2 addresses.
I have a 4byte value and a 2byte value which seems to greatly influence criticals and misses. (100% criticals so far). Is it safe to assume this is the right address?
When I freeze them at the values for 'miss' (when I miss an attack). It seems to guarantee a miss. At least I had 50 misses in a row and I used turbo mode to randomise the frame of attack... I have to freeze them both, so it seems they share a relationship. If I freeze one value only, then some attacks won't miss/critical.
Miss and critical are governed by the same addresses, so when I said 'miss' in this post you could substitute it for 'critical'. I do have the separate values required for critical and miss.
Sorry if it's confusing.
Seems to be what I'm looking for?
I don't have any experience with debugging, I may need some additional help =p But I'll see how I get on.. oh, and thanks for your help so far.
http://doc.kodewerx.org/tools.html#psx
This website recommends PCSX with debugger over pSX emulator. I'll try PCSX w/debugger first.
setting a breakpoint on the enemy HP being written, and backtracing up to the point where the damage/critical-ness is determined.
Do you mean that I should find the address for the enemies health? And set a write breakpoint on that?
I'm using MHS by L.Sprio for RAM hacking. It also features a debugger, so I would to use that.
I'm not sure of what do about breakpoints and 'backtracking'
If you could give me some idea of what to do :p
Do you mean that I should find the address for the enemies health? And set a write breakpoint on that?
It depends on the capability of the debugger. If there's a "backtrace" button, then yes; breaking on the enemy HP being written to, and getting a backtrace at the instant when it changes will narrow down the relevant code to a few functions, one of which will have the formula we're looking for. If not, it gets hairy. You'll need, first, to find the frame on which the HP is written, and then find the RNG read that immediately preceeds the HP write. It'll be there that the criticalness and damage are determined. The problem is, the RNG might be read and written a dozen times before the execution passes through the crit formula.
A problem is that the addresses I've found are not the same address with other programs. I think it has something to do with the offset.
Basically, PCSX-debugger uses different addresses, in the format of 800xxxxx
In my memory hacking program the address is 00BF8634.
Can I convert it or find a way to know what the address is in PCSX-debugger, or even pSX emulator for that matter..?
Yes, but read on.
another thread wrote:
Sometimes when I close and re-open PCSX emulator all my addresses in MHS will have changed...
This is because PCSX's RAM chunk is "dynamically allocated". What you need to do is find the "static pointer" to the 0th byte of the RAM. Whereas dynamic memory will be different every time you run the program, the static pointer will point to the dynamic memory.
There's a special checkbox that searches for "static pointers only" or something, and the range would be set thusly:
from: 0xBF0834-10000
to: 0xBF0834
...So that the static pointer to the 0th address would be listed among a (hopefully very small) set of found addresses.
I think there's actually a tutorial in the help files that explains how to do this in more detail.
Once you know the 0th byte, you should be able to calculate the in-emulator address of the enemy HP by subtracting the MHS RAM base address from the MHS Enemy HP address. The calculation will look something like this:
0xBF0834 - 0xBF0000 = 0x834
In which case, the emulator address would probably be 0x80000834
Eh... hopefully some of that made sense. This is getting rather complicated, so I wouldn't blame you if you wanted to give up and just luck manipulate by hand, at least for the time being. :/
Edit: also, regarding using MHS' debugger, I think even L. Spiro advised against using it for emulator debugging, somewhere on his forums. It would complicate the disassembly a whole lot, adding emulator stuff like input handling, GUI, threading, and whatever else. It would also give you the PSX assembly after it had been converted to PC assembly, which I think would be much harder to read.
You'd be much better off in the long run using a native debugger.
Edit2: The PSX processor uses a "reduced instruction set", which can apparently be described in a few pages, unlike x86 assembly. I'm adding this because that link is going to be handy later.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Ok, this is PCSX debugger window. It is not the same version which has frame advance and re-recording options. I'm not entirely sure what to do here..
[URL=http://i187.photobucket.com/albums/x268/antdgar/debugger_pcsx.jpg][/URL]
you may want to click on the picture to view in full size :p
I believe the enemy health address is at 800F8614. I put that under 'Set Breakpoints' on the bottom right. I'm not sure what 'Reg' should be set to...?
I guess MemWrite is setting a breakpoint when the address is written to...
Once I press Run, it brings me back to this screen. And the address 800B007C is selected and shown in various boxes. I guess the enemies HP is being written on every frame by 800B007C?
I'm not entirely sure what's going on here. Some reading up on the subject should be helpful. Are there any general things I should be doing?
Oh, I'm not going to give up until I've tried everything. I really dislike manipulating critical hit luck manually... =D
edit: if you have some spare time, im in irc, maybe it's easier to discuss there.
I believe the enemy health address is at 800F8614. I put that under 'Set Breakpoints' on the bottom right. I'm not sure what 'Reg' should be set to...?
Leaving it unset seems the sensible thing to do there. I believe 'Reg' refers to 'register', which is like a memory address located inside the CPU. All the data being processed has to go through one of the 32 registers.
Once I press Run, it brings me back to this screen. And the address 800B007C is selected and shown in various boxes. I guess the enemies HP is being written on every frame by 800B007C?
To be clear, you need to set the breakpoint during battle, preferably immediately before Cloud's sword hits an enemy and the numbers appear. If you set it while the ROM is booting up, you'll get false positives as the PSX does some stuff we don't care about.
800B007C is the "execution pointer". It's the address in the ROM where the code currently being executed is. In this case, "ADDU" is the opcode being executed, and s1, r0, and r0 are the operands being read or written. The CODE column, incidentally, is just the DISASM column rendered in hexadecimal. It's not important.
I notice that s7 holds the address used in the breakpoint. It also happens to be used as an operand in the op that preceeds the one hilighted in the screenshot: 800b0078 SW v1, 0000(s7)
It might load the value held by the address in s7 into register v1. You're going to need to learn the MIPS architecture to decipher this.
If you press Run repeatedly and the execution only advances a single frame each time, that would suggest you may have the wrong address. If there's a way to lock/poke it, you should verify that it is what you think it is. It's also probable that the enemy HP would be loaded into one of the registers as you step through the execution upon hitting the breakpoint.
I'm not entirely sure what's going on here. Some reading up on the subject should be helpful. Are there any general things I should be doing?
One thing that's probably not immediately obvious is that all functions exist to operate upon certain memory addresses. Knowing what those addresses are and what they do in the game is crucial to understanding why a function exists, and how it fits in the program as a whole. In other words, a big part of this task will likely involve watching memory addresses to see what they're for.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Hmm, I see. This seems way over my head. I'm seeing most of this for the first time, and it doesn't seem easy :p
There is another method, but I've only heard about it from FatRatKnight. IIRC, he uses trial and error (i.e., statistics) to infer the critical hit formula. I could venture a guess at how he does that, but you'd probably want to ask FatRatKnight himself.
I have just private messaged him, hopefully he can get back to me about that. What would be your guess?
I'm eager to make some progress on the run tonight, as I only have the weekends free>.<
Hmm, I see. This seems way over my head. I'm seeing most of this for the first time, and it doesn't seem easy :p
The hard part is getting your head around it. After that, it's actually pretty simple. But yeah, it's more than a weekend endeavor.
I have just private messaged him, hopefully he can get back to me about that. What would be your guess?
He is a genius, but I hadn't counted on the RNG being so complicated. 40 bits to be reckoned with, apparently. That seems like a lot. I'm not really sure how the time spent decoding the RNG would compare to manipulating the old fashioned way, even over the course of the entire run.
It's too bad my computer fails at PSX emulation, or I'd have figured this out myself by now. If PCSX had Lua support, I could feasibly write a script to find criticals by brute force... Now that I think about it, there IS another option. LSS: L. Spiro Script. It's a scripting language inside MHS. I can't just wink an LSS script into existence and send it to you as I could with Lua, but it's worth a shot if FatRatKnight can't offer any better ideas.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
40 bits to be reckoned with, apparently. That seems like a lot.
after more research it seems that there is more =x
the entire string consists of 9 1byte values next to each other and 1 2byte in another location.
I found this because 1 out of 1000 attacks (literally 1 out of 1000>.<) were not getting critical.
I looked at the address range and saw other aligned addresses that are also to do with the RNG (maybe). After freezing those values too, I found that I could get critical on the (1/1000) frames where I was missing before... Maybe it isn't as complicated as first thought. As freezing 1 value increases the chance of getting critical, freezing more values seems to make the chance even greater still... I don't know what this means though.
I'm not really sure how the time spent decoding the RNG would compare to manipulating the old fashioned way, even over the course of the entire run.
ok, then I may as well start the traditional way. Although it is a demotivational tool :)
LSS: L. Spiro Script. It's a scripting language inside MHS. I can't just wink an LSS script into existence and send it to you as I could with Lua, but it's worth a shot if FatRatKnight can't offer any better ideas.
are you saying you would write an LSS script for me ;)
mz, if you are watching, LUA support please ;))
Sure... I'd love to, but I don't have the necessary motivation (and knowledge) to do such huge amount of work. :P
You can always add some simple modifications to the emulator, if brute-forcing is all you need... I did something like that for my Puzzle Bobble 3 TAS:
(Just an example to show how simple C can be: here I use the Lag Counter to show me what is the first frame where I can shoot a bubble. :P)
As a side note, I'm going to make a TAS of the FFVII demo that came with Tobal No. 1; just for fun. I already did a short TAS test of FFVIII a while back, and I think both games use a very similar random battle mechanism...
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.
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Oh, FFVII demo is nice. I remember that encounters are so frequent.
So then I can only hope that you create a critical hit brute forcer thing for the demo that can be nicely ported to the full version :P
Somehow, I'm mentioned in this topic. Then I spotted something about a private message, and lo and behold, there it is.
I'm not sure how helpful I will be using an emulator I'm unfamiliar with to work on a game I merely have passing knowledge about, in an attempt to decode the critical hit formula which only has two results (crit or not crit), which uses a rather sizable list of numbers to determine which result. I could forgo the emulation completely, and never gain any familiarity with the game, and still attempt to crack through it from everyone's data collection here.
This definitely does not sound easy. I have a record of analyzing some deepgamemechanics without knowing what the code is, so I think asking for my help isn't entirely worthless, in spite of my unfamiliarity of the situation.
I suppose the first thing I should ask is to be pointed to the recommended tools, and instructions on how to use said tools. The next thing is to ask about what is known now, though I could just read through the thread for that. I'll probably need a few weeks to get myself fully started with my own tests, but if you still haven't figured much more by then, then I can be of help.
On the other hand, after I read through this thread, I could try to point out what to do next in an attempt to figure it out the darned RNG. Sure, I'd depend entirely on everyone else to get the exacting data I want, but I don't exactly need all the set-up time to just talk about it. The "first thing I should ask" up there, forget it!
Hmm... Weeks of set-up and dealing with other stuff in life in the meantime, or a bit of reading now and jump straight into the logic, skipping all the story, wandering, and so forth. I don't exactly want to try to track down the FFVII ISO and read up on how to use a new emulator's features, so I'll attempt to inject my skills while scarcely even knowing this game. If that fails, we didn't lose much in the attempt.
But first, reading. If I come up with something, I'll state my thoughts.
[/URL]
you may want to click on the picture to view in full size :p
I believe the enemy health address is at 800F8614. I put that under 'Set Breakpoints' on the bottom right. I'm not sure what 'Reg' should be set to...?
I guess MemWrite is setting a breakpoint when the address is written to...
Once I press Run, it brings me back to this screen. And the address 800B007C is selected and shown in various boxes. I guess the enemies HP is being written on every frame by 800B007C?
I'm not entirely sure what's going on here. Some reading up on the subject should be helpful. Are there any general things I should be doing?
Oh, I'm not going to give up until I've tried everything. I really dislike manipulating critical hit luck manually... =D
edit: if you have some spare time, im in irc, maybe it's easier to discuss there.
