bug in route1patrolAI

[Commander McLane]

Spotted a bug in route1patrolAI. Nothing dramatic, but it means that some of the police ships will return to the planet too early.

In the HEAD_FOR_WITCHPOINT state, in the INCOMING_MISSILE-part, there is a "setStateTo: INBOUND_LOOT", which of course has to be "setStateTo: OUTBOUND_LOOT".

And I would be delighted to know why a missile attack triggers a looting attempt at all. And why the looting attempt is only triggered by an incoming missile. Really don't understand that part.

[Eric Walch]

It's a copy and paste bug. In 1.65 it was okay. But I remember this special line had a bug that could lead to an idle cop after a missile attack. On repairing both seem to have ended up with the same code.

On the looting I don't get it either. I would have chosen to also loot after a normal attack. Problem is maybe that hunters and police use the same AI file.

Cops only find escape pods when scanning for loot. Hunters will also find cargo. In my opinion both should use separate AI files and police should always rescue ejected pilots after an attack.

[Commander McLane]

Okay, I understand why police and hunters would search for escape pods. But what on earth has an escape pod to do with a missile fired at said police or hunter? I really cannot imagine. And that's the point I am raising.

A police ship (if it has scoops) should look for an escape pod after a fight. Not when some pirate has aimed a missile at it. Where are the escape pods in that case? Just makes no sense to me at all.

[Commander McLane]

Suggestion: If I'm right with the 'after a fight'-part, then we need to put the respective OUTBOUND_LOOT- and INBOUND_LOOT-states at the point where the AI is after ending a fight. As the AI executes the fighting itself by "setAITo: interceptAI.plist", the RESTARTED-message would be the proper place, because that's where the AI gets restarted after returning from interceptAI. Or, alternatively, the ENTER-message, because that's the entry point if there is no RESTARTED, right? And it wouldn't do harm to scan for escape pods once at the endpoints of the route.

Or Aegidian didn't mean it that way. Probably he wanted the police to take care of escape pods even in the middle of a fight. Therefore he put the search for them into one of the messages that are to be expected during a fight, and went for INCOMING_MISSILE. Although that wouldn't work well, because during a fight the police doesn't have this AI, but interceptAI instead. Which means the OUTBOUND_LOOT or INBOUND_LOOT states are only ever triggered when the fight opens with a missile being fired on the police.

But even then, would it work at all? Immediatly after the "setStateTo: OUTBOUND/INBOUND-LOOT" follows a "groupAttackTarget", which invariably leads to "setAITo: interceptAI.plist". So what does the AI actually do? Go to state INBOUND/OUTBOUND_LOOT? Or execute the following "groupAttackTarget", recieve the GROUP_ATTACK_TARGET-message, and therefore leave the route1patrolAI (and with it the INBOUND/OUTBOUND_LOOT-state) altogether?

I have to confess that I still don't understand many aspects of AI-programming. But this one is particularly puzzling.

[Eric Walch]

But even then, would it work at all? Immediatly after the "setStateTo: OUTBOUND/INBOUND-LOOT" follows a "groupAttackTarget", which invariably leads to "setAITo: interceptAI.plist". ....

It does work as intended. But this is very complex scripting as this state contains two setAI's. On a simple RESTART it would not know from which subroutine it returned. Set state is only done to have a new return address for after the intercept. But I explained that already in the report of the original bug. (Here or at Berlios)

[Commander McLane]

Ah. Found the explanation here and two posts below.

Okay. I'll try to build from there.