some more AI problems (still on 1.73.3)

Commander McLane · Post by **Commander McLane** » Wed Sep 23, 2009 2:30 pm

I was observing the following while still on 1.73.3, but it is probably helpful anyway:

Missiles sometimes have a weird behaviour, for instance not responding to ECM. One reason I found is a missile with interceptAI instead of missileAI:

Code: Select all

[dumpState]: State for <ShipEntity 0x1f8a600>{"Missile" ID: 390 position: (7137.45, 10218.7, 287552) scanClass: CLASS_MISSILE status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 390
  [dumpState.entity]: Scan class: CLASS_MISSILE
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (7137.45, 10218.7, 287552)
  [dumpState.entity]: Orientation: (-0.931215 + 0.0528909i - 0.246267j - 0.263425k)
  [dumpState.entity]: Distance travelled: 19176.4
  [dumpState.entity]: Energy: 5 of 5
  [dumpState.entity]: Mass: 113.906
  [dumpState.entity]: Owner: <ShipEntity 0x13c6b800>{"Trident Executive Shuttle" ID: 314 position: (8157.49, 10262.5, 282830) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}
  [dumpState.entity]: Flags: isShip, hasMoved, hasRotated, isSunlit, collisionTestFilter
  [dumpState.shipEntity]: Name: Missile
  [dumpState.shipEntity]: Display Name: Rakete
  [dumpState.shipEntity]: Roles: <OORoleSet 0x671830>{EQ_MISSILE missile oolite-missile}
  [dumpState.shipEntity]: Primary role: EQ_MISSILE
  [dumpState.shipEntity]: Script: <OOJSScript 0x11a07b90>{"oolite-default-ship-script" version 1.73.3}
  [dumpState.shipEntity]: Subentity count: 1
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_ATTACK_FLY_FROM_TARGET
  [dumpState.shipEntity]: Target: <PlayerEntity 0x1ce2a00>{"Imperial Courier" ID: 100 position: (7049.59, 10210.8, 288082) scanClass: CLASS_PLAYER status: STATUS_IN_FLIGHT}
  [dumpState.shipEntity]: Destination: (8422.9, 9926.04, 282534)
  [dumpState.shipEntity]: Other destination: (0, 0, 0)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 750
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: interceptAI.plist
    [dumpState.ai]: Current state: ATTACK_SHIP
    [dumpState.ai]: Next think time: 992.441
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 0
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 26.5202
  [dumpState.shipEntity]: Spawn time: 965.876 (26.5402 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: isFrangible, canFragment

Another odd thing is a missile having no target. Something must have gone wrong with inheriting the mother's target, probably related to the fact that it has no owner (although it could be that I killed him before I targeted the missile):

Code: Select all

[dumpState]: State for <ShipEntity 0x13d2c000>{"Nuclear Torpedo" ID: 415 position: (-1322.29, 4041.45, 176381) scanClass: CLASS_MISSILE status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 415
  [dumpState.entity]: Scan class: CLASS_MISSILE
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (-1322.29, 4041.45, 176381)
  [dumpState.entity]: Orientation: (0.543548 + 0.502555i + 0.466013j - 0.484588k)
  [dumpState.entity]: Distance travelled: 11330.4
  [dumpState.entity]: Energy: 10 of 10
  [dumpState.entity]: Mass: 113.906
  [dumpState.entity]: Flags: isShip, hasMoved, isSunlit, collisionTestFilter
  [dumpState.shipEntity]: Name: Nuclear Torpedo
  [dumpState.shipEntity]: Display Name: Nuclear Torpedo
  [dumpState.shipEntity]: Roles: <OORoleSet 0xe863d40>{EQ_NUKE_MISSILE missile}
  [dumpState.shipEntity]: Primary role: missile
  [dumpState.shipEntity]: Script: <OOJSScript 0xe86a520>{"oolite-default-ship-script" version 1.73.3}
  [dumpState.shipEntity]: Subentity count: 1
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_IDLE
  [dumpState.shipEntity]: Destination: (8364.72, 3191.37, 172574)
  [dumpState.shipEntity]: Other destination: (0, 0, 0)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 550
  [dumpState.shipEntity]: Fuel: 0
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 0
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: nukeAI.plist
    [dumpState.ai]: Current state: ATTACK_SHIP
    [dumpState.ai]: Next think time: 1279.61
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 3122.3
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 21.4853
  [dumpState.shipEntity]: Spawn time: 1257.81 (21.5 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: pitching_over, isFrangible, canFragment

And then again I met a sunskimming Boa with enteringTraderAI in state GO_TO_SKIM, which doesn't exist in that AI. It also had a stack depth of 0, so I wonder what's going wrong:

Code: Select all

[dumpState]: State for <ShipEntity 0x1dbc600>{"Boa" ID: 857 position: (1636.22, -21459.9, 9847.64) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}:
  [dumpState.entity]: Universal ID: 857
  [dumpState.entity]: Scan class: CLASS_NEUTRAL
  [dumpState.entity]: Status: STATUS_IN_FLIGHT
  [dumpState.entity]: Position: (1636.22, -21459.9, 9847.64)
  [dumpState.entity]: Orientation: (0.894454 - 0.39336i + 0.103092j + 0.185988k)
  [dumpState.entity]: Distance travelled: 35787.6
  [dumpState.entity]: Energy: 450 of 450
  [dumpState.entity]: Mass: 192444
  [dumpState.entity]: Owner: <ShipEntity 0x1dbc600>{"Boa" ID: 857 position: (1636.22, -21459.9, 9847.64) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}
  [dumpState.entity]: Flags: isShip, hasMoved, isSunlit, collisionTestFilter
  [dumpState.shipEntity]: Name: Boa
  [dumpState.shipEntity]: Display Name: Boa
  [dumpState.shipEntity]: Roles: <OORoleSet 0x128c0b80>{oolite-boa trader}
  [dumpState.shipEntity]: Primary role: trader
  [dumpState.shipEntity]: Script: <OOJSScript 0xf480980>{"oolite-default-ship-script" version 1.73.3}
  [dumpState.shipEntity]: Subentity count: 1
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Destination: (-418980, -863989, 856697)
  [dumpState.shipEntity]: Other destination: (-418980, -863989, 856697)
  [dumpState.shipEntity]: Waypoint count: 0
  [dumpState.shipEntity]: Desired speed: 240
  [dumpState.shipEntity]: Fuel: 38
  [dumpState.shipEntity]: Fuel accumulator: 1
  [dumpState.shipEntity]: Missile count: 4
  [dumpState.shipEntity.ai]: AI:
    [dumpState.ai]: State machine name: enteringTraderAI.plist
    [dumpState.ai]: Current state: GO_TO_SKIM
    [dumpState.ai]: Next think time: 2726.24
    [dumpState.ai]: Next think interval: 0.125
  [dumpState.shipEntity]: Frustration: 0
  [dumpState.shipEntity]: Success factor: 1.26647e+06
  [dumpState.shipEntity]: Shots fired: 0
  [dumpState.shipEntity]: Time since shot: 100174
  [dumpState.shipEntity]: Spawn time: 2545.74 (180.436 seconds ago)
  [dumpState.shipEntity]: Hull temperature: 60
  [dumpState.shipEntity]: Heat insulation: 1
  [dumpState.shipEntity]: Flags: isFrangible, canFragment

Post by **Eric Walch** » Wed Sep 23, 2009 2:54 pm

Missiles sometimes have a weird behaviour, for instance not responding to ECM. One reason I found is a missile with interceptAI instead of missileAI:

I think I had also seen it once but ignored it then. But just brainstorming: Currently the missiles are added the the group on launch. When the ship has escorts it comes also in the escort group. I must look in the code but when mom issues a deployEscort command, a random number of the escorts is put in interceptAI. I assume the problem arises here when deploying escorts with a missile in the air.

Edit:
This can be fixed by adding a check for being not-missile in deploy escorts. Looking at the code I see another bug because of this. When mom tries to dock its escorts when there is still a missile in the air, it will also give that missile a dockingAI. So that needs also a check. dockEscorts goes correct because that uses the escort array not the escort group.

Is there a reason missiles must be part of the ship group? Missiles were already put in the group with 1.65. But with the old group structure this had no side effects. I don't see were there is actually made use of missiles being part of the group.

Post by **Kaks** » Wed Sep 23, 2009 4:38 pm

Hmm, having the missiles in a specific group could still be useful to distinguish between friendly and enemy fire, so I wouldn't want to remove them from the launching ship's group...

Post by **Eric Walch** » Wed Sep 23, 2009 4:56 pm

And then again I met a sunskimming Boa with enteringTraderAI in state GO_TO_SKIM, which doesn't exist in that AI. It also had a stack depth of 0, so I wonder what's going wrong:

At far as I can see this is only cosmetic as it is flying the right AI. (route2SunSkimAI in this case). It just looks if it is remembering the wrong AI name. Same happens when the ship gets a route1TaderAI. What actually happens:

The ship starts with a exitingTraderAI after wormholing to the new system. When the player enters his system, he gets a "EXITED WITCHSPACE" message, immediately switches to enteringTraderAI and in the same update roles a dice and switches to a third AI.

When changing the GLOBAl state of enteringTraderAI into:

Code: Select all

	GLOBAL =
	{
		UPDATE = ("setStateTo: DECIDE_ROUTE");
	};

, the second AI change happens one update later. I just tested it: In that case it displays the correct AI name.
(But that does not fix the underlying problem of displaying the wrong name).

------

Kaks wrote:
Hmm, having the missiles in a specific group could still be useful to distinguish between friendly and enemy fire, so I wouldn't want to remove them from the launching ship's group...

In that case I add the ![escort isMissile] check and test is a bit before committing.

Post by **Eric Walch** » Wed Sep 23, 2009 5:28 pm

I looked into the code of setting the statemachine:

Code: Select all

- (void) setStateMachine:(NSString *) smName
{
	NSDictionary *newSM = [self loadStateMachine:smName];
	
	if (newSM)
	{
		currentState = @"GLOBAL";
		[self reactToMessage:@"ENTER"];
		
		// refresh stateMachineName
		[stateMachineName release];
		stateMachineName = [smName copy];
	}
}

Inside the routine it does a [self reactToMessage:@"ENTER"];. When that ENTER message switches again a the stateMachine, it is correctly switched and gets the right name, but than on continuing the main routine the old name is used as "stateMachineName". I would say that changing the order of commands into

Code: Select all

- (void) setStateMachine:(NSString *) smName
{
	NSDictionary *newSM = [self loadStateMachine:smName];
	
	if (newSM)
	{
		// refresh stateMachineName
		[stateMachineName release];
		stateMachineName = [smName copy];

		currentState = @"GLOBAL";
		[self reactToMessage:@"ENTER"];
	}
}

would fix this but I don't know if this is a save change. In the current state, changing states already in the ENTER of GLOBAL will store a wrong name but it still uses the right AI. So it is mainly a problem for scripts trying to read the ships AI. Behaviour itself is not affected.

JensAyton · Post by **JensAyton** » Wed Sep 23, 2009 7:24 pm

Kaks wrote:
Hmm, having the missiles in a specific group could still be useful to distinguish between friendly and enemy fire, so I wouldn't want to remove them from the launching ship's group...

Owner should be sufficient, surely?

Eric Walch wrote:
…but I don't know if this is a save change.

As far as I can see, that would only be a problem if something was relying on the wrong name being in use in ENTER, which seems pretty far-fetched.

Post by **Eric Walch** » Wed Sep 23, 2009 9:15 pm

Ahruman wrote:
Eric Walch wrote:
…but I don't know if this is a save change.
As far as I can see, that would only be a problem if something was relying on the wrong name being in use in ENTER, which seems pretty far-fetched.

I now played with the AI lines in a different order. Not only the name was now correct in the ship.AI property but also the occasionally wrong names in AI logging were gone. In the past there was always one logged name wrong when switching AI.

Post by **Eric Walch** » Wed Sep 23, 2009 9:38 pm

Ahruman wrote:
Kaks wrote:
Hmm, having the missiles in a specific group could still be useful to distinguish between friendly and enemy fire, so I wouldn't want to remove them from the launching ship's group...
Owner should be sufficient, surely?

The friendly fire check only looks at the group of the ship that fired the missile and not at the group of the missile itself. So it does not need the missile being part of the group to detect it was friendly fire. I can't find any other place in the code that might use a missile being part of a group. And any JS script can ask for the missiles owner and check the group of the owner when the script wants to know.

So to prevent any future surprises with it, it seems more safe to not place the missile in the group in the first place.

-------
That fixes two of McLanes examples for 1.74. The middle one is a clear AI bug. That was also in Oolites HardMissileAI.plist and a fixed version was already committed for 1.74.
TARGET_LOST can arrive when in CHECK_EXPLOSION. But it also can receive a GONE_BEYOND_RANGE when in CHECK_EXPLOSION state. Probably rare but possible when the player keeps hitting the ecm.

Looking intensively at the code I now realise it is a waste of energy when continue hitting ECM. the code hangs 5 seconds in CHECK_EXPLOSION before it can detect a new ECM signal. A second ECM within 5 sec is just a waist of energy!.

Post by **Kaks** » Wed Sep 23, 2009 10:21 pm

It all sounds good & a perfectly safe change!

Btw, this might be a bit premature, but so far, so good with the fore/aft shields bug. Thanks for squashing that one too!

Commander McLane · Post by **Commander McLane** » Thu Sep 24, 2009 5:15 am

Eric, there is another problem with the third example: Both times I met a trader in GO_TO_SKIM state, he still was close to the witchpoint. Which means he shouldn't have been in GO_TO_SKIM, but in HEAD_FOR_SUN. The GO_TO_SKIM state isn't meant for the long journey from witchpoint to sun, but should be only a very brief episode between HEAD_FOR_SUN and SKIM_SUN. If for some (yet unknown) reason a trader immediatly gets into GO_TO_SKIM when arriving at the witchpoint, something else is wrong.

The visible result for the player is that he can kill that trader without any attempt of defence, because there is no ATTACKED message in GO_TO_SKIM.

Therefore the bug isn't yet completely squashed, I'm afraid.

-------------------

For the second example: This means that nukeAI should be updated to match hardmissileAI, when 1.74 comes out?

Post by **Eric Walch** » Thu Sep 24, 2009 7:25 pm

Commander McLane wrote:
Therefore the bug isn't yet completely squashed, I'm afraid.

That one was not so straightforward as I thought. With AI logging it showed that I always got a DESIRED_RANGE_ACHIEVED shortly after a checkCourseTo destination. But DESIRED_RANGE_ACHIEVED is only generated when behaviour is behaviour_intercept or behaviour_fly_to/from_destination. The target instector always claims the ship is in performIdle when entering the wormhole. Somehow that tricked me as the old behaviour is simply put on stack when entering the wormhole. Than it is changed to performIdle, until the player follows him through the wormhole and the old behaviour to fly to target is restored from stack. And that restoring of behaviour immediately generates the DESIRED_RANGE_ACHIEVED. I would not even be surprised when this bug was already present in very old Oolite versions. Simply fixed now by adding a "performIdle" in the enteringTraderAI:

Code: Select all

	GLOBAL =
	{
		ENTER = (performIdle, "setStateTo: DECIDE_ROUTE");
	};

-------------------

For the second example: This means that nukeAI should be updated to match hardmissileAI, when 1.74 comes out?

I just uploaded a nukes.oxp (v 0.95) to the box. That one contains the original nuke missile and two others. Version 0.95 has this AI bug fixed. (Not yet available on the wiki) I just have to chat with cmd Wyvern if this one should replace his version or if he will upload a improved one himself. However no need to wait until 1.74 as that new version of nukes can be put in action immediately.

Cmdr Wyvern · Post by **Cmdr Wyvern** » Fri Sep 25, 2009 11:56 am

Eric Walch wrote:
I just have to chat with cmd Wyvern if this one should replace his version or if he will upload a improved one himself. However no need to wait until 1.74 as that new version of nukes can be put in action immediately.

No need for the chat, I approve.
I don't have a patent on it or anything, improve away.