Topic: Automatic action retargeting

[avalanche]

Some actions implicitly re-target if the previously selected target is no longer valid (such as dead) by the time it is executed.  Obviously Fight does this.  Do others?  Do spells?  Is the logic of when retargeting is performed known?

[chillyfeez]

I've pondered this before, but don't know exactly how it works.
Equally puzzling to me is how commands like fight always default to targeting the first monster, which is always represented by the highest bit out of all of the monsters currently on the battlefield... So "80" if there are eight monsters, but "40" if there are seven and "20" if there are six, etc.
As far as I know, any command that targets a single enemy will retarget if that enemy is unavailable to target at the time of execution. I think that "single target (defaults to enemy)" defaults to the first enemy, and "split enemy" defaults to the last. Also, "all" targeting needs to retarget if one of the targets originally targeted dies, so the spell animation doesn't hit the empty space.
To further confuse matters, I think when a monster's AI script doesn't specify a target ("target random character," for instance) it will auto retarget, but if the script does specify a target ("target Cecil"), it will not auto retarget.

[avalanche]

In my implementation, the battle with Golbez and his dragon using Disrupt goes badly if anyone is dead, because it's re-targeting Disrupt, killing everybody and ending the game instead of leaving Cecil alive.

So I'm following a bunch of assembly trying to figure how this works, and I have to just say this:  How many darn places does this game test the caster/target/action/subaction for allowance to do said action??  I swear I've seen the "disallow when swoon except when using these spells or items, disallow when stone except ... disallow when Hide or Jump" in several places.

Rant aside, I found what looks like the relevant assembly, but it's lengthy and convoluted and my eyes are really dried out now.  Need to break.  I wonder if this is one of the things where other people could benefit or if it's just my weird project :)

[chillyfeez]

Hey, I'd say if you found the assembly that actually controls the retargeting, post it. I don't know if anybody will have immediate use for it, but seeing how they did it might have come in really handy when I was making the limit break system for my hack, instead of comp!etely rewriting my own targeting system. Point being, it's sure to be helpful to someone, at some point.

[avalanche]

I'll hold off posting the assembly because I have a ton of half finished analysis notes in it.  For reference, the routine I am looking at is approx 03:AD67 through 03:B0AD.   By the time it's called, a partial AI sequence is available around $3659 or above, depending on the monster index.  By partial, I mean it is cut off at the next Chain Divider (FB) or a few others, I imagine FC,FE,FF.

Also interesting to point out that the caster's action, subaction, and target bits have already been set, based on that partial sequence, even though the sequence has not yet been executed.  For simple monsters, they'll already have C0 and a random target picked.  For AI with a target instruction, it will have run and set the target.  If the target failed, the partial sequence is modified to replace the main action with an E1 and store a zero for their target.  I think that is why the routine in question does not re-target.

[chillyfeez]

That's interesting. So, hypothetically, if there were a queue of eight monsters all ready to act, and say monster X was set by AI to attack Cecil specifically, but Cecil is killed by one of the other seven monsters before Monster X gets his turn, Monster X would retarget as long as the AI-reading routine had already done its thing. Is that right?

[avalanche]

No, I think that it operates on the partial sequence just in the moment it needs to run.  I'm still looking into it, so this is highly speculative.  When a monster's turn comes up, I think it reads from the sequence starting with where it left off last time up to the next Divider(FB), WaitForNextTurn(FE), or end marker(FF), possibly Chain End (FC) as well but I'm not sure about that one yet.  Then something looks it over to explicitly or implicitly target and set the target, action, subaction.  If the targeting fails, then it overwrites the action to do nothing.  Then it calls the assembly routine I mentioned where more target validation and possible re-targeting is performed.  But I think you're right that if the AI explicitly targets something then it won't retarget, because it sort of aborts before it even gets to the retargeting code.