47948201 Posted December 22, 2012 Share Posted December 22, 2012 Oh well doop, I guess I have no suggestions xP But maybe it would be easier to do a one-time ASM hack? Eh, I don't know what I'm talking about when it comes to that stuff; carry on. Quote Link to comment Share on other sites More sharing options...
Chocolate Kitty Posted December 22, 2012 Share Posted December 22, 2012 I...Don't understand what you're saying, sorry. I'm just saying that the script can be useful if you're playing a chapter where the main character isn't required to win. Like, imagine you're fighting the Fire Dragon, and Eliwood is about to land the finishing blow, but he misses, and the Dragon scores a fluke critical. Is there any reason the remainder of your forces should be disallowed from completing the game? Or even if, say, you suck at the game and every single one of your units but Athos dies, but the Dragon is almost dead--will Athos abandon the entire chapter and let all the other dragons come in? He really shouldn't. As for the script itself needing suggestions, I don't think it does (hence why I'm arguing like this for it XD). If there's no script currently released to get rid of permadeath (I haven't checked), though, you should make that, since it would go well with this one. In your situation, yes, since having no Eliwood or Hector means no FE6. But, I misunderstood what you meant to begin with so B:AUJSKVHJA SJHGV 8D And yeah, something percentage based, or even a set number that you could alter if that would be easier. Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 22, 2012 Author Share Posted December 22, 2012 In your situation, yes, since having no Eliwood or Hector means no FE6. But, I misunderstood what you meant to begin with so B:AUJSKVHJA SJHGV 8D And yeah, something percentage based, or even a set number that you could alter if that would be easier. I'll go with number based since it's easier. BRB Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 22, 2012 Author Share Posted December 22, 2012 (edited) Yo, Kitty of Time. https://dl.dropbox.com/u/35795576/IfMoreThan3AlliesDead.dmp Mind testing this for me? CheckPlayerAliveQuantity: .thumb .org 0x00 mov r1, #0x00 @Cycler mov r2, #0x00 @True or False mov r3, #0x00 @Death Counter CheckCharacterID: ldr r0, =0x0202BD50 @Loads start of character ID pointer offset ldr r0, [r0, r1] @Looks for a pointer cmp r0, #0x00 @Checks to see if a pointer exists bne CheckCurrentHP @Continues code if there is, meaning there is a character there b DeathCheck @If there is not a pointer, meaning no character, then begin next phase CheckCurrentHP: ldr r0, =0x0202BD63 @r0=Offset of current HP ldrb r0, [r0,r1] @r0=value of current HP plus slot cmp r0, #0x00 @Check if current HP is zero beq AddDeathCounter @If so, add to death counter add r1, #0x48 @If not, next slot and try again b CheckCharacterID AddDeathCounter: add r3, #0x01 @Add 1 to death counter add r1, #0x48 @Prepare to check next slot b CheckCharacterID @Proceed to check next slot for a dead unit DeathCheck: cmp r3, #0x03 @Compare death counter to the number 3 bhi returntrue @If it is higher, return true mov r0, #0x00 @Otherwise, return false bx lr @End code Returntrue: mov r0, #0x01 @Return true bx lr @End code Edited December 22, 2012 by MarkyJoe1990 Quote Link to comment Share on other sites More sharing options...
CT075 Posted December 22, 2012 Share Posted December 22, 2012 not gonna bother talking about the inefficiencies of that code (if it works it works) but wouldn't it be more useful to have it percentage based instead of a fixed number Quote Link to comment Share on other sites More sharing options...
Chocolate Kitty Posted December 22, 2012 Share Posted December 22, 2012 er... I suppose(I didn't actually have any plans to use it, I just thought an alternative version might be nice), I'll have to find where I can test this and I'll get back to you. Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 22, 2012 Author Share Posted December 22, 2012 not gonna bother talking about the inefficiencies of that code (if it works it works) but wouldn't it be more useful to have it percentage based instead of a fixed number If you're willing to answer more questions I have on skype, I can work on making it percent based. Quote Link to comment Share on other sites More sharing options...
zahlman Posted December 24, 2012 Share Posted December 24, 2012 (edited) Basically just paste this dmp into an area of your rom To be specific you need to paste the contents of the .dmp file, at an even address. Anyway, taking a shot at some optimization (on the second assembly; you can figure out how these ideas apply to the first) just to show you some techniques... CheckPlayerAliveQuantity: .thumb .org 0x00 ldr r1, =0x0202BD50 @ pointer to current character struct mov r2, #0x04 @ number of allies that have to die for a game over CheckCharacterID: ldr r0, [r1, #0] @ is this struct used? cmp r0, #0x00 bne CheckCurrentHP @ if nonzero, inspect this struct. mov r0, #0x00 @ otherwise, ran out of characters and enough are alive; bx lr @ return false. CheckCurrentHP: ldrb r0, [r1, #13] @ 0x13 is the offset of HP member of the struct cmp r0, #0x00 @ Alive? bne Alive Dead: sub r2, #0x01 @ Take away a strike bne Alive @ If nonzero, we still have strikes remaining mov r0, #0x01 @ Uh oh, ran out of strikes; bx lr @ return true. Alive: add r1, #0x48 @ Otherwise, try the next unit. b CheckCharacterID The basic idea is that you usually want comparisons to work opposite to what you expect; you write a branch instruction that executes when the special thing *doesn't* happen, so you can use it to *skip* the special handling. Also comparing to zero is easier than comparing to other numbers, so try to make counters that count down to zero instead. Finally, try to let things "fall through"; if you need to do something (add r1, #0x48) whether or not the condition is true, then put it in a spot where it will be reached whether or not the condition is true, instead of duplicating it in both condition-specific parts. (Often there is a "common" task but nothing to do in one of the cases - e.g. here there's common code whether a unit is dead or alive, and specific code when it's dead - but nothing specific when it's alive. So I use a branch to skip the "dead" handling when the unit is alive, and then do the common part.) This all makes more sense if you compare it to how it would be structured in a friendlier language ;) Edited December 24, 2012 by zahlman Quote Link to comment Share on other sites More sharing options...
Arch Posted December 24, 2012 Share Posted December 24, 2012 (edited) Nobody's discussing the most glaring flaw: it doesn't even work. I put it in an ASME in misc events, just like the DefeatAll code works for the main game. It didn't trigger when all of the players were defeated. I then thought to try it out with a turn event with [01,255] and an IFAT. It triggers regardless, even when everyone's still alive. IFAF triggers never. It might be that I'm testing in a chapter without a prep screen; if so, that's another flaw. Bummer. I was pretty happy when you posted this; right when I needed something just like this, too. Edited December 24, 2012 by Arch Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 Nobody's discussing the most glaring flaw: it doesn't even work. I put it in an ASME in misc events, just like the DefeatAll code works for the main game. It didn't trigger when all of the players were defeated. I then thought to try it out with a turn event with [01,255] and an IFAT. It triggers regardless, even when everyone's still alive. IFAF triggers never. It might be that I'm testing in a chapter without a prep screen; if so, that's another flaw. Bummer. I was pretty happy when you posted this; right when I needed something just like this, too. When I find the time, I'll get to fixing it. Sorry for the inconvenience. Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 Okay, so I checked the code using a debugger (Thank you Cam), and it appears my code works fine. Arch, did you kill off three units, or did you kill off MORE than three? The code only returns true if more than three are dead. And it has to be IFAF since apparently IFAF and IFAT are in reverse (IFAF activates when the argument is true, and vice versa). Though, that might depend on your event assembler version. Quote Link to comment Share on other sites More sharing options...
Arch Posted December 24, 2012 Share Posted December 24, 2012 I'm not using the three, I'm using the original one for "all fielded units dead." Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 I'm not using the three, I'm using the original one for "all fielded units dead." ... Oh. Alright, I'll check that one out then. Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 (edited) Alright, tested the "All Units Dead" code... It works fine for me. I checked it in the debugger and confirmed this. You said you were running the check before your units are fielded, right? Meaning, no ally units on the screen? The code is supposed to be used either as an AFEV code, or a TURN code, and called in an event with IFAF. If you use it before the prep screen, it probably won't work as intended. If it still isn't working, my best guess is that you might be doing something wrong. EDIT: Apparently it doesn't work when you have a prep screen. I'll look into this. EDIT2: Try this one. Edited December 24, 2012 by MarkyJoe1990 Quote Link to comment Share on other sites More sharing options...
Arch Posted December 24, 2012 Share Posted December 24, 2012 You said you were running the check before your units are fielded, right? Meaning, no ally units on the screen? ....No? I'm running the check after everybody's dead. In the middle of the chapter, through a TURN. I thought I was clear about this in the original post. I tried a TURN [01,255] with IFAT and IFAF, neither worked appropriately. Tried an ASME ala the DefeatAll code, no dice there either. How would I use it as an AFEV? AFEVs, as far as I know, don't point to ASM conditions. EDIT: Apparently it doesn't work when you have a prep screen. I'll look into this. Huh? I'm guessing you typo'd and meant "not have," right? Because my problem is the exact opposite because I have no prep screen. Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 (edited) How would I use it as an AFEV? AFEVs, as far as I know, don't point to ASM conditions. I wasn't clear. Trigger an event with AFEV or TURN, and make the event call the condition. Though, I guess you already did that. Huh? I'm guessing you typo'd and meant "not have," right? Because my problem is the exact opposite because I have no prep screen. Okay that's weird, because I don't have a prep screen in my testing chapter. Are there ally units you haven't deployed? Also, I edited my previous post to have a download to new ASM. Have you tried it? If you can, could you talk to me on skype about this? I wanna get to the bottom of this. Edited December 24, 2012 by MarkyJoe1990 Quote Link to comment Share on other sites More sharing options...
Arch Posted December 24, 2012 Share Posted December 24, 2012 Also, I edited my previous post to have a download to new ASM. Have you tried it? If you can, could you talk to me on skype about this? I wanna get to the bottom of this. I just applied the new version, works like a charm. Thanks. Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 (edited) I just applied the new version, works like a charm. Thanks. The fuck? Wow. I didn't even test it to make sure it works. You're welcome. =S Lemme know when you need other ASMy stuff. Edited December 24, 2012 by MarkyJoe1990 Quote Link to comment Share on other sites More sharing options...
Arch Posted December 24, 2012 Share Posted December 24, 2012 Mm'kay, so I went back and did some further testing. It works when there are no units left, yes. But the event just triggered with one unit left, which sort of destroys the effect I'm going for. Any way to get that fixed up? Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 24, 2012 Author Share Posted December 24, 2012 (edited) Mm'kay, so I went back and did some further testing. It works when there are no units left, yes. But the event just triggered with one unit left, which sort of destroys the effect I'm going for. Any way to get that fixed up? I'll figure something out. Actually. mind sending me your ROM + SAV + ASM Location so I can debug the problem? EDIT: I tossed a guess out and assumed that sometimes undeployed units are checked before deployed ones, and remade the code. Here Hopefully that fixes the problem. Edited December 25, 2012 by MarkyJoe1990 Quote Link to comment Share on other sites More sharing options...
CT075 Posted December 25, 2012 Share Posted December 25, 2012 (edited) it's not the presence of a prep screen that causes a problem it's the presence of allied units that are not currently on the field ie in EN there is garbage data leftover from between tales that is causing a problem Edited December 25, 2012 by CT075 Quote Link to comment Share on other sites More sharing options...
MarkyJoe1990 Posted December 25, 2012 Author Share Posted December 25, 2012 it's not the presence of a prep screen that causes a problem it's the presence of allied units that are not currently on the field ie in EN there is garbage data leftover from between tales that is causing a problem Yeah, I had a feeling it was something like that. The game needs to remember your other ally units afterall. Hopefully this new update of the ASM will work. Quote Link to comment Share on other sites More sharing options...
Arch Posted December 25, 2012 Share Posted December 25, 2012 I'll figure something out. Actually. mind sending me your ROM + SAV + ASM Location so I can debug the problem? EDIT: I tossed a guess out and assumed that sometimes undeployed units are checked before deployed ones, and remade the code. Here Hopefully that fixes the problem. This one solved the problem, yeah. Much appreciated, Marc! Quote Link to comment Share on other sites More sharing options...
zahlman Posted December 25, 2012 Share Posted December 25, 2012 it's not the presence of a prep screen that causes a problem it's the presence of allied units that are not currently on the field ie in EN there is garbage data leftover from between tales that is causing a problem Yeah come to think of it, that test for the outer loop seemed pretty sketchy to me. I assume there's an actual count of fielded units for each team in WRAM somewhere, yeah? Do you happen to know where? Quote Link to comment Share on other sites More sharing options...
CT075 Posted December 25, 2012 Share Posted December 25, 2012 it would make sense that there is one but i don't know where it is but any unfielded ally unit has their coordinate bytes set as FF XX (where XX is something that i don't know) so once you reach those you know you're done Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.