since the subject has been resurected : has anyone tried the run while leveling up in mount ordeals (when Cecil becomes a paladin)? His white magic affinity skyrockets higher than anyone in the game, making it easy to damage undeads (don't forget his sword). A lamia (weak to fire) - 2 skeletons combo gives over 800 exp for a party of 4
I have trouble believing that grinding for Cecil would be advantageous. The existing run is basically a low-level run except that it raises Rosa's level high enough to get Wall so Zeromus can be killed with reflected Nukes (and it does that grinding in a single fight!). The other boss fights don't seem to suffer for having underleveled characters, in part thanks to guest party members (c.f. Tellah, FuSoYa), but mostly because all-out offensives are much more viable when luck-manipulation means you don't have to worry about healing.
For normal games, I'm given to understand that Cecil can level very effectively on Mount Ordeals if you want to, but I've personally never really felt the need.
cecil's leveling influences others' leveling afterwards. you can easily have a walled rosa when you get her
You're still trading one fight's worth of grinding D. Machines with Life abuse vs. many fights of grinding Cecil without access to high-value targets or ways to quickly kill entire encounters (since presumably the twins are KO'd to get Cecil more experience). D. Machines give 41500 experience, and it all goes to Rosa. You need multiple D. Machine kills to get Rosa to a sufficient level to learn Wall. That's a lot of Ordeals fights.
I don't have a good feel for the numbers involved here. Presumably you can save some time on the intervening boss fights thanks to having higher-leveled characters, but how much? I bet even one Ordeals fight takes long enough to easily wipe out the gains from one boss fight going faster.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Pasky, Deign put in some mem adresses in the submission text. Try those, (I do not remeber what is there.) Or ask deign, maybe he knows.
Thanks, I just checked though, http://tasvideos.org/2033S.html
He mentions nothing on the character timers or monster timers. I believe deign has also been MIA for a while, so no good in trying to contact him =/. Still having trouble locating this.
7E1845 - Apparently a timer for battle. Watch this carefully.
7E2A07 - Another timer? I'm guessing it's for one of your own characters.
7E2A70 - Yet another timer? Same here.
I spent a little time (less than an hour) looking into this game after reading the discussion here. All I knew was that timers were involved, and likely ticks if the game isn't paused. Mainly running the published TAS while taking a look, and I'm pretty sure the timers won't tick whenever that TAS pauses the game.
I hope this is a good point to continue your searches with.
EDIT: Some more information...
7E2A07 - Player 1 Timer
7E2A1C - Player 2 Timer
7E2A31 - Player 3 Timer
7E2A46 - Player 4 Timer
7E2A5B - Player 5 Timer
7E2A70 - Enemy 1 Timer
7E2A85 - Enemy 2 Timer
7E2A9A - Enemy 3 Timer
7E2AAF - Enemy 4 Timer
7E2AC4 - Enemy 5 Timer
7E2AD9 - Enemy 6 Timer
Basically, these are 0x15 apart. Feel free to investigate these.
7E1845 - Apparently a timer for battle. Watch this carefully.
7E2A07 - Another timer? I'm guessing it's for one of your own characters.
7E2A70 - Yet another timer? Same here.
I spent a little time (less than an hour) looking into this game after reading the discussion here. All I knew was that timers were involved, and likely ticks if the game isn't paused. Mainly running the published TAS while taking a look, and I'm pretty sure the timers won't tick whenever that TAS pauses the game.
I hope this is a good point to continue your searches with.
EDIT: Some more information...
7E2A07 - Player 1 Timer
7E2A1C - Player 2 Timer
7E2A31 - Player 3 Timer
7E2A46 - Player 4 Timer
7E2A5B - Player 5 Timer
7E2A70 - Enemy 1 Timer
7E2A85 - Enemy 2 Timer
7E2A9A - Enemy 3 Timer
7E2AAF - Enemy 4 Timer
7E2AC4 - Enemy 5 Timer
7E2AD9 - Enemy 6 Timer
Basically, these are 0x15 apart. Feel free to investigate these.
Yup, I found these slightly before you did ^_^ thanks to looking at the GBA version of the game which used the same system.
The ATB for chars and monsters counts down from a number generated from their agility. Apparently monsters can get different values during the fight something to do with a lookup table and their agility modifier. Players seem to have some randomness applied only at the beginning of the battle, then it seems to be fixed, but not absolutely sure.
Link to video
So I have the ATB bars working (implemented poorly in lua, but it does the job). Now I wanna work on getting a random encounter step display to show how many more steps until an encounter. Anyone have any information on how it works? I know the step counter is at:
0x7E0686
but not sure what it is compared against. There seems to be another address that gets incremented as well and I think it has something to do with the random encounter formula also:
0x7E0688
But I'm unsure, my knowledge with the CPU instruction set of the SNES is limited. Hopefully someone else already knows how it works, I couldn't find any documents on it at gamefaqs in the algorithm FAQ or at romhacking.net.
Thanks for all the help.
Well, I reversed the random encounter address....at least I know what triggers it anyways.
7E0686 is incremented every step you take. It basically becomes the offset for a pointer to a table of values that the encounter code compares against.
008951: BNE 00895c ($9)
00895C: LDA $1700
00895F: CMP #$00
008961: BNE 00899d ($3a)
008963: LDA $1707 // Load 7E1707 into the accumulator
008966: LSRA // Shift the byte right 2 times
008967: LSRA
008968: AND #$f8 // And it against 0xF8
00896A: STA $06 // Store the result in 0x7E0606
00896C: LDA $1706 // Load 0x7E1706 into the accumulator
00896F: LSRA // Shift the byte right 5 times
008970: LSRA
008971: LSRA
008972: LSRA
008973: LSRA
008974: CLC // Clear the carry flag
008975: ADC $06 // Add the value at 0x70606 to the accumulator
008977: TAX // Copy the value of the accumulator into register X
008978: LDA $0ec300,X // Load 0x0EC300 + Register X into the accumulator
00897C: STA $06 // Store the result into 0x7E0606
00897E: PHX // Push Index Register X
00897F: PLY // Pull Index Register Y
008980: LDA $c0 // This loads 7E06C0 into the accumulator, to zero out the accumulator
008982: BNE 008994 ($10)
008984: LDA $86 // Load 7E0686 into the accumulator
008986: TAX // Copy the accumulators value into X
008987: LDA $14ee00,X // Load 0x14EE00 + X into the accumulator
00898B: CLC // Clear the carry flag
00898C: ADC $17ef // Add the value at 0x7E17EF to the accumulator, this seems to only change on a reset
00898F: CMP $06 // Compare the accumulator's value against 0x7E0606, if 0x7E0606 is greater than the accumulator, don't set the carry flag
008991: BCC 008994 ($1) // Branch on carry, if this does not branch, an encounter occurs
I've only tested on the earth world map. Well, that's what I've found so far.
EDIT:
Successfully reproduced this in Lua and made a step counter for the random encounter.
EDIT:
Just noticed that the step counter would incorrectly display the steps if the value at 0x7E0686 rolled over (i.e. FE -> FF -> 00). I figured out why, because when this rolls over, the value at 0x7E17EF increases by 0x11, so the step counter gets recalculated.
Link to video
Just figured out how enemy groups get calculated and made a script to show the next encounter group. Only bad part is, I have to manually add the names for each group value v_v, oh well I don't mind. I got plenty of time and in no rush.
Anyways, here is how they are calculated for the world map.
Here is the actual code for the monster groups, it's actually a part of the encounter subroutine. I'm too lazy to explain everything this time. Just know that 0x7E1800 is where the result of the monster group gets stored (at 008A16: STA $1800)
Dungeons seem to use a different subroutine because no breakpoints were being set inside that part of the code when I went to one. I'll have to see how those work some other time.
I haven't fixed the encounter script yet, so if it rolls over it will just recalculate so I put the step counter next to the 'steps left' so I'll know when it's going to roll over and the 'steps left' will recalculate.
Link to video[/video]
Do you plan to increase the current run? it is definetly improvable and I would love to see it improved with all the things you are doing!
Probably not. I refuse to use the 'Pause Glitch'. I think it retracts from the entertainment value of the run having that stupid "PAUSE" box in the middle of battles and any run submitted without it would probably be rejected.
Vykan12 wrote:
Wow, that is a seriously impressive script you're working on, Pasky13! What's motivated you to tackle this challenge out of the blue?
I just love FFIV. I usually target a game from now and then that I want to see how it works (usually games I grew up playing). This just happens to be the current one.
Time/SpaceMage wrote:
If there's CPU info you want, that's easy enough to search for...
Here's a resource over at ol' Zophar's...
After checking on a couple of things this evening, the game seems to have 4 different routines for random encounters and what enemy group you get. 0x7E1700 holds a value that goes from 00-03.
008951: BNE 00895c ($9)
00895C: LDA $1700
00895F: CMP #$00
008961: BNE 00899d ($3a)
008963: LDA $1707 // Load 7E1707 into the accumulator
008966: LSRA // Shift the byte right 2 times
008967: LSRA
008968: AND #$f8 // And it against 0xF8
00896A: STA $06 // Store the result in 0x7E0606
00896C: LDA $1706 // Load 0x7E1706 into the accumulator
00896F: LSRA // Shift the byte right 5 times
008970: LSRA
008971: LSRA
008972: LSRA
008973: LSRA
008974: CLC // Clear the carry flag
008975: ADC $06 // Add the value at 0x70606 to the accumulator
008977: TAX // Copy the value of the accumulator into register X
008978: LDA $0ec300,X // Load 0x0EC300 + Register X into the accumulator
00897C: STA $06 // Store the result into 0x7E0606
00897E: PHX // Push Index Register X
00897F: PLY // Pull Index Register Y
008980: LDA $c0 // This loads 7E06C0 into the accumulator, to zero out the accumulator
008982: BNE 008994 ($10)
008984: LDA $86 // Load 7E0686 into the accumulator
008986: TAX // Copy the accumulators value into X
008987: LDA $14ee00,X // Load 0x14EE00 + X into the accumulator
00898B: CLC // Clear the carry flag
00898C: ADC $17ef // Add the value at 0x7E17EF to the accumulator, this seems to only change on a reset
00898F: CMP $06 // Compare the accumulator's value against 0x7E0606, if 0x7E0606 is greater than the accumulator, don't set the carry flag
008991: BCC 008994 ($1) // Branch on carry, if this does not branch, an encounter occurs
Underground:
0089A5: LDA $86 ; Encounter formula begins here
0089A7: TAX
0089A8: LDA $14ee00,X
0089AC: CLC
0089AD: ADC $17ef
0089B0: CMP $0ec340
0089B4: BCC 0089b7 ($1) ; Triggers battle if branch not taken
The moon Random Battle formula seems to be the exact same formula as the underworld formula since 0x0EC340 and 0x0EC341 contain the same value of 0x08. I assume it uses a different routine because the way it loads the enemies different, since it's all in the same routine.
Moon world map:
0089DC: LDA $86 ; Encounter formula begins here
0089DE: TAX
0089DF: LDA $14ee00,X
0089E3: CLC
0089E4: ADC $17ef
0089E7: CMP $0ec341
0089EB: BCC 0089ee ($1) ; Triggers battle if branch not taken
Dungeons: (And anywhere else that isn't the world map that can encounter enemies randomly)
I'm not sure if this was known, but I know for sure people knew about the tiles in castles that would increment the step counter for random battles. Well there is another room that does this, inside the underground dungeon for the crystal where kain betrays the party.
Here is an example of what I mean:
Link to video
Also found a strange anomaly with the random battle formula. I'm unsure what causes this at all, and it only seems to happen sometimes and only at this Y on the earth world map (that I've discovered anyways, there may be more of these on other maps) position.
If you move to the left, you get a different amount of steps until an encounter, if you keep going right the encounter will occur. But if you move to the left and and increment enough steps that the counter that was on the right will pass, it will continue with the left side's counter instead. It doesn't always happen either, I displayed this by walking left and then right after the first encounter in the video. I'm not sure what causes it, but it's no error on my script because both counters will trigger the encounter if you stick with it.
Example:
Link to video
Not sure if this would help a TAS, but I thought it was worth mentioning.[/video]
Clearly, for that encounter increment anomaly, there's an encounter at step 0xEB shared by both areas. It's just that one part doesn't have it at 0xD9 while another part does, and by walking around the area that won't encounter it, you skip the 0xD9 encounter and continue on to the 0xEB encounter, where both regions will encounter something (and neither region has encounters in 0xDA to 0xEA).
Similar concept with the no encounter zones that still increment on steps.
Clearly, for that encounter increment anomaly, there's an encounter at step 0xEB shared by both areas. It's just that one part doesn't have it at 0xD9 while another part does, and by walking around the area that won't encounter it, you skip the 0xD9 encounter and continue on to the 0xEB encounter, where both regions will encounter something (and neither region has encounters in 0xDA to 0xEA).
Similar concept with the no encounter zones that still increment on steps.
Finished all the areas for the random battles and enemy grouping, and fixed my script to correctly display remaining steps until an encounter when the step counter rolls over. I set it to display the next 5 encounters. It's possible to predict the enemy groups indefinitely.
Link to video
With this it's possible to add to the script a way to determine how many encounters until you reach one you want (i.e. how many more to encounter a pink puff etc...) since the enemy you get is determined by the encounter number.
Anyways, that's the progress so far, I'm gonna work on getting some in battle items going next I think.
Thanks to bond617's GFAQ text file (http://www.gamefaqs.com/snes/522596-final-fantasy-ii/faqs/53579) I was able to just parse his text file and get all enemy names for the encounter group.
Joined: 5/13/2009
Posts: 700
Location: suffern, ny
well for one thing, Pasky found a glitch using the step counter to avoid battles, this will save many frames as Deign gets into some battles. Not sure this works everywhere, but it may help in some places. Deign also listed some improvements in the submission text.
[19:16] <scrimpy> silly portuguese
[19:16] <scrimpy> it's like spanish, only less cool
It's technically not a glitch! Just an exploit of the map design. There's no glitch, merely the sidestepping of an encounter trigger by being in a low-encounter zone.
Perhaps reveal the encounter rate of the area one is in? Another improvement would be to use input.get() trickery to allow the script to change its display on the fly based on the user's desire. Such as changing the opacity of the display, for one thing.
Joined: 7/17/2004
Posts: 985
Location: The FLOATING CASTLE
Cutting battles is a good thing to look at. I did some similar optimizations in Final Fantasy 1 where it is even more critical because some fights can't be run from.
There I used FFHackster to get maps of where all the no-encounter spaces were. I was actually able to make a hacked rom where no-encounter spaces were marked. So I recommend doing something similar to find all the possible places that may be useful. In some cases it was worth it to go quite a bit out of the way to avoid encounters.
The other thing was to make a script that figured out where I would have battles the entire run. It might not be such a big deal for this game because you can save and load without items. But if you could do some prediction you may find some cases where taking extra steps in one area prevents encounters in other areas. Or even better, you can change your path to step over more or fewer no-encounter squares to tweak things. It takes some work but it could lead to a nice improvement.
I've decided to focus my attention on Mother 3, so I don't think I'll have time to complete this script. I've somewhat lost interest in this after playing the PSP remake which is great!
I'll post the Lua script I made when I get home, I'm in class right now....Please keep in mind I'm no expert in lua, so my functions may be unorganized or unoptimized...but they do their job :).
Here is the Lua script I made that shows the ATB for players/monsters, random encounter steps, and next encounter groups. Like I said, it isn't the prettiest or well optimized code, but it did what I wanted.
http://pastebin.com/sbfm9yfKhttp://www.multiupload.com/A4EQBBCV5R
