lushen124 / Universal-FE-Randomizer

Properly universal this time.
MIT License
98 stars 28 forks source link

FE7 - Five Billion Garbage Classes #417

Open GlitchWarrior opened 1 year ago

GlitchWarrior commented 1 year ago

Maybe this is a non-issue. But half the time, me randomizing FE7 and then going into FEBuilder to apply cosmetic touches results in several "garbage classes" being generated that are treated as game-breaking issues. I can only assume this is caused by extending the class table to include the "replica" lord classes for the main characters, as all of them are immediately after Hector's class.

image One of the "garbage classes" in question.

image The settings I'm using (also, the UI is too big for my screen help-)

UPDATE: I noticed that it generates the classes (and, thus, the garbage data) even if lord randomization is turned off. Oof.

Geeene commented 1 year ago

For the garbage classes, I had a quick look at this.

I found this help entry for FE Builder:

https://feuniverse.us/t/fe-builder-gba-if-you-have-any-questions-attach-report7z/2845/1525

Apparently to decide when to stop it takes a look at the classId, if it's != 0, then it considers it another entry.

I guess we are not leaving enough space in this case after the class table to prevent this from happening.

Not entirely sure what that data is in your case tbh. (probably some text changes)

But anyway, an easy fix for this should be to just write an empty entry (so that the 4th byte here is 0)

2023-05-02 14_41_04-Window at the end of the method:

random.gba.loader.ClassDataLoader#compileDiffs

Result: 2023-05-02 14_47_47-Window

only 11 errors remaining 2023-05-02 14_52_15-Window

GlitchWarrior commented 1 year ago

...to be honest I didn't understand a word of what you said in the second half of the post, maybe you can explain it in a little more detail?

Geeene commented 1 year ago

I mean you don't really need to care, just added it for completeness sake

But basically:

Each entry you see in the Class editor is 84 Bytes. The 5th Byte of which is the Class Id.

(in this screenshot the red marked area is the class data of the newly created Lord class) the 5th value is 66, the class id.

235670873-6910c254-1a52-434a-952a-9d0da2f077cd

FE Builder when going through the Classes will keep reading (in 84 Byte chunks) until it finds one with ClassId = 0.

Since currently there is some non-class related Data after the Class Table, there is no guarantee that the 5th byte of the 84 byte chunk is ever a 0..

So the best way to guarantee that it will stop reading, is to add 0s at the end until it knows, there are no more classes comming (minimum 5 needed i.e. until classId or just add one full 84 byte entry doesn't really matter).

Also, I doubt that the game itself ever goes through the class table like this, so I doubt this really matters, but it's an easy fix so I don't see why this shouldn't be fixed.

GlitchWarrior commented 1 year ago

Still don't know how to write that. But thanks.

I actually thought of an alternate fix. You know how there are unused classes? Like, between Lord and its promotions? Maybe you could slot the main character classes in there.

lushen124 commented 1 year ago

The non-technical explanation is that the randomizer uses empty space at the end of the ROM file in order to relocate and expand some tables. This includes the table for class data. But the randomizer doesn't leave any extra space in this case, and FEBuilder seems to be relying on this empty space to let it know to stop looking for more classes. As @Geeene said, we can just add a dummy/terminator class (all 0s) to let FEBuilder know to stop looking.

Admittedly, this wasn't written with FEBuilder in mind, so we have different tolerances. Some of the remaining engine errors seem to be FEBuilder checking the length of some dialogue lines to see if they're too long to fit the screen, which the randomizer doesn't do (and is primarily an issue when you randomize recruitment and start changing names).

EDIT: As for why we don't slot in to the unused classes, I think we certainly could today, but looking to the future, I can think of two reasons to have a more flexible system:

  1. If we can restore those unused classes to a functional state, that would be something we could add to the randomizer. If that happens, then we still need a different solution for new classes.
  2. Maybe a bit of a stretch goal at this point, but there's also been some work done to have a system to import characters randomly from external sources, and this may include custom classes in the future, so we still should have a more flexible solution if that does come to pass.
GlitchWarrior commented 1 year ago

Ooh, external characters? That sounds awesome.