Final Fantasy Hacktics

Amazing and finished quicker than I expected- gonna test this in a while, though I was looking at the files earlier and you accounted for things like feeding monsters etc already, so I can't think of any weirder case off the top of my head you wouldn't have tested yourself. Maybe steal/item destruction abilities? Sensing hidden items?

I don't know if other people made custom consumables before, but for those interested this also fixes new consumables not actually using the intended item; until now you could display item count but not actually consume them.

Two questions:
-If you set up a new item-related ability, there's no reason it has to go in the ITEM command, right?
I didn't have any ideas when you brought up what the new item-consumption conditions could be used for, but I guess very basic ways to use them would be to give Ninjas throwable kunais, or Alchemists item-related abilities that enhance the typical uses they would have through ITEM.

I don't even have Ninjas in my mod, but that last one sounds like it'd have some potential and differentiates it further from vanilla Sage (meaning I could eventually re-introduce Sage). Plus I'm not a huge fan of ALC having an extra command no one else has. Or of giving it to others.

-The custom ASM conditions would be basically anything, like whether the item is equipped or not right? Or whether it's idk, day 6 of Madmoon I guess. It's sometimes hard to grasp scope of some options given how restrictive development has been until now.

If you use the exorcise effect slot without the fix Leonarth made for it past week, the units hit are permanently removed from your clan; hence the game over from removing Marche.

And yeah tying neutral side effects that the AI doesn't normally consider to simple damaging ones etc does "let it" use them, but it needs some more fine tuning if it's supposed to be used somewhat restrictively instead of just affecting everything regardless of context.

Small update since there was so much talk about totemas and their palettes- the blue Super Mateus Sister(many question marks) looks significantly less janky now, after a lot of messing around with palettes to understand how they worked (even though all the info was spelled out from step 1) all again thanks to Leonarth's info about special unit structure and data.

Also I was keeping their mechanics a bit hush-hush, but since I prob won't release for a while a bigger look at them shouldn't hurt. Here's how the AI uses them and one of the unreleased cultist abilities:

Initially I wanted them to only have one ability, but I might give them another that consumes their status effect before release. Also will prob make their ranges melee too.

So I realized a big thing that was eating a lot of my dev time when it comes to abilities was trying to do things far outside of what tools were made for in vanilla:
There are only so many ways to target units, and one has to undertake a lot of restricions like self-targeting AoEs to even achieve simple abilities based on two different criteria (eg, aim at humanoid target and if successful, charm all monsters around him).
Some of those work for player use, but they'll be completely unusable by the AI; that's already the situation with some abilities and it's not something I want to keep doing- it also requires for the player to actually choose to aim the ability the right way unless you restrict them the way I mentioned above, so in general it makes for wonky gameplay.

tl;dr the Mateuses(Mateii?) are done, although differently from what I initially intended I like how they came out and they're 100% AI friendly.
I intended to release the patch with content until this fight since... well, there's two years old content that I never actually uploaded so there's more content than one might think- but there's tons of improvements stemming from Leonarth's engine hacks I want to learn to use and set up for future content, so it might also take much longer.

Preview for one of Mateus' abilities!

Quote from: rrs_kai on August 14, 2020, 11:40:16 pm0.8 speed means 80% favourable chance

It sure does but what you had said in that initial statement was that 8 points was worth 10 lv ups for a 0.8 job; 16% is the chance of getting those +1 8 times, not 10. We're just calculating different things lol.

As you can see in this unintentional comparison though, despite the relative chance of hitting +1 8 instead of 10 times being ~50% higher, the overall difference in likelihood between 0.8 giving its "expected" 8 points result vs just giving out the same as 1.0 is only ~5%.

Anyway no need to go more in depth on that point, I personally think the speed should be rounded and just stablished at a higher level but those are just my preferences, if you think these are better for your hack I hope they deliver as well as you can- I mostly wanted to comment on them to make sure potential issues didn't blindside you later on.

Well I was writing a pretty long example of why the RNG level ups are hugely unbalanced (tl;dr, 0.8 growth has a 16% chance of getting 8 points in 10 lv ups) but I guess you're going with whole numbers now?

I won't go into much detail regardless, but keep in mind speed is by far the most important character stat and you'll be having a tier that flips coins to get either minimum or maximum gain.
Looking at the speed numbers on your gdoc it's hard to judge, since you might have speed sources in items, but a 140 to 210 speed range is a 2:3 ratio and imo already gives too much of an advantage to speedier jobs, since acting 3 times instead of two in a given timeframe is extremely strong- still not as bad as some vanilla examples though.

Mind you, maybe the explanations are obvious. I don't really know how familiar you are with them and this is the kind of thing that causes structural issues with unsolvable balance problems later down the road.

About the last thing with rounded growths, 2.5 means the unit will gain either 2 or 3 50% on a coinflip.
With overall lowered stats, this means there will be a much greater power disparity between units just based off of their leveling rng alone. A lucky vs unlucky outcome with 2.5 yields a 50% difference in stats gained, for example.

You can use Leonarth's newLevel engine hack to avoid this, but there are two things to consider:

1- the game won't use those decimal values for anything, meaning it's the same having 14 attack or 14.9

2- characters might miss out on points if they level up and "hold" 0.5, only to switch to a job with whole numbers and forever carry that 0.5 that isn't actually factored in until they level up again in a 0.5 job and it's added to their total stat score

The 2nd part isn't as awful if you have only 0.5 as an inbetween step in growths, since at most units would miss one point at the end, but it's still something to keep in mind since the stats system isn't as intuitive one would initially assume.

So, I don't have much to contribute to this whole conversation but the totema fight I've been working on recently happens to use a totema pulling from the normal unit palettes alongside a dephts one. It could've been a normal one instead or up to two more regular unit palette'd totemas and they would all render fine.
This is a pretty straightforward option for anyone to do, but posting it since it might've not come across kai on his attempts to place different looking totemas on the same encounter: I haven't followed the whole conversation (started in another thread I think?) so sorry if that's already something you've tried.

Freeing the palettes does sound like a very good idea still; in fact I started with the normal unit palette in this fight as a placeholder, though I've grown used to it and might use it regardless- don't think it looks so bad? Will see.

Also that Marche sprite wearing a hat. I'm pretty sure that's in some scene in game in which he is listening on people trying not to be recognised, after Palace puts a price on his head.

And more on topic (lol), work has kept going. I'm mostly acquainted with thr game and its quirks again, fixed a lot of issues with abilities not respecting boss immunities and saw Leonarth fix things that have been major problems since day one.
Also, given that ahrimans are failures who will try to gaze attack someone's shoulder, I've been working on a new ability set for them that would have them target fallen units to "wound" them, removing them from the fight and spreading damage or status effects around them.

That's partially related to why the Mateus fight would feature two Mateus, each with different abilities.

Damn, so four years later there's an explanation to why this happened.

When I took up the hack again I wanted to keep the emulator version the same while getting up to speed with changes I had unfinished, to make sure everything was working and be able to spot any new issues (should they happen) when updating to the newest one.

For example, through second year of hiatus I got a few reports of a Bishop ability animation being broken, and apparently that was related to a certain issue with the version of mgba at the time. Currently in the latest version it seems to be working again.

Anyway, should've remembered to run the test for the engine hack on the latest version as I usually do not to compromise things.

I was testing the bigHP.event hack a bit further- it looks like if you target several units with an AoE attack and press L or R to switch between damage specifics of each unit, the game will softlock.

The"Lv: XX" on the target's stat display starts quickly flashing in and out, as you can see in this screenshot it wasn't visible despite it always being printed when the hack is active:

Combos aren't but totemas are just abilities with normal animations that can be re-used and changed with no issue, yeah.

Thanks for the heads up in blocking totema command alone btw! It doesn't modify the read JP for units, right? Didn't notice a change testing JP-mult on combos, at least.

IMO the combo system deserves more credit than it's often given:
The only two factors that break them are the extremely high user-JP multipliers active on any multi-unit combo and the lack of control over the base damage for the user. Although in truth, either of these alone would be enough to deal massive damage to basically anything.

Still, the core idea of the move is requiring multiple units within range of a target- often one dangerous enough to warrant all this in the first place; and in case of longer range combos that are more lenient with positioning, risking allies just not landing their hits at all, since hit% for ally hits drops for longer range combos and is unaffected by anything.
On top of this, the fact user JP zeroes after using it means that if the enemy survives you'll be locked out of initiating combos with that unit- while if you kill the target you'll be able to continue combo'ing (at a much lower multiplier).

It has a few flaws like rewarding having JP stacked beforehands, but I think the system is fun to play with when you have restrictions what items you can wield when using combos and lower the JP multiplier significantly. At least I've had a lot of fun clearing fights with combo-oriented teams this way.


Totemas, on the other hand, are unsalvageable and completely boring.

Also, to make this more relevant to the thread since it's not really meant for mechanic discussion; is there any part of the JP-learn system code that can be placed as a standalone in the main buildfile to disable the Totema option in battle from appearing?
The intended effect would be to disable Totemas without enabling the whole JP-learn system.

EDIT: Seems like the only line for that I see is this? at least out of the commented ones or the ones with dmps I can follow
PUSH; ORG $C8088; SHORT 0x2000; POP //disable combos and totema summoningI guess a workaround is just leaving them enabled and reducing max JP, would allow for more fine tuning with how to ramp up combo damage as JP increase.

Haha, that is super cute. I actually kind of expected you to release something like this- not sure if because you mentioned in the past or because I thought if you already fiddled with when naming happens for the tutorial skip, porting the feature to all generics would be a natural thing to want.

Also I dont think anyone will be disappointed it doesn't impact gameplay. I think this is something almost everyone who's ever been into ffta wanted at some point!

I'll try it out in a few hours and edit in some feedback about how it works later :D

Sigh, nevermind. I meant the shorter display used for tergetting units while moving/attacking, but I forgot you can actually toggle off the level displayed by pressing select, works (and looks) very good when you actually do that.


Sorry about the bother!

Funnily enough uncluttering the stats was one of the first things I did in LN, to allow more scale in differences between the player's party and other units. Recently had to up hp slightly though, to make a few differences less rough.

Anyway, I tested this too and target stats display seem to be offset (by two digits) whenever looking at them from the movement or attack aiming prompts:
That unit in particular had 206/92 HP/MP.

Forgot to mention earlier, good thing you guys were talking about it.

I'm sorry, the display is this then?

That is the current hack's display, I think there was some confusion because what I referred to as "mastered" was the ability permanently staying in the unit's set after equipping the item, while I think you were talking directly about it displaying the mastered bit or not. None of them do in the hack as is, and the only ones that display any AP information are the few that will never permanently stay in the unit's set (because they require AP you'll never gain), with their empty bar.

If there's something else I'm missing, I wouldn't mind trying that solution with setting their cost high and making ones with that cost artificially trigger. However that might create some weirdness with the way items display ability costs; showing 0AP isn't perfect but it sends a message clear enough that they don't cost anything to learn.
Otoh, 255 or some other high number would make it much harder to grasp at a glance. I understand this display could be edited too, but it seems like work I can't help with and that would pile onto you.

Quoteitems

I guess all it needs should be there by now, now that I think about it. Last time I tried (3y ago) the main limitation was putting images into the game and since it was unsurmountable it stopped me from looking further into it. I remember I tried to use artifact sprites too, but they don't render properly in the inventory UI so I shelved the whole thing.
Given that I'm not using more than a handful artifacts, I could very well turn a lot of those sprites into actual items, will need to be later down the road though.

Quoteability mastery issues

I was initially misreading this and thought you meant the functionality of "permanently learning an ability upon equipping" was very demanding to recreate. I understand the concern of having an inaccurate display (ability is mastered but doesn't show the tag), but in the four years since the hack has existed no one has shown interest in replicating the 0AP system for any other purpose.
I don't think going into extreme lengths to polish a system likely no one else will use is a good idea, and if this easy change you talk about recreates the vanilla interaction, I'm perfectly fine with missing the mastered tag next to learned abilities.
I'd be concerned with lack of visual distinction with abilities that can't actually be mastered, but these already have an empty AP bar next to them.

Plus, it won't impact jobs showing their "mastered" star or not, since none can master their combos and thus even in the current hack the star is impossible to obtain.

Since I don't know how familiar you are with the specifics- the whole point of using this is creating a scenario in which mundane abilities can be learned immediately upon getting the item, while also leaving some impossible to master due to no sources of AP existing in the game, effectively linking them to the item that grants them.

Quoterepointed text questions

Nice. I'm still surprised by the modularity of all this. Before I decide whether to keep it or not I'll take a look at the table and see how much I'd realistically have to add on it. I have my changes documented, but it still a lot of content to port over.

Furthermore, wouldn't breaking support for text changes now cause further issues down the line if say, support for custom items was added one day?

Also, please don't misunderstand. The engine hacks are by a long shot the base I would use if I was starting the hack today, I'm aware the few weirdnesses we're running into are caused by fankensteining it together with an already (questionably) hacked base- more than anything I'm surprised that they actually play so nice with all the changes, given that I've always prioritized end experience results and consistency over anything else.

Thanks for the detailed explanation btw, I'm currently stablishing a base I can trust to handle the content to come and it's very helpful to have this kind of docs to avoid pointless limitations. No yellow or stoned ahrimans as "secret endgame monsters", wow!

Quote from: undefinedthe ROM buildfile.event file is made to contain the options of which engine hacks to install, if you don't see one in there then that means it's considered essential and is always installed.

Damn, now that is what I was missing completely. That is a very interesting system, I'll run it properly tomorrow and update with changes, if any.

Quote from: undefinedThis is because I made these with a script (...) I can try to explain the format if you would be interested in making your own.

I was assuming they weren't made manually due to how much data they handle, but yes. I'm not sure I have any case use other than monsters with weapons but it would be good to learn about it.

Also yeah, if they don't have an animation they stand still during the swing.

Quote from: undefinedI'm lost here, why do you want to remove the weapon animations?

Tl;dr is that it's hard to internalize that the hack changes the way animations are used and I was worried it'd break existing skills, so I was trying to minimize the changes in a way that kept functionality I can use (the safeguard monster thing in weapon fix' case).
Upon further inspection it's clear there is no way weapons fix alone could cause new issues with previously working skills, and there are no negatives from the status quo since I used a mix of punches and standing animations as well for all this too.

EDIT:
Got around to install things properly. I had previously identified the root of dead cutscene units and it was just not properly installing newlevel. Using the buildfile everything works as intended, bar the missing mastery bit option for working with 0AP. I misremembered it being a real feature rather a potential one (lmao).

That said, I've run into not so much of an issue but a customization question:
Left is the base hack and right is post engine hacks- although I know by now you have better systems in place, this hack plainly uses repointing for a lot of its custom text, including cannibalizing useless entries for space while writing descriptions (big yikes).
Do you know if any part of the engine hacks overriding these repoints could be commented out? Descriptions and in-battle text is still working as intended, so I was hopeful this isn't part of a crucial system and can be toggled off on build.

Wanted to test this ASAP so I did the same makeshift buildfile with only jobAndRaceCustomization.event- tried a wide array of custom animations with no issues, meaning the new graphics can be loaded while old stuff remains unaltered, works great!

The issues with units being dead in cutscenes persists, but I think that should be fixed upon using the proper buildfile; I had a few questions about that if you don't mind:

When commenting out functions in general, do you need // more than the #include that defines the function? I've been commenting out the whole block but wondering if it's necessary.

When choosing options in ROM buildfile it doesn't acknowledge some engine hacks, like job&race. I know about their data and options .events for fine tuning, but I can't tell what file needs to be modified to actually choose which of those unacknowledged engine hacks the buildfile will install.

___

Separately, I went looking into what "playable characters" covered for the weapon fix and I noticed it seems to stop on units don't normally use weapons. I applied it (without specialAnimations) and was pleased to discover that even though monsters aren't directly adressed, there's a safeguard that makes them able to aim weapons up and down slopes without pulling sprites off of other monster tables due their shorter lists.

Is it feasible to make a patch option that applies only to monsters/totema enemies that don't usually wield weapons?
And if not, would deleting the current content of animations.txt be a good way to recreate this effect of keeping monster weapon swings using other tables, while leaving the rest of weapon usage effectively vanilla?

I have no idea how you made the animation.txt for each individual unit and I can't see a way to make them for monsters, but I'm pretty keen in keeping this ability for monsters to properly use weapons as it can make for interesting encounter design and to spice things up in pretty cool ways.

EDIT: On further testing, I thought the reason I was getting issues with some skill animations despite not using specialAnimation.event was that they call for weapon animations and those were somehow conflicting with the replacements from your weapons fix. In reality I just had leftover code from specialAnimation that was interacting with those skills directly.
As far as I can tell right now, the weapons fix is fully usable and nothing needs to be deleted for it to be usable on this project in particular, very thankful for that since it means no work goes to waste, and in reality I never used any weapon animation replacements that were any better than just punch.

EDIT2: Not overly concerned about this since I'm testing it without applying the patch properly, but I'm getting (very rare) irreproducible crashes when going into the job selection menu for a unit during battle deployment phase. Can't go into detail right now (not that I have any) but just mentioning in case it's familiar to you.