Topic: How to do Step Mine for 0 MP

[mblock129]

This invloves exploiting 2 bugs and can only be done in a few select places but it is possible.

The 2 bugs:

1. In a timed area (like the escape from the Floating Continent), Step Mine's MP cost is calculated from the time remaining (MM:SS) not the total time elapsed in your game (HH:MM). Step Mine costs 1 MP for every 30 seconds left. So if you've only got 29 seconds left until the Floating Continent explodes, Step Mine is free.

2. Step Mine's MP cost is not calculated from the actual time. It is calculated from the time when you last went to the subscreen (by pushing X). On a side note the damage is calculated from the actual step count. You don't need to exit to the subscreen to refresh this.

So, wait until there are 29 seconds left on the Floating Continent (or the collapsing house in Tzen), go to the subscreen, then get in a fight. You got yourself a free Step Mine.

Here's a picture:
http://zephyr129.brinkster.net/stepmine.html

Another thing you can do is charge up your Step Mine for a big battle, but don't go to the subscreen. You get the increased damage without the increased MP cost.

[Lenophis]

Would it be possible to manipulate the timer in a way of checking the menu early, doing a timed event (such as the fall of the FC), then load the menu afterwards and have a really low time at the start of the WoR? This sounds like it would be possible, but either way it's worth investigating.

[assassin]

very nice.  i linked to this thread on Mnrogar's forums, in case there are people who read those but not these.

#2 kind of reminds me of this bug (however unrelated):

http://mnrogar.slickproductions.org/phpBB3/viewtopic.php?f=2&t=108&p=2188&hilit=leafer#p2188

(the post is an elaboration and explanation of the "Monsters in the wrong area" from the Bugs Guide.)

out of curiosity, will the time be updated by entering+exiting battle or boarding+unboarding the airship, or by only visiting the menu?  while the bugs are quite different, i figured i'd pursue the parallel.

a fix for #2 would involve reading the timer variables directly.  however, a difficulty is that one time variable might change in between reading the variables.  for example, let's say we're at 5 hours 59 minutes, and fractions of a second away from 6 hours even.  a "fix" function might read the hours as 5, and by the time it reads the minutes a few milliseconds later, they're rolled over to 0; so you'll get a bogus reading.  i'll assume whatever saves the timer variables when you visit the subscreen momentarily freezes them first.  if not, that's a rarely-occurring bug in the making.  if so, it's worth mimicking if anybody ever tries to make a patch for this Step Mine issue.

do any of you Bank C3 explorers (Lenophis, Imzogelmo, etc.) know anything about freezing the timers?

[assassin]

hmm, i should note that the screenshot isn't showing up.  Brinkster doesn't like the direct linking (unless it's to HTML files and maybe TXT ones) or embedding.  best just present URLs as plain text in the future, so people can copy+paste them.  btw, how much did the personal domain cost you?  glad to see you join the ranks of Brinksterites.  Brinksteronians?  Brinksterese?  :)

[mblock129]

@ Lenophis
I see what you're suggesting but the FC would be very impractical. You would have to get from the end of the FC to picking up Strago/Gogo in the WoR without checking the menu. That means no equips for Celes. But I did try hacking the events so you start on the Solitary Island with Strago in your party and I was able to go out and fight some battles. Step Mine was indeed 0 MP.

Another thing worth trying would be to delay picking up Sabin in the WoR, and use that timed event instead. You could probably pull a free Step Mine on Kefka that way. Unless the part where you choose your fighters for the final battle updates the clock...

@ Assassin
Brinkstars, Brinkstoners...

Fighting and winning battles doesn't refresh the clock. Neither does loading a new map, staying at an inn, buying/selling, changing parties in the Airship, having that guy remove everyone's equips, riding a Chocobo,  finding the Floating Continent, or participating in an auction. Cart saves and tents can't be tested because you must check the menu.

[Imzogelmo]

The game time is calculated from the frame count, which every bank updates via NMI. 60 frames => 1 second, 60 seconds => 1 minute, etc. This is an interesting bug, as it implies that the Step Mine calculation is looking at the display variables, which are copies, instead of the original game time, and that the copies are only updated by visiting the menu (which makes sense). Awesome find, mblock!

As for a fix: Assassin, your idea about a possible bug arising from a brief carry-in when reading the variables is plausible. One question though, Wouldn't it be best just to make a single read of the minutes variable? There shouldn't be any reason to look at any smaller increment.The frames, seconds, minutes, and hours are stored consecutively, so a single 16-bit word could be read (for hours and minutes), and then divided as needed.

Just my initial thoughts.

[Lenophis]

Ok, more like thread necromancy. Whatever. mblock, is this your discovery?

do any of you Bank C3 explorers (Lenophis, Imzogelmo, etc.) know anything about freezing the timers?

I don't know about freezing, but I do know that all menu-related stuff in C3 has one NMI routine. That routine will update the game time:

Code: [Select]

C3/13C8: AD1E02  LDA $021E    (Load frame count)
C3/13CB: C93C    CMP #$3C     (Is it 60?)
C3/13CD: F002    BEQ $13D1    (If so, branch to below "carry out" into seconds)
C3/13CF: 802B    BRA $13FC    (Otherwise, branch directly to overflow checks)
C3/13D1: 9C1E02  STZ $021E    (Set frames to 0)
C3/13D4: AD1D02  LDA $021D    (Load seconds)
C3/13D7: C93B    CMP #$3B     (Is it 59?)
C3/13D9: F005    BEQ $13E0    (If so, branch to below "carry out" into minutes)
C3/13DB: EE1D02  INC $021D    (Increment seconds)
C3/13DE: 801C    BRA $13FC    (Branch to overflow checks)
C3/13E0: 9C1D02  STZ $021D    (Set seconds to 0)
C3/13E3: AD1C02  LDA $021C    (Load minutes)
C3/13E6: C93B    CMP #$3B     (Is it 59?)
C3/13E8: F005    BEQ $13EF    (If so, branch to below "carry out" into hours)
C3/13EA: EE1C02  INC $021C    (Increment minutes)
C3/13ED: 800D    BRA $13FC    (Branch to overflow checks)
C3/13EF: 9C1C02  STZ $021C    (Set minutes to 0)
C3/13F2: AD1B02  LDA $021B    (Load hours)
C3/13F5: C963    CMP #$63     (Is it 99?)
C3/13F7: F003    BEQ $13FC    (If so, branch to overflow checks)
C3/13F9: EE1B02  INC $021B    (Increment hours)
C3/13FC: AD1B02  LDA $021B    (Load hours)
C3/13FF: C963    CMP #$63     (Is it 99 now?)
C3/1401: D00A    BNE $140D    (If not, branch to frame increment; hours haven't overflowed)
C3/1403: AD1C02  LDA $021C    (Otherwise, check minutes)
C3/1406: C93B    CMP #$3B     (Is it 59?)
C3/1408: D003    BNE $140D    (If not, branch to frame increment; minutes haven't overflowed)
C3/140A: 9C1D02  STZ $021D    (Set seconds to 0)
C3/140D: EE1E02  INC $021E    (Increment frames)
C3/1410: 7B      TDC
C3/1411: 6B      RTL
I have a feeling there might be a third bug at work here. Testing this will be a pain in the ass though, because of what's involved. I'm thinking it may be possible to taint the actual game-time with the timer if you never enter the menu until you're almost out of time in a countdown scenario. I have a feeling this isn't a clearly explained description, my apologies. I will elaborate further if needed.

[assassin]

to be sure, the NMI routine itself can't be interrupted, right?

[Lenophis]

I'd think no, unless IRQ could, but all IRQ does in C3 is jump to an RTI.

[assassin]

ah, thanks.  that code excerpt reminds me: are you guys tackling the "Monster Encounter Randomosity" bug in Pandora's Box?

it's discussed here:

http://www14.brinkster.com/assassin17/guides.htm

(if you find that confusing, lemme know and i can paste a shorter tentative description ZED and i came up with over AIM years ago, as well as the GameFAQs topic i started on the bug.)

fixing the bug should be as simple as:
1) adding a new byte variable that is incremented in function C3/13C8: a 0-255 frame counter.
2) having C2/23ED use the new variable instead of $021E, and no longer multiply it by 4.

my hesitation in doing it is mainly because i wasn't sure which free RAM byte to use (particularly if i want the patch to hold up on FF6j, and FF3us 1.1).  Imzogelmo emailed me a list of unused RAM bytes awhile back, but i don't remember much.

[Lenophis]

that code excerpt reminds me: are you guys tackling the "Monster Encounter Randomosity" bug in Pandora's Box?

I think we did without ever directly touching it. See, we completely trashed the old RNG and replaced it with something even better than my RNG patch. However, I guess we need to test it to be sure.

However, in the event that my word is not enough, I'll address each point:

fixing the bug should be as simple as:
1) adding a new byte variable that is incremented in function C3/13C8: a 0-255 frame counter.

We've already added the 0-255 frame counter. Question, why would C3/13C8 need to be changed for this?

2) having C2/23ED use the new variable instead of $021E, and no longer multiply it by 4.

The new RNG renders $BE effectively useless, and it also renders $1F6D useless as well. But like I said, I guess it would need some extensive testing.

[assassin]

ah, i forgot all about you overhauling the RNG(s).

However, in the event that my word is not enough,

you lying dog!  *narrows eyes*

We've already added the 0-255 frame counter. Question, why would C3/13C8 need to be changed for this?

because C3/13C8 is responsible for incrementing the 1-60 frame counter, and the 0-255 frame counter would be incrementing at the same regularity as that frame counter.  (except it'd have a wider range, obviously.)  so it makes sense to harness the original incrementing function since you can rely on its timing.  did you find a better place to do it?

    2) having C2/23ED use the new variable instead of $021E, and no longer multiply it by 4.

The new RNG renders $BE effectively useless, and it also renders $1F6D useless as well. But like I said, I guess it would need some extensive testing.

ok.  maybe you already threw out the *4 as a result of the overhaul, but if not, you should probably chuck it.  i say "probably" because i dunno how many entries are in your new RNG table.  if there are still 256, you want to chuck it, because the multiplication will effectively cause you to skip 3/4 of the entries in the table, which is bad.  if there are 1024 or more, then i suppose the *4 is harmless.

[Lenophis]

ah, i forgot all about you overhauling the RNG(s).

Indeed, we were using my Holy Randomness patch until recently. We've actually gone through eight or nine revivions of RNGs... Either because of bad seeds, bad results, characters dancing, whatever. You name it, it's happened.

because C3/13C8 is responsible for incrementing the 1-60 frame counter, and the 0-255 frame counter would be incrementing at the same regularity as that frame counter.  (except it'd have a wider range, obviously.)  so it makes sense to harness the original incrementing function since you can rely on its timing.  did you find a better place to do it?

No, we actually made a mess of hooks. Originally I wasn't sure if C3/13C8 was continuously being called or not. Looking through all of the disassemblies, it is not. In fact, I only see the one call in C3's NMI routine. I've always been concerned about how fast this RNG is, and it's fairly fast now. Certainly much faster than the current Holy Randomness patch.

ok.  maybe you already threw out the *4 as a result of the overhaul, but if not, you should probably chuck it.

I believe we never touched that part of the battle init code at C2/23ED. The new RNG is ignoring $BE's and $1F6D's input entirely, and is going on its own function. Although in older incarnations of the RNG, the multiplication may have lead to the problems we kept running into.

i say "probably" because i dunno how many entries are in your new RNG table.  if there are still 256, you want to chuck it, because the multiplication will effectively cause you to skip 3/4 of the entries in the table, which is bad.  if there are 1024 or more, then i suppose the *4 is harmless.

One incarnation of the RNG was to use those table entries as seeds, even more complex than what the current Holy patch does. Extensive testing finally lead us to the conclusion that everything we were doing was no better than the original system.

[assassin]

ok, much of that answer confused me.

No, we actually made a mess of hooks.

are any of these hooks being triggered by C3/13C8's execution?  if not, then how do you accomplish a 0-255 frame counter which increments 60 times per second?

Originally I wasn't sure if C3/13C8 was continuously being called or not. Looking through all of the disassemblies, it is not.

it's not being called continuously by the original game, or by your added patch code?  if it's the former, then i don't follow, because one would think it HAS to be called continuously to keep running timer variables.

[Lenophis]

ok, much of that answer confused me.

are any of these hooks being triggered by C3/13C8's execution?

No.

if not, then how do you accomplish a 0-255 frame counter which increments 60 times per second?

The way I did originally was extremely sloppy, I found code that executes in specific areas and hooked those. In essence, the frame counter is incrementing all the time except during transitions which might be true of the original game's behavior. I haven't checked, suppose I should.

it's not being called continuously by the original game, or by your added patch code?

I was going to say original game, but then Imzog was kind enough to point out that there are other ways to get to C3/13C8, such as C3/000C. I completely overlooked that, even when it was right in front of my face.