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 - Husbjörn

Pages: [1] 2
Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2021-05-27 08:57:30 »
Alas, after 2 years, guess this is going nowhere.

Sorry for the late reply. To summarize, Ronso is probably not going anywhere further no, however I have (slowly, whenever I have some spare time to spend on it) made some further reverse engineering of the Steam version of the game and I have a pretty concrete idea of a kind of modding suite I'd like to make from it. I don't want to draw any undue attention to it until I'm 100% sure I can deliver on it (both in terms of stable functionality and actually being able to get it fully put together and released) though.
But yeah, I still have my interest in FFX and am at least intending to make something of it.

@Lyrithus: Interesting finds!
If it can be repacked without the need for any (unknown) encryption that should definitely be a possibility. Keep in mind that the data on disk and in memory may not necessarily be laid out in the same order however. Personally I think that direct memory access is better for trying out / experimenting with things. It can also offer greater capabilities as you don't necessarily have to keep within the limits of the game's expected data (ie. maybe enemy AI only has 16Kb of instruction memory alloted to it, modifying stat growth for character A may also affect character B and so on). But once you have a concrete idea of what you want to do (and assuming it is possible within the game's confines), then making a persistent file-based mod would of course have its clear advantages. :)

WIP / Re: FF8: Concept of a new magic system
« on: 2020-01-16 21:38:02 »
Sounds pretty good.
One thing I've been thinking about doing with regards to magic in FF8 is to limit the amount you can draw from enemies to say 50, draw points to 75 and then swap the decrementing counter on usage so that you'll get one more of each spell each time you use it, thus making it so that they in fact get stronger the more you use them and you have to actually use them to max out their potential.

General Discussion / Re: FFVIII Remastered
« on: 2019-09-07 11:04:51 »
I tried IDA, IDA+scyllaHyde, OllyDgb and CE debugger- I'm getting 0x400000f1 (STATUS_WX86_BREAKPOINT) on all threads and the game is immidiately killed. Happens only for core game code
I can confirm that this happens for data breakpoints as well. Patching IsDebuggerPresent / CheckRemoteDebuggerPresent / ExitProcess / TerminateProcess / GetThreadContext etc. seems to yield no hits. Furthermore the game refuses to start without Steam and dies if it is killed, however suspending all Steam processes appears to not matter so it doesn't seem dependent on any realtime communication.

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2019-08-12 12:28:32 »
Thanks for the appreciation, and sorry for my tardiness in replying.

My favorite thing was definitely the max health doubling, for sure. I'm not wrong in thinking that there's no other enemy that does something like that, right?
Not as far as I'm aware no  :)

It would probably be possible to either make the <Element>-proof effects only account for say 75% of the total damage dealt, though a nicer thing would be to make it so that certain spells can override elemental resistances in part. I can think of at least one way to accomplish this, though it would be a bit prohibitively involved. A better way may be to have a per-skill modifier that is applied to the elemental resistance value during damage calculations.

Any news on this?
Not really no, as said it's still just a proof of concept and my free time is sadly limited :-\
I think I know the general direction I would like to take things in though.

Hello! I'm fuzzymillipede, another FFX modder of sorts. This is awesome, excellent work Husbjörn!
Oh hello, that's really cool to hear from you! I remember playing around with your memory card item buffer overflow glitch back on my PS2 back in the good old days (as well as the other things tweakable by FFXED), thanks a lot for making the tools and information that you did available :D

I'm wondering if you have considered (or already implemented) an import/export system, where all the edits in your editor can be imported from or exported to a text file.
This is already sort of supported. You can right-click on a skill in the list to copy its data, whereafter you can either paste it over another skill to use as a base or compare different data values between a copied and a selected skill.
You can also export/import individual skills, as well as save/load the entire skill + string table. The saved files can of course be shared and imported by others.
There's no issue with hot-patching the game (talking about the Steam version now only of course); the skill table is in fact pretty small in memory. The same thing would go for fiend data (which uses a different approach alltogether but I'm imagining asynchronous transfers should be perfectly achievable if you want to update / change things at runtime). And indeed, no physical game file modification will be necessary.

I really appreciate your offer to help out with this project. Again I'm rather swamped these days but once my schedule clears up perhaps I could shoot you a message? If you're not commonly around here perhaps you could PM me an e-mail address?
It was nice to hear from you regardless!

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2019-07-07 16:55:03 »
I put together a small (or perhaps rather quite lengthy...) proof of concept video of modified enemies here.
All fiends in that battle have had some of their stats altered, the Yellow Element has an entirely new, home-made AI of sorts (as well as have been made immune to Silence, because that would be way too simple)  ;)

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2019-03-25 20:20:52 »
Oh god please yes. This is all I've ever wanted. Though more in depth skill editing is amazing too. As sad as it is, every 6 months to a year or so (without logging in) I've hopelessly checked this thread and the steam FFX-HD board just in case someone released such an editor. I shall continue to wait, forever if need be.
Ouf, why thank you for your keen interest! ^^`

It's mainly just about thinking outside the box with what I have in mind. That said, I'd like to put it on my resume / list of good deeds someday so I'd prefer to not give up my idea to someone else at this point in time.

If there's anything I can do to help at all (I realize you're not actually developing it right now, but if you ever do start fully to realize it), I'll do it.
There is some pretty repetitious manual data collection that would need to be done at some point if you're truly that passionate about it.
I'd have to sit down and make sure that things check out before setting you up with that if so though, so that it doesn't turn out that it all has to be done over again further down the road because some pieces were missing.

Either way, thank you for making the skill editor period.
You're very welcome; I'm glad to hear there are people out there who enjoy it. :)

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2019-03-16 22:33:27 »
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...

General Discussion / Re: Where is this played?
« on: 2016-06-05 18:51:12 »
Switching tracks for looping is very strange behavior for sequenced music. I mean, modern games with streaming music like Sonic Generations do that, because most streaming music formats do not have good looping support, but sequenced music can easily have a custom loop point defined, and in fact several FF7 and FF8 songs loop back to a point near the beginning rather than right at it.
Indeed, but he stated this wasn't a sequenced track but rather stored as one large audio file, unless I misunderstood.
If it's a sequence then it may very well just be some leftover thing that never was used; it would take much less space so maybe it would have been a bigger deal to remove it and relocate stuff following it than to just leave it be?

General Discussion / Re: Where is this played?
« on: 2016-06-05 16:04:46 »
IF the third track is the same as second track with only about 7 second intro then I highly suspect that this second track is only used after the first intro and after the second track has played it loops third track indefinitely.
This would be my guess as well. It makes no sense to loop a track with a distinct intro.

General Discussion / Re: Where is this played?
« on: 2016-06-05 13:59:09 »
It isn't that.  As I said - that is a separate track on the PSX (it has an intro and then the start of the music as one track).  You can see this by the extracted PSFs.   You can also tell because the music fades into it with that one you sent - the track I sent has no overlapping fade.
I would say that after playing through that one once then it switches to this one so as to not repeat the intro when looping.
However, the PSX FF games used their own midi-like system which sequenced individually sampled instrument notes as far as I know. Which would make this kind of thing redundant.
At the same time you're saying your track was extracted from the PSX game, which brings this into question as well. Is the track stored as a real, stand-alone audio track and not as a sequence of other, more basic audio tracks (ie. instrument / sound effect samples)?

I have no plans for controlling creatures in FFX at this stage. I haven't looked at it and have no idea if it will even be possible.
I haven't looked too deply into it but it would appear that monster data is loaded from disk at the start of each battle and not held in a static memory area. It might be possible to find a static pointer and alter it as it is being loaded however, but it seems unfortunately tricky.

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2016-05-20 18:05:32 »
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.

Both the PS2 and Steam versions of FFX use the same character encoding.
The following is C# code for setting up a pair of encode / decode maps that translates characters between FFX's charset and Unicode:
Code: [Select]
// Symbols
EncodeMap.Add((char)0, 0x00);             // Null character

// NOTE: 0x03 seems to be used as a newline character. We need to handle this separatedly since it needs to be represented
//       by two characters (\r\n) in unicode however.

EncodeMap.Add(' ', 0x3a);
EncodeMap.Add('!', 0x3b);
EncodeMap.Add('\"', 0x3c);
EncodeMap.Add('#', 0x3d);
EncodeMap.Add('$', 0x3e);
EncodeMap.Add('%', 0x3f);
EncodeMap.Add('&', 0x40);
EncodeMap.Add('\'', 0x41);
EncodeMap.Add('(', 0x42);
EncodeMap.Add(')', 0x43);
EncodeMap.Add('*', 0x44);
EncodeMap.Add('+', 0x45);
EncodeMap.Add(',', 0x46);
EncodeMap.Add('-', 0x47);
EncodeMap.Add('.', 0x48);
EncodeMap.Add('/', 0x49);
EncodeMap.Add(':', 0x4a);
EncodeMap.Add(';', 0x4b);
EncodeMap.Add('<', 0x4c);
EncodeMap.Add('=', 0x4d);
EncodeMap.Add('>', 0x4e);
EncodeMap.Add('?', 0x4f);

EncodeMap.Add('[', 0x6a);
EncodeMap.Add('\\', 0x6b);
EncodeMap.Add(']', 0x6c);
EncodeMap.Add((char)(0x0361), 0x6d);      //  ͡ , could maybe be replaced with '^'? «»
EncodeMap.Add('_', 0x6e);                 // TODO: Replace with a normal underscore if no other (shorter) such is found in the game font
EncodeMap.Add('`', 0x6f);

EncodeMap.Add('{', 0x8a);
EncodeMap.Add('|', 0x8b);
EncodeMap.Add('}', 0x8c);
EncodeMap.Add('~', 0x8d);                 // Fullwidth tilde
EncodeMap.Add('•', 0x8e);
EncodeMap.Add('【', 0x8f);
EncodeMap.Add('】', 0x90);
EncodeMap.Add('♪', 0x91);
EncodeMap.Add('♥', 0x92);

EncodeMap.Add('“', 0x94);
EncodeMap.Add('”', 0x95);
EncodeMap.Add('—', 0x96);

EncodeMap.Add('¡', 0x98);
EncodeMap.Add('↑', 0x99);
EncodeMap.Add('↓', 0x9a);
EncodeMap.Add('←', 0x9b);
EncodeMap.Add('→', 0x9c);
EncodeMap.Add('̈', 0x9d);                 // TODO: Consider replacing with '¨' if this isn't represented by some other character code
EncodeMap.Add('«', 0x9e);
EncodeMap.Add('°', 0x9f);

EncodeMap.Add('»', 0xa1);
EncodeMap.Add('¿', 0xa2);
EncodeMap.Add('À', 0xa3);
EncodeMap.Add('Á', 0xa4);
EncodeMap.Add('Â', 0xa5);
EncodeMap.Add('Ä', 0xa6);
EncodeMap.Add('Ç', 0xa7);
EncodeMap.Add('È', 0xa8);
EncodeMap.Add('É', 0xa9);
EncodeMap.Add('Ê', 0xaa);
EncodeMap.Add('Ë', 0xab);
EncodeMap.Add('Ì', 0xac);
EncodeMap.Add('Í', 0xad);
EncodeMap.Add('Î', 0xae);
EncodeMap.Add('Ï', 0xaf);
EncodeMap.Add('Ñ', 0xb0);
EncodeMap.Add('Ò', 0xb1);
EncodeMap.Add('Ó', 0xb2);
EncodeMap.Add('Ô', 0xb3);
EncodeMap.Add('Ö', 0xb4);
EncodeMap.Add('Ù', 0xb5);
EncodeMap.Add('Ú', 0xb6);
EncodeMap.Add('Û', 0xb7);
EncodeMap.Add('Ü', 0xb8);
EncodeMap.Add('ß', 0xb9);
EncodeMap.Add('à', 0xba);
EncodeMap.Add('á', 0xbb);
EncodeMap.Add('â', 0xbc);
EncodeMap.Add('ä', 0xbd);
EncodeMap.Add('ç', 0xbe);
EncodeMap.Add('è', 0xbf);
EncodeMap.Add('é', 0xc0);
EncodeMap.Add('ê', 0xc1);
EncodeMap.Add('ë', 0xc2);
EncodeMap.Add('ì', 0xc3);
EncodeMap.Add('í', 0xc4);
EncodeMap.Add('î', 0xc5);
EncodeMap.Add('ï', 0xc6);
EncodeMap.Add('ñ', 0xc7);
EncodeMap.Add('ò', 0xc8);
EncodeMap.Add('ó', 0xc9);
EncodeMap.Add('ô', 0xca);
EncodeMap.Add('ö', 0xcb);
EncodeMap.Add('ù', 0xcc);
EncodeMap.Add('ú', 0xcd);
EncodeMap.Add('û', 0xce);
EncodeMap.Add('ü', 0xcf);
EncodeMap.Add(',', 0xd0);   // This appears to be another comma, positioned about one pixel higher vertically than the 0x46 one. We'll use a fullwidth one here.
EncodeMap.Add('ƒ', 0xd1);   // Not sure whether this is supposed to be a musical forte character or a mathematical function "f"; the former can't be represented
EncodeMap.Add('„', 0xd2);
EncodeMap.Add('…', 0xd3);
EncodeMap.Add('‘', 0xd4);
EncodeMap.Add('’', 0xd5);
EncodeMap.Add('▪', 0xd6);   // Not really what the in-game symbol looks like but it'll do I guess
EncodeMap.Add('–', 0xd7);   // Shorter dash than 0x96, but not a hyphen?
EncodeMap.Add('~', 0xd8);   // "Normal" tilde, as opposed to the fullwidth one at 0x8d
EncodeMap.Add('™', 0xd9);

// NOTE: 0x93, 0x97, 0xa0 and 0xda seem to be unused and will print nothing if used in game text

EncodeMap.Add('›', 0xdb);
EncodeMap.Add('§', 0xdc);
EncodeMap.Add('©', 0xdd);
EncodeMap.Add('ₐ', 0xde);   // This is actually a superscripted 'a' in the game's font, but this is the closest there seems to be in the 16-bit unicode charset
EncodeMap.Add('®', 0xdf);
EncodeMap.Add('±', 0xe0);
EncodeMap.Add('²', 0xe1);
EncodeMap.Add('³', 0xe2);
EncodeMap.Add('¼', 0xe3);
EncodeMap.Add('½', 0xe4);
EncodeMap.Add('¾', 0xe5);
EncodeMap.Add('×', 0xe6);
EncodeMap.Add('÷', 0xe7);
EncodeMap.Add('‹', 0xe8);
EncodeMap.Add('⋯', 0xe9);   // Midline horizontal ellipsis as opposed to the baseline version at character 0xd3

// The characters in-between do not print anything and are presumably either not valid characters or act as
// placeholders for character names and the like in certain contexts.

EncodeMap.Add('\t', 0xfc);  // Wide space or tab, not sure which; all the remaining characters up to 0xff appears this way when typed so probably not valid

// Create reverse mapping for the symbols in the encode map
foreach (char c in EncodeMap.Keys)
    DecodeMap.Add(EncodeMap[c], c);

// Digits
for (int n = 0; n < 10; n++) {
    EncodeMap.Add((char)(48 + n), (byte)(0x30 + n));
    DecodeMap.Add((byte)(0x30 + n), (char)(48 + n));

// Letters
for (int n = 0; n < 26; n++) {
    char uc = (char)(65 + n);             // Uppercase
    char lc = (char)(97 + n);             // Lowercase
    byte ub = (byte)(0x50 + n);
    byte lb = (byte)(0x70 + n);
    EncodeMap.Add(uc, ub);
    DecodeMap.Add(ub, uc);
    EncodeMap.Add(lc, lb);
    DecodeMap.Add(lb, lc);

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.3.0.0)
« on: 2016-05-16 15:31:44 »
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...

Make a proxy version of any of these dlls and then apply your patch in memory during dllmain entry point.
That is what I'm planning to do yes, but the point I'm stuck at is how to access the actual program memory.
I can imagine what I need to do is find a function pointer to the entry point of the executable and then work with offsets from there, but how would I do this? GetProcAddress won't work because the target is an executable that doesn't export any named functions (or is it possible still? The documentation says ordinals, ie. (char*)1 can only be used with dll's though, but maybe there is some other function to get this pointer?).

Edit: ah, it was too simple x)
For anyone wondering, the HMODULE of the base program is also a pointer to the executable data, which can be read but not written to normally. Using WriteProcessMemory, you can write to it as well. So problem solved :)

I have recently managed to manipulate a program to set the upper bound of a for-loop to a desirable value through de- and reassembling it.
However, due to reasons I'm not allowed to modify the physical executable file (or rather, I wouldn't be able to release a modified version of it legally). I was therefore wondering what my options are to achieving this patching on the fly? The actual instruction in question is a MOV operation where I need to modify the second, literal argument.
ReadProcessMemory is unable to view this value (presumably because it isn't stored on the heap?) so that won't work. It feels like there should be some way to achieve this.

What I have at my disposal is access to a dll that is loaded and used by the application in question, so I should hopefully have the required access rights. The program in question is furthermore a Win32 application that is always run as an administrator.
Any ideas or suggested reading?  ???

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.2.0.0)
« on: 2015-09-05 17:02:49 »
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.

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.2.0.0)
« on: 2015-08-16 16:37:15 »
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.

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.1.0.0)
« on: 2015-08-11 19:32:59 »
I think so too. And yet, it's pretty amazing what they managed to squeeze into a mere 32Mb... :o
(Not to mention 2Mb before then!)

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.1.0.0)
« on: 2015-08-10 17:15:55 »
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.

so, each weapon model has the appearance for each name, like

Caladboung = has configured to create model id 0x07 inside the weapon model (data, vertex, meshes)? this is it?
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.

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.1.0.0)
« on: 2015-08-08 10:41:56 »
Thanks :)

...could you add weapon effect, ID, model and attributes too ;)
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".

Misc. Tools / Re: [FFX] Skill editor - Ronso (v0.1.0.0)
« on: 2015-08-06 21:19:48 »
Thanks DLPB :)

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

Misc. Tools / [FFX] Skill editor - Ronso (v0.3.1.0)
« on: 2015-08-06 14:08:44 »
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: [Select]
* 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.

2016-05-16 - New features in version 0.3:
Code: [Select]
* 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.

2015-08-16 - New features in version 0.2:
Code: [Select]
* 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)?

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

I beliebe the FFWiki's abilities list was mostly adapted from Siniroth X's guide, which may give more information.
Sweet, I wasn't aware of that, seems like quite an interesting read!

When I said "animation", I was more thinking of "animation sequencing". It's not a structure that details a model animation, but it's a sequencing code...
Ah right. Yes, there may very well be something like that somewhere. If I were to guess, I'd assume it to be stored in a separate table somewhere in memory with only an offset from the beginning of that table stored in with the ability data, if they are indeed connected at all. Much like how player-usable abilities are kept in a separate location from enemy-exclusive abilities, where the latter has its name offsets into a different string table than the first, the static cameras may then be caused by the given offset, that points to a valid animation sequence in the enemy-exclusive table, having no corresponding sequence in the character-accessible memory block. Maybe. Though a crash would probably be the more likely outcome than just ignoring camera animations then.
I think I'll investigate by trying to replace one enemy-exclusive skill's data with another and see if that makes any difference or if it'll be the same result still. Heave and Meteor might be good candidates for a swap since they're both unique to the behemoth enemy.

Maybe that's what is inside that 96-byte structure, no?
No, the 96-byte structure contains the actual skill data.
I haven't managed to get it all figured out yet but when / if I do I guess I'll post a description of it.
It begins with a 4-byte ID that seems to vary incrementally for "listed" abilities such as white magic and black magic, but is set to zero for most other abilities ("Attack", "Defend", "Item", various overdrives, trigger commands, etc.) Following that is a 2-byte offset into the afforementioned string table used to store names and descriptions for player-accessible data. This offset is to the beginning of the ability's name string, then follows 6 unknown bytes and then there's another 2-byte offset corresponding to the description of the ability. Another 6 bytes follows, then there's a pair of two 2-byte values where one represents the visual animation used by the ability on land and the other under water. Then there's another unknown byte and then one that seems related to what casting animation the user of the ability will perform (physical attack, item useage, spell casting, or one of several special animations associated with the issuing actor). Four more unknown bytes follow but then I have the most of them figured out (about half of the skill data is made up of individual infliction rates and durations of all status effects present in the game).
So if anything, I'm guessing one of those unknown values might be an offset into another table containing such an animation sequence as you're describing.

Thank you for your input.
I'm aware of FFXED and how it allows you to use skills presumably through some overflow bug in the game if you set item id's beyond what is normally obtainable within the game itself.
I cannot find said videos at this time and it's been a while since I saw them so maybe this was indeed what was used there, though I believe what was actually done was modifying some black magic spell and not done through an item.
Regardless, this Final Fantasy Wikia page lists a bunch of enemy skills with correct parameters:
Granted most of that is obtainable from just observing their effects in the game, but the power and accuracy values are interesting and do indeed match the enemy skills that reside in the game's data so they have probably been retrieved from there one way or another. The following quote from that page also suggests this:
Abilities listed in italics are not named in-game, but are named as such in the coding.

Upon inspection, it appears that both shared spells as you call them, and enemy-specific abilities are stored in the very same 96-byte structure (this is in memory upon running by the way so the way it is stored in the game files may be different). While roughly interchangeable there still appears to be something else influencing the skills however; for example I replaced all the bytes of the enemy skill "Meteor" with a byte-for-byte copy of the shared spell "Flare" and killed a Behemot King. He casts this skill as a final attack, but he still uses his "final attack" casting animation instead of his normal spell casting animation (which is normally used for Flare, which this monster can also use normally). Furthermore, Flare is a single-target spell (as denoted, and changeable, from its skill data) but Meteor hits all targets, as does Flare when used as his final attack. The camera animation likewise seems different to that used when casting Flare normally, but it doesn't make the camera look to the heavens as is done for the Meteor animation. As such there does indeed seem to be some other component at play here...

If I understood well, the spells that are normally used by enemies on the party has always a camera centered on the party when casting (even when it's cast on enemies through hacking)? Or is it the other way?
Not quite, I have recorded a video showcasing the results here:
There definately is quite a lot of camera animation in that spell when used "properly" by the behemoth as can be seen at the end of the video, but as you suggest it doesn't do more than show the character casting it and then the camera movement seems to stop there. It might possibly be that the character animation is supposed to tell the camera what to do next, and since there is no such data for the used character animation, it stays where it is until after the spell animation is done. I am not sure how much sense such a system would make though; just imagine all kinds of spells that use the default casting character animation but still moves the camera differently based on the spell. The functionality to do it differently certainly is in there, so then one can wonder why they would bake it into the caster animation in certain cases?

That's for FFIX, though. But I think IX and X are quiet close in terms of data structures. I've already seen some of them in IX and told myself "Ah ! They used the same system for FFX.".
Indeed, it's quite cool how the older games tend to be relatively similar with regards to certain data structures.

Pages: [1] 2