The “ALT_PID_Setter” function

Documentation
1

I wanted to consolidate some documentation regarding a function that can be found at these addresses:

FE6 = 0x08017764
FE7J = 0x0817DAC
FE7U = 0x08179BC
FE8J = 0x08017BDC
FE8U = 0x08017EBC

In laqieer’s function library they are listed separately, with the FE6/FE7 versions labeled “func_fe6_0817764” and the FE8 versions as “FixROMUnitStructPtr”.

I call it ALT_PID_Setter because it’s called during unit initialization and reduces the unit’s current PID by 1 if the Alt PID bit is set.

The function takes a unit structure as an argument and checks the character/class bitfield found in it’s PInfo for x00800000 (the top of the 3rd byte). If set, it subtracts 1 from the PID and writes the pointer to the new PInfo into the unit structure. This is presumably an alternate copy of the character and is used to turn Gonzalez B into Gonzalez in chapter 10B of FE6.

Despite there being a fair bit of documentation for these functions, it seems mostly scattered and information on it is poorly circulated.

Using FE8 with FE Builder has the Alt PID bit labeled as “NPC” with a hover text of “Unknown” while in FE7 it is ominously labeled “Usage prohibited” and a hover text of “Bugs the game. Don’t use without replacing default function”. This label makes sense as changing the PID of crucial units does indeed break many of the earlier game cutscenes most people do their testing on, often violently so.

To summarize, this function is present and fully functional in all versions, although it is only ever used natively once in FE6. FE6 is the only game to feature any characters with the alt PID bit set, and 9 out of 10 of those character slots go unused, with Gonzalez B being the sole case.

It’s not really hard to see why. The only unique feature of this incredibly inefficient system is being able to deploy a unit with a different weapon rank. I suspect this function is very old and a hold-over from an outdated and less flexible event engine early in development.

(Although this is just conjecture, I would say there’s even evidence that Gonzalez B was probably intended to be removed and was left in anyways.)

8 Likes
2

What makes you say that? Is it something to do with this ALT_PID_Setter function or other aspects of his inclusion?

1 Like
3

Gonzalez’s level in his PID is 7 but during his load event on route A is set to 5. On the B route, his level is set to 11 which matches the PID level of the B varient. This leads to a pretty huge power gap between the two.

There’s also a Geese B who’s only difference from base Geese is that he’s 2 levels higher. One could infer that one of this function’s original utilities was setting units to different levels, a feature of the current event engine.

This combined with every alt character being cut except the one gives me the the feeling that everything surrounding this mechanic was kinda scrapped and was probably slated to be cut altogether. This isn’t rock solid proof which is why I put that part in parentheses and said it was “conjecture”

The fact that it’s still present yet is completely unused 5 release versions later leads me to believe that the devs simply forgot about it, or didn’t care to remove it. It’s a super tiny function after all.

Edit: Changed my original post to say, “left in anyways”, instead of “left in by mistake”. Mistake is a powerful word and it’s a pretty big leap to assume the inclusion of Gonzalez B was specifically negligence on the part of the devs.

2 Likes
4

Are you sure it’s the same in FE8? I tried it a while ago and got some weird results, like Eirika changing into Neimi (who is 7 IDs after), and creating a gap in the roster.
image

EDIT: After thinking about it for a minute, subtracting the ID (which is 1) by 1 would probably cause some weird side-effects. Neimi showing up is probably a coincidence since everything else is 0.

1 Like
5

It your’re using FE8U, then line 0x08017ED8 explictly protects against… multiplying 0 by 0x34…? I think this was supposed to be some kind of safety check but ultimately still allows you to store 0x00000000 as a character pointer, nullifying them.

So yeah, using this function on any lord with the bit set will wipe them out and then trash the unit RAM.

If you want to set the bit and see it in action, make sure you edit any events to instead effect the character that they will become. For example, 68 O’neill will become 67, the unused bandit, so all events should point to him instead.

I thought a post on this function was warrented because of 3 factors:

-It’s effect is actually very simple in nature.

-It has an extreme effect on gameplay.

-It’s something that anyone playing around with
character info is very likely to encounter.

There doesn’t seem to be any broadly available information on it despite being both easy to encounter and having highly adverse effects.

6

Thanks for your research, we only need to remove this function and then we can get a custom character state bit CA_BIT_23(1<<23)

// for FE8U
PUSH
ORG 0x017EBC
SHORT 0x4770
POP
1 Like
8

It’s a technicality, but FE6 also does this with Dayan in chapter 20D (map 0x1F).

Still, very interesting to see it functions across the three games.

1 Like
9

You’re right! I missed that one.
It’s funny because the true Dayan actually has S rank bows at base but we instead get the one with only A rank. This would have been really useful, having someone who could immediately use Murgleis going into chapter 21.

There’s alot you can infer from these unused alts. Like how both of Tate’s alts are labeled C and D instead of A and B. Perhaps she was originally associated with the Illia/Sacae route split rather than the Western Isles one?

Also note that Tate D is actually flagged as an alt while Tate C isn’t. This means Tate D will become Tate C, but Tate C won’t change at all.

1 Like