Oolite Bulletins

Posted: **Fri Mar 09, 2012 10:55 am**

Fatleaf wrote:
Welcome to the life as a test pilot It's not Uber lasers and injectors all the time, just most of it

...and don't forget the many horrible new ways to die that you find

Posted: **Fri Mar 09, 2012 11:19 am**

snork wrote:
I put on my docking computer and felt I had to switch it off and stop suddenly when I was within a quarter of my Python's length away from the edge of the Torus. I reckon the top of my Python was going to catch the edge of the ring. With hindsight (one day I'll order some in advance) I should have taken screendumps.

I think the docking AI is not tailored for huge objects. Whenever you (or an NPC) approaches from behind the dockable object and the AI has to fly the ship around it first, it takes a path too close to the dockable object. The same is true for fuel stations, by the way, and may be the reason why they are surrounded by cargo pods so often. I witnessed an NPC approaching a fuel station from the planet side the other day, so it had to go around the fuel station first. Unfortunately it also didn't pass the fuel station with enough distance, so it smashed right into the structure.

I guess it has to do with how the waypoints for flying around an object are plotted. It seems that the engine tends to underestimate the radius of big objects.

Posted: **Fri Mar 09, 2012 4:23 pm**

Fatleaf wrote:
SandJ wrote:
Having spent ages visiting all the dockables I was not inclined to risk being destroyed just to see what would happen next if I let the docking computer keep going.
Welcome to the life as a test pilot It's not Uber lasers and injectors all the time, just most of it

Anyway, I have gone back to the relevant saved game and tried this a few times. It is Galaxy 5, Gesolaon, which has a Type B Torus. I have flown to the back of the station - through the spokes!

- and tried to use the docking computer. Twice it rammed the edge of the Torus:

but on this most recent one, it flew through the spokes!

Posted: **Fri Mar 09, 2012 5:37 pm**

My new Kiota stations also seem to have this effect/issue. It does seem that the docking AI waypoints are too close, and aren't taking the dimension of the entity they're docking with into account.

One for a feature request/bugfix perhaps...

Posted: **Fri Mar 09, 2012 10:11 pm**

Commander McLane wrote:
I think the docking AI is not tailored for huge objects. Whenever you (or an NPC) approaches from behind the dockable object and the AI has to fly the ship around it first, it takes a path too close to the dockable object. The same is true for fuel stations, by the way, and may be the reason why they are surrounded by cargo pods so often....
I guess it has to do with how the waypoints for flying around an object are plotted. It seems that the engine tends to underestimate the radius of big objects.

I don't think he underestimated the station collision radius. When checking agains the size, its even a few percents bigger. Its also not the AI. It must have to do with setting the waypoint.

I just added a few traders at the wrong side of the station. Very soon they were in a waypoint mode. Making a target dump revealed something weird:

Code: Select all

  [dumpState.shipEntity]: Name: Mosquito Sport
  [dumpState.shipEntity]: Primary role: trader
  [dumpState.shipEntity]: Behaviour: BEHAVIOUR_FLY_TO_DESTINATION
  [dumpState.shipEntity]: Target: <StationEntity 0x135731800>{"Torus Station" "Torus Station" position: (-62611, 64318.4, 648654) scanClass: CLASS_STATION status: STATUS_ACTIVE}
  [dumpState.shipEntity]: Destination: (-62611, 64318.4, 648654)

Compare the destination in above list with the stations position. They are the same! The checkCourseToDestination should change the coordinates of the station to a safe coordinate. Now I noticed the ship not just crashing with the station, but it even went for its centre and crashed there.

No idea what goes wrong as in the past I even verified it sets correct point around the planet when starting opposite of the station.

Posted: **Fri Mar 09, 2012 10:16 pm**

So it looks like the code checks the position of the entity that has to be circumnavigated. But then it doesn't construct waypoints around that position, but makes the position itself into the destination.

Posted: **Sat Mar 10, 2012 10:52 am**

Commander McLane wrote:
So it looks like the code checks the position of the entity that has to be circumnavigated. But then it doesn't construct waypoints around that position, but makes the position itself into the destination.

Yes, but why. At least the waypoint is calculated correct. I added some logging in the routine that calculates waypoints:

Code: Select all

[shipEntity.navigation.hazard]: Ship <ShipEntity 0x13a7b3800>{"Boa Class Cruiser" position: (-68004.8, 70185, 642856) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT} has found a hazzard: <StationEntity 0x1021bd600>{"Torus Station" "Torus Station" position: (-62611, 64318.4, 648654) scanClass: CLASS_STATION status: STATUS_ACTIVE}.
[shipEntity.navigation.safeVector]: Ship <ShipEntity 0x13a7b3800>{"Boa Class Cruiser" position: (-68004.8, 70185, 642856) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT} has found a safeVector: (-68720.5, 67502.3, 644881).

Calculating the distance to the station results in:

Code: Select all

S.mainStation.position.distanceTo([-68720.5, 67502.3, 644881]) --> 7854.8935546875

That is far enough. But an entity dump shows:

Code: Select all

[dumpState.shipEntity]: Destination: (-62611, 64318.4, 648654)

This is the station position again. It is not always wrong though. It could be because "WAYPOIT_SET" is only reacted on during the next update, giving the AI an opportunity to overwrite the new destination with the station position again.

An other thing that sometimes leads to a crash into the station is the dockingAI itself. That never uses waypoints and just assumes it has a free flightpath. When it starts the dockingAI on the wrong side of the station is will always fly in a straight line to the given position. In normal game this is generally not a big problem because the traders fly first to the planet and only than to the station. This will result in a station approach from the side and not from the wrong side as in my tests.

Anyhow, I'll look if something can be improved here.

Posted: **Sat Mar 10, 2012 11:38 am**

Ah, now I see why it often hits the torus station in my test conditions. From the log:

Code: Select all

[ai.takeAction]: Boa Class Cruiser 342 to take action setStateTo: HEAD_FOR_PLANET
  [ai.message.receive]: AI route1traderAI.plist for Boa Class Cruiser 342 in state 'HEAD_FOR_PLANET' receives message 'ENTER'. Context: changing state, stack depth: 1
  [ai.takeAction]: Boa Class Cruiser 342 to take action setCourseToPlanet
  [ai.takeAction]: Boa Class Cruiser 342 to take action setDesiredRangeTo: 30000.0
  [ai.takeAction]: Boa Class Cruiser 342 to take action setSpeedFactorTo: 0.35
  [ai.takeAction]: Boa Class Cruiser 342 to take action checkCourseToDestination
    [shipEntity.navigation.hazard]: Ship <ShipEntity 0x13fc39000>{"Boa Class Cruiser" position: (-70380.1, 70408.9, 643554) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT} has found a hazzard: <StationEntity 0x12874d600>{"Torus Station" "Torus Station" position: (-62611, 64318.4, 648654) scanClass: CLASS_STATION status: STATUS_ACTIVE}.
    [shipEntity.navigation.safeVector]: Ship <ShipEntity 0x13fc39000>{"Boa Class Cruiser" position: (-70380.1, 70408.9, 643554) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT} has found a safeVector: (-69733.4, 69835.2, 647096).
[ai.message.receive]: AI route1traderAI.plist for Boa Class Cruiser 342 in state 'HEAD_FOR_PLANET' receives message 'AEGIS_IN_DOCKING_RANGE'. Context: handling deferred message, stack depth: 0
[ai.takeAction]: Boa Class Cruiser 342 to take action dockEscorts
[ai.takeAction]: Boa Class Cruiser 342 to take action setStateTo: GO_TO_STATION
  [ai.message.receive]: AI route1traderAI.plist for Boa Class Cruiser 342 in state 'HEAD_FOR_PLANET' receives message 'EXIT'. Context: changing state, stack depth: 1
  [ai.message.receive]: AI route1traderAI.plist for Boa Class Cruiser 342 in state 'GO_TO_STATION' receives message 'ENTER'. Context: changing state, stack depth: 1
  [ai.takeAction]: Boa Class Cruiser 342 to take action setTargetToSystemStation
  [ai.takeAction]: Boa Class Cruiser 342 to take action setDesiredRangeTo: 5000.0
  [ai.takeAction]: Boa Class Cruiser 342 to take action setDestinationToTarget
  [ai.takeAction]: Boa Class Cruiser 342 to take action checkCourseToDestination
[ai.takeAction]: Boa Class Cruiser 342 to take action setTargetToSystemStation
[ai.takeAction]: Boa Class Cruiser 342 to take action setDesiredRangeTo: 5000.0
[ai.takeAction]: Boa Class Cruiser 342 to take action setDestinationToTarget
[ai.takeAction]: Boa Class Cruiser 342 to take action checkCourseToDestination
[ai.takeAction]: Boa Class Cruiser 342 to take action scanForHostiles
[ai.takeAction]: Boa Class Cruiser 342 to take action pauseAI: 10.0
[ai.message.receive]: AI route1traderAI.plist for Boa Class Cruiser 342 in state 'GO_TO_STATION' receives message 'NOTHING_FOUND'. Context: handling deferred message, stack depth: 0
[ai.message.receive]: AI route1traderAI.plist for Boa Class Cruiser 342 in state 'GO_TO_STATION' receives message 'WAYPOINT_SET'. Context: handling deferred message, stack depth: 0
[ai.takeAction]: Boa Class Cruiser 342 to take action setAITo: gotoWaypointAI.plist

The HEAD_FOR_PLANET state generates two messages: AEGIS_IN_DOCKING_RANGE and WAYPOINT_SET. The station is on its way to the planet so a deviation is calculated. However, the AEGIS_IN_DOCKING_RANGE is first executed, resulting in switching to the GO_TO_STATION state. There the station is made the new destination. checkCourseToDestination now does not find a new hazard. Is correct as it only looks for objects on route to the destination. It excludes the destination itself.

But the WAYPOINT_SET message is still pending so it does jump in the no longer needed waypoint AI. And that AI tries to navigate the ship to a point within 50 meters of the destination. But, that is now fatally close to the station.

I assume this problem is mainly caused by the test conditions of already adding the ship in the aegis on a collision route.

EDIT:
adding a dropMessages like:

Code: Select all

	"GO_TO_STATION" = 
	{
		ENTER = ("dropMessages: WAYPOINT_SET", setTargetToSystemStation, "setDesiredRangeTo: 5000.0", setDestinationToTarget, checkCourseToDestination);

fixes this problem of wrongly heading straight for the stations centre.

Posted: **Sat Mar 10, 2012 2:06 pm**

The dockingAI.plist still had the problem that it could crash the ship into the torus station. That is because the first issued approach coordinate was on the port side of the station.
I now added an additional check to see from which side a ship was approaching. When from the back of the port, I added an additional first approach coordinate: On the 'equator' of the station at the ships side and 5000 meters away from the station.

I tested it with a few dozens of traders, all starting from the wrong side of the torus station. None crashed. Currently my commander activated the docking computers. No longer trying to fly trough the spokes, but rounding the station on a safe distance.

Oolite Bulletins

Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence

Re: Torus space stations' sphere of influence