• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
March 28, 2024, 04:27:58 pm

News:

Please use .png instead of .bmp when uploading unfinished sprites to the forum!


Formula Hack v0.57

Started by formerdeathcorps, November 14, 2011, 06:41:21 pm

Pickle Girl Fanboy

December 07, 2011, 02:18:44 pm #40 Last Edit: December 07, 2011, 04:52:28 pm by Pickle Girl Fanboy
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.

Glain

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.
  • Modding version: Other/Unknown

Pickle Girl Fanboy

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

Xifanie

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.
  • Modding version: PSX
Love what you're seeing? https://supportus.ffhacktics.com/ 💜 it's really appreciated

Anything is possible as long as it is within the hardware's limits. (ie. disc space, RAM, Video RAM, processor, etc.)
<R999> My target market is not FFT mod players
<Raijinili> remember that? it was awful

formerdeathcorps

December 07, 2011, 05:20:28 pm #44 Last Edit: December 07, 2011, 05:37:55 pm by formerdeathcorps
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)
The destruction of the will is the rape of the mind.
The dogmas of every era are nothing but the fantasies of those in power; their dreams are our waking nightmares.

Pickle Girl Fanboy

December 07, 2011, 08:24:23 pm #45 Last Edit: December 09, 2011, 11:49:31 am by Pickle Girl Fanboy
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.

bugnomore

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!
  • Modding version: Other/Unknown

RavenOfRazgriz

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.

formerdeathcorps

December 25, 2012, 11:06:30 pm #48 Last Edit: January 07, 2013, 08:29:51 pm by formerdeathcorps
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.
The destruction of the will is the rape of the mind.
The dogmas of every era are nothing but the fantasies of those in power; their dreams are our waking nightmares.

formerdeathcorps

January 06, 2013, 07:01:20 pm #49 Last Edit: January 08, 2013, 03:45:33 pm by formerdeathcorps
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
The destruction of the will is the rape of the mind.
The dogmas of every era are nothing but the fantasies of those in power; their dreams are our waking nightmares.

formerdeathcorps

November 29, 2013, 05:36:40 am #50 Last Edit: November 29, 2013, 08:00:54 am by formerdeathcorps
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.
The destruction of the will is the rape of the mind.
The dogmas of every era are nothing but the fantasies of those in power; their dreams are our waking nightmares.