Miscellaneous Forums > Misc. Tools

[FFX] Skill editor - Ronso (v0.3.1.0)

(1/13) > >>

Husbjörn:
Ronso is a skill editor for Final Fantasy X.
As of version 0.3, both emulated PS2 versions of the game and the HD Remaster version released for PC through Steam are supported*.
It works through run-time memory editing and was initially developed as a tool for generating ActionReplay / GameShark / XPloder codes for the PS2. However with the advent of a proper PC version of the game, the application is quite capable of being used as-is and not just as a tool for use with the afforementioned other devices.
As for reliability, the memory regions of interest are identified by scanning for memory patterns that seem to be at constant offsets to the skill and string data. While the Steam version seems a bit trickier with its memory organization than the original PS2 version, I believe that Ronso should now be able to find the skill tables in memory for it too reliably. No guarantees though; I only got my hands on the PC version yesterday at the time of writing this.

The application requires .NET Framework 4.5 and makes use of ReadProcessMemory / WriteProcessMemory, so it will most likely require administrative privileges if you have UAC enabled.
Download Ronso v0.3.1 here.

2016-05-20 - New in version 0.3.1:

--- Code: --- * Fixed a bug where changing the damage calculation wouldn't update the skill table.
 * Found addresses for skill category and icon.
 * Found bit flags for "normal" and "extended" delay status infliction.

--- End code ---

2016-05-16 - New features in version 0.3:

--- Code: ---* Preliminary support for the Steam version of the game.
* Can transfer skill data between emulated PS2 versions and the Steam version of the game.
* The window can now be resized.
* Identified miscellaneous bit flag #22 and added a checkbox for this. If set, the actor's equipped weapon's damage formula and strength will be used instead of the ones specified for the skill itself.

--- End code ---

2015-08-16 - New features in version 0.2:

--- Code: ---* Enemy-exclusive skills can be edited.
* The current settings for all skills can be saved and loaded; upon loading, the memory of the opened emulator process is updated to match what was previously saved.
* Individual skills can also be exported / imported.

--- End code ---

From what I've been able to find out, skill data is stored in a list of 96 bytes per skill (or rather 95 bytes since it appears the 96:th byte is always 0 and might be used as some kind of separator / padding). The current version of Ronso can edit each and everyone of said bytes. About 2/3:rds of the data is known; should you happen to know of / figure out any other values I would be happy to hear about it.


Skill names and descriptions are stored in a separate memory region and are referenced by skills by an offset into this string table.
Ronso allows you to select offsets as well as edit the strings themselves.

There is no clear "end" of the string table data; the skills use 16-bit offsets into it which means they can at most reference a string stored 65535 bytes in, however the actual string data ends long before this (after 13826 bytes in the english PAL version). Because other languages probably having different-length strings, the string table editor allows you to edit up to offset 17408 (0x4400) from the start of the string table, which I assume should definately be enough for any language version. After the strings there is some unknown data that you probably don't want to overwrite with strings, and a bit after that comes scan descriptions for the main characters. Fortunately there are a couple of appropriately named "Extra xx" entries at the end of the string table. There also are a bunch of named skills that never show their name in the actual game that you can replace and use if you so chose, such as all of Wakka's different overdrive shots, complete with descriptions of the "Wakka's personal skill xy" persuasion.

Most editable fields contain a single byte value. These are to be entered as decimal values for everything except status infliction rates, which use hexadecimal values instead. The reason for this is that 0xfe (254) is considered the highest probability value by the game, whereas an infliction rate of 0xff (255) means the status will be inflicted on the opponent regardless of whether it's immune to it. The only player-accessible skill that uses this by default is Zanmato, which forces infliction of the death status on all targets.
By right-clicking a single-byte field, the flag manager will be opened:

This allows you to view and edit a byte value as either a decimal or hexadecimal value as well as a set of bit flags.
This functionality is also available for the "custom byte" field that can be used to access parts of wider values (such as the animations, string offsets or miscellaneous flags) as their individual bytes.

In addition, skill data can be copied by right-clicking the relevant skill in the list on the left. When a skill is copied it can either be pasted over a different skill, or it can have its individual bytes compared to another skill; both of these operations are available from the same right-click menu of the skill list. In the current version (0.2), only byte fields (including the custom one) are compared by the comparison operation, ie. checkboxes, names and wider-bit fields are not compared against each others.

As for the two animation index fields, the first one is the animation to use for skills that are used on land, while the second one is a special animation that is used if the skill is used under water. These can off course both be set to the same animation id.


Finally, I'll list what I know about those fields that have question marks in their descriptions.

* Menu - this appears to be a set of bit flags. If bit 7 is set, the skill becomes usable from the menu. However, it cannot target any player character after selecting it from the menu; something else likely affects this, or possibly it is hardcoded to only work with HP-restoring skills.
* Overdrive - this seems to be the "overdrive cost" of the skill. A value of 20 (0x14) will deplete the entire overdrive gauge while smaller values reduce the overdrive gauge by value/20. Skills that have a non-zero value here will be grayed-out unless the user's overdrive bar is full. The skill will also display the overdrive "cast" animation prior to use if this value is set.
* Byte 48 - this might be the probability to shatter a petrified target given in decimal percents (0..100)?

Also, thanks to ppbirdman for listing the available effect calculation formulas in his Ultimate Companion Guide.

DLPB_:
Nice work!

Maki:
Correct me, if I'm wrong, but isn't the process memory changing regarding emulator and or plugins used? I mean, isn't the memory drastically changing if you use any other software to emulate game? Also, things like that are locked to specific game images. NTSC and PAL version memory addresses can be totally different, am I wrong?

Husbjörn:
Thanks DLPB :)


--- Quote from: MaKiPL on 2015-08-06 20:20:18 ---Correct me, if I'm wrong, but isn't the process memory changing regarding emulator and or plugins used? I mean, isn't the memory drastically changing if you use any other software to emulate game?
--- End quote ---
As far as I know the only actually functional PS2 emulator as of today is PCSX2 so I haven't really given that much thought. Virtual addresses are used which doesn't change between two runs / several instances / etc. of the same emulator at the very least (ie. I'm not accessing actual RAM offsets).
The program takes things like different game images (regions, languages, etc.) into consideration (granted though I only own the UK PAL version so that's all I've tested it with) in that it scans all readable process memory for patterns that seem to be at a static offset to the skill / string data and works from there. If it is started and these patterns are not where they are supposed to in reference to the stored address, it will attempt to rescan the memory for them. If this fails it will tell you so and I would be interested to hear about it so that I can see whether I could do anything about it then.

As for how to convert the addresses to ie. GameShark instructions, all you should need is a known address for that and the corresponding emulator address to calculate the offset between the two (something easy like the total amount of gils is probably a good candidate for this). I do believe at least PSCX2 allocates a single memory block that it uses as if it were the whole work memory of the PS2, so this should probably not be a problem, but don't quote me on that. Things like video / sound memory buffers are clearly of no interest for this application and are likely what will mostly vary depending on your emulator plugins (there's no such thing as a "CPU plugin", only the bios).

gledson999:
congratulation for this nice tool, could you add weapon effect, ID, model and attributes too ;)

Navigation

[0] Message Index

[#] Next page