Messages

1

Final Fantasy IV Research & Development / Re: Final Fantasy II: A Threat from Within (Version 0.5.1 Available)

« on: November 22, 2015, 09:02:04 AM »

I particularly like the arpeggio bit at 1:20.

2

Final Fantasy IV Research & Development / Suppressing PC celebration after battle

« on: November 13, 2015, 01:50:04 PM »

I was a little disturbed when, in my game, Edge and the party were celebrating after Edge's parents died.  I thought surely that wasn't right, and it isn't.  As an addendum to http://slickproductions.org/forum/index.php?topic=2024.0, which discusses victory music and reward suppression. 

Encounters in which PCs do not celebrate
List at 13:FE76 (ROM A0076), FF-terminated.  If in this list, the PCs will not celebrate.

These two are documented by Pinkpuff and Grimoire in the page linked above:
Encounters which do not reward with XP/GP/loot
List at 13:FD00 (ROM 9FF00), FF-terminated. 

Encounters which should play victory music, even if "no change music" battle flag
List at 13:FE67 (ROM A0067), FF-terminated.


Also, a little info on $A8, which stores flags for why to end battle.  If it is non-zero, battle ends.  Some routines check for victory/loss conditions and assign it regularly through battle.  Also some spells might set it directly, like the special action that ends battle.  Here's what I can gather about what the bits mean, most don't seem to be used together:

Code: [Select]

bit hex  description
0   01   (?)
1   02   (?)
2   04   Set by handler for End Battle AI spell/action
3   08   Faux-loss in a "no game over" encounter
4   10   Used with 20 bit to gain rewards, etc. (not set when encounter is in 13:FD00 table)
5   20   Victory, sometimes with 10 bit above.
6   40   (?  confused, like victory but weird pc status checks I couldn't understand)
7   80   Actual loss
So maybe some custom code might find that interesting.  I would imagine running, and the Exit/Smoke spells are relevant here too, but I didn't check into them.

3

Final Fantasy IV Research & Development / Re: AI condition flags / AI commands F4,F5

« on: November 06, 2015, 09:04:30 PM »

I'm... a little bit confused. Granted subtracting conditional flags does have its purpose. But doesn't FF4kster already do this? I may be missing something here.

(Again I feel a little bad to admit that I don't know if FF4kster has it, as I don't use it for my project.)  But in the document by Phoenix called "EAS", it is a little thin in the details about the format of the parameter byte.  I had to fix a bug in my AI interpreter because Dr. Lugae and Balnab weren't behaving correctly.  So I dug into the assembly, found out that my problem was that they share the flags instead of having their own.  But also found out exactly what bits did what and saw the subtraction option that wasn't in the document.  Just wanted to post something more concrete in case it could help anyone.

4

Final Fantasy IV Research & Development / AI condition flags / AI commands F4,F5

« on: November 06, 2015, 04:09:48 PM »

Here's a break down of the parameter byte for AI commands F4 and F5 which modify the condition flags.  First, the flags are shared by all monsters, which I didn't realize until just now when I was looking at Dr.Lugae and Balnab.  For some reason I assumed each monster had their own.

Code: [Select]

MMxxxxxx
    MM = mode
         00: add
         01: subtract  (never used)
         10: set
         11: (undefined, would probably behave as 10)
    xxxxxx = 6-bit operand


5

Final Fantasy IV Research & Development / Re: Developing FF4kster: a comprehensive editor for FF4

« on: November 05, 2015, 01:16:07 PM »

Tiny contribution for your config files, if you don't already have it (my version of your editor is old).  Event flag 0x3E (62 decimal) that is set when Rydia rejoins the party is for whether the Tanks display at the Tower of Babil.  Fun enough, it's checked every frame (at 00:92C2) so you can edit it at $1287 (bit mask 0x40) and see them appear or disappear live.

6

Final Fantasy IV Research & Development / Re: Automatic action retargeting

« on: November 04, 2015, 02:00:53 PM »

No, I think that it operates on the partial sequence just in the moment it needs to run.  I'm still looking into it, so this is highly speculative.  When a monster's turn comes up, I think it reads from the sequence starting with where it left off last time up to the next Divider(FB), WaitForNextTurn(FE), or end marker(FF), possibly Chain End (FC) as well but I'm not sure about that one yet.  Then something looks it over to explicitly or implicitly target and set the target, action, subaction.  If the targeting fails, then it overwrites the action to do nothing.  Then it calls the assembly routine I mentioned where more target validation and possible re-targeting is performed.  But I think you're right that if the AI explicitly targets something then it won't retarget, because it sort of aborts before it even gets to the retargeting code.

7

Final Fantasy IV Research & Development / Re: Automatic action retargeting

« on: November 03, 2015, 07:09:11 PM »

I'll hold off posting the assembly because I have a ton of half finished analysis notes in it.  For reference, the routine I am looking at is approx 03:AD67 through 03:B0AD.   By the time it's called, a partial AI sequence is available around $3659 or above, depending on the monster index.  By partial, I mean it is cut off at the next Chain Divider (FB) or a few others, I imagine FC,FE,FF.

Also interesting to point out that the caster's action, subaction, and target bits have already been set, based on that partial sequence, even though the sequence has not yet been executed.  For simple monsters, they'll already have C0 and a random target picked.  For AI with a target instruction, it will have run and set the target.  If the target failed, the partial sequence is modified to replace the main action with an E1 and store a zero for their target.  I think that is why the routine in question does not re-target.

8

Final Fantasy IV Research & Development / Re: Automatic action retargeting

« on: November 03, 2015, 04:28:41 PM »

In my implementation, the battle with Golbez and his dragon using Disrupt goes badly if anyone is dead, because it's re-targeting Disrupt, killing everybody and ending the game instead of leaving Cecil alive.

So I'm following a bunch of assembly trying to figure how this works, and I have to just say this:  How many darn places does this game test the caster/target/action/subaction for allowance to do said action??  I swear I've seen the "disallow when swoon except when using these spells or items, disallow when stone except ... disallow when Hide or Jump" in several places.

Rant aside, I found what looks like the relevant assembly, but it's lengthy and convoluted and my eyes are really dried out now.  Need to break.  I wonder if this is one of the things where other people could benefit or if it's just my weird project :)

9

Final Fantasy IV Research & Development / Automatic action retargeting

« on: November 02, 2015, 06:27:26 PM »

Some actions implicitly re-target if the previously selected target is no longer valid (such as dead) by the time it is executed.  Obviously Fight does this.  Do others?  Do spells?  Is the logic of when retargeting is performed known?

10

Final Fantasy IV Research & Development / Re: Hidden spell/action name, monster flashing

« on: November 01, 2015, 12:09:12 PM »

Usually adherence to how the original data or assembly does things, but in this case since the list of them is relatively short, it's not that big of a deal.  So here I'm willing to set some hard-coded overrides if I can just find which are affected.  I appreciate the offer to look into it, but I don't want to ask you to do any work on this one.  I'll save it for something bigger.  : )

Thanks though!

11

Final Fantasy IV Research & Development / Re: Hidden spell/action name, monster flashing

« on: November 01, 2015, 09:16:16 AM »

Hm.  I'm sure A9/AA (invincibility) do not flash, as per D.Mist.  I also suspect AD-BF do not flash.  But do Recover(AB) and Remedy(AC)?  If they do flash, then it makes it not a single range.  I bet a few earlier special ones don't flash either, like Disrupt(73).  Well I think I may have to just hardcode which of the spells have these properties for my project.  Sad, but doable.

As for the name, I briefly wondered if it was just not showing any name that started with a "D", like the Dummys (Disrupt, Dancing, DullSong)... but then there's Demolish and Digest that show.  So that hypothesis didn't pan out.

12

Final Fantasy IV Research & Development / Hidden spell/action name, monster flashing

« on: November 01, 2015, 07:36:00 AM »

Does anyone know why some spell/action names do not display?  How about whether or not monsters flash when using them?  Is it a number range thing, or a table flag thing, or custom assembly thing..?

13

Final Fantasy IV Research & Development / Re: Final Battle's bagkground effect - Is it usable elsewhere?

« on: October 30, 2015, 11:23:39 AM »

Good finds, avalanche!
Do you know if the graphical data for background 10 are stored among the data for the other backgrounds? I'm guessing it might be hard to see in a tile editor. Probably just a bunch of horizontal lines, huh? Maybe not much more than a few tiles, even...

No, I don't know where those graphics are stored yet.  Actually come to think of it, I don't think I know where any of the battle background graphics are yet.

14

Final Fantasy IV Research & Development / Re: Any info on Map Transfer effects?

« on: October 30, 2015, 10:51:55 AM »

I (almost) got what you asked for to work.  I was able to change the "normal map transitions" for when just walking around to use a fade out/in instead of the pixelation effect.  I also found how to invert the event script "load map without pixelation effect", but there's a problem with that, as I'll describe later.

Fair warning - there are a number of places where this patch needed to occur. I may have missed some. Obviously one would need to really play through the whole game to ensure there weren't event scripts messing something up.

First, find routines to do what we need

Original pixelation routines:
  00:9021 - routine to perform pixelation keyhole-close
  00:904B - routine to perform pixelation keyhole-open

Low level fade routines, but cannot just use them directly:
  00:8BB3 - low level fade-to-black, but needs param in accumulator
  00:8B92 - low level fade-from-black, but needs param in accumulator

Now luckily I found some existing assembly that happened to do what was needed, even though they aren't whole routines:
  00:87EA - passes fastest fade speed parameter to fade-to-black routine
  00:8834 - passes fastest fade speed parameter to fade-from-black routine


Normal Map Transitions
First up, the places where the pixelation routines are called for normal map transitions.  Note: The close and open routines seem to be paired, so if you only change some of them, then glitches can occur.

Various closures, change each JSR from $9021 to $87EA:

Code: [Select]

World to dungeon:
  00:9C12  20 21 90    JSR $9021

Dungeon to dungeon:
  00:9A99  20 21 90    JSR $9021

Dungeon to world:
  00:9AA8  20 21 90    JSR $9021

Using a Return Tile:
  00:8197  20 21 90    JSR $9021


Various openings, change each JSR from $904B to $8834:

Code: [Select]

Opening on Overworld:
  00:831B  20 4B 90    JSR $904B

Opening on Underground:
  00:8328  20 4B 90    JSR $904B

Opening on Moon:
  00:8335  20 4B 90    JSR $904B

Opening on Dungeon:
  00:8348  20 4B 90    JSR $904B

With these changes, I was able to test walking around Baron, the town, buildings, and the overworld, and it just uses the fade transition.


Inverting the event scripts transitions (sort of)
I found where to invert this, but it's buggy.  It will work okay for some transitions, but many event scripts will need to be modified to make it work, because they assume the state of the fade.  Some are flickery, and some mess up and try to "toggle fade" when it isn't needed and end up re-fading permanently as a result.  Also some of the visual FX are involved, leaving the fade wrong, etc.

So, I recommend leaving the "without pixelation" as-is, and simply modify each script to toggle the checkbox.  Fixing all the errors otherwise seems prohibitive.

In any case, the places to modify to invert the behavior.  Simply change the BEQ's to BNE's.

Code: [Select]

00:EDE5  F0 04       BEQ $04
  ...
00:EE1B  F0 04       BEQ $04


Again, there could be some bits I missed. But it's a good start!  Happy hacking.

15

Final Fantasy IV Research & Development / Re: Final Battle's bagkground effect - Is it usable elsewhere?

« on: October 29, 2015, 08:25:08 PM »

Slight necro here.  Dug a little into this one.

The special battle background 0x10 is indeed forced based on an encounter number check.  When the encounter number is 439-440, it overwrites the byte at $1802 with 0x10

Code: [Select]

00:8739  AE 00 18    LDX $1800                 Load battle/encounter ID
00:873C  E0 B7 01    CPX #$01B7                Branch if encounter ID < 439 (0x1B7)
00:873F  90 0A       BCC $0A       [00:874B]   ..
00:8741  E0 B9 01    CPX #$01B9                Branch if encounter ID >= 441 (0x1B9)
00:8744  B0 05       BCS $05       [00:874B]   ..
  > only for encounter ids 439 and 440
00:8746  A9 10       LDA #$10                 
00:8748  8D 02 18    STA $1802

00:874B  [carry on]


Then there is a routine called every frame to update the animation at 03:F902.  It checks $1802 for 0x10, and if so, performs some math to slide horizontal strips of the background.

Code: [Select]

03:F909  AD 02 18    LDA $1802                 load battle background ID
03:F90C  C9 10       CMP #$10                 
03:F90E  D0 37       BNE $37       [03:F947]   branch if not zeromus's battle BG (returns from routine)

This routine will animate whatever background is there.  So if you for example change $1802 to 0x10 after the first test (or change the test assembly to something more complex), then it will happily animate some other background other than the blue starry Zeromus bg.  I tried it with the grass and desert.  It might take some crafty background artwork to look good, because it just slides 8-pixel-tall strips around.

So by modifying the first part which tests for encounter number, you could reuse the entire zeromus battle background as-is.  Or you could leave that part, and change the second part which tests for 0x10, and you could animate a different background.

As a bonus, the strip-sliding math uses a table at $7992 which contains how much to move each strip to the left every frame, defining the galactic spinning shear it has.  You can change those values to slide stuff to the right or change the pattern in other ways.  I'm sure this 18-byte table is either copied from the ROM or generated procedurally, but I didn't look into it.