Old AI bugs

JensAyton · Post by **JensAyton** » Wed Oct 10, 2007 9:11 pm

Eric Walch wrote:
While testing the dockingAI.plist I put a lot off commsmessages in it for debugging purposes. One was in the enter part of the second state. This message showed op in the startupscreen os Oolite 1.65. I don't know why this AI was run on startup?

Once again, I ask that you report bugs in the bug tracker as per the bug report guidelines.

AIs run during the startup demo screens because the game is already running there. Why? Only Giles knows, but probably because the ship display is done using the standard gameplay mechanism. If you start a new game, you actually just enter the game world that’s already running. If you load a new game, it’s torn down and recreated.

JensAyton · Post by **JensAyton** » Wed Oct 10, 2007 9:13 pm

Arexack_Heretic wrote:
saw a cobra3 trader hanging around close to the sttion a few days ago, thought this was odd and checked it's AIstate. It appeared to be stuck in the STANDOFF state.
It did not make a move, the cause may have been collision avoidance. which IIRC Ahruman has recently improved. (or was that fixed in next version?)

I haven’t touched collision avoidance. There was a problem with collision detection, which is a simulation issue, not an AI issue.

Arexack_Heretic wrote:
In the same session I also noticed that the player-entity also had dockingAI.plist as it's AI.(in Eagis) This may have something to do with it being run when a game is loaded.

The player always has dockingAI.plist. The docking computer (not insta-dock) works by transferring the player to AI control.

Frame · Post by **Frame** » Thu Oct 11, 2007 8:44 pm

Ahruman wrote:
The player always has dockingAI.plist. The docking computer (not insta-dock) works by transferring the player to AI control.

Disturbing....

Post by **Eric Walch** » Thu Nov 22, 2007 10:41 pm

Shuttles are not landing anymore.

Yesterday I followed a shuttle to the planet surface. (with oolite 1.69.1) Here I expected to see it land. But it didn't. Just above the surface it turned an flew upwards for at least 20 000 meters. Looking with the debugging tool I saw if was flying in the waypointAI.plist. Strange as this is only mend to take evasive movements. Somehow it was trying to avoid collision with the surface. (But that makes it hart to land, or not?)

I created a whole bunch of shuttles and all did the same. Flying to the surface, 20000 meters up and than down again. And up again. A kind op loop. This should not happen. It must have worked, but somewhere maybe better collision pre-warnings were added resulting in this avoiding behavior. Behavior could also be dependent on planet radius. (I saw this behavior with one of 6 100 km).

Now it flies on a course to the planet where it checks till the end if it has a free flight path. This check gives the problem but is actually only necessary around the station to avoid local traffic. So I have a proposition for Improvement. I added a check for "AEGIS_LEAVING_DOCKING_RANGE". This check comes up when the ship is on 70-80% of the distance to the surface. From hereon no checking, just flying straight forward. There are two tests for landing. "DESIRED_RANGE_ACHIEVED" will be visible on 50 meters from the collision radius and "APPROACH_SURFACE" when he is at about 2000 meters from the surface. In the old Ai it just disappeared with a "LandOnPlanet", but I added a routine were it turns upward before disappearing. It looks better like a landing.

My proposal for: fallingShuttleAI.plist

Code: Select all

{
    "FLY_HOME" = {
		ENTER = (setCourseToPlanet, checkCourseToDestination);
		"COURSE_OK" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"WAYPOINT_SET" = ("setAITo: gotoWaypointAI.plist");
		"APPROACHING_SURFACE" = ("setStateTo: LANDING");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: LANDING");
		"AEGIS_LEAVING_DOCKING_RANGE" = ("setStateTo: APPROACH");
        ATTACKED = (setTargetToPrimaryAggressor, broadcastDistressMessage); 
        "INCOMING_MISSILE" = (fireECM); 
		UPDATE = (setCourseToPlanet, checkCourseToDestination, "pauseAI: 10.0");
		EXIT = ();
	}; 
    "APPROACH" = {
		ENTER = (setCourseToPlanet, "setSpeedFactorTo: 0.7", performFlyToRangeFromDestination);
		"APPROACHING_SURFACE" = ("setStateTo: LANDING");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: LANDING");
        ATTACKED = (setTargetToPrimaryAggressor, broadcastDistressMessage); 
        "INCOMING_MISSILE" = (fireECM, "setSpeedFactorTo: 1.0"); 
		UPDATE = ();
		EXIT = ();
	}; 
    "LANDING" = {
		ENTER = ("setSpeedFactorTo: 0.0", setTargetToSystemStation, setDestinationToTarget, performFaceDestination);
	        "FACING_DESTINATION" = (landOnPlanet); 
		UPDATE = ();
		EXIT = ();
	}; 
    GLOBAL = {ENTER = ("setSpeedFactorTo: 0.25", "setStateTo: FLY_HOME"); EXIT = (); UPDATE = (); }; 
}

I'll also put in on Berlios

There was also an jump to an nonexisting FLEE state in the AI. I cerrected this also in my proposal.

Post by **Eric Walch** » Mon Jul 07, 2008 12:03 pm

Trying something, I found a bug in the "route1patrolAI.plist. It has a state "OUTBOUND_LOOT". It only gets there when a missile is fired. I suspected that the commands "setAITo: interceptAI.plist", "setStateTo: OUTBOUND_LOOT" should be switched. To test I put AI debugging on and shot a missile. The result was quit different than expected and left the police idle hanging around. I just list the relevant AI lines below and the AI dump.

What is happening. On an incoming missile the line "INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, groupAttackTarget is executed. The remainder of the line is skipped because it now gets the priarity message "GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist");.
Than it continues with the remainder of the old line "setAITo: interceptAI.plist", "setStateTo: OUTBOUND_LOOT");

Result is that it sets the AI into an interceptAI.plist but than does the same again. There is now an interceptAI upon an other interceptAI. When I cloak, the target get lost and it does an exitAI. However it does not end in the original AI but in the first interceptAI. That one is only programmed to attack the found target. There is none so it will never get a "TARGET_LOST" message and it will stay attacking an non existing target.

The AI does get a RESTARTED message but the AI is not programmed to do anything with it. The most general solution is to add the line RESTARTED = (exitAI); to the interceptAI so is will automatically fall back one level deeper. I saw a similar problem with escorts that also could set 2 times in an interceptAI. Adding this line will probably benefit other AI with similar bugs.

The real fix for this route1patrol would be the completely remove the "setAITo: interceptAI.plist" after the groupAttackTarget command because it will always execute the GROUP_ATTACK_TARGET in response. And I think that "setStateTo: OUTBOUND_LOOT" should be placed before groupAttackTarget because this is intended as a new return state after an AI restart.

Code: Select all

    "HEAD_FOR_WITCHPOINT" = {
        "INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, groupAttackTarget, "setAITo: interceptAI.plist", "setStateTo: OUTBOUND_LOOT"); 
        ATTACKED = (setTargetToPrimaryAggressor, groupAttackTarget); 
        "GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist"); 
	};

Code: Select all

[AI reactToMessage:] (AI.m:353): AI route1patrolAI.plist for Revolutionary Guard 186 in state 'HEAD_FOR_WITCHPOINT' receives message 'INCOMING_MISSILE'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action fightOrFleeMissile
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setTargetToPrimaryAggressor
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action deployEscorts
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action groupAttackTarget
 [AI reactToMessage:] (AI.m:353): AI route1patrolAI.plist for Revolutionary Guard 186 in state 'HEAD_FOR_WITCHPOINT' receives message 'GROUP_ATTACK_TARGET'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setTargetToFoundTarget
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setAITo: interceptAI.plist
[AI preserveCurrentStateMachine] (AI.m:188): Pushing state machine for <AI 0x50f2870>{"route1patrolAI.plist" in state: "HEAD_FOR_WITCHPOINT" for Revolutionary Guard 186}
[AI reactToMessage:] (AI.m:353): AI route1patrolAI.plist for Revolutionary Guard 186 in state 'GLOBAL' receives message 'ENTER'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action switchLightsOn
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setStateTo: ATTACK_SHIP
[AI reactToMessage:] (AI.m:353): AI route1patrolAI.plist for Revolutionary Guard 186 in state 'GLOBAL' receives message 'EXIT'
[AI reactToMessage:] (AI.m:353): AI route1patrolAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'ENTER'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action performAttack
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setAITo: interceptAI.plist
[AI preserveCurrentStateMachine] (AI.m:188): Pushing state machine for <AI 0x50f2870>{"interceptAI.plist" in state: "ATTACK_SHIP" for Revolutionary Guard 186}
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'GLOBAL' receives message 'ENTER'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action switchLightsOn
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setStateTo: ATTACK_SHIP
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'GLOBAL' receives message 'EXIT'
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'ENTER'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action performAttack
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action setStateTo: OUTBOUND_LOOT
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'ECM'
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'OFFENCE_COMMITTED'
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'TARGET_CLOAKED'
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'TARGET_LOST'
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action switchLightsOff
[AI takeAction:] (AI.m:411): Revolutionary Guard 186 to take action exitAI
[AI restorePreviousStateMachine] (AI.m:201): Popping previous state machine for <AI 0x50f2870>{"interceptAI.plist" in state: "ATTACK_SHIP" for Revolutionary Guard 186}
[AI reactToMessage:] (AI.m:353): AI interceptAI.plist for Revolutionary Guard 186 in state 'ATTACK_SHIP' receives message 'RESTARTED'

I removed a few lines from the log that didn't matter. AI scripting stays difficult and the new debugging tool is very useful for this because this bug must been there, unnoticed, for ages.

Frame · Post by **Frame** » Mon Jul 07, 2008 1:37 pm

Arexack_Heretic wrote:
saw a cobra3 trader hanging around close to the sttion a few days ago, thought this was odd and checked it's AIstate. It appeared to be stuck in the STANDOFF state.
It did not make a move, the cause may have been collision avoidance. which IIRC Ahruman has recently improved. (or was that fixed in next version?)

I often see ships hanging around the stations, especially the Viper interceptors.. one allways launches and stops just before buoy.

same deal goes for Scavengers, they launch, scoop, and then become shuttles... and sometimes they just get stuck..

Same deal for marooned Escorts... that have not found a new business... these however tend to make endless loops...

Post by **Eric Walch** » Mon Jul 07, 2008 8:44 pm

I just filed bug 014160 at berlios:

The route1patrolAI has two bugs. One bug was already present in oolite 1.55 and the second was added with version 1.65 Bugs are with the four messages about "INCOMING_MISSILE". Below are the corrected lines. Already in version 1.55 the "INCOMING_MISSILE" message triggered direct setting the AI into an interceptAI. but it was also set to an interceptAI over the "GROUP_ATTACK_TARGET". This resulted two interceptAI's on the stack and on return the AI hang in the first AI. "setAITo: interceptAI.plist" must be removed from the four "INCOMING_MISSILE" messages.

Second bug was introduced with version 1.65. Here the gotoWaypointAI was introduced into this AI. This resulted that a "RESTARTED" message didn't know from with of the two AI's it returned. Giles removed the "RESTARTED" message and added a "setStateTo: INBOUND_LOOT" at the end of the incoming missile message. Bu at that moment the AI is already in the interceptAI and that has no "INBOUND_LOOT" state. Result was that it since then never executed these states. (Police can only find escape-pods). What Giles mend to do was setting the return state to "INBOUND_LOOT". It does work when it is switched with the groupAttackTarget command. I tested it. When sending a missile, it switches to INBOUND_LOOT, only executes the ENTER message and that goes into an interceptAI over the GROUP_ATTACK_TARGET message. When the target gets lost, it returns nicely into the INBOUND_LOOT state as mend and did happen before 1.65.

The four "INCOMING_MISSILE" lines should be replaced by:

Code: Select all

    "HEAD_FOR_PLANET" = {
        "INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, "setStateTo: INBOUND_LOOT", groupAttackTarget); 
        "GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist"); 
	}; 
    "HEAD_FOR_WITCHPOINT" = {
        "INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, "setStateTo: OUTBOUND_LOOT", groupAttackTarget); 
        "GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist"); 
	}; 
    "OUTBOUND_LOOT" = {
        ENTER = ("setSpeedTo: 0.0", performIdle); 
        "GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist"); 
        "INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, groupAttackTarget); 
    }; 
    "INBOUND_LOOT" = {
        ENTER = ("setSpeedTo: 0.0", performIdle); 
        "GROUP_ATTACK_TARGET" = (setTargetToFoundTarget, "setAITo: interceptAI.plist"); 
        "INCOMING_MISSILE" = (fightOrFleeMissile, setTargetToPrimaryAggressor, deployEscorts, groupAttackTarget); 
    };

Something similar is valid for route2patrolAI. This one is still the old one from 1.55. Here only the "setAITo: interceptAI.plist" commands must be removed from all "INCOMING_MISSILE" messages.

An other issue is why only scanning for loot after reaction on a missile attack? And not after all groupAttacks? But in that case the long "pauseAI: 10" in the update of INBOUND_LOOT should be removed. Its a once only state so time is no real issue and the ship should return as soon as possible to its police business. Police will only find escape-pods but hunters will find all spilled cargo.

dmipet · Post by **dmipet** » Sat Jul 19, 2008 4:38 pm

Not sure if it fits here. If not, I deeply regret the offtopic. I tried to create an account at Berlios site to post it as a bug, but my IE warned me that site's security certificate is not authorized, so I aborted.
I am using Oolite 1.71.2 and Dredger OXP 1.1. I noticed a strange behavior of a dredger I tried to dock. I approached it and asked for automated docking (shift-C, AFAIR). It continued to move in circles (why do they always do when I'm around, by the way? to avoid collision?) and asked me to wait. I grew impatient in several seconds, aborted the sequence (C) and docked it manually (not very easy when it is turning, but I managed). After I traded and left, the captain continued asking me to wait for docking approach (his view over the large ship from the small cabin is not very good, I think, so he probably simply missed my tiny vintage Python :) ).
More interesting, I left the system almost immediately, and when I returned to normal space - the dredger was there, near the beacon. It finally told me that it is ready to accept me. And indeed it stood still until I entered it for the second time - 60 seconds and 5 light years away from the first.
So, what does this "abort automatic docking" (C) actually does? Anyway except for giving me back controls (these are blocked after autodocking is activated).

Frame · Post by **Frame** » Sat Jul 19, 2008 5:58 pm

dmipet wrote:
Not sure if it fits here. If not, I deeply regret the offtopic. I tried to create an account at Berlios site to post it as a bug, but my IE warned me that site's security certificate is not authorized, so I aborted.
I am using Oolite 1.71.2 and Dredger OXP 1.1. I noticed a strange behavior of a dredger I tried to dock. I approached it and asked for automated docking (shift-C, AFAIR). It continued to move in circles (why do they always do when I'm around, by the way? to avoid collision?) and asked me to wait. I grew impatient in several seconds, aborted the sequence (C) and docked it manually (not very easy when it is turning, but I managed). After I traded and left, the captain continued asking me to wait for docking approach (his view over the large ship from the small cabin is not very good, I think, so he probably simply missed my tiny vintage Python ).
More interesting, I left the system almost immediately, and when I returned to normal space - the dredger was there, near the beacon. It finally told me that it is ready to accept me. And indeed it stood still until I entered it for the second time - 60 seconds and 5 light years away from the first.
So, what does this "abort automatic docking" (C) actually does? Anyway except for giving me back controls (these are blocked after autodocking is activated).

just ignore the warning EI gives you on that particular site, its completely safe, but a good thing you did not proceed when you did not feel secure..

regarding the rest, i think that is OXP bugs, as not as much bugs in Oolite itself.

Could some moderater split this and move it into the OXP section.. i do not have a clue to who wrote the dredger...

Post by **Eric Walch** » Sat Jul 19, 2008 8:39 pm

dmipet wrote:
I am using Oolite 1.71.2 and Dredger OXP 1.1. I noticed a strange behavior of a dredger I tried to dock. I approached it and asked for automated docking (shift-C, AFAIR). It continued to move in circles (why do they always do when I'm around, by the way? to avoid collision?) and asked me to wait. I grew impatient in several seconds, aborted the sequence (C) and docked it manually (not very easy when it is turning, but I managed).

Hello to this board dmipet.
I am currently in the middle in the scripting of a followup of the dredger. Graphics are from Sabre, AI scripting is mine. Some things you write are logic, others are curious.

I'm not sure were you encountered it, but I noticed a bug that allows it to appear in interstellar space. However, the ship has no fuel, so it should never be able to jump galaxy unless it entered a wormhole. But npc traffic is explicit disallowed, so there should never launch a trader that could create such a wormhole in front of the ship.

To the docking itself. It is very impossible to do it manually. I'm surprised anybody managed it. In my opinion it is a bug of oolite that any ship that asks for docking can stop a carrier automatic. (But that is an other issue)

This version tries not to collide with anything, so manual docking in the front should be very difficult when it is flying. When you initiate automatic docking, the system tells him to do a perform stop. But in my AI I made the mistake to also send a perform idle. This overrules the previous command and idle does almost the same as stop except stopping itself.

>So, what does this "abort automatic docking" (C) actually does?

When you cancel "automatic docking", the ship receives a message that "docking is complete". Not all carriers are programmed to react on that message, but the dredger will, and continue its old course. The only easy way of docking is to wait until an other ship asks for docking.

When you need a quick fix, replace both "performIdle" occasions with "performStop" in the only AI file there is. This week a got permission from Sabre to also use his other dredger models. I add a similar script to those ships and add some extra's do it. I'll announce the upload then in a Dredgers topic.

dmipet · Post by **dmipet** » Mon Jul 21, 2008 4:39 pm

A very friendly board indeed, and a very nice game. I have seen its predecessor on ZX Spectrum and looked for the modern port for a long time. Glad I found it

As for the dredger I have little to add to my previous post. As I approached it, I noticed that it's moving in large vertical circles. I mean "vertical" to the vessel itself - it constantly moved forward simultaneously turning down. So I asked for autodocking, perceiving manual docking as very difficult. It answered positively (don't remember the exact phrase), but didn't stop or change it's strange circling. I waited for a few seconds (it asked me once again to wait), than grew impatient, cancelled the autodocking, positioned my ship on the imaginable radius outside its circle and waited for the dredger to begin ascending loop approaching me. At that moment I started to approach it too, so that when we met I was exactly at its front landing port. In a moment it swallowed me whole. Not an easy docking, as I said, more difficult than docking with the station, but quite possible.
After I left, it continued asking me to wait. I need it only to refuel, so I paid little attention to its pledges and hyperjumped. I did never seen this or any other dredger entering the hyperjump or a wormhole, or exiting one - neither when I arrived. There simply was another dredger there that was still asking me to wait for docking. I believe that when I jumped, the new dredger was created as part of system's population, and docking sequence was somehow passed to it. Do not ask me please how it is possible, as I am no programmer. All I know is that after several more communication lines the second dredger informed me that docking is allowed and then stood still. I docked it just out of curiosity – indeed this time it was much easier

If I can help with any details, please tell me.

Post by **Disembodied** » Mon Jul 21, 2008 4:58 pm

Eric's just posted a link to an interim update of the Dredger which might help – see here for the link.

Post by **Eric Walch** » Wed Dec 24, 2008 9:11 am

I was working at a variation of the pitateAI.plist. According to the code it is intended that all pirates make a hyper jump after their hold is full. It is just that i never witnessed such thing in all those years. I added pirates and cargo around me an waited. When their hold was full they didn't jump.
With an AI trace I noticed that when the hold was full, it first got an NOTHING_FOUND message and after that the HOLD_FULL message. However, the NOTHING_FOUND message already made that the AI switched to the next state. And that state got the HOLD_FULL message. And that state was not programmed to react on that message:

When I followed the trace I was surprised that the CARGO_SCOOPED message even arrived another state later.

Code: Select all

  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'COLLECT_LOOT' receives message 'ENTER'
  Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setSpeedTo: 0.0
  Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action performIdle
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action scanForLoot   <--- here scanning
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action pauseAI: 5.0
Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'COLLECT_LOOT' receives message 'TARGET_FOUND'
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setTargetToFoundTarget
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setStateTo: LOOT
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'COLLECT_LOOT' receives message 'EXIT'
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'LOOT' receives message 'ENTER'
  Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action performCollect  <--- start collection
Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'LOOT' receives message 'TARGET_LOST'  <--- here scooped up, hold full.
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setStateTo: COLLECT_LOOT
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'LOOT' receives message 'EXIT'
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'COLLECT_LOOT' receives message 'ENTER'
  Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setSpeedTo: 0.0
  Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action performIdle
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action scanForLoot
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action pauseAI: 5.0
Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'COLLECT_LOOT' receives message 'NOTHING_FOUND'
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setStateTo: CONSIDER_DOCKING
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'COLLECT_LOOT' receives message 'EXIT'
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'CONSIDER_DOCKING' receives message 'ENTER'
  Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action checkForMotherStation
Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'CONSIDER_DOCKING' receives message 'HOLD_FULL'  <-- only here the reaction
Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'CONSIDER_DOCKING' receives message 'CARGO_SCOOPED'  <-- only here the reaction
Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'CONSIDER_DOCKING' receives message 'NOTHING_FOUND'
Oolite [ai.takeAction] -[AI takeAction:] (AI.m:411): Krait 256 to take action setStateTo: LURK
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'CONSIDER_DOCKING' receives message 'EXIT'
  Oolite [ai.message.receive] -[AI reactToMessage:] (AI.m:353): AI pirateAI.plist for Krait 256 in state 'LURK' receives message 'ENTER'

So I added the HOLD_FULL message also to the next state of the AI. In my case the TRAVEL_TO_LURK_AREA state. This way it (almost) worked as it should and all the pirate with full hold made its hyperspace jump.

Problem with pirates is that some are defined with a cargo bay of zero capacity. (like the oolite-asp) These ships will immediately generate a HOLD_FULL and jump. Yesterday I tries some time to rewrite the pirateAI so ships with cargo bay jump when their hold was full and others with a zero cargo bay stayed in the system. But how I tried, I could not get a good Working AI.

Problem is that the checkForHoldFull only generates a message when the hold is full. So when using it in a state, that state must also have a command that lets it proceed to an other state. And this results in receiving the HOLD_FULL message in an other state. I only could come up with something when using dices. But that looks as a bad approach.

What we actually need is that the checkForHoldFull generates 3 different messages: HOLD_FULL, STILL_HUNGRY and [NO_CARGO_BAY[/i]. This way you can write code that ensures that it always proceeds to an next state when using the
command checkForHoldFull.

**Having pirates without cargo bay is kind of a bug itself.**
The main purpose of pirates is attack traders for their cargo and scoop it. According the pirateAI they should turn into normal traders when their hold is full. With a full hold there is no reason to attack other ships. Currently that part of the pirateAI does not work as it was written. Maybe it worked in the old days, but messages like TARGET_LOST spoil this now. But those messages are also needed.

When we want to have pirates that only attack and have no bay, we should rewrite the code a bit so the HOLD_FULL is only generated with ships that can carry cargo. That way it becomes much easier to write an AI that let only traders that actually scooped their bay full become traders.

Post by **Eric Walch** » Wed Dec 24, 2008 4:05 pm

Okay, I now got the improved pirateAI working. I droped it in an OXP for easier use by others: New pirateAI

Just drop this oxp in your AddOn folder and Oolite will switch to this one for all pirates. It is just mend for testing before putting it in Oolite itself. It will already work with 1.72 and older because I used a dice to get out of one state. For Oolite 1.73 this dice should be removed. More info in the file itself.

The other thing that this new AI does is better anticipation on a cloaked attack.

Post by **Eric Walch** » Thu Dec 25, 2008 4:26 pm

On testing the scooping by the pirates I noticed that not all barrels give a "CARGO_SCOOPED" message. And those barrels were also not added to the cargo. So even the krait had to scoop many barrels before the hold of two was full. When I spawned an "oolite-barrel" it was never added to the cargo. I know scripted cargo is also not added and only some special cargo with additional definitions from CargoWreck.oxp were added.

I repeated it with the player itself. "oolite-barrels" were not added to the cargo, they were empty.

This is a bug that was already present in Oolite 1.65. Only cargo added by the popuplator had content, legacy_addShips added cargo was empty. Therefor I had only scripted cargo in my older oolite versions.
This bug was fixed in 1.71 In this version all barrels with RANDOM_CARGO had also a content when added with a scrip command. Therefor I removed a lot of the scripted cargo from ups. I now see that all those pods are empty again. Pods with CARGO_CARRIED do have content when added by script.