Experiment with tighter docking approach.

[Eric Walch]

There are still complains about ships having problems with docking. Although I don't see it at my computer, it could happen more often on lower FPS conditions. The whole navigating has parts that are framerate dependent and problems will mainly be visible in the station approach for docking. So yesterday I committed a small tweak to trunk that should improve things a bit with low frame-rates by forcing ships in flying through a smaller corridor. (r4787)

But it might worsen things on other points. I was special affright that ships start to flip between two positions without getting a correct heading. This was a main problem on my old and deceased 700 MHz computer were I often went below 10 FPS. Anyhow, as I can't test anymore on low-end computers, it would be good if others on such computers could verify if last nighty improved docking for them and did not add new problems.

----

For those who are interested in some of the flight mechanism within Oolite I will try to explain briefly one of the mechanisms.

In order to fly to a target, a ship first rolls toward the right position and than pitches toward the destination. In combat situations ships keep pitching towards an exact position, but in normal flight, pitching stops when the heading brings a ship on a flightpath within the 'desired range'. With extreme high frame-rates this would result in all ships heading for a spot on a circle with radius 'desired_range' around the target.

With lower frame-rates, ships will more often go for spots inside the circle. To explain it better I made next sketch:



Assume we have a ship with a heading of line A. The next frame it will turn towards the target with max_flight_pitch. At high frame-rates this goes in small steps and the ship will have a bearing along line B on the next frame, while with low frame-rates the bearing of C will be more likely. In both cases the heading goes through an area within 'desired range' and turning stops. However, with a low frame-rate it is also possible for a ship to follow line B when it turned from a bearing right of line A.

Now the ship starts moving forward at a low frame-rate. After N frames it reaches the line 'frame-n'. When traveling along line C it will mean he reached its destination. But, when traveling along line B it has not yet reached its destination and has to travel for another frame. But than on frame n+1 he already overshot its target and is no longer on a course that leads through the target area and the ship has to make a turn in the direction of the target.

This overshooting the target is more likely to happen at low frame-rates and will mainly be noticeable during a station approach. Since Oolite 1.75 is the target circle already lowered to 95% of desired range, but in yesterdays tweak I force ships that have docking instructions to correct heading until it will go through a circle of 50% of desired range. The ship still will stop when entering the circle described by desired range but the ships will now go more through the centre.

My tests with ships that had extreme high turn-rates showed an improvement, but real tests with low-end computers would be welcome.

[Commander McLane]

[slightly off-topic]

Thanks for the explanation. I have often wondered why ships, when heading to a desired range around a certain target, usually don't head for the point exactly between their own position and their target, but tend to head for the outermost point of the sphere around their target, a point more or less perpendicular to the straight line from their initial position to their target's position. Now I know why.

[aegidian]

Great and useful post.

I find myself thinking that rather than simply looking at whether a ship has received docking instructions, the tolerances and speeds of AI navigation should be adjusted by some factor based on the number of frames drawn in the last second. Certainly a mathematical check determining whether the pitch (turn) rate and speed mean that the target sphere could be missed at the current frame rate should lead to an adjustment.

[snork]

Sorry, I'd like to be a good tester, but am not really up to it.
I tried to test this, with me usually playing at roundabout 16 fps near main station, but ...

I hardly ever saw some NPC crashing into a station anyways, with 1.76 docking AI, I mean. So it is hard to tell a difference.
I think to sometimes succesfully have made ships crash into a rock hermit by irritating them, positioning my own ship almost in their way, or just crossing their way, though.

At the main station, when I try to make things worse by going TAF>=4x, I am afraid any problems do not really reflect normal game.

Anyways, for what it's worth - playing with TAF-up-and-down I noticed :
old AI : at TAF 4x or higher, no NPC will ever successfully dock nor crash, they remain like frozen. Both in approaching their waiting-point*, or at their reached waiting point*, or also in what looks like a good final approach. They then look like perfectly in line, but will never advance anymore.

From the looks my amateurish thought was if maybe they can not match the rotation to their liking ? I mean when autodocking myself, it looks as if the docking AI is really obsessively perfectionist(ic?) not only with the being in line and centered, but also with matching the rotation.

(* These may sometimes after a while decide to go some other place ? Very )

new AI : at TAF 4x or higher ships will be frozen on their waiting point or on some subsequent steps, but when they are in final approach when I raise TAF to 4x, they will sometimes continue, and even successfully so.

So there is an observable difference - but it could also stem from small number of observations.

But, my impression was that there wasn't much crashing of docking NPCs anyway.

-----------------------------

Maybe low framerates kind of compensate themselves, with the ships having a chance of "skipping" the crashing conditions ?
Like in the past I sometimes was able to torus-drive through solid objects like rock hermits, at probably worse framerates than I have these days.
Or like I still am able to fly through outer spike-parts and rings of a double Torus station. El Viejo says he can't do this.

I guess the same rule applies to NPCs ? - so maybe they do not seriously scrape docking bays as often as they would at higher framerates.

[Eric Walch]

TAF 4x or higher ships will be frozen on their waiting point or on some subsequent steps, but when they are in final approach when I raise TAF to 4x, they will sometimes continue, and even successfully so.

So there is an observable difference - but it could also stem from small number of observations. .

The current change only narrows the corridor. It only will lower the chance of overshooting the target and thereby forcing the ships to make a looping in front of the dock what slows down the docking. When they do that to close to the dock, they crash and not normally because they were a bit to far outside the docking lane.

Ships not doing anything at all is another thing. That is probably constantly overshooting the heading as result the flipping between two headings. I remember it from my old mac. Often you could get ships out of the flipping by briefly switching between full screen and windowed mode.

Anyhow, I realised that my current change might have worsened this because of the tighter restrictions for heading. That needs a second fix I already had in mind: check the angle a ship has to turn against the calculated roll/pitch and the time between updates. I just didn't want to commit both simultaneously to get feedback about the first change by itself.
By making sure roll/pitch don't overshoot, ships stop flipping between two positions on my computer when using TAF 16x. So I assume it should also work nice for low frame rates.

But this change I will test a bit further myself before adding to trunk because flight behaviour should stay the same at high FPS rates. I think it still does, as at high framerates you still get the normal overshooting the target when turning to fast. That is because the turning has an inertia build in (like the thrust for speed) that limits the change of pitch/roll for npc ships.

EDIT: I just added my changes in r4791. Looks good at 16x taf conditions, but now need conformation it also fixes problems for low fps conditions.

[Eric Walch]

Certainly a mathematical check determining whether the pitch (turn) rate and speed mean that the target sphere could be missed at the current frame rate should lead to an adjustment.

Such a check is there already. When the ship would miss the target, it reduces speed. Probably that code is not enough, but good enough as I now have not seen ships turning in the last second. They still do sometimes turn a few steps before the dock when testing at 16x taf. That position of a few steps before the dock is the point were the circle is the smallest. After that position the target circles become wider again. As long as corrections are rare and non-lethal, there is no harm in leaving them in.

I did add a time dependent limit for pitch/roll in my later commit of r4791. That should stop the flipping between two positions without being able to get the correct center position. With 16x taf getting a correct pitch for docking is now smooth. I can't test on a slow machine, but 16x taf on a machine that normally has an 50 fps update should give comparable big jumps from frame-to-frame as a 1x taf at 50/16 = 3 fps.

But real test results of owners of slow computers would be welcome....

[armadillozenith]

... no NPC will ever successfully dock nor crash, they remain like frozen. Both in approaching their waiting-point*, or at their reached waiting point*, or also in what looks like a good final approach. They then look like perfectly in line, but will never advance anymore.

From the looks my amateurish thought was if maybe they can not match the rotation to their liking ? I mean when autodocking myself, it looks as if the docking AI is really obsessively perfectionist(ic?) not only with the being in line and centered, but also with matching the rotation..

It may be something totally different next, but this description is nearest to something I have seen several times in vicinity of a Naval Station (often after after I have been inside to trade or sign up for Reserves mission). I then notice a small Naval Ship is unmoving (does not advance, leave or try to dock - and is not placed toward docking port of station but rather somewhere behind it) - but fixed in one spot just does a repeated 'dance' turning to and fro. [Enters immersion mode] I explain to myself that it is a pilot testing his orienting controls a few times! [Leaves immersion mode] I have not played for many months and willl have to reinstall Oolite and OXPs - so cannot give full details.

[Eric Walch]

but fixed in one spot just does a repeated 'dance' turning to and fro. [Enters immersion mode] I explain to myself that it is a pilot testing his orienting controls a few times! [Leaves immersion mode] I have not played for many months and willl have to reinstall Oolite and OXPs - so cannot give full details.

The nose jumping up and down by a few degree is what I remember from my old computer under low fps conditions. Should be unrelated to the navy station, but those systems are 'by design' a bit overcrowded, leading to lower fps values. In those days, I fixed it by approaching the ship till we hit each other. In most cases that helped proceeding its path. What also helped is temporary switching between windowed mode and full screen mode.

I could not reproduce this problem directly on my current computer but I could simulate it by using high TAF values. From those results, this problem for docking ships should be strongly reduced (fixed?) since this weeks Ooltite 1.76.1 release.