Final Fantasy Hacktics

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):
- Breed monsters into spaces 17-20

(Remember that I know nothing about actual hacking)

I do think the hard limit is 20, 16 for non-guests. You are limited, AFAIK, to 4 guests and the games really WANTS that space.

Quote from: Kokojo on August 21, 2011, 05:28:24 pm
(Remember that I know nothing about actual hacking)

I do think the hard limit is 20, 16 for non-guests. You are limited, AFAIK, to 4 guests and the games really WANTS that space.

Yes, while it should technically be possible to eat two of those spots because the game never actually forces more than two guests on you, I'm guessing that it's locked down pretty tight through hardcoding. Personally I haven't looked because I couldn't care less but apparently people really want this so maybe I will!

Quote from: pokeytax on August 21, 2011, 05:39:50 pm
Yes, while it should technically be possible to eat two of those spots because the game never actually forces more than two guests on you, I'm guessing that it's locked down pretty tight through hardcoding. Personally I haven't looked because I couldn't care less but apparently people really want this so maybe I will!

Guests can be removed from the party roster with some easy editing (Like I did for FFT: Plus...they only show up in battles, but not in the party menu...the only one that still shows up is Beowulf, because he is needed to trigger the sidequest)
So you could "eat" 3 spaces and not 2 :-)
P.s: Adding some extra space to the party roster would be epic behiond belief

Making Beowulf not be needed on the party roster should be rather easy, assuming the game actually checks for his Unit ID in WORLD.BIN and not just that you triggered the event and set the variable it follows correctly.  I doubt it actually checks for him, though... you can't boot him and there's already a variable to track the event, checking for the un-removable Beowulf would be redundant.  Then again, Squaresoft.

Ergo, I can has all four slots, please?

Side quest will beowuf are triggered if he's in the party.

0100 A700 0100 0100 A800 0100 0100 A900 0000 0400 1F00 1A00 1E00 D401 000000000000000000000000

wldcore.bin command for the Goland event. 0400 XXXX is the job check and in this case, its Beowulf.

Is there any way to change it?

I'm assuming the variable check command for WORLD.BIN is almost exactly the same as the one used in ATTACK.OUT, and if the event has no variables set innately... setting them would be easy enough, just editing one event to contain one additional line and changing the bolded line in Pride's code to check for said variable instead.

Wouldn't it be easier to just change wldcore.bin to remove the check, and/or change it to something dumb that's always true, like if Ramza's job (03) is in the party instead of Beowulf's (1F)?

Quote from: Glain on August 22, 2011, 09:49:40 pm
Wouldn't it be easier to just change wldcore.bin to remove the check, and/or change it to something dumb that's always true, like if Ramza's job (03) is in the party instead of Beowulf's (1F)?

You could do that too, since Beowulf doesn't actually join the party until after you complete Colliery anyway.  That's actually a derp-simple solution, changing the 1F to an 03.

I am in full support of a roster expanding hack. It would immediately be mandatory in every patch.

Quote from: RavenOfRazgriz on August 22, 2011, 10:20:52 pm
You could do that too, since Beowulf doesn't actually join the party until after you complete Colliery anyway.  That's actually a derp-simple solution, changing the 1F to an 03.

I think it would be wise to completely remove the check and alter the event a bit in order to not allow the choice...So Ramza will always accept his help

Quote from: Cheetah on August 22, 2011, 10:32:23 pm
I am in full support of a roster expanding hack. It would immediately be mandatory in every patch.

Before applying the patch you would need some FFPatcher editing (Guests never join, etc etc...) but yeah, I completely agree

I'm starting to become curious if it could be done without patcher edits... but you'd have to do something for the ENTD processing code like:

If [Join After Event] = true and [Save Formation] = true, then set [Join After Event] = false (No guests allowed in party);
[Save Formation] = false (Don't try to save stats/equip for guests);
[Load Formation] = false (Don't try to load stats/equip for guests).

Actually getting the game to allow you to have more than 16 regular party members could be a lot more complicated though, like Pokeytax was saying. Hmm... I may look into it.

...Except... why would you make a complicated code to do what unflagging things can do?

That sounds like the most literal form of overthinking and waste of space possible, considering you're writing a complicated ENTD check to simulate what unflagging Join After Event and Save Formation would do.  Basically, you'd be wasting code space and your own time to write a routine to do something that 5 minutes of skimming the ENTD with 3 brain cells can do for you.  Why the fuck.  It'd be faster and more efficient to just make a Vanilla .FFTPatcher file that unflags all the Guest-Join scenarios if you're worried about people being retards and forgetting to do that.

Though, "Guest" status is linked to Sprite ID in some way as far as all of my experiments have lead me, for those who didn't know.  Hence why Xifanie has a Generic Can Join as Guest hack and stuff.  Not sure how relevant that is going to be to making this happen, but I figured I'd point it out.

I wouldn't want to write a patch that only does part of what it's supposed to do, regardless if it's easy to do the other part separately... that's just cheesy. Saying "You need to change things here, there, and over there" is not generally as useful as just saying "This patch does what it says it does". It shouldn't be a waste of space if you can just replace lines of code in SCUS. As far as a waste of time? If I feel like it, it isn't.  :D

There's an important question, though... would you want to be able to retain control over guest joins but also expand roster size? In that case, we wouldn't want to do what I mentioned in my previous post (unless it was a separate patch) because it would limit your options.

I actually suspect this would all be the easy part of the patch though, so I wouldn't worry about time taken on this part as opposed to the part where you actually allow more than 16 party members to join.

It's interesting what you mention about guests and sprite set. Maybe it's something that applies to generics specifically? I'm quite sure I had 17 Gafgarion permanently in my party in a patch I was playing around with. (The 11 version will crystalize at Lionel if he goes down, as it's a job check and not a Unit ID check)

Quote from: Glain on August 23, 2011, 08:12:18 pmThere's an important question, though... would you want to be able to retain control over guest joins but also expand roster size? In that case, we wouldn't want to do what I mentioned in my previous post (unless it was a separate patch) because it would limit your options.

This is the other bit - lost functionality.  If I only want slots 1-19 usable and slot 20 for a Guest... I can't because you removed that feature so someone could save either opening a .fftpatch that only changes the ENTD or save unclicking like 5 check boxes.  Letting some ass be lazy lost functions needlessly.  That's also terrible, personally.

Quote from: Glain on August 23, 2011, 08:12:18 pmIt's interesting what you mention about guests and sprite set. Maybe it's something that applies to generics specifically? I'm quite sure I had 17 Gafgarion permanently in my party in a patch I was playing around with. (The 11 version will crystalize at Lionel if he goes down, as it's a job check and not a Unit ID check)

17 Gafgarion has both a different UnitID and JobID, you realize that yes?  I'm looking at the event command right now, it's UnitID.  Events don't check Job IDs.  Vanilla FFT just has Special Units with their UnitIDs and JobIDs matching.  Your 17 Gafgarion doesn't Crystalize because his UnitID is 17, not 11.

Lost functionality would obviously be a problem, yes. That in and of itself would necessitate a different approach. Not sure what laziness has to do with anything, but yes, you shouldn't sacrifice functionality in exchange for laziness (Obviously).

Just to clarify, I was referring to base job ID / sprite set and not just job ID, but regardless, it doesn't matter, as apparently it is indeed the Unit ID that is checked and not the base job.

I'm trying to find Unit ID in the in-battle data and it's just... buh? For enemies it seems to be 0x0161 away from the start of the unit's data (base job), but for allies, it might be at 0x0161 and might be at 0x015F? Or maybe something else? Uh?

So if I have a 11 Gafgarion at Lionel, what happens? I get 11 and the real Gaf has to take something different? Or is it something delightfully stupid like Unit IDs not really being unique?

The latter.  The Event will wig and stuff, if memory serves, but I haven't played with matching IDs much yet.  You can reuse UnitIDs safely as long as the same ID doesn't appear twice in the same battle.  The only "Special" ones are Ramza's 3 IDs (01, 02, 03), because they trigger the hardcoded Game Over sequence when they're Crystalized, and 70-8F.  70-7F are the Generic Player Unit IDs (aka, the ones placed by the player), and 80-8F are the Generic Everything Else Unit IDs.  But yeah, UnitIDs are really only "unique" in that they're how you flag specific units during battle, and when your Special Unit Joins, your UnitID is preserved for things like the dialogue between Agrias and Gafgarion at Golgorand Execution Site.  Outside of those things, UnitIDs aren't at all "unique" in the sense most people think they are.

Very interesting! That's useful to know. I guess I can see why Square did it that way, though personally I think they should have kept the IDs unique.

It's interesting. It's like... for events you'd have to use the Unit IDs, because you wouldn't want to be confused about which unit to use if they had the same base job. But on the other hand, the Unit ID gets the base job anyway, because you wouldn't know what the Unit ID is for special characters otherwise, as they could be fielded in any order...

Regardless! I seem to have created a rather impressive tangent...

Quote from: Glain on August 23, 2011, 10:32:31 pm
Very interesting! That's useful to know. I guess I can see why Square did it that way, though personally I think they should have kept the IDs unique.

Basically, the UnitID is its own thing in ENTD, and saved as its own thing when a character joins.  For 70-7F, if your unit has a Special ID, it's treated as having BOTH the "Generic" placed ID and its unique UnitID.  The 70-7F UnitIDs are usually only called for things like when your party runs in to fight Velius, etc. and it can be any number of any units, and all the potential 70-7F IDs that could appear at that particular moment are called simultaneously.  They're never used for things that don't affect the entire player party, or an entire deploy squad simultaneously, etc.

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)

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.

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.

Quote from: Glain on August 24, 2011, 04:21:32 pm
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.

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

Quote from: Xifanie, March 20, 2009
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.

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

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.

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!

Quote from: Cheetah on August 28, 2011, 01:13:19 am
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.

Quote from: Glain on August 28, 2011, 12:03:25 pm
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.)

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)

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.

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.

Awesome!
Edited the first post

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.

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?

...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.

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.

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.

Quote from: RavenOfRazgrizthe 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.

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.

Quote from: pokeytax on August 31, 2011, 06:06:33 pmYes, 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.

This is going to be one of the best ASM ever made

Quote from: pokeytax on August 31, 2011, 06:06:33 pmYes, 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.

Issue you're going to have though, is that the game uses the same flag setup that saves Guest to the Formation Screen to silently add Generic Units to the player's party.  If you make the game blanket-ignore these flags, you won't get your 5 Generics at the start of the game.  You'll need to work around that somehow, too.

...And even with the SCUS hack, the patch maker will need to edit the ENTD anyway to make sure that the proper Algus/etc load into the battle, as the current ones are just huge piles of random everything with "Load Formation" checked.  So, I still don't see the SCUS hack as being worth the time, as they'll need to update their ENTDs regardless.

Those generics don't seem to have Save Formation checked though (ENTD 188?) so how would it be the same set of flags? Delita does, but we already know he's a guest.

Is there anything wrong with the huge piles of random everything? There's not going to be anything in the formation for them to load anyway, so the information of what they used to have just isn't there. Seems for the most part they're being set to Party Level - Random with their base job and random equipment; reasonable enough in my opinion, and you can always change what you want manually. I guess you could get them to spawn with really good stuff if you levelled high enough (unless you used my gear level hack or something), but could you get that stuff off of them?

Quote from: Glain on September 02, 2011, 10:04:22 pmIs there anything wrong with the huge piles of random everything? There's not going to be anything in the formation for them to load anyway, so the information of what they used to have just isn't there. Seems for the most part they're being set to Party Level - Random with their base job and random equipment; reasonable enough in my opinion, and you can always change what you want manually. I guess you could get them to spawn with really good stuff if you levelled high enough (unless you used my gear level hack or something), but could you get that stuff off of them?

The issue is that (IIRC) their Brave, Faith, and Zodiac are random, and I think their base Job might be set to Random too.  It's nott he Guests scaling or coming in with random things, but the fact there's lots of stuff set to random that SHOULDN'T be set to random no matter what you're doing that you'll often need to fix... and if you need to fix it all anyway, it only takes an extra second to press the Load/Save Formation button.

wow i just noticed this... finally. its easy to work around guest situations, 4 extra slots is significant

Okay, sorry to bump, but I needed to share this. I had been messing around with guest players before this and I found out that if you have a guest player in your party in one of your original 16, then when the guest went to leave, they would actually stay there and it would take the one out of your original 16.

Then I found this and I was playing the game a bit just to test it out. I was right before you save Algus from the Death Corps and I kicked Delita outta my squad, even though he original entered as a guest. When the battle started Algus was in the place of Delita for some reason and I chose not to save Algus. It was pretty great to see Algus turn and look at himself and say "I'll save him...".

;) Again, sorry to bump.

Dome, I don't think the link in the OP is the most recent version.  Can you update it to this one (http://ffhacktics.com/smf/index.php?topic=7629.20#msg154297)?

Yep :-)
And thanks again for this awesome hack

No problem.  Have you (or anybody) noticed any issues?

Nope
As far as I've seen, everything works just fine

Question:
Does this version fixes the "Beowulf problem"?

Quote from: Dome on February 08, 2013, 04:17:52 am
Question:
Does this version fixes the "Beowulf problem"?

Yes, this includes a WLDCORE edit to remove the Beowulf check.  I don't really like doing so when that may interfere with existing patches, but it's the simplest thing and the patch author can always just remove that line from the XML.

Awesome!
Thanks a lot for the quick reply

could anyone please explain how to use this? I have absolutely no idea.

anyone having trouble triggering the worker 8 ball event? i have mustadio in the party with this active but i cant trigger the event. any clues?

First off, the thread is over a year and a half old. Make a new thread next time.

Second. This post holds true to what you are having an issue with as well, you need to remove the checks for the special party members in the worldmap instructions.
http://ffhacktics.com/smf/index.php?topic=10735.msg204669#msg204669

Hello, not happy about this necro, but can't see any other post related to this ASM.
Based on what Dome and pokeytax said, Beowful's problem is fixed,

is there any other bug (aside from breeding monsters) documented?.
Worker 8's event or any other across the entire vanilla game?, Thank you.

This is still somewhat bugged last I checked. Units in the guest slots remain flagged as Guests, and I think there were other issues with those slots as well...

Oh, too bad there is no stable use for general-vanilla use,

Thanks for the anwser,

A while back a new user kind of showed up or of the blue and fiddled with a bunch of people's hacks. He claimed to have fixed this one in particular. I don't know if he or anyone else ever tested it or even looked it over.

This could be a solid lead or a wild goose chase. If you want to test it you'd pretty much have to pay though every event in the game and use units 16 - 20 in every battle.

You can find it here under PRE.xml

https://github.com/xjamxx/FFTPatcher/tree/master/FFTorgASM/XmlPatches (https://github.com/xjamxx/FFTPatcher/tree/master/FFTorgASM/XmlPatches)

@Timbo
Yes, it's been tested because we wanted to use it for TLW, but it's broken as hell, worse than that original one IIRC.

Quote from: Xifanie on March 10, 2020, 01:11:43 pm@Timbo
Yes, it's been tested because we wanted to use it for TLW, but it's broken as hell, worse than that original one IIRC.

Sorry for getting anyone's hopes up. 😬