Messages

1

Submissions / Re: FF3us - 255 hours on timer

« on: June 05, 2013, 11:54:58 PM »

it was horrible! ;)  either:

1) change all references to $326C to have your new function's address, wherever that may be.  suppose it were located at C3/1234.  you'd change C3/311F to "20 34 12    JSR $1234", and C3/354B to "4C 34 12   JMP $1234".  C3/3143 and C3/3167, which enter Function C3/326C midway through at C3/3295, would also need to be adjusted.

so more generally, the format of the (non-relative) calls and branch instructions is: opcode (20h for the JSR, which is a call, or 4Ch for the jump JMP), low byte of offset, high byte of offset.  for a far call or jump, it's: opcode (22h for JSL, or 5Ch for JML), low byte of offset, high byte of offset, bank.

2) keep the original function in the same place, and just branch to free space to finish executing the added part.  so you'd include the first 7 instructions of Leviathan Mist's new code as written, then the first "JSR $04B6" would become "JMP $1234".  then at C3/1234, you'd have everything from the "JSR $04B6" through the end of his function.

this has the advantage of using less free space and not having to modify the functions that call or jump to C3/326C.  a disadvantage is that it's slightly slower due to the added "JMP $1234" instruction, but i doubt that matters.  hell, changing the "JSR $04B6" right before the "RTS" to a "JMP $04B6" like the disassembly recommends will make up for some of that.

2

Submissions / Re: FF3us - 255 hours on timer

« on: June 05, 2013, 08:58:22 PM »

that said, i still need to do the frame-by-frame check, and verify that there are indeed 61 frames between display updates.

confirmed this as well.

were they thinking?

i did call them "monkeys" for it, but i can understand their mistake.  they want to update the display every 60 frames, so they set a "frame delay" variable to 60 in Function C2/B936.  if Function C2/B925 worked like:

- decrement frame delay variable
- branch to C2/B936 if the variable is zero

their delay would be as intended.  but the function does the variable check *before* decrementing it.  apparently, this is to make the timer display update the very first time C2/B925 is called in a battle.  i think that the frame delay variable is a default of zero to start a battle (as are many other variables), so my hypothetical order above wouldn't work right in that case.

anyway, Square's order means that C2/B936 won't be called on a frame where the variable goes from 1-->0, but on the frame _after_ that.  to compensate for that extra 1-frame wait, they should have made Variable $628F one smaller, at 59.

and that's what i shall do, in The Easiest Patch Ever (tm).

3

Submissions / Re: FF3us - 255 hours on timer

« on: June 05, 2013, 05:14:57 AM »

hah; confirmed.  the 2-second jump will occur 61 seconds into the battle, but maybe sooner..  i'm not sure on what frame alignments a battle can start, but suppose the real timer is at 20 seconds and 0 frames when a battle commences.  the initial display will indicate those 20 seconds.  then the display is updated 61 frames later, when the real timer is at 18 seconds and 59 frames -- meaning you'll see the seconds go from 20 to 18 without the 19.

those monkeys were apparently confused by C2/B925, even though it's right above C2/B936.  i think changing the "LDA #$3C" at the start of the latter function to "LDA #$3B" oughta solve it.  that said, i still need to do the frame-by-frame check, and verify that there are indeed 61 frames between display updates.

4

Submissions / Re: FF3us - 255 hours on timer

« on: June 05, 2013, 04:41:30 AM »

if you're in a battle, C2/B936 converts the timer into minutes and seconds for display.

looking at Variable $628F, it seems that this function is called every 61 frames rather than every 60?  meaning the display update will lag 1 frame behind each actual second update.  and if you're in a battle for over 60 seconds, you might see a 2-second decrement in this timer display..

maybe i'm misreading something here.  i'll test it in an emulator going frame-by-frame.

5

Game Modification Station / Re: New Skill Help

« on: May 28, 2013, 10:20:43 PM »

no prob.  ah, i didn't stop to think that things like the "REP #$20" were missing.

6

Game Modification Station / Re: New Skill Help

« on: May 28, 2013, 07:34:19 PM »

When removing the JSR, did you replace it with 3 NOPs?  Normally, I wouldn't harp on your pasted instruction addresses, because that would make me a dick, but it's worth asking, given the damage failure is puzzling me.

7

Game Modification Station / Re: New Skill Help

« on: May 28, 2013, 04:23:09 PM »

Change C2/3DF7 to point to 3BCB .  Keep your C2/4263 function, but drop the "JSR $3BCB".

8

Game Modification Station / Re: New Skill Help

« on: May 28, 2013, 01:20:45 AM »

the functions reached from Table C2/42E1 are the once-per-strike special effects.  those pointed to by C2/3DCD are the once-per-target special effects.  add a Mantra function of the latter category that calls Evil Toot.

9

Game Modification Station / Re: FF6 Improvement Project

« on: March 09, 2013, 10:37:09 PM »

or you could duplicate The Sealed Door Fix's change using a map editor.  shouldn't take long, though it won't do anything to address gobs of bytes being altered.

10

Game Modification Station / Re: FF6 Improvement Project

« on: March 08, 2013, 07:35:18 AM »

ok, Novalia's added to the patch documentation to address this.  the patch itself is unchanged, indicating he's confident it works.

i can't think of any other patches in the Improvement Project that edit Maranda's interior map (nor Jidoor's, as previously stated).  if one interprets the Readme warning verbatim, simply modifying the ROM with a map editor is enough to possibly cause clashes, even if it's a different map you're editing.

11

Game Modification Station / Re: FF6 Improvement Project

« on: March 06, 2013, 10:34:57 PM »

weird.  often, map edits will result in larger patches than what he has (like thousands of bytes), because the maps use compression, and changing one tile (at least in a map editor) can wind up changing a whole string of ROM values once the new sequence of tiles is recompressed.  the fact that his patches are so small makes me think that Novalia Spirit manually edited the data, so it's possible that he misread some of the compression info.  or typoed. :P

if he had used a map editor, the chances would increase that a patch editing one area of Jidoor's interior map would conflict with a patch that edits another area of it.  however, i can't think of any other patches that alter this map.

it's worth double-checking "The Magic Bridge Fix" and South Figaro, though it's unlikely there's a problem, with that having been out 4.5 years.

12

Game Modification Station / Re: FF6 Improvement Project

« on: February 18, 2013, 01:38:10 AM »

go via here:
http://fantasyanime.com/finalfantasy/ff6/ff6saves.htm

13

General Discussion / Re: NFL season (2012-2013) week 21 (playoffs?!)

« on: February 03, 2013, 05:31:55 PM »

Ravens.  since a game of this magnitude deserves a made-up score, 28-25.

14

General Discussion / Re: NFL season (2012-2013) week 21 (playoffs?!)

« on: February 03, 2013, 04:30:48 PM »

if i pick Ravens, i'm guaranteed to "win" the playoffs on the board this year (we've all done mighty well), so that's the best strategic pick.  but i'll try not to be a wanker, and look at the game itself.

based on stat comparisons, i like the 49ers better.  but the Ravens have a better turf record (and have played there more games).  against common opponents, they both beat the Patriots, by a similar (average) margin, so the deciding team is the New York Giants, whom Baltimore beat and San Francisco got drubbed by.  they've both done well in the playoffs (obviously), but i was more impressed by the Ravens' last two opponents going into their games than i was the Forty Niners' -- enough to pick against Baltimore both times (the opposite of San Fran), and thus to be more impressed by their victories.  so they have the "momentum" edge if such a thing can exist.

in that vein, San Francisco's defense was more dominant during the regular season, but Baltimore's has struck me as more smothering during the playoffs, remembering that 14 of Denver's 35 points against them came from special teams, which is damn difficult for anybody to reproduce.

there's also the factor that i regularly pick against Baltimore in these threads, this year being no exception.  it's nothing personal; i just happen to think their playoff opponents are better, and am often proven wrong.  this year especially, i've eaten plenty of crow (or rather, crow's cousin has eaten me!).  so not wanting to get burnt thrice in a row would also incline me to pick the black birds.

but i still have 2 hours left, so a pick can wait. :P

15

General Discussion / Re: NFL season (2012-2013) week 21 (playoffs?!)

« on: January 26, 2013, 05:43:45 AM »

Since we did the lark of Pro Bowl picking last year, might as well do it again.  I'll go with the NFC, as they had 39 inter-conference wins this year, versus a mere 25 for the AFC.