• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
March 28, 2024, 04:46:02 am

News:

Don't be hasty to start your own mod; all our FFT modding projects are greatly understaffed! Find out how you can help in the Recruitment section or our Discord!


(ASM) Gear level - Now can use story progression instead of level/0x0169

Started by Glain, March 27, 2011, 12:57:58 pm

Glain

Thanks guys. Yeah, as pokeytax said, Blaze Gun and Stone Gun would never be loaded randomly anyway unless you unchecked the rare flag, so you wouldn't run into that scenario.

Since mantles seem to be a progression (i.e. next to each other in the item list), their quality should indeed scale up with the enemies, so no late game Small Mantles! :cool: The mantles do appear to have rather high level requirements though (10 for small, 20 for leather, 30 for wizard, etc).

EDIT: Turns out I found a problem with that patch loading in gear in the wrong slots. I'll have to figure out what's wrong with it.
Solved this issue... Patch is back in business! Refer back to that patch post for more details.

Darkholme (and/or anyone interested):

I did just check out the idea of saving the gear level on Ramza as a default. It might indeed work (and I've got a patch for it :)), but I'm not totally sure if I can properly get away with what I'm doing...

Turns out Ramza's out-of-battle data is loaded in all the time... at least from everything I tested. World map, story battles, random battles, cutscenes, chapter changes, oh my! His data was always there. It even saved to the memory card! Perfect!

Most of Ramza's data is in use though. It starts at 0x00057f74 and goes for another 0x100 bytes, where it runs into the next unit's data. I found a location that was 16 or so bytes away from most of his data, in an area that always seemed to be filled with zeroes, and loaded/saved properly... 0x00058053. That's my magic memory location. It weathers everything, saves/loads, and hopefully isn't used for anything. Perfect, except I'm not sure about that last part! (This is why I'm not sure if I can truly get away with what I'm doing.)

The modification we were talking about just means I have to modify my BATTLE.BIN subroutine. I came up with this:

EDIT: I've got a new patch and a new routine!


(1) Load r14 = unit's offset (0x0169)
0015c9bc: 91ae0169 lbu r14,0x0169(r13)
0015c9c0: 30a500ff andi r5,r5,0x00ff

(2) Conditional branch based on value of r14 [0x00 -> continue; 0xFF -> Jump to (5); Neither -> Jump to (6)]
0015c9c4: 25c30001 addiu r3,r14,0x0001
0015c9c8: 306300ff andi r3,r3,0x00ff
0015c9cc: 28630002 slti r3,r3,0x0002
0015c9d0: 1003000a beq r3,r0,0x0015c9fc
0015c9d4: 00000000 nop
0015c9d8: 140e0006 bne r14,r0,0x0015c9f4
0015c9dc: 00000000 nop

(3) Load r14 = default (0x00058053)
0015c9e0: 3c0e0006 lui r14,0x0006
0015c9e4: 91ce8053 lbu r14,-0x7fad(r14)
0015c9e8: 00000000 nop

(4) If r14 > 0, jump to (7)
0015c9ec: 140e0005 bne r14,r0,0x0015ca04
0015c9f0: 00000000 nop

(5) Load r14 = unit's level (0x0022) and jump to (7)
0015c9f4: 91ae0022 lbu r14,0x0022(r13)
0015c9f8: 08057281 j 0x0015ca04

(6) Save r14 to default (0x00058053)
0015c9fc: 3c030006 lui r3,0x0006
0015ca00: a06e8053 sb r14,-0x7fad(r3)

(7) Return
0015ca04: 03e00008 jr r31
0015ca08: 00000000 nop



(1) Load from unit's offset (0x0169)
0015c9bc: 91ae0169 lbu r14,0x0169(r13)
0015c9c0: 30a500ff andi r5,r5,0xff
0015c9c4: 140e000e bne r14,r0,0x0015ca00
0015c9c8: 00000000 nop

(2) If result = 0, load from 0x00058053 (the default)
0015c9cc: 3c0e0006 lui r14,0x0006
0015c9d0: 91ce8053 lbu r14,-0x7fad(r14)
0015c9d4: 00000000 nop
0015c9d8: 140e000b bne r14,r0,0x0015ca08
0015c9dc: 00000000 nop

(3) If result >= 255 (0xFF), result = 0
0015c9e0: 29c300ff slti r3,r14,0x00ff
0015c9e4: 140e0008 bne r3,r0,0x0015ca08
0015c9e8: 00000000 nop
0015c9ec: 140e0006 bne r14,r0,0x0015ca08
0015c9f0: 00000000 nop

(4) If result = 0, load from level (0x0022) and jump to (6)
0015c9f4: 91ae0022 lbu r14,0x0022(r13)
0015c9f8: 00000000 nop
0015c9fc: 08057282 j 0x0015ca08

(5) Save to 0x00058053
0015ca00: 3c030006 lui r3,0x0006
0015ca04: a06e8053 sb r14,-0x7fad(r3)

(6) Return
0015ca08: 03e00008 jr r31
0015ca0c: 00000000 nop


I tested in a story battle to make sure nothing ridiculous happened. It all seemed fine, the same as before... so at the very least, it's not horribly breaking. I also checked to see if it saved to the right location... which it did. (After I had to modify the ASM a bit... didn't know about those negative lbu and sb offsets! Sneaky!)

I haven't actually tested this in a random battle yet however... I can't seem to remember where you run into humans in random battles, and thought you might have a good test scenario. Normally I'd do more testing before listing out a patch, but since I've already got the hex codes for the ASM, why not?

Use at your own risk... (Eh, just make a backup of your ISO :))


   <Patch name="Random unit gear priority: [Flag 0x0169, Default, Level]">
    <Description>
   Random gear in ENTD will now be based on unit flag 0x0169
        (in ENTD, unknown section, last row, leftmost box)
        instead of unit level. If unit flag 0x0169 is 0, it will
        try to load a 'default' level based on previous levels. If
        that also fails, unit level will be used as normal. Unit
        level will also be used if 0xFF (255) is specified for the
        gear level.
    </Description>
    <Location file="BATTLE_BIN" offset="F59BC">
      6901AE91
      FF00A530
      0100C325
      FF006330
      02006328
      0A000310
      00000000
      06000E14
      00000000
      06000E3C
      5380CE91
      00000000
      05000E14
      00000000
      2200AE91
      81720508
      0600033C
      53806EA0
      0800E003
      00000000
    </Location>
    <Location file="SCUS_942_21" offset="4D49C">
      9400BFAF
      21688000
      6F72050C
      20000234
    </Location>
    <Location file="SCUS_942_21" offset="4D52C">
      00000000
    </Location>
  </Patch>
  • Modding version: Other/Unknown

Darkholme

I'll have to test thisafter my exam on next monday. I'll probably just make a random battle with a bunch of generics and see how it turns out.

Darkholme

Quote from: Glain on April 05, 2011, 08:43:39 pm
Thanks guys. Yeah, as pokeytax said, Blaze Gun and Stone Gun would never be loaded randomly anyway unless you unchecked the rare flag, so you wouldn't run into that scenario.

Since mantles seem to be a progression (i.e. next to each other in the item list), their quality should indeed scale up with the enemies, so no late game Small Mantles! :cool: The mantles do appear to have rather high level requirements though (10 for small, 20 for leather, 30 for wizard, etc).

EDIT: Turns out I found a problem with that patch loading in gear in the wrong slots. I'll have to figure out what's wrong with it.
Solved this issue... Patch is back in business! Refer back to that patch post for more details.

Darkholme (and/or anyone interested):

I did just check out the idea of saving the gear level on Ramza as a default. It might indeed work (and I've got a patch for it :)), but I'm not totally sure if I can properly get away with what I'm doing...

Turns out Ramza's out-of-battle data is loaded in all the time... at least from everything I tested. World map, story battles, random battles, cutscenes, chapter changes, oh my! His data was always there. It even saved to the memory card! Perfect!

Most of Ramza's data is in use though. It starts at 0x00057f74 and goes for another 0x100 bytes, where it runs into the next unit's data. I found a location that was 16 or so bytes away from most of his data, in an area that always seemed to be filled with zeroes, and loaded/saved properly... 0x00058053. That's my magic memory location. It weathers everything, saves/loads, and hopefully isn't used for anything. Perfect, except I'm not sure about that last part! (This is why I'm not sure if I can truly get away with what I'm doing.)

The modification we were talking about just means I have to modify my BATTLE.BIN subroutine. I came up with this:


(1) Load from unit's offset (0x0169)
0015c9bc: 91ae0169 lbu r14,0x0169(r13)
0015c9c0: 30a500ff andi r5,r5,0xff
0015c9c4: 140e000e bne r14,r0,0x0015ca00
0015c9c8: 00000000 nop

(2) If result = 0, load from 0x00058053 (the default)
0015c9cc: 3c0e0006 lui r14,0x0006
0015c9d0: 91ce8053 lbu r14,-0x7fad(r14)
0015c9d4: 00000000 nop
0015c9d8: 140e000b bne r14,r0,0x0015ca08
0015c9dc: 00000000 nop

(3) If result >= 255 (0xFF), result = 0
0015c9e0: 29c300ff slti r3,r14,0x00ff
0015c9e4: 140e0008 bne r3,r0,0x0015ca08
0015c9e8: 00000000 nop
0015c9ec: 140e0006 bne r14,r0,0x0015ca08
0015c9f0: 00000000 nop

(4) If result = 0, load from level (0x0022) and jump to (6)
0015c9f4: 91ae0022 lbu r14,0x0022(r13)
0015c9f8: 00000000 nop
0015c9fc: 08057282 j 0x0015ca08

(5) Save to 0x00058053
0015ca00: 3c030006 lui r3,0x0006
0015ca04: a06e8053 sb r14,-0x7fad(r3)

(6) Return
0015ca08: 03e00008 jr r31
0015ca0c: 00000000 nop



So.
1. it loads the gear level from the unit, and if !=0, it jumps to 5.
2. if the number is 0, load it from ramza. then skip to the end.
3. If the result is >=255 set "result"=0. (I dont understand the asm for this one)
4. if it's now equal to 0 load it from the unit's level; and then skip saving and go to 6.
5. Save the number you have on ramza.
6. End.

Here's how I see that it's supposed to work based on a readthrough of it (in theory).
- So: It assigns the numbers in whatever order they're loaded in battle, meaning the last one loaded is the number saved, as opposed to the highest in the battle or the lowest or anything like that. So if you put level 5, 10, and 15 gear into the fight, whichever one is read in last (likely the one with the highest index) is the level that gets saved.
- If you set it to 255, to use 'Unit Level' for gear, it doesn't save the number. This is useful for bosses and whatever else you might want to have a higher level of gear, without raising the level of gear in random battles.

So; I guess, the best way to do it, is Set the level of gear you want people to have in general at the beginning index (excluding anyone you set to 255), leave all the people in the middle at 0 (since they'll use the number of whoever came before them) and set the level of gear you want random battles to use at the end index, (you might not even need to include them in the fight, just set them to not show up).

Here's a bug I think I found.
- If you set the number to 255, #1 doesn't check for it, and it jumps to 5 and saves 255 in ramza's number.

Glain

Yeah, I noticed numerous problems with that routine, and have now updated the previous post with a new one! I was trying to be a bit clever in section (2) in the new one, particularly:


0015c9c4: 25c30001 addiu r3,r14,0x0001         r3 = r14 + 1 (0x00 would become 0x01, 0xFF would become 0x100)
0015c9c8: 306300ff andi r3,r3,0x00ff               r3 = (Lowest byte of r3) (Affects nothing EXCEPT 0x100 becoming 0x00!)
0015c9cc: 28630002 slti r3,r3,0x0002              r3 = (r3 < 2) (Only true if r14 was 0x00 or 0xFF!)


I am still testing the new patch, but I entered a random battle and got a knight whose level was too low for diamond helmet, but was still equipped with one. The magic memory location had 22 in it, which would have been high enough... (and made sense as I was in chapter 3). So maybe it's working!
  • Modding version: Other/Unknown

Darkholme

I'd really like to see another #4 after #5, personally, as I liked the idea that if you load the unit's level it doesn't mess up the level of gear overall. I thought it would be useful because it allows you to use 255 on bosses. (and the current algorithm would raise the gear level to match the boss).

Other than that, great Job!

Glain

It should already be working the way you describe. :) The default gear level (0x00058053) should never be written to unless we loaded a non-0, non-FF value from 0x0169 of some unit. This can only happen at the first branch in (2). As long as the boss isn't the last unit with something at 0x0169, his gear level won't be the one that ultimately gets saved.

Are you sure you're not misreading the routine? We don't save anything to the default memory location except at the end of (6). We can't get to (6) except from the jump at (2). (5) jumps to (7), skipping over (6). Adding anything between (5) and (6) would be unreachable code. (That j statement is an unconditional jump) Or am I missing something?

(Haha, I think that should be some kind of record for number of parens in a single paragraph... :P)
  • Modding version: Other/Unknown

Darkholme

ah. Yeah.
that's me, not used to the ASM for this processor. I've only really looked at ASM for a SPARC processor. it doesnt have a j operator; It has ba for branch always.

Totally missed the j. Okay. no worries; carry on then. Fantastic work.
I'd like to seen every patch implement your random gear algorithm fix, and all the scaling patches use the gear scaling algorithm you just updated.

You wanna head over here next and see if you can help us figure out where they limit the FPS to get rid of the WotL slowdown?

Glain

So I found a way to use the story progression byte after all...

Way back in my first post in the thread (and the entire forum, as it happens), I made reference to attempting this, and finding the WORLD.BIN subroutine (RAM 0xef1a8) that seemed to get it. After a bunch of investigation, I seem to have found that same routine in BATTLE.BIN at RAM 0x13b590. It's the same code but with some different addresses, because we're elsewhere in memory. Makes you wonder why the routine isn't just in SCUS, but anyhow, since it's in BATTLE.BIN, I can use it in the gear picking code.

I believe this routine is actually what gets any script variable, i.e., those set/checked by TEST.EVT and ATTACK.OUT, with r4 = [the index of the variable]. Story progression is variable 0x6F (and this parameter is specified in WORLD.BIN as well when checking the shop items, but I didn't understand the significance of it before). That means, if I want the story progression byte, I go:

jal 0x0013b590
ori r4,r0,0x006f

Not so bad. Using story progression instead of unit offset 0x0169, we get this:


andi r5,r5,0x00ff          # Most likely worthless, but carried over from 0x5cc98
addiu r29,r29,-0x001c      # Make space on the stack
sw r31,0x0014(r29)         # Save return address to stack
sw r13,0x0004(r29)         # Save 0x5cc98's args to the stack (registers might be changed by 0x13b590)
sw r5,0x0008(r29)
sw r6,0x000c(r29)
sw r7,0x0010(r29)
jal 0x0013b590            # Find story progression variable! (code for this variable = 0x6f)
ori r4,r0,0x006f
ori r14,r2,0            # r14 = r2 (Story progression variable)
lw r31,0x0014(r29)         # Load return address from stack
lw r13,0x0004(r29)         # Load 0x5cc98's args from the stack
lw r5,0x0008(r29)
lw r6,0x000c(r29)
lw r7,0x0010(r29)
addiu r29,r29,0x001c      # Set stack back to original size
ori r2,r0,0x0020         # Set r2 back (0x5cc98)
jr r31                  # Return
nop


It's still nearly the same amount of space as the other one, even though there's far less relevant logic, because I had to save a bunch of registers on the stack that the gear-picking routine was using and I didn't know if 0x13b590 would overwrite them (it probably did). I also had to change the gear-picking routine to check the item's story progression instead of the item level (8 bytes to the right).

Anyhow! [Story progression] and [Unit offset 0x0169] patches are mutually exclusive, but the [more selective gear] patch/bugfix is totally independent of either of them.

Unlike the unit offset one, the story progression patch should be fire and forget -- no need to set anything in FFTPatcher, unless you wanted to edit item tiers. You may see a bit less gear variety though, since there are less item tiers than there are levels.


 <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
     00004E34
     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>

  • Modding version: Other/Unknown

pokeytax

This is another neat hack! And the stuff you uncovered is helpful in doing story progression job unlocks for the RAD hack. Also, actually seeing someone write out how they're using the stack is really useful.

Do you happen to know what variables the story progression/script variable subroutine overwrites?
  • Modding version: PSX

Glain

I tried to trace that routine a few times... it's fairly insane and the recursion makes it hard to remember how far into it you are. I'm not entirely sure how many registers it changes, but it's a lot.

FFT's compiled code was compiled under these conventions, which specifies that registers r16-r23 ($s0-$s7) must be preserved across routine calls (i.e., that these registers must be in the same state they started in when the routine returns). Standard practice is to assume that all other standard-use registers are overwritten (and that is probably not far off for this routine).

So basically, before calling a routine, save what you want saved either to:
1. The stack
2. r16-r23 (but you must save these registers to the stack before using them, and load them when done before returning)
3. Memory somewhere (if you want to save something outside the scope of this routine's stack frame, i.e. a global variable)

Since this is true for every routine, it saves us from having to figure out which routines change which registers, unless we're so cramped for space that we can't do things the normal way. But I'd assume this particular routine (0x13b590) changes everything but r16-r23, because it's an absolute beast.
  • Modding version: Other/Unknown

Eternal

So, I'm slightly confused on how to use this. After using it in orgASM, do I just set each item to the chapter I want enemies to start using it and then I'm good? Or do I have to put the 12 in the ENTD box I saw earlier in the topic? I'd appreciate if you clarified this. Thanks a ton! :D
  • Modding version: PSX & WotL
"You, no less human than we? Ha! Now there's a beastly thought. You've been less than we from the moment your baseborn father fell upon your mother in whatever gutter saw you sired! You've been chattel since you came into the world drenched in common blood!"
  • Discord username: eternal248#1817

Glain

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

Eternal

All right, this helps a ton. Thanks!

While I'm thinking about it, it'd be awesome if you could make that comprehensive XML and edited your first post with it. I think it'd help a ton of people out, but the way you have it now seems fine to me as well, IMO.
  • Modding version: PSX & WotL
"You, no less human than we? Ha! Now there's a beastly thought. You've been less than we from the moment your baseborn father fell upon your mother in whatever gutter saw you sired! You've been chattel since you came into the world drenched in common blood!"
  • Discord username: eternal248#1817

Eternal

Okay, so I've implemented the ASM and Xifanie noticed something: enemies in Orbonne I/Gariland don't start off with any gear. Which leads me to ask, do you know exactly when the game officially starts Chapter I?
  • Modding version: PSX & WotL
"You, no less human than we? Ha! Now there's a beastly thought. You've been less than we from the moment your baseborn father fell upon your mother in whatever gutter saw you sired! You've been chattel since you came into the world drenched in common blood!"
  • Discord username: eternal248#1817

Celdia

Et, do you really need story scaled gear randomly set on those battles? Just preset everyone. Its not like you don't know what level the player will be at.

*quietly slips off to edit the ENTDs of those battles in her own patch to have preset equipment*
  • Modding version: PSX
  • Discord username: Celdia#0

RavenOfRazgriz

Quote from: Eternal248 on July 02, 2011, 05:53:58 pm
Okay, so I've implemented the ASM and Xifanie noticed something: enemies in Orbonne I/Gariland don't start off with any gear. Which leads me to ask, do you know exactly when the game officially starts Chapter I?


Have you considered it might be directly after the battle in Gariland Magic City, where the Shop is available for the first time and carrying the Gear listed as being "Chapter 1 - Start"?

Glain

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

Eternal

Quote from: RavenOfRazgriz on July 02, 2011, 07:00:56 pm
Have you considered it might be directly after the battle in Gariland Magic City, where the Shop is available for the first time and carrying the Gear listed as being "Chapter 1 - Start"?


Yeah, Raven, I had pretty much determined it was that. Just struck me as odd since I'd think it'd be right when the game starts. =\

@Glain- thanks, that'll help a ton. *goes of to reset gear*
  • Modding version: PSX & WotL
"You, no less human than we? Ha! Now there's a beastly thought. You've been less than we from the moment your baseborn father fell upon your mother in whatever gutter saw you sired! You've been chattel since you came into the world drenched in common blood!"
  • Discord username: eternal248#1817

Dome

Necrobumping like a boss!

Sorry if I might sound stupid, but I want to be sure
Step 1: I apply this patch to my hack (FFT: Plus)

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


Step 2: Flag all the units I want in the FFPatcher with "Random" equipment

From now on, every unit I flagged that way will always have the best gear you can buy in stores (And not more/less powerful stuff), regardless of levels?

P.s: Is there any bug/problem I should be aware of?

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

Glain

If you also use the "Random unit equipment more selective" one in addition to that one, then yes. Without that patch, it can select really bad gear (due to a bug in vanilla).

I don't think there should be any problems, but let me know if you find anything. Sterling LaVaughn made a post here about using it.
  • Modding version: Other/Unknown