Party roster hack! You can now have up to 20 units in the party!

[Glain]

Quite interesting indeed, that's good info.

...Actually, that 0x70-0x7F range could be one thing we'd have to change to expand roster size... there's only 16 possible values in that range. Ramza does have his 01/02/03 though instead of one of those...
Anyway, when I was looking around at in-battle unit memory last night, my findings seemed to be that:

Offset 0x15F = Special Unit ID, if applicable, for allies (e.g. 1E for Agrias); otherwise, it was something else... sometimes 0x6X? (? I may need to look at this a bit more)
Offset 0x161 = Unit ID (Non-Ramza allies: 0x70-0x7F; Ramza: (his base job, 01/02/03); Others: ENTD Unit ID)

[RavenOfRazgriz]

It's not.  70-7F are your up to 16 values for Player units, and 80-8F are your up to 16 values for enemy units.  A single map can only have 16 individual units (and 9 different sprite sheets) deployed at any one time, so enough UnitIDs are reserved so that each time can have 16 units on it.  No idea why, but since UnitIDs are essentially piss-easy to come by anyway, I guess better safe than sorry.

Possibly x15F has some filler value when dealing with a generic unit?  I wouldn't know.

[Glain]

Okay, I may have misread what you said in a previous post... I thought you were saying that the Unit ID was saved as out-of-battle data with each unit, and that it was imported with the unit into the battle. If they're just generated as temp IDs then I agree that it doesn't matter that there are only 16 of them.

[RavenOfRazgriz]

Okay, I may have misread what you said in a previous post... I thought you were saying that the Unit ID was saved as out-of-battle data with each unit, and that it was imported with the unit into the battle. If they're just generated as temp IDs then I agree that it doesn't matter that there are only 16 of them.

70-8F are Temp IDs used for the current battle.  It's why you should never use 70-7F for anything and 80-8F should only be generic enemies.

Everything else is, as you've discovered, an ID that's saved with the Unit if they join you... but is otherwise nonspecific.

[pokeytax]

Here is the 85% complete version of the roster hack. You will need to remove auto-join guests, as discussed previously. (Creating a companion hack that edits all ENTD data and fixes that Beowulf check would be a good idea - what game file is the ENTD data stored in?)

You can:
- Invite enemies up to spot 20 (and probably accept units who join after battle)
- recruit up to spot 20 from the soldier office
- bring party members from spots 17-20 into battle

You can't (yet):
- count units past "16/16" in the soldier office
- lay eggs in spots 17-20
- prevent these units from looking like malboro guts on the pre-battle (battle is fine)
- dismiss spots 17-20 or keep them from saying "Guest"

So basically... just cosmetic stuff left? Kinda surprising, and it feels like there must be some epic bugs hiding somewhere, but it seems to work okay.

EDIT: whooooooooooooooooa high five to Xifanie two and a half years in the past

Forget it, I found it.

ATTACK.OUT
0x9BCC
1400222A
UNIT.BIN sprites loaded for the battle formation = 01-20

Now these units all look normal which was the major impediment! I'm going to tighten up those last couple ornamental details but this hack is... actually looking pretty good. If you could move it into the OP and maybe change the title to be more descriptive, Dome, that'd help trick people into testing it?

20 units is pretty much the hard cap. Doing this hack was like taking the rolled up paper out of a pair of new shoes before putting your feet in. Doing 24 units would be like building a new, longer shoe out of the existing shoe.

[Dome]

Updated the first post with your post and edited the topic title
I'll ask a mod/admin to sticky this or make this topic somehow more visible

I'll test it right now

[Cheetah]

This is amazing Pokeytax! Finally another FFT dream is being achieved. I think I have some notes on the "Guest" byte, but I'm not sure. Actually I think I have the offset for where it draws the graphic from if that would be any help.

[Glain]

I think ENTD data is in the BATTLE directory in ENTD1.ENT through ENTD4.ENT. At the very least there's something related to ENTDs in there!

[pokeytax]

Actually I think I have the offset for where it draws the graphic from if that would be any help.

Yes, can't hurt. Getting rid of that guest stamp and inability to dismiss is the real issue remaining and I imagine they're connected.

I think ENTD data is in the BATTLE directory in ENTD1.ENT through ENTD4.ENT. At the very least there's something related to ENTDs in there!

Thanks! I would have just checked Patcher but as you know it doesn't save ENTD modifications. So the necessary modification is just removing Load and Save Formation from all guests who appear in battle and don't join at the end of that battle, or what? (I haven't touched the ENTD much.)

[Dome]

You also should modify the Beowulf event a bit...
If you only touch the ENDT, you won't be able to play his side.quest (Without modifications, you need him in the party to trigger the fights)

[Glain]

Pokeytax: Probably it would have to be removing [Join after Event] and [Save Formation] for any joining guests (so they don't join), and removal of [Load Formation] from everybody (It should only be on guests; if the unit is not in the party as a guest and it tries to load formation, I believe it wigs out rather hard).

Dome: Yes, we would have to include an edit to wldcore.bin (I believe that is the file Pride specified) as well to modify that check.

[pokeytax]

This version removes nominal guest status from units 17-20 (e.g. you can dismiss them now). Just need to fix that soldier office display issue, and slap together an ENTD/WLDCORE companion hack, and I'm happy.

[Dome]

Awesome!
Edited the first post

[Glain]

If you do make the ENTD companion hack, isn't it going to just keep getting overwritten by FFTPatcher when someone makes an update to their patch, though? You'd have to keep applying it. That's one of the reasons why I was thinking about changing the ENTD processing instead.

[pokeytax]

That's a good point, I'll do what you suggested and leave the current hack around for people who want to do the ENTD edits themselves. The WLDCORE edit should be fine to put in though, right?

[RavenOfRazgriz]

...You guys do realize that when you apply a .fftpatch, you can choose to only have it edit certain things (such as the ENTD or Abilities), right?  That's what all those check boxes and radio buttons on the Patch ISO screen mean.

So, unless you've already edited your ENTD before using what'd be an accompanying .fftpatch or are too dim to make sure you're only editing the ENTD before applying, there should be no issue.  Apply this .fftpatch, apply your .fftpatch and make sure the ENTD isn't being edited, then Open ISO and Save As a new .fftpatch that has your previous edits and the ready-to-go ENTD all set.

If you already HAVE done tons of ENTD edits... removing a couple guests shouldn't be a big deal to you at that point, and is possibly already done for other reasons.

Tl;dr the ENTD edits would only get overwritten if you're a moron.

[Glain]

I would think the WLDCORE edit would be a part of the patch, sure. As for ENTDs, I forgot about the load from ISO feature in Patcher, so it could work, but that process just seems... eh. It sounds like you're going with doing just the WLDCORE edit and not the ENTD edits anyway. I still think a companion (separate patch) SCUS edit to ignore the guest saving/loading ENTD flags would be a decent addition, but depends on how annoying that would be to write.

[pokeytax]

Made the WLDCORE edit for Beowulf and fixed the soldier office. All that's left is monster breeding into spaces 17-20 and handling guest flags.

the ENTD edits would only get overwritten if you're a moron.

Yes, that's why I'm planning on writing a small SCUS hack if it's not too hard, so it's usable by morons, and so it works with LFT/FFT 1.3/whatever with no fuss. Non-morons will still have the option of using the existing patch and doing it themselves, or maybe I'll provide an .fftpatcher file as well to speed things up.

[RandMuadDib]

dont forget that if you're building a new patch and plan on using this hack, you can do the ENTD patch first, then just load FFTPatcher from the iso instead of creating a new patch, and then they should already be incorporated in your new patch. Doesnt really help people who have already started their patch though.

[Pickle Girl Fanboy]

Yes, that's why I'm planning on writing a small SCUS hack if it's not too hard, so it's usable by morons, and so it works with LFT/FFT 1.3/whatever with no fuss. Non-morons will still have the option of using the existing patch and doing it themselves, or maybe I'll provide an .fftpatcher file as well to speed things up.

Nice.