[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 10/31/2021 at 1:50 AM, Firion231 said:

Found another problem while trying to randomize FE6. I tried randomizing growth rates and set the minimum growth to 25, but no matter which of the three modes I select, there are still growths under 25. Additionally, sometimes when I select "Randomize Absolute" it just uses the character's default growth rates instead of generating new ones. I've spent the past hour or two checking different options and trying to generate a satisfactory randomizer seed and these setbacks are very frustrating.

I can't reproduce this issue. There is a known issue where randomizing CON blows away the growth changes, so if you're using that as well, disable it first (I'll have a fix for this later). But for me, when I set the minimum to 25% every playable character has growth rates in excess of 25% in every stat. Some of them even just have some areas that are flat 25% because of it.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 9/19/2021 at 3:38 PM, Robinjonator said:

Hello, a friend of mine and me are playing FE4 Randomizers right now. My friend got to Gen 2 and for some reason he can't save his game normally anymore. Only Save states seem to work. But whenever he wants to save manually or using the auto save fuction the game crashes and his save gets deleted.  I don't know if it's because of the Randomizer or because of the rom. But since it worked for all of Gen 1 and stopped working out of nowhere in Gen 2 I thought it would be better to report that issue.

That's the first time I've heard of it. Do you have the settings you used? Maybe some of the recent changes I made broke something. I think the most recent thing I did was about Seliph's inheritance being unlocked for more holy blood choices and the option to remove Pursuit and let AS dictate follow up attacks.

On 9/25/2021 at 10:42 AM, GoatLunchbox said:

How long does it typically take for the pallete data to load?

Shouldn't take that long. Which file are you loading? And is it reproducible?

On 10/1/2021 at 1:00 PM, LethalAether said:

when i randomized the growths in FE7, they dont change from their Vanilla growths

There's a bug in the latest version where randomizing MOV/CON accidentally wipes away changes for growth rates. If you have that option checked, you can try unchecking it for the time being. I'll look into a fix for it.

On 10/14/2021 at 8:56 PM, Jerry311 said:

I just wanna point out that this is at least the second complaint in this thread about pre-promotes being really weak, and I have had numerous discussions about this sort of thing in various discord channels. Me and a lot of other people are tired of having Pent and Jaffar replacements that die on turn 1, and just generally having crappy units. My personal recommendation would be to set it to level 20, but at the very least just make it higher than 10. Maybe you could make the way they autolevel an option you can customize? These units are always awful and it sucks.

Yeah, definitely heard a lot on my side as well. I think I'll go ahead and just set it to 20 for toggling between promotion and demotion. Or even just 20 for promotion and leave demotion at 10, before we end up with garbage demoted units. Or, as you said, just make these adjustable, with defaults set to 20 and 10 for promotion and demotion, respectively. For a randomizer, better to err on the side of giving more to the player than making it artificially difficult.

On 10/30/2021 at 4:23 AM, Firion231 said:

I'm having a problem with randomizing FE6. I've tried 11 times now and I can't get Echidna to randomize to an unpromoted class. The class and recruitment settings I'm using are in the screenshot below. Earlier, I couldn't even get her to not take Cecilia's place until I selected the "Use Slot Class" setting. I've also tried with and without the "Assign Classes Evenly" option and it makes no difference. This doesn't affect any other pre-promoted character and I remember being able to randomize Echidna into an unpromoted unit in previous versions. I'm using the latest version (0.9.3). Any help would be appreciated.

So, what's not immediately obvious is that the game tries to keep within the bounds of the original game when it comes to assigning new classes to units. Echidna likely won't ever be an unpromoted class because an unpromoted version of her normal promoted class doesn't exist (the female Mercenary). As such, she should be limited to any other promoted slot since you allowed cross-gender assignments (without it, she would be locked to only female prepromote slots, of which, Cecilia is one of 4 slots I can think of, the others being Juno, Igrene, and Niime.). That said, there are two potential issues here. One is that if you did have "Allow Cross-gender assignments" checked, then Echidna should be jumping around a lot more than just ending up with Cecilia's slot (assuming you are using different seeds).

The other is that maybe Allow Cross-gender assignments should also unlock these characters that can't demote to a valid class normally to demote to their closest analogue. Funnily enough, this only affects Echidna in FE6, as being the only one that doesn't have a directly demoted class to fall on. It's a much bigger issue in FE7, because most prepromoted female units don't have their corresponding unpromoted classes.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

14 hours ago, Jifflez said:

The Yune Randomizer is absolutely amazing and I am thoroughly enjoying it. I do have a question that I can't seem to find an answer or fix to though. I really enjoy Fire Emblem 8 since it throws monster classes into the mix. However, I've noticed that the Growths Randomization doesn't seem to change anything. I've tested it multiple times with different settings and making sure I was using the US version of the game. No matter what I do, the character growths always remain exactly the same. Everything else works perfectly (bases, con, mov, class changes) but the character growth %s remain unchanged. Maybe I missed something somewhere but any advice would be much appreciated. 😄

I believe a bug was introduced in the latest version where randomizing move or con overwrote the growth modifications. I haven't had time to look into it, but if you're mostly dealing with GBAFE, then using an older version can potentially sidestep that. Otherwise, don't use MOV/CON randomization if you want growth randomization for the time being. I'll work on getting it fixed for the next release (which is TBD at the moment).

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 8/21/2021 at 9:26 PM, SophiaOP said:

Gotcha. I can't say I agree with you here about it being fine because 3 points diff. of Str that early in the game really changes things a lot/makes it difficult to get any finishing blows on chars that already struggle to get last hits (mostly a sword user problem). I would prefer a separate category for Slim/slim equivalent.

It's a small difference later in the game, but I'll agree that it can make a larger difference in the early game. I could make it less common in the beginning of the game, but at the same time, it's only in the beginning of the game where you would see these kinds of weapons to begin with and the only time when using them actually makes sense (unless you're specifically setting up kills). At the same time, Iron Swords are purchasable very early in the game for all three GBAFE titles, so it shouldn't be too problematic to get better gear.

On 8/21/2021 at 9:26 PM, SophiaOP said:

Got it. I think it would be nice to exclude reinforcements from item drops. It's kind of gamebreaking to get like 5+ Master Seals in a row from reinforcements 😛

To me, this is part of the fun of the randomizer. Alongside the Slim Sword argument above, sometimes the randomizer makes your life harder, but it can also make your life easier too. For me, neither of these are strictly issues in and of themselves. Additional context could make them larger issues, but a character you like/want to use starting off difficult to use isn't unheard of, and the enemy being particularly generous with drops also isn't unheard of.

On 8/21/2021 at 9:26 PM, SophiaOP said:

It wasn't me that mentioned it, I only just discovered your randomizer in early July/late June.

My understanding is that the even class option doesn't work though unless we enable the option to randomize PC classes, right? I prefer canon classes, but just want enough healers/flyers (even just 1 of each is a godsend) in the early game so that certain tasks don't become impossible. I like your idea, but could you make it available to work with canon classes as well?

Randomize PC classes is required, but I had assumed you were using this option already, unless you're strictly using random recruitment. But if that were the case, you should have a relatively even blend of classes for the entire game, as random recruitment only promotes/demotes units at most. Also, you'll have to define what you mean by canon classes. The issue in github was about the evenly assigned classes option don't feel evenly assigned, and that's mostly due to how it currently works. The example given by the github issue was that it would consider a final roster of 4 berserkers evenly assigned because pirate, corsair, brigand, and berserker are all "different classes" according to the randomizer. The proposal I made was to assign promoted classes and demote as needed, which should do a better job of mixing up the final roster of characters, as a second Berserker could only be assigned once until we've exhausted the other promoted classes.

On 8/21/2021 at 9:26 PM, SophiaOP said:

FE7: Lyn mode isn't a problem. It's cake whether getting healers/flyers early or not. It's early HHM that's a pain. I haven't played since my last post here, but iirc I pretty much used all my vulneraries when I didn't get early healers and it was insanely hard. Guaranteed healer in early HHM would be really nice.

FE6: I haven't tried FE6 with randomizer yet, but HM is already difficult in vanilla (hardest FE between 6,7,8). I have played vanilla HM FE6 trying to get full S ranks (non-Ironman). Adding on the difficulty of a unlucky randomization/vulnerary-only for early chapters + Ironman sounds like a nightmare.

FE8: The most doable of the three games for surviving early chapters with just vulneraries. I already had some unlucky randomizations and was able to survive them until I got a healer. But still would be nice to have 1 guaranteed healer by a certain chapter number.

Hector mode has purchasable vulneraries every 1 - 2 Chapters between 12 and 18. I'm pretty sure all of these early games can be done with just vulneraries, except maybe on hard mode in some cases. But it also wouldn't be too hard to add an option to guarantee a healer by the second chapter in most of these games. In FE6, it means one of Allen, Lance, Bors, Wolt, Marcus, Elen, Dieck, Lot, Wade, or Shanna is a healer. In FE7 (excluding Lyn mode), one of Lowen, Rebecca, Marcus, Dorcas, Bartre, Serra, Matthew, or Oswin is a healer. In FE8, one of Seth, Franz, Gilliam, Moulder, or Vanessa is a healer. FE7 also has the unfortunate distinction of not having an unpromoted male healing class, so with strict gender requirements, we'd be back down to Marcus, Rebecca or Serra.

On 8/21/2021 at 9:26 PM, SophiaOP said:

Understood. I'm actually surprised more people haven't requested this.

Lots of people have requested something along these lines. The space needed for this is just huge to be able to specifically define each individual character and their class pool. I have some ideas now of what this might look like, so I may look into it sooner, rather than later.

On 8/21/2021 at 9:26 PM, SophiaOP said:

I looked up Erk's average Lvl 6 Sage stats, and he should have 36.6 HP, 15.6 Mag, 15.6 Skl, 19 Spd, 10.2 Lck, 9.8 Def, 16.6 Res. This would give him the bulk to get 3HKO'd rather than 2HKO'd and if he lives the first turn, then all the wyvern that accked him on that round should be dead. It looks like he wasn't autoleveled correctly. I just don't know if it's because of a wrong setting or because of a bug.

So I can explain the discrepancy in stats, because the randomizer autolevels promoted units to 10/X instead of 20/X. This is primarily to make newly created prepromotes not completely busted with their higher growth rates. In the case of slots where an NPC needs to live, maybe it's worth doing the full 20/X. Alternatively, we use a middle ground of 15/X. I didn't want to invalidate the earlier characters with prepromotes, but maybe that's fine, and we just use 20/X all around. It would make late game/ironmans much more reliable.

On 8/21/2021 at 9:26 PM, SophiaOP said:

Sorry I wasn't clear. I meant random weapon ranks for each character, not each weapon type gets a random rank. So like if character A starts with sword rank B and lance rank D, then you can randomize how far off the original ranks you want. So if you set a difference of 1 rank, then character A starts with a sword rank C through A, and lance rank D through B. (Probably better to use exact rank points difference to do this though since each rank doesn't weigh the same # of points).

Oh, I misunderstood. I had considered this for a bit, but it runs into a similar issue with changing weapon ranks on weapons, because it generally buffs early game characters (because ranks can't go lower than E) and nerfs late game characters (whose primary benefit is their A rank in weapons). Characters in the middle are fine though.

But if we're using the numeric values, then maybe it's doable, even if it's not entirely clear what's happening. The result is that characters either have a slight head start towards their next rank (which can be nice in early game) or they can be slightly behind what they should have (which isn't a complete dealbreaker). I'd have to modify the existing logic slightly to accomodate partial weapon levels, but I think it could be interesting. I'll definitely look into this option.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

12 hours ago, Hasechi said:

no. you're wrong. The old one able to do that (the one with florina icon). That tool can randomize a ROM that is edited or patched rom. 

Oh, the ability to randomize a ROM that is edited you mean. You can do it with the new one too, but it'll ask you to select the correct game because it can't necessarily determine what you give it. It's also not guaranteed to work correctly, especially if the ROM is heavily modified.

If you select the correct game, and your ROM is only slightly edited, it might work without issues, but if you've moved things or added entries into tables (like what the randomizer does normally or what most romhacks do), chances are the randomizer won't know what to do with them. In the future, I may look into adding a heuristics-based approach to determining the character/class/item data, but for now, much of the logic is specific to the base versions of those games.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

14 hours ago, Hasechi said:

@lushen124 your universal randomizer can patch a rom without needing original GBA roms. Could you please do the same to this Yune Randomizer?

That would mean bundling the ROM, which I can't legally do. The old one didn't let you do this either, and as far as I know, none of the randomizers or tools do this for you.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 7/3/2021 at 9:24 PM, SophiaOP said:

1. One issue I noticed is that when I lose an Ironman run, and try to re-randomize, I keep getting the same randomization (same order of characters recruited, etc.). Is it based on the randomizer seed phrase? If so, then is the set of phrases very limited (it seems so)? If so, can we just set our own randomizer seed phrase to make it extremely unlikely to repeat the same randomization?

1. The seeds that the randomizer cycles through is indeed a fairly small pool of quotes from the game you're randomizing, but the text field itself is editable, so you can type in whatever you want. The same seed will result in the same randomization, so if you want something completely random, you should type something random into the seed field.

Quote

2. Another issue I noticed is that even though I set max Delta to 5 for growths randomization, I don't remember ever seeing a growth that wasn't a multiple of 5 in the changelogs (even though max Delta of 5 should mean +-0, +-1, +-2, +-3, +-4 off the original growth stat should be possible). Besides this issue, I'd like to suggest to add an option for an offset: Let's say original growth for some stat was 50%. Then we apply max Delta of 5 so that means the new growth will be between 45-55%. Then the new setting would shift the growth so if the growth were, say, +2, then the new growth would be 45+2 through 55+2, so 47 through 57. Same wish for bases randomization.

2. I think it used to allow for weird growth values, but there was some feedback a while back that the growths should be multiples of 5. Maybe if the delta is small enough, it'll fall back to use all numbers instead of just multiples of 5. Redistribution method distributes in chunks of 5 anyway, so that stays as it is.

Quote

3. "Strict Matching" weapon assignment might not be working as intended. For example, I remember sword users in early chapters of HHM randomizing sometimes with Slim Swords, sometimes with Iron Swords. And that's a very big difference in Might/useability of the character.

3. This is actually intentional. The way strict matching works is that it groups weapons together by categories. Slim Swords fall into the same category as Iron Swords (as well as the Blades, but those start at D rank). This is so that if we need to change weapon type, they'll swap to another weapon in the same category. So both Slim and Iron Swords will become Iron/Slim Lances or Iron Axes once the weapon of the same rank is selected. If multiple choices are available after category and rank (as in this case), a random one is selected. Since Slim has no equivalent in Axes or the magic types, they get converted to the "Iron" equivalent. We could make a separate category for Slim if desired, but it would just be Slim Sword, Slim Lance, and maybe Short Bow, which are already somewhat rare to begin with. I'll leave it up to everybody else if we should make that distinction. My personal opinion is that they're fine being in the same group.

Quote

4. Random Enemy Drops have one issue which is that when they drop from sets of enemies that spawn from forts, they drop the same items.

4. This is how the game works normally, because the units that spawn in from reinforcements are coded identically to spawn on a turn counter. They could just be excluded from item drops, but if a reinforcement drops something, future reinforcements from the same group will continue to drop it.

Quote

Getting too many of a certain class/weapon type. I had a few runs in FE7 with too many axe users (brigand, pirate, or fighters) or too many myrmidons. Those were a bit too tough for my taste. Suggestion/wish is to be able to limit how many of a certain class/weapon type specialist you receive in the early chapters of the game.

1) Re: Class balance: This was brought up in the github (and maybe it was you that mentioned it), but I'm thinking the even class option should distribute based on promoted class and demote from there as necessary. This would make it much more likely for you to get an even blend throughout the game as it collapses the classes that promote to the same thing into a single entity.

Quote

Related to sub-point 1, is not getting healers/fliers early in the game (this really hurts in an Ironman run, especially the healer part!). Not getting a flier on Lyn mode Chapter 3, for example, means it's often impossible to visit the village in the top left. It would be nice to be able to set a minimum # of healers/fliers you receive before an arbitrary point/chapter in the game. And/or to be able to keep healer/flier slots like in vanilla (just like for thieves/special chars) so that only other healers can replace a healer, and other fliers can replace a flier (e.g. Serra, Priscilla, Pent, Renault are interchangeable as healers; Florina, Fiora, Farina, Heath, Vaida are interchangeable; no other characters can replace them at the points where you recruit them in the vanilla game).

2) Re: Healer Distribution: I'd say this is normally when you'd have to rely more heavily on Vulneraries to heal, or find ways of mitigating damage. That said, FE7 Lyn mode doesn't really give you any way of doing that until Ch. 7 when you can buy Vulneraries, which might be pushing it. FE6 gives you shops in Ch. 2 and FE8 in Ch. 4, so I think both of those should give you enough opportunity to pick up healing items. Maybe specifically for FE7, we can add an option (or have default logic) to make sure you get a healer by the time Serra joins.

Quote

Suggestion to add partial recruitment randomization. i.e. To be able to set when certain characters are recruited. For example, let's say it's FE6 and one of my favorite characters is Sophia, and I want her to be available throughout the whole game, I could set her to be recruited/available in Chapter 1, and the rest of the characters' recruitment could be randomized.

3) Re: Set Recruitment: This is close to the idea of having more robust controls for class randomization, or at least it runs into the same problem as that, which is that it would take a lot of space to implement this properly. Not to say that it can't be done, but it would probably require a breakout window, or just a redesign of the app to support this kind of UI. Not saying I don't think this would be a neat addition, but just that this would be fairly low on the priority list unless specifically requested by the community.

Quote

Not sure how to solve this problem yet...but my furthest Ironman in FE7 ended in Chapter 23 HHM because Erk replaced Pent, and Erk always dies in Turn 1 of the map. Even if it were not Ironman, I still automatically lose. I had a similar issue in FE8 where the dog monsters would spawn with Hellfang and be able to 1RKO a lot of characters early. Chapter 11 (saving L'Arachel map) is especially a problem with recruitment randomization because a lot of characters (including the two chars that need to be saved) can get 1RKO. I had to face Hellfang dog monsters, centaurs, Sharp Claw spiders, and even an Arch Mogall in that chapter and it was just too tough. For FE8, I think those types of enemies should only appear later in the game.

4) Re: Impossible Missions: It's surprising this is happening if enemies aren't buffed. Erk replacing Pent should be among the most doable situations if he's autoleveled correctly. The L'arachel situation is a bit more understandable, since I can guess what happened in that case. Entombed are considered promoted units, and if they randomize, they randomize into other promoted monsters. But since Entombed are generally garbage, there's a power spike when they become other monsters like Gwyllgis, who default to having Hellfang by the randomizer. I'm thinking Entombed need to be handled differently than other monsters, or at least they should spawn with the worst weapon a monster can use.

Quote

Maybe add randomization options for weapon ranks?

5) Re: Random weapon ranks: If there's a compelling reason why this should be added, it wouldn't be hard to do, but I can't think of one. Seems to me like it mostly upends game progression. Iron weapons can only get worse (by being weaker and less accessible) and Silver weapons can only get better (by being stronger and more accessible).

Quote

6. For randomized enemies, I had one issue which is the Sniper on FE8 Chapter 9 got replaced with a Recruit. I did not expect the Recruit to be so strong and moved Dozla towards it thinking it was "just another Recruit". But he got 1RKO'd (please see attached screenshots). Not sure if this is an issue for normal runs. But for Ironman, it was a little frustrating to suddenly have a unit get one-shotted. At the time it happened, I wondered if something was wrong with the randomizer. Then I looked up the unit list for that map and figured it had replaced the Sniper.

6. The sniper was replaced with a Super Recruit. Unfortunately the game doesn't have a way to make that clear, but on susbequent playthroughs, the Super-Trainee classes become available for Ross, Amelia, and Ewan. The randomizer treats these as Tier 2/promoted classes with promoted bases and caps beyond 20. There have been some requests to just remove these characters from the pool, but I haven't done that yet. Maybe it's worth putting these into an option to exclude from the class pool so that they don't show up. They're not particularly good classes, AFAIK.

Quote

. In FE8, Trainee classes don't seem to be able to promote with Trainee Seal or even any of the normal promotion items. Only Master Seal seems to work

7. Yeah, these seem to have broken in the latest update. I'll have to investigate.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 6/18/2021 at 12:49 AM, DerLumpensammler said:

Edit: Ok nevermind, I just noticed if you don't promote instantly and use the Lunar and Solar thingy afterwards you can choose the normal promotion path for the class again.

 

The new update is really cool, thanks for that. Only thing I was wondering is if I always have to wait for the promotion of my randomized lord with the new update? For example do I always have to wait now until after the Renais chapter until I can promote my Eirika and Ephraim replacements and do I always have to promote them into the vanilla lord classes?

 

I always enjoyed not having to wait until then and being able to promote your lord early like your other characters. And especially not the boring lord classes.

 

 

Yeah, one of the changes the last release made was to enforce each game's fixed promotion event for the main lords. Part of this was more that I wanted to keep that progression intact, but most of it was because the fixed promotion event would demote an already promoted lord. You could probably just promote them again with the appropriate item, but I think this is a cleaner solution. If people feel strongly enough, I can make the entire change an option instead of just being the default, but the same code is also how the new Prf weapons work (or at least how they work alongside the old Prf weapons being locked to classes).

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 6/7/2021 at 3:26 AM, Vicious Sal said:

That's a pretty neat update! looking forward to more FE9 stuff. =]

Regarding FE10, though I always enjoy more people looking into the inner workings of FE10, there already exists an incredibly extensive Randomiser for FE10. 

Right. This isn't to take away from what already exists. Practically speaking, we don't need another FE10 randomizer. But part of why I want to work on one is for academic reasons, but most of it is because FE10 is my favorite, and I wanted to dig deep into it. The ideas I had were more around being able to randomize both FE9 and 10 simultaneously to the point that you can legitimately use transfer data between the two. Another smaller reason relates to one of my goals for this project, which was to make randomizing FE games more accessible to more people without needing significant know-how to operate. This is why, for example, FE9 doesn't require any additional tools for extraction or rebuilding (beyond you ostensibly extracting it from a Gamecube disc, which is platform agnostic), as I went through great lengths to make sure the randomizer can operate on the raw ISO file (since said tools are almost always locked to Windows users only).

18 hours ago, Kalieum said:

Not sure how useful this is, but I had some issues where the randomiser would close when I loaded a rom, which consistently happened over a good number of tries when trying to troubleshoot it. But, when I was going through methodically to be able to give a more useful report, it suddenly started working.

Specific order of actions undertook was
Try (untranslated, headered) FE4 rom on 0.93 x64 exe, program closes. (All failures were identical - after verifying the window would expand to its full size but before populating itself with widgets it would suddenly close).
Removed the header and changed extension from .smc to .sfc just in case, program closes.
Tried different JP FE4 rom, program closes.
Tried FE7 rom, program closes.
Tried JP FE8 rom, Yune complained about being unable to verify, told it it's FE8, program closes.
Downloaded & tried executable jar file, didn't even start. Not sure why. Navigating to the directory in a command prompt window and trying to run it that way didn't give any errors, but no window appeared and I didn't see java processes appearing in task manager.
Tried x86 executable, wouldn't open either.
Checked my jre version, slightly out of date. Updated, tried x64 exe and .jar again, same results.
Restarted computer, tried those two again, same results.
Tried last version of Yune I had (0.8.5 x64 executable), work without issue.
Downloaded source code zip from releases, tried x64 executable in \Executables\Windows, program closes.
Tried 0.9.2 x64 executable in \Executables\Windows\0.9.2, works just fine.
Tried 0.9.3 again, no-go.
Tried 0.9.2 again just in case it was a fluke or something(?), still works.
Wanted to confirm whether it was all games it didn't work with or not so opened some random non-FE game file in 0.9.3 to tell Yune that it was each game in turn to load each set of options in turn, they all suddenly work.
Load actual FE4 rom in 0.9.3, it's working.
Wonder if 0.9.2 still running in the background is somehow effecting this, close 0.9.2, try 0.9.3 again, it still works.

And that's where I am. It went from not working 100% of the time in an consistent manner to just working, but I figure it's still worth a bug report.

I ran into a similar issue and it might have a similar cause. The issue is when it tries to load your last used settings. Since I added new settings to the bundle, I upped the versioning of the saved settings. If the version doesn't match, it's supposed to wipe the settings and start fresh, but I think it doesn't do that in some cases (or I messed up the settings version in one of the versions). If you run into it again, let me know, but I'll look into trying to prevent this scenario. The main issue is that the preferences have some booleans that shouldn't be null, but are, which causes a crash when it tries to load the UI with the saved settings.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

Update 0.9.3 is now available. The headliner for this is that FE9 is greatly improved to the point that it works with Nintendont/real hardware now. Shadow Ikes should be eliminated at this point and any scripting oddities and cutscene crashes should be resolved. For GBAFE, quite a few new additions were added including the ability to have finer grain control over random weapon effects, enemy buffing, and class assignments. There's also an option to revert to 1 RN mode if you didn't like being lied to with 2 RN. One feature that was suggested was an option to randomly add Fog of War to maps, so a beta version of that has been included for testing. It can look a bit weird in some cases, but it seems functional from my testing. For FE4 fans, a few improvements have been made including one to change Pursuit to only make it easier to double instead of being a hard requirement for follow up attacks (AS thresholds adjustable). Sigurd/Deirdre/Seliph also have more options for holy blood now due to the third holy blood byte now being available for use.

Release: https://github.com/lushen124/Universal-FE-Randomizer/releases/tag/0.9.3

As for what's next, I think it's time we tackle FE10 and aim for a full 1.0.0 release. Since FE9 should be fairly solid at this point, I want to dive into FE10 and seeing if we can make that happen. I have a few ideas that could involve randomizing FE9 and 10 in tandem, and FE10 is so much more fleshed out mechanically that there's a lot more to play with, IMO.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 5/17/2021 at 6:48 PM, AnonymousSpeed said:

I understand wanting to leave the game as close to its base form as possible aside from the randomizations, but I think removing the event is more in line with the spirit of the randomizer than forbidding Rath's slot from being a cleric. That makes his slot a little less random to accommodate this one fairly minor detail that no one would really miss, especially if they skip Lyn mode.

Reasonable points. The reason I try to avoid touching scripts too much because they're a bit more fragile and error prone while being hard to comprehensively test. I only adjust them if I really have to for the game to function properly. In the case of Rath, he isn't quite limited enough for me to justify making script changes (he can literally be any class except for Cleric, Troubadour, and Dancer/Bard). For an example that I would prioritize, you can look to Fiora and other fliers, who really only have to be fliers because of a scripted move. But even then, at least for now, the simpler solution is to just restrict some characters and not open the can of worms of modifying scripts until I'm ready for it. That rabbit hole goes deep.

Also to note: my priorities with the randomizer aren't actually about being faithful to the original games. It's actually more about stability, both game stability and randomizer stability. To start entertaining script changes is to increase both test cases and possible points of failure. At a high enough confidence level, this isn't an issue, but we're not quite there yet.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

On 5/5/2021 at 6:59 PM, AnonymousSpeed said:

S'all good. What you've put out is already more-or-less a finished product.

It could be tucked away in an advanced settings window. You'd have to press a button to open it or something, I don't know. I agree that it would complicate the UI too much to but it all in one window.

If you eventually get to implementing such a feature, you might as well let the user define their own class pools and assign characters to them individually. For instance, define Class Pool A as containing Nomad and Myrmidon. If Rath is assigned to Class Pool A, he'll be one of those two classes. If you want Rath to be a female myrmidon, simply set Class Pool A to only contain female myrmidon. This could also be a way to incorporate King and other silly classes without messing things up too horribly- you just leave them out of the default class pool.

Would it be possible to remove the event entirely? I understand that it might be beyond your vision, but it could also simplify things.

Customizing class pools is definitely a bit much. The use case I was responding to was more about directly setting what you want for some parameters (like an archer-only run or 0% growths) and randomizing the others. It'd be essentially integrating a simpler version of FEBuilder into the pre-randomization phase. There have already been a few suggestions from some people that we could support a serializable XML or JSON style format to specify changes. Hell, the Yune name would naturally lead into Ashunera: Ashera for the editor and Yune for the randomizer. The data models are already mostly in place for an editor for every game Yune supports. 😉

As for the class pools, it actually wouldn't be too difficult to implement the logic to support custom class distributions, but as we agreed on, the space needed to layout that UI would necessitate a secondary window, with it essentially controlling who can be randomized and what they can be randomized into. Supporting class pools on an individual or even group level would be another step up. I think at some point, I would probably be looking into a redesign of the UI to actually support large UIs like that. It's already getting a little bloated with the introduction of skills and weapon effects with the more recent releases.

As for the event, it is my goal to hopefully not have to entirely remove events, so I still want to know how it was possible to get a cleric in Rath's slot. My guess is that Bishop Karel was considered "ranged" and was assigned to Rath's slot, but then realized he had to demote, which no longer made him "ranged".

6 hours ago, BrewenMoon said:

So i've used this before for fe4 and I love it, but now when I am trying to do another run it gives me all the same classes and growths from like a pool of pre set stuff? Sigurd keeps being the same classes with the same blood and growths to a t as previous randomizations. Was just wondering if they pulled all the changes from a pool or if there's some way to fix this and make it more random. Thanks! 

There isn't any fixed pool, but if you're using the same settings with the same seed phrase, you're going to get the same result. This is by design (and makes it easier to debug if things go wrong). That said, I don't guarantee that every phrase will yield a different result, as I'm really just taking a hash of the string you give me. It's possible for two different strings to yield the same result, but you'd have to be incredibly lucky/unlucky for that result. Try a few other seed phrases and see what you get. If you still get the same result, then after making sure you aren't loading the old ROM, let me know, and I can look into it. 🙂

[Lamia's FE4 stuff]

I figure I'd drop this here in case anybody needs it, since I was looking through FE4 ASM earlier for the Yune randomizer. Maybe it's already out there and I just didn't look hard enough.

Removing the Pursuit requirement for follow-up attacks

All ROM addresses are headered and based off of the original (though I've tested it with the Naga patch).

0x4E567

Old Values:

90 12 BD 24 00 89 00 40 F0 0A B9 30 00 DD 30 00 10 02 38 60 18 60

New Values (the 00s don't matter, I just stubbed them out so that it's clear they do nothing)

20 10 FF 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x50110

Old Values: All 00s.

New Values:

90 2C B9 30 00 DD 30 00 10 24 BD 24 00 89 00 40 F0 0E BD 30 00 38 F9 30 00 C9 03 00 90 10 80 0C BD 30 00 38 F9 30 00 C9 06 00 90 02 38 60 18 60

In that set of new values, there are two values that can be tweaked. The two 0xC9 bytes are each followed by a value for the AS threshold needed to double with and without Pursuit. In the above example, this is 6 AS to double without Pursuit and 3 AS to double with Pursuit.

Technical Explanation

The first change replaces the routine that checks for Pursuit to determine doubling. Originally, this ASM looked like this:

$84/E367 90 12       BCC $12    [$E37B]      A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Some kind of check that bypasses this entire sequence if the result of the previous function (see above) has the carry flag cleared.
$84/E369 BD 24 00    LDA $0024,x[$7E:4ED9]   A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Loads Attacker Skills into Accumulator.
$84/E36C 89 00 40    BIT #$4000              A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Check if the Pursuit bit is set. If it is, clears the zero flag.
$84/E36F F0 0A       BEQ $0A    [$E37B]      A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Branches if zero flag was set.
$84/E371 B9 30 00    LDA $0030,y[$7E:4F45]   A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Loads the defender's AS into the Accumulator
$84/E374 DD 30 00    CMP $0030,x[$7E:4EE5]   A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Compares it with the attacker's AS. Sets the negative flag if necessary (i.e. Defender AS - Attacker AS)
$84/E377 10 02       BPL $02    [$E37B]      A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Branches to skip the double attack if the negative flag was not set. (i.e. Defender AS > Attacker AS)
$84/E379 38          SEC                     A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Sets the Carry to indicate a follow up attack is needed.
$84/E37A 60          RTS                     A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Return
$84/E37B 18          CLC                     A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- The Branch Destination if there is no double attack. Clears the Carry flag to indicate no double attack.
$84/E37C 60          RTS                     A:0000 X:4EB5 Y:4F15 P:envmxdizc <-- Return

Since the check is bit more complex, I opted to jump to my own subroutine and do calculations there for more space. Thankfully Jump and Return instructions don't mess with any flags, which is what we need to preserve for returning to the original caller.

The ASM for the jump is just:

$84/E367 20 10 FF    JSR $FF10  [$84:FF10]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Jump to our new subroutine.
$84/E36A 60          RTS                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Return the result from our new subroutine.
$84/E36B 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Stubbed out to 00s.
$84/E36D 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E36F 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E371 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E373 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E375 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E377 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E379 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/E37B 00 00       BRK #$00                A:0000 X:4EB5 Y:4F15 P:envmxdiZC

The new code we wrote is in the same data bank, but uses empty space at the end of the bank. The ASM looks like this:

$84/FF10 90 2C       BCC $2C    [$FF3E]      A:0000 X:4EB5 Y:4F15 P:envmxdiZC
$84/FF12 B9 30 00    LDA $0030,y[$7E:4F45]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Loads the defender's AS.
$84/FF15 DD 30 00    CMP $0030,x[$7E:4EE5]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Compares the defender AS with the attacker AS.
$84/FF18 10 24       BPL $24    [$FF3E]      A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If the defender is faster, skip the rest and return no follow-up.

$84/FF1A BD 24 00    LDA $0024,x[$7E:4ED9]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Load the attacker's skills.
$84/FF1D 89 00 40    BIT #$4000              A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Does the attacker have Pursuit?
$84/FF20 F0 0E       BEQ $0E    [$FF30]      A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If he doesn't, skip to the logic for checking doubling threshold without Pursuit.

$84/FF22 BD 30 00    LDA $0030,x[$7E:4EE5]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If we get here, the attacker has Pursuit. Load the attacker AS.
$84/FF25 38          SEC                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- 65816 CPU quirk for subtraction.
$84/FF26 F9 30 00    SBC $0030,y[$7E:4F45]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Subtract the defender's AS from the attacker's.
$84/FF29 C9 03 00    CMP #$0003              A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Compare it to the Pursuit threshold (3 in this case). Sets the carry flag if AS difference > threshold.
$84/FF2C 90 10       BCC $10    [$FF3E]      A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If carry flag is not set, skip to the end. No follow-up needed.
$84/FF2E 80 0C       BRA $0C    [$FF3C]      A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Otherwise, we have a follow-up. Always jump to the follow-up routine.

$84/FF30 BD 30 00    LDA $0030,x[$7E:4EE5]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If we get here, the attacker does not have Pursuit. Same as above, load the attacker AS.
$84/FF33 38          SEC                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- 65816 CPU quirk for subtraction.
$84/FF34 F9 30 00    SBC $0030,y[$7E:4F45]   A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Subtract the defender's AS from the attacker's.
$84/FF37 C9 06 00    CMP #$0006              A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Compare it to the non-Pursuit threshold (6 in this case). Sets the carry flag if AS difference > threshold.
$84/FF3A 90 02       BCC $02    [$FF3E]      A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If carry flag is not set, skip to the end. No follow-up needed.

$84/FF3C 38          SEC                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If we get here, we have a follow-up attack. Set the carry flag to indicate this.
$84/FF3D 60          RTS                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Return.
$84/FF3E 18          CLC                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- If we get here, we don't have a follow-up attack. Clear the carry flag to indicate this.
$84/FF3F 60          RTS                     A:0000 X:4EB5 Y:4F15 P:envmxdiZC <-- Return.

Note: I use "Attacker" and "Defender", but that really just refers to the values in the X and Y registers. The routine is called twice if necessary, swapping X and Y in the second case. I suspect this only happens if the initial call does not result in a follow-up attack, since only one side can have a follow-up.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

Sorry for the late replies. I've been taking a bit of a break on this project for the last few months. Hoping to get back into the swing of things.

On 12/1/2020 at 1:28 PM, Benice said:

So, made great progress with another run of FE8 with prf weapons! However, got a few glitches to report; First off, both lords randomized into Armor knights-However, weapons that normally deal effective damage against armor knights don't work on either of them. Effective damage seems to be working as normal everywhere else, though.

Ah, I probably forgot to add their new classes to the effectiveness list. At least, I don't remember adding that logic. That should be a relatively quick fix (assuming I don't break other things in the process). Thanks for the report!

On 12/1/2020 at 12:54 PM, Callie said:

Would u do Mag/Str split for fe 6,7,8 ? and add skills to those games ?

This isn't planned for the time being. Maybe after a 1.0 release, I might look into supporting hacks and other mods to the base games, but my focus right now is to increase coverage for the base versions of each game.

On 12/6/2020 at 3:42 AM, ProfessorRPG said:

To start off, I absolutely LOVE this randomizer you have put together. I am curious though, how possible would it be for in a future update adding a feature where you could manually select what a unit's class is swapped too? I've wanted to try an archer-only or mage-only playthrough before where all my units are a given class. Is this a possible feature, or is there a way to generate a seed that does that? 

Thanks!

It wouldn't be too hard to do, but it is somewhat outside of the scope of a randomizer. I may look into creating a different tool to do these kinds of modifications, since this line of thought opens the door to several other features that would probably complicate the UI more than it already is.

On 12/12/2020 at 1:39 PM, Cornchip said:

Hi, sorry if this has been addressed already or has a workaround. I did my best to search, but I couldn't find any answers.

Currently playing a randomized FE7, and got to the chapter in Lyn's story where you recruit Rath. He has a scripted fight, but instead of Rath, I got a Cleric Karel that can't fight, so the game gets stuck. I tried holding L to skip animation, but that isn't working.

That is odd. Rath's slot is marked as requiring range attack, so under no circumstances should the character filling it be unable to attack at range. Do you have the changelog? I can look into it more if I can reproduce it.

On 2/26/2021 at 7:49 AM, radev1924 said:

would it be possible to add the feature in the future for units to be able to randomize into enemy-only classes like Zephiel's king class, Idunn's dragon class, Julius's dark prince and so on?

It's possible, but I explicitly disabled these classes mostly because they 1) upset game balance due to how their stats are coded, and 2) take away from the uniqueness of the final boss/characters (also 3) they're probably glitched in more ways than one if you try to use them outside of their intended purpose).

On 3/23/2021 at 7:39 PM, Fatal_Cerberus said:

I'm having trouble getting the randomizer to work for FE9, every time I try to randomize FE9 it gets stuck on loading text data. Not sure if I'm doing anything wrong but any help would be appreciated.

This usually means you're out of memory. FE9 requires a bit more memory than the default allocated memory for Java since it's processing the entire ISO. You can override the memory limit with java flags at runtime, or install a 64-bit JRE. The latter is easier if you don't already have a 64-bit JRE.

[FE6 Localization Patch v1.2.1 - Full localization with new features, including Support Conversation reader]

Thanks! I also noticed we've reintroduced huffman encoding for FE6, which I guess is how we managed to cut down the final size so drastically.

EDIT: If you saw the bug earlier, ignore the bug, I think that's an issue with my text parser not recognizing apostrophes.

EDIT 2: Ok, another question. Text seems to be working now, but for whatever reason, changing Roy's class seems to break his battle animation (and only his). I'm not sure if anything has changed that might be related to that. The weird thing is that anybody else that is the same class as he is works fine, so it's not like the class's animations are broken. But the game seems to freak out when his battle animations are called to play. From my limited testing, his animations work while he's a lord or a mercenary (for some reason). Otherwise, his battle animations seem to break if he's a mage, cavalier, or myrmidon (haven't tested other classes yet). It's entirely possible that the randomizer is at fault still because of some assumptions I've made, but if you have a technical list of changes, that would help a lot.

EDIT 3: After further testing, it seems to be related to the palettes. I was originally relying on empty space that was internal to the base ROM to put new palettes, but I'm not sure what the new free space areas are, or even if there are any in the new patched version. (Admittedly, I'm not sure of the actual requirements for where these can live, beyond the fact that they seem to be byte aligned).

EDIT 4: I must say, thanks for releasing this new patch. It's gotten me to go back and look at my code again, and find a lot of issues that didn't surface earlier. Apparently, I wasn't always byte aligning new data beyond the end of the file, so the palettes were breaking because of that.

[FE6 Localization Patch v1.2.1 - Full localization with new features, including Support Conversation reader]

Hey Gringe, I'm looking to integrate this into the randomizer, and I've run into a bit of a snag regarding the text. I'm not sure if my text parser is just incomplete, but Wendy/Gwendolyn's name seems to not be interpreted correctly, which is weird, because every other string is interpreted correctly (and Gwendolyn's name in dialogue is also interpreted correctly). Were there some new characters that were added to the text encoding table? My guess is that maybe Gwendolyn's name is too long to fit in most text boxes, for names, so a slightly different character was used for G, e, n, d, o, and y (w and l seem to be interpreted correctly).

[Yune Randomizer: A Universal Fire Emblem Randomizer]

22 hours ago, TrumpetZorua said:

The 64-bit versions aren't working for me. I've tried other 64-bit applications and those work so don't understand why it won't open.

What version of Java are you running? If you open up the command prompt and type

java -version

it should print out the version and any options you might have. On mine, I get:

Microsoft Windows [Version 10.0.19041.508]
(c) 2020 Microsoft Corporation. All rights reserved.

C:\Users\Lu>java -version
Picked up _JAVA_OPTIONS: -Xmx4g
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)

C:\Users\Lu>

 

[Yune Randomizer: A Universal Fire Emblem Randomizer]

Oh, I see a potential issue. I can fix it, but, just curious, are you using both randomized recruitment and classes or just one of them? There's a bug if you only use one of those options at the moment.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

That's a new one. The sprites seem to be half-loading? I'll try replicating your settings. Thanks for the report!

EDIT: So I just used your settings, but I was unable to get the same result that you did (I got Cav Duessel as Eirika and Assassin Forde as Seth). Are you sure those are the same settings?

Assuming they are:

1. Was Armor Knight Marisa the lord unit? This would point to an issue with the new class I created.

2. I'm not sure why she's using Gilliam's default palette. If the palettes were swapped correctly, she should have a different color. If they were swapped incorrectly, she should have the generic armor knight palette.

3. Even though I couldn't reproduce your exact situation, my armor knight animations seem to load fine. Does this happen with different seeds/settings as well?

[Yune Randomizer: A Universal Fire Emblem Randomizer]

Sorry, try it again. I updated the link: https://www.dropbox.com/s/mg2o8lyzbrvmn1m/Yune.jar?dl=0

[Yune Randomizer: A Universal Fire Emblem Randomizer]

2 hours ago, Benice said:

Aren't hard mode bonuses absent in FE8? I could be mistaken, but I seem to recall all enemy playables have the same stats on Hard as Normal mode.

Windows 64 bit.

Oh, right. I believe the bonuses are limited to those above a specific character ID, specifically to not apply it to playable characters. We could make it an option. By my count, this affects Joshua, Amelia, Rennac, and Marisa. I can look into it.

In the meantime, here's a beta build to test the Prf weapons. Things to look for:

* Prf weapons should have the same stats as the original Prf weapon. For Eirika, Eliwood, and Roy, this should match the Rapier. For Lyn, it should match the Mani Katti. For Hector, it should match the Wolf Beil, and for Ephraim, it should match Reginleif. This includes the effectiveness, which should be Armored Knights and Horseback units (and if it's a bow, flying units as well).

* The Prf weapon should only be usable by the lord character. No other characters, even those that match the class, should be able to use the weapon.

* The Lord character should no longer be able to promote without the story appropriate item, regardless of their class. For Roy, this means the story event at Chapter 30. For FE7, Lyn requires a Heaven Seal, and the lord that's not the main character also requires a Heaven's Seal. The one that is requires the story event. FE8 requires the story event or the Lunar/Solar Brace.

* I haven't applied the same thing to the legendary weapons yet. That's coming later.

Dropbox: https://www.dropbox.com/s/mg2o8lyzbrvmn1m/Yune.jar?dl=0

[Yune Randomizer: A Universal Fire Emblem Randomizer]

15 hours ago, Benice said:

I'd be happy to help, although I don't have a ton of time to playtest everything. FE8 would be easy and fast enough to give it a spin or two, though!

Also, could making HM bonuses a thing be an option for the Randomizer?

I'm not sure what you mean by HM bonuses being a thing, because I didn't specifically make them not a thing, so any HM bonuses should still be applying if they were in the original game.

Also, let me know which platform you're on (Windows (32 or 64 bit), macOS, or Linux) so I can build the appropriate binary.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

@zigludo_ssb Since you suggested the idea, would you be willing to beta test the Custom Prf weapons feature? I'm not quite ready to do a full release yet, but I'd like to see if somebody can help me verify that nothing is broken beyond the first couple chapters. The feature should be available under both random classes or random recruitment for FE6, 7, and 8. Let me know what platform you're on and I can make a special build. Anybody else is also free to volunteer.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

19 hours ago, AnonymousSpeed said:

Wouldn't removing their class base total from their "total bases" total before comparing them account for that?

 

Maybe +2 magic, +1 skill, and +1 speed could be the bonus? As is, mages have lower base strength than soldiers and lower base speed than fighters. This would kinda those two, at least.

 

Thanks, looking forward to it!

I'm not entirely sure what you mean by the first point. Promoted -> Unpromoted would be garbage because their growth rates are generally worse than Unpromoted units normally are. So if I decreased their bases until the point where they matched unpromoted units' bases, they would never be able to catch back up because of their lower growths. Normally what saves them with autoleveling is that their level downs don't change much because their growths worse. So under the current system, prepromotes becoming unpromoted units should have better than expected bases with the trade off being that they wouldn't be growing all that much. Unpromoted units that become prepromotes are a bit worse because they were assuming a promotion level of 10 (and then -3 for a reason I don't remember). Hopefully changing it to 12 or 13 and then removing the -3 should rectify it.

As for mages, my understanding is that they're pretty trash because their class bases are pretty trash (due to them targeting RES instead of DEF, where RES is usually worse than DEF). For example, a mercenary gets 4 base STR, while a mage starts with a 1 base MAG. What we could do is just bring that MAG class base more in line with physical class STR base. This would affect both playable characters and enemies, which I think is a fair trade. Alternatively, we only buff playable characters, but that feels like an unnecessary buff for playable units. I don't know, I could go both ways on it, because on one hand, I get that it is a change that is more than randomization, but I also get that magic users get the short end of the stick in this regard.

[Yune Randomizer: A Universal Fire Emblem Randomizer]

16 hours ago, Graveless said:

I decided to give FE7 a whirl too and it's mostly been working well, but I found a strange behavior. 

When trying to promote units who randomized into lords, the Heaven Seal is selectively available.

Lyn randomized into herself and turned into an Eliwood lord; The Heaven Seal works for her. However, I have Oswin -> Nils as a Hector lord who cannot use it to promote. Technically I have a Lyn lord and other Hector lord as well, but they aren't high enough level to try.

I'm playing Hector Hard Mode for this one and wasn't sure if this was caused by something about Nils, it being the Hector class in Hector mode, or some other issue.

The heaven seal changes its usage depending on the mode. On Eliwood mode, it promotes Hector Lord and Lyn Lord, while on Hector mode, it promotes Eliwood Lord and Lyn Lord. This is true in the vanilla game as well.

One of the things I'm looking into right now is actually to make this a bit more like the vanilla game and allow non-Lord characters that become Lord classes to promote normally, but also making sure that Lord characters (regardless of the class) cannot promote by any other means than their normal promotion. In terms of FE7, this means that, on Eliwood mode, for example, Hector and Lyn, regardless of their class, can only promote with the Heaven Seal, and Eliwood's promotion is scripted. So even if Hector were to become a Cavalier, Knights Crest would NOT work on Hector. However if, say, Sain became a Hector Lord, he WOULD be able to promote with the Knights Crest.