• Welcome to Final Fantasy Hacktics. Please login or sign up.
 

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

Started by Dome, August 21, 2011, 04:42:25 pm

Dome

From: Pokeytax


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

"Be wise today so you don't cry tomorrow"

Kokojo

(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.
I keep leaving, I keep coming back. Boomerang boy.

pokeytax

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!
  • Modding version: PSX

Dome

August 21, 2011, 05:49:55 pm #3 Last Edit: August 21, 2011, 05:52:14 pm by Dome
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

"Be wise today so you don't cry tomorrow"

RavenOfRazgriz

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?

Pride

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.
  • Modding version: PSX
Check out my ASM thread. Who doesn't like hax?

Dome


"Be wise today so you don't cry tomorrow"

RavenOfRazgriz

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.

Glain

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)?
  • Modding version: Other/Unknown

RavenOfRazgriz

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.

Cheetah

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

Dome

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

"Be wise today so you don't cry tomorrow"

Glain

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.
  • Modding version: Other/Unknown

RavenOfRazgriz

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

Glain

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)
  • Modding version: Other/Unknown

RavenOfRazgriz

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.

Glain

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?
  • Modding version: Other/Unknown

RavenOfRazgriz

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.

Glain

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...
  • Modding version: Other/Unknown

RavenOfRazgriz

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.