Some things about the move-with-leader AI (Ai1 0x0D) I figured out and discussed with @Pikmin1211
First, how it works:
Ai1 #13 asmc [0803F51D]([00000000]) goto 1 if [0203AA8B] == 1 asmc [0803F72D]([00000000]) goto start label 1 chai ai1 = 0, ai2 = 0 goto start
FE8U:0803F51C(+1)checks whether the active unit’s leader exists and setsFE8U:0203AA8Bto 1 if not; Otherwise it will “simulate” the leader’s Ai to determine which unit will be their next target (if any) (the target unit id is stored atFE8U:0203AA8A(by unit id here I mean the “allegiance id” or whatever of the unit, not character id)).
FE8U:0803F72C(+1)checks whetherFE8U:0203AA8Ais set and refers to a valid unit, and try to make an offensive action targetting that unit. If it fails, then it will uhh try to target a unit that is in the same general direction? (FE8U:0803F6B8, it compares the diffence of positions between active and target + active and other and only returns true if both components of the differences are of the same sign?), and if that fails then it will try to move towards that unit.So a unit with “move with leader” ai1 will only start doing anything once their leader can target an enemy unit (not necessarily after doing so), at which point they will target that specific unit themselves (or move towards them while attacking other things too perhaps if they can’t reach). They will switch to ai 0, 0 (Action in range/pursue) if their leader dies.
(The script part comes from DOC/AiDump.txt at master · StanHash/DOC · GitHub).
(I’m pretty sure most of that was already known but I find it’s never bad to check things yourself).
The one interesting thing that we found out by digging a bit more (as pik was having unexpected ai behaviours) is that FE8U:0203AA8B is only ever set by that function (that is, when the unit’s leader is dead), and never cleared.
This means that if you have two groups of move-with-leader units, assuming group 1 units move before group 2 units, if the leader of group 1 is dead, then group 1 units will have their ai script set FE8U:0203AA8B as expected and will therefore change their ai to 0, 0 accordingly, but that value will carry over to group 2 ai and those units will also have their ai changed to 0, 0! Which is not good (as group 2 leader is still fine).
In addition to that, that value at FE8U:0203AA8B is also (probably) set by various other parts of the ai, including some thieving logic, which means that just bringing a thief as reinforcement may also break your move-with-leader AIs (that also happened to pik).
And since the issue is of a value within the Ai data not being cleared properly, this means that the behaviour of those units will be normal after a RAM clear (reset into load suspend), further confirming this as being a good old bug.
I made a quick fix for that if other people are interested (it makes it clear the problematic byte when entering the function at FE8U:0803F51C:
It hasn’t been tested thoroughly but according to pik it works.