• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
June 01, 2024, 07:30:01 pm

News:

Please use .png instead of .bmp when uploading unfinished sprites to the forum!


It is possible...! Distribute JP after battle

Started by Eldiran, May 15, 2013, 08:57:39 pm

Eldiran

Heheh, that is very, very true...

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


    <Location file="SCUS_942_21" offset="4D0F4">
547A0108 <!-- j 0x0005e950 -->
    </Location>
    <Location file="SCUS_942_21" offset="4f14c">
00000000
00000000
03008290
4A000324
13000624
22104300
22184600
02006004
00000000
21100000
FEFF4004
20104200
DC004524
2128A400
0000A294
2800A394
64004224
64006324
0000A2A4
2800A3A4
2A008294
2E008394
3E720108
00000000
   </Location>


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:


    <Location file="SCUS_942_21" offset="4D0F4">
A9600508 <!-- j 0x1582a4 -->
    </Location>
    <Location file="BATTLE_BIN" offset="F12A4">
00000000
00000000
03008290
4A000324
13000624
22104300
22184600
02006004
00000000
21100000
FEFF4004
20104200
DC004524
2128A400
0000A294
2800A394
64004224
64006324
0000A2A4
2800A3A4
2A008294
2E008394
3E720108
00000000
   </Location>
 


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?

Choto

May 25, 2013, 05:55:56 pm #21 Last Edit: May 25, 2013, 06:04:33 pm by Choto
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.

Eldiran

May 25, 2013, 07:11:04 pm #22 Last Edit: May 25, 2013, 10:02:05 pm by Eldiran
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?

Choto

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.

Eldiran

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.

Choto

 :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!

Eldiran

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

Pride

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.
  • Modding version: PSX
Check out my ASM thread. Who doesn't like hax?