[FE7,FE8] Array-based Weapon Lock System


#1

This hack, in its current incarnation, allows you to define weapon locks for characters or classes by an
array located anywhere you wish. It can also distinguish between ‘hard’ locks, which operate the same
as the vanilla GBA locks, or ‘soft’ locks, which let the matching character use the weapon at Level E,
no matter what its normal rank is.

This, however, requires some setup. Part of the ASM code will point to a pointer table; each
pointer in that table should lead to an array that determines which character IDs are part of the lock,
and whether the lock is a soft or hard one.

Which pointer in that table is used is determined by the Ability Byte 4 in the weapon you wish to give
the lock to. 0x01 means the weapon will use the first pointer; 0x02 the second, and so forth. 0x00 indicates that the weapon will not use a custom lock.

The proper format for each array is as follows: the first byte indicates whether or not the lock is
soft or hard, and whether it uses character or class IDs: 0x00 = soft character, 0x01 = hard character, 0x02 = soft class, 0x3 = hard class.
(So the first bit determines hard/soft; the second bit determines class/character)

Then follows the IDs of every character/class that is part of the lock. At the end of the array must be
a 0x00 byte, so the routine knows to stop looking for character IDs. There is also a feature whereby you can set a weapon to require ranks in multiple weapon types, or one among multiple. See the readme for more.

This hack will also nullify all of the default weapon locks based on the vanilla system. More details, and complete installation instructions, can be found in the readme itself.

The hack itself can be downloaded here.
(Old version)


Obsoleted Bytes in Fire Shell
FE_Builder_GBA
Resource Directory
Venno's small ASM hacks and notes
#2

This looks amazing.

Just one question: how hard would it be to expand that so that 0x00 gives you a soft character lock, 0x01 a hard lock, 0x02 a soft class-based lock, and 0x03 a hard class lock? Or to XX (soft/hard) YY (character/class) ZZ ZZ ZZ ZZ ZZ (list).


#3

Impressive. The Soft Lock aspect is a really nice touch.


#4

Wouldn’t be very tough, no. In fact I can probably have it do that in an hour or so.

In fact I’ve already done so! Check the download again.


#5

I’m gonna have to start coming up with a new wishlist.


#6

Venno is a wizard lol

EDIT

Are there meant to be random nop’s at the end of the file? Arch was having an issue where it was just breaking my patcher because I didn’t failsafe properly; I’m going to address that on my end as well but I feel like they wouldn’t be there if it was just garbage???


#7

No there definitely isn’t. I’m not sure what the deal is with those is - it’s almost like devkitpro is padding it out with nops to make the bytelength a multiple of 0x10. I can’t see anything in the source that would tell it to do that so idk. Looks like it happened with my weapon rank hack too.

Also I’m definitely not a wizard, practically anybody could do this stuff.


#8

Small update - weapons that had no rank but used a custom lock would display “-” as their rank instead of “PRF”. You only need to change one byte to fix this, so I’ve added instruction for this fix to the first post and the readme in the download


#9

This may or may not have an effect on how the AI sees locks. See the code around
080161CC

It may be fairly trivial to modify that code to simply look off of the 4th byte, though, however.

Edit: might be my bad – might just be the general method for determining if you can equip.


#10

No, you’re right - the code at 161CC is part of the general weapon lock checking code. The readme includes instructions for bypassing it if you don’t want to have the vanilla weapon locks in your game (e.g. to free up those bits in weapon data), but I’ll add that tibdibt to the OP.

I didn’t want the code to break any of the default weapon lock code in case somebody wanted to use it, which is why I set it up to branch from 0x08016350.


#11

Yeah uh, just disregard that. I was being temporarily stupid.


#12

There seems to be a bug in the current version that freezes.
Both EF7U and FE8U freeze.

I prepared a vanilla rom and applied the patch.
It seems that the game freezes at the event of loading units in prologue.


#13

In all of my attempts to use this the game freezes when loading units; is there a working example of this being used in a buildfile, by chance?