1
Final Fantasy V Research & Development / Re: FFVX - A Rebalancing Mod
« on: March 04, 2018, 09:47:58 PM »
I know it's long after the fact, but don't bother with ZSNES, it's shitty.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Final Fantasy V Research & Development / Re: Improving the FF5a Custom Class Mod
« on: November 26, 2017, 10:56:13 PM »Quote
Short version - NO. The number of innates is fixed - 16, while passives ... well I haven't counted but they are much more. So simple tagging of all passives as innates is not possible. Also innates are hard coded, so you can't even change their order.
It seems to me you don't understand how innate work. I will suggest take my Viewer and check carefully Ability & Jobs tabs. Let me try to explain:
- innate are subset of Passive abilities
- there are exact 16 innates (2 bytes) and their bit meaning is hardcoded
- innate don't need to be equipped or learned in order to function
- which innate will be active depend of the Job
This isn't really a hard no, but it's definitely difficult enough to be a soft no.
Simply, when a character either has an innate skill from a class, or equipped via the learned ability, one bit of a word is set. IIRC, this is actually done via masking; each ability and class has a word value that is all OR'd together. For Freelancer and Mimic, it's a bit more complicated, and I don't recall it well enough without checking my notes (it's been a while).
There's nothing stopping someone from making more innates via expanding tables, finding free space, possibly changing references, and checking that instead... although this is where it becomes a "soft no" since this is quite the undertaking. Similarly, there's nothing technically stopping someone from changing innates (or expanded innates) to being included in Freelancer/Mimic (or any class) as soon as they are learned - it's just not easy.
However, if you were looking to simply change a passive, that's considerably easier (but by no means trivial). It just involves removing references where the passive bit was originally checked, and writing new code to check the bit for your new passive.
3
Final Fantasy V Research & Development / Re: New Project
« on: September 03, 2017, 11:20:42 AM »2. if you have 30 AGL you need 90 ATB ticks, 90 AGL needs 30 ATB ticksOK, so the ATB decrements with 1 each tick, right???
those ticks happen several times per second, slow/haste does not affect that anymore from here.1. The initial ATB value is in fact the "120 - Agility" part (Of course, it will depend too on whether you get a Pre-emptive or Back Attack). For example, lets take Butz default stats which has an agility of 25, so 120-25 = 95. So it's expected that his ATB is either 95, 96 or 94 (due to the chance of +/- 1). Each time you end your turn, the ATB will go back to 95 and start decreasing from thenAre you sure? This is calculated when timer hit 0, but I'm not sure is that the case when the battle starts ...QuoteI also have these other addresses, but I haven't played with them so I don't know exactly how they work. They are sort of controls for the ATB behavior.Yeah there bunch of tables in memory connected with timers (ATB been one of them). According to LightPhenix research (just add +$A for Player 1):Code: [Select]3CF1 Status Flag 1 - On; 0 - Off; 80 - Ending
3D75 Timer Value
3DF9 Timer Initial Value
3E7D Creature List Counter A counter used to rotate through each creature in the list above
3E88 Process Ending Timer Flag Set when any creature's timer reached zero. The code only handles ending one creature per status each frame.
3E93 Random Creature List A randomized list of each creature position (0-B), generated when battle starts at C2/1FD2
3E9F ???
3EB7 Creature Timer Ending Set to whichever creature number's timer is ending this frame
3EC2 ???
3ECE ???
3ED9 Timer Decrement Duration Certain timers do not decrement every frame. These values are held in D1/2976
3EE4 Process Timer Flag Set when the decrement timer is zero; true when processing, false when not needed
I was about to post how I did a bunch of research trying to increase the number of timers, and didn't realize I had already posted it here. Good to know.
4
Final Fantasy V Research & Development / Re: Too many in-Battle Loopholes
« on: July 30, 2017, 06:04:30 PM »The bigger problem would be places where the same code checks both monster HP and player HP. You'd need special code to handle those cases.I don't know if FF5 made it easy, but in FF6 it was made to be very easy. It uses indexing for stats, and all we had to do was check to see if our index was at least 8. If it was, we knew it was a monster and could check the third byte and do the special checks. Unfortunately, the checks are everywhere cause FF6 is a mess. I am merely speculating if FF5 would be easier to do this with, since FF5 is just a less-sophisticated version of FF6, engine-wise.
FF5 is similar; there are checks for HP everywhere (along with the usual shortcuts like comparing the low and high bytes to check for zero/non-zero).
That said, I don't think it would be difficult to do per se with a little experience, just not as straight-forward as it seems at first glance. You could probably write a short subroutine (and check by index would work for monster/player) and just swap it in.
5
Final Fantasy V Research & Development / Re: Too many in-Battle Loopholes
« on: July 02, 2017, 04:19:51 PM »What would be more realistic, and I'm surprised this hasn't been brought up yet, is implementing a third byte for HP. FF5 has far fewer systems in place than FF6 did, so it wouldn't be nearly as difficult to implement. Damage/healing, Vampire (falls under damage/healing), exploder (figuring monster HP for damage), white wind (figuring monster HP for healing), some AI commands that determine actions based on HP, and Libra. Then again, with FF5's engine the way it is currently, you're still going to have the same problems as listed before.
It's a little more difficult than that, since HP is checked in numerous places... but not stupidly so. Superficially, you just need to find all the checks for HP and alter them. The bigger problem would be places where the same code checks both monster HP and player HP. You'd need special code to handle those cases. Also, depending on how you layout the extra byte, you might need some added code to handle offset conversions.
6
Final Fantasy V Research & Development / Re: Two Galufs
« on: June 08, 2017, 12:01:53 AM »
Hey, just for the record, I don't care if anything I share - files, posts, whatever - gets shared. Information helps everyone.
7
Final Fantasy V Research & Development / Re: New Ability Info
« on: May 28, 2017, 01:33:16 PM »
Not sure if any of this will be helpful, but here are my notes on menu drawing. No guarantees anything is correct though. I haven't had time to do anything with it, so hopefully other people can.
8
Final Fantasy V Research & Development / Re: New Ability Info
« on: May 25, 2017, 08:24:07 PM »
D0/ED02 is a mapping table that correlates an ability index with a function address. For obvious reasons, these are sometimes the same. For example - all spells use the function at c2/5b9f to run. This doesn't actually have anything to do with menus at all; this is purely to queue effects and animations when you use an ability.
Almost all menu code can be found in C1. If you're interested in animations, C1 is also where most of that code is found. "Effect" is my terminology for checking/setting/getting values, and with regards to battle is almost entirely within C2.
Almost all menu code can be found in C1. If you're interested in animations, C1 is also where most of that code is found. "Effect" is my terminology for checking/setting/getting values, and with regards to battle is almost entirely within C2.
9
Final Fantasy V Research & Development / Re: Only Evasion from Shields is counted
« on: April 22, 2017, 02:57:02 PM »
Nothing specific. I've been very busy with work and life, and have had very little time to work on any big projects.
I (of course) have a big project that is basically rebalancing classes and abilities, and eventually making battles less frequent and more interesting.
I would like to keep working on bugfixes, but a lot of them require more thorough rewrites. For example, all the equip bugs in battle (Thornlet, Mirage Vest, Mix bugs, a few others) can be fixed by rewriting the recalculation function to take into account stuff. It's a larger undertaking than it seems at first blush though.
I would love to do more thorough work on understanding C1 and graphics/animation in general. That's not really a romhack though, just information gathering. It's been a long time since I've looked at any of that. Specifically, I really want to get a handle on window drawing.
I (of course) have a big project that is basically rebalancing classes and abilities, and eventually making battles less frequent and more interesting.
I would like to keep working on bugfixes, but a lot of them require more thorough rewrites. For example, all the equip bugs in battle (Thornlet, Mirage Vest, Mix bugs, a few others) can be fixed by rewriting the recalculation function to take into account stuff. It's a larger undertaking than it seems at first blush though.
I would love to do more thorough work on understanding C1 and graphics/animation in general. That's not really a romhack though, just information gathering. It's been a long time since I've looked at any of that. Specifically, I really want to get a handle on window drawing.
10
Final Fantasy V Research & Development / Re: New Information about Targeting
« on: April 09, 2017, 03:08:24 PM »
So, I wanted to follow up on this since I don't like leaving things half finished. Plus, I've been looking into AI a bit after I realized how much space in RAM it takes up. Anyway, based on the code, here's the list of target parameters:
00 Target Bartz
01 Target Lenna
02 Target Galuf
03 Target Faris
04 Target Krile
05 Target Monster 1
06 Target Monster 2
07 Target Monster 3
08 Target Monster 4
09 Target Monster 5
0A Target Monster 6
0B Target Monster 7
0C Target Monster 8
0D Target Self (Effectively, see below)
0E All Non-Self Monsters
0F All Monsters
10 Single Non-Self Monster
11 Single Monster
12 All Front Row Players
13 All Back Row Players
14 Single Front Row Player
15 Single Back Row Player
16 All Female Players
17 All Male Players
18 Single Female Player
19 Single Male Player
1A All Available Players (see below)
1B Single Availble Player
1C All Monsters With Reflect (not really useful)
1D Single Monster With Reflect
1E All Monsters With Critical (aka Near Death)
1F Single Monster With Critical
20 All Monsters Less Than Half HP
21 Single Monster Less Than Half HP
22 Single Player Without Reflect
23 All Players In Team (see below)
24 Single Player In Team
25 All Monsters Dead Or 0 HP
26 Single Monster Dead Or 0 HP
27 ??? (see below)
28 Target Bartz If Jumping (see below)
29 Target Lenna If Jumping
2A Target Faris If Jumping
2B Target Galuf If Jumping
2C Target Krile If Jumping
2D Target Previous Attacker
2E All Players Where Flag Set (see below)
2F Target Bartz if Dead (see below)
30 Target Lenna if Dead
31 Target Faris if Dead
32 Target Galuf if Dead
Notes:
Unless explicitly targeted, single targets are randomly chosen from the list of available targets.
0D: This isn't explicitly targeting self unless a flag (7C56) is set to zero, but appears to serve that function. I suspect the additional code is for counters that trigger on self, but I have not verified this.
1A: By available here - players that are Present and not Petrified, Dead, Erased, Hidden, or Jumping. These are checked for most of these targeting functions.
23/24: I'm not sure offhand what the difference between this and 1A/1B are. This checks the "In Team" flag (#40) in the player info byte (2000,X) similar to Gender/Row.
27: This parses more of the AI code, and it's a can of worms I'm not prepared to look into yet. When I've unraveled more of the AI parsing I'll come back to this.
28-2C: These target a jumping player, if they are not already affected by Interceptor Rocket. The way IR works is that it tells the affected target to perform action #50, overwriting whatever it was doing before. This function checks if the player is performing command action #50 already and skips them if they are. This prevents IR from being used on a target twice.
2E: This checks $7C87 and if the player's bitflag (80 = B/L/F/G/K/-/-/-) is set, and adds them to the target list if it is. I don't know what sets this flag, but it's something in C1 so it's likely to be animation based.
2F-32: There is no function to explicitly target a dead Krile. Oops.
00 Target Bartz
01 Target Lenna
02 Target Galuf
03 Target Faris
04 Target Krile
05 Target Monster 1
06 Target Monster 2
07 Target Monster 3
08 Target Monster 4
09 Target Monster 5
0A Target Monster 6
0B Target Monster 7
0C Target Monster 8
0D Target Self (Effectively, see below)
0E All Non-Self Monsters
0F All Monsters
10 Single Non-Self Monster
11 Single Monster
12 All Front Row Players
13 All Back Row Players
14 Single Front Row Player
15 Single Back Row Player
16 All Female Players
17 All Male Players
18 Single Female Player
19 Single Male Player
1A All Available Players (see below)
1B Single Availble Player
1C All Monsters With Reflect (not really useful)
1D Single Monster With Reflect
1E All Monsters With Critical (aka Near Death)
1F Single Monster With Critical
20 All Monsters Less Than Half HP
21 Single Monster Less Than Half HP
22 Single Player Without Reflect
23 All Players In Team (see below)
24 Single Player In Team
25 All Monsters Dead Or 0 HP
26 Single Monster Dead Or 0 HP
27 ??? (see below)
28 Target Bartz If Jumping (see below)
29 Target Lenna If Jumping
2A Target Faris If Jumping
2B Target Galuf If Jumping
2C Target Krile If Jumping
2D Target Previous Attacker
2E All Players Where Flag Set (see below)
2F Target Bartz if Dead (see below)
30 Target Lenna if Dead
31 Target Faris if Dead
32 Target Galuf if Dead
Notes:
Unless explicitly targeted, single targets are randomly chosen from the list of available targets.
0D: This isn't explicitly targeting self unless a flag (7C56) is set to zero, but appears to serve that function. I suspect the additional code is for counters that trigger on self, but I have not verified this.
1A: By available here - players that are Present and not Petrified, Dead, Erased, Hidden, or Jumping. These are checked for most of these targeting functions.
23/24: I'm not sure offhand what the difference between this and 1A/1B are. This checks the "In Team" flag (#40) in the player info byte (2000,X) similar to Gender/Row.
27: This parses more of the AI code, and it's a can of worms I'm not prepared to look into yet. When I've unraveled more of the AI parsing I'll come back to this.
28-2C: These target a jumping player, if they are not already affected by Interceptor Rocket. The way IR works is that it tells the affected target to perform action #50, overwriting whatever it was doing before. This function checks if the player is performing command action #50 already and skips them if they are. This prevents IR from being used on a target twice.
2E: This checks $7C87 and if the player's bitflag (80 = B/L/F/G/K/-/-/-) is set, and adds them to the target list if it is. I don't know what sets this flag, but it's something in C1 so it's likely to be animation based.
2F-32: There is no function to explicitly target a dead Krile. Oops.
11
Final Fantasy V Research & Development / Re: Only Evasion from Shields is counted
« on: April 08, 2017, 04:39:57 PM »
Expand the code at C2/9BCB. See other code in that area, which does similar things for other stats.
12
Final Fantasy V Research & Development / Re: Only Evasion from Shields is counted
« on: April 06, 2017, 11:17:14 PM »
Which animation is used depends on order of operations in the functions.
(Not strictly true - it's based on checking the Miss Flag ($56). When it gets set, the function is over. So the animation byte could theoretically get overwritten after the fact.)
For example: the hit determination at 7EBE calls the Evade/Parry/Elf Cape check before the Shield check. So those will always take precedence if they trigger. Within that function, the order is Evade (ability) > Parry (Defender) > Parry (Guardian) > Elf Cape.
You could certainly change that order pretty easily though.
(Not strictly true - it's based on checking the Miss Flag ($56). When it gets set, the function is over. So the animation byte could theoretically get overwritten after the fact.)
For example: the hit determination at 7EBE calls the Evade/Parry/Elf Cape check before the Shield check. So those will always take precedence if they trigger. Within that function, the order is Evade (ability) > Parry (Defender) > Parry (Guardian) > Elf Cape.
You could certainly change that order pretty easily though.
13
Final Fantasy V Research & Development / Re: Only Evasion from Shields is counted
« on: April 03, 2017, 09:01:18 PM »Code: [Select]Check for Physical HitYeah you can see it in the code only $2011 and $2012
C2/7E23: 20 A2 02 JSR $02A2
C2/7E26: C5 4E CMP $4E Check (0..99) < Hit%
C2/7E28: B0 2E BCS $7E58 Miss if (0..99) >= Hit%
C2/7E2A: A6 49 LDX $49
C2/7E2C: BD 1B 20 LDA $201B,X
C2/7E2F: 1D 71 20 ORA $2071,X
C2/7E32: 29 70 AND #$70 (Target Status2 = Sleep, Charm or Paralyze)
C2/7E34: D0 24 BNE $7E5A Can't Evade
C2/7E36: BD 1C 20 LDA $201C,X
C2/7E39: 29 10 AND #$10 (Target Status3 = Stop)
C2/7E3B: D0 1D BNE $7E5A Can't Evade
C2/7E3D: 20 A2 02 JSR $02A2
C2/7E40: C5 4F CMP $4F Check (0..99) < Evade%
C2/7E42: B0 16 BCS $7E5A Hit if (0..99) >= Evade%
C2/7E44: A6 49 LDX $49
C2/7E46: BD 11 20 LDA $2011,X
C2/7E49: 1D 12 20 ORA $2012,X
C2/7E4C: F0 0A BEQ $7E58
C2/7E4E: A5 47 LDA $47 (Can't Miss if Attacker = Target)
C2/7E50: C5 48 CMP $48
C2/7E52: F0 06 BEQ $7E5A
C2/7E54: A9 06 LDA #$06
C2/7E56: 85 5D STA $5D
C2/7E58: E6 56 INC $56 Attack Misses
C2/7E5A: 60 RTS
That code is not where the Evasion stat is calculated. $4F holds the evasion chance; it is loaded on a per attack basis.
Evasion is calculated as part of the clown fiesta that is the equipment calculation code (home of Mirage Vest, Thornlet, and other bugs). The specific calculation is at C2/9BCB, and stored into $202C,X. Note however that this code also only uses Shield Evasion. If you want to change evasion to use everything, you'll want to do that here. That way it will always get calculated correctly when stats are recalculated.
Okay, so what is that shield check doing then?
The CMP $4F/BCS is branching if you have hit (note it jumps past setting the miss flag). The next step is checking if the target has a shield equipped; if they don't, set the miss flag and exit. Then obviously auto-hit if you're attacking yourself. Finally, we set a value of 06 to $5D. You should suspect already what this is - something only set when blocking with a shield equipped. This is an index to what "evade" animation will play. Try changing the value to see other animations (for example 00 is nothing and 03 is the cape).
14
Final Fantasy V Research & Development / Re: New Information about Targeting
« on: April 03, 2017, 11:18:55 AM »
Random single target. The workflow is something like this:
The game gets a random number 0-7
Checks if that number corresponds to a valid player target and chooses it
(if no player) Checks if that number corresponds to a valid monster target and chooses it
Repeat if no target found
The game gets a random number 0-7
Checks if that number corresponds to a valid player target and chooses it
(if no player) Checks if that number corresponds to a valid monster target and chooses it
Repeat if no target found
15
Final Fantasy V Research & Development / Re: New Information about Targeting
« on: April 01, 2017, 07:56:54 PM »
A couple of notes here based on an hour or so of quick research:
First, below I refer to "player" as one of the four slots of Bartz etc. "Monster" refers to one of the eight monster slots. I prefer this to ally/enemy to prevent ambiguity.
Second, F3 doesn't actually use the second parameter. It's meaningless to include, and gets overwritten (to store monster targets).
00-04 are targeting a specific player as noted, and yes 04 is Krile.
05-0c are targeting a specific monster slot (offsets 0200 through 0580).
0e-11 are various combos of targeting random monsters (not players). 10 and 11 are specifically a random targetable monster; 11 is unsurprisingly random monster including self.
Side note: if you're looking at the code (F3 at C2/33EC, or parsing the parameter at C2/2C27) $2724 is true if targeting all available targets. The code for checking this is in 33EC.
12-19 all use the same function and check bits in $2000,X. 12 is All in Back Row, 13 is All in Front Row, 14 is RST in Back Row, 15 is RST in Front Row. 16 is All Female, 17 is All Male, 18 is RST Female, 19 is RST Male. For these functions, this is *only* checked for players, not monsters.
I haven't looked at any of the others, but there are 33 total (see indirect jump at C2/2C4A).
First, below I refer to "player" as one of the four slots of Bartz etc. "Monster" refers to one of the eight monster slots. I prefer this to ally/enemy to prevent ambiguity.
Second, F3 doesn't actually use the second parameter. It's meaningless to include, and gets overwritten (to store monster targets).
00-04 are targeting a specific player as noted, and yes 04 is Krile.
05-0c are targeting a specific monster slot (offsets 0200 through 0580).
0e-11 are various combos of targeting random monsters (not players). 10 and 11 are specifically a random targetable monster; 11 is unsurprisingly random monster including self.
Side note: if you're looking at the code (F3 at C2/33EC, or parsing the parameter at C2/2C27) $2724 is true if targeting all available targets. The code for checking this is in 33EC.
12-19 all use the same function and check bits in $2000,X. 12 is All in Back Row, 13 is All in Front Row, 14 is RST in Back Row, 15 is RST in Front Row. 16 is All Female, 17 is All Male, 18 is RST Female, 19 is RST Male. For these functions, this is *only* checked for players, not monsters.
I haven't looked at any of the others, but there are 33 total (see indirect jump at C2/2C4A).