Failed scoop - expected behaviour not happening??

[Capt. Murphy]

Firstly not sure if this is a bug or not.

What is supposed to happen if a scoop attempt on an escape pod fails?

E.g. you get the Scooping message, but haven't got the message yet about what you have scooped, but then jink around so the scoop doesn't actually happen. Looking at the source it appears the intention is that the pod should continue on it's way as if nothing has happened. In practise it ends up dead in space with no thrust. The AI is still correctly set to homeAI.plist, and in state HEAD_TO_PLANET.

Also on a related note the beacon in escape pod locator tracks it's associated pod by targeting it. Beacon removal is triggered via a this.shipTargetLost handler in the beacon's shipscript on the assumption that this will fire when the pod is destroyed, scooped or lands successfully.

But again in the case of a failed scoop this handler is fired at the point you get the first Scooping message, so a failed scoop results in a pod with no beacon. Should this not fire in this scenario when the pod is actually removed from the universe and added to the players manifest?

I've tested this under rev 4673, and with pods manually spawned with system.addShips. The target lost behaviour has been noted with pods spawned by the game engine in the normal fashion.

Edit - the dead in space behaviour confirmed for a pod spawned by the game engine in normal play.

Another edit - I can see in the source that other entities losing target seems to be deliberate. I think I can work around this in script if changing it would break other stuff.

[Kaks]

Another edit - I can see in the source that other entities losing target seems to be deliberate. I think I can work around this in script if changing it would break other stuff.

It is deliberate. That fixed bug 12344:
http://developer.berlios.de/bugs/?func= ... up_id=3577

The standard AIs do seem to reacquire failed scooped targets afterwards without too many problems.

[Capt. Murphy]

Thanks Kaks,

Having thought about it a little more I guessed it for something like that.

What about the pods being 'dead in space' after a failed scoop which is a seperate issue. I'm posting from my phone right now but I think I saw a section in shipentity.m that looked like it was intended to reset them back to their normal in flight state. If so it is not working quite right.

[Capt. Murphy]

A little more info for you re 'dead in space' pods.

Comparing entity dumps for just before and just after a failed scoop the problem appears to lie with the AI 'Next think time' being set to a point an hour into the future, along with a desired speed of 0. Everything else looks 'normal' but the escape capsule isn't producing any log entries when reportAImessages = true (as the next UPDATE is so far ahead).

After an hour the pod duly sprung into life and carried on it's way, and started reportingAImessages.

I see that nullAI.plist has an update pause of 3600 seconds, but the EXIT message should set it to 1 second. That doesn't appear to be happening. Does homeAI.plist need some RESTARTED lines to reset the update time?

Just before scooping.

04:52:15.859 [dumpState]: State for <ShipEntity 0x8c8f9d8>{"Escape capsule" position: (-1.14187e+006, -244473, 911563) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT}:
04:52:15.859 [dumpState.entity]: Universal ID: 269
04:52:15.859 [dumpState.entity]: Scan class: CLASS_CARGO
04:52:15.859 [dumpState.entity]: Status: STATUS_IN_FLIGHT
04:52:15.859 [dumpState.entity]: Position: (-1.14187e+006, -244473, 911563)
04:52:15.859 [dumpState.entity]: Orientation: (-0.0594143 - 0.721541i - 0.094511j - 0.683313k)
04:52:15.859 [dumpState.entity]: Distance travelled: 339.064
04:52:15.859 [dumpState.entity]: Energy: 25 of 25
04:52:15.859 [dumpState.entity]: Mass: 618.881
04:52:15.859 [dumpState.entity]: Owner: self
04:52:15.859 [dumpState.entity]: Flags: isShip, hasMoved, hasRotated, isSunlit
04:52:15.859 [dumpState.shipEntity]: Type: griff_normalmapped_escape-capsule
04:52:15.859 [dumpState.shipEntity]: Name: Escape capsule
04:52:15.859 [dumpState.shipEntity]: Display Name: Escape capsule
04:52:15.859 [dumpState.shipEntity]: Roles: <OORoleSet 0xba8ab50>{escape-capsule griffescape}
04:52:15.859 [dumpState.shipEntity]: Primary role: escape-capsule
04:52:15.859 [dumpState.shipEntity]: Script: <OOJSScript 0x77812d8>{"oolite-default-ship-script" version 1.75.4}
04:52:15.859 [dumpState.shipEntity]: Subentity count: 3
04:52:15.859 [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
04:52:15.859 [dumpState.shipEntity]: Destination: (-1.14195e+006, -244541, 911574)
04:52:15.859 [dumpState.shipEntity]: Other destination: (0, 0, 0)
04:52:15.859 [dumpState.shipEntity]: Waypoint count: 0
04:52:15.859 [dumpState.shipEntity]: Desired speed: 21.4075
04:52:15.859 [dumpState.shipEntity]: Thrust: 5
04:52:15.859 [dumpState.shipEntity]: Fuel: 0
04:52:15.859 [dumpState.shipEntity]: Fuel accumulator: 1
04:52:15.859 [dumpState.shipEntity]: Missile count: 0
04:52:15.859 [dumpState.shipEntity.ai]: AI:
04:52:15.859 [dumpState.ai]: State machine name: homeAI.plist
04:52:15.859 [dumpState.ai]: Current state: NEW_WAYPOINT
04:52:15.859 [dumpState.ai]: Next think time: 678.023
04:52:15.859 [dumpState.ai]: Next think interval: 0.125
04:52:15.859 [dumpState.shipEntity]: Jink position: (0, 0, 0)
04:52:15.859 [dumpState.shipEntity]: Frustration: 1.875
04:52:15.859 [dumpState.shipEntity]: Success factor: 101.043
04:52:15.859 [dumpState.shipEntity]: Shots fired: 0
04:52:15.859 [dumpState.shipEntity]: Time since shot: 111.953
04:52:15.859 [dumpState.shipEntity]: Spawn time: 665.96 (11.969 seconds ago)
04:52:15.859 [dumpState.shipEntity]: Hull temperature: 60
04:52:15.859 [dumpState.shipEntity]: Heat insulation: 1
04:52:15.859 [dumpState.shipEntity]: Flags: isFrangible, canFragment

Just after failed scoop attempt

04:53:16.234 [dumpState]: State for <ShipEntity 0x8c8f9d8>{"Escape capsule" position: (-1.131e+006, -251105, 909057) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT}:
04:53:16.234 [dumpState.entity]: Universal ID: 269
04:53:16.234 [dumpState.entity]: Scan class: CLASS_CARGO
04:53:16.234 [dumpState.entity]: Status: STATUS_IN_FLIGHT
04:53:16.234 [dumpState.entity]: Position: (-1.131e+006, -251105, 909057)
04:53:16.234 [dumpState.entity]: Orientation: (0.144073 - 0.666503i - 0.297351j - 0.66828k)
04:53:16.234 [dumpState.entity]: Distance travelled: 2135.88
04:53:16.234 [dumpState.entity]: Energy: 25 of 25
04:53:16.234 [dumpState.entity]: Mass: 618.881
04:53:16.234 [dumpState.entity]: Owner: self
04:53:16.234 [dumpState.entity]: Flags: isShip, hasMoved, isSunlit, collisionTestFilter
04:53:16.234 [dumpState.shipEntity]: Type: griff_normalmapped_escape-capsule
04:53:16.234 [dumpState.shipEntity]: Name: Escape capsule
04:53:16.234 [dumpState.shipEntity]: Display Name: Escape capsule
04:53:16.234 [dumpState.shipEntity]: Roles: <OORoleSet 0xba8ab50>{escape-capsule griffescape}
04:53:16.234 [dumpState.shipEntity]: Primary role: escape-capsule
04:53:16.234 [dumpState.shipEntity]: Script: <OOJSScript 0x77812d8>{"oolite-default-ship-script" version 1.75.4}
04:53:16.234 [dumpState.shipEntity]: Subentity count: 3
04:53:16.234 [dumpState.shipEntity]: Behaviour: BEHAVIOUR_IDLE
04:53:16.234 [dumpState.shipEntity]: Target: <PlayerEntity 0x76eb090>{"Cobra Mark III" position: (-1.13141e+006, -250758, 909156) scanClass: CLASS_PLAYER status: STATUS_IN_FLIGHT}
04:53:16.234 [dumpState.shipEntity]: Destination: (-1.1398e+006, -244398, 911323)
04:53:16.234 [dumpState.shipEntity]: Other destination: (0, 0, 0)
04:53:16.234 [dumpState.shipEntity]: Waypoint count: 0
04:53:16.234 [dumpState.shipEntity]: Desired speed: 0
04:53:16.234 [dumpState.shipEntity]: Thrust: 5
04:53:16.234 [dumpState.shipEntity]: Fuel: 0
04:53:16.234 [dumpState.shipEntity]: Fuel accumulator: 1
04:53:16.234 [dumpState.shipEntity]: Missile count: 0
04:53:16.234 [dumpState.shipEntity.ai]: AI:
04:53:16.234 [dumpState.ai]: State machine name: homeAI.plist
04:53:16.234 [dumpState.ai]: Current state: HEAD_FOR_PLANET
04:53:16.234 [dumpState.ai]: Next think time: 4313.04
04:53:16.234 [dumpState.ai]: Next think interval: 0.125
04:53:16.234 [dumpState.shipEntity]: Jink position: (0, 0, 0)
04:53:16.234 [dumpState.shipEntity]: Frustration: 0
04:53:16.234 [dumpState.shipEntity]: Success factor: 1.1053e+006
04:53:16.234 [dumpState.shipEntity]: Shots fired: 0
04:53:16.234 [dumpState.shipEntity]: Time since shot: 172.328
04:53:16.234 [dumpState.shipEntity]: Spawn time: 665.96 (72.344 seconds ago)
04:53:16.234 [dumpState.shipEntity]: Hull temperature: 60
04:53:16.234 [dumpState.shipEntity]: Heat insulation: 1
04:53:16.234 [dumpState.shipEntity]: Flags: isFrangible, canFragment

I've spotted two bits of code in shipentity.m that look like they deal with the situation of a failed scoop. One explicitly sets the thrust back to original and one doesn't.

Code: Select all

if (lost_contact)       // 250m range for tractor beam
                        {
                                // escaped tractor beam
                                [self setStatus:STATUS_IN_FLIGHT];
                                behaviour = BEHAVIOUR_IDLE;
                                [self setThrust:[self maxThrust]]; // restore old thrust.
                                frustration = 0.0;
                                [self setOwner:self];
                                [shipAI exitStateMachineWithMessage:nil];       // exit nullAI.plist
                                return;

Code: Select all

// double check scooped behaviour
        //
        if ([self status] == STATUS_BEING_SCOOPED)
        {
                //if we are being tractored, but we have no owner, then we have a problem
                if (behaviour != BEHAVIOUR_TRACTORED  || [self owner] == nil || [self owner] == self || [self owner] == NO_TARGET)
                {
                        // escaped tractor beam
                        [self setStatus:STATUS_IN_FLIGHT];      // should correct 'uncollidable objects' bug
                        behaviour = BEHAVIOUR_IDLE;
                        frustration = 0.0;
                        [self setOwner:self];
                        [shipAI exitStateMachineWithMessage:nil];  // Escapepods and others should continue their old AI here.
                }
        }

Edit to add - adding some RESTARTED lines to homeAI.plist seems to fix the problem.

Code: Select all

{
	GLOBAL =
	{
		ENTER = ("setSpeedFactorTo: 1.0", "setStateTo: HEAD_FOR_PLANET");
	};
	"HEAD_FOR_PLANET" =
	{
		ENTER = (setCourseToPlanet, checkCourseToDestination);
		RESTARTED = ("pauseAI: 10.0");
		"NOTHING_FOUND" = ("setStateTo: MOVE_AWAY");
		"WAYPOINT_SET" = ("setStateTo: NEW_WAYPOINT");
		"COURSE_OK" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"DESIRED_RANGE_ACHIEVED" = (landOnPlanet);
		"APPROACHING_SURFACE" = (landOnPlanet);
		UPDATE = (setCourseToPlanet, checkCourseToDestination, "pauseAI: 10.0");
	};
	"MOVE_AWAY" =
	{
		ENTER = (setDestinationToCurrentLocation, "setDesiredRangeTo: 7000.0", checkCourseToDestination);
		RESTARTED = ("pauseAI: 10.0");
		"COURSE_OK" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"DESIRED_RANGE_ACHIEVED" = ("setAITo: dumbAI.plist");
		UPDATE = (checkCourseToDestination, "pauseAI: 10.0");
	};
	"NEW_WAYPOINT" =
	{
		ENTER = ("setSpeedFactorTo: 1.0", setDesiredRangeForWaypoint, checkCourseToDestination, "pauseAI: 2.0");
		RESTARTED = ("pauseAI: 10.0");
		"WAYPOINT_SET" = ("setStateTo: NEW_WAYPOINT");
		"COURSE_OK" = ("setStateTo: HEAD_FOR_PLANET");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: HEAD_FOR_PLANET");
                "UPDATE" = ("setSpeedFactorTo: 1.0", setDesiredRangeForWaypoint, checkCourseToDestination, "pauseAI: 2.0");
	};
}

[Wildeblood]

Also on a related note the beacon in escape pod locator tracks it's associated pod by targeting it. Beacon removal is triggered via a this.shipTargetLost handler in the beacon's shipscript on the assumption that this will fire when the pod is destroyed, scooped or lands successfully.

But again in the case of a failed scoop this handler is fired at the point you get the first Scooping message, so a failed scoop results in a pod with no beacon. Should this not fire in this scenario when the pod is actually removed from the universe and added to the players manifest?

Re: Escape Pod Locator, I think you should be using shipTargetDestroyed, rather than shipTargetLost.

shipTargetDestroyed

The shipTargetDestroyed handler is called when the target gets destroyed. target contains the destroyed target entity. This command is always preceded by the shipTargetLost handler.

Target "lost" only means that it has dropped off the scanner, not necessarily that it will soon be destroyed (?).

[Capt. Murphy]

Re: Escape Pod Locator, I think you should be using shipTargetDestroyed, rather than shipTargetLost.

shipTargetDestroyed doesn't fire on scooping a pod. I doubt it fires if a pod lands on the planet either. shipTargetLost does fire in all these instances, just a little early in the scoop process. But I can work around that no problem.

[Capt. Murphy]

I see that nullAI.plist has an update pause of 3600 seconds, but the EXIT message should set it to 1 second. That doesn't appear to be happening. Does homeAI.plist need some RESTARTED lines to reset the update time?

Last little bit of this bug report.....

In AI.m

Code: Select all

- (void) exitStateMachineWithMessage:(NSString *)message
{
        if ([aiStack count] != 0)
        {
                [self restorePreviousStateMachine];
                if (message == nil)  message = @"RESTARTED";
                [self reactToMessage:message context:@"suspended AI restart"];
        }
}

Does it need a line to send the EXIT message?

eg.

Code: Select all

- (void) exitStateMachineWithMessage:(NSString *)message
{
        [self reactToMessage:@"EXIT" context:@"changing state"];
        if ([aiStack count] != 0)
        {
                [self restorePreviousStateMachine];
                if (message == nil)  message = @"RESTARTED";
                [self reactToMessage:message context:@"suspended AI restart"];
        }
}

[Eric Walch]

I see that nullAI.plist has an update pause of 3600 seconds, but the EXIT message should set it to 1 second. That doesn't appear to be happening. Does homeAI.plist need some RESTARTED lines to reset the update time?
Does it need a line to send the EXIT message?

The addition of the EXIT message in nullAI.plist was my work. I also noticed that coming back from a nullAI, the pause should be strongly shortened or some AI started with a very long 'hibernation' . Apparently I thrusted this to always work and did not test it explicitly.

It seems that the EXIT message is only send when switching states and not when switching AIs. I think it also should do it there like your code:

Code: Select all

- (void) exitStateMachineWithMessage:(NSString *)message
{
        [self reactToMessage:@"EXIT" context:@"changing state"];
        if ([aiStack count] != 0)
        {
                [self restorePreviousStateMachine];
                if (message == nil)  message = @"RESTARTED";
                [self reactToMessage:message context:@"suspended AI restart"];
        }
}

Its probably a very trivial change, but I don't want to add it before the NMSR.

[Capt. Murphy]

Fair enough Eric, I can imagine that would need some testing to ensure it doesn't break anything else and I see a hint in the SVN log that MNSR is just round the corner...

How about another update to homeAI.plist to include some RESTARTED lines. That also fixes the problem, and won't break anything else.

[Kaks]

Target "lost" only means that it has dropped off the scanner, not necessarily that it will soon be destroyed (?).

Aye! As well as when another ship starts scooping your target, other examples of target lost: ship flying beyond your scanner range, jumping to another system, docking to a station...

[Eric Walch]

How about another update to homeAI.plist to include some RESTARTED lines. That also fixes the problem, and won't break anything else.

Its not that critical, so that I rather leave it alone for the time being instead of adding a patch I would still remove later on. I think an AI should not have the need to be prepared for getting the next update only after an hour of game time. It should be the AI that did set it that high, that should bring it back to a normal value. And that means the NEXT message must be send under all conditions.