Jump to content

lushen124

Member
  • Content Count

    96
  • Joined

  • Last visited

1 Follower

Previous Fields

  • Favorite Fire Emblem Game
    Radiant Dawn

Member Badge

  • Members
    Micaiah

Recent Profile Visitors

1873 profile views
  1. 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?
  2. Sorry, try it again. I updated the link: https://www.dropbox.com/s/mg2o8lyzbrvmn1m/Yune.jar?dl=0
  3. 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
  4. 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.
  5. @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.
  6. 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.
  7. 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.
  8. 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. 🙂
  9. 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. 🙂
  10. 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.
  11. 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.
  12. 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.
  13. #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).
  14. 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.
  15. 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.
×
×
  • Create New...