lushen124

Depends on how you define "too low" lol. I'm actually wondering if we're going about autoleveling in the wrong way. To be more consistent, another way is to keep giving them "level ups" (or level downs) until they reach the same base stat total as the person they're replacing. This would make prepromotes that become unpromoted units be kind of garbage though. We could also choose to be asymmetrical in how we do the logic. Maybe leveling down uses the old logic, while leveling up tries to match the replacement. We could apply a bonus, but it really depends on what the bonus is. The opposite problem would be mage units being noticeably better than non-mage units due to said buff. And to be perfectly honest, I had forgotten about the personal growths idea until you brought it up again. I'll add it to the github so that I don't forget. 🙂

Yeah, the autoleveling logic can be a bit hit or miss sometimes. I had to take quite a few stabs at it across the previous versions. Usually it flips back and forth between extremely useless to extremely overpowered. Part of this is because autoleveling is going to inherently favor unpromoted units becoming promoted units due to high growth and promoted units becoming unpromoted units being good due to naturally higher bases (from their lower growth). The other problem is that unpromoted to unpromoted can end up spotty as well, especially when the levels of units that join you also don't increase monotonically. I do indeed treat promotion as a 10 level gap, so Lv1 Unpromoted to Lv1 Promoted is just 10 levels of their growths, in addition to the promotion bonus they would receive. Looking at the code, I also have special logic that apparently made brand new pre-promotes (i.e. unpromoted units becoming promoted units like what you're referring to) slightly worse by removing 3 levels, which I'm sure I had a reason to do, but at the moment, I don't remember, so maybe that's causing the discrepancy (though that's like 2 extra points at most in all areas). Honestly I might just remove that, because I'd rather units be a bit overpowered than causing softlocks. I can also adjust it to 15 levels for promotion, but I feel like that's a much more drastic change. Maybe we can try 13 levels for promotion. It's an odd number, but maybe that'll feel more balanced. I'll have to look at Wallace as a special case, because the randomizer treats characters only as if they were one class (so I admittedly forgot about this case). In Wallace's case, I think it uses his normal class, which is a vanilla Knight. It's possible that his class here actually is changed in the script somewhere, or it loads one of two classes, which I don't take into account. This is a bit weird. The delta should be floor((growth / 100) * levels) So if there's only one level, then that should be a change of 0. The only other thing I can think of is that it does use the level from the character data to determine what the level difference is, and that level isn't always consistent with the level that character shows up as (which is defined in the chapter data). On reflection, this probably explains Wallace. Bartre and Hector are consistent though, so I'm not sure what the deal of that is. And yeah, Ninian and Nils have some oddities, so one of the recommendations was an option to not randomize Ninian and Nils when doing random recruitment, since these are the issues it can cause. Yune should have stripped any kind of custom animations from the characters. This is one of the things it does prior to doing any kind of character randomization, precisely for the reason you listed. That said, looking at the code, I noticed I only do this when classes are randomized. So if you're only doing recruitment randomization, I have a bug to fix. 🙃 The palette adaptation process isn't guaranteed. I think some characters and classes are particularly problematic as they have insufficient colors to map to other classes. Yune tries to make up a middle color or slightly different shade of the same color where necessary, but it's possible this won't ever look perfect on some classes. Troubadours and Nomads (and their promotions) are particularly problematic, since their horse happens to share a lot of the colors with the characters themselves. There's only so much you can do when the logic is written to be as loose as possible (i.e. without hardcoding a specific palette for each character/class combination). I've heard this feedback more than once, but I'm unsure of how much of a buff this should be before it becomes the opposite problem. Should it be a flat +X buff to their result, or should it have a floor of Y (fill in X and Y as necessary)? And is Power the only stat that has this issue? Maybe it's something we apply to the class itself that buffs its base to make all mages (playable and enemy) better. The only thing I can think of is a more general bugfix I made recently. If you are randomizing weapon effects as well, I do update the weapon descriptions to be more descriptive of the effects that were added so that they're easy to look up in gameplay. The bugfix wasn't specific to any game, but the diffing logic I had to apply changes was bugged so that every 1024 bytes written could have some changes that should have been made, but are not. This manifests in some really weird ways and the logic was used for all games. Yeah, I usually keep the smaller (i.e. non-major) releases on the github page because I don't want to spam other places I post this to. I can update the first post to point to the new version, though. I appreciate all of the feedback, so keep them coming. 🙂

Never mind, I figured it out. For future reference if anybody has the same question: The map sprite table is, for whatever reason, tied implicitly to the class table, so if you move the class table and start adding classes, the map sprite table also needs to move, and each class should have a corresponding entry in the table. Why the index to the map sprite in the class data isn't sufficient, I don't know, but this was the root cause of issues for me.

I feel like this is probably something stupid I'm missing, but I've been trying to create a clone class for an existing class to better manage promotions and effectiveness. So I've copied the 0x20D0 bytes from the default location in FE7 (0xBE015C) to the bottom of the file (0x1000000). I then updated the pointers to 00 00 00 09 (three instances replaced). So far everything works up to this point. All of the existing classes still work fine. I then go and copy Lyn's class and paste it to the end at index 0x64 after some of the placeholder classes that apparently are known to cause issues. I also update the class number appropriately to 0x64 (this is the only change I make). Then I give this class to a unit in the chapter data. This causes the game to freeze once that unit tries to load. Is there something else that needs to be done when adding a new class? It doesn't use any new animations or sprites. Everything points to a known working class. If I use the original class (0x2) everything still works. So my current guess is that it doesn't like reading past 0x63 or that there's another table that is implicitly tied to the class table that I'm unaware of.

It's in the data, but as far as I know, it has no attached battle animation, which I do want to work to consider it functional. Most classes that had a female variant in the other games generally have a female variant in FE7 as well as far as the data is concerned, but using those classes usually result in something missing, whether it's map sprites or battle animations.

#1 is fine. #2 is actually mostly already done. Monster classes in FE8 have to be specifically turned on via "Mix Monster Classes". By default, monsters can only randomize into other monsters and humans to other humans. Necromancer is an end-game class and is already removed from the class pool (so existing Necromancers are not randomized, and nobody randomizes into a Necromancer. This is also true for other end-game classes like King in FE6, and Dark Druid in FE7.). The only classes that we don't cover is Brigand and Soldier (and Brigand is allowed for FE6). Female Thief I think could be problematic, since Leila's class isn't actually complete. It doesn't promote like male thieves do (at least not properly), and it uses an assassin battle animation (that I'm not even sure if it's functional beyond just standing there). Prepromote females in FE7 get a lot more variety since it adds Paladin, Swordmaster, and Wyvern Lord into the mix, but yeah, unpromoted units are pretty much stuck with the small pool. The female list does include the healing classes, but specifically for the classes that are able to attack, the pool is incredibly small. The main concern is Lyn, who has a total of 4 choices (because a Cleric or Troubadour Lyn is immediately softlocked in her prologue). Yeah, Armor Knight's battle animation is basically the same, but at least in the code, there are technically two different classes for Armor Knights. But if we're going to just try to use the correct gender class where possible, then it shouldn't be an issue. As for the Trainee classes, Tier 0 is actually the most difficult to make work properly, but I think there have been some new discoveries and breakthroughs for that, so maybe it could happen. But having an option to remove Trainees from the class pool should be relatively straightforward. Interestingly, the Paragon scroll is, by default, locked to Geoffrey and Astrid, which makes it completely useless normally. 0.9.2 gives it a proper name (along with a few other unused items that didn't have names attached) and removes the unit restrictions, so it should work properly now. Ch. 19 I think is fixed, though I haven't verified it yet. The theory is that when I was messing around with randomizing chests in this chapter, I broke the chapter script a bit so that it skips the battle prep. I have since then refactored the logic for chest randomization to be much more intelligent than before, so it hopefully should fix the issue (but again, I haven't verified it).

It can certainly be an option. I mentioned earlier that when I wrote this, the initial version was limited to FE7, so a lot of logic came out of that game first. This is one of those because limiting it by gender can be extremely limiting in FE7 for female characters, as the only attacking unpromoted classes they can be are Archer, Lyn Lord, Mage, and Pegasus Knight. Since I was testing on Lyn mode at the time, it meant Lyn's class choices were effectively 1 in 4, one of which is just to not randomize the class. But I'm curious of your implementation. Are you thinking that we just assign the correct gender where possible instead of restricting the class pool for characters? That may not need an option, honestly. As for the Super Trainee classes, I can probably add an option for that. Do you think it should restrict Tier 1 and Tier 2 super trainees or just Tier 2 ones? That's odd. Without knowing much else, I'd say to check your version of Dolphin, or if you have a changelog, I can see what might be causing the issue. There are still many things I don't know about FE9 and how forgiving it can be with different settings. I know the stable version of Dolphin (5.0) shouldn't have any issues with the randomized game, but developmental versions can have problems (the newest versions will let you ignore for the session if it's not a fatal issue). The only thing I'd make sure of is that MMU is disabled in the Advanced tab (though if this is enabled, then you shouldn't be getting past the prologue anyway (this is something I do want to fix eventually)). We can do that. I actually don't remember the old randomizer having this option, but it would be easy enough to add for each of the GBAFE titles. But just to make sure I understand what you have in mind beyond soldiers and brigands (and FE6 would include brigands for Gonzales), since I can't think of a class that's not included outside of the ones that are already not in the pool. If you saved a changelog, it has the seed you used in it (under the randomization options). If you copy and paste that seed, you should get the same result assuming you use the same version of the randomizer.

We could make it an option to limit dancers to one, but I'm not sure if how that would solve a randomized recruitment run without also randomizing classes (outside of not changing when dancers join you). FE9 (and FE4) is actually problematic because dancers in that game can refresh up to 4 units, so with two herons, you have infinite turns. For what it's worth, FE9 (and FE4) does have logic to make sure you don't get multiple herons, but that's a relatively recent fix. I suspect the run you're seeing is using an older version of the randomizer. There was a bug that basically ignored the heron check when assigning classes that has been fixed as of 0.9.2. With strict matching, it should be trying its best to keep you with Iron weapons where possible. Makes me think strict matching is broken a bit, honestly. Loose randomziation will just try to match the rank, and if strict matching fails, loose matching is what it falls back to. If you want an option to just entirely remove them from the pool, we can do that as well, but I think it does cut down on a lot of the variety of weapons that you can get. But as an option, that's fine. This is correct. When I wrote the first version of this randomizer, it only supported FE7, which, obviously, starts you with a solo Lyn. If she can't attack, then the game's over right there, so that was one of the first checks put into place. It's carried over to all other games since then. Since FE7 is also very scripted, a lot of the restrictions also came out of it. Like units that have scripted fight sequences are also required to be able to carry out their part of the script. For example, Rath and Erk both have to attack/counter an enemy, so they both also have to be able to attack (and they both have to be able to do so from range). Since then, I've had a bit more experience messing with scripts, so it's possible to remove some of those restrictions if we're willing to alter the script to avoid these issues, but they're relatively low priority issues. I'm in the process of making a list of weapons for each type right now (specifically making some custom weapon icons), but I figure I'll need a set of names for the starter weapon and a set of names for the final weapons. FE9 is probably not going to be able to do this just yet, because I'm unsure of how to make a new weapon in that game just yet, or where any of the icons are stored. They're also only grouped by weapon types for the time being, since I wanted to get a version where this works first before going ham on the potential weapon pools and having certain weapons for certain classes. If we have a surplus of weapons, we can randomly choose one. I'll probably create the final weapons based off of legendary weapons from other titles. One challenge is that for a game like FE7, I'll need three weapons of each type on the off chance that all three lords use the same weapon type. The other challenge is coming up with names that fit in the limited space the game has to display the name. Any name that is three words long is almost certainly not going to fit.

Hmm... That's weird. I can't find VBA-M at version 1.8.0. I do see vanilla VBA 1.8.0, and it seems to work fine there too. Assuming Eirika breaks for you, it seems to work fine for me: Maybe try a different emulator and see if it still breaks? I personally use mGBA. I will say that it's weird that only some classes do this.

I tried replicating your settings with the same seed, and I haven't run into any problems in the first two chapters. Do you know which classes specifically have issues? Or which encounters have issues? (This assumes we actually have the same result, which may not be the case if the Java Random implementation is different. I have Cav. Eirika, Ranger Seth, Recruit Gilliam, and Brigand Franz.) If it's inconsistent with the same encounter, then I'm not sure. What emulator are you using?

Currently there are some issues with running the randomized game on real hardware. I'm looking into this for the next release, but for now, it will most likely crash after the prologue's title card.

There probably is space for it, but the bigger benefit is definitely the second point you mentioned: the ability to lock lords from promoting regardless of their class until the appropriate time, which would take care of the other problem where if you promote early and then the story forces you to promote, it will actually demote you, since promoted classes' promotion is set to the base class again. The first point about locking weapons specifically to lords could be done by, as you suggested, simply setting the weapon lock ability to specific characters, rather than specific classes. This also means I only need the base classes to be unique. They can promote into the generic version of the promoted class. So that's 1 extra class in FE6, 3 extra classes in FE7, and 2 extra classes in FE8. I might even be able to do this without repointing, since there's a lot of slots for classes that are reserved, but not used (like female cavaliers in FE6 and FE7).

You are correct. This is a flag that can be moved from the class to the character if we want to lock it specifically to a single character, but by default, the vanilla game locks it to class instead, and the randomizer does not change this. Since the lords are unique classes, this isn't a problem in vanilla and there's no difference whether the class has it or the character has it. But obviously, when you start giving out these classes freely in a randomized setting and multiple characters can be lords, then there is a difference. I opted for it to be less restrictive and anybody that becomes the lord classes can use the lord weapons. You can make an argument for the opposite, and if I do go down the custom weapons path, that'll likely be what I do, since those classes are not unique classes to begin with, so they would be tied to characters specifically. But that's also why I don't want to necessarily remove Rapier, Wolf Beil, or Mani Katti (or Reginleif).

My understanding is that the Prf weapons in the GBA titles are tied to class, instead of character, so they can by used by any character that becomes a Lord class, though that may not be a guarantee depending on your options. The option to exclude lords is partially for people that don't want to have to deal with that, but is also to minimize game breakage, since a lot of game scripts directly refer to the lords to do things, not to mention other changes like the menu and the world map. The way the randomizer is written, the lord classes are added to the pool if lords themselves are included, but are excluded if the option is disabled, so there should always be a chance of any character becoming a lord class if lords are randomized. This doesn't guarantee that those weapons aren't useless, but the odds should be in your favor that at least one character can use them (though not necessarily a good character). If you enable the option to assign classes evenly, this should be guaranteed, as it won't give out a duplicate class if a class in the pool hasn't been assigned yet. While I do agree, this is mostly up to RNG and can be considered working as expected. And lances, for example, don't really have a Prf type weapon naturally in the game. Maybe in a future release, I could have an option that creates custom weapons for the actual lords based on their weapon type with a similar (or random) special effect. It'd be a neat idea. Hector Chapter 11, I know is notorious for being easy to softlock on since you only have two characters to rely on. I have some ideas for addressing this particular issue at least with the boss Wire (though maybe the minions may be in need of some nerfing too (or the Hector replacement in need of some minor buffing)), but I think the further along in the game you get, the less likely this is to happen unless you're intentionally trying to softlock. I'd imagine with the amount of units you get before things start to seriously ramp up, you should have at least a few gems in there that can carry you. It's definitely on the roadmap for the next release as something I want to tackle after seeing a few other runs come close if not immediately hitting a brick wall with Wire. This is an interesting idea. I don't necessarily want to get rid of the original weapons, but it wouldn't be too difficult to create an axe with identical specs to the rapier. Might even be able to get some custom icons for those too. Obviously it wouldn't get to the point of getting fancy animations for Durandal and the like on an axe, but at least the axe would look neat. Like I said, the weapons are locked to the classes and not necessarily the character, so any character that becomes, say, an Eliwood Lord would be able to use Rapiers and the Durandal. With that being the case, I don't necessarily want to get rid of Rapiers, but I'm ok with creating a custom weapon for the actual lords if they're not of the normal Lord classes. Like if a Pegasus Knight were to fill a lord slot, I'd insert a Wing Spear or something into the game and give it to him/her. Maybe an option to make sure lords get their Prf weapons to start instead of a completely random weapon would be a good idea too. It'd also solve the Hector Ch. 11 issue if the Hector replacement always started with a special weapon instead of a random weapon. I plan on backporting some of the FE9 options into GBAFE where feasible. Similar replacements was an idea I had for FE9 after testing out a few runs of the first chapter, since it has two houses with items that could potentially be either completely useless or completely gamebreaking. Bonus damage in FE7 is definitely doable and something I'd consider adding (along with some other fun or interesting mechanics changes for all of the GBAFE titles), but while I would love to make this change to FE9, I have yet to figure out where any of the game logic is and how to change it safely yet, so that might be a long ways down the road. As for the cross-gender assignment option, for recruitment it was mostly because I had added logic to replace names in the script to match the character, but I didn't have a good way of changing pronouns properly, since it wasn't always clear who a character was referring to in the dialogue, so if referring to, say, Serra replacing Hector as a "he" bothered people, there would be an option to make sure only those of the same gender could replace him, so that pronouns continued to match. I actually had this for classes at one point, but for some games like FE7, that really limits class selection for female characters due to the surprisingly small pool of unpromoted female classes that could attack (basically just Lyn Lord, Archer, Mage, and Pegasus Knight). FE6 and FE8 fare much better in this regard. As for donations, I wasn't planning on having any kind of donations or anything at least until I get to v1.0, since it didn't feel right to ask for it before I had something that I considered complete enough for an initial proper release. Right now, I mostly work on this in my spare time and at my own pace, and I was concerned that having people give money for working on it would set expectations that may be out of my reach. So I've held off for now. Once v1.0 is ready and I can confidently say that the supported games can be randomized and beaten reasonably most if not all the time, then I'll consider it.

I would love to do this, and yeah, v1.0 was intended to be when I get Radiant Dawn randomized. That said, I haven't even started on Radiant Dawn yet, so that probably won't be for a while, especially considering Radiant Dawn has to go through decryption for the ISO before I can even process it. Thankfully the systems and data structures are fairly similar, so in theory, at least, the randomization piece should be easy.

Oh, that's interesting. I assumed that she'd use the weapon if she had at least one weapon in her inventory. Was she forced to her first weapon? I can make a fix for this for future releases. Meanwhile, if you want to fix it yourself, you can go into Nightmare and FE6's army editor and open that chapter and reorder her starting inventory in the chapter.

Hmm... Do you have another line after that? On my MacBook Pro, I get this: Shens-MBP:~ Kotori$ java --version java 12.0.1 2019-04-16 Java(TM) SE Runtime Environment (build 12.0.1+12) Java HotSpot(TM) 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing) Shens-MBP:~ Kotori$ It wouldn't hurt to update to the newest version of Java to see if that helps. I only built one version, and if you don't have a 64-bit JRE somehow, then that might explain things. I use this for development: https://www.oracle.com/java/technologies/javase-jdk14-downloads.html

It shouldn't take that long. If you're stuck on calculating file offsets, then you likely do not have enough memory allocated for the VM. You can read a few posts above for a solution. The first error message sounds like you don't have Java installed or you have an outdated Java version installed, which is rare for Mac, since I think they all come with it installed. What does java --version give you when you type it into terminal?

After you finish randomizing, the randomizer should give you an option to save a changelog. The changes the randomizer made should be in that resulting HTML file. I need to polish this, but the information you're looking for is there.

That's great to hear! I'll look into seeing if I can set that flag in the wrapped executable for future releases so that people in the future hopefully won't have to worry about it.

Possibly. The ISO itself is 1.4GB so if your max heap size is on the order of hunderds of MB, then it probably is running out of memory. I think that is the default for a lot of 32-bit JVMs, but clearly you do have a 64-bit JVM. I think there are ways of changing the default for the JVM, but you can also specifically run the JAR with java options to override the max heap size. If you use the JAR, java -Xmx4g -jar Yune.jar or whatever you name the jar file. I do know that different VMs will have different default settings, so I'm guessing you have a relatively old VM when they capped the max heap size to a lower value. That said, it's interesting. I'm wondering if 32-bit JVMs actually do have enough memory to do FE9 as long as whatever the max heap size is overridden to allow it to use more memory.

Hmm... Maybe your JVM isn't set up to use that much memory? I'm assuming you're on Windows, so if you open up the command prompt and run java -XX:+PrintFlagsFinal -version | findstr HeapSize you can figure out how much the maximum heap size your JVM is allowing. On mine it's a little under 4GB (4,278,190,080). I think the default should be the minimum of that and half of your real RAM, so if you have relatively less RAM, that may also cause issues. For what it's worth, this is my result: C:\Users\Lu\Documents\Universal-FE-Randomizer\Executables\JAR>java -XX:+PrintFlagsFinal -version | findstr HeapSize uintx ErgoHeapSizeLimit = 0 {product} uintx HeapSizePerGCThread = 87241520 {product} uintx InitialHeapSize := 536870912 {product} uintx LargePageHeapSizeThreshold = 134217728 {product} uintx MaxHeapSize := 4278190080 {product} 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\Documents\Universal-FE-Randomizer\Executables\JAR>

I can't say where to get the ISO from beyond ripping it yourself from the disc, but if it's a .7z file, you can probably decompress it with 7zip and and it might be the correct format already. It's hard to say though, since the compressed file could be anything.

If you had the wrong ISO, then the randomizer would have told you when you first loaded it up (it should have told you the checksum didn't match anything the randomizer knew about). Assuming you didn't see that dialog, it should work. Now if you did see that dialog, then chances are good it's either the wrong version or the wrong format. Yune operates off of the clean ISO directly ripped from the disc, while Dolphin can support a variety of formats. Specifically, if you saw this dialog: That's probably the wrong version or wrong format. If you want to run the checksum, the CRC32 for FE9 should be F24CB38A.

If you're using the 64-bit one, you shouldn't have this issue (unless you're running out of memory even on the 64-bit VM). The 32-bit one will very likely run out of memory for FE9, so definitely don't use that one. That said, if you are indeed running out of memory, there's not much that could be done for the time being. I could look into optimizing it for memory usage, but since Yune avoids writing extra files to the hard drive, it has to keep quite a bit of data in memory to randomize it. I would check to make sure you are indeed running the 64-bit one, and then I would check if you have enough disk space. The randomizer creates a brand new ISO out of the one you give it, so you'll need 1.4GB free. That said, if your hard drive is also low on space, then I would recommend writing to a different drive or clean some stuff off of the drive. Even on the slowest of computers it shouldn't take that long to calculate file offsets. The only file that takes a noticeable amount of time to calculate is system.cmp (because that's where most of the changes happen), so if it's any other file that it's recalculating, it's definitely stuck.