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.

* 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.

* 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.

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)?

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?

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?

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).

(...)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.

That's a really smart one! Good job! Scanning for pattern and finding addresses dynamically) is going to work in most cases on different versions and emulators (There are some less popular emulator there, but pcsx2 is the best one ATM).

IIRC, model is determined (other than unique weapons like ultimates and Brotherhood) by a hierarchical combinations of attributes on the weapon.

The actual base model isn't determined like this (or well it is upon creation / adding more attributes in-game but it doesn't repeatedly fetch its model like this; once the weapon is created this data is stored along with it and can be changed).

Weapon models for other characters can be equipped. For obvious reasons they may look wrong when held by another character than they were intended for though.

Here's another one... the model ID of the weapon also seems to determine what hit animation is played upon using it.

This is a Flame Sword with the Pupu model. The flames effect of the sword is applied but the model remains the same.

A buster sword model exists, but it seems to be in an unfinished state. It has no attachment points so it doesn't display any effects if coupled with an elemental strike ability (visiby at least) and the game gets stuck in an infinite loop if attacking with it, perhaps due to there being no associated on-hit animation. Using skills / items with it equipped works however.

This data is even stored in the save file when saving the game and can be changed by fuzzymillipede's FFXED.The model "effect" is determined by whether it has any of the elemental strike atttributes like NFITC1 suggested however and I haven't been able to find anywhere to change this. What probably happens is that the attributes are checked when loading a battle and the respective effect is loaded. I was thinking that you could maybe detect this battle transition and change an attribute to whatever gives you the desired effect and then change it back as soon as the controllable part of the battle begins, but it seems that all weapon attributes are copied somewhere else when loading the battle so changing the attributes associated with an equipped weapon upon loading will for example make it have Fire Strike for the entire duration of the current battle. Another problem occurs if you were to switch weapons in battle.

That's a really smart one! Good job! Scanning for pattern and finding addresses dynamically) is going to work in most cases on different versions and emulators (There are some less popular emulator there, but pcsx2 is the best one ATM).

Haha thanks, I thought it would be pretty much the standard to do it like that. As you say, it makes sense to assume data is relative to each other in different versions of the same game unless it has undergone serious editing and / or your patterns happen to be part of what is indeed altered.Just out of interest, could you name these less popular emulators?The two I've found are PS2EMU, which flat out refuses to start for me (granted I didn't bother mucking around very much with it so it probably can be gotten to work) and NeutrinoSX2 that even advertises itself as being "a work in progress that currently can't run any commercial games".

The actual base model isn't determined like this (or well it is upon creation / adding more attributes in-game but it doesn't repeatedly fetch its model like this; once the weapon is created this data is stored along with it and can be changed).

n00b question: if this is a memory editor, won't changes revert on save load?

An in-game load perhaps. But a quicksave/quickload wouldn't undo changes.

I just tried it and it does in fact not seem to reset within the game at all, not by loading after a game over or through a soft reset. The data seems to be loaded into a separate RAM area at startup and then just kept there. It is naturally possible that certain cutscenes / FMV's may push it out of memory and the game will then reload it, this seemed to be a thing in earlier PSX Final Fantasies due to memory limitations, but I haven't found any evidence pointing to this so far.Again, my main idea with this was to figure out desirable skill changes and then use a Action Replay / GameShark-style device to achieve these changes on an actual PS2, in which case the changed values would continously overwrite whatever might be set by the game, ie. "frozen" using Cheat Engine names.

Kind of but not quite. Judging by the save map there seems to be a list of 200 (or possibly 255, but only 200 are stored in a save file anyway from the looks of it) "equipments". This includes both weapons and armours. Each piece of equipment has a boolean flag stating whether that slot in the equipment list is occupied or not, a name (probably through another offset into a string table as with the skills), the id of the character that can equip it, another id that is only set to the respective character id if this particular piece of equipment is currently equipped by them, a damage formula, attack power and critical hit rate, up to four auto-abilities and a model id. Since the model id's used seems to begin around 16000+ it is quite likely that other models can be loaded and used as weapons / shields as well. The game crashes when changing this to an invalid id however so it would probably be a slow process to try to map any possible other values by hand.The actual vertex data is not stored with the equipment declaration. It is also possible that there's some additional data for each piece of equipment in the game's memory at runtime that doesn't have to be stored to the savefile.

Version 0.2 is available to download from the opening post.New features include the possibility to edit enemy-exclusive skills and some saving/loading functionality.There's also a "reset" option under the File menu; this will attempt to set all skills to their default values. Note that the default values were sampled from the PAL version and so it's possible that there might be some slight changes against other versions of the game.

I've also been working on altering the damage limits (9999 and 99999 respectively) but this isn't available as an option yet as the memory where this is stored seems to be dynamically selected. There also aren't any static memory patterns preceeding this data and it isn't even put into memory until you enter a battle after loading a save in-game. After that these values remain at a constant memory address however.

Ouch, yeah it has fixed dimensions on the window... I don't suppose you are able to increase your screen resolution?You can try to move the window so that it goes beyond the top of your screen, though that may not work. The process list is just below what is visible in your screenshot. Another hack is to hide the taskbar (or simply just kill your explorer.exe process; that will remove it until you restart it); that should allow you to select an emulator process and after that you shouldn't need to be that far down unless you want to read the output log.

Preliminary support for the Steam version is now available in version 0.3 of Ronso.See the opening post for more details and a download link.

Interestingly it appears that some of the skill data has been changed for the HD Remaster, perhaps as some type of rebalancing? I haven't managed to play this version beyond Besaid yet so will have to see if it plays out differently later on I've also identified misc. flag #22 as determining whether the damage formula and power value of the skill itself is used or not. When this flag is set, the actor's equipped weapon will be consulted for the damage formula and attack power instead. This is used by most physical attacks and skills in the game (breaks, the distil abilities, some of Kimahri's overdrives, etc.).I also may have found out a value that places the skill in a certain category; I accidentally moved Dark Attack from "Skills" to "Black Magic" earlier, so will have to dig into that a bit.

@rucky: This latest release will also allow you to resize the window.

Edit: How annoying; I just found out that the enemy skill table pattern matching wasn't 100% for the Steam version (a few bytes would switch between different runs). Fixed that and updated the downloadable archive. Hopefully there won't be any more such surprises now...

A new version is available containing a bugfix for damage formulas not getting properly updated when changed through the drop-down list.Also found the purpose of a few more bytes / bit flags which now have proper descriptions in the UI. See the opening post for details.

A new version is available containing a bugfix for damage formulas not getting properly updated when changed through the drop-down list.Also found the purpose of a few more bytes / bit flags which now have proper descriptions in the UI. See the opening post for details.

thank you , with your skill you could also solve another problem of this game : yojimbo , the magus sisters and their crazy way to be controlled , it could be so nice if they can be controlled directly :O

Apologies for necroposting, but no one considering taking the mantle for this?

I have some new ideas for a more in-depth kind of editor actually (as well as have managed to figure out a working way to alter enemy data of the Steam version at load time), just not the time needed to realize it. Hopefully one day...

I have some new ideas for a more in-depth kind of editor actually (as well as have managed to figure out a working way to alter enemy data of the Steam version at load time), just not the time needed to realize it. Hopefully one day...