Final Fantasy Hacktics

Yo.  20/M/NH.  Interests include long walks on the beach, sizable breasts, and delicious food.

Skilled in most forms of editing when it comes to FFT, sans Assembly Hacking and advanced levels of Sprite editing.

Currently working on 3 Projects, an unposted reorganization effort known as Vanilla Plus, an unannounced gameplay and story modification patch, and Final Fantasy Tactics - Special Power Rangers Edition!

Not much else to say.  Herro.

So, guys, I've taken up a bet with a number of the various Spriters at our fine site here at Final Fantasy Hacktics.  

The contents of this bet?  If they can supply me with an adequate number of (Season 1) Power Rangers, a Megazord, some Puddies, and other essential Sprite-based materials needed, I will make a Power Rangers Mini-Patch.  At least one brave soul is actively taking up this challenge and others seemed to express interest, so we'll see how this goes.

Why this thread?  To build hype, to make sure I don't forget, to make sure THEY don't forget, and to get the input of you, the reader.  I've already got a rather solid outline for plot continuance, encounters, abilities, stereotypical always-the-same-place Megazord battleground, etc., so never fear if ye have no ideas.  However, if any of you come up with any cool ideas for this mini-mod, from cool potential battle/cutscene scenarios, potential bosses, skills for allies and enemies, and whatever else may come to mind, feel free to suggest it here.  I feel I've already got a solid foundation but because of how spur-of-the-moment the actual drive to make this project is, there's a high chance some collaboration could easily improve it.

So, thinktank with me, mein brothers and mein sisters, while we wait for our Sprites to be completed.

EDIT: For those who want to know how this project will differ from the actual Final Fantasy Tactics mechanically, visit my other Project.  These two Projects will share a majority of basic gameplay changes with each other, though the gameplay itself will obviously be vastly different by virtue of concept differences.  For those who don't want to check that, the important stuff is that Move/Act no longer grants bonus CT, almost everything works off either Fury or Will (Brave or Faith), and Status interaction is greatly modified.  There will hopefully be a few mechanics that will, however, be unique to the Special Power Rangers Edition.  I have a few planned but they are not the easiest to code so I won't be announcing those until I have working versions of them.

Also, for those wondering what a Power Ranger looks like in the Final Fantasy Tactics Universe:

Why an ATTACK.OUT editing tutorial?  Because one is sorely needed, I say.  This Tutorial will cover the basics of editing these events and which tools are needed to easily do so.  Something to remember is that events are basically coded with Lego bricks - so you as long as you conform to the very general constraints of the commands here, you can usually get the victory conditions you want.  You add this code to the game using a handy spreadsheet made by Xifanie and edited by myself to remove excess code, though I will instruct on its use after telling how the code itself actually works.  Also needed will be a Hex Editor that has the Write function.  Most have this, but a few do not or are really annoying in allowing you to access it, so make sure your current one has it and that you can access it easily before continuing.

First, however, it's time to learn the code.  The easiest way to do so is just to have it thrown at you at once then systematically disassembled in my experience, so that's how I'll be handling this Tutorial.  Don't be afraid at what you're about to be shown, kids.  To preface, all numbers are in hex, remember this.

180003000800020000002500000001000100000001006800020001006500040001007E00010001007F000000
010080000000040003000500030001000600050000000800050009000B000300160019000300

[NOTE - This line was broken up in order to remove a horizontal scrolling issue.  There should be no break in it normally.]

...You'll never see a monster this bad even in Vanilla's base code, but it's something you could throw together.  So, let's break this thing down.

The first piece of code we'll look at is one that appears five times in this string of numbers, 0100XX00##00.  This is the variable check command.  It takes the variable XX and checks to see if the number it contains is equal to ##, and if it finds this condition to be true, will allow the event to proceed to the next check.  Most often, this is used as a true/false trigger, looking to see if something's occurred earlier during the battle or event, or checking to see which choice was made on a conditional event.  (Think: choosing whether or not to save Algus at Mandalia Plains.)  However, these variables can hold more than just 0 or 1, so creative use can allow you to further track things about events the player has or hasn't triggered.  It's also worth noting, obviously, that these variables are indeed saved and tracked by the game over the course of a playthrough - meaning you should reset a variable when done with it to avoid errors, but also meaning full on branched-paths are indeed supported by the game if you can allocate the space to them.  Note that variables themselves are not incremented by ATTACK.OUT, but in the events themselves located in TEST.EVT.

There are some special variable calls listed here though, specifically 65, 68, and 80.  65 and 68 are very rarely used - their only purpose in Vanilla is to track how far the player has traversed into the Deep Dungeon and which floor tile is currently the active exit tile during that particular battle.  As such, they are only listed here for completion.  The one that will be used more often is 80 - this is the game's "end of battle" variable, which does what it says on the tin, making sure the battle hasn't ended before playing the event.  The note here, though, is that this check is rarely needed, as most conditions to make an event play cannot be completed while ending the battle simultaneously.  It *can* be needed sometimes, so remember it exists, but it is not a necessary check in most cases.

Tl;dr - Use 0100XX00##00 to check variable XX for value ##, which is set by the Event and not ATTACK.OUT, remember they carry over, remember that 65, 68, and 80 are reserved for special game functions, though 65 and 68 can be used if you intend not to use the Deep Dungeon in Vanilla's form.

1800030008000200000025000000010001000000040003000500030001000600050000000800050009000B000300160019000300

This leaves us with this, already much more acceptable.  Since I've covered one of the key functions of Deep Dungeon, I'll cover the other, along with a very similar feature only used once in the whole game.  First, let's cover 1800ID00XC00YC000000, the command used at Bethla Sluice for opening the flood gates and at Lionel Castle for lowering the gate.  This checks for Unit ID based on the ENTD, then checks to see that the unit being looked for is on the square specified by XC (X-Coordinate) and YC (Y-Coordinate).  Anyone who has touched an ENTD or remembers the most basic of basics from Geometry class should see how this is applied.  Use the maps on the front page of the site to get an accurate top-down view of each map and set the correct X and Y coordinates.  25000000XC00YC000000 is the other, similar command used in Deep Dungeon - it functions exactly the same, but doesn't require a Unit ID field, meaning any player-controlled unit can trigger the event in question.  Knowing both exists can be a life-saver for anyone wishing to use this command, since it gives the choice as to whether or not a specific unit is required to trigger the event in question.

Tl;dr - use 1800ID00XC00YC000000 or 25000000XC00YC000000 to create events that run based on units that step on specific tiles, the former if a specific unit is needed and the latter if not.

040003000500030001000600050000000800050009000B000300160019000300

Look at that code peel away!  Now we can knock out three simple commands in quick succession!

0400ID00 is a simple command - it checks to see if the Unit based on Unit ID in ENTD exists on the map.  Mostly useless since oftentimes you want to check if the unit is also alive, or dead, or other various things about it, but it's good for the rare situations where all that info actually doesn't matter, such as Delita's infamous cutscene-powered get-back-up at Fort Zeakden.  The next two commands we'll be discussing are far more universally useful.  0500ID000100 checks to see if the unit is alive.  The uses of this command are obvious - it stops a unit called by its ID in the ENTD from speaking if all other circumstances needed to trigger an event are true and said unit died somehow.  You will usually want this unless you intend for that scene to include a dramatic Delita get-back-up, or are using the next command I'll be discussing.  This command is 0600ID000000, which is the unit dead check.  This command is most often used during Assassination Missions where your goal is to actually murder your target, and as the defeat condition trigger for situations such as "Save Rafa!" at the top of Riovanes Castle.  As per usual, ID is the Unit's ID in the ENTD.  All simple commands whose uses are fairly obvious, I hope.

Tl;dr - 0400ID00 checks to see if the unit exists and is usually unneeded, 0500ID000100 checks to see if the unit is alive, 0600ID000000 checks to see if the unit is dead, three simple but useful commands.

0800050009000B000300160019000300

Just a few more commands left now!  0800ID00%%00 is another useful command, often seen on those pseudo-Assassination Missions where the goal is to really get a target below X% health, which is exactly what this command checks for - Unit ID by ENTD at less than or equal to %% hex-percent health.  Very simple and easy to use.  0B00ID00 is another simple command to use, as it checks to see that the Unit by ID in ENTD has active turn.  This is useful for things like the Bethla Sluice "help" hint, where Ramza mentions the floodgates during his first turn, and other, similar scenarios.  It can be combined with clever variable usage to create back-and-forth conversations between units each time one of them has active turns, or to have an event trigger on a certain unit's Nth turn, though the latter especially requires some high-end critical thinking to be done effectively and efficiently.

Tl;dr - 0800ID00%%00 checks for a unit's health percent to be equal to or lower than the input value in hex, 0B00ID00 checks for the unit to have active turn.

160019000300

This is all we have left, the most primitive and common commands.  1600 takes no input, and needs no input - it checks to see that all units on all existing teams besides the player team have been defeated.  1900#### is the process run if all conditions before it return true - 1900 here is the command, and when all conditions are true, will play the event located at Event Script ####.  While events are usually in sequence, this *does* mean you can call events out of sequence if you have a reason to do so.  This is an odd quirk that most people shouldn't need, but can easily be put to work as necessary.  However, remember that the bytes here are inverted.  So, trying to run Event Script 01EA would be input as 1900EA01.  This can seriously screw you up if you forget this and send you bug hunting for errors that don't exist, so take care to always make sure you are using the proper coding convention here.

Tl;dr - 1600 is the "killed everything" flag, 1900 tells the game to run next event if all things before it return True, #### tells the game which event is the "next event."

So, to say, apply this knowledge... let's make a quick event.  01007F000100050003000100080003000F000B00030019008F01.  What does this event do?

Go on.

For those who didn't figure it out, it checks to see if variable 7F is equal to 1, likely meaning a previous event in the fight must be triggered before this one.  Then, it looks to see if Ramza (Chapter 4 variant specifically) is alive, at 16% health or less, and has active turn.  Then, if all these factors are true, it plays Event Script x018F.  If even one of these conditions returns false, the event does not play.  Simple and Lego-like just as I said, right?

However... there is one more small piece of code to remember.  0100FD0101001900####.  This is special initializer code for the very first event in the battle or cutscene, telling the game to play the Event Script after 1900 without any checks.  Use it basically always as the code for the first event of every cutscene or battle situation you create.  Nothing more, nothing less.

Tl;dr - 0100FD0101001900#### should be the entire conditional code for the first event of every battle or cutscene you create.

"But Raven, the Spreadsheet!  What the frell is that?!"  You cry!  Well fear not, for despite this long tutorial, I have not forgotten!

It will be attached to the bottom of this post, and can be opened in either Microsoft Excel or OpenOffice.  It contains the hex code for all the battle conditionals.  However, since this is my version of it, all redundant code checks have been removed, making this far easier to read and edit for someone not familiar with the code, and far easier to add more expansive events to without hitting the code ceiling.  Put simply, when the Spreadsheet is open, Column A will list exactly how to use it - when you're done editing code, click the blue bar (Column B), copy, and *write* to the offset in ATTACK.OUT referred to by Column A using your Hex Editor of choice.  Note that you *must* use the Write command and not the Paste command, or serious errors will occur.  To edit a particular battle, simply find its header in the Spreadsheet, click the line of code you want to modify, and go to town.  A little bit of playing around will make how it works fairly obvious now that you have the knowledge of what those numbers actually mean at your disposal.  And yes, for those who didn't know, that's how the game is organized in Vanilla, incredibly sloppily and slapdash.  The bar that says "Safe" in green with a fraction above it tells how many bytes of ATTACK.OUT you are currently using vs the maximum you are able to.  When adding a lot of content, it is good to be wary of this fraction.  The Spreadsheet I am supplying you with only uses 7294/8636, so there is plenty of space to play, and yes, someone was payed to code that badly.  Funny world, eh?

Hopefully, this tutorial will help people having problems getting their ATTACK.OUT battle conditionals to work how they want them to overcome those problems with ease, while also teaching how to use every single bit of code at their fingertips to maximum effect and efficiency.  If there are questions or suggestions for improving this tutorial, feel free to leave them.

FFMaster apparently didn't realize this existed and asked me to make a topic with it as a downloadable attachment so more people know it exists.

For those who don't know, it's a quick and dirty stat/growth calculator that can work with and stat/class/gender combination, including custom ones and ???? stats (which the editor refers to as "Zodiac Beast Gender").  A quick how-to:

Input a Class/Character and a Gender (mostly a dirty way of getting male or female raw stats, though it has the base Multipliers and Growths of all vanilla classes stored if you actually need them), click "Base Class", click "Start."  Adjust the raw stat values under the Statpoints box as needed if they're not accurate to your needs, adjust the Class Multiplier Values and C Values to match the respective Multipliers and Growths you need, then use the scroll down "Lvl Change to" box to set the level you want to change to, and view that data in the "LvlChange Preview" box on the right.  (The "Current Stats" box on the left, of course, shows the stats you're starting with as they would appear in-game.)  If you want to save the end stats in the "LvlChange Preview" and "Statpoint Change Prev" boxes so you can adjust growths and continue for the sake of things like cross-class leveling, just slam the "Update Current Stats" button and continue as normal.

Tl;dr: It's a highly quick-and-simple self-explanatory Multiplier and Growth Calculator that's far less resource intensive and more convenient and simple than a spreadsheet.  Download it and enjoy if you don't already have it.

(Raw Image and Blank Motivational here for anyone who wants to make their own.)

[Blame PX for inspiring this and my boredom for making it.]

I've been talking with R999 for a while over MSN and we hit a rather odd problem - actually having enough available skill slots to house all generic skills, hero skills, enemy only skills, etc.  This seems like a small issue at first, but considering there are 16 hero teams, over 18 generic classes, around 10 Zodiac Beasts, and probably 16 enemy "hero" units all of which will have at least some number of unique skills, this becomes a big freaking issue.

After some discussion with R999 (where I had to stop him from doing really silly), I've come up with a solution to this problem, and the purpose of this thread is to evaluate, critique, and improve upon said solution to ensure all classes have streamlined ability lists and that we're making optimal use of all the space in the game.  There are roughly 338 editable skill slots, last they were reviewed, for reference.  Each aspect of this post is contained in spoiler tags to prevent needless scrolling.










In short, what's needed are thoughts, critiques, improvements, potential flaws, and in the end consent/approval to this strategy, a variation of it, or an altogether different and better strategy should someone have it so that everyone's skillsets can be made unique, fleshed out, and balanced without breaking the bounds of the game.  So, those others of you out there involved with the gameplay discussion, do critique and offer improvements upon this strategy, and do remember this has nothing to do with the actual skills in each set, so keep those discussion within their own respective threads.

Edit: Naming Convention will be updated in the future.



I finally finished putting together some draft notes for four sets of gear (the fifth set is reserved for either an awesome conceptual idea of for elemental toying).

Currently, my equipment notes look like:

[center:t4cfkhne]-Equipment Data-[/center:t4cfkhne]

Hats, Helmets, Clothes, Armors, Robes: Names are based on location of creation and class and spiced up in what ways I could think of.


Igros: MP emphasis, made for Magicians.


Lionel: HP emphasis, made for Defense.


Zeltennia: PA emphasis, made for Fighters.


Riovanes: Speed and Offense emphasis, made for Assassins.


Lesalia: ?????????? - Reserved for some crazy idea or another that may turn up or some otherwise needed role for balance.


I raped thesaurus.com for a few of those, bite me.  The names would've been too boring else.  Fairly basic right now, but the restrictions R999 wanted me to work with (no status protection, no elemental properties, few initial status) makes me think they were meant to be that way.  Nonetheless, outside of a bit of number dickery they should be roughly equal to each other because of how the oneshot / twoshot ceiling is designed in IA and such.

Suggestions for slight number shoves to better balance / critiques / ideas for Lesalia's goods / etc welcome.  No weapons at this time because R999 has all that info and I think wants to handle those himself, but I'm unsure.  Shields are included, however, and their current conservative design is mostly so that they can easily be adapted for wide-range use without issue since I don't have the exact specifics of what units can equip them.

Accessories:  No naming scheme besides being freaking awesome.  Includes Gauntlets, Rings, Armlets, Mantles, Shoes.


Gauntlets:


Rings:


Armlets:


Mantles:


Shoes:


I used Always: Status over Initial: Status if a status was meant to be crippling because Initial: Status is almost always incredibly easy to work around and barely a draw back if you're competent... especially since you can like, heal it with a single action from a different unit or even the afflicted unit.  Obviously positive status is always Initial: Status only, except in the cases of Feather Boots.




For those wondering, these are the numbers that were used in the making of these equips (Human max statistics for HP/MP, max allowed equipment HP, etc):



Notepad file containing this information also attached for convenience's and simplicity's sakes.[center:t4cfkhne][/center:t4cfkhne]