Escape pods on 4668

[Kaks]

That's the way ShipEntityAI's setCourseToPlanet defines its random destinations:

Yes it's not very precise, but has been used by quite a few AIs to get 'near enough' to any planet before doing whatever else is required.

Making changes to setCourseToPlanet will potentially break a lot of OXPs, but I suppose we can always add this:

"AEGIS_IN_DOCKING_RANGE" = (setTargetToSystemStation, "setAITo: dockingAI.plist");

So in case the escape pod is near the main station it can go directly to the station instead of disappearing.

"DESIRED_RANGE_ACHIEVED" = (landOnPlanet);

will need to stay in case the pod is near another planet in the system.


I'll have another look to see if I can make setCourseToPlanet more precise without breaking things - something I've been doing rather a lot these past few days - if not, a new setCourseToPlanetSurface command will be duly added to the Post-MNSR new features TODO...

[Eric Walch]

I notice it received a WAYPOINT_SET message in response to checkCourseToDestination. Does this reset the desired_range? Maybe it needs a "WAYPOINT_SET" = ("setAITo: gotoWaypointAI.plist"); line? Also seems odd that it got a COURSE_OK and a WAYPOINT_SET message at the same time. How does that happen?

Code: Select all

08:11:17.765 [ai.message.receive]: AI homeAI.plist for Escape capsule 536 in state 'HEAD_FOR_PLANET' receives message 'WAYPOINT_SET'. Context: handling deferred message, stack depth: 0
08:11:17.765 [ai.message.receive]: AI homeAI.plist for Escape capsule 536 in state 'HEAD_FOR_PLANET' receives message 'COURSE_OK'. Context: handling deferred message, stack depth: 0
08:11:17.765 [ai.takeAction]: Escape capsule 536 to take action setSpeedFactorTo: 1.0

The 'WAYPOINT_SET' message indeed indicates that a new destination was set. Not 50 meter from the planet, but very close to the current target. That is a likely cause of pods just vanishing into nothing. Strange I never noticed before. Probably it only happens when trying to avoid another pod. As they are so small, the new destination will also be very close and reached within an update.

[Eric Walch]

I'll have another look to see if I can make setCourseToPlanet more precise without breaking things - something I've been doing rather a lot these past few days - if not, a new setCourseToPlanetSurface command will be duly added to the Post-MNSR new features TODO...

I don't think there is a problem with setCourseToPlanet. The current form just ensures that not all ships head for the same spot on the planet.

[Eric Walch]

I now confirmed that having a ship with 20 escape pods, there suddenly disappeared 17 of them. OUTCH.

With following AI, things seem to behave normal. (Done just one test on this writing)

Code: Select all

{
	GLOBAL =
	{
		ENTER = ("setSpeedFactorTo: 1.0", "setStateTo: HEAD_FOR_PLANET");
	};
	"HEAD_FOR_PLANET" =
	{
		ENTER = (setCourseToPlanet, checkCourseToDestination);
		"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);
		"COURSE_OK" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"DESIRED_RANGE_ACHIEVED" = ("setAITo: dumbAI.plist");
		UPDATE = (checkCourseToDestination, "pauseAI: 10.0");
	};
	"NEW_WAYPOINT" =
	{
		ENTER = ("setSpeedFactorTo: 0.0", setDesiredRangeForWaypoint, checkCourseToDestination);
		"WAYPOINT_SET" = ("setStateTo: NEW_WAYPOINT");
		"COURSE_OK" = ("setStateTo: HEAD_FOR_PLANET");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: HEAD_FOR_PLANET");
	};
}

Is also makes that the pods try to avoid obstacles, instead of doing nothing in the old situation.

[Cody]

I now confirmed that having a ship with 20 escape pods, there suddenly disappeared 17 of them. OUTCH.

Indeed... it was a strange sight, seeing a whole bunch of them suddenly disappear en masse.

[Kaks]

Impressive stuff & thanks!
Not quite sure why I only saw 1 or 2 disappeared pods per launch myself!


Will follow them & see what happens!

[Fatleaf]

It was very random. Sometimes 17 would vanish other times 3 still another time none would disappear. But asuming Erics code works well then that is another bug squashed.

Thanks guys for the time to fix this.

[Capt. Murphy]

Nice one Eric, that looks like it should do the trick and I see you've committed the fix.

Quick question arising from me wondering how the pod that posted log got both a "COURSE_OK" and "WAYPOINT_SET" message at the same time Those entries were the only ones for that particular entity.

Am I right in thinking that if the "ENTER" line does not include a pauseAI, that "ENTER" and the first "UPDATE" will run concurrently? When I was putting together the escort contracts AI I think I assumed that to be the case and always put a pauseAI in the "ENTER" line when the state also included an "UPDATE". It seems to me that not doing this in general could cause the occasional AI glitch, and if nothing else unnecessary CPU cycles.

Does putting a pauseAI in the "ENTER" line stop the AI reacting to messages straight away?

Edit - I think this thread (https://bb.oolite.space/viewtopic.ph ... eAI#p46821) and it's link to http://wiki.alioth.net/index.php/State_machine answers my question. There is in effect a default "pauseAI:0.125" inherent in "ENTER". I remember reading this now whilst putting together the escort contracts AI.

[Eric Walch]

Nice one Eric, that looks like it should do the trick and I see you've committed the fix.

Quick question arising from me wondering how the pod that posted log got both a "COURSE_OK" and "WAYPOINT_SET" message at the same time Those entries were the only ones for that particular entity.

Both messages were not sent simultaneously, I think the first was generated by a command in 'ENTER" and the second by a command in 'UPDATE'. Than on evaluating the messages on UPDATE, they were both present.

Am I right in thinking that if the "ENTER" line does not include a pauseAI, that "ENTER" and the first "UPDATE" will run concurrently?

No, they don't run concurrently, but without defining a pause, the default value is 0.125 seconds and feels probably concurrently

Does putting a pauseAI in the "ENTER" line stop the AI reacting to messages straight away?

There is never a reaction on plain messages during 'ENTER' only on UPDATE. Unless the commands in ENTER generate 'reactToMessages' that are always immediately.

[Capt. Murphy]

I now confirmed that having a ship with 20 escape pods, there suddenly disappeared 17 of them. OUTCH.

With following AI, things seem to behave normal. (Done just one test on this writing)

Code: Select all

	"NEW_WAYPOINT" =
	{
		ENTER = ("setSpeedFactorTo: 1.0", setDesiredRangeForWaypoint, checkCourseToDestination);
		"WAYPOINT_SET" = ("setStateTo: NEW_WAYPOINT");
		"COURSE_OK" = ("setStateTo: HEAD_FOR_PLANET");
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: HEAD_FOR_PLANET");
	};
}

Is also makes that the pods try to avoid obstacles, instead of doing nothing in the old situation.

Eric - I've come across another minor bug with the new homeAI.plist. A jettisoned pod is I think hardcoded to be tumbling on ejection. Because there is no performFlyToRangeFromDestination they don't actually move to the way point if the course is blocked they can end up in a loop between states HEAD_TO_PLANET and NEW_WAYPOINT.

This fixes it -

Code: Select all

"NEW_WAYPOINT" =
	{
		ENTER = ("setSpeedFactorTo: 1.0", setDesiredRangeForWaypoint, checkCourseToDestination, "pauseAI: 2.0");
		"WAYPOINT_SET" = ("setStateTo: NEW_WAYPOINT");
		"COURSE_OK" = ("setSpeedFactorTo: 1.0", performFlyToRangeFromDestination);
		"DESIRED_RANGE_ACHIEVED" = ("setStateTo: HEAD_FOR_PLANET");
	};

[Eric Walch]

Eric - I've come across another minor bug with the new homeAI.plist. A jettisoned pod is I think hardcoded to be tumbling on ejection. Because there is no performFlyToRangeFromDestination they don't actually move to the way point if the course is blocked they can end up in a loop between states HEAD_TO_PLANET and NEW_WAYPOINT.

You may be right. But, as it is very minor I won't change it now. You are right that in the very beginning there is no performFlyToRangeFromDestination but the idle state it starts with does react on speed instructions, just not on direction instructions

Escape pods used to be ejected in the same way as cargo: That is tumbling around. But because the pods regularly crashed into their mother, I changed the ejection mechanism for 1.75:
If an ejected pod contains a pilot, it is not ejected tumbling, but instead the pod is rotated so that it points away from the mother and than is it ejected with a slightly higher speed as normal pods.

[Capt. Murphy]

Cheers Eric, that makes sense - the issue has only been observed on (unpiloted) pods spawned via the debug console.