[FE7] Matthew's replacement doesn't come with keys

[IkeResplandeciente]

Matthew's replacement was Geitz as Bard, and he didn't come with any items, which in turn made Chapter 12H unbeatable because no one can open doors.

[IkeResplandeciente]

Checking the problem in FEBuilderGBA, I noticed that Geitz does have keys in his inventory, but not in his first slot. Perhaps that's the root of the problem?

[PurdraDan]

Checking the problem in FEBuilderGBA, I noticed that Geitz does have keys in his inventory, but not in his first slot. Perhaps that's the root of the problem?

This is still beatable, the enemy thief that spawns will always starting on turn 2 open every door and chest on this map before trying to leave, just go left first.

But I believe the keys on Geitz not spawning is indeed because the first item slot isn't filled in with any item

[abbatrombone]

I went and tried to recreate the bug, on my system, and on normal and hard mode for Hectors starting chapter and the data was there. I had a knight over a dancer though. It might be that combo that's the issue, with how the data was updated or seen. Ill try to look into more, but will take awhile as im still learning how all the code works.

[lushen124]

It's possible. I believe dancers have some logic to receive a random ring of some kind in FE7. Not sure why it would leave the first slot empty though. I think I did add logic later to collapse a unit's inventory (i.e. move empty slots to the end of the list), so this should no longer be an issue with the updated release.

[abbatrombone]

In FE7Data it looks for a dancer and only returns rings:

public static Set<Item> specialClassKit(int classID, Random rng) {
			if (classID == FE7Data.CharacterClass.DANCER.ID) {
				int randomIndex = rng.nextInt(allDancingRings.size());
				List<Item> rings = new ArrayList<Item>(allDancingRings);
				Collections.sort(rings, Item.itemIDComparator());
				return new HashSet<Item>(Arrays.asList(rings.get(randomIndex)));
			} else if (classID == FE7Data.CharacterClass.THIEF.ID) {
				return new HashSet<Item>(Arrays.asList(LOCKPICK));
			}
			return null;
		}

My hunch says its somewhere in ClassRandomizer when it tries to validate the inventory.

[abbatrombone]

In my case I got Serra as a mage. Their inventory is blank. I checked the terminal output and found this:
[Class Random] Validating inventory for character 0x23 (Serra) in class 0x20 (Mage)
[Class Random] Original Inventory: [0x6b (Vulnerary), 0x4b (Mend), 0x78 (Chest key), 0x69 (Door key)]
[Class Random] Final Inventory: [0x6b (Vulnerary), 0x0, 0x78 (Chest key), 0x69 (Door key)]

I believe the issue is the 0x0. In GBAFEItem 0x00 is none, and if the system reads 0x0 as 0x00, then nothing showing up makes sense. This seems like the most likely reason for the issue to occur. I compared this to a vaild run where pent was the character:
[Class Random] Validating inventory for character 0x23 (Pent) in class 0x28 (Cavalier)
[Class Random] Original Inventory: [0x6b (Vulnerary), 0x78 (Chest key), 0x69 (Door key), 0x0]
[Class Random] Final Inventory: [0x6b (Vulnerary), 0x78 (Chest key), 0x69 (Door key), 0x1 (Iron sword)]

Checking the problem in FEBuilderGBA, I noticed that Geitz does have keys in his inventory, but not in his first slot. Perhaps that's the root of the problem?
In FEBuilder are you able to see this 0x0 byte data in there at all? If so do you see it on that save (if you still have it)?

[lushen124]

That's almost certainly the issue. I don't remember which step actually tries to collapse the items, or if I'm just hallucinating adding that logic in, but it shouldn't be difficult to just re-order any 0x00s to the end of the list.

[abbatrombone]

Glad i found the issue. I believe this is the logic that does that. I found the logic that does that. It might be a moment before i send in the fix. I tried it and found something i do not believe is intended. If the replacement rolled is also a thief they get the replacement keys AND a lockpick which is most likely not suppose to happen.

Additionally, i noticed a lot of logic is reused a lot so i am trying to clean it up and make it easier to read/debug.

[lushen124]

The logic is that any unit that randomizes out of a thief will get a set of chest keys and door keys to avoid softlocking. At the same time, any unit that randomizes into a thief will get a complimentary set of lockpicks. In theory, if a unit randomizes out of thief and then back into a thief, they will have both the keys and the lockpicks. IIRC, this logic happens at the slot level if you randomize recruitment as well as general Class Randomization, so what I'm guessing happened is that Lucius randomized into Matthew or Legault's slot, thereby granting him keys because he was a Monk at the time. Then he randomized into the thief class during class randomization, which grants him the Lockpick.

[abbatrombone]

Yup thats what happened.