Jump to content

lushen124

Member
  • Content Count

    100
  • Joined

  • Last visited

1 Follower

Previous Fields

  • Favorite Fire Emblem Game
    Radiant Dawn

Member Badge

  • Members
    Micaiah

Recent Profile Visitors

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