Docking AI

[Micha]

Hi to all you Happy Scripters,

I've noticed that sometimes when I approach a station, a lot of ships are mingling around waiting seemingly forever. Myself included unless I shift-D into the Station.
I've gone through a fair bit of AI code from the OXPs I run and found that some scripts call 'dockingAI.plist' without first ensuring that the ship is anywhere near a station.

This has 2 unfortunate side-effects:
1. Generally the ship in question stops responding to attacks or other events while it flies towards the station (although it will still attempt to avoid collisions).
2. It ties up the docking queue at the station.

So to maintain harmony and avoid "Docking Rage" amongst pilots, could I please respectfully request that you ensure your scripts first drive you close to your target station (say to within 15km) before engaging the dockingAI?

Cheers and Happy Docking!
- Micha.

[Eric Walch]

Code is correct. You don't need to be near the station before issuing the call. When you target a station on the other side of the galaxy, the ship will still dock correctly. But you are right that this is not a wanted method. However, I don't think these ships are responsible for the queue.

I think the problem is in the "face_destination_behaviour". For some reason some ships don't react on this command while the ai-code is indefenitely waiting for the result "FACING_DESTINATION". I think it happens when the ship is facing exactly the opposite side when entering this code.

In my alternative for the dockingAI I tackled this problem to no not wait indefinitely for the answer but always continue with the code after 10 seconds by adding an UPDATE. It solved the problem for me. (It is in my last version of "new_1.72_only_AI" oxp)

(It is just that I still look for a sftp program to be able to upload my AI changes to Berlios)

The change is in ABORT. Try to replace it witch this:

Code: Select all

	ABORT =
	{
		ENTER = (abortDocking, "setSpeedTo: 0.0", setDestinationToDockingAbort, "setDesiredRangeTo: 500.0", performFaceDestination, "pauseAI: 10");
		"FACING_DESTINATION" = ("setSpeedFactorTo: 1.0", "setDesiredRangeTo: 500.0", performFlyToRangeFromDestination);
		"RESTART_DOCKING" = ("setStateTo: GLOBAL");
		"REACHED_SAFETY" = (performIdle, "setStateTo: GLOBAL");
		"DESIRED_RANGE_ACHIEVED" = (performIdle, "setStateTo: GLOBAL");
		ATTACKED = ("setStateTo: ATTACK_SHIP");
		"GROUP_ATTACK_TARGET" = ("setStateTo: ATTACK_SHIP");
		"UPDATE" = ("setSpeedFactorTo: 1.0", "setDesiredRangeTo: 500.0", performFlyToRangeFromDestination, "pauseAI: 10");
	};

[another_commander]

(It is just that I still look for a sftp program to be able to upload my AI changes to Berlios)

Eric, I think you only need an SVN client to upload to Berlios. No ftp required and I'm not even sure that it will work either.

[Micha]

Code is correct. You don't need to be near the station before issuing the call. When you target a station on the other side of the galaxy, the ship will still dock correctly.

I never said that the ship wouldn't dock correctly

But you are right that this is not a wanted method. However, I don't think these ships are responsible for the queue.

I'll try your suggested modification to the dockingAI.plist, however, my statement stands.

When you enter dockingAI.plist, it issues a call to "requestDockingCoordinates". This call, eventually, trickles through to StationEntity.m:dockingInstructionsForShip, where the ship is added to the Approach queue (if the target station is happy to accept the docking request). Once in the Approach queue, no other new ship can dock until that ship has - even if it takes half an hour to get there.. (ok, slight exageration, but still...)

I'm playing around with a slight modification to the StationEntity code which -should- work nicely with existing AI as well as not tying up the approach queue, but I'm loath to make such a change as it may have unexpected repercussions.

[EDIT]

Looking at the code after thinking about your comments for a few more minutes, I think I may have misinterpreted the way the AI and the code interacts..

However, ships in the approach queue will prevent -launching- ships from leaving, so while not as bad, it's still not great.

Also, with the new Docking Clearance functionality, it will prevent the -Player- from manually docking as the station waits until all approaching ships have docked before giving clearance. And this is where I primarily noticed this effect.

[Eric Walch]

Once in the Approach queue, no other new ship can dock until that ship has - even if it takes half an hour to get there.. (ok, slight exageration, but still...)

Could be true. But there are two queues, hold queue and approach queue. Ships in the second will be docking. But all hanging ships I saw ware in a perform_facing_destination and not waiting for a queue.
NB you noticed that both queues are resolved after docking. That is because the system fast docks all ships in both queue when the player launches. But the ships in the ABORT state still keep hanging; meaning they were not yet in a queue.

But there is a whole other bug added around 1.70 when the distance check for requestDockingCoordinates was removed. All escorts used to dock at the nearest station when released by their mother. But in 1.72 they are send to the station that is closest to the player (not the mother). This results that when a boa that docks at the main station, it sends its escorts to a rock hermit when the player is closer to that hermit. This bug drove me crazy when testing dockable ships that constantly were halted by distant docking requests.
This bug is submitted at berlios long ago and is probably already fixed in 1.73

[Cmdr James]

I have been experimenting with the following changes to dockingAI for a few weeks. Seems to prevent the problem, which seems to be a deadlock of ships blocking each other.

Code: Select all

	  "WAYPOINT_SET" = ("setAITo: gotoWaypointAI.plist");
      FRUSTRATED = ("setSpeedTo: 0.0", checkCourseToDestination, performFaceDestination);

But, I do see quite a few ships crash into the station, not sure if that related.