Final Fantasy Hacktics

Quote from: Timbo on May 24, 2020, 01:43:18 amBecause that doesn't make a lot sense to me.

Think of it as being fenced?

Do you have a link to the art you made the front of the box from? It's lovely.

Sorry for reviving a five year old thread, Xifanie. Is there a chance of this coming back? I don't know what the problems with it were, but it seems a lot nicer than dealing with ARH's space conflicts or starting from scratch.

Thank you! <3

So by default, if a unit neither moves nor acts it ends its turn with 40 CT, if it does only one or the other it ends with 20, and if it does neither it ends with zero. I've been having a tough time finding the routines that determine this. Conservatively, it'd be nice to tweak those numbers; more ambitiously, knowing where this math comes from means I could try to write new routines to do things like giving abilities custom CT costs, FFX style (this is somewhat possible with damage formulas, but not ideal).

If this info isn't readily available (I had a hard time digging through BATTLE.BIN for it), maybe give me a hint about what I should breakpoint to get started? It'd be nice if eventually I could answer small questions like these on my own.

Aw, I like some of them... but yeah, I can make choices about what to cut.

Thanks so much! Excited to see what we can manage using the known SMD instruction set. ^^

OK! So having thought about this a little further, the file table having a set number of entries isn't a deal-breaker, as long as higher sector numbers don't somehow go outside the address space; the maximum number of tracks would stay the same, but if the entries in the file table are changed then the songs can be different lengths, in different spots on the disc, and so on. That's a pretty manageable restriction compared to some of the other tables I'm looking at, haha (looking at you, Item Attributes...).

One more question assuming I'm correct so far: are songs streamed from SMDs as they play or is a song loaded into RAM all at once? If the latter, do you know how much space is allocated for it (i.e. is there an effective limit for SMD file sizes)?

Glad I wasn't too far off. The consistent byte sizes and contiguous addresses probably should've tipped me off to it being a table--I'm still getting used to reading hex. I'm guessing that 00028acc - 00040970 in SCUS is mostly dedicated to misc tables, then, since that's the huge unlabelled block that also contains the music file table. Hard to tell what uses that space at a glance since it doesn't link to anything.

Followup questions:

• Do these file tables typically have headers? Are they contiguous to the first entry? Do they have consistent sizes? I can't think of anything a header would be needed for but I want to make sure that I'm not leaving something out...



• Is there freeable space in SCUS to shove the table off to? Amusingly this was the first result when I googled and I can't decide if that's a good sign or a bad one, lol



• Is repointing to the table after moving it a really involved process, or can it mostly be automated? I'm guessing it would depend on the table...



• "Though you kinda have to edit the ISO to add files to the index to make important new files easier rather than import them directly to sectors." I'm not sure I understand this sentence... which index are you referring to? The index of the associated file table? Or does the ISO itself have an index that would need manual editing?

Sorry, that... looks like a lot more, written out. I really appreciate your help so far!

So what I've gathered so far from the wiki is that files are loaded from the ISO through addresses in SCUS 942.21. For example, all the SMD files are listed this way. I'm not entirely sure what the SCUS file is even after scanning through its massive wiki page, but since it holds the PSX kernel and is also apparently used for file loading, my guess is that it's the entry point for the game and its contents are always in RAM, sort of a "Main" file.

I don't know what magic links the SCUS addresses to the SMD files themselves. I can see here that all the SMD files are in contiguous sectors in the same folder, which seems significant, but... maybe it isn't? If I were to, say, add a new SMD file to one of the giant free spaces listed in the CD Index, could I somehow add a pointer to that song in SCUS and play it like any other SMD file? Even if the answer is "no" (which I'm guessing it is) it'd be helpful to know which parts of my conceptual understanding are correct and which are off.

OK, thanks for the links!

The graphical section meaning that's where the data shown in the UI is stored in RAM? So I'm guessing that's not per-unit, and that's why there are a bunch of duplicate fields?

I did notice the graphical section header but hadn't quite put together what that meant, since yeah it's weird that they share the same page. I could split that section off if you'd like but I'm not sure which pages should link to it and so on. >_>

Reading through this, I wonder why they decided to store things like Move as halfwords and not single bytes...

http://ffhacktics.com/wiki/World_Stats

I see that a Gender Byte shows up at 0x04 in the Stats List, and then again at 0x70 with different flags but some overlap. Does anyone know what's going on there?

That's helpful to know, thanks!

The reason I care about formation sprites is that I'd like any new jobs to, well, have them... so I was trying to figure out to what extent I would need to remove other content to make that happen. Hopefully I'm not misunderstanding something fundamental there.

I guess I'll mark this as resolved and report back somewhere if I ever get far enough with RAD to have findings worth talking about. I know I'm not the first or most experienced person to try, but it can't hurt, hey.

Not sure what "talk about it" you're basing that on; I haven't been able to find anything concrete from rereading the thread, searching the forum and wiki, etc. I was asking for specifics earlier because this reply doesn't help me understand the problem.

Like I mentioned, I'm aware that RAD's "extra" jobs aren't fully separate and need to share JP, job levels and learned ability flags; those aren't major issues for my usage case. I'm also aware that some UI (listing which jobs can use a piece of equipment, finding the new jobs on the battle status screen, maybe others I don't know about) don't automatically update to reflect the new jobs, but those don't seem like hundred hour problems (but I could be wrong!). If RAD breaks the game in more fundamental ways that are impractical to fix, then that's the sort of thing that would be good to know upfront.

Right, but I want to know how that applies in this context. Are you saying that incorrect formation sprites are the reason it's not serious, or am I misunderstanding? Because that's the reason I'm trying to figure out what my options are for using the formation sprite space available to me. Calling RAD not serious seemed to imply a more fatal design flaw than e.g. cutting out some monsters or making sprites gender-neutral.

I can live with making something that's emulator-only, but if you can expand on what you mean by a "serious mod" (or link to something already written about it) I'd appreciate it. I'm new to FFH but have a programming background so more specificity is helpful to me if you have time.

Well, I've gathered from the fact that RAD exists (even in a buggy form) that more jobs are possible within a specific set of restrictions (shared JP/JL/Learned bools are the ones I know about)--I'm just trying to figure out to what extent spritesheets and formation graphics are among them. But if I'm off-base about all that it would be good to know!

OK, thanks for letting me know! Shishi's wiki page should probably be updated to reflect that but I don't know if I'm the person to do it.

Followup question, if that's alright: can formation and spritesheet slots originally intended for monsters be repurposed for fitting more generic units? My guess was no due to size and structure differences, but it's difficult for me to test currently without PC access.

Hi! This is my first post here. Sorry if this is a basic question; I couldn't find a straightforward answer after a couple days of digging.

I've read the tutorials I could find on Shishi and FFTEVGRP. The tutorials address *replacing existing formation images*, but I couldn't find any indication of whether adding entirely new formation images and spritesheets is possible without overwriting existing content. I can't tell whether this is as simple as expanding the ISO and following a couple steps in an existing GUI tool or whether it would require significant/impractical manual restructuring of files. I'd appreciate being pointed in the right direction. Thank you!