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

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Glain

541
PSX FFT Hacking / Re: Question (Party roster size)
August 23, 2011, 09:50:47 pm
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?
542
PSX FFT Hacking / Re: Question (Party roster size)
August 23, 2011, 08:12:18 pm
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)
543
PSX FFT Hacking / Re: Question (Party roster size)
August 23, 2011, 06:20:30 pm
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.
544
PSX FFT Hacking / Re: Question (Party roster size)
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)?
545
Heal for 1x. Or maybe x/2!

I don't agree with any of the options. Why should Weak and Absorb take any effect when you're healing? Those should be disjoint states that affect how a character takes damage from an element. (That would also mean you can't stack them; why could you?)

And why would a character weak to an element be healed effectively by it? I'd say don't modify the heal at all, but if you really wanted to do something, then halve it!

Honestly, I wouldn't generalize the whole "undead reversal" concept... if that is indeed what's going on here? At least not in that way. Maybe have another way to do it, but doing it with Weak vs Absorb just doesn't seem right.
546
Just wanted to say it's quite interesting that you mention running the FFTPatcher suite in wine -- we've had a few people attempting to do that, haven't we, with little success? Was there anything non-straightforward about getting it to work?
547
You can use any effect (animation) you want for any ability. It has nothing to do with skillsets. As Shade and Pride were saying, some animations just don't go off on any more than one target, even if the ability is coded to hit multiple.

Also, if you're unfamiliar with the ability names, I believe the hex codes are the same, so if you like the animation of "0EC Blind 2", for example, just select whatever 0EC is called in the PSP naming.
548
PSX FFT Hacking / Re: ALMA 3: previewability 0.1
July 25, 2011, 12:37:17 pm
Nah, the [lui] instruction doesn't actually load anything from memory (it's like the only command starting with 'load' that doesn't), so there's no load delay slot in play here.

I gotta say, that is something. I wouldn't have thought there was anything wrong with that code either... I can only throw out some half-baked theories:
1. Doing a comparison in a branch delay slot that changes one of the registers being compared in a conditional branch is somehow a problem? (lines 6 and 7)
2. Attempting to save to those memory addresses (0x8015A820, 0x8015A824) is somehow a problem? (lines 2 and 3)
3. Logic: r3 being set to (r2 < 0x79) instead of (r2 < 0x50) if the first branch is taken is somehow a problem? (unlikely as you probably already considered this)

The thing is, none of it seems likely. The huge list of [nop] fixing the problem is reallllllly bizarre. I actually think the [nop] in the original code is unnecessary (not sure why it's there).

EDIT: beq r0, r0? Don't you mean j?
Also, even though branch delay and load delay are similar, one is branching and one is memory loading, so it's probably better if we differentiate, i.e. beq/bne have a branch delay slot, not a load delay slot. But anyway.
549
Help! / Re: Blank Skills
July 24, 2011, 02:48:10 pm
As far as I know, you can use the ones in the gap between Parasite and Potion except for the last one, which is actually the normal attack ability.
550
Help! / Re: Formula 0D - Question
July 24, 2011, 12:27:08 pm
Yeah, Pride's version is the best.

I was going to say, if the status proc function 0x187eb4 didn't return the proper value in r2, you may still need to remove the check that I was removing, but I think we can get away with this as is, because 0x187eb4 seems to return the hit status bit in r2 (1=hit, 0=miss), so that will feed okay into the next check and we won't skip the part of the function we need to run.
551
Help! / Re: Formula 0D - Question
July 23, 2011, 10:44:07 am
Not sure. There's also the option of hacking formula 0D. This will only work with the PSX version; don't attempt this on the PSP version. Back up your ISO if you try this regardless, as I really haven't tested this.

You could try patching this with FFTorgASM:


 <Patch name="Formula 0D can hit when status not applied">
   <Description>
      Formula 0D can hit when status not applied
   </Description>
   <Location file="BATTLE_BIN" offset="121F68">
     00000000
   </Location>
 </Patch>


Basically, that's just removing the check that says "Did the status not get applied? If so, forget it!" (From looking at the ASM, this also seemed to happen if the target was undead?)
552
I don't even think offsets are the half of it. I believe the code was modified and recompiled for the PSP -- even the same routines wouldn't have the same code. Luckily the target assembly language is still MIPS, but it is for a later architecture, so the compiler might have generated totally different looking ASM! Maybe even a few commands the PSX can't use -- barrels of fun, I'm sure.
553
Help! / Re: generating hacking spreadsheets and xml
July 12, 2011, 11:36:52 am
I haven't looked at the code, but based on how the XML patches look, you've got enough information to patch any game, so long as it can read the ISO. The procedure for patching other games would be no different than patching FFT. You'd just have to know what you're trying to patch -- file paths, file names, offsets -- and put those in the XML patches. (<Location file="PATH_FILENAME" offset="OFFSET"> tags.)
554
Quote from: Pride on July 06, 2011, 09:28:41 am
By story progression, you mean integer 0x006E correct (from this list: http://ffhacktics.com/instructions.php?id=B0)

I assume so but I want to be sure.


:shock:

I hadn't thought to look for a list like that within the documentation for those commands. Would have helped! Instead I did a bunch of detective work to get 0x6F, but that's for shop availability, which was more what I was doing with the gear level. Is 0x6E more granular?

Edit: Seems that it is. Variable 0x6E goes all the way up to 0x35 = 53, whereas variable 0x6F only goes up to 0x10 = 16.
555
PSX FFT Hacking / Re: FFTPatcher needs some lurve
July 07, 2011, 09:30:21 am
Before I weigh in... have the Linux people tried running any of the .NET apps like FFTPatcher in wine? It might get around the problem. I do have a Linux setup I could test some of this on, but a lot of it is just seeing what other people have done...

If not, .NET might be pigeonholing us a bit into Windows. Can't say I agree about spreadsheets being more useful than apps.
556
All right, I've got what I think is a fix for this. Seems to work for me, at any rate.

I think the problem with those two battles, as you guys have basically deduced, is that the story variable hasn't been set to 1 yet, so it's 0 and no gear is allowed. When the game sets the story variable, it looks like this decompiled from TEST.EVT:

ZERO(x006F)
ADD(x006F,x0001)

This is where the story variable gets set to 1, and it looks like it's happening at the start of the Gariland battle. But the random gear is picked before the battle starts, i.e. before this event is run.

What I've done is change my routine to basically say:
1. [Allowed gear level] = [Story progression variable]
2. If [Allowed gear level] = 0, set [Allowed gear level] = 1
3. Return [Allowed gear level]

Here's an XML patch:

  <Patch name="Random unit gear based on story progression">
    <Description>
      Random unit gear based on story progression
    </Description>
    <Location file="BATTLE_BIN" offset="F59BC"> 
      FF00A530
      E4FFBD27
      1400BFAF
      0400ADAF
      0800A5AF
      0C00A6AF
      1000A7AF
      64ED040C
      6F000434
      0100452C
      21704500
      1400BF8F
      0400AD8F
      0800A58F
      0C00A68F
      1000A78F
      1C00BD27
      20000234
      0800E003
      00000000
    </Location>
    <Location file="SCUS_942_21" offset="4D49C">
      9400BFAF
      21688000
      6F72050C
      20000234
    </Location>
    <Location file="SCUS_942_21" offset="4D52C">
      00000000
    </Location>
    <Location file="SCUS_942_21" offset="4D5D8">
      0A00A390
    </Location>
  </Patch>


For those interested in what I've actually done on an ASM level, here's the relevant part:

jal 0x0013b590           # r2 = [Story progression variable] (code for this variable = 0x6f)
ori r4,r0,0x006f
sltiu r5,r2,1                 # r5 = (r2 == 0)  (If r2 == 0, r5 = 1, but r5 = 0 otherwise)
addu r14,r2,r5             # r14 = r2 (Story progression variable) + r5
557
It depends on which XML you're using, but the patch names should be pretty specific. The patch descriptions cover most of it, but are pretty vague, so I can try to elaborate by patch name (I've got 3 different XML patches in this thread that do something like this).

Before I list them out, I should probably point out that I have a bugfix in this thread for a tendency in FFT's random gear picking routine to use a low quality item if it has to consider more than one item type (e.g. armor and robe). The "Random unit equipment more selective" XML should take care of that, and can be used in tandem with any of the patches.

Now, as far as the patch itself goes, you can choose one of three options (all found in this thread):

"Random unit gear based on story progression" (the latest XML): Enemy gear will just be based on where you are in the story (which is the current shop availability). No need for the ENTD box. You can manipulate which items are available in the shops at which points in the story in the items section in FFTPatcher.

Now, a note about the next two XML patches. They do something similar, but both use that ENTD box that you mentioned. The way FFT's random gear picking routine works by default is that it tries to pick the item with the highest item level that is still not beyond the unit's level. If you use this patch, the number in the ENTD box will be used as a replacement for the unit level in that routine. The thing to remember is that this box holds a hex value. So if you wanted an enemy to use gear that is no higher than item level 25, you'd set the box to "19", because hex 0x19 = 25. (You can see and change item level for each item in the items section of FFTPatcher).

"Random unit gear priority: [Flag 0x0169, Default, Level]": Checks the ENTD box, but if no number was specified in that box, it'll use a default number based on the last time it checked that box. If it can't find that either, it'll take the unit level as normal. You can see Darkholme and I discussing this process in the thread a bit.

"Random unit equipment based on unit flag 0x0169": Only looks at the ENTD box, but will use unit level it if can't find that.

I should probably just make a comprehensive XML with all this stuff in it...
558
PSX FFT Hacking / Re: Floating Point Multiplication
June 29, 2011, 09:55:33 am
I'm starting to wonder if we can get away with something like...

r2 = (numerator)
r3 = (denominator)

and if you want to multiply fractions, just multiply (numerator) * (numerator) and (denominator) * (denominator) and then at the very end, just do (r2 / r3).

Seems like it'd be way simpler but I'm not sure how high r2 and r3 might get. Then again you've got 32 bits and you're probably only working with a final damage number that's a halfword anyway. I don't know... it's a thought. Seems like less work if we can get away with it.
559
MassHexASM is written in C#. The reason I went with C# is primarily because I wanted access to the Windows forms and the web-like elements it contains (textboxes, buttons, what have you). ...Come to think of it, a lot of our apps would probably be more portable (for example, to Linux) if we wrote them in C++ using GNU gcc, or even Java, but that could be annoying.

armips is great and all, and we could use it, but there's no reason to uproot our current encoding/patching process, since we already have our patcher (FFTorgASM) and assembler (MassHexASM, as it takes the mantle from Renegade64). Not worth changing.
560
PSX FFT Hacking / Re: Coding Standards Sticky
June 27, 2011, 01:14:54 pm
I forgot about that one.

From what I can tell, you're not allowed to use mult or div within two instructions of using mfhi or mflo (this may also apply to mthi and mtlo). Wikipedia says "Do not use a multiply or a divide instruction within two instructions of mfhi/mflo (that action is undefined because of the MIPS pipeline)"

Let's say we want to perform this operation:

r10 = (r2 * r3) + (r4 * r5)

Incorrect
mult r2,r3            # Perform r2 * r3
mflo r8                # r8 = (r2 * r3)
mult r4,r5             # Perform r4 * r5             Not allowed to use mult within two commands of mflo.
mflo r9                # r9 = (r4 * r5)
addu r10,r8,r9      # r10 = r8 + r9

Correct
mult r2,r3            # Perform r2 * r3
mflo r8                # r8 = (r2 * r3)
nop
nop
mult r4,r5            # Perform r4 * r5
mflo r9                # r9 = (r4 * r5)
addu r10,r8,r9      # r10 = r8 + r9

You could be more efficient if there were some other commands you could throw in place of the nops, but there's nothing relevant to this particular example that could go in those slots, as far as I can tell.