Main script:
http://gtm.steamproxy.vip/sharedfiles/filedetails/?id=1330904900


The ship will first always make sure it's pointing in the correct direction. It will do this with a yaw and a roll at the same time using all gyroscopes it finds on the same grid as the connector. (Unless checkGrid is set to false.)

Once it's within 0.1 radians (the spinAngle global variable) of pointing in the correct direction the program will check if it's below or above the target connector. (more specifically, below connectorClearence or above hangarHeight). If it's out of the acceptable range it'll accelerate in the z axis (towards or away from the home connector) and maxing out at "hangarCorrectionSpeed".

Once the ship is within the acceptable range it'll accelerate in the x and y axis (perpendicular to the direction towards the connector) until it's close at which point it'll start to decelerate. It will take the most direct route to the connector with minimum deviation.

This whole process is adaptive, if it get's nudged so it's out of 0.1 radians of pointing in the correct direction it will adjust before carrying on. Decisions are made irrespective of what occured in the previous frame so it's always reacting to the current environment.

This image should explain the distances:


When close to the connector it travels at these speeds:


If it's approaching and is less accurate than the required accuracy at that level, the ship will stop moving downwards and wait until it's aligned then carry on.

While moving downwards, if "spinsBeforeConnecting" is true and it's a small ship (or largeShipsSpinToo = true) then the ship will spin to line up with the connector on the way down.

Spin direction lines up the connectors with both of their "up" directions:
You can change the direction by adding [90] to the END of your connector name (works for both the ship and station's connector). can be negative and a decimal value (If you want an insane amount of precision)

The script has an in-built method for automation when docking, simply add [Dock] to a timer block's name and when the ship completes an automated dock, the timer will be started.
This obviously has a minimum time limit of 1 second unless you want to hunt down the two lines that say:
timer.GetActionWithName("Start").Apply(timer);
and replace them with:
timer.GetActionWithName("TriggerNow").Apply(timer);

Uses:
This means you could have a system that could:

• close a hangar door,
  
• lock landing gear,
  
• unlock the connector and activate the script to send the ship to another location,
  
• stop rotors spinning on a helicopter/ship,
  
• Auto unload miners materials, wait a certain amount of time then leave,
  
• Have a bus system setup between points,
  
• Setup a ship that is completely fully automated.

Keen's in-built autopilot isn't the best but ususally it gets the job done fine, if not a little slow.
Usefully, it has the ability to do an action once a waypoint has been completed, this is perfect for automation as you can hook up this script to start when it's finished a route. - Eg an auto go-home then dock.

A suggestion somebody in the comments had was to have an automatic parking area, where when the ship is in a certain area, this script takes over.
If you do get it working, it'd be pretty nice to fly the ship in the general home direction then get out and leave it to it's docking sequence.
This could be easily done with a little scripting knowledge however it'll be slightly more difficult with just sensors. This is because you somehow have to get a signal from the station to the ship (if the sensor is on the station) or a sensor on the docking ship that somehow only detects whether you're close to the docking point.

If you're here, you likely know a bit about code, something I've done is added a broadcast once the script lands the ship or is aborted. This can be picked up by an antenna linked to a script for more advanced sequences.
Or you could be more devious and detect if an enemy is using the autodocking script and pick up where the ship's coordinates are...
Broadcasts are sent in this format:
"LANDED",<homeConnectorName>,<shipName>,<currentArgument>
"ABORTED",<homeConnectorName>,<shipName>,<currentArgument>
There's also plenty of communication when using the optional script you can tap into, such as dock requests for certain ports that come in the format:
"DockRequest",<homeConnectorName>,<shipName + currentArgument>

Generally the script only sees things that are on the same grid as the connector unless "bool gridCheck = true;" is set to false.
Upon a recompile the script looks for a cockpit (or remote control), this is pretty vital to the functioning of the script as it allows the script to get the gravity direction and strength and mass of the ship. (by default the mass is guessed to be 850000kg). The script does work without a cockpit but it's a bit touch and go.
The script then looks for a connector that contains the connector tag. (finds the latest one created if there are multiple).
Looks for an antenna with the antenna tag.
Looks for a timer with the timer tag.
Checks the "Storage" variable for the user's saved data. (In-built persistant variable)
If you're a pro at string manipulation you could do something with the data, it's in a format divided by certain characters:
homePosition,homeDirection,connectorNames,homeName!homePosition...etc
Note - commas seperate individual info, exclaimation marks seperate each home connector section. Each thing is stored as a vector3 converted to a string or just a string. "homeName" holds the argument associated with that home.

Not much going on here to be honest.
Starts the sequence described in the movement part of this extra guide.
Defines what thrusters are useable here - creates the list.
Performs some checks on your ship to ensure it's capable of the environment.
Get's going.

All communication is done via the antennae on board so yes, they do need to both be in range of each other.
Docking requests
Docking requests are sent from the docking script every 10 frames (If you've got over 10 ships running at once, you may hit lag spikes). A request consists of:
"DockRequest",<Connector Name>,<Ship Name + Argument>
This means each connector has to have a different name otherwise the script won't know which connector's coordinates to send back.
It also means each ship must have either a unique name or argument as the home script needs to be able to send the right communications to the right ship.
Docking responses
When a request is recieved by the base, it'll respond with the asked for connector location.
Responses are in this format:
"Pos",<Ship Name + Argument>,<Position of connector>,<Direction of connector>,<Up direction of connector>
This message is sent and all ships with my script in will pick it up (if they're connected to an antenna) however they'll all check the attatched ship name and argument to see if this message applies to them.
This is basically all that the home script does, it answers position requests so the main script can update it's home position. - doesn't need to be any more complex for what it does.

As the request uses the name of the connector, you could actually swap two connector names round and it'll dock to the other connector. This could actually be a way of implementing your own connector system - have a script that changes the block.CustomName round between two base connectors and it'll reroute the dock. (As long as the optional script is installed this will work not matter if anything is docking or not).
However if the optional script isn't installed this could cause issues.
I'd be interested to see if anybody creates something that does something as described, be sure to send me a link :)

Without any direct changes to the code, my script won't allow landing onto a currently moving platform. However it will still attempt it and generally do a good job getting close but never actually doing the final connection.
This is because the ship is just connecting to the currently known coordinates which are updated once every 10 frames but in the middle frames it isn't updated so it's effectively static most of the time to the program.
(I do actually have a variable that holds the current velocity of the home ship, this variable is even stored on the docking ship so the hard part is done. I'm just having issues implementing it as my script works on accelerations - It calculates what acceleration it needs to reach a point then what deceleration is needed etc. Adding a constant speed to it's movement is difficult and i'm pretty busy at the moment with work. If anyone has any ideas and know how to code I'd appreciate it...)

Currently there is actually a lot of disabled code that is almost finished. It allows the user to add a [Managed] tag to a connector on the base. This means when a ship requests to dock, if it's a managed connector the home script will pick a free connector to send the ship to.
The issue with this is if there's already a ship docking to a managed connector, the home script obviously shouldn't send a ship to the same connector (collision and subscribers unhappy...). The solution would be to keep a list of all connectors that are awaiting currently landing ships and removing them from the list when the ship has landed.
This produces even more problems as I'd need to remove the connectors from the list if the landing was stopped for any reason (which is why i added an "ABORTED" broadcast from a ship when it's stopped) but this still is a bit of a flimsy system as many things could go wrong.
Let me know in any comments section anywhere whether I should persist with this feature.