Is there an "offspring seal" type item in FEbuilder for FE8 Hacking?

Questions
,
1

So as the title asks. Is there an item or a way to program one that works like the offspring seal? My main reason for asking is I like the concept of branching class options which in turn makes me hate prepromotes since that option was stolen from me. The alternative would be an offspring like item that would let you promote and choose the class but would then make that character whatever level they would have been without this.

I guess the other question here would also be, is there a way to store “internal levels” for your units?

2

To my knowledge, no. Promotion items simply initiate promotion, and that’s all it does.

There are patches that can specify that promotion does not reset your level, but applying this would apply it to ALL promotions, including unpromoted → promoted.

Still, you can work around this by turning off promotion level reset, and just having prepromotes join at Lv15 or Lv20 or something similar if you want to reduce their EXP gain. You’d get rid of, or at least adjust, the promoted EXP modifier so EXP works solely off of level (much like FE4, where Quan and Sigurd are low-level prepromotes).

As for stat changes, that becomes difficult. The main problem is that in FE8, stat changes upon class change are defined by class, unlike in FE6 where the stat change is automatically the difference between classes. More importantly, there is NO PATCH for FE8 to make class change work like FE6, so each class can only be associated with one set of stat changes. It is definitely possible to still implement your idea, but it would be very very difficult.

For a sample tree of 3 classes (1 unpromoted [Cavalier] and 2 promoted [Paladin and Great Knight]), you’d need all of the following:

One entry for the Cavalier class, with whatever stats you see fit.

Two versions of the Paladin class, called A and B. Their class bases, caps, weapon ranks and other flags are identical.

Two versions of the Great Knight class, called A and B. Their class bases, caps, weapon ranks and other flags are identical.

Paladin A has promotion bonuses set to be the intended bonuses from Cavalier into Paladin.

Paladin B has promotion bonuses set to be the difference between Paladin and Great Knight’s class bases.

Great Knight A has promotion bonuses set to be the intended bonuses from Cavalier to Great Knight.

Great Knight B has promotion bonuses set to be the difference between Great Knight and Paladin’s class bases.

Then, you define these promotion branches.

Cavalier → Paladin A
Cavalier → Great Knight A
Paladin A → Great Knight B
Paladin B → Great Knight B
Great Knight A → Paladin B
Great Knight B → Paladin B

This means that assuming the unit in question repeatedly reclasses, they’ll end up in the B versions of their respective classes in the long run, which can class change between each other without problems. The A versions solely exist to be promoted into from an unpromoted class, while all promoted → promoted reclasses funnel the unit in to the B version of the class in question.

Of course, if you have gendered versions of classes, you’d need to duplicate all of the class entries mentioned above, meaning you’d end up with 2 different versions of Cavalier, 4 Paladins and 4 Great Knights, all of which need their own entry in the Class Editor (which will quickly run you out of space). Even if some of those classes are not gendered, if another class in the tree is, then they still need to be gendered, because you don’t want Great Knight (any gender) being able to promote into both Paladin (M) and Paladin (F). If you don’t need gendered versions of classes (Armor Knight, General, Great Knight for instance), then you can get away with only needing 2 versions of each promoted class.

Another issue that comes with reclassing between promoted classes is overruning caps. Say Paladin’s SPD base is 10, and cap is 26. Great Knight’s SPD base is 6, and the cap is 20. What do you think happens if a Paladin with 26 SPD tries to reclass into Great Knight? If class change differences are equal to base differences, then the unit in question only loses 4 SPD, leaving them at 22 SPD, more than the Great Knight cap of 22. And if they try to class change back with the Great Knight SPD cap of 20, they’d end up with 24 SPD as a Paladin.

To avoid this issue, you’d also have to restructure your bases and caps to adopt an FE4/TRS-style system, where Stat Cap = Class Base + X, where X is a consistent number (usually 15) that is the same across that STAT (all SPD caps can be Base + 20, but all STR caps can be Base + 15, for instance). This ensures that whatever difference in class bases you do, the cap also changes by that amount, preventing the unit from overrunning the cap. As for HP, you’d have to either have class change not affect HP (even if the base changes), so as to not overrun a global hard cap (60 or 80), or instead have different HP caps by class (using the above system).

3

Hmm, i see your points. So ultimately i might need to go the FE4 route with promotions not resetting levels and having a higher level cap overall. I dont think the promoted to other branch would work well for this

4

you could have every prepromote get a forced promotion on join and then gain autolevels using events

5

It does get much simpler if you have a class tree where you don’t actually have any unpromoted units in.

For instance, for Archer, Sniper and Ranger, if you don’t actually have any Female Archers join the party at all (only female Snipers and Rangers join as prepromotes), then you don’t need F!Sniper A and F!Ranger A, since nobody is being promoted into F!Sniper or F!Ranger from a base class. At that point, all you do is have F!Sniper and F!Ranger have the class base differences as their promo gains. You’d only be spending 2 class slots, which is the same as vanilla. Of course, if you have a Male Archer join as a base class, you’ll need two versions of M!Sniper and M!Ranger each.

TLDR: You only need to go this far for units who can reclass and who start as unpromoted units. If all units in a given tree start as prepromotes, then you don’t need to use excessive amount of space in the class editor.

6

Ok, i see what your saying. To make this one work, would i event the class change option after recruitment, but keep then where they naturally are up until then?

This might be more doable. Question would be, can i keep them in there normal prepromoted class up until recruitment. Then once recruited, force them into the base class, do the promotion and autolevel?

7

Here’s a more direct example; there’s no eventing needed, ever.

Jack is a pre-promoted Ranger. His reclass option is Sniper.

There are no unpromoted male Archers, so excess space in the class editor is not necessary.

M!Ranger can class change into M!Sniper, changing stats by a difference between the two classes’ class bases.

M!Sniper can class change into M!Ranger, changing stats by a difference between the two classes’ class bases.

Jack joins as a Ranger. If you want to make him into a Sniper, you use a class-changing item on him, and he becomes a Sniper.

If you want to turn Jack back into a Ranger, you use a class-changing item on him again, and he becomes a Ranger.

You can reclass Jack between Ranger and Sniper over and over again as long as you have class-changing items. You don’t need any eventing because he joins in one of the options.

Now if you want the player to be able to pick between whether Jack joins as a Ranger or a Sniper, then it becomes a relatively simple eventing sequence.

Simply use a Yes/No selector to have the player pick between one of two options.

For instance;

Jack: Should I bring a horse?
Yes/No

Picking Yes would cause the event to go on a branch where Jack loads in as a Ranger, along with his Ranger inventory (Silver Bow + Iron Sword, for instance).

Picking No would cause the event to go on the other branch where Jack loads in as a Sniper, along with his Sniper inventory (Silver Bow + Iron Bow, for instance).

Jack is the same unit in the Unit Editor, because his personal bases can just be the same. The only difference is what class he loads in as (and as this is two separate entries in the Unit Placer, this also allows you to assign separate inventories).

Lastly, there’s another issue I haven’t touched on regarding implementing reclassing like this. That is the fact that weapon ranks don’t disappear if you class change into something that can’t normally use that weapon type (Ewan’s loss of Anima rank on his Pupil → Shaman promotion is hardcoded into FE8 and is a one-off thing; additionally, it would reset it to 0, instead of just saving it for later). There is a solution for it, but you need to install a patch to have more weapon locks available.

What you do is simply create one weapon lock for each weapon type, such that all Swords (Iron Sword, Silver Sword, Mercurius…) are assigned a lock specifically for swords, which is granted to all sword-using classes (Mercenary, Paladin, Falcoknight…), and the same is done for all other weapon types. Multi-weapon classes have multiple weapon locks ticked for them. This way, when Jack the Ranger reclasses into Sniper, he still keeps his Sword rank, but the Sniper class only has the Bow lock ticked, meaning it is unable to use Swords even if the unit in question has a Sword rank. If Jack reclasses back into Ranger, then he becomes capable of using Swords because Ranger has the Sword lock ticked.

8

Ok, I get what your saying. I guess I’ll be specific and we can brain storm from there. My initally thought here is to do a boss recruitment version of FE6&7 (similar to what @ArcherBias made) but I’d be using @HauntRS_0337’s remakes of those games that were made in FE8. So the initially conundrum came from being able to change those bosses you recruit later in the game. Your way makes sense where I can keep their class and stats the same, so say Eagler can stay a paladin but I’d give him this class change item and allow him to be a great knight if the player wanted to. Or they can just sell/store the item for others. The bosses seem to generally keep the same classes so with your way I probably wont need to take up too much extra space.

I’d need to think on if I want to extend this to the normal prepromates you get (Marcus for example) or if I should just leave those the same.