Final Fantasy Hacktics

Can't really do much if there's no replication steps.
I don't know why this would happen, much less why it would happen just sometimes.

If you can get me a savestate of just before you lose the JP and tell me which action makes you lose it that would allow me to easily fix the issue.

QuoteSo, should I edit "movement name.s"?

I have no idea what file you are talking about, but if it has a .s at the end the answer is no, that is asm source code, the engine hacks are made so that you never have to edit any of the source code (unless you actually want to change how the systems themselves work).

You edit movement abilities the same way you would edit any ability, you don't need to do anything special.
Certain combo ability effects have been replaced with movement ability effects, and that is all, if you make a Moogle combo use the Combat Combo effect (combo effect 1), then that Moogle combo will also be Move+1, if you made that same Moogle combo have effect 7 then it would be Ignore Height. And to change the name you can, again, do it like you would do with any other ability. If you set the name to 0x701 it would be Move+1, 0x702 for Move+2, and so on.
Here's a table:

QuoteThe AIO lists totema as an A-ability. So, would it be possible to replace totema command with another skill?

I mean, possible, yes, of course. I have not looked into it, though.

QuoteIf yes, does it work fine without messing up Li-Grim's Descent skill (summons random totema)?

If you edit the Totema skill themselves then yes, it would mess up Descent, if you edited which ability the Totema commands use then no, it would not mess with Descent at all.

QuoteHow to make it stay at 1 law the entire game?

Have not looked into this either.
If I had to guess it's just some flag that gets set? So you would change the events so that they are not set or (more likely) change the check for it so that it's always false.

QuoteWould it then be possible to have player Floateyes be the regular blue and enemy Floateye be Ahriman red?

It is, and it's not different from how playable jobs work. You can do that in a hack if you want, I'm not going to do it.
In case you don't yet know this, I'm not making a romhack here, I'm making tools people can use to make their romhacks, you can take my stuff and go make your own thing if you want the features you are suggesting.

QuoteHow do the player class palettes work?

There's only two palettes jobs use, and they are the same that monsters use (minus the yellow palette, which no playable job uses, only monsters and special characters like Montblanc use that one), each job has a different palette based on the faction the are in.
You CAN make Floateyes be blue when on the player side and red when on the enemy, side, you CAN'T make them be green or purple or whatever, without changing their graphics. If you don't make new graphics they can only be blue, red or yellow.

I think you still haven't understood what a palette is and how it works, so I'll try to explain it:

These are the three palettes.
When a unit is using the blue palette, it can only use the colors you see in the top row.
If that unit changes palettes, you can't just decide what color each color becomes, the palettes are shared for all units so you can't just change them. blue becomes red, green becomes purple, you don't get to choose.
Therefore, if you want a Floateye that is not red, blue or yellow, you need new graphics that use the green/purple/emerald color slots. I suggest you look up "indexed color" on google if you don't understand what I'm saying.

QuoteWhat do you mean by cuts on the available color variations?

Say someone wants to make new types of Ahrimans. For each one, they would need to make two new colors instead of one, and they would have half as many possible variations as a result, for example, they wouldn't be able to have a green one because it would be used by player Floateyes and they wouldn't be able to use a purple one because it would be used by player Ahrimans. As a result, they could realistically only make one new type of Ahriman. Making a change that's going to have to be undone by anyone that wants to add new monster types doesn't sound very productive.

However, if all the Floateye types have the same palette regardless of side, you can easily have at least 6 different types of them. This doesn't make an impact on playable jobs becuase each one has different graphics anyway, but for recolored monsters it can be pretty important.

Anyway, again, just don't like the idea. I'm not going to work on something I don't want to see.

QuoteCan you expand on the point on recolored enemies using the same graphics?

There's not really more to expand on?
If you change the graphics for the Floateye, the graphics for the Ahriman also get changed, they are literally the same graphics, they just have different palettes applied to them.

QuoteDo you mean you could make the Ahmiran use entirely new graphics instead of being a recolor, relatively easily?

I mean, yeah?, but what I explained makes it harder to make them use entirely different graphics, because in vanilla they don't... And the only other alternative would be that they do, so this is harder. It's not hard, but it is harder.

QuoteI'm guessing the graphical glitches would be flickering or parts of sprites being cut off?

No, it wouldn't look like that at all.
The units themselves would look just fine, what would be broken is stuff like the cursor and the status bubbles, which would get the sprites for the units written on top of.

QuoteThat being said, how hard would it be to add player Monster class palettes, just like the main races have player and enemy palettes? Like going with Floateyes again, player Floateyes would have a sea green palette as opposed to the straight up blue palette of the enemy Floateye.

I already explained the palette slots are taken. You can't do that. A palette is not just the colors a sprite uses, it's a set of 16 colors in a specific order which are applied to indexed graphics, you can't apply the palettes in a different way, if you want a green Floateye or a purple Ahriman or an emerald one, you need new graphics. You could have a yellow one with no new graphics, though.

In short, what you are asking for is having different graphics, not just palettes, based on side.
It would be possible, but it would mean you would need two versions for every monster, which I really don't like the sound of, this cuts on the available color variations you could otherwise use in your hack and doesn't really add anything, in my opinion.
Also monsters changing colors when recruited sounds plain weird to me for some reason.

QuoteRight, so it sounds like you can't do a custom palette. I wasn't aware of that limitation, but it makes sense.

Keep in mind that even if you can't make a new palette, you CAN make monsters of "new" colors, making a green Flan is as easy as grabbing the already existing one and changing the index of the colors it uses. In vanilla all the recolored enemies use the exact same graphics as their other versions, but there is nothing forcing it to be that way.

QuoteSo when a morpher morphs in your hack does it take the palette of the first monster of that type?

You can specify which monster the Morpher morphs into in the morphedTable in morphingMorphersMorph.event.
It's a bit hard to read, but it's just a list of the job ids the Morphers transform into for each of their abilities.

QuoteHow is the Morpher's "Raving/Transformed" state spriteset handled? Is there any reason why the developers went for that when making the game.

Sprites for playable jobs are smaller than sprites for monsters, I think they were concerned a player with 6 Morphers could glitch the game (visually) so they opted for an animation that was the same size as a regular player unit. That's just a guess, though.

QuoteIt sounds like it isn't really possible though unless you like added something like Poisondrakes.

It is very much possible, the new dragons wouldn't even need to have any abilities or anything, the would pretty much only use their looks and walking type, I just don't like the idea.

QuoteWould it be to ask if you're focused on creating another hack?

I've been working on the engine hacks for the Minish Cap randomizer, lately I'm focusing on studies though.

QuoteIf I can ask another hack question, does the engine of FFTA allow enemy recruitment the way it worked in the original Final Fantasy Tactics as well as the Tactics Ogre Knights of Lodis? Or just a capture for humanoids?

The question is not "does the engine allow for" or "is this possible", the GBA is a computer, if you program it in, then it will do that, the issue is with the workload that comes with developing new features. I have to want the feature enough that I want to put in the time to develop it.

For me the biggest issue with changing recruitment is that there's a bunch of ways to go about it:
Would a persuaded enemy instantly leave the battlefield and join your clan if there's space?
Should persuade just fail if there's no space in the clan?
Should the unit have to survive through the whole battle to be recruited?
Should there be a prompt at the end to confirm the recruitment?
Should player units be able to be persuaded?
Can units be persuaded back? what determines the persuade chance?
Which enemies can you persuade?
And many more, there's too many things to decide.

QuoteI don't think any monster in the game uses a green palette, bar the Malboro.

The Malboro uses the exact same palette as, for example, the Floateye or the Soldier.
There are only 3 palettes normal units use, blue/green, red/purple and yellow/emerald.
There are also slots that are reserved for special palettes used in totema battles.

QuoteSo a green morphed monster would look unique for almost any monster class.

In vanilla, maybe, but people could add them to their hacks, which is what my whole point was.
To do this I would have to make new graphics (not palettes, graphics) for the monsters, which people could then just use in their hacks, defeating the whole point of giving the Morpher those colors in the first place.

QuoteWould it be possible to allow morphers to do a basic "fight" command in monster form?

It sounds like a good idea, currently I'm not really developing these hacks further though, I'm focusing on other things.

QuoteDo you have an an all common monsters capturable hack?

No, this would require an extensive rework of the monster bank as well as the game save data. It is something I would like to do (and I actually have notes on what it would look like) but it's not something you should wait for. Whenever you see a hack that allows you to capture some new monster that just means that it's either not going to be sent to the bank or that it's replacing a previously capturable monster. The monster bank only has so many slots and each slot is specifically reserved for one type of monster, the game doesn't even save the job id of the monster when storing it in the bank, it deduces it entirely from the slot it is saved to.

Either way, even with a rework you would never get to have all of the types of monsters captured at once, at least not easily and not without a cost, there is only so much save space. The rework would only make it so monster types are not tied to the slot they are stored in, so you could have repeat monsters and whatnot, same total of slots but used in a different way.

I do however have a monster taming hack, which does allow you to capture all common monsters. They are not sent to the bank, though, they are added to your clan.
https://ffhacktics.com/smf/index.php?topic=12212.0

QuoteThis one.

That was available before I even made the post you quoted. It's on GitHub like everything else.

Quotewhat if the Morpher's monster form has a unique palette not used by any monster variants?

A unique palette for each one? Impossible, there's only so many palettes you can use at once (16) and all the slots are already pretty much taken, and even if they weren't if you wanted a unique palette for each monster you would potentially need a slot for each Morpher you can have in your team, which is unreasonable.

However, if you wanted to have a green or purple version of a monster you wouldn't need a new palette at all, those colors are already available, what you want is new graphics that use those colors. You can do that for your hack, I have no interest in including it. I think it makes no sense to do, a hack can easily include a new monster type that uses those colors anyway which makes it no different compared to just using one of the already existing ones for the Morpher.

If you want to learn more about how the GBA works I recommend reading http://www.coranac.com/tonc/text/

I'm not sure what Morpher thing you are talking about in particular but everything I made is on github.
https://github.com/LeonarthCG/FFTA_Engine_Hacks

You should do the opposite. An .ups patch can't be made to adapt to a different ROM, my engine hacks easily can.
First patch your ROM, then apply the changes to it afterwards.
(However, ideally you would make all of your changes exclusively through .event files.)

If your .ups patch uses any freespace, it would write all over the engine hacks. However, even if your patch uses freespace, the engine hack starting offset can be changed in order to avoid conflicts. This is why the order matters.

Anyway, when applying the engine hacks to a patched ROM, you first need to make sure the FreeSpace definition is still correct.

If you have never looked at the ROM in a hex editor, there's a point after which there's just nothing, even though the file continues going on, it's all filled with FF (or 00 in some ROMs), FreeSpace should be defined as the offset after which there is no more data, only dummy bytes like that.

Quote1. How did you change the formula for the "Capture" ability?

I simply found where the vanilla formula was and added my own stuff to the code.
I think I just check for space in the clan and them being a monster?
I don't remember changing the hit% at all, other than making it able to hit monsters it can't in vanilla, and being unable to hit if the clan is full.

Quote2. Although you removed it on the hack, monsters still were added to the Monster Bank. What did you do for that? (I tried checking the "Enable Capture" box on AIO's Job Editor, but it did nothing :p)

All of the code for the capture effect was rewritten, it does unlock the monsters in the bank but just barely, I mainly did this just to see if it would get that one mission where the monsters escape to work. I'm not sure what you mean with "What did you do for that".
Each monster type has a set place in ram it gets stored to for the bank, if the monster can be found in the bank in vanilla then it gets stored, if not then it doesn't.

Quote3. Do you know how to make an universal "Control" (and also a "Morph") ability that affects all monster Jobs, instead of having one ability for each monster class ([Control] Goblin, [Control] Panther, etc.)?

For "Control" you would just change which Jobs can be targeted, no? It's not something I've looked into.
Morph is more complicated. When you Morph the game actually stores which race you morphed into so you would need to rework whole all of that works.

Quote4. While testing the "Enable Capture", I happened to visit the Monster Bank and the instead of the monster battle sprites, it only showed the shadow at their feet (screenshots attached).

The Monster Bank shouldn't be possible to visit, at least last time I checked it didn't even show up in the map.
I don't store all of the info for the monsters so that could be why they don't show properly.

Hello!
I am not exactly making a mod, you can think of what I do as making tools that people can use for their mods. These can, of course, also be used directly with the normal game, if that is what you want to play.

Everything you can see on this thread is publicly available and you can get it at https://github.com/LeonarthCG/FFTA_Engine_Hacks

As this is meant to be used as a starting point from which people can make mods there are many options to choose and customize. That is one of the reasons this is not distributed as a patch, like you might have expected or be used to. If you need help setting it all up, feel free to send me a private message.

I also have a mod that was released last year and uses some of the features shown in this thread. It follows the normal game but you are forced to capture and use monsters instead of normal units.
https://ffhacktics.com/smf/index.php?topic=12212.0

I don't feel comfortable accepting donations but I appreciate the sentiment. Thank you and stay safe.

That would be the base offset of the table.
A nightmare module is structured like this:

1
Name
Base offset
Number of entries
Length of an entry in bytes
Dropdown list .txt file (or NULL)
NULL

After that, you get to specify the values to edit, like this:
Name
Offset
Length in bytes
Type of data
NULL
The types of data are not very important right now, what we need to know is just the base offset, the length of an entry and the offset of the data we want to edit.
The data we want to edit would be at (base + id*length of entry + offset of the data)
(id = entry, it's just a different name for the same thing)

The semi-secrets do not have a character ID to them, they are just generics with forced names.
If you want to give them special sprites, you will have to give them a character ID.

Once you've done that, they will work just like any other non-generic and their sprites will never change when changing jobs.

If you are using the intro cutscene removal patch, you can reuse the character IDs for the kids.
I haven't looked into editing the data for special recruitments, though, so I can't really help you on that.

You don't want to import the new graphics over the old graphics, and you can't, because the animation template graphics are bigger than the vanilla animations.

What you can do is simply make the game not use the old animation. Open the animation template and change the TEMPLATEID definition to the ID of the animation you want to replace. For example, if you wanted to replace the Soldier you would set the ID of the template to 0x00 and the ID of the water template to 0xBC.

It will work exactly the same as if you were using a new ID.

Alternatively, you can insert the animation with a new ID and change the ID of the battle sprite for the class. It really makes no difference, the space used is the same, you can't save space by replacing the old graphics or anything  like that.

Makehack hasn't finished running in that image, please leave it open and allow it to run, at the end you'll either get error messages or a message saying "No errors."
It will take a few minutes.

Like I explained earlier, the first step the script does is to copy the rom, so the rom appearing does not mean the script has completed.

When you run makehack the first thing that happens is that the rom gets copied.
If there are any errors, your rom would stay just like a vanilla rom.

Since you edited the buildfile it's possible that there's now errors, please run makehack and wait for it to complete, then show us if there are any errors.
(you could also show us your changes)

Other than that, make sure your Event Assembler is in the right location (and not somewhere like /Event Assembler/Event Assembler/)

Monsters can't equip any items, that's just how vanilla is and I didn't want to change anything about the monsters themselves.

That said, if an enemy monster starts a battle with an item and you capture it, it should retain the item, I think?

I don't remember if I made any code to prevent capture of monsters with items or to remove items from them. I also don't remember if there's any monster that starts battle with any item in FFTA to begin with, I know there are in FFTA2, I can't remember any from FFTA though.

Just to be clear, you don't need to include anything, everything is already included.
You don't need to uncomment anything outside of the main file either.

Some things are not installed but that's not because the hacks themselves are commented out or not included, rather the definitions that are checked for installing them are what's commented out, you should only uncomment those (in rom buildfile, the main file) and not the hacks themselves (which wouldn't be commented to begin with) if you just want to install them.

QuoteOr do I need to, like, copy the newMaxLevel hack codes into the main buildfile

If you look at the buildfile you'll see lines that say "#include soandso.event", that is the same as if that whole file had been copied and pasted in, so you don't need to copy anything anywhere.
You would want to uncomment (remove the // that's in front of) noStatVariance so that it gets installed, after that you can just change the definition for newMaxLevel to whatever you want the max level to be.

As for the death system idea, I don't think it's a bad idea but I'm not really interested in implementing it, mostly because there's so many different ways it could work: it could be made to trigger when downed at the end of a battle, when downed for 3 turns or both at once, I could also see people wanting increasing punishments for this, ending in death maybe? or people wanting to mix it with permadeath, it all sounds like a headache.
Maybe you can just impose it on yourself as a challenge?