Please login or register.

Login with username, password and session length
Advanced search  


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

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.

Messages - Glain

Pages: [1] 2 3 ... 26
Help! / Re: Status CT timer to turn number
« on: February 27, 2019, 10:22:41 PM »
That looks like a breakpoint on either a read or a write (signified by "RW" in the breakpoints window), and a read triggered it:
Code: [Select]
0x8019ab54: lbu r2, 0(r5)

That takes the value in RAM at the memory address in r5 (+ 0) and copies it into register r2.  We can see the value of r5 = 0x80190938, which is an address included in your breakpoint.
(Using 0x190938 - 0x190939 for the breakpoint will cause it to trigger for both locations; you should be able to use 0x190938 for both start and end)

The call stack there isn't actually showing the call stack but just the current instruction.  If you step through a few lines, it should eventually load the call stack properly again.  Sometimes you have to step all the way through the current routine to get it to happen.  Not entirely sure why...

Anyhow, what we're interested in is a write to the death sentence CT, not a read of it.  You can set up the breakpoint to only be for writing and you'll just see "W" instead of "RW" in the breakpoint window.  That should hopefully find the code we want to see!

Also, for clarity: addu r6, r6, r4 is r6 = r6 + r4, not r6 + r6 = r4.  The first register listed is the one assigned to, and it's nearly always that way for any instruction that modifies a register value.

Help! / Re: Status CT timer to turn number
« on: February 26, 2019, 01:59:11 AM »
No need to play detective with where the value is in RAM because we already know.  This is a very handy reference.

In-battle unit data in RAM starts at address 0x801908cc and the size of a unit is 0x1c0 bytes.  They're stored sequentially in one big array.  If you use debugging tools to inspect the values of these RAM addresses at runtime, you should be able to find your test unit.

From the reference above, we also know the death sentence CT is offset 0x006c from the start of a specific unit's data.  That should give you a specific RAM address for your test unit.  You can set up a write breakpoint at that memory location which will break execution when the value is changed.

Help! / Re: Status CT timer to turn number
« on: February 25, 2019, 01:55:23 AM »
Oh, those comments are from my annotation of that code on the Wiki.  The code itself doesn't actually have comments in it.

Yes, the jal statement you highlighted is the one that calls the routine.  That code probably runs for every clocktick, whereas the code that handles the death sentence CT probably only runs on unit turns so I imagine it's somewhere else.  Finding that code is the question, and that's where I'd use a debugger.

Help! / Re: Status CT timer to turn number
« on: February 25, 2019, 12:07:42 AM »
Heh heh heh.  Apparently you haven't seen much of FFT's code yet.

It's probably hardcoded by status ID.  The routine that handles decreasing status CT for those that use clockticks is here and the routine that calls it is here.  It's looking directly at status IDs.

I'm not sure, however, where the code is that affects the countdown for death sentence.  Looks like a job for a debugger -- breakpoint when the value changes.

Completed Patches / Re: Auto-SCC Patch
« on: February 17, 2019, 06:34:28 AM »
How does this affect the actual battles? For example, in that particular instance, is Agrias a Geomancer during the actual Bariaus Valley fight or is she forced that way after?

She's a Holy Knight during the battle, and is then locked into the chosen SCC class afterwards.  The general rule is that Guests will be the same as usual until they join you.  I also didn't want that battle in particular to be a lot more difficult if you had chosen a less sturdy class.

Strange change for the Rubber Shoes. It's not terribly important but it does change the fight At the Gate of Lionel Castle. Why change it?

For that reason.  The Rubber Shoes make you immune to damage from everybody in that battle except Gafgarion (and maybe the summoner?).  I don't think it was intended for Rubber Shoes to break the battle that badly, because the enemy units in the Lionel Gate battle are actually assigned to have random equipment, and it just so happens the game can only select the lightning weapons because of the unit levels.

The "crits always do bonus damage" business is also a little strange to me. I'm for quality of life changes but anything that shakes the foundation of the game, even if it's only a little, makes the challenge slightly different from the original. Of course, if that was your goal, this is a solid patch through and through, and may be worth a try one day.

I understand that point of view, but I think of "crits that aren't really crits" as a bug that should be fixed.  It's strange for the visual and audio effects of a crit to happen but for no bonus damage to be dealt, and I don't see why that would be desirable behavior in any circumstance.

The three values in the Animation tab are really just numbers, corresponding to certain IDs.  They don't represent a set of flags, so editing each bit individually makes no sense, and you can just edit the numbers directly in the textboxes.  The checkboxes were removed for that reason.

I'm pretty sure one of those numbers (the third?) is the ID of the quote that sometimes comes up when you use the corresponding ability, with 0 meaning no quote.

Help! / Re: FFTorgASM appears to be doing nothing
« on: February 13, 2019, 01:05:30 AM »
That should have worked.  It turns out... there was a bug in my elemental hack!  Thanks for reporting the issue.  I've fixed the problem and uploaded a new zip in my ASM thread.

Help! / Re: FFTorgASM appears to be doing nothing
« on: February 11, 2019, 10:15:09 PM »
The formula labels in FFTPatcher don't read anything from the actual formula code in the game, so that doesn't work as a quick test.  :D

You'll have to try testing the behavior in-game.

Generically, you can also see whether or not the timestamp updates on the BIN file when you apply a patch.

Hmm... not sure what may be going on there.  The patch should apply just like any other patch. 
I just did a test and it seemed to work for me.  For 70 Faith Ramza with a Blaze Gun and two savestates, one normal and one patched:

58 faith target, bad compat: normal damage 85, patched damage 127
53 faith target, normal compat: normal damage 103, patched damage 155

That's the location within the PSX RAM where the code will be when it's run.  The offsetMode="RAM" attribute will cause that offset to automatically be translated to the correct offset in BATTLE.BIN, that being 0x121C34.

Hrm, well, here's a patch that should do 1.5 * ability power for formula 4, rounded down.  Untested!

I mean, formula 4 could be modified via ASM hacking to do the sort of thing you're talking about.  The modifications made by the ASM patch would depend on what exactly you wanted the formula to do.  Not sure if that answers the question.

I do know item types are hardcoded by item ID in some places in the code.

Help! / Re: Sprite size problem
« on: January 26, 2019, 09:46:26 PM »
To be fair, I was already inclined to make that change :D.  That popup asking to restructure the ISO every time you open the program was driving me insane.

Completed Patches / Re: Auto-SCC Patch
« on: January 13, 2019, 05:56:56 PM »
I hadn't even really thought of it, but yes, I suppose I could release the level cap functionality as a separate hack.  I just put together the pieces from the SCC patch that control the level cap functionality into a single patch.  I didn't really test this new patch, so let me know if it doesn't work, but I did at least test to make sure it didn't cause a crash when a unit levels up.

The parts of this patch that use free space can be moved around in free space by changing the offset attributes of the relevant Location tags if there is a conflict with another hack.

The actual level caps are defined in the first Location tag in the patch XML.  The data looks like this:

0F 14 1F 23 29 32 35 46 00 00

Each entry is a two-byte set, and it ends with 00 00.  All numbers are in hex.

The first number in each set is compared against the storyline progression variable (List of some of the possible values here:
Basically, events corresponding to certain cutscenes set this variable (Variable 0x006E) to a specific value to keep track of how far you are in the storyline.  The higher the number, the further along you are.

The second number in the set is the actual level cap, and that cap applies when the storyline progression variable is less than or equal to what the first number is.

In our case we have four sets.
0x0F    Orbonne (Ch 2 start scene)  (0x14 = 20)
0x1F    Chapter 3 Start                   (0x23 = 35)
0x29    Chapter 4 Start                   (0x32 = 50)
0x35    Before final Orbonne            (0x46 = 70)

Anyhow, here are the goods:

Yep, agreed.  I've always found ePSXe to have weird, inconsistent audio, even when playing unmodified FFT.

In addition, this patch doesn't change anything that should affect battles or cutscenes.  The only affected files are WORLD.BIN (world map, formation screen, etc.), ATTACK.OUT (pre-battle), and REQUIRE.OUT (post-battle).  The ATTACK.OUT one could only affect battles/cutscenes if the data was copied somewhere into SCUS/BATTLE data during runtime and I don't think it is.

I've never heard of or experienced anything like this happening with this patch.  Is this audio issue happening during battles, on the pre-battle screen where you set your formation, during the post-battle sequence, or outside of battle entirely (world map, formation screen, etc.)?  Is this on console or emulator (if so, which)?

(This isn't really so much an assembly hack as it is replacing one hardcoded value and some tables of static data.)

In .492, under other images, if you go down to Dragon on Unit.bin, it doesn't give the 4th palette which is used for Reis in dragon form.

Normal EVGRP doesnt have this either, it can currently only be seen in the Japanese version of EVGRP which is in the japanese programs set.

Didn't notice this somehow.  The 4th palette is stored way out of order in the file, making this cumbersome to deal with.  I added another entry "Holy Dragon" two entries down from Dragon that points to the same graphic but with the purple palette.  Here's an EXE with the update.

PSX FFT Hacking / Re: ASM Caster/Target Faith
« on: October 25, 2018, 02:28:40 PM »
If you're referring to the ASMs "Remove target's faith from spell damage calculations" and "Remove caster's faith from spell damage calculations" then yes, that is precisely what they do.

Completed Patches / Re: Auto-SCC Patch
« on: October 21, 2018, 06:25:24 PM »
That's as expected, and standard fare for certain SCCs.  The first katana doesn't become available until Chapter 2, as always.  On the bright side, you should be able to punch decently hard since Samurai have good PA.  I think high Brave will also help you do more punching damage.  You can also rely somewhat on Guests (who have no class restrictions) in the early game.

Help! / Re: Unaligned offset at address xxxx
« on: October 11, 2018, 08:40:11 PM »
This will cause the game to crash on console.  Some emulators may allow it.  Use at your own risk.

EDIT - The hardware doesn't allow doing unaligned loads and stores using lw/lh/lhu and sw/sh.  I wouldn't recommend using any hack that does it.  Any emulator that does allow it is not emulating the hardware correctly.
Unaligned loads/stores of 4-byte values can be done with lwl/lwr/swl/swr but you need to use 2 instructions a shot.

EDIT - Event Instruction Upgrade v1.13 doesn't have unaligned loads/stores.

Pages: [1] 2 3 ... 26