Final Fantasy Hacktics

Scripts made this so much faster than I had hoped.
What you are seeing is 13 units on the same map, which doesn't sound like much, but there is more to it: in vanilla having more than 10 monsters at the same time was not possible, the remaining 3 (13 is the unit limit in general) would be invisible. Not anymore. (Gria have always been monster-sized, because of the wings).

I made some scripts to go through each animation and reduced the tile count of all of the offending ones manually to 20, you can now have any units you want in your map provided that you stay below (or at) the 13 units limit (the Judge IS a unit), I reduced tile count by changing which objects the sprites are made out of and shifting tiles, but without changing not even one single pixel of what they look like in the end. They will, however, behave a bit differently when moving behind tiles that cover them and similar, let me know if any of the animations looks unacceptably bad in those scenarios (most edited sprites are for attacking animations so I hope there won't be big issues).

This was step one on my plan for making an animation template, although for now it doesn't mean much unless you really really wanted to have that many monsters in your map. With the template all animations will be of the same size because there's just no reason not to use big animations anymore, this means I can have just one template instead of two which is easier for everyone.

The next step is to make a way to give units attacking animations for weapons they don't have, including units that, like Marche, use that slot for something else entirely, it will also include the data for them out of the box so if you wanted to say give Archers knives, you'll be able to.

When that's done I'll be able to release the template too, which will consist of one event file in which the user will define the race (from the playable races, for special animations unique to that race) and one sprite sheet. Users will drop this sheet on an .exe which will return a GBA ready version of the graphics. Of course if someone wants to edit the template to add some new animation or similar they'll be able to do that too.

When it is complete it will be part of the job customization.

You can check out the fixed animations with lower tile counts by downloading the attachment and including fixedAnimations.event in your buildfile. Please let me know if you see anything weird while playing around with it.

Update:
I wrote a python thingy to make weapon animations based off of the existing ones, no extra sprites needed.
(This is not yet included, it will be included when the next update comes).

This means all jobs (and races) will be compatible, animation-wise, with all weapons.

Please keep in mind these were written by a script and there are over 1200 animations, I won't be testing all of them individually, if you notice any odd-looking animations be sure to let me know.

As I previously said the next step is the write the animation template, I'll let you guys know when that's done.

If it helps people understand better how it works then it's not a waste of time.

I don't think there is much need to merge jobs, the job table could be repointed and expanded and in vanilla only 0x73 (115) of them are used, that leaves us with a bit over half of the IDs (140) being unused, I doubt anybody is going to have issues with that.

If the day where we need more than 254 jobs does come then what I would suggest is making a job table for each race, which would be a lot of work too but would mostly preserve the vanilla layout of the data while expanding greatly on the job IDs, with 254 jobs for each race. I say 254 because the first one is a dummy to represent no job and the second one is data for using items.

Most of the data in the tables and the data.event files are either completely new, an extra way to load data on top of the existing one or replacing hardcoded values with lists, I haven't changed how the majority of the data works. When I say "what I would do" I mean that is how I would write the data in Event Assembler, the data itself would still be in the same format as the ROM data once inserted, I'm not doing anything that AIO doesn't do there.
The way a lot of routines work would also need to be adapted to this new ability lists, for example, when checking if an ability is an action ability or not you would need to find every job of that race, find the pointer to their ability pool, find every pointer inside there and check what type of ability it is, this is not just much more work than just checking one list for one race but would also, as I said, require a complete rewrite of many routines.

I didn't decide to make race ability lists or job data this way, that is just how they are in vanilla, changing them would take a very high ammount of effort and they are perfectly fine as they are right now.
What you propose for ability lists would, I think, make it take more space and make it harder to use, it could make reusing abilities on different jobs harder too.
Abilities would still be tied to race anyway so we wouldn't be adding anything to it.

For anyone reading that wants to understand why this is the case:
Keep in mind the game needs to at all times remember what abilities each unit has, there is only one way to do this and it is to keep track of it in RAM, the game also needs to know which abilities the unit has equipped.
To do this, the game in vanilla reserves a section of the unit's data in RAM to store the progress of each ability, it takes one byte for every ability, there are about 0x8E (142) bytes reserved for this because that is how many abilities humes have, and humes are the race with the most abilities.
This is why ability 2 for hume and ability 2 for nu mou are not the same, they use a different list so they can keep track of their own abilities, otherwise to store information for all possible abilities this 0x8E bytes section would need to be increased to... who knows how much, but a lot more, probably around 5 times as much, that's a huge ammount of data considering that these 0x8E bytes are already over half of all the data saved for a unit, this would not only need to be stored in RAM but also saved, which can be costly considering this is a game with a lot of moving parts and 3 whole save slots (one of them being the suspend one).
Additionally, the sections that keep track of the equipped abilities would need to be increased to 2 bytes, and all routines that deal with ability IDs at all would need to be updated to use 2 bytes for them instead of 1.
With the 1bit abilities engine hack the number of abilities that are kept track of is increased to 0xFF, yet it only takes up 0x20 (32) bytes because it no longer has to keep track of AP progress, it does not increase it past 0xFF because of what I mentioned earlier about equipped abilities.
I hope this explained why it just doesn't matter how you define abilities in ROM, having a list of abilities by race is the only way this can work.

As for the structure of the data itself:
Remember, data means nothing on it's own, there is nothing specific to a byte that says "this is HP", data is what the game makes of it, to reestructure a table what you actually have to do is rewrite all code that interacts with it, which is as much of a pain as it sounds like. There has to be a really good reason for that. It would also mean I would need to provide new tables with adapated vanilla data, or make the routine able to work with both, if you look at how tables like the portrait palette tables or the job icon tables that's what I did, these however are way simpler and they are providing a solution to the limitations of the game, for example: job icons above a certain number are hardcoded to be Monster except for specific IDs which are Expert, that is a pain to work with so I decided a new table was a good choice.

What you called "Special" is already a thing, it's not part of job data, it's part of character data, every unit has a character ID and IDs over 1 replace the graphics with that character's graphics for all jobs.
Also, is there such a thing as base race stats? Or is this a feature request for something that does not exist in vanilla?

There's no option to change job races in the installer, you can use AIO editor like normal, it's not ideal though.
In the future I'll probably make and include tables for editing job data as .csvs, as well as making the current ones into .csvs.

In the meantime you can use a macro.
Place this anywhere within your buildfile:
#define setJobRace(jobID,raceID) "PUSH; ORG (0x521a14+4+(jobId*0x34)); BYTE raceID; POP"
After that, you can use setJobRace(jobID,raceID) to set the race of a job.
You would replace jobID and raceID with the numbers you want to use, but only when USING the macro, not when defining it.

Keep in mind this will have no effect on units that already exist in your save.
Special characters don't actually have races, only jobs do, units are given the race of the job they have when they spawn so Ritz is a Viera because she spawns as a Fencer, not because she is Ritz and NOT because she is currently a Viera job, only because she spawned as one, if you want her to not be a Viera then you'll need to go to the data she uses when she spawns/the data for her join request and change her job there.

However, even though you can set someone to hume and still have them be a fencer, the abilities will be all wrong, this is just how the game works, the ability list is tied to race and not to job, otherwise every unit would need space to save AP progress of every ability of every job of every race. Also Marche has no rapier/spear animations, similarly Ritz probably lacks some hume animations, like the animation for Provoke and the animation for Advice.
Even worse, they probably have some other unrelated story animation on the same slot that would be used for these animations, I do have an idea on how to solve this but it will take a while.

So yeah, setting an existing job to be of a different race with no changes is not going to do much, you need to repoint the ability list of the race, add the new abilities you want this job to use, then you can make a new job/edit a existing one to use these abilities and be of the race you want, and you also need to either take care of the new animations or be sure that no new animations are needed.

The ability lists are at 0x51ba84, each entry is a pointer to the list for that race, 0 being items, 1 being hume. If you want new races you'll have to repoint this table, if you just want new abilities for an existing race you'll only have to repoint that particular list. No race can have more than 0xFF abilities so be mindful of that. Also, the first entry on these lists is always 8 bytes of 0, I haven't looked much into that so I would recommend that when you repoint the list or make a new one you have it start AND end with 8 bytes of 0.

To repoint it what I would do is go to 0x51ba84+4*race id in my hex editor, go to the offset pointed to by the entry there, copy all the data for the list and save it in a new .bin file (also in the hex editor), I would place this file on the same folder as my buildfile.
Then I would make my new list like this:
ALGIN 4
nameOfYourList:
#incbin "path to the .bin file"
(insert new data for abilities here)
BYTE 0 0 0 0 0 0 0 0
And finally, to repoint the list:
PUSH; ORG $0x51ba84+(4*raceID); POIN nameOfYourList; POP

The data for an ability on that list would look like this:
SHORT nameID descriptionID abilityEffectID; BYTE abilityType apCost

Of course you would replace raceID, nameID etc with the values you want to use

If you need help getting this to work or setting it up feel free to send me a PM.

Chances are the new wheels are installed just fine, you just have no race that has over 12 jobs, the L and R buttons only show up if there is a second page and this only happens if there's more than 12 jobs.
For the gif I set all jobs to hume so I could show the different pages, of course that doesn't mean the jobs would work correctly, it was just a test.

As for Babus and Ezel, the fix to make them regular Nu Mous is not finished, as a I said "keep in mind some of the images are taken after changing data, such as setting Biskamatar to be a Hume job", this is also true for Babus and Ezel, I just set their race to Nu Mou to show what can be done, by default they'll remain in their special race which means they have no jobs to change to. Even if the fix was completed the Babus and Ezel of your save would STILL not be Nu Mou so they wouldn't get the option to change jobs either.

So TL;DR: I think it's all working, you just haven't made changes to vanilla so it all looks normal, like intended.
Please try making a copy and setting some jobs to be bangaa or something to test if you want to check if it's working.

This update is a pretty big one!
It includes my recently released job/race customization stuff, which means 1bit abilities are here.
For now that doesn't change much but look forward to new things that make use of the freed up save space!

Please remember that saves done with 1bit abilities on are NOT compatible with saves made with 1bit abilities off and vice cersa.

[Download]

Changes:

• Reworked the way the game ties abilities to jobs and jobs to races.
     Please read this post for more information on that, how to use it and what it allows: [click here]
     It adds many options so be sure to check it.


• You no longer need to visit the job change menu to unlock jobs.


• When Judges are disabled the "Law" button on the world map will no longer appear, pressing L will do nothing.
     The yellow and red card icons and count on the status screen also gets removed.


• Reworked the way the JP purchase figured out which skills were being drawn or looked at to prevent future issues.


• Added 1bit abilities, along with an option to disable them and use AP like always.


• There is also a new way to load abilities for spawned units, which is optional to use, and allows for abilities up to 0xFF to be loaded.
     In vanilla there is only 5 words for known abilities in formation data.
     By setting the first 4 words to 0xFFFFFFFF the last word will be used as a pointer to an 8 word list.


• Added manual sorting, which allows swapping units around, changing their unit number.
     There have also been some fixes done to it.
     Fixed some graphical stuff and Marche not being the first unit hanging the game in some events.


• The Link option has been removed.
     Adding support for it would have been extremely hard.
     The Link option has been removed because it was now both useless and potentially dangerous.

   
Fixes:

• Replaced the AP icon with a JP one at the shop.


• Made JP icons that replaced AP ones use the right palette.


• Fixed the Action/Support/Reaction/Combo icons on item info.


• Fixed some stuff related to drawing the 999 JP cost.


• The menu no longer goes back to the unit's current job after purchasing an ability from a different job.


• Purchasing abilities now correctly unlocks jobs, and the menu is updated instantly.


• Imprisoned and dispatched units can no longer buy abilities.


• Made the movement confirmation hack not explode on you when you tried playing the game.


• Made the movement confirmation hack not lock the game after looking at the status screen of a different unit.


• Fixed the abilities lists not working correctly during battle if there were no abilities to display for the current job.

Options:

• Added an install1bitAbilities option, when defined 1bit abilities will be used, otherwise AP will work same as always.
     This includes all graphical changes that replaced AP with JP.
     Current AP will also be drawn in the abilities list. It looks a bit different than it used to.
     On by default.


• Added a quickStart option, if defined the two first fights will be replaced by a new event.
     The new event allows the player to name the main character and the guild, then throws them on the world map.
     On by default.


• Added a noStatVariance option, which makes non-player units always have the same stats if spawned at the same level and job.
     Off by default. This thing will probably see changes in the future.


• Added an option to have Morphers transform when they morph

Here are two screenshots comparing 1bit abilities and non-1bit abilities things:



There were a lot of changes, I think I covered all of them but I might have missed some, sorry if that's the case.

Next on my list is to continue with reducing tiles in animations, which I talked a bit about in a previous post.
The idea is to get animations that use too many tiles to use 20 or less.
Playable jobs use up to 16, which I have lowered to 12 just in case, currently I'm working on monsters.
The point is that if we manage that we'll be able to use big (monster-sized) animations only.
This would grant more freedom on animations and make them easier to work with and install.
It would allow 13 monsters on the map at once, making a 6v6 of monster sized units and a judge possible.
Currently if you tried to do that you would find that you can only have 11 units on the map before they go invisible.
Of course, doing this without changing what the animations look like is quite difficult so it might take a while.

As for what will be done with the freed up space, I was considering a few things:

• Squares moved in the current turn.


• JP pools for each job of the unit's race (undecided on max job ammount by race).


• Custom names for generic units without forced names.


• Stat decimal fractions, which would add up to 1 and grant a point, removing the random factor of growths.


• New counters, there's already a kill counter but we could count other stuff as well if people are intersted in that.

Also, in my testing I was unable to get the enemy to ever use "Steal: Ability", do you guys know if they CAN?
If you have a method to make them use it, please tell me.
And I mean a proved method that has worked for you, not just an idea that might work, I tried all I could think of for days.

Remember, if you have any features you would like to see in (or changed), let me know, there's several things I want to touch up, like how JP is earned in combat, any suggestion you drop here will be considered when I add new stuff.

[Download]

Ah, I guess I clicked on it twice when selecting the files to include, silly me.
Check now, it should be in there.

Download: https://github.com/LeonarthCG/FFTA_Engine_Hacks

New Update!
I've done a lot of progress, I made graphics and animations for all jobs of all races and a couple of special characters so that they can use all abilities (for example, Marche could use Jump or Montblanc could use Parley). Any previously playable job should now have animations for all weapons and all generic job animations (I have not checked if there are animations unique to special jobs).
The characters that got these are: Marche, Montblanc, Ritz, Shara, Babus, Ezel, Cid, Llednar and the judges you get to fight. And of course all the playable generics.
Just like the weapon animations, the animations for the abilities were done with a script.
Please let me know if you notice anything that doesn't look right.

Here are some samples of the new animation stuff:


However, finding which abilities use which character animations takes a lot of time, this is what I said I would need help with.
I have added support for all the abilities I found, but there may still be some missing, if when using this you notice any of those, let me know.
Additionally, if you could help complete this list of which abilities use which animations it would be of great help:
Talking: Advice, Wyrmtamer, Parley.
Fast swing: Saint Cross, Tremor, Lancet, Far Fist
Spin: Whirlwind, Mow Down, Wild Swing, Swallowtail.
Charged punch? Kinda weird imo: Revive, Exorcise, Holy Sign.

I know the descriptions of those animations isn't great so please refer to the originals if you want to see what they look like.

Here's the changelog:

• Abilities that cost 0 AP/JP should now be unlocked by default, even if using 1bit abilities.
• Added the complete animation template. This allows for new animations to be made by just editing an image.
     The template works for both regular and water animations.
     Animations made with the template come with animations for all weapons and for abilities from all playables jobs.
     There is one exception to this: I did not make animations for being morphed while in the water.
     Unless there's enough demand for that I would suggest to use the Morphing Moprhers Morph hack instead.
     I also didn't make flying animations for everyone but it's not like any playable has those in vanilla.
     If someone takes the effort to make sprites for those, I'll add them in.
• Added animations for all weapons for all playable jobs, Marche, Ritz, Shara, Babus, Ezel, Cid, Llednar and enemy Judges.
• Added animations for all abilities from all playable jobs for all playable jobs, Marche, Ritz, Shara, Babus, Ezel, Cid, Llednar and enemy Judges.
• Jobs will now correctly be displayed as mastered (the little star) when using 1bit abilities.
• Instead of showing all jobs on the ability list, only jobs the unit can change into will be shown.
     Jobs that the unit somehow has an ability for will be shown even if the unit can't change into them.
• Similarly, only the current job and jobs the unit has abilities for will be shown when equipping a second action command.
• The Item option will not appear for monsters, and it will appear greyed out for the Alchemist. I think this is clearer.
     Of course which jobs get or don't get Item can be changed in the job and race customization hack data.
• Changed how abilities are displayed when checking what abilities an item teaches.
     It's now just generally less hardcoded.
     You can set any abilities and any jobs and all of them will be displayed correctly.
     However, just like in vanilla, there is only one icon displaying what type of ability is being taught.
• Units can now be made to spawn with a Combo ability.
     The byte used is the last one in the unit entry, this is the last Unknown Values in AIO's formation editor.

   
Here's a comparison of the old vs new window for the abilities an item teaches:

It might look worse at first, but unlike vanilla this can update the ability name and cost instead of just changing icons.
This means you can potentially have 9 completely different abilities being taught by an item, and all of them will be displaed.
You can also customize it with empty entries or move the old entries around to make it look like it did in vanilla.
For example, instead of the vanilla:
Fire Fire Fire Thunder Thunder Thunder Blizzard Blizzard Blizzard for the Rod, you could get it to look the same as vanilla with:
Fire Thunder Blizzard Fire Thunder Blizzard Fire Thunder Blizzard. If that makes sense. It's hard to explain.

Currently there's an issue when scrolling through items in the equip menu, if you encounter that just press R to hide and display the window again. It's being looked at so expect a fix for the next update.


If you have requests about more job/race things you would want to see be customizable, please let me know.
I already have a few things planned though, expect a custom animation template in the future.

Most importantly, if you have doubts about how to use this, check the readme, but don't be shy to ask either here or via PM, I don't think I did a great job with the readme anyway.

As part of my job/ability assignation rework thing (which is honestly growing into a much bigger thing than I imagined) I'm messing with vanilla animations, trying to reduce the tile count so we can have more units at once.
So far I managed to get human sized units down to 14 from 16, I aim to go for 12, but that's not what I'm here for:

I grew tired of exporting and reassembling the animations by hand so this morning I wrote a script to do just that for me.

I attached a zip that includes all the sprites I could rip, there were some issues with weapons, I guess there's something different about them.
The sheets are separated into 64x64 cells, they have no outlines though so if you want to see that you'll have to use some program like Usenti or Aseprite to set a grid.
Only one palette is included in the images but I also included a second .rar that has an image with all 3 palettes, the special ones (such as Totema palettes) are missing though.

Right now there isn't a huge ammount you can do with these, other than edit them, but I plan to release a way to insert them in the future too, similar to how I inserted the hunter gria.

You'll notice that water animations are on their own sheets, that's because those are actually different animations with their own IDs, you can change those by changing the second value under "Unknown Values" in the Sprites/Unknown tab of the Job Editor in AIO.

If you notice anything wrong with the sheets (other than they all using the blue palette) please let me know.

https://www.romhacking.net/utilities/606/
Download NUPS, open NUPS, select your ROM, select the patch, patch the file.
This patch is for the USA version of FFTA (the one that's english only).
After you are done patching Steal: Accessory should be able to steal shoes.

I did some more checks and you guys are right, I was too quick to assume Fight had 30 Power, it just so happened that both item setups I tried added up to 30 attack...

Doing this I also discovered that Marche's unarmed attack won't change when he changes jobs, it stays at 10, there's a byte that's like the "display" job which is pretty useless from what I can tell, most units just have it be the same as their job but Marche has it as 0x50 (one of the placeholder jobs next to runeseeker and hermetic), since it's mostly empty it doesn't make his job name stay the same when he changes jobs, but it does affect his unarmed damage which is kinda stupid if you ask me.

I always assumed this was a placeholder for a special job but maybe this was just a way they had before they programmed character IDs to have Marche and other special characters look different to the other units, we don't have much use for it anymore though so I'll "remove" this byte (by making it be set to the same as job for all party characters) and see how that goes.

As for Doubleshot I haven't checked but it's likely that it just makes the unit use Fight twice.

I'm glad this topic came up, now I understand the damage formulas, although I find them pretty weird, I would expect Weapon Atk to translate directly into damage and not to be multiplied by the "Extra" Weapon Atk... Mostly because there's no way that I know of to check specifically your extra attack.
This probably makes attack too strong of an option on the late game, I haven't checked how it works for Double Sword but we all know how good that is.

If it were up to me I would change how the Fight formula works, changing the Power to always be the same, maybe it would depend on weapon type (or job), this way stronger weapons wouldn't escalate damage so much, it would also make the attack stat less of a lie. Different damage formulas for different weapons/abilities could also be an option, and it would probably be way more interesting.
What would you guys think about something like that? What damage formulas do you think would work best?

I'll check more of this when I have the time but why would Body Slam damage be independent of weapon?

Looking at the vanilla data for it, it seems to me that it is a regular attack with a higher Power and the recoil damage, I don't see anything special about it that would make it not take the weapon into account.

Just because the animation doesn't display a weapon it doesn't mean the weapon isn't adding damage, I even found the routine for the formula by setting a break on the weapon's attack stat.
I can confirm that in vanilla the formula is what I listed in my previous post.

However, changing the Weapon byte in AIO does change the damage so there's something going on there, I changed it from (according to AIO) 0 (not used) to 1 (used) and the damage dropped from the formula in my previous post to the same damage as Fight, so that's something. I didn't check if it was using the same formula or the damage just happens to be the same, though.

I did several tests in vanilla and the damage formula for Body Slam is:
(Caster's Weapon Att - [Target's Weapon Def / 2]) * Ability Power / 100

Body Slam's ability power is 45, Fight's ability power is 30.

I followed the routine and saw all that happen, unarmed attack is added if there's no weapon equipped, attack is min 1, I never saw it discriminate between stats that come from weapons vs stats that come from other items, or treat stats any differently in Fight compared to Body Slam.

However, with just this formula the damages you showed make no sense, I assume there is something else going on here, there must be support abilities or debuffs at play, I noticed you are using a two handed sword too, generally if you are going to be doing something like this you would want to remove all those unknown variables. You never even told us what Marche's defense is, or if his equipment and abilities have stayed the same between all tests.

Also, Estreledge gives 5 defense and res in vanilla, it's giving 20 and 10 here, what's up with that?

There's just too many things you didn't tell use here, you also didn't provide a save I could use to test, not really much I can do here.
If this is a modified ROM I have no way to know what you have changed so that certainly doesn't help either.

Quote from: Diedrik on January 01, 2019, 12:10:20 am
How much work would it be to make all classes able to use any weapon type? Oh, also is the update for Skill Purchase now compatible with Manual Sorting? And/or do I need to change the offset in the build file for that or something? I know last time when I just tested the UPSes together they resulted in a reliable crash.

Giving all jobs animations for all weapons it would just be some tedious work, the graphics already exist, it's only a matter of making the data for the frames, I have an idea that will allow that without replacing the special animations the jobs may have.
As for the patches, they have always been compatible, if you have trouble mixing them send me a pm and I'll walk you through it.

rrs_kai:
That's the palette, not the sprite, if you set the player morpher to be yellow then his monsters will be yellow, which are the rarest, it's the least used palette by far but it's not unused, Montblanc, creams, thunderdrakes and some npcs use it.

As I have explained before there is no need to "separate" the thiny patches, they are already separated, they are just included in the same download, you can go grab them from the jp purchase system and use them on their own, If you guys need a tutorial on that just let me know. If you are talking about making .ups patches for all of them, that's not possible.

When you assign a Battle Sprite what you are truly asigning is an index on a table.

In this table there's a pointer for every battle sprite.
If we follow one of these pointers we'll find another list of pointers, one for each animation this battle sprite has, some of these are 0 because the game has no need for them, we can simply create an animation elsewhere in the rom and point to it in this list, making it use graphics it already has or new ones, doesn't matter.
You could even use the pointer for an animation of a different job and it would also work just fine.

When I say animation I'm talking about a list of data for each frame, just that: data of the location of the graphics, the location of the data for the oam, duration, position...

Generally speaking all playable jobs have the graphics for all animations of all other jobs, excluding race exclusive things (such as Advice and Morphing). There aren't that many different unique graphics, all attacking animations use the same 3 (or 6 I guess since there's different graphics for when they have their back turned towards the camera), sometimes mixing in the graphics for walking too.

The animations are always in the same order, lance/rapier animations will always begin with the 47th one:


A different issue we would run into is that some jobs have different animations in slots they would normally not use, marche has story animations where his lance animations would go, I have already planned a workaround for this though, which will take advantage of the free space that exists in the tables.

• I'm using multiple sprite sheets I found on the internet, none of which is complete, some of the frames were done by a friend bust most of them I fixed myself (the colors and all that).


• I use usenti and aseprite, aseprite for the editing, usenti to make sure the format is correct.


• There isn't an easy answer to this so I'll detail it down below.

There are two different sprite sizes, 0x10 and 0x18, 0x10 is used for playable jobs and 0x18 is used for monsters, Grias use 0x18 because there would be no way to fit them in otherwise.

0x10 sprites may have up to 10 unique 8x8 tiles in any arrangement, 0x18 sprites may have up to 20 8x8 tiles in any arrangement.
I don't really know why they are 0x10 and 0x18 but those are the numbers the game uses.

Animations are actually metasprites, composed of several multiple sprites, on top of making the graphics you also need to make sure to use (or create!) the right metasprite data for them. This is what I mean when I say "any arrangement", your sprites don't need to stick to the same rectangular shape every time, in fact, vanilla doesn't, many poses have special metasprite data for them, often specific to only that pose, and even though monsters always use the same data and are all 32x40 sprites nothing is preventing us from using different data to use a different shape.
Something similar happens with portraits, the Gria portrait I made is composed of 11 different sprites that move together, which means I had to go and make the data for this collection of sprites.

There is no limit to how long your sheet can be (you would sooner hit the limit of the ROM size), or to how many frames an animation can have (well, there is, it's 4294967295 frames), your spritesheet can be of any shape as long as the tiles end up in the right order, I used 32x(40*ammount of frames) for the gria animation, along with a script I wrote to reorder the tiles correctly.

I need to use a script because the way the sprites look to us is not the way the are stored in the rom, the GBA will just make sprites from left to right, top to bottom using tiles ONLY from left to right, there is another method of reading tiles for sprites but the game does not use it, and for good reason, even though it is a more human readable way of loading them it makes having as many possible sprites on screen a giant pain, these are often called 1d and 2d mapping modes, check the link at the bottom if you want to learn more. Anyway, this means the game needs a different order than the one that is natural to us, here is an example:

On the left, what we end up seeing and what my sheets look like, on the right is what the game needs and what my script outputs if given the image on the left.
Now the same image, with every sprite that forms the complete frame marked with a different color, maybe that will be easier to understand:


Only one frame is ever loaded at a time so there is no limit to the size of the sheet, sprites don't even need to be on a sheet, you can have the tiles of one frame at the beggining of the rom and the tiles for the next at the end of the rom.

In the end the animations aren't really difficult to do (not talking about graphics here, just the data for the animation), the process is just tedious as you are likely going to be referencing existing animations over and over. Luckily unless you want some special animation, like some non-generic characters have, you are likely just going to want the same animations for every job, this means we can build a templete that can be used for any new job, with only the graphics needing to be replaced.
I already did this for the Gria so when I make the next one I'll already have most of the tedious work done, however this one only works for monster sized sprites, which are much easier to work with, doing this same thing for small sprites will take a lot more time, and a much more complex tile reordering script. I guess I could just make several different scripts, too, that should be easier.

If you want to learn more about how sprites work in the GBA, give this a read: https://www.coranac.com/tonc/text/regobj.htm
Section 8.2.1 is the most relevant to what I explained.
If you are interested in how the GBA works I recommend to give the whole Tonc text a read!, I'm personally not interested in C hacking so I skip over that stuff, but just the data on the GBA itself is worth a read even if you don't care about the rest.

To give a wheel to Ezel the easiest way would be to make him a Nu Mou, once everything is ready I will include an easy way to do that with the download.
You can totally give a special job to Ritz or Marche and have only them be able to switch to it (or even see it, which I recommend), with Marche you would have the issue of not having any free abilities on the hume race, unless you have 1bit abilities, but for Ritz you should have no issue at all.

Ezel wouldn't get a wheel by default because he has no jobs available on his default race, since I already made a routine to lock Babus' and Cid's jobs to their character IDs.
This is a section of the table:

The first pointer is the ability list, it's 0 which means that the vanilla list of abilities will be used.
The second pointer is the unlocking condition.
The third pointer is checked even after the job is unlocked, and prevents units from seeing the job if they can't fulfill it.

Only units that can see more than one job for their race get a wheel, otherwise the job change option is greyed out.

There's only one job that I made a list for so far, other than for testing, Red Mage:
vieraRedMageAbilities:
BYTE 0x16 0x17 0x18 0x19 0x21 0x1B 0x1C 0x1D 0x1E 0x1F 0x20 0
This list is the same as the vanilla one, but the Cure ability is replaced with the same Cure that white mages have, freeing one ability and making sure they are mastered at the same time even when using the JP Purchase system.

If the system can't find a custom ability list it will use the vanilla one so there's no need to make lists for most of the existing jobs.

On a different note, I finished all the Gria Hunter animations, including water ones:


A friend helped me with the portrait too, making a version with colors that play nice with palette swaps:

I also figured it would be nice to be able to set which races get which random names so I added that to my list of things to include. I have some ideas on how it should work but there's a few routines to worry about so it might take a while to complete.

I think you misunderstood what's going on.

The job/ability assignation rework system does not need the JP purchase system, the JP purchase system needs the job/ability assignation rework, these are two completely different things:

The JP purchase allows for abilities to be bought, with this new way to get abilities and the job/ability assignation rework working together, we can have 1bit abilities and save a bunch of character data space for other things. 1 bit abilities will be an option in the JP purchase system, not mandatory, at least that's what I hope.
This system also includes the movement abilities, which replace combos. Combos would be completely broken anyway since you would be able to use them once every turn, since you would get JP awarded for just attacking.
I am thinking of ways to get combos back though: Maybe a FFTA2 style thing, a chance at the beggining of the turn to get the Combo command for that turn only, this would only happen if you had mastered the job, or it would happen more often the more abilities of that job you have mastered (compared to the total number of abilities on that job), the combo performed would depend on the current job.

The job/ability assignation rework is a completely different thing which doesn't need the JP purchase system for anything (unless you want 1bit abilities), it allows the assgination of custom lists of indexes of abilities to jobs instead of the vanilla approach of from X to Y, it adds new options to make expanding the number of playable jobs and races possible and it adds new editable options for things like default unlocked jobs, job unlock conditions, job icons and jobs that can't use items.
None of those things have anything to do with removing AP and in fact by default the system uses AP to check if abilities are mastered.

The morpher thing will be included with the job/ability assignation rework because I felt it's too small of a thing to go on it's own, since it's job related that seemed the best place to put it in, if you guys want the thing on its own I can do that too. Or you could wait for the job/ability assignation rework and grab it from there, same thing.

To give morph to blue mages you would also need to port the abilities from the nu mou to the hume race, there wouldn't be enough space to do that without replacing existing hume abilities on the list, you would need to replace existing hume abilities or use the 1bit abilities thing I'm working on (so no AP).

Other than that, yeah, it should work as long as the name of the moveset is Morph.

I think other races being able to morph is not a highlight of this though, custom animations aren't that hard to do, you could have just made new animations for the blue mage being morphed, or used the standing ones for it.

The custom animation talk reminded me I should finish my hunter gria too.

Small Christmas update, today I decided to make something I always wanted as a kid, as a kind of gift to my child self

When I was a kid I heard from my cousins that morphers could transform into monsters and use their abilities, to me that was the coolest thing I had ever heard about this game so I started training a Nu Mou just to see it, once I had a morpher I found out I also needed a hunter so I had to get one of those too.
When I finally figured out how to capture a monster I was extremely disappointed by the fact that after "transforming" morphers would look like they were late to school, waving their arms and sweating, nothing to do with what I had imagined, they only transformed for abilities and then immediately went back to looking silly.

So here I am, 15 years latter, fixing the issue and making my imagination into reality:



This will be included as an option for the job/ability assignation rework.
In case it's not clear yet, this engine hack makes morphers actually transform into monsters, changing their aspect and their movement types.
Morphers will still use the same palette they were using before morphing so player morphers will always be blue or green.
I call it: Morphing Morphers Morph.