FFTPatcher: * Fixed bug in ability editor where it could try to update the "inflict status" values for abilities without attributes * Fix for ampersands inside certain controls that use TextRenderer.DrawText() (Includes ENTD unit area)
FFTactext: * Made PSXText.xml and PSPText.xml external files that can be used to configure section entries, DTE, compression, etc. These were previously the internal psx.xml and psp.xml files. * Text sections now have at least the number of entries specified in the appropriate XML file, even if text is loaded from a file without those entries listed. * Corrected number of entries for Diary of Nanai and Wyuvle.
FFTorgASM: * Moving ASM blocks also updates loads/stores and address references!
ASM Encoder/Decoder: * No longer flags load delay on writeback registers.
Those hacks rewrite that routine in different ways, so they are not compatible. There's no way to get around that by moving anything (indeed, there is nothing to move).
(Writing only to free space would be useless because the new code or data would never be referenced by the game. Other changes are needed to change the behavior of the game. Some hacks don't need or use free space at all.)
I'm releasing another version of my XML (and Include files), including the Unit bench hack (10 extra unit slots)! It's attached to the original post in this thread (direct download).
This update includes the Now Loading routine rewrite, a patch that can expand load and save data, and the Unit bench hack (which includes the former). This version of my .XML also comes with (and requires) the latest FFTPatcher suite 0.493, currently available here.
EDIT - Uploaded new version of XML to fix problem with circle menu regarding the bench hack. EDIT - Uploaded new version of XML to add the option to change the checksum end block for the Expand Load and Save Data and Unit Bench hacks. Changing 3C to 40 (hexadecimal values) will cause saves made without the patch not to load! EDIT - Uploaded new version of XML to fix issues regarding Tutorials.
EDIT - Uploaded new version of XML to fix an issue with the Speed shortens Ability CT patch where AI routines were unaware of the CT change.
FFTorgASM: * Added and modified some patch XMLs (Dokurider.xml added). * Fixed issues with Free Space viewer and Conflict Checker. * "Complete!" message no longer appears when Canceling an action. * Now supports <Include> tags with a "patch" attribute to include another patch (by name). * Reload button now reloads the currently selected file. Select All in the file list before pressing Reload to reload all the files.
This also includes the latest version of my XML file (including the unit bench hack). EDIT - Updated attachment to include latest fix for bench hack.
# ROUTINE: Write block # Writes a block corresponding to a graphic. # Parameters: # a0 = Base pointer for block # a1 = Top Y Position (Screen) # a2 = Left X Position (Screen) # a3 = Bottom Y Position (Screen) # t0 = Right X Position (Screen) # t1 = Top Y Position (Bitmap) # t2 = Left X Position (Bitmap) # t3 = Bottom Y Position (Bitmap) # t4 = Right X Position (Bitmap) write_block: sh a1, 10(a0) sh a1, 18(a0) sh a2, 8(a0) sh a2, 24(a0) sh a3, 26(a0) sh a3, 34(a0) sh t0, 16(a0) sh t0, 32(a0) sb t1, 13(a0) sb t1, 21(a0) sb t2, 12(a0) sb t4, 20(a0) sb t2, 28(a0) sb t3, 29(a0) sb t4, 36(a0) jr ra sb t3, 37(a0)
# ROUTINE: Copy words # Word-aligned memcpy. Size must be multiple of 4. # Parameters: # a0 = dest, a1 = src, a2 = size copy_words: beq a2, zero, copy_words_end nop lw t0, 0(a1) addiu a2, a2, -4 sw t0, 0(a0) addiu a0, a0, 4 j copy_words addiu a1, a1, 4 copy_words_end: jr ra nop </Location> <Variable name="Color Red Value" file="SCUS_942_21" offset="40C24" offsetMode="RAM" bytes="1" default="80" /> <Variable name="Color Green Value" file="SCUS_942_21" offset="40C28" offsetMode="RAM" bytes="1" default="80" /> <Variable name="Color Blue Value" file="SCUS_942_21" offset="40C2C" offsetMode="RAM" bytes="1" default="80" /> </Patch>
Hmm. It was counting variables wrong. A simple fix, but that's a pretty fundamental thing that blocks testing, so it's going to require another beta version. Here it is, attached (Beta v2). This also includes ctrl + mouse wheel functionality for Shishi zoom and the problem with the cut-off Shishi text about duplicate sprites should also be fixed.
I'm now ready to release the FFTPatcher .493 beta! This contains a LOT of new features and fixes and is probably the biggest release I've done!
Special thanks to the following for their contributions which helped make this release possible (as well as others!):
Raijinili: Feature requests (including ENTD unit table changes and the concept for View Stats), convenience feature ideas, labeling fixes, team color research, etc. Xifanie: Reference data, Gameshark conditionals, FFTText Editor concepts (including Altima font), Ideas around consolidating/repointing duplicate entries, etc. Elric: Ideas for improving several of the tools, including FFTPatcher defaults, separating the two UNIT/WLDFACE entries, fixing Proposition text, changing around Shishi sections, and adding functionality to Shishi RetroTypes: Consolidating patch XMLs, ideas for Shishi features (including Zoom and other images entry numbers), discussions about labeling Raven: Ideas around consolidating Item Attributes and Inflict Status, General ideas, labeling discussions Choto: Effect notes FFMaster: Idea about supporting more pseudoinstructions with non-specified source operand for ALU commands Jumza: Team color information Emmy: Information about FFTPatcher labeling, especially in the Propositions section cadence: Idea for showing information about Item Attributes and Inflict Status, and pointing out some ASM hacks
Here's my latest version of the FFTPatcher suite including a version of Shishi that can edit the extra palettes in WLDFACE.BIN. The new entries are just added at the end of the list. They're annoyingly arranged in the file, so if modifying one of these entries, both the original and new entries should be updated.
I also separated out the XML files that define what goes in the Other Images section so that they can be updated without needing to recompile the Shishi EXE.
There are also a few convenience changes to the ASM patcher added in here.
* In the Other Images section, WLDFACE.BIN now has extra sections for units with extra palettes. If changing one of these units, both the original and new entries should be changed. * The PSXFiles.xml and PSPFiles.xml files that define the entries in the Other Images section are now external files rather than being compiled into the program. This enables custom entries to be added into Shishi by adding them to the appropriate XML file(s)! Just an example... <Section Filename="E173.BIN" Filesize="48304"> <PalettedImage8bpp> <Name>Night Sword</Name> <Width>128</Width> <Height>256</Height> <Sector>EFFECT_E173_BIN</Sector> <ColorDepth>_16bit</ColorDepth> <PalettePosition> <Offset>14508</Offset> <Length>512</Length> </PalettePosition> <Position> <Offset>15536</Offset> <Length>32768</Length> </Position> </PalettedImage8bpp> </Section>
* ASM checker no longer shows a warning if a stack pointer offset is not a multiple of 8 (but will if the offset is not a multiple of 4). * Multiple offsets can now be specified in one Location tag using comma separated values. Example: <Location file="EFFECT_E137_BIN" offset="AAB,923,E7F,B6F,C33,9E7,CF7,DBB,85F,10CB,F43" mode="DATA"> 02 </Location>
I'd just like to point out that the Learn with JP flag is only for whether or not the player can spend JP to learn the skill from the formation screen (which is why the flag name has "(Player)" next to it). I don't believe the game even checks it when generating units from ENTD.
Neither one of those flags should affect whether generated units learn abilities...
The files are ENTD1.ENT through ENTD4.ENT in the BATTLE directory of the disc image. Only the current ENTD entry is kept in RAM for any length of time (which is why GS codes for them can't really be generated, at least without a ton of conditionals).
I think the codes starting with 7 are conditional codes, although I don't know if that's proper form for the Gameshark. It should probably be D instead of 7. So essentially, if the value at 0x14E61C == 0xF400, run the next code. This is probably a test to see if BATTLE.BIN is loaded (and that's the binary file you're looking for).
Glancing at the Data/Table locations page, here's the memory range being edited: 801b63f0 - Ability Effect (2 bytes each, 0x1c6 total)
Use an execute breakpoint, not a memory read breakpoint. The former breaks when the instruction at that address is executed; the latter breaks when the value from that RAM location is read (by a different instruction somewhere).
You can hit breakpoints in the formation screen just fine. It also doesn't make sense that the breakpoint would fire after BATTLE.BIN is loaded because that should overwrite the breakpoint (due to the way pSX handles execute breakpoints). Are you sure you have the address right? Your screenshot shows no breakpoint...
You would have more success asking more specific questions...
"What operations do what" and "how to look for specific things" doesn't exactly give much to go on. What specific things? The location of party data in RAM? The location of the subroutine that levels a unit up in the game code? For the PSP version, we don't have much of that mapped out. That means this will be something of a pioneering effort, and you'll need to use a debugger. You were already, seemingly, on the right track with that, using PPSSPP. CWCheat codes might also give you a clue as to where certain values are in RAM (and those can be generated with FFTPatcher). There are also a few relevant threads in the PSP hacking section. I would think you would have at least looked at this one.
And what do you mean by "operations"? That does read like you mean low-level instructions, as in arithmetic/logical operations. If that's not it, what do you actually mean? Again, we don't have most of the subroutines mapped out for the PSP version, at least as of yet...
The PSP CPU is called Allegrex. The architecture it uses is MIPS32 release 2 (32 bit), and it also has some custom instructions/encodings.
When I was adding the PSP instructions into MassHexASM/LEDecoder, I was able to look up most of the instructions in the general MIPS32r2 documentation, and I found the rest in the source code of a PSP emulator.