AI problem after launch

[Commander McLane]

For a long time I have observed ships launching from the main station, turning around, and crashing into the station right away. Now I have investigated a little closer. My AIs for personalities.oxp (a modified hunter- and pirateAI) produce the same problem, if one of the personalities is launched, so I'm interested in a solution.

It turns out that the ships in question are in goToWaypointAI. There intended AIs have HEAD_FOR_WITCHPOINT as first state after GLOBAL, and this includes a checkCourseToDestination with alternative COURSE_OK or WAYPOINT_SET responses. The latter sets the AI to goToWaypointAI.

It seems that immediately upon launch either the buoy or the station itself are detected as an obstacle, therefore the AI receives the WAYPOINT_SET message and reacts accordingly. It turns around, flies back a little, and comes to a halt right in front of the station it just left. Now the goToWaypointAI is exited and the original AI restarted in state HEAD_FOR_WITCHPOINT. The coordinates are set and the ship starts to accelerate and turn. And then it depends on its acceleration and turn rate. If it accelerates to quickly and turns too slowly, it crashes into the station. If it accelerates slowly and turns quickly, it just passes.

The interesting part is that the launching ship already is in goToWaypointAI, before the launch_actions or shipLaunchedFromStation are triggered, and before it receives the LAUNCHED OKAY message. All this only happens when it is already in goToWaypointAI, which has no check for LAUNCHED OKAY, of course.

I have no idea why the AI sets itself to goToWaypointAI so early. I just see that, if I target the ship as soon as I can after it has launched and immediatly pause the game, the AI is already goToWaypointAI, and shipLaunchedFromStation is only executed a second or so later, together with the AI receiving the LAUNCHED OKAY message.

Ships launched by the populator don't have this problem, because they get exitingTraderAI, which doesn't check for waypoints. But I think many OXP ships with custom AIs derived from the standard AIs may have this problem. To be precise: any ship with a checkCourseToDestination + WAYPOINT_SET-combination in its initial AI state should have this problem.

I am trying to resolve it for my own AIs by giving them a pauseAI: 2.0 (perhaps 1.5 will be sufficient, have to do some tests) in the ENTER message of their GLOBAL state, move the setStateTo: HEAD_FOR_WITCHPOINT to its UPDATE message, and add the LAUNCHED OKAY message, which will probably send them to an intermediate state with getWitchPointEntryCoordinates, and only send them to HEAD_FOR_WITCHPOINT when they have reached these coordinates. The result should be that, if spawned somewhere else in the system, the AI does nothing for about 2 seconds, and then continues as before (HEAD_FOR_WITCHPOINT), but if launched from a station, it gets the LAUNCHED OKAY first and moves away from the station disregarding any obstacles, before heading for the witchpoint.

But this is of course only a solution for the AIs I am working on now. Probably a more general solution could be to include a "LAUNCHED OKAY" = (exitAI); in goToWaypointAI? I haven't tested this, it is just an idea.

Any thoughts?

[Thargoid]

This is giving me a deja-vu feeling of something I've encountered before and mentioned here, and that there was a solution in-place too when I did.

It might have been in relation to the Strelka liners from Famous Planets, but that's only a maybe. I'll trawl things tonight if I have time, but a quick search or review of the older threads might yield something here?

[Eric Walch]

Any thoughts?

Known problem I also had it. Main solution is to not use setCourseToPlanet on the very first initialisation of the AI. Don't use it in the GLOBAL-ENTER, and when that ENTER immediately jumps to a next state, also not in the ENTER of that state. All these commands are executed during addition of the ship.

Look for instance at the fallingShuttleAI. That also uses a setCourseToPlanet very early, but the first time at the first UPDATE of the AI. That is enough to catch an "LAUNCHED OKAY" message to first clear the station before doing other stuff.

"LAUNCHED OKAY" itself is probably immediately present but those messages are only evaluated on the first UPDATE.

[Commander McLane]

Thanks!

So that's basically what I described as my plan.

Still, can we do something to "heal" the other AIs already affected?

[Eric Walch]

Thanks!

So that's basically what I described as my plan.

Still, can we do something to "heal" the other AIs already affected?

When doing a setCourseToPlanet on initialisation, there will be a "WAYPOINT_SET" message along a "LAUNCHED OKAY". Than on the first update the messages are read in at random order, so 50% will clear the station an 50% will go into waypoint.

I have not seen such wrong AI in a release, but your suggestion to add a "LAUNCHED OKAY" = "exitAIWithMessage: LAUNCHED OKAY" in the gotoWaypointAI.plist should work for those AI. Could you test it against your problem AI?

Code: Select all

	"NEW_WAYPOINT" =
	{
		ENTER = ("setSpeedFactorTo: 0.0", "setDesiredRangeTo: 50.0", checkCourseToDestination);
		"WAYPOINT_SET" = ("setStateTo: NEW_WAYPOINT");
		"COURSE_OK" = ("setStateTo: GO_TO_WAYPOINT");
		"FRUSTRATED" = ("setSpeedFactorTo: 0.1", "setDesiredRangeTo: 1000.0", exitAI);
		"LAUNCHED OKAY" = ("exitAIWithMessage: LAUNCHED OKAY");
		ATTACKED = ("exitAIWithMessage: ATTACKED");
		"DESIRED_RANGE_ACHIEVED" = ("setDesiredRangeTo: 1000.0", exitAI);
		"INCOMING_MISSILE" = ("exitAIWithMessage: INCOMING_MISSILE");
	};

[Commander McLane]

Works like a charm, except I had to also insert it into the GO_TO_WAYPOINT state, because in my tests the ships are already in that state when they receive the LAUNCHED OKAY. May be different in different circumstances, so the message should be in both states.

[Eric Walch]

Hmm. In my tests adding to one state was enough. When looking in the code, I see you are right. That message is generated somewhere in the ships update:

Code: Select all

	if ([self status] == STATUS_LAUNCHING)
	{
		if ([UNIVERSE getTime] > launch_time + LAUNCH_DELAY)		// move for while before thinking
		{
			StationEntity *stationLaunchedFrom = [UNIVERSE nearestEntityMatchingPredicate:IsStationPredicate parameter:NULL relativeToEntity:self];
			[self setStatus:STATUS_IN_FLIGHT];
			[self doScriptEvent:@"shipLaunchedFromStation" withArgument:stationLaunchedFrom];
			[shipAI reactToMessage: @"LAUNCHED OKAY"];
		}
		else
		{
			// ignore behaviour just keep moving...
			[self applyRoll:delta_t*flightRoll andClimb:delta_t*flightPitch];
			[self applyThrust:delta_t];
			//....
			return;
		}
	}

and LAUNCH_DELAY is defined as 2 seconds so the message and the coresponding handler is only is generated at 2 seconds after launch. Until than it just flies straight ahead, ignoring other behaviour settings during those first 2 seconds. And I also see it is a reactToMessage. So it is not handled during the AI update but immediately on sending.

I'll add it to both states as you suggest.