• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
November 27, 2020, 12:08:06 am

News:

Use of ePSXe before 2.0 is highly discouraged. Mednafen/RetroArch is recommended for playing/testing, pSX is recommended for debugging.


FFTA Long Night 0.64 release!

Started by dck, February 21, 2016, 09:19:33 am

Leonarth

Quoteand a lot of cutscene animations break as well
Any examples? This could mean pretty much anything.

Quote from: undefinedI need to figure out causes for the cutscene issues first
That's something I've never seen before...
This is probably caused by you having some but not other of the required things?
Using the engine hacks any way other than through the provided ROM Buildfile.event is going to be tricky.

I'm pretty sure your cutscene characters just have 0 current hp, but from what I remember you were using the new level up stuff so that shouldn't be possible?, the KO stars have literally nothing to do with unit animations either way.

If you are getting the job and race customization stuff from the thread instead of the repo, don't do that, that's old and hasn't been updated in... ever.

Quote from: undefinedit automatically gives any job any skill that requires 0 AP
Yeah... It just compares required and gained AP, I guess I could look into always requiring the mastered bit as an option. I remember having issues with this because units that spawn with equipped items don't actually set their bits correctly.

As a side note, I've had an idea for a while: loading palettes into the 3rd and 4th slot (normally used by totemas and li-grim) based on mission ID, with a default case and some other options, which could give people either 2 new always usable palettes to give jobs (which is incompatible with totemas, I guess), or 2 mission based palettes for bosses and the like? or I guess a combination of the two options.
  • Modding version: Other/Unknown

dck

I never considered cutscene characters were actual units that could have HP. What I meant by animations being broken was that they were behaving in a way I couldn't find a pattern for, like Marche in the post-snowball fight cutscene laying down (in his pajamas) when looking at certain angles, or Mewt/Ritz constantly kneeling as can be seen in one of those screenshots. Cid himself is using an odd sprite too in that same shot.

Of course if they're actually dead that would explain a lot. The game would be calling for the right sprites for that and those are much lower in the tables, where more niche sprites tend to be.

I got the files from the repo, but I'm pretty sure I misunderstood installation process because what I did was make my own ROM buildfile.event out of the jobAndRaceCustomization.event.
I was unsure of whether to modify the FreeSpace offset in the buildfile or in every .event it calls, so I thought I'd use it separately like newlevel and negative items. I'll report back after trying the provided buildfile.

Incidentally, is it normal that upon commenting out the special and weapon sections, the make_hack was giving out an error about these two lines (84,85)? They can't be commented out because then there just won't be animations pointed at to actually play, but I was under the impression these "animation fix" features of the hack were separate from the graphics installer and system for custom jobs.


Regarding the AP handling. I'd personally appreciate the mastery bit feature as it'd play nice with the 0AP interaction. I think the only use case in which it would matter would be if you disarm a unit that has been given access to a certain skill only through having that weapon equipped, rather than actually mastering it on formation.
Even then, it could be seen as a potential feature as it allows for the 0AP interaction to be used without losing the ability to give units skills tied to gear pieces that they could lose in battle- thus losing the skill.

Thanks for taking an interest btw, I was holding off on asking you directly until I understood more of what was happening.
  • Modding version: Other/Unknown
  • Discord username: adri#1824

Leonarth

Those two lines reference labels that are set in specialAnimations.event and weaponAnimations.event, so if you comment them out EA won't know what they mean and won't be able to proceed.

If you want to remove the fixed special and weapon animations, delete everything from
//setting up special animationsup to
//never register as special character for the original dismiss message routineSo, lines 48 through 95.

I also went ahead and added an option to enable/disable the installation of the fixed animations, so you can use that instead.
Please let me know if I messed up.
  • Modding version: Other/Unknown

dck

August 01, 2020, 06:54:23 pm #63 Last Edit: August 01, 2020, 07:55:31 pm by dck
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.
  • Modding version: Other/Unknown
  • Discord username: adri#1824

Leonarth

You shouldn't need to comment out any #include directives, the 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.

Of course, some engine hacks have their own options elsewhere, but other than those options and  the ones in ROM buildfile.event you generally shouldn't need to touch anything else, other than some lists here and there, and all of the options would be #define directives.

If you have something specific you want to try to get done just send me a dm and we can look into it together.

QuoteI noticed it seems to stop on units don't normally use weapons
QuoteI have no idea how you made the animation.txt for each individual unit
This is because I made these with a script, it took specific animations from specific jobs (say, sword animations from Soldier) and used the data of those animations, together with sprites that all jobs have (like standing, punching, etc) to make new animations for all of the jobs. Of course I did need to make new sprites for a bunch of special animations. None for weapon animations, though, all jobs have all needed sprites for those. I can try to explain the format if you would be interested in making your own.

Quotethere's a safeguard that makes them able to aim weapons up and down slopes
If a unit doesn't have the animation for a specific thing, it uses the walking animation instead, I think is what I did?

Quotewould deleting the current content of animations.txt be a good way to recreate this effect
I'm lost here, why do you want to remove the weapon animations?
  • Modding version: Other/Unknown

dck

August 01, 2020, 09:38:44 pm #65 Last Edit: August 02, 2020, 09:52:16 am by dck
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.
  • Modding version: Other/Unknown
  • Discord username: adri#1824

Leonarth

Quoteit would be good to learn about it.
If you look at the animation template, it contains a very big list of pointers, such as "idle_front_pointer".
You can search for the label in your text editor "idle_front_pointer:" and it will get you to the data for that animation.

Once there you'll see, first of all, the ALIGN 4 and label, that's just setting the label for usage.
After that there's a "WORD X", where X is the number of frames the animation has.
Then you'll see a list of aFrame() macros, the a stands for animation.

The format of aFrame is define in Graphics Helpers, and if you go check that you'll see it's not entirely documented.
For the named stuff: tiles, oam, duration
Tiles is a relative offset (0x69B89C is added to it by the game when it reads it) to the graphics of the frame.
OAM is also a relative offset (but using 0x852E7C as a base instead), this time to the sprite data.
Finally, dureation is... the duration.
As for the other values, I know some of them just shift the whole thing up/down and left/right, others are more important, as they control stuff like when ability animations start and end, as well as loops. I kinda just copied vanilla for what to put on those, though, so it's not really all that well documented.

You'll also see aFrameV() macro definitions, those are the same as aFrame but without the relative offset adjusting for the tiles, these are meant to be used if you are translating frames directly from the game, so you can just copy the tile offset value from those instead of having to add 0x69B89C to them, and same for the oam.


Quotebar the missing mastery bit option for working with 0AP
I've been looking into this and it's honestly way more much work than I originally though...
This is going to be a lot of spaghetti so I'm not sure when or if it will get done.

Getting the mastered on equip to work is extremely easy and it'll work just fine in battle, what is hard is getting it to DISPLAY as mastered or not properly, in the learnt abilities tab. There are a ton of exception for 0 AP cost abilities, because of the item abilities and such.


QuoteThat said, I've run into not so much of an issue but a customization question:
That's because the text tables are repointed and/or reworked by the engine hacks, for easy expansion and such.
I believe those entries are part of the "Others" table.

If you don't like that you can find this line in the master hack installer
////////////////////////////////TEXT CHANGESand just delete everything from there up to
////////////////////////////////GRAPHIC CHANGESIt will probably break some stuff? But if you aren't using movement abilities are JP learning I think it should be fine.
You will get some errors from the master text installer but you can just go and comment those lines out.

Or if you don't have a ton of edited text entries, you can add them back in through the master text installer.

Keep in mind the engine hacks are made to be used as a base, rather than be added on to an existing hack, so it's really just natural that you'd find issues like that.
Happy to help, though.
  • Modding version: Other/Unknown

rrs_kai

Quote from: Leonarth on August 02, 2020, 11:52:25 amKeep in mind the engine hacks are made to be used as a base, rather than be added on to an existing hack
I'm using them as an add-on. I make all the changes in the AIO/nightmare and then apply the engine hacks at the end.  :?
  • Modding version: Other/Unknown

dck

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!
  • Modding version: Other/Unknown
  • Discord username: adri#1824

Leonarth

Quote from: undefinedI understand the concern of having an inaccurate display
The display is much worse than you described, not only does it never show the mastered tag, it also does not have a bar and the ability name is always white, there is essentially no way to tell the ability isn't mastered.

I was thinking this could be done in a different way, instead of making the abilities have a 0AP cost, I'd give them a high cost, maybe 0xFF? This can then be checked when the item is equipped and the abilities would be mastered right there, instead of setting the equipped bit. I'm not sure I would add that to the engine hacks but I could make it for you, I guess.

Quote from: undefinedsupport for custom items was added one day?
Not sure what you mean by this, what is preventing you from adding more items?
  • Modding version: Other/Unknown

dck

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.
  • Modding version: Other/Unknown
  • Discord username: adri#1824

rrs_kai

Quote from: Leonarth on August 01, 2020, 02:54:25 pmAs a side note, I've had an idea for a while: loading palettes into the 3rd and 4th slot (normally used by totemas and li-grim) based on mission ID, with a default case and some other options, which could give people either 2 new always usable palettes to give jobs (which is incompatible with totemas, I guess), or 2 mission based palettes for bosses and the like? or I guess a combination of the two options.
I tested and saw that the game can handle a totema and Li-grim on the same map.
Why not release a test patch where all player units are Addremmelech coloured and enemies are Li-grim coloured. I want to see how normal units look in a totema's palette. I am biased towards Addremmelech's palette and prefer seeing the other two totema in his palette.

Also, I saw on spriters-resource that Marche has a hoodie/cap sprite. I do not recall any scene where he wears a cap. Is it japanese only?
  • Modding version: Other/Unknown

Leonarth

Quote from: undefinedI tested and saw that the game can handle a totema and Li-grim on the same map.
Of course it can, that's what I said, and also happens in vanilla. The 3rd and 4th palettes are used for this.
The 3rd is used by totemas, the 4th by Li-Grim.
Either way, that has nothing to do with what I said about freeing the palettes so I'm not sure why you are bringing it up.

Quote from: undefinedI want to see how normal units look in a totema's palette
They would probably look terrible because the palettes are not made to work with regular sprites.
If you want to know just replace the palettes with your desired palette. Open the debugger, go into the palette window and just use the search function in a hex editor.
  • Modding version: Other/Unknown

rrs_kai

August 13, 2020, 12:03:02 am #73 Last Edit: August 13, 2020, 03:56:33 am by rrs_kai Reason: Leonarth is right. I thought that the purple palette was normal but it's special
Quote from: Leonarth on August 12, 2020, 04:45:15 pmI'm not sure why you are bringing it up
You know that when there are two totems on the same map, in their special palette, the game shifts one of thier colour. I was only saying that the game did not cause this error.

Quote from: Leonarth on August 12, 2020, 04:45:15 pmOf course it can, that's what I said, and also happens in vanilla.
I don't think we get to see Li grim and a totema, in their special palette, paired on the same map in vanilla. Li grim is paired with the Deph-purple variant, which does not cause any palette shifts. it does

EDIT: Leonarth is right. I thought that the purple palette was normal, like Ezel, but it's totema-special.
  • Modding version: Other/Unknown

Leonarth

Quote from: undefinedI don't think we get to see Li grim and a totema, in their special palette, paired on the same map in vanilla.
We totally do.

Quote from: undefinedLi grim is paired with the Deph-purple variant
Which uses a unique palette that is loaded to slot 3...
Quote from: undefinedwhich does not cause any palette shifts.
Which does change palette 3.
Also, this purple palette is used for the Remedi fight as well, in order to have two different totemas on the map at once.

If you do go look at the palette you will see that it's not like the regular red palette at all, it has more shades of purple than it has shades of red, the colors are less vivid and the yellow/brown part is pretty different. And, of course, the order is different.
As for the Li-Grim palette, it is mainly blue, and it does have the blue colors on the same place as the normal blue palette, but they are slightly brighter and the palette has golden instead of green, as well as dark purple instead of yellow/brown.

All of these sprites could be redrawn with the already existing palettes and they would look pretty okay, or if not then they could be drawn with two new (static) palettes, which would be purple + blue and green + red, which is why I say these palette slots could be freed without necessarily having to lose the totemas and such.

I'll explain this again:
Totemas use palette 3.
Li-grim uses palette 4.
Or viceversa, I'm actually pretty sure it's the opposite and I have been saying it backwards the whole time but I haven't looked at it in a while and honestly the order is the least important part.

If you won't believe me, just open the debugger and go look at it yourself.
Simply go to a map with a totema (or more) and you will see how palette 3 is updated to match them.
Do the same with Li-Grim and palette 4 changes.
You can actually have Li-Grim and any totema on the same map and it will work perfectly, it's only having 2 different totema (unless they are deph totema) that breaks colors.

And just to be clear, we start counting from 0, so palette 3 is the one that goes right after the 3 regular palettes.
(So the first black one, unless there's a totema).

Anyway, we have hijacked this thread enough, this is moving into off-topic category very fast (sorry), if you want to keep talking about these things I'd say that it is best to either start a new thread or take it to the DMs.
  • Modding version: Other/Unknown

dck

August 13, 2020, 05:17:43 am #75 Last Edit: August 13, 2020, 11:38:55 am by dck
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.
  • Modding version: Other/Unknown
  • Discord username: adri#1824

dck

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!
  • Modding version: Other/Unknown
  • Discord username: adri#1824

dck

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.
  • Modding version: Other/Unknown
  • Discord username: adri#1824

rrs_kai

Quote from: undefinedbut they'll be completely unusable by the AI
That's very nice to get the enemy use "Remove Unit". The AI never uses Parley/Oust/Wyrmtamer.
Seeing you, I made this. Thanks for the idea.
I added "Remove Unit" as a secondary effect to Fire. The AI just thinks that it is damaging the enemy. Even when Marche was removed, the game did not crash, I just got the GAME OVER screen.
  • Modding version: Other/Unknown

dck

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.
  • Modding version: Other/Unknown
  • Discord username: adri#1824