Pandora's Box

If it has bytes, we can change it. Talk about anything relating to hacking and emulation here.

Moderators: General Moderator, Game Moderator

Re: Pandora's Box

Postby Master ZED » Thu Jul 21, 2011 4:37 pm

On a related note, I got this in my PM box over at G'FAQs a couple days ago, but didn't really care to follow up on it (yip, still bored of this game). tl;dr, you may wanna test those fixes.
I'm currently playing through FF3 on SnesGT with a bunch of patches applied and I ran into a problem. During the battle with Vargas I couldn't get Sabin's pummel tutorial to occur. I ran some tests and found that the problem was due to the FC05 enemy command fix.

Testing involved returning to a savestate before the battle with Vargas, with the party standing in front of him prior to speaking to him. Then I started the battle and saw if I could get the tutorial to work. Once I thought I had isolated the problem to the FC05 patch I did the following.

Tried a clean rom: Tutorial came up easily.

Tried a rom with just the FC05 patch: No tutorial.

Tried a rom using every single patch and FF3usME...except for the FC05 patch: Tutorial came up easily.

Added the FC05 patch to the otherwise fully patched file and tried again: No tutorial.

I wanted to make very sure that I had found the right culprit because I had accidentally isolated the wrong patch for this problem earlier.
The Unoriginal White Sheet - http://masterzed.cavesofnarshe.com/
-Master ZED
User avatar
Master ZED
Moderator
Moderator
 
Posts: 472
Joined: Sat Sep 04, 2004 4:31 am

Re: Pandora's Box

Postby Assassin » Fri Jul 22, 2011 7:03 am

Lenophis: thanks for the reply.

Lenophis wrote:We used the logic from ZED's FC 05 patch and applied that to FC 02 and FC 03.

; FC 01
F01C40: TYX
F01C41: LDY $3290,X
F01C44: BMI F01C51
F01C46: LDA $3D48,X
F01C49: CMP $3A2E
F01C4C: BEQ F01C51
F01C4E: CMP $3A2F
F01C51:
F01D1B: BEQ F01D1F

F01D1D: CLC
F01D1E: RTS

; this fix is similar to ZED's FC 05 fix, but it applies to spell, command, and item counters
F01D1F: LDA #$FF
[...]


what's up with the bolded part? one address has no instruction, then you're magically resuming execution at an address many bytes later.

looking at the actual patched ROM in a hex editor, there is still an oddity. in Function F0/1BAF (the equivalent to the original C2/1C3B), the BMI and the first BEQ have had their branch sizes shortened, by 2 bytes and 4 bytes respectively. the effect of this is that both of them jump to the second BEQ at F0/1BC5 (at C2/1C51 in the original game, or F01C51/F01D1B in your pasted section). so you're pointlessly executing two conditional branch instructions in a row. now fortunately, executing the second branch doesn't harm anything, and you'll wind up going where you originally intended anyway. but that seems to be more due to luck than design.

based off what i can tell, these branches should have stayed the same size. i have no idea why they were reduced, but the empty instruction you have above seems to be related. something wacky in the assembling process?

----------------------

Master ZED: did you at least reply to the guy since he put in the work? :P even a simple, "I can't stomach this game anymore. But noted." would suffice.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Lenophis » Fri Jul 22, 2011 10:54 am

The missing instructions are whitespace for xkas to ignore, but the label is still there in case something jumps to it (probably the two consecutive branches you mentioned). We had some assembly problems by removing labels before, which became a small pain to track down. So we started leaving them and commenting out or removing the code on such lines. This horrendous code for example:

Code: Select all
; move entire inventory to ram for now
C326B8:   TDC
C326B9:   TAX
C326BA:   LDA $1869,X  ; load this item
C326BD:   STA $7EAA8D,X  ; move it
C326C1:   LDA #$FF  ; no item
C326C3:   STA $1869,X  ; save in this inventory slot
   LDA $1969,X  ; load this quantity
   STA $7EAB8D,X  ; move it
   STZ $1969,X  ; zero current quantity
C326C6:   INX
C326C7:   CPX #$0100
C326CA:   BNE C326BA
C326CC:   ; TDC
C326CD:   ; TAX
C326CE:   ; LDA $1969,X
C326D1:   ; STA $7EAB8D,X
C326D5:   ; TDC
C326D6:   ; STA $1969,X
C326D9:   ; INX
C326DA:   ; CPX #$0100
C326DD:   ; BNE C326CE
C326DF:   RTS


Optimizing that sped up the "arrange" by almost a full second when you have a full-ish inventory (close to 230 items).
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Pandora's Box

Postby Assassin » Fri Jul 22, 2011 11:37 am

gotcha on the labels. any idea why the branches were wrongly shortened?

good work on the C3 function; the original was goofy. have you considered speeding it up further by doing a REP #$20 before the loop, two consecutive INXs in the loop, a SEP #$20 after the loop, and a TDC after that (to be safe)? it'd fit in the original function size, though i dunno whether you've since claimed the space for other parts of your patch.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Lenophis » Fri Jul 22, 2011 6:06 pm

Assassin wrote:any idea why the branches were wrongly shortened?

Can't think of anything, unless Imzog did it for the fixes.

have you considered speeding it up further by doing a REP #$20 before the loop, two consecutive INXs in the loop, a SEP #$20 after the loop, and a TDC after that (to be safe)?

Unfortunately, I have not. That should speed things up a bit even further.

it'd fit in the original function size, though i dunno whether you've since claimed the space for other parts of your patch.

Space is not an issue, since C3 (along with F0) are dynamically assembled, and that was a pain to get working correctly. :lol:
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Pandora's Box

Postby Assassin » Thu Jul 28, 2011 10:32 am

man, that does sound tough, but probably worth it should you make changes.

as for why i asked the original question about how PB handled those fixes: i was aware of the FC 05 patch issue when making my post. fistukman and i had been corresponding because he thought the Wild Cat bugfix was at fault, but after we determined it wasn't, he found the actual culprit. then he PMed ZED on gamefaqs, but the PM was too big and didn't go through, which he didn't realize for a few days.

the patch will work with most monster scripts, but has trouble with Vargas' because:
1) there are two FC 05 commands ("If monster has been attacked") in the counterattack script.
2) there are multiple IF conditions that must be met.

the way the patch is built, should the FC 05 command be executed twice in response to a single attack, it won't work properly. the first FC 05 command passes, then nulls out $327C,Y. then when the second FC 05 command rolls along, it wrongly fails, because $327C,Y is null, indicating the monster hasn't been damaged by anybody.

here is the relevant part of the script:

If monster has been attacked
If target self has less or equal than 10880 HP
If VAR000 has all the following bits cleared: 0
VAR000 set bits: 0
Text: "Enough!! Off with ya now! "
*Trigger event: Sabin intro defy Vargas*
-End if and reset targetting-
---
If monster has been attacked
If VAR000 has all the following bits set: 0
If VAR000 has all the following bits cleared: 1
If target self has less or equal than 10368 HP
*Trigger event: Sabin must use blitz (instructions follows)*
VAR000 set bits: 1
-End if and reset targetting-


when we're hitting Vargas and he's above 10880 HP, we're fine. the first FC 05 command tests positive, but then immediately exits, because his HP is too high. the second FC 05 command fails, but we don't really care, because had it passed, it would have exited due to high HP anyway.

when we're hitting Vargas and his HP falls between 10368 and 10880, the first FC 05 command tests positive, as does the HP test for <= 10880. him blowing away the party and introducing Sabin occurs, which is what's supposed to happen. the second FC 05 command never executes, and is irrelevant.

ah, but when we're hitting Vargas and his HP falls under 10368, we encounter problems. the first FC 05 command tests positive, but eventually exits, because Bit 0 of VAR000 has already been set. so we move onto the second FC 05 command, which should pass. but it fails, because $327C was nulled by the first instance of the command. so we'll never see the Blitz tutorial.

...maybe all those GameFAQers circa 2000-2004 somehow had this patch applied on their SNES cartridges? :P

the solution is to move the nulling of $327C,index so it doesn't occur as early. my best theory is to hook the early part of Function C2/13D3 (Take One Turn), and just null out everybody's variable then. and i believe it's safe to do this unconditionally, since it changes nothing if the variable was already null, and if the variable had been set, you'd want it nulled by the next turn anyway. while you're executing the loop, you might as well null out the variables used by FC 02 and FC 03 too.

now, because no *existing* monsters have multiple FC 02 or FC 03 commands in their counterattack scripts, the way PB currently does things should be safe.. but it's not robust enough to handle scripts modified in such a way, and in theory could run into the same problem that the FC 05 bugfix is.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Lenophis » Thu Jul 28, 2011 11:11 am

We are also aware of the "first come, first serve" behavior the AI uses. To that end, we make sure no two conditions start with the same check, if we can help it. That won't stop Heavy Armors from attacking themselves (yeah, they seriously do that right now) but hey, all's fair...
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Pandora's Box

Postby Assassin » Thu Jul 28, 2011 2:20 pm

re heavy armors: in the normal game, or just in PB?
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Lenophis » Thu Jul 28, 2011 6:20 pm

Just in PB.

Code: Select all
F1 45 - Target: Character that last attacked
EE - Fight
FF - End normal attack sequence

We've since realized that F1 45 doesn't always do what we were lead to believe. I forget the details at the moment, but it's not always the last character.
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Pandora's Box

Postby Assassin » Fri Jul 29, 2011 10:54 am

i'd have to see the whole script to comment intelligently. if the TekBarrier casting is still in there, maybe the targeting from that is lingering?

anyway, you're right that F1 45 is not specific to characters. looking at Function C2/1FFB, people were probably confused into thinking the "CMP #$0A" was checking characters versus monsters. but $32E0,Y differs from most variables in that it isn't referencing battle entities in increments of two (0, 2, 4, 6, 8, 10, 12, 14, 16, 18), but rather of one (0, 1, 2, 3, 4, 5, 6, 7, 8, 9). so the CMP #$0A is just present to make sure that the entity stored there isn't null (i.e. that there is a previous attacker). they can't use a simpler BMI test to just check for FFh because the top bit of the variable was cleared at the end of the previous turn, so it wouldn't trigger a counterattack every time Function C2/4C5B was called for the once-attacked entity.

because Variable $32E0 and a number of other variables differ from $327C in that damage doesn't have to occur for an "attacking" entity to be stored there, TekBarrier could be responsible. now, i don't think that TekBarrier would trigger a counterattack with F1 45, because Function C2/4C5B has exceptions for attacking oneself.. but because command F1 45 is in the normal script, it will be executed.

iow, i think everything is working as designed here. post the full PB script to be sure, since rampant speculation makes me look irresponsible. ;)
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Lenophis » Fri Jul 29, 2011 12:19 pm

As you wish:

Code: Select all
FC 20 4B 00 - Conditional attack if current map is 0075
    FC 1B 27 00 - Conditional attack if current battle is using formation 039
    F1 01 - Target: Locke
    EF - Special: HydraulicKick
    EF - Special: HydraulicKick
    FE - End if
FC 06 36 01 - Conditional attack if Self has at most 256 HP remaining
    FC 09 36 16 - Conditional attack if any of set (Self) does not have status: Protect
    FC 26 02 00 - Conditional attack if game's difficulty is n00b
    F1 36 - Target: Self
    BF - Spell/attack: Magiwall
    FE - End if
F1 47 - Target: Use attack's normal targetting
FC 08 36 16 - Conditional attack if each member of set (Self) has status: Protect
    FC 06 36 01 - Conditional attack if Self has at most 256 HP remaining
    F1 54 - Target: Character with highest current MP
    F0 EF EE EF - Pick one spell/attack at random: HydraulicKick, Fight, HydraulicKick
    FE - End if
F1 45 - Target: Character that last attacked
EE - Fight
FF - End normal attack sequence
FC 12 00 00 - Counter attack if Monster(s): self is/are dead
    FC 06 45 01 - Counter attack if Character that last attacked has at most 256 HP remaining
    F0 EF FE B5 - Pick one spell/attack at random: HydraulicKick, Do nothing, Magilaser
    FE - End if
FF - End script


Magiwall is TekBarrier, if you were curious.
Image
Lenophis
Veteran
Veteran
 
Posts: 588
Joined: Sat Mar 26, 2005 5:52 am
Location: Duluth, MN

Re: Pandora's Box

Postby Assassin » Tue Aug 02, 2011 2:46 pm

Lenophis wrote:We used the logic from ZED's FC 05 patch and applied that to FC 02 and FC 03.

Code: Select all
; FC 01
F01C40:   TYX
F01C41:   LDY $3290,X
F01C44:   BMI F01C51
F01C46:   LDA $3D48,X
F01C49:   CMP $3A2E
F01C4C:   BEQ F01C51
F01C4E:   CMP $3A2F
F01C51:
F01D1B:   BEQ F01D1F
F01D1D:   CLC
F01D1E:   RTS

; this fix is similar to ZED's FC 05 fix, but it applies to spell, command, and item counters
F01D1F:   LDA #$FF
F01D21:   STA $3D48,X
F01D24:   BRA F01C5B


so it also includes FC 01 (Counter Commands)?

i scanned the Monster Scripts FAQ, looking for someone Vargas-esque in its use of FC 01, and found ... WoB Guardian (#273)!

in the original game, Guardian will often counter Fight with Battle. i believe your patch will stop it from doing so (though i have no idea what the PB script for WoB Guardian looks like). also, i'm pretty sure you'll never see the "No use!" message either, because VAR001's incrementation is a prerequisite for that.

because the "which command last used on monster" variable is overwritten quite regularly by the existing game (in contrast with the "which spell last used on monster" and "which item last used on monster" variables, which stay unchanged if you don't use any further spells or items), i don't think that FC 01 is in need of the same fix as FC 02 and FC 03.

but excluding it from the fix requires an extra comparison and branch, which is another reason i still favor doing the FC 02/03/05 bugfixes by hooking an early part of C2/13D3. (unless and until that method is proven flaky too!)
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Imzogelmo » Wed Nov 07, 2012 1:28 pm

Egads, I have a lot of catching up to do.

It looks like assassin's concerns on FC 02/03/05 are valid. Perhaps we should implement a fix in the manner he's suggesting so that we can have enough "window" in the counterattack scripts to be able to string together multiple conditions of the same set. That being said, it may also be worthwhile to create an FC condition that needs only to have had the target be attacked once to ever trigger the condition (Equivalent to FC 05 + set some variable). Since that is a fairly common thing to check for (and we really have no shortage of FC options), that may be one we should implement.
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 658
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

Re: Pandora's Box

Postby Assassin » Wed Nov 07, 2012 2:45 pm

i've been meaning to post a followup on this. a couple things:

1) Hollywood Narrator made a nice workaround to have Vargas' script avoid the bugginess with ZED's FC 05 patch:
http://slickproductions.org/forum/index ... 2#msg17422

2) my idea of clearing everybody's FC 02/03/05/etc counterattack variables at the start of any entity's turn (i.e. hooking early C2/13D3) won't work. specifically, there's the example of a multi-target spell being used on a group of monsters, all of whom have counterattacks in response. i had hoped that the game'd work this way: C2/1A91 gets triggered for all the monsters to queue their counters, then C2/13D3 (take one turn) gets triggered for all of them. but it's actually: C2/1A91 gets triggered for one monster, C2/13D3 gets triggered for that monster, C2/1A91 for the next monster, etc, etc. in this case, the second and third monsters' counterattack variables are zapped before they can make their decision about countering.

now, maybe narrowing this counterattack variable clearing in C2/13D3 to only whoever is taking the current turn would work better. however, i'm not quite sure that another "turn" performed by the entity -- such as periodic damage/healing or an auto-expiring status -- wouldn't be able to intercede and still cause problems by clearing the variables too early. these quasi-turns can get pretty high priority, so i lack the confidence to rule out that they might happen between a monster's FC 05/02/03/etc. check and whatever the monster eventually uses as its counter, particularly if there are other IF tests in between.

as of recent days, i've shifted in another direction with when to clear the variables: the start of Function C2/35E3, and only for the entity in question. also, the FC 01 and FC 04 variables won't need explicit clearing, because they are overwritten in this function any time the entity is hit with anything -- which is why, outside of PB, they don't suffer from bugs like FC 05/02/03 did.

i'm more confident doing the patch here, because this is where Square themselves writes the variables, and because i don't have to worry about the interceding turn issue described above. with the FC 02/03/05 variables no longer being stale in my envisioned fix, their omni-counter bugs go bye-bye.

the one shortcoming for the C2/35E3 approach that's coming to mind is if this family of FC commands are used in the first part of the monster script, their variables don't get updated, and will (still) suffer from a similar sort of bug. now, Colossus is the only monster i've found so far that does so. he uses FC 01, which (unlike FC 02/03/05) is normally unbugged in the second part of the script, but gets the omni-counter issue when used in the first half.

if nobody besides dummied monsters use the commands this way, maybe we just throw up our hands and say that Colossus' script was improperly written and never ironed out, instead of worrying about limitations.

then again, if you use the Master ZED and PB style fixes in conjunction with Hollywood Narrator's clever remedy (as well as a similar one for Guardian, and any custom monsters one might come up with), they have the advantage of letting these FC commands work better in the first half of scripts.

personally, i'm not nuts about the idea of rearranging scripts to accomodate a bugfix when the original script wasn't broken to begin with, but practicality will trump my ideas of what's "proper" here.

in the meanwhile, i'll comb through more scripts to see whether there are any more Colossus-like examples.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Imzogelmo » Wed Nov 07, 2012 9:16 pm

I'm not nuts about re-arranging scripts to accommodate bugfixes either, but still give kudos to Hollywood Narrator for use of the custom monster variables for saving the state of a FC 05's condition to carry it over to the next condition. When I made my FC conditional patch*, it was my imagination that those monster variable were great for saving conditional states that you later intend to check for again--because either the condition may elapse, or maybe you just don't want to run the same multi-conditional check several times.

As for the proposal, I think it's best to fix a potential issue even if it only can occur in a dummied-out monster. My theory is that then engine and the game should be independent, so ironing out the bugs of the engine to make any possible game work is a goal. Thus the whole notion of "bugs seen only via hacking." Of course that opens up a huge gray area as to what is a bug, but that really doesn't matter, as it's the end user who ultimately decides whether to apply the patch or not.


*What my FC conditional patch does is give a NOT equivalent of each original FC condition, by setting the top bit of the second byte. This, along with the facts that two consecutive FC conditions essentially form an AND, and the fact learned from logic that NOT(NOT(A) AND NOT(B)) = A OR B, makes a clumsy but workable way to OR condition together. Of course sometimes you need a variable to keep track of all that.
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 658
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

Re: Pandora's Box

Postby Assassin » Wed Nov 07, 2012 10:29 pm

i don't think he's storing any states in custom variables; he just rearranged the existing script instructions. i should've linked to his original post, where he has the changed lines bolded, rather than a quote of it:
http://slickproductions.org/forum/index ... 5#msg17315

this reordering works because we no longer have to worry about both of Vargas' FC 05s being executed in one instance; either the "If VAR000 has all the following bit cleared: 0" or the "If VAR000 has all the following bit set: 0" passes, but not both at a given time.

i have the inclination to support dummied monsters too, but at the same time want to avoid running down the rat hole of trying to support commands in a certain section of the script where they might not have intended to be used (aside from a fleeting case). if we view FC 01-05 as reactions to being hit a certain way, then they're arguably undefined (or have a different meaning *) when used in a script section that's executed on intervals rather than in response to hits. then again, if available measures can make them behave in the first script half more closely to how they do in the second half, it's probably worth taking these measures..

* by different meaning, i intend that because "if current hit has property X" doesn't really apply here, they become "if most recent hit has property X". and the question becomes whether property X should be regarded as persisting until: the next hit on the monster, OR we've processed the first instance of a hit with Property X. i initially favored the latter, and probably still do, which my proposed C2/35E3 patch would not fulfill. but i can make an argument for the former.

whoa, FC conditional. that takes me waay back. i remember "if this party's a rockin', don't come a knockin'" or something similar being used in reference to Floaters and possible Quake use.
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Imzogelmo » Wed Nov 07, 2012 11:21 pm

*accidental double post deleted*
Last edited by Imzogelmo on Wed Nov 07, 2012 11:35 pm, edited 1 time in total.
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 658
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

Re: Pandora's Box

Postby Imzogelmo » Wed Nov 07, 2012 11:34 pm

Assassin wrote:i don't think he's storing any states in custom variables; he just rearranged the existing script instructions. i should've linked to his original post, where he has the changed lines bolded, rather than a quote of it:
http://slickproductions.org/forum/index ... 5#msg17315

this reordering works because we no longer have to worry about both of Vargas' FC 05s being executed in one instance; either the "If VAR000 has all the following bit cleared: 0" or the "If VAR000 has all the following bit set: 0" passes, but not both at a given time.


I should've paid closer attention. :|

Assassin wrote:i have the inclination to support dummied monsters too, but at the same time want to avoid running down the rat hole of trying to support commands in a certain section of the script where they might not have intended to be used (aside from a fleeting case). if we view FC 01-05 as reactions to being hit a certain way, then they're arguably undefined (or have a different meaning *) when used in a script section that's executed on intervals rather than in response to hits. then again, if available measures can make them behave in the first script half more closely to how they do in the second half, it's probably worth taking these measures..

* by different meaning, i intend that because "if current hit has property X" doesn't really apply here, they become "if most recent hit has property X". and the question becomes whether property X should be regarded as persisting until: the next hit on the monster, OR we've processed the first instance of a hit with Property X. i initially favored the latter, and probably still do, which my proposed C2/35E3 patch would not fulfill. but i can make an argument for the former.


I realize that the regular and the counter-attack parts work a bit differently, maybe not well enough to articulate the differences, but yeah. I kinda see what you're saying about some commands maybe being intended for use in one and not the other, although the FC commands under discussion now are pretty far from that concern. The difference in their actual meaning stems not from what they represent, but how the two sections function differently. One is a loop that goes forever (subject to ATB refill times and as such gets interrupted), and the other is a series of queries that operates on a first-come, first-served basis and gets checked outside the normal flow of time (not sure exactly how often they get checked, but to say it's always in response to an attack is a bit over-simplifying, IMO). Honestly, the hashing out the finer points of difference deserves its own thread.

Assassin wrote:whoa, FC conditional. that takes me waay back. i remember "if this party's a rockin', don't come a knockin'" or something similar being used in reference to Floaters and possible Quake use.


Yeah, that was my first (and still most ambitious) patch. Did it by hand, on paper, over several days, while working the graveyard shift. Amazing that it all fit in the space I had. But oh! The branches!!! Make them stop!
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 658
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

Re: Pandora's Box

Postby Assassin » Thu Nov 08, 2012 11:05 am

Imzogelmo wrote:I realize that the regular and the counter-attack parts work a bit differently, maybe not well enough to articulate the differences, but yeah. I kinda see what you're saying about some commands maybe being intended for use in one and not the other, although the FC commands under discussion now are pretty far from that concern. The difference in their actual meaning stems not from what they represent, but how the two sections function differently. One is a loop that goes forever (subject to ATB refill times and as such gets interrupted), and the other is a series of queries that operates on a first-come, first-served basis and gets checked outside the normal flow of time (not sure exactly how often they get checked, but to say it's always in response to an attack is a bit over-simplifying, IMO). Honestly, the hashing out the finer points of difference deserves its own thread.


for this part: "but to say it's always in response to an attack is a bit over-simplifying, IMO" , are you saying there are times it can happen when not in response to an attack, or there are times an attack happens and it doesn't respond, or both?

anyway, because FC 01-05 used in the first part of the script don't have an immediate trigger like they do when used in the second half, it's debatable (in my mind) whether their condition's expiration should be immediate.. or if they should be interpreted as a more loose "If last hit on entity has Property X" that doesn't get updated until the next hit. as mentioned in my last post, i still favor the former a little, but can see argument for the latter.

a twist that shows why this is complex: suppose a monster with an "FC 01 CommandX" in both the second and first parts of its script. if we're granting that using this command in the first half is valid, and we already know using it in the second half is valid, then what about both halves? if we don't view such a script as pure unacceptable nonsense, then the question becomes how should it behave? in one patch scenario, when CommandX is used on the monster, FC 01 in the counterattack section triggers first (i assume all the time, but can't be 100% sure), and the variables get cleared, so FC 01 in the main section will not pass. in another patch scenario, FC 01 in the counterattack section triggers, then FC 01 in the main section will pass, and continue to trigger until the next hit on the monster (i.e. as long as the most recent hit was CommandX).

which one is right, i cannot say. it's a hypothetical, yes, but being able to fight a dummied monster is also a bit of a hypothetical.

Colossus is the only monster to use FC 01-04 in the first half of a script. i haven't come close to ruling out all the FC 05 instances yet, as there are so very many.

interesting backstory on FC Conditional. but i can't find it on your website; where'd it go?!
User avatar
Assassin
Moderator
Moderator
 
Posts: 1190
Joined: Tue Sep 14, 2004 5:10 am

Re: Pandora's Box

Postby Imzogelmo » Thu Nov 08, 2012 12:22 pm

Assassin wrote:for this part: "but to say it's always in response to an attack is a bit over-simplifying, IMO" , are you saying there are times it can happen when not in response to an attack, or there are times an attack happens and it doesn't respond, or both?


It's been a long time, but I seem to recall attacks happening that didn't evoke a response (where they should have). I know you can move a script to an address above 8000h in its bank and the counter-attack portion will never trigger. I wouldn't be surprised to see the other but can't remember any instances of it. I know that counter-attacks have a separate queue, but whether all attacks are capable of evoking a response (and whether that can occur any time or only in specific windows) is a question that I don't consider settled.

Assassin wrote:anyway, because FC 01-05 used in the first part of the script don't have an immediate trigger like they do when used in the second half, it's debatable (in my mind) whether their condition's expiration should be immediate.. or if they should be interpreted as a more loose "If last hit on entity has Property X" that doesn't get updated until the next hit. as mentioned in my last post, i still favor the former a little, but can see argument for the latter.


I favor the latter, for the flexibility. My thinking is that I may want to have some condition that stays true until the monster is attacked again. Say you hit the monster with some checked-for command, then just sit there and do nothing, and the script is written with one of these FC 01's in there. My thought is that it should continue doing that same section of the script on each pass until you hit it with a different command.

In your hypothetical scenario where both sections have the same FC 01, I would say that I still favor the latter, where one triggers immediately and the other continues to trigger each pass until a different command is used on the monster. The thing of it is, I'm not sure which one takes precedence and occurs first--intuition says it is the counter, but intuition is not always right, so it needs investigation.

All that being said, I champion consistency above all else. The same effect I am describing above can be simulated through variables, so having it "just work" that way is not entirely necessary. I can see an argument for the FC 01-05 commands being counterattack only as well. I think it all boils down to whether their description should be "last attack" or "currently counterattacked attack" in nature.

Assassin wrote:interesting backstory on FC Conditional. but i can't find it on your website; where'd it go?!

I commented it out. I think it's still in the source, and the file exists on the site, so I can get it for you if you're a collector. Nobody has requested it, though. :(
User avatar
Imzogelmo
Veteran
Veteran
 
Posts: 658
Joined: Wed Sep 08, 2004 4:07 pm
Location: On the spirtual plane

PreviousNext

Return to ROM Hacking and Emulation

Who is online

Users browsing this forum: No registered users and 1 guest

cron