Final Fantasy Hacktics

I will update the version numbers as features get added.

v0.1 means only the existing formulas that allow evasion will have the evasion toggle.
v0.2 means that all existing formulas will be evadable, if you so flag it.
v0.3 will render my blind/transparent hacks entirely obsolete by rewriting how the AI understands base hit chance.  Doing it this way makes it very easy to make skills that boost/lower accuracy by X%.
v0.37 allows you to set W and C-M-EV.  It also contains Xif's global C-EV hack and my monster C-EV = A-EV hack.
v0.5 allows you to set all the necessary features for virtually any character stat (PA/MA/WP/LVL) or HP/MP% based damage / healing routine into Formula 11.  Incorporates by default a version of the Weapon Strike Fix, the Oil Fix, the Mighty Sword Fix, the HP/MP% DMG cap.
Currently Working On: v0.7 and v0.77, which synchronizes my routines (coded nearly two years apart), adds more optional features (multi-hit) and odd restrictions (katana break, item usage, etc.) from the original Square code, and codes the +Stats and pure % to inflict effect formulas.

Ev Toggle = how to set an attack as taking P/M-EV
Equip EV Explanation = how to set weapons/jobs as having P/M-EV
Instructions = how to set up X / Y / D / O bytes to take their proper values
If you don't understand the latter two, download instructions.rar.  There is a spreadsheet inside (expanded on Choto's original) that will assist with calculation.


Part I (Evasion)





Optional Features





Part II (XA/YA values)
Part III (Multipliers)
Part IV (Special Effects)











Limitations:
1) Drain or Recoil with AoE AND evadable or self-damage or healing creates unintuitive behavior.  In particular, I didn't check the cases where a drain HP attack is cast on self + recoil.
2) 2H and martial arts will apply as long as damage is flagged as physical.  I can make a version where 2H is never applied to physical damage OR a version where 2H only applies to weapon strike / weapon ranged attacks but NOT one where it corresponds only to WP in the formula without serious rewriting of this code's IF / JUMP statements (which is a headache as is).
3) Elemental fixes (to make heal + weak or weak + absorb more intuitive) was not coded because I wanted to get the original Square behavior down first.  More complicated fixes are on the TODO list.
4) Currently conflicts with almost every other ASM hack in terms of Kanji space.  Sorry, will fix later.
5) Hand slot break (break everything in RH, then LH) was not coded, but it's on the TODO list.
6) Does not address the +Stat formulas (that is next) or pure % to cause status formulas.  Also, % to cause damage may display totally wrong accuracies.
7) Does not support formulas taking both physical and magical multipliers, though I probably don't want to do this.
8) Breaks the Steal and EQ Break routines.  Top priority on my TODO list.

Formula:
[(XA1 +/- C) * XA2 * (D + 1) / 128]
OR
Accuracy = (XA1 + C) * (Br or Fa)%
Effect = [XA2 * (D + 1) / 128]
Built-IN ASMs:
Oil Fix
If Weapon Strike, then Ability Element = Ability Element + Weapon Element
If DMG / Heal deals X% of tar/cas|cur/max|HP/MP, then pre-elemental DMG / Heal caps at min{999 * X%, tar/cas|cur/max|HP/MP * X%}
Mighty Sword Fix
Optional Selections:
* CasBr% * TarBr%
* CasFa% * TarFa%
* Physical Multipliers
* Magical Multipliers
Proc Spell (ID Range 0x80 - 0xFF)
Proc Status Proc (ID Range 0x00-0x7F)
Break Target Gear (Random, Head, Armor, Accessory, WPN, Shield)
Healing
Drain
Undead Reverse
P or M-EV (a different implementation than above)
Recoil

Instructions:
See attachment...it should all be self-explanatory except:
1) Flags with black dots means they now have actual effects on damage (and not just for the AI)
2) E means if flagged, element = ability element + weapon element.
3) If you see two of the same letter next to 2+ different flags, that means all related flags need to be flagged for the effect to work.
4) H+ means HP healing, H- means HP damage, M+ means MP Healing, M- means MP damage, HM- means HP / MP damage where MP damage is half of HP damage, HM+ means HP / MP healing where MP healing is half of HP healing.  P means PEV and M means MEV.
5) If you don't have a weapon, XA1 defaults to Naked PA and XA2 defaults to PA * Br%.
6) If you use the first formula, XA2 takes all multipliers (like ATKUP).  If you use the second formula, XA1 does, but the sum takes compat.
7) If you flag healing, reducing multipliers like Shell or DEFUP will be ignored.

Did anyone ever get around to labeling all the known bits in FFTPatcher?
(http://files.sharenator.com/Fuck_yeah_2_More_Fuck_Yea-s580x480-47161-580.jpg)

Quote from: Pickle Girl Fanboy on November 14, 2011, 06:59:23 pm
Did anyone ever get around to labeling all the known bits in FFTPatcher?

You can't relabel the column in FDC's screenshot, Melonhead has that hardcoded to the interface for some fucked reason.

I could release a Resources.zip that renames all the others properly, if I were less lazy.  It'd only take a minute, but it'd only really give names to all of 3 flags.

@raven: Yeah, go ahead, somebody will want it sooner or later.

@fdc: I'm super pumped about this, but I can't really afford to play or test it right now.  I'm sure that this thread will be full of congrats once word spreads.  But could you say what specific features are implemented in this version of the hack?

Quote from: Pickle Girl Fanboy on November 14, 2011, 07:03:17 pm
@raven: Yeah, go ahead, somebody will want it sooner or later.

I'm that somebody

Fuck yeah!! This is awesome! Can't wait for it to be finished. :D

Woooooohooooooo!!! All my dreams will come true soon enough!

Sweet! B)

Here is a quick conversion chart. It gives the decimal number you would enter in FFTPatcher to get the P evade and M evade listed. For those interested I included the upper and lower bits. Hopefully everything's correct.

Quote from: Choto on November 28, 2011, 09:42:33 pm
Here is a quick conversion chart. It gives the decimal number you would enter in FFTPatcher to get the P evade and M evade listed. For those interested I included the upper and lower bits. Hopefully everything's correct.

Thank you.  This should help people who don't want to do the math.  I should also mention here that it was Choto who provided me the base for the .XML file, Xif who helped me do testing, and Raven who worked with me on designing the features of this hack.

*drools* been waiting for this... now if I could only pull myself away from skyrim long enough to try it

Did I just see a bunch of event data in the ASM collective battle.bin map?  Is that gonna be optimized?  HOLEY SHITE!

(This reminds me....)

Wow. This is rather impressive and I say that as someone who's hardly been worrying about formulas as of late.

Have I told you how much I appreciate your work lately, Pride formerdeathcorps? Ah, Hell. I'll tell you again considering it's been a month: I greatly appreciate your work, Pride formerdeathcorps.

(No hugging.)

Quote from: The Damned on December 03, 2011, 05:32:20 am
(This reminds me....)

Wow. This is rather impressive and I say that as someone who's hardly been worrying about formulas as of late.

Have I told you how much I appreciate your work lately, Pride? Ah, Hell. I'll tell you again considering it's been a month: I greatly appreciate your work, Pride.

(No hugging.)

It's too bad this Formula Hack is formerdeathcorps' mostly-solo work in terms of the actual coding and Pride hasn't so much as posted in this topic...

(Nice to see that I'm still blind, though thanking Pride is something that I meant to do.)

Haha. Whoops, my bad. Got my already screwed wires crossed, but fixed.

A formerdeathcorps is fine too.

All right, before I move onto XA/YA, I will consolidate some flags.  Just as a quick poll, how many of you actually use the random hits flag on AI moves?

I use it on the Lucavi "Limit Breaks" to ensure they don't spam it.

Random hits is used for, um, Rafa, Malak, and Hyudra/Hydra/Tiamat, right?

That's right.  I'm just wondering if anyone even wanted that flag in their patch since it makes the AI retarded about using good moves, though obviously non-difficulty patches may need precisely that.

How does it make the AI retarded?

It's also good for stopping the AI from spamming horribly OP moves like Altima 2's Lifebreak-All-Ultima in 1.3.  That functionality is good for bosses, since you can give them things that are horribly scary and horribly OP to create tension without worrying about the boss being impossible to beat.  Even a difficulty patch can make use of that, since nothing says that said boss' "lesser" skills can't be scary too.

Quote from: Pickle Girl Fanboy on December 04, 2011, 05:02:31 pm
How does it make the AI retarded?

They no longer use their moves optimally.  If you give the AI flare, for example, and it sees it can pull a KO, it will do so every time (unless it has to resurrect an ally or heal itself).  If you flag flare with "random hits", the AI will only use it some of the time rather than all of the time.  Mind you, with flare, given the MP and CT costs in vanilla, that may not be so bad an idea.

Does Random Hits also imply Multiple Hits?

If it does, then Random Hits is fucking stupid.  The AI should, when it finds a Random Hits ability, try to reduce the AOE by attacking targets in such a way that the AOE is restricted to the target.

Also, should there be a separate Multiple Hits flag, or is there one already?

random hits is terrible... it randomly forces to use the specified skill over any other possible action. As long as targeting is possible, even if the skill doesn't do anything and has 0% to hit, the AI will still be forced to attempt using it.

It looks like I'm not qualified to have an opinion on Random Hits, since I can't figure out what it does.

Multiple hits is hard-coded currently to formulas.  Don't worry, it will be assigned to a flag (or equivalent thereof).

Quote from: formerdeathcorps on December 04, 2011, 05:49:37 pmIf you flag flare with "random hits", the AI will only use it some of the time rather than all of the time.

Quote from: Xifanie on December 04, 2011, 06:30:45 pmRandom hits randomly forces the AI to use the specified skill over any other possible action. As long as targeting is possible, even if the skill doesn't do anything and has 0% to hit, the AI will still be forced to attempt using it.

So which is it?  Will it force the AI to attempt to use it if targeting is possible, or will it disuade the AI from using an otherwise optimal ability once in a while?

What I said; fdc and I both already figured out how to make skills multi-hits. fdc will have a flag for it, but currently you can't really have weapon strike + many hits; the game will "forget" your equipped weapon after the first strike and will punch in the air afterwards.
FFTPatcher has a lot flags misnamed... that's because melonhead didn't read my spreadsheet carefully and named all the flags just like in my spreadsheet... that along with many other flags was marked as red, meaning just a wild guess of what it could be linked to. melonhead took those for granted.

Flags to be saved:


NOTE: Direct is included here as well.



Evadable (this one's a bit trickier, because the AI only counts physical evasion)
Require Sword
Require Materia Blade



BATTLE.BIN: 0x1132C4
1000A393
C0010234
19006200
12100000
1980033C
CC086324
21A04300
1200A387
0E000234
19006200
12100000
0680013C
C0180300
21104100
21186100
F1FB4790
F0FB5390
2800A7A3
F2FB4790
F3FB5290
3000A7A3
F6FB4790
F6EB7890
3800A7A3
00000000

BATTLE.BIN: 0x11344C
20000233

(I'm late as always, but given that I wasn't even on yesterday....)

I don't think I'm using the random flag for anything. Malak & Rafa have been changed for probably close a year now and Hydras' random moves were slain a while ago even when they were just normal enemies. The only other things that uses it is, what, the Nameless Song and Dance abilities? Those have both also been dead for me for quite some time.

Anything that's desperation move-worthy I'm testing out another way that doesn't use randomness. The random flag can have its uses as Raven pointed out, but by and large it makes the already troubled AI even dumber than it should be. (Clarifying EDIT: Fixed the first sentence of this paragraph.)

Anyway, Reflect and Silence are/were the same flag? How so? Not everything that's reflectable is affected by Silence and vice versa, so...?

Reflect and Silence should be seperate flags, like they are now. Shit like summons, for example. IMO, random hits should be saved, it's a useful flag for boss fights.

I don't care what happens, as long as we retain the ability to create abilities like rafa/malak/hyudra/hydra/tiamat/reis multi-hit, random hit abilities, with both the ability to flag and alter multi-hit (specifically, Hit = x or y +1) and maybe the ability to flag random hit.

May I ask why you're trying to consolidate flags like random hits?  Do you intend to keep random hits hardcoded to a forumula?  If that's the case, then couldn't you just make the AI check if that formula is in effect?

We also need reflect and silence to be separate flags, since we might use silence to create a debuff like Addle or Palsy.

NOTE: the bolded text is me rambling, since I don't remember exactly how multiple random hits work.  Do they hit randomly within the AOE of the ability, and does each "hit" have a hardcoded AOE of it's own?

There's way too much confusion about what is going on.  Let's release a map showing explicitly what gets mapped where.

You will notice that each number appears at least twice on the map.  If an ability flag has the same number as an AI flag, the AI flag, when I finish, will assume the role of the ability flag.  If you see a "b" next a number, that means the code that I need to modify in FFT between these two effects are closely linked, and hence, I will tackle both cases simultaneously in my forum post.

Special Notes:
4b is Triple Attack and Triple Breath because both of those AI flags correspond to "3 Directions" the ability flag.  The only difference to the AI is that Triple Attack is not ranged and Triple Breath is.  A future version will definitely merge both AI flags under Triple Breath.
(1) is Evadable.  Like I mentioned in my earlier post, the only skills with the AI flag that correspond to "Evadable" flagged are skills that are P-EVable.  Thus, I'm not exactly sure merging "Evadable" into the AI flag marked "Unknown" is wise.  The key is to see if the AI byte that holds the value of hit chance checks M-EV.  If it does, then it should be fine to code this merger.
* is Direct.  The problem here is that the byte containing direct is loaded onto the stack before the targeting pattern is created.  This is much harder to analyze because trying to track when addresses on the stack are read/written from is a lot harder a task (because it happens much more often than designated data RAM).  Nor can I directly write the desired AI byte to the stack because that would affect all the other flags on the same byte/column (including ones that don't have an AI flag equivalent).  Thus, this flag may be put off until later.
+ is EQ Sword and EQ Materia Blade.  The problem here is that Xif's ARH renders these obsolete, but Xif's ARH probably needs to be recoded to run on all systems and uses a lot of free-space.  Unless Xif wants to do this, I'd likely have to do this, but since this is not directly related to my formula hack, removing the effects from the EQ Sword and MAteria Blade flags while preserving their functions in some other feature will spend a good deal of time mostly away from the formula hack.  Thus, these flags may be put off until later.

Quote
May I ask why you're trying to consolidate flags like random hits?  Do you intend to keep random hits hardcoded to a forumula?  If that's the case, then couldn't you just make the AI check if that formula is in effect?

I think I'm getting the source of your confusion.  Malak/Rafa/Reis/Tiamat spells have "Random Hits" (under AI), "Random Fire" (under Abilities), and multi-hit (hardcoded) simultaneously and you're mixing the three up.
I was slating the AI flag "Random Hits" for deletion.  Most of you opposed it.  Hence, it will not be.  That flag, by itself, HAS NOTHING to do with the Ability flag "Random Fire".  The fact they are even named similarly is a consequence of melonhead making FFTP when we knew nothing about flags and not correcting these names over time.  The reason why Square paired all the skills with "Random Hits" with all the skills that also have "Random Fire" is unknown and likely would result in no change if you removed "Random Hits".
The ability flag "Random Fire" means that given an AoE, you will hit a random panel in the AoE rather than the whole space.  THat is a flag and isn't hard-coded at all.
Multi-hits, a characteristic of tiamats and Rafa/Malak/Reis, will be turned into a flag, though the priority is relatively low.

So basically you're consolidating redundant flags. On a side note FFTP really needs to have all those flags rewritten.

Vanya, many of the flag names are hardcoded into fftpatcher.  What we really need is a complete rewrite in something like C++, with the focus on clean and well-commented code (for easy maintainability), modularity, and cross-platform compilation.  This should make everyone happy, because one of our geekier members can host the latest Windows and Mac binaries, and the rest of us linux bastards can compile fftpatcher ourselves, do bugtesting, and learn about programming along the way.  This will probably require that FFTPatcher (or whatever we want to call the software suite which will replace it) get it's own board or sub-board.

Quote from: Pickle Girl Fanboy on December 06, 2011, 03:39:40 pm
Vanya, many of the flag names are hardcoded into fftpatcher.

No, only that box containing Learn on Hit (so Learn with JP, Action?/Display Ability Name, Learn on Hit, Blank, Unknown A/Used by AI, Unknown B/Smart-Target Allies, Unknown C/Smart-Target Enemies, Blank, Blank, Blank, Blank, Unknown D/Sidestep on Dodge) are hardcoded to FFTPatcher directly.  The AI Behavior and Ability Behavior boxes (the other two Flag windows) can be edited through Resources.zip like most everything else text-related in FFTPatfcher.  The problem is, outside of a bit of name-changes-for-clarity and clarifying 2 or 3 AI Behavior Unknowns (Unknown A/Check CT, Unknown B/Check Faith, Unknown C/Check Evasion), we don't really need to rename most of those until FDC's well into his Flag mauling work, and you can get all the info I just gave you on them right here (http://ffhacktics.com/smf/index.php?topic=4714).  Considering FDC has hobbled FFTPatcher together from its source code before (see: .466), I imagine he or someone else could take the source code for .457 and/or .466 (the only versions of FFTPatcher worth using since .478 is shit) and fix up that one hardcoded window.

I don't happen to have anything remotely resembling a C# compiler, though, nor do I have FFTPatcher's source code lying around, hence why I never bothered with that myself.

To be fair, I didn't code 466.  That was on Xif's FTP.  I released 478 from the C# source-code.

However, 478 is not a complete copy of FFTP (which is why melonhead didn't release it yet).  Hence, many features are broken.
.478's Patcher is completely broken.  I never released a functional copy.  What we commonly call .478's Patcher is actually .466's.
.478's ShiShi, after R999's revisions, is the best version.
.478's orgASM compiled without any bugs, but it itself is buggy.  Don't use it.
.478's TacText...I never bothered using it, but I do remember creating the executable.

AS for my work at releasing the thing?  I did this over 2 days, spending about 12 hours on the source code per day, with minimal food in between.  Mind you, my actual coding skill in C# is not great, so given my working conditions, I probably made some errors.  It's probably why Patcher doesn't even work in the first place.  My C# compiler while I recompiled 478 was the shareware one from Microsoft (since I didn't have one at the time), but I am using a free one now.

Well, In that case it would probably be a good idea to eventually work on the patcher to implement all the cool shit that's being done now.

If you check out the last post in this thread (http://ffhacktics.com/smf/index.php?topic=7163.0), I actually did grab melonhead's latest and compile it successfully (no compile-time errors at all), and run it seemingly without error. I have a zip up in that latest post of that compiled version, wondering if anyone found anything wrong with it. Admittedly I didn't test it too much, but all the programs seem to work. Not sure why this conflicts with fdc's findings. Oddly, a bunch of people seem to have downloaded it, but there's no feedback at all.

PGF, can't say I agree about the rewrite idea, unless some people really want to do it. You'd spend half the time trying to figure out how to create the GUI (form elements) in C++, which come built-in in C#. That would be so annoying that I'd probably rather use java, which is cross platform as well. Maybe you could find a good library to do it... not to mention there is a LOT of code. I see the point about cross-compatibility, but I'm still not sold on the idea that it wouldn't be possible to configure wine or the like to run FFTP. (didn't someone make casual mention of doing it at one point?)

With that said, IF the current base we have works, it probably isn't a bad idea to update some of the things like flag names; maybe even make a few code modifications.

Byuu made an API called phoenix, explicitly for creating hex editors, emulators, front-ends for GUI tools, archivers, video games that need configuration panels,...

I'm no programmer, but wouldn't it make sense - even if we do stick with the current tools - to create a set of command line tools which are the same across all platforms, and then we can focus on making a GUI for each platform, using whatever is easiest for each platform, like C# for Windows, and maybe Perl scripts or C++ for Linux distros?  While making things like the names of each tab or whatever part of several *.config plain text files - instead of the current version using xml?  Though maybe that makes more sense on Linux, I don't know, not a programmer.  It would certainly help to translate the editing tools into other languages, which could get ffhacktics a lot more members, exposure, and all that.  Maybe so much that we'd have to create Help boards for different languages.

What is a collaborative community if it doesn't try to absorb and integrate as many people as possible?

http://byuu.org/phoenix/

QuoteAbout

phoenix is a C++0x GUI meta-toolkit. It is designed as a simple, light-weight API that can be used to create up to moderately complex GUIs; which can then be used to target other popular toolkits, such as the Windows API, GTK+ and Qt.

The idea behind phoenix is to limit one's self to the bare minimum functionality necessary to create standard user interfaces. By using such a small subset, the overall portability of your application is improved. For instance, porting phoenix to another toolkit is at best a weekend project.

While other toolkits such as GTK+ and Qt are cross-platform, they require massive (5MB+) run-times to be distributed with your application. They also tend to be slightly buggy, and their look-and-feel usually ends up somewhere in the uncanny valley. Close, but not perfect.

phoenix allows you to target 100% native APIs for your chosen platform. And by being so light-weight and simplistic, it does not require any run-time DLLs, nor does it add much of anything onto your executable size. phoenix is compiled as a single object file, and adds roughly 50KB onto your executable size.

Caveats

Of course, nothing is without its trade-offs. By being so light-weight, you lose the ability to make truly sophisticated and compelling user interfaces. You will not be able to write the next Open Office or Firefox with phoenix. Instead, it is best utilized for simple to moderately complex user interfaces. Think hex editors, emulators, front-ends for GUI tools, archivers, video games that need configuration panels, etc.

phoenix also targets C++0x. At this time, that means GCC 4.5 or later is required. As soon as clang and Visual C++ catch up, this problem should go away. It was a difficult decision to target C++0x, but it was that or cause the API to become dated as soon as the official C++0x specification was released. By using C++0x, powerful concepts such as lambdas can be used, which greatly speed up application development time, especially in the field of GUI programming.

Also, I'm not just talking about making a FFT editing suite that's cross platform.  If we have a set of editing software that had, well, any standards at all in terms of code readability and separating the different components and the low level stuff from the GUI, (and other things I won't pretend to understand) we'd be better off, because we could add new features and fix bugs faster.

I think if we go cross-platform, we can just have a single code base in C++ that uses GCC or the like. Still, doing that port would be really time consuming.

It shouldn't be a port, IMO, but a clean break.  We should still work on cleaning up and updating FFTPatcher, but if the desire exists beyond just me, those who can should maybe start working on the low-level stuff.  Which could then be integrated into FFTPatcher via a DLL, and then maybe that would free people up to work on the other stuff, since after that it'll just be a matter of getting the GUI for FFTPatcher to work.  While one team works on getting the FFTPatcher GUI working, the other team could try to get a gui for the replacement editor.

I know it's not a good idea to divide efforts/forces, but I don't have the expertise to come out and say we SHOULD do one or the other.  It may be best to hedge our bets.

Also:
http://board.byuu.org/viewtopic.php?f=10&t=2247

A FFTPatcher like editor isn't really hard to code... personally I lack the knowledge and motivation, but the same would apply to FFTPatcher which is a terrible base to start working with. My first plan was to make a python 2.7 portable with wxpython GUI which would be cross-platform and easy to share the source.

Why are we making this replacement editor to begin with?  Thanks to Glain, .478's Patcher works, and porting it is simply a procedural decision (do we generate a C++ port, do we use phoenix, or some hybrid/other system)?  If you're saying that Patcher currently does not contain things on Raven's spreadsheets (like SCUS data for initial inventory and level 1 stats), then Patcher should be updated, but Patcher should not encompass everything.  At its core, Patcher is a data table editor (akin to Gameshark), not an ASM insertion tool.  For ASMs that provide customizable options like ARH or ALMA or my weapon XA hack, a spreadsheet would be preferable to Patcher.

The only things we currently can't edit at all:
1) RAM size (not fixable)
2) Sprite/map image compression (requires recoding how FFT renders pictures...we don't know what code does this, and we haven't decided on how to standardize this compression)
3) Sound (we know how, but it is WAY too time consuming...there needs to exist a tool)
4) Movies (file format is unreadable by standard PSX movie readers and currently impossible to reinsert)
5) Sprite types (making our own .SHP/SEQ files)
6) More TEST.EVT/ENTD slots for a longer storyline/branching storyline.

The things we can partially edit
1) ROM size (only to the end of ISO)
2) AI (very basic, SA and I both know only a little)
3) Drawing of statii (SA is working on this)
4) Formula hard-coding/variable stat inputs (I am working on this)
5) Event Command types (Xif is working on this)
6) Item/Moveset/Job hard-coding (GSF/ALMA/RAD edits this, but the native Square code is still in place, which no one has entirely deciphered...another issue is that table expansion will cause items to take up 2 bytes of space, rather than 1, which requires virtually all of battle RAM to be restructured)

This may not be a very good reason, but the having an editor that is easy to update is what we should have done in the first place, just to make everything less confusing and less of a patchwork/shoestring, spit, and duct tape project.

Other things.
*Tighter integration between parts of the software suite, to replace many of the spreadsheets.  Or, if you want, you could change the name of an ability in your patch and have the editor reflect that while you're editing the new abilities attributes.
*Improved controls (like the ability to copy and paste entries in data tables; to move data entries around as you see fit; to check instantly whether an ability you're thinking of moving is used in any skillsets, or to check if what skillsets an ability is used in and to bring all of them up for editing - basically, anything which currently requires you to make a list and check it off to make sure you didn't miss anything).
*Nobody thought of this (and it just occurred to me), but we're gonna need to make an editor anyways, for Tethical.  We might as well make something which we can reuse later on.  As such, the layout I mention (command line tools linked to a GUI by a set of modifiable scripts, and configured by plain text files) is the least stupid way to do it.
*The less people have to worry about updating and maintaining spreadsheets, the more time they can devote to any of the investigation, documentation, and reverse-engineering projects you mentioned, FDC.
*We're gonna need a coder anyways to come up with an automated way to extract and insert videos, to develop a PNG compression/extraction routine to replace what I assume are the BMP derived sprites sheets we currently have.  Though that routine will then have to be compiled into PS1 assembly language, but such a tool should currently exist, if PS1 homebrew exists.  Same with music and sound effects.  Same with encoding PNG or BMP into images FFT can use.
*If we use the layout I proposed (command line tools linked to a GUI by a set of modifiable scripts, and configured by plain text files), we'd have a set of tools which, with a bit of effort, could be modified to work for any PS1 game, and maybe any game, period.  Though I don't think we should pursue such modularity (don't know if that's the right word) from the beginning.
*Linux and Mac compatibility.
*Speed/Performance (sometimes FFTPatcher freezes on older computers).

Really, I don't know enough to make a decision on this, so I'll shut up for now.

EDIT

You're right, FDC, but I realize now that we're talking about different things.  What I describe is a long-term project, which will eventually "complete" or "perfect" fft hacking.

My 2cc as a professional software developer: don't give in to the temptation of rewriting the code from scratch. Not only will you spend half a year trying to get basic functionality back up, the result will have less features and more bugs than the existing code-base. A "clean start" may sound more enticing than doing the hard, thankless job of fixing the current code-base, but 9 times out of 10 it is the wrong decision.

Regarding Mac and Linux compatibility: make sure data structures and logic are separate from the UI and specialize the UI for each platform (WinForms for Windows, MonoMac for Mac, GTK# for Linux). If you are lucky, this will already be the case and adding new platforms will be easy. If you are unlucky, C# has good refactoring tools to take most of the pain away - and the total pain will be nothing like rewriting everything in C++.

Again, my 2cc. Good luck!

Quote from: bugnomore on December 16, 2011, 05:05:37 am
My 2cc as a professional software developer: don't give in to the temptation of rewriting the code from scratch. Not only will you spend half a year trying to get basic functionality back up, the result will have less features and more bugs than the existing code-base. A "clean start" may sound more enticing than doing the hard, thankless job of fixing the current code-base, but 9 times out of 10 it is the wrong decision.

This is what we keep telling Pickle Girl Fanboy, honestly.  He just don't listen to us, man.  Unless you have absolutely nothing else to work on, there's no reason to go backwards when your effort can be put to use making something new.  And even then, like you said, well over half the time it's still more hellish than it's worth.

All right, I'm still going to continue this, but this is impossible to continue without giving ourselves the space to run.

All of the following are to be rerouted to Kanji space.

0x00 -        Flags 1
                0x80 - Break Toggle (if Uneqiup is on; then if this is on = break, if off = steal)
                0x40 - Display Ability Name
                0x20 - Learn on Hit
                0x10 -
                0x?9 - Movement
                0x?8 - Support
                0x?7 - Reaction
                0x?6 - Math
                0x?5 - Aim
                0x?4 - Jumping
                0x?3 - Throwing
                0x?2 - Item
                0x?1 - Normal
                0x?0 - None

0x01 -        Flags 2
                0x80 - HP
                0x40 - MP
                0x20 - Cancel Status
                0x10 - Add Status
                0x08 - Stats
                0x04 - Unequip
                0x02 - Target Enemies
                0x01 - Target Allies

0x02 -        Flags 3
                0x80 - Target Map OR Self-only
                0x40 - Reflectable
                0x20 - Drain Toggle (if attack is flagged stats, HP, or MP, on = drain Stat, off = just damage)
                0x10 - Follow Target
                0x08 - Use Randomly
                0x04 - Faith
                0x02 - Evadeable
                0x01 - Silence (on = affected by silence)

0x03 -        Flags 4
                0x80 - Arc Attack
                0x40 - Direct Attack
                0x20 - Linear Attack
                0x10 - Attack from Range
                0x08 - Brave
                0x04 - Triple Breath
                0x02 - Magic Defense UP
                0x01 - Defense UP

0x04 -        Flags 5
                0x80 - Usable by AI
                0x40 - Cannot Target Enemy
                0x20 - Cannot Target ally
                0x10 -
                0x08 - Same Target Toggle (if on, this means all three statii/procs hit the same target)
                0x04 -
                0x02 -
                0x01 - Evasion Toggle (if evadeable is on; then if this is on = P-EV, if off = M-EV)

0x05:         Flags 6
                0x80 - Zodiac Toggle (if on, Zodiacs modify effectiveness; if off, Zodiacs have no effect)
                0x40 - ???
                0x20 - Weapon Attack
                0x10 - Vertical Fixed
                0x08 - Vertical Tolerance
                0x04 - Weapon Animation
                0x02 - Centered at Self
                0x01 - Can't Target Self

0x06:         Flags 7
                0x80 - Weapon Damage Toggle (if on, take 2H and use weapon type and WP to determine XA and YA; if off, use given XA and YA)
                0x40 - Math Skill
                0x20 - Top-down Targeting (if higher elevation has target, do not hit lower elevation)
                0x10 - Can't Mimic
                0x08 - Random Target (Each attack only hits one panel in AoE range)
                0x04 - Persevere
                0x02 - Quote
                0x01 - Can't Hit Caster

0x07:         Flags 8
                0x80 - Counter Flood
                0x40 - Counter Magic
                0x20 - Animate on Miss
                0x10 - Countergrasp
                0x08 - Proc Toggle (If on, then spell proc, else, status proc)
                0x04 - Random Damage (If on, then variance is 0.5 - 1.5x expected, else no variance)
                0x02 - Poach
                0x01 - No Targeting

0x08           XA (takes multipliers--selecting more than one stat yields the average between them):
                0x80 - PA
                0x40 - MA
                0x20 - SP
                0x10 - (LVL / ?? + ??, to be determined by user)
                0x08 - WP
                0x04 - Naked Stat (if paired with WP yields PA * Br%)
                0x02 - + Toggle (If true, + ZA, if false * ZA)
                0x01 - Number (Sets XA as a number rather than as a stat)

0x09           ZA (does not take multipliers):
                Upper 6 bits are treated as a number for calculation.
                0x02 Control Toggle (See Subsection A)
                0x01 Variate Toggle (See Subsection A)

Subsection A:
If Control Toggle is off, then Variate Toggle behaves + Toggle does for byte 8.
ELSE,
IF Variate Toggle is on, then XA [?] ZA is the hit chance, and YA the damage.
IF Variate Toggle is off, then XA [?] ZA is the damage, and YA the hit chance.

0x0A           YA (does not take multipliers--selecting more than one stat yields the average between them):
                0x80 - PA
                0x40 - MA
                0x20 - SP
                0x10 - (LVL / ?? + ??, to be determined by user)
                0x08 - WP
                0x04 - maxStat (as referenced by HP / MP flags; if neither, this means nothing)
                0x02 - Naked Stat (if paired with WP yields PA * Br%)
                0x01 - Number (Sets YA as a number rather than as a stat)

0x0B           "B1"
                IF Unequip is flagged;
                0x80 = Accessory
                0x40 = Body
                0x20 = Head
                0x10 = Shield 
                0x08 = Weapon
                Lower 3 bits are checked regardless of flags:
                0x04 = Golem
                0x02 = Inflict Moldball Virus
                0x01 = Interchange XA with YA (meaning the + toggle on XA corresponds to YA [] ZA, and the + toggle on ZA corresponds to ZA [] XA, but XA still takes multipliers)
               
0x0C           "B2"
                IF Stats is flagged;
                0x80 = PA
                0x40 = MA
                0x20 = SP
                0x10 = CT
                0x08 = Brave
                0x04 = Faith
                0x02 = EXP
                0x01 = Gil
                0x00 = Level

0x0D          "P"
               Upper 4 bits determine recoil damage (0000 means no recoil, everything else (Upp4bits + 1) / 16 * damage dealt to self.)
               Lower 4 bits determine multiplier to base damage given by (1111 means 3/2 * base damage, everything else is (Low4bits + 2) / 12 * base damage.)

0x0E         "C"
               Upper 4 bits determine critical hit rate at (Upp4bits + 1) / 16 chance IF evasion toggle is on, ELSE, the critical hit rate is 0.
               Lower 4 bits determine proc rate at (Low4bits + 1)  / 16 chance.

0x0F         "N"
               Upper 4 bits determine the maximum number of times an attack hits, as given by Upp4bits + 1.
               Lower 4 bits determine the minimum number of times an attack hits, as given by Low4bits + 1.  If Upp4bits don't equal Low4Bits, then attack for a random number times bounded by the maximum and minimum.

0x10 - Inflict Status/Proc 1 (Unless Same Target Toggle is on, hit target at proc rate)
0x11 - Inflict Status/Proc 2 (Unless Same Target Toggle is on, hit self at proc rate)
0x12 - Inflict Status/Proc 3 (Unless Same Target Toggle is on, hit target at proc rate)
If Same TArget Toggle is on AND IF 0x10, 0x11, 0x12 are all non-zero:
Status/Proc 1 has proc rate * .6 chance to land.
Status/Proc 2 has proc rate * .3 chance to land.
Status/Proc 3 has proc rate * .1 chance to land.
If Same TArget Toggle is on AND IF 0x10, 0x11 are all non-zero:
Status/Proc 1 has proc rate * 2/3 chance to land.
Status/Proc 2 has proc rate * 1/3 chance to land.
If Same TArget Toggle is on AND IF 0x10, 0x12 are all non-zero:
Status/Proc 1 has proc rate * 4/5 chance to land.
Status/Proc 3 has proc rate * 1/5 chance to land.
If Same TArget Toggle is on AND IF 0x11, 0x12 are all non-zero:
Status/Proc 2 has proc rate * 1/2 chance to land.
Status/Proc 3 has proc rate * 1/2 chance to land.

If Same Target Toggle is on, only one status/proc from the above selections CAN be inflicted.  NOTE: If you have an AoE attack that hits multiple targets, it is possible to hit each target with a proc, regardless of type.

0x13 - Restriction Type (reads "ARH-style" table that restricts both attacker and target types as well as "ALMA-style" attack restrictions by support)
0x14 - Consumed Item ID
0x15          "S"
               Upper 4 bits determine chance to consume item if item ID is not 00, given by (Upp4bits + 1) / 16 chance.
               Lower 4 bits, if not 0000, determine the terrain type ID restriction.  Attack can only be executed on terrain with terrain type ID (given by separate table) of Low4bits.

0x16         "R"
               Upper 4 bits determine the maximum range, as given by Upp4bits + Innate Range [non-zero if weapon attack is on, or for THROW, JUMP, ITEM, etc].  If Innate Range > 0, then Upp4bits is signed (and is bounded by [-8, 7]).
               Lower 4 bits determine the minimum range, as given by Low4bits + Innate Range [possibly non-zero if weapon attack is on].  If Innate Range > 0, then Low4bits is signed (and is bounded by [-8, 7]).

0x17         "A"
               Upper 4 bits determine knockback chance (0000 means on physical critical only, everything else has knockback probability of (Upp4bits + 1) / 16.)  This will be considered only if the Lower 4 bits of "A" is 0 OR if random target is on.
               Lower 4 bits determine Area of Effect, but 1111 means target map.

0x18 - Vertical, as given by Vertical + Innate Vertical [non-zero if weapon attack is on, or for THROW, JUMP, ITEM, etc].  If Innate Vertical is not 0 or 255, then Vertical is signed.  If Area of Effect is 0, then 0 Vertical means to ignore this byte.  If Vertical is unsigned and has value of 255, target map.
0x19 - Element
0x1A - CT
0x1B - MP Cost

Status Infliction Flags
0x80 All or Nothing (If Status infliction passes proc chance check, inflict all statii marked)
0x40 Random (If status inflict passes proc chance check, inflict a random selection of statii marked)
0x20 Separate (Each status selected must pass proc chance check separately.)
0x10 Cancel (Replace the word "infliction" with "removal" in the descriptions of each flag other than "Strongly-blocked" under "Status Infliction Flags".)
0x08 Strongly-linked (If no status is inflicted, cancel the main effect of ability.)
0x04 Strongly-blocked (If any status to be inflicted is nullified, do not inflict ANY status)
0x02 Counter-inflict (If the main effect of the ability is blocked, inflict the status anyways at proc chance.)
0x01 Interlinked (If the "Same Target Toggle" is off, all three Inflict Status Procs are inflicted under one RNG check; if off, all three have separate checks)

I'm not sure how I'm going to use this make reactions (and especially their triggers) easier, but it will be the next topic.  The counter data will use the exact same format and I will post it soon.

All right, let's get moving

Data Structure:
0xE9980 (BATTLE.BIN -- 0x1C [above data structure for the chosen move] + Assorted Extra Flags + 0x1C * 0x200 [the data table to be copied from] + Excess Table [weapon formulas])

Code:
~0xF0000 (BATTLE.BIN)

addiu r29, r29, 0xFFD8
sw r16, 0x0000 (r29)
sw r17, 0x0004 (r29)
sw r18, 0x0008 (r29)
sw r19, 0x000C (r29)
sw r20, 0x0010 (r29)
sw r21, 0x0014 (r29)
sw r22, 0x0018 (r29)
sw r23, 0x001C (r29)
sw r31, 0x0020 (r29)
lui r16, 0x8015
addiu r16, r16, 0x0980        // r16 = Address of the start of the data structure of the considered move.
lw r4, 0x0004 (r16)           // r4 = Load Flag 5 / Flag 8
jal 0x188b64                   // Inflict Status
lw r5, 0x0010 (r16)         // r5 = Inflict Status/Proc 1/2/3

BATTLE.BIN
0x121B64

addiu r29, r29, 0xFFF4
sw r31, 0x0000 (r29)
sll r5, r5, 0x08
srl r5, r5, 0x08
beq r5, r0, END
addu r2, r0, r0
srl r2, r4, 0x10
andi r2, r2, 0x0800
beq r2, r0, END
andi r1, r4, 0x0008
beq r1, r0 THREE
addu r6, r5, r0
lui r1, 0x8018
ori r1, r1, 0x????
addu r3, r0, r0
addiu r7, r0, 0x0022
(LOOP) beq r5, r0, DECISION
srl r4, r5, 0x08
sll r4, r4, 0x08
lbu r2, 0x0000 (r1)
blez r7, NEXTCHECK
addiu r1, r1, 0x0001
addiu r7, r7, 0xFFF0
(NEXTCHECK) beq r4, r5, LOOP
addu r5, r4, r0
blez r7, NEXTCHECK2
addu r3, r3, r2
addiu r7, r7, 0xFFFF
(NEXTCHECK2) ori r2, r2, 0x0080
j LOOP
sb r2, 0x0000 (r1)
(DECISION) addiu r4, r1, 0xFFFC
jal 0x2230C
addu r5, r3, r0
bgez r7, NOREDUCE
andi r7, r7, 0x0002
beq r7, r0, NOREDUCE
lhu r1, 0x0000 (r4)
addiu r5, r5, 0xFFFE
addiu r1, r1, 0xFDFE
sh r1, 0x000 (r4)
(NOREDUCE) multu r3, r5
mfhi r3
addiu r7, r0, 0xFFFF
(LOOP2) lbu r1, 0x0000 (r4)
addiu r4, r4, 0x0001
sltiu r2, r1, 0x0080
beq r2, r0, LOOP2
addiu r7, r7, 0x0001
andi r1, r1, 0x007F
subu r3, r3, r1
bgez r3, LOOP2
nop
sll r7, r7, 0x03
srlv r6, r6, r7
(THREE) lbu r5, 0x000E (r16)
jal 0x2230C
andi r4, r6, 0x00FF
andi r5, r5, 0x000F
addiu r5, r5, 0x0001
ori r1, r0, 0x0010
multu r3, r1,
mfhi r3
sltu r1, r3, r5
bne r1, r0, SUCCESS



lw r31, 0x0000 (r29)
addiu r29, r29, 0x000C
(END) jr r31
nop

Any above post that does not have an attachment file is an aborted failure that I will no longer pursue.  All further development will continue along lines given here (http://ffhacktics.com/smf/index.php?topic=9990.msg193690#new).