minerAI.plist and max_cargo

[Okti]

Hi,

In my latest OXP, I used parts of minerAI.Plist from the resources. Although the ship had a maximum 5 tones of cargo space they eated literally hundreds of astroids and never got cargo full message.

I don't know if it is bug in oolite or in AI.

[Eric Walch]

Hi,

In my latest OXP, I used parts of minerAI.Plist from the resources. Although the ship had a maximum 5 tones of cargo space they eated literally hundreds of astroids and never got cargo full message.

I don't know if it is bug in oolite or in AI.

With AI problems/testing it is always advisable to switch on reportAIMessages. You can do it by targeting the ship and set it or very explicit include it in the shipSpawned() event of the ship script. The last is very useful for ships added out of reach of the player. I suspect the message is coming but you miss it, or you use scripted cargo, that does not has a content by default.

[Okti]

I think most of the AI problems are not realized if they are not used in an OXP. If I did not used parts of the minerAI in my OXP no one would realized if it worked or not. I will try to identify which messages are received during the next week end.

Unfortunately the documentation in wiki does not say outcome of the messages for performCollect. So I used most of the other replies as splinter scoped.

[Eric Walch]

Unfortunately the documentation in wiki does not say outcome of the messages for performCollect. So I used most of the other replies as splinter scoped.

There was no documentation because performCollect does not generates messages except a FRUSTRATED message. The messages CARGO_SCOOPED and HOLD_FULL are always generated when colliding with cargo, even in combat and has nothing to do with performCollect itself. Although collect mode is the most likely moment of happening.

But, the message CARGO_SCOOPED was nowhere mentioned on the wiki AI page, so I added it now under performCollect, as that will be the first place to look for.

[Okti]

I think the problem is on the AI.

Code: Select all

	"COLLECT_STUFF" =
	{
		ENTER = (performCollect);
		FRUSTRATED = ("setStateTo: LOOK_FOR_SPLINTERS");
		"CARGO_SCOOPED" = ("setStateTo: LOOK_FOR_SPLINTERS");
		"HOLD_FULL" = ("setStateTo: DOCK_WITH_STATION");
		"TARGET_LOST" = ("setStateTo: LOOK_FOR_SPLINTERS");
		"COLLISION" = ("setStateTo: LOOK_FOR_SPLINTERS");
		ATTACKED = (setTargetToPrimaryAggressor, groupAttackTarget, broadcastDistressMessage, "setStateTo: FLEE");
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
	};

It does not effect a normal miner. COLLECT_STUFF Always receives a TARGET_LOST message and state changes to LOOK_FOR_SPLINTERS and CARGO_SCOOPED is not called at all. I am not sure if TARGET_LOST message has a higher priority or not.

I tried to add CARGO_SCOOPED handler to LOOK_FOR_SPLINTERS state, but it seems not to be fired every time accourding to the log.

[Eric Walch]

COLLECT_STUFF Always receives a TARGET_LOST message and state changes to LOOK_FOR_SPLINTERS and CARGO_SCOOPED is not called at all. I am not sure if TARGET_LOST message has a higher priority or not.

I tried to add CARGO_SCOOPED handler to LOOK_FOR_SPLINTERS state, but it seems not to be fired every time accourding to the log.

TARGET_LOST is a reactToMessage that is handled immediately. The others are normal ones, handled in the next update. Than the AI is already in the LOOK_FOR_SPLINTERS state. But by logging you should see the CARGO_SCOOPED the message, even when the current state is not using it.

I must admit that the "TARGET_LOST" message is not very script friendly for collecting but it is a general message linked to the primary target. For other scripts the immediate reaction is useful. I remember the CARGO_SCOOPED message sometimes coming after 3 state switches in the pirateAI, so you must add it to all states were it can be read.
And remember that the normal messages are not executed in the order of generation. They can be executed in any random order. So on a full hold there is no rule which of the following two comes first: CARGO_SCOOPED or HOLD_FULL.

Only in cases of scripted cargo the CARGO_SCOOPED is not send when there is no commodity set for the cargo. But that are special cases you probably don't have.

[Okti]

Hi Eric,

Sory to be a pain in the neck, I just tried to find a way to get the CARGO_SCOOPED event but I discovered it is not fired every time visually a splinter is scooped.

The temp link to the OXP is Here

But it is fun to watch the miner and receive the events. I think the cargo scooped event occurs only 1 in 8.

The debug mode is on in the oxp. So if you can say what I'm doing wrong It will be appreciated.

Okti

[Okti]

I think I found the problem, I had ore processor OXP intalled at the same time and splinters generated by this OXP are CARGO_SCRIPTED_ITEM's. So CARGO_SCOOPED message is not created for them. After Uninstalling this OXP I started to get the messages.

[Eric Walch]

I think I found the problem, I had ore processor OXP intalled at the same time and splinters generated by this OXP are CARGO_SCRIPTED_ITEM's. So CARGO_SCOOPED message is not created for them. After Uninstalling this OXP I started to get the messages.

Ore Processor should be no problem. Only scripted cargo without any content is ignored. With Ore processor the script detects that the splinter is scooped by a npc ship and than immediately sets the cargo to minerals for the splinter. That way the splinter, scooped by a npc, is not lost, but stored in the cargo room. It was programmed that way to make sure the same splinters are released again after destroying the ship.

I just double checked:

The window on the left shows the miner, that on the right the splinter. (I make the shot with TAF at 0.06x). The window in the middle shows the AI state of the miner in more detail. The splinter was just scooped, the generated messages are still pending, but clearly the CARGO_SCOOPED is among them. I also noticed there is a TARGET_LOST pending message. Here I was wrong as I thought TARGET_LOST would be a reactToMessage. I checked it with the code, for scooping it becomes a normal message.

As far as I can see are CARGO_SCOOPED messages only lost when more that one splinter is scooped between two updated. But the messages were never designed to keep track of any individual message, only to signal the AI that cargo was scooped.

[Okti]

Thanks Eric,

Combining AI with JS and also adding ship.scoopedOther, to the ship script, I solved the problem.

What Happens according to my findings is TARGET_LOST message is the first message, Followed by a CARGO_SCOOPED event. I actuall looked at the source code for oolite, and found the part that handles this situation, there is a supress target lost like something but it seems it does not supress target lost message.

For scripted Cargo, first ship.scoopedOther event handler is called and than A Target_Lost message is received by the current state of the AI. So my solution in the AI is below

Code: Select all

	"LOOK_FOR_SPLINTERS" =
	{
		ENTER = ();
		"TARGET_FOUND" = (setTargetToFoundTarget, "setStateTo: COLLECT_STUFF");
		"NOTHING_FOUND" = ("setStateTo: LOOK_FOR_ROCKS");
		"HOLD_FULL" = ("setStateTo: PREPARE_FOR_COLLECTION");
		"NO_CARGO_BAY" = ("setStateTo: PREPARE_FOR_COLLECTION"); 
		ATTACKED = (setTargetToPrimaryAggressor, groupAttackTarget, broadcastDistressMessage, "setStateTo: FLEE");
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
		"QUIT" = ("commsMessageByUnpiloted: Cargo Full Miner returning.","setStateTo: PREPARE_FOR_COLLECTION");
		UPDATE = (scanForRandomLoot);
	};
	"COLLECT_STUFF" =
	{
		ENTER = ("sendScriptMessage: informState1 COLLECT_STUF","dropMessages: TARGET_LOST",performCollect);
		FRUSTRATED = ("setStateTo: LOOK_FOR_SPLINTERS");
		"CARGO_SCOOPED" = ("sendScriptMessage: informState1 CARGO_SCOOPED");
		"HOLD_FULL" = ("setStateTo: PREPARE_FOR_COLLECTION");
		"TARGET_LOST" = ("sendScriptMessage: informState1 TARGET_LOST");
		"COLLISION" = ("sendScriptMessage: informState1 COLLISION");
		ATTACKED = (setTargetToPrimaryAggressor, groupAttackTarget, broadcastDistressMessage, "setStateTo: FLEE");
		"INCOMING_MISSILE" = (fightOrFleeMissile, "setStateTo: FLEE");
		"LOOKFORSPLINTERS" = ("setStateTo: LOOK_FOR_SPLINTERS");
		"QUIT" = ("commsMessageByUnpiloted: Cargo Full Miner returning.","setStateTo: PREPARE_FOR_COLLECTION");
		UPDATE = ();
	};

And JS

Code: Select all

this.informState1 = function(message)
{	 
	this.lastMessage = message;
	if (message == "TARGET_LOST")
	{
		this.cTimer = new Timer(this, this.doActions, 5);	
		this.TargetLosts +=1;
		}
	else if (message == "CARGO_SCOOPED")
	{
		this.cTimer.delete;
		this.informState();
		this.ship.sendAIMessage("LOOKFORSPLINTERS");
	}
	else if (message == "COLLECT_STUF")
	{
		this.lastMessage="";
	}
}
this.doActions = function()
{
	if (this.lastMessage == "TARGET_LOST")
	{
		this.ship.sendAIMessage("LOOKFORSPLINTERS");
	} else if (this.lastMessage == "COLLISION")
	{
		this.ship.sendAIMessage("LOOKFORSPLINTERS");
	}

}
this.shipScoopedOther = function(whom)
{
	this.informState();
}

informState is the actual part that handles what to do with the scooped cargo.

Thanks for the help

[Eric Walch]

What Happens according to my findings is TARGET_LOST message is the first message, Followed by a CARGO_SCOOPED event. I actuall looked at the source code for oolite, and found the part that handles this situation, there is a supress target lost like something but it seems it does not supress target lost message.

The suppressTargetLost you found in the code, is an 'empty' function in shipEntity, but does something in playerEntity. So, it is there only for the player. But, don't rely on the message order. When there are two or more pending messages, any of them can be processed first. And as you now did, the easiest way of understanding AI is by looking into the source

[Okti]

What Happens according to my findings is TARGET_LOST message is the first message, Followed by a CARGO_SCOOPED event. I actuall looked at the source code for oolite, and found the part that handles this situation, there is a supress target lost like something but it seems it does not supress target lost message.

The suppressTargetLost you found in the code, is an 'empty' function in shipEntity, but does something in playerEntity. So, it is there only for the player. But, don't rely on the message order. When there are two or more pending messages, any of them can be processed first. And as you now did, the easiest way of understanding AI is by looking into the source

Any way it seems to be working to my requirements now. Thanks for the help. Probably I will release it later tonight. And I also added A rock Breaker pod, which only breaks the rocks and the others can collect the splinters. Because 5 of them were going after the same splinter and colliding most of the time