Jump to content


  • Content Count

  • Joined

  • Last visited

1 Follower

Previous Fields

  • Favorite Fire Emblem Game
    Radiant Dawn

Member Badge

  • Members

Recent Profile Visitors

2763 profile views
  1. 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.
  2. 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. Shouldn't take that long. Which file are you loading? And is it reproducible? 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. 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. 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.
  3. 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).
  4. 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. 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. 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. 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. 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. 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. 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.
  5. 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.
  6. 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.
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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). 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. 7. Yeah, these seem to have broken in the latest update. I'll have to investigate.
  8. 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).
  9. 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). 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.
  10. 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.
  11. 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.
  12. 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". 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. 🙂
  13. 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.
  14. 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. 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! 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. 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. 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. 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). 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.
  15. 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.
  • Create New...