Final Fantasy Hacktics

Hey, occasional lurker here --  I am loving all the fantastic hacks that come out of here, but one change in particular is something I have always dreamed about.

Is it possible to distribute JP to all the active units after (or at the start of) a battle?  Ideally the JP would be proportional to the number and strength of the enemies, but a flat rate would also suffice.

Example:
Player brings 5 units in to a random encounter.
The encounter consists of 4 enemies.
At the end of the encounter, 4 * 50 JP is distributed amongst the players' units (into their respective current class).

I will gladly (attempt to) learn basic ASM hacking to add this if it's doable.  What do you all think?

Thanks!

entirely possible. You would just have to code the routine into the Require.Out file, nothing too crazy. Require.out is where all the routines that store modified stats, equipment, gil, etc. after battle.

Excellent, thank you!  Would basing it off of number/stats of the enemy units be possible?  I can't imagine their data would be stored or used after the battle...

Do you have any tips on where is best to start learning for this particular task? (Besides the general tutorials linked in the forums) I imagine I'm in for quite a ride trying to pull it off. Seems like I need to do the following things:


1. Make a temporary variable X for JP rewarded (based off of enemies?)
2. Divide X by number of player chars in the battle
3. Increment each character's JP (of their current class) by X


Or I could just do the calculations in 1 and 2 for every assignment in 3 but I dunno if that'll work in ASM.

Seems like 3 is going to be the hard part, trying to get at the correct JP count for each class.

Thank you very much for the help!

And as an aside, if anyone suitably knowledgable happens to be interested in implementing this kind of patch, I'd love to not have to learn all this... : P

hehe.. the number of general hacks that are produced these days has dropped dramatically... so your best bet may be to learn. Scour the tutorials and the important links section. I made a little package for beginning ASM that I think is in the important links or tutorials section.. It'll take a bit of effort but people on here will always help when possible. First you have to learn where data is stored, which is mostly in the Data Locations.txt. You'll have a much better idea of what to do once you spend some time learning

Aw, dang :p  Thank you again for the help.  Time to go delve in, I suppose... though I'm sure it's only a matter of time until I post in the Help section again.

The nice thing is that once you know your way around, its much easier to do unique things that you want. You don't have to rely on somebody else to make your hacks for you. it just takes some time and alot of effort, that's all.

True indeed.  This stuff is pretty crazy and terrifying to get into, but I think I'm getting the hang of it... a bit...

But now I'm stuck!  I found this particular routine on the wiki: http://ffhacktics.com/wiki/Initialize_Unit%27s_Battle_Data

I'm attempting to insert code at line 0005b260.  Using FFT OrgASM XML Generator, I've made this:

<Patch name="JP+100 On Load Battle">
    <Description>Describe Your Patch Here</Description>
    <Location file="SCUS_942_21" offset="0005b260">
      26250064
    </Location>
  </Patch>

Then using FFTOrgASM I've applied it.  (FFTOrgASM is definitely working, because I also applied "No MP on Battle Start" alongside it and I can confirm that's working.)

However I'm not getting any results for JP going up.

Am I on the right track at all?  Is it possible to edit routines like that?  Am I editing the wrong routine? (Seems like Initialize Unit's Battle Data happens prior to every battle, right?)  Does the command 26250064 actually addiu by 100, like I think it does?

I just need some confirmation that I'm using the tools correctly before I try different things. Thanks!

I have no idea what I'm doing.  T_T

Apparently my command 26250064 is big endian.  Which is wrong.  Although I see all the commands in big endian when I use the debugger... anyway.  So I tried it little endian but nothing changed.

And when I open up my address, 0x0005b260, in the debugger, I see it all as it is laid out on the wiki.  Except for the command I edited, which is marked as "illegal" and says it's "4c444444".

And either way, nothing has any effect.  Although a breakpoint set at 0x0005b260 triggers multiple times at the start at any battle, (~8 times before formation placement, 2-5 times whenever I L1 or R1 to the next character, and ~5 times after formation is set), even inserting nonsense 'illegal' commands apparently does nothing.  And given how often the routine is called I suspect I'm on the wrong track anyway.

Even if I could find a routine that was executed once per battle, and even if I could insert anything I wanted in there correctly, I have no idea how to get access to the player's unit's current job's JP.

I see the addresses on this page: http://ffhacktics.com/wiki/Battle_Stats

But I have no idea what to do with them.  And I wouldn't know how to modify only their current job anyway without some gigantic labyrinthian switch statement that I would have to repeat 5x.  And it would probably crash if the player used less than 5 characters.

I'm happy to see that you're putting effort into it! ok, there's a couple of things that you're missing.

First, "4c444444" is an execute breakpoint. When you set a breakpoint, it stores that command in memory.. and then stops execution of code upon reaching it. It's only temporary, so no worries there.

in your patch, your offset is "5b260". However, this is the offset in RAM. When you write a hack, you actually have to write to an offset in a file. Files are loaded to different portions of RAM. For example, the SCUS file actually starts at 0xF800 in memory, so you would actually have to write it to 0x5b260 - 0xf800 = 0x4ba60. Don't worry, everybody has made this mistake.

lastly and most importantly, your approach will not work. the line in the wiki is actually an address, not a JP total. What the routine is doing is loading the job levels and jp from "Party data" (data stored in SCUS for your formation screen) into Unit Battle Data (temporary data loaded FROM party data to be used and manipulated during battle). To accomplish this though, it loads the two locations to 2 different registers, and then transfers the data using an intermediate routine. Thats this:

0005b264: 0c017895 jal 0x 0005e254      Store X Byte into Y (JP/Total JP)

It was a good thought to do it at the beginning of the battle though, good idea! To accomplish this, we'll use a different routine: http://ffhacktics.com/wiki/Move/Jump_%2BX_Calculation. You can write a jump command that jumps from this routine to a custom one that does what you want. It should only be called once per unit, although there's always the possibility that this routine is skipped for monsters or something, since they can't equip Move +X abilities. You'd have to test that

Now the hard part. You will have to code a routine that does the following:

-Get units data
-Load units Job (0x03 in Unit Battle Data)
-subtract units Job by 0x4A (this is to get the number of the job starting from 0. 0 would be squire, 1 would be chemist, etc.)
-add this number to the unit data address
-load the value at THAT address + 0x00DC (http://ffhacktics.com/wiki/Battle_Stats - this is where current JP amounts are stored. so now our result will be the address of the units current job JP amount)
-add 100 to this value (which you already figured out how to do)
-store the new value
-add 0x28 to the address (this gives you the address to the jobs TOTAL JP amount)
-load THAT value
-add 100 to it
-store it

Yes... you picked a pretty hard hack to do for your first one lol. However, it is completely doable.

A better list of data locations is the "Data Locations.txt" that can be found in the ASM starter kit thread. It has a list of the Party data and Unit battle data, and wayy more other data that is irrelevant atm. For your reference:

Party data starts at 0x57f74, and each unit has 0x100 bytes worth of data (this means that to get for example the third units data, you would do 0x57f74 + (0x100*3) = 0x58274
Unit battle data starts at 0x1908cc (although PLAYER unit data starts at 0x1924cc), and each unit has 0x1c0 worth of data.

Mull it over and check some of the other threads. Sometimes seeing other examples of how people learned will allow you to make connections and learn.

Thank you so much! I never would have been able to figure out to change the offsets like that... or to use Move/Jump +X Calculation. I think I'm really starting to get it because of all your help.

I even was able to change the Base Class' JP!  But that only works when I overwrite large parts of Move/Jump +X Calculation.

Your list of tasks

Quote-Get units data
-Load units Job (0x03 in Unit Battle Data)
-subtract units Job by 0x4A (this is to get the number of the job starting from 0. 0 would be squire, 1 would be chemist, etc.)
-add this number to the unit data address
-load the value at THAT address + 0x00DC (http://ffhacktics.com/wiki/Battle_Stats - this is where current JP amounts are stored. so now our result will be the address of the units current job JP amount)
-add 100 to this value (which you already figured out how to do)
-store the new value
-add 0x28 to the address (this gives you the address to the jobs TOTAL JP amount)
-load THAT value
-add 100 to it
-store it

is also extremely useful. However, I noticed that Move/Jump +X Calculation already has access to the unit's data, so I skipped to just using the existing reference in r4, which works perfectly.  And thankfully, since Move/Jump +X Calculation is called once per unit, I won't have to loop it.

Anyway right now I'm trying, and failing, to create a separate routine.  Currently what I have looks like this:


<Location file="SCUS_942_21" offset="4D0F0">
877A0108 <!-- j 0x0005ea1c -->
    </Location>
    <Location file="SCUS_942_21" offset="4f21c">
DC008294 <!-- lhu r2,0x00DC(r4) -->
04018394 <!-- lhu r3,0x0104(r4) -->
64004224 <!-- addiu r2,r2,0x0064 -->
64006324 <!-- addiu r3,r3,0x0064 -->
DC0082A4 <!-- sh r2,0x00DC(r4) -->
040183A4 <!-- sh r3,0x0104(r4) -->
3E720108 <!-- j 0x0005c8f8 -->
    </Location>


Offset 4f21c (5ea1c) is a chunk of 13 nops according to my debugger.  What the above is doing is just jumping to 5ea1c, loading, adding 100, and saving to the unit's Base JP and Total Base JP, and then jumping back to 5c8f8.

But for some reason it freezes up! I figure there must be an infinite loop in there somewhere, but I can't see what the problem is.  It's all being properly assigned -- I can see it in the debugger -- but there's a glitch somewhere.  All the registers (such as r4) should still be the same from Move/Jump +X Calculation, too... Perhaps I'm using Jump wrong?

EDIT: What the heck?!?!?!?! It works UNLESS I hold down the "fast forward" button in pSX v1.13??  What is that even?

Okay, disregard the above, maybe?  Is this a thing that happens normally??

EDIT2: Okay, I have no idea what's going on.  Whether it works or not appears to be random.  I'm just loading, crashing, reloading, and it works, I don't even know.  More testing.

EDIT3: It appears that it always works if I use debug mode and add a breakpoint at 5ea1c. And apparently it either fires many times prior to, during, and after formation setup, OR it fires ZERO times.  And either way it works perfectly.

Unless I don't have that breakpoint in which case pSX crashes.

I got it working!!!  Phew!

The problem was placing a jump command immediately after a bne.  Apparently those two did not get along, but somehow debugging makes them cooperate.

Anyway, my separate routine is now workable, and I can continue expanding it.  My only questions now is:

Would you say it's safe to overwrite "illegal" commands like 01010101, 02020101, etc?  I'm probably going to need the space...

Excellent job! Now there are a couple more tricks of the trade you need to know.

Even though a space can be full of 00's or nops, that location may be written to by the original game code at some point, which would overwrite your code. Also, "illegal" commands like the ones you suggested appear to be parts of a table of data. Not all hex is code, many places are filled with tables of data. You should certainly stay away from overwriting tables of data, not healthy.

So the solution? Thankfully square left a decently big section of free space called the "kanji table". There were just kanji characters stored here that seem to have no correspondence with anything in the game. You can see the offsets here: http://ffhacktics.com/wiki/Allocated_space

Now, the cause of MOST issues with existing ASM hacks is that space is hard to keep track of, and some hacks are written to the same space as others. The best way to insure that you're not overwriting space is to do the following.

-Open your iso in CDmage
-extract your Battle.bin file (the kanji table exists in this file)
-Open it in a hex editor (HxD is a good one)
-go to the kanji table offsets (The offsets on the wiki are file offsets, not RAM offsets, so no conversion is necessary)
-copy a block of hex values
-paste it into MasshexASM
-convert it to code, and see if it is code that makes sense. If it is, it's probably a hack, if it's not.. it's probably fair game to be used.

Once you have some free space set aside, its as simple as jumping there, doing your thang, and jumping back.

Other things to be aware of when inserting your code in the midst of vanillas:
-Is there an important value stored in a register that you overwrite? See if the original routine uses that value, or overwrites it.
-When you return to the original routine, is everything in a state that it won't mess up the original routines function?

One other thing you have to be careful of is return addresses. You'll notice that the Move/Jump + X routine doesn't have any jal commands. A jal command jumps to another routine, and saves the address of the next command so that it can return there once the other routine is done. The address is stored in r31. However, because all of code is a sequence of calling a subsequent routine.. there is always an important return address in r31. You may see code that looks like this:

in the beginning of a routine
0005c5c8: 27bdffe0 addiu r29,r29,0xffe0      
0005c5cc: afb10014 sw r17,0x0014(r29)      
0005c5d4: afb00010 sw r16,0x0010(r29)
0005c5dc: afb20018 sw r18,0x0018(r29)
0005c5e8: afbf001c sw r31,0x001c(r29)

at the end of a rooutine:
0005c8d0: 8fbf001c lw r31,0x001c(r29)
0005c8d4: 8fb20018 lw r18,0x0018(r29)
0005c8d8: 8fb10014 lw r17,0x0014(r29)
0005c8dc: 8fb00010 lw r16,0x0010(r29)
0005c8e0: 27bd0020 addiu r29,r29,0x0020
0005c8e4: 03e00008 jr r31
0005c8e8: 00000000 nop

What this is doing is saving the return address (r31) as well as other important data in other registers (r16, r17, r18) on the stack, and then loading it at the end so the routine it jumps back to can use it. jr r31 jumps to the address in r31, which is why we reloaded the return address in there.

You can check the standards sticky (http://ffhacktics.com/smf/index.php?topic=7346.0) to get a grasp of some things that can cause problems when writing ASM and how to avoid them.  If you're having problems where something seems to work in the debugger but not while running normally, there's definitely something wrong with the code (though sometimes I find the debugger itself can crash in certain circumstances when deleting breakpoints).

Another thing to note is branch delay -- jumps/branches aren't actually taken until the instruction after the branch is executed. e.g.:

jal  some_routine  # some_routine to be executed after delay slot
add r4,r3,r2   # delay slot: r4 = r3 + r2
# now we jump to some_routine

Putting another jump/branch in the branch delay slot causes problems (pipeline hazard).

I did it!!! 8D Works flawlessly regardless of job/monster! Here's hoping it works consistently as I play through...



I certainly hope I didn't overwrite anything important... since I'm working in SCUS, I didn't conflict with any of the allocated space, but I also don't have a kanji table.  I did have to create an alternate version located somewhere slightly different to make it compatible with 1.3 (they were using the same nops for something else).

Good tips on the return addresses too, I had some brief wrestling with jal before I realized it was a bad idea.  Thank goodness Move/Jump +X Calculation already had about 4 registers it was going to use, so I could just coopt those.

Thank you so much for all your help!  I seriously could not have even scratched the surface without all the feedback.  Now I'm going to play with this for a while, and if I don't find any problems, I'll post it in a proper thread.

Glain, that is a very useful sticky -- I didn't even realize load commands had delay.  Seems I lucked out by copying the format already in use by Move/Jump +X Calculation.

Like I said before, you need to use the kanji space. pick a location in that range of offsets I gave you, and write it there. You're overwriting the movement cost/geomancy skill/terrain status table. This is really gonna cause some strange and crippling side effects :P  Almost there though by the sound of it. Keep learning and more things will make sense to you.. Then you can really edit the way you want

Thanks for that note Glain, I forgot about that convention.

Oh!  For some weird reason I thought jumping from file to file wasn't possible, but I don't know where I got that notion.

In my initial testing I did notice certain tiles had suddenly become unwalkable, but I thought that was interaction between 1.3 and my code. :p Apparently my 1.3-compatible version isn't overwriting that stuff... maybe... but I'd better start delving into the kanji.  I guess I should start looking from 0x0006B90F onward, since that's the last reserved space in WORLD.BIN listed.

Thanks!

Files are just loaded into RAM. During gameplay, either BATTLE.BIN (events/battles) or WORLD.BIN (world map + formation) will be loaded and both have kanji space you can use. The SCUS is always loaded... as for other files, they are loaded depending of the situation, but REQUIRE.OUT is only ever loaded alongside BATTLE.BIN, so it's safe.

its pretty simple to look into the battle.bin file and see what's there. there should be either unknown/illegal commands, or stuff that just doesn't make sense at all. Copy-paste the hex into MasshexASM and it'll show you what's there.

Thanks guys!  I took a break for a bit, but now I'm having another crack at it.  Unfortunately my attempts aren't yielding much fruit... if I put my chunk of code into WORLD.BIN, it seizes up at the start of battle.  (As it should, since I assume WORLD.BIN is not loaded when Move/Jump +X Calculation fires.)

And if I put my code into BATTLE.BIN, it works in battle but crashes when I try to enter the Formation screen.  It seems that Move/Jump +X Calculation is called during the formation screen, but in the past my code apparently just happened to never do anything in that context. (Man was I lucky it ever worked in the first place!)  Naturally this would crash since BATTLE.BIN isn't loaded at that point.

Now I'm not quite sure what to do.

As an aside, it works perfectly when placed in SCUS because I lucked out and put it at 8005e950 (listed as unidentified by the wiki, and seems to do nothing).  I'd like to expand it to do more, but I'm out of space in SCUS.

Paste what you currently have, i'll take a look at it. Welcome to the world of hacking... shit never works perfectly lol. However crashes are not always a fatal omen. A good idea is to set a breakpoint at the start of the routine that you edited... and produce the situation that causes a crash. That way you can step through the commands one by one and try to figure out where in the code it's causing a crash and fix it. Could be something simple.

Heheh, that is very, very true...

Well, here's the version of the code that works:



And here's the version that causes crashes when entering the formation screen (giving me giant piles of "executed illegal opcode"), but works just fine in battle:



For testing purposes I used the location 0x000F12A4 (allocated to FFMaster) because since someone else has used it, it ought to work.

And it does, in battle. As for the formation screen, I put a breakpoint in Move/Jump +X Calculation at my jump command -- that's where it crashes.  (Oddly when I use the debugger like that, instead of crashing it just reboots the game.)

However, this is a pretty unique situation in that I actually know what the problem is : P

Move/Jump +X Calculation is crashing because BATTLE.BIN is not loaded.  What I'm wondering is... is there a check I could perform in Move/Jump +X Calculation so that it only jumps when we're in battle mode?

that's strange... I guess you can't use this routine. I tried observing the return address for each time it's called in the formation screen, but they're the same as the ones in battle. Sometimes you can check for a certain return address so it'll only run when jumping from a specific place.

You may be able to load a byte of some random code in battle.bin, and check for that byte value before continuing through your code. Code usually isn't going to change, whereas table data may. That way the byte would be different if loaded in world.bin and fail. kind of a hack-job way to do it though. Otherwise i'll have to track down a routine that only runs once to initialize data in the start of battle.

Hmm... that's an idea.  Thanks for trying to test that.

I tried seeing if I could run a check on the address the address I'm using (F12A4) to see if it contains my code.  But I'm having trouble getting data at such a high offset, as well as storing an entire command into a register for comparison.



Then I noticed this spot in memory listed in the wiki:
80066200 - Start of Battle Flag? (1 = Initialize data?)

This flag is set to 1 during the formation screen, but set to 0 during battle (and before Move/Jump +X Calculation too!)

However I don't know how to access such a large address (ignoring the 8).  MassHexASM translates my input of "lbu r6, 0x66200(r0)" back out to "lbu r6,-0x33c0(r0)".

If I could get at it, I could run a comparison and execute code only when it's time to battle.

EDIT: come to think of it, is there any Unit Data that differs between combat and formation?
I tried only doing BATTLE.BIN if X Position > 0, but that still fired in formation.

EDIT2: there's a tremendous swathe of empty space in SCUS around 66320 -- it appears to work just fine -- is there a reason I shouldn't use it?

couple things.

To load a large address you need the following commands:

lui rX, 0x8006
lw, lhu, lbu rX, 0x6200(rX)

This loads the data at 0x80066200 into rX depending on which size command you use. Loading a word, halfword, or byte will load 4 bytes, 2 bytes, or 1 byte respectively. Here's a visual demo:
00000000 - Word
0000 - Half
00 - Byte

It's probably sufficient to load a halfword's worth of data and check. Just make sure the data at whatever offset you choose is different in Battle.bin and World.bin. To load a large number into a register to check it against you can do the following:

lui rX, 0x8006
ori rX, r0, 0x6200

This will load 0x80066200 into rX.

You seem to be locked in on using SCUS space... but I highly suggest that you don't. Even if there is no data at the location you want to use, it could be dynamic data that will change over time. Or it could be a part of a table of data, such as the movement cost data that you overwrote before. You have to use the data in Battle.bin on the kanji table like you were doing before, there's no getting around that.

You can try using that flag, it may very well work. You'll just have to test it. You're getting closer and closer so keep digging.

An easy way to see if your code exists in RAM: Go to the debugger and click on the disassembly window (the window with all the code) and press ctrl-g. Then put the address that you want to check in: 0x1582a4. It's RAM offsets, not file offsets.. which is why I added 67000 to f12a4. You can then see the code that exists at that address.

Choto, you are so ridiculously helpful that I just don't have the words to describe it. 8D

It totally works!  I loaded 80066200 as you described and checked it, jumping to BATTLE_BIN when it = 1, and it behaves in formation and works perfectly in battle.

I even moved it to some unreserved BATTLE_BIN space and it still works!  8D  Thank you so much!

Unfortunately I still must use a bit of SCUS to fit the check in there, but only the "8005e950 - (0x80 long?)" part that has proven to work fine (got around 20 hours of playtesting on it last week).  So that should be okay.

I've expanded my code to do a bunch of crazy things, so I'm going to do some thorough testing and then post it.

 :twisted: :evil: USE BATTLE.BIN SPACE!!!!

there is wayyyy more than you'll ever need in a single hack so space should not be an issue. The reason you think the SCUS space is ok is because you haven't tried to use an elemental ability or move with some of the movement supports: move in water, float, fly, teleport, etc. I am 100% positive that there will be an issue if you keep it there.

but otherwise, Nice job! Looks like you got a nice start, now hack it up!

Haha, yeah, I really should... I may have thought of a way to transfer it all to BATTLE.BIN, so I'll look into that.

Although, I wouldn't be surprised if this data wasn't vital -- at least, I can't imagine what possible use "19191919191919191919191919191919191919191919191919191919..." (repeat 10x) could be, especially considering it is clearly not part of a larger data table.  It's literally just 0x80 worth of "19" sandwiched between two unrelated sets of data.

Anyway.  Thanks!  Definitely enjoying the ability to hack in and do whatever : P

That is part of the movement data table. Don't touch it. The only space in SCUS is the space you make for yourself by rewriting large and/or inefficient routines such as the Starting Inventory routine or changing where the data locations are loaded such as those movement data tables could be moved to battle.bin since they are only used in battle.