Attacked while docking

[Eric Walch]

I have lately problems with ships attacking the station. The reason of this is the added ATTACK message in dockingAI.plist. But I would prefer a solution other than removing it again.

What's happening exactly: The docking ship has the station as target in its docking process. When attacked it sets target to the attacker and goes in an interceptAI. But sometimes the found target was for some reason nil and target is not changed and stays the station.

I see several routes to solve this but don't really know what is the best way.

I think it goes mainly wrong with groups. When a ship is attacked that is part of a group, the core code checks if it has escorts of if it has role pirate. In both cases all group members get an ATTACK message. This is independent of the AI. And this are the two situations were I noticed the problems till now. Working on pirate cove I now regularly noticed pirates attacking their station. When forcing an exitAI on them they fell back into a dockingAI what clearly showed they initiated their attack when busy with the docking procedure. Part of them is already docking while others are still fighting and receiving hits. I think this automated attack message is even send when both ships don't see each other. For 1.73 this will be better as the ships will get an other role on launch and the automated ATTACK message to group members is not send anymore.

Yesterday I saw this behaviour for the first time with an escorted ship. I was playing cataclism and was escorting the ambassador back to the main station. At the end I noticed he was in a dockingAI and both of its escorts were just hanging still in a ENTER_WORMHOLE state of the escortAI. Very strange as the mother just does a "dockEscorts" and nothing fancy like "wormholeEscorts"? Anyhow, one moment the embassador ship was still dockings and the next moment it was in an interceptAI, attacking the main station. Of course he didn't survive it as the police killed him for that.

An other situation were thing can go wrong now when ships target a friendly object and scan for hostiles. When found the get a "TARGET_FOUND" message. But the target can get destroyed before the next update were the setTargetToFoundTarget is used. Rare but it can happen. I had similar friendly fire incidents in the past with a hostile target just at scanner range. In that case my AI must have received also a TARGET_LOST that I didn't handle right.

-----
Several suggestions:
A) Remove the automated ATTACK messages. Do we really need this code or is it from a period before we had a groupAttack command and this code was just left in after the groupAttack was introduced?

B) currently it is:

Code: Select all

- (void) setTargetToFoundTarget
{
	if ([UNIVERSE entityForUniversalID:found_target])
		[self addTarget:[UNIVERSE entityForUniversalID:found_target]];
}

But the AI always assumes it has a target set and proceeds. Maybe this routine can use an else line where it sends a "TARGET_LOST" message. I don't know if this helps but I think it might help. It won't prevent entering an attack state but the target lost might put it back the next update. However, I also don't know if it can do harm with other situations.

With setTargetToPrimaryAggressor my mind is not so clear. When used while attacking it should not send a target lost message.

Code: Select all

- (void) setTargetToPrimaryAggressor
{
	if (![UNIVERSE entityForUniversalID:primaryAggressor])
		return;
        // further code deleted.

I think when it has no found target it should also send a "LOST_TARGET", but in this case only when the current target is not hostile.

[Screet]

I have lately problems with ships attacking the station.

I think it goes mainly wrong with groups. When a ship is attacked that is part of a group, the core code checks if it has escorts of if it has role pirate.

I can confirm those sightings. For me, it's typically police doing that. Sometimes a whole police fleet attacks the systems station, sometimes a single police ship. Therefore, probably it's a bit more than just pirates/escorts? It appears that thargoids fighting in the area of the station somehow "encourage" this behaviour, which could suggest that the ships did have a target and lost it before turning against their own station, as you wrote.

Anyway, there seems to have been many changes between 1.72.1 and .2 - I just finished a report because I do get annoyingly more crashes and another observation is that very often clean ships fight each other or me.

Screet

[Svengali]

I have lately problems with ships attacking the station. The reason of this is the added ATTACK message in dockingAI.plist. But I would prefer a solution other than removing it again.

I've seen the station attacks too - specially with escorts.

Anyway, there seems to have been many changes between 1.72.1 and .2 - I just finished a report because I do get annoyingly more crashes and another observation is that very often clean ships fight each other or me.

The clean ships are a oxp problem. It seems to be related to the method that is used to add these ships. When the auto_ai/AI/bounty/roles/scanClass declaration is not absolutely right and the wrong method is choosen the pirate ships don't get their bounty. The oxp has to be fixed.

[Eric Walch]

The clean ships are a oxp problem. It seems to be related to the method that is used to add these ships. When the auto_ai/AI/bounty/roles/scanClass declaration is not absolutely right and the wrong method is choosen the pirate ships don't get their bounty. The oxp has to be fixed.

I agree that this is a real oxp problem. Since my first ups release I already added copies of pirates with bounty set to the system to let them have a bounty. Now with all that JS stuff there are other ways to adding a bounty to pirates, but it means additional code after adding them. (see my deep_space_pirates were the pirate bounty is handled separately).

Best thing is a code change to let the auto_ai boolean also set bounty for pirates. That would force pirates to have a bounty unless the flag is deliberate set to auto_ai false.