Can someone make a better docking computer?

[Mazur]

Given that an experienced pilot can dock at full speed from an off-angle approach, and some forum members like to do the same on full injectors, the computer is intentionally designed more for reliability than speed. The docking computer taking ages to dock is mildly irritating; the docking computer slamming you into the station wall is considerably more of a problem.

Agreed. Nevertheless, I think there are major improvements possible there. I mean, even in the last 2 kilometers there are stops at 1 km and at 0 km, after rotational alignment has already been achieved (well, not always perfectly, oddly enough, I've come in on computer one or two degrees skewed a couple of times, but that's nothing to worry about), there are two more total stops, whereas I trundle in at 80, manually "precision" correcting rotation with brief taps about two/three per second. Were I a computer I could seize the moment I was aligned perfectly and simply maintain that, without so much as looking at my speed. I'd hazard to guess the stops and starts are a remainder of development stage code where bugs were still rife.

Within that, it mostly already works as you describe, with a few minor changes...

• The waiting positions are less tightly specified.
• There's a docking heap rather than a docking queue. Ships in the heap (which includes the player using a docking computer) request docking every few seconds and get added to the much smaller close approach queue if they happen to be the first to make the request after a ship docks. This means that the length of time it takes a particular ship to get an approach slot is non-deterministic, but in most cases this isn't noticeable and usually means the player gets to dock quicker than they might expect ... but in particularly busy docks it can make the process much longer.
• The lining up with the docking axis takes place about 5km from the station, rather than 10km.

...and one big difference:

but without stopping and starting.

This is very tricky to get right. The stops are used to verify that the approach is still correct - failing to stop or break off on an incorrect approach risks a collision. It would certainly be good to get this working - it would speed up final approach to about half its current duration, or perhaps better - but it's probably the most complicated bit of the whole process.

I would tend to disagree, as people seem to be able to dock on witchfuel injection using ILS. And when I go back to comparing with my "Infinity welcomes Careful Drivers" approach: once lined up to the centre of the dock, I pretty much go at it full speed up to when 3km shows up as distance, throttle back to 80, and still have ample time to fine tune centring and wait for the right rotation to come around. And a computer could do the last two while at full speed and with much greater precision than an aging lummox like myself, if need be.

It sounds like there's two possibly related problems here:
1) Ships are for some reason failing to run through the approach pattern correctly (possibly because 2 increases the need for collision avoidance in the holding areas)
2) Ships are arriving at least as fast, if not faster, than they are able to dock (possibly because 1 slows things down)

Xexedi is probably a particularly bad case for this - and not a system I've visited for a while - if there are 10 cops, and they're hanging around, probably at least 9 of them are waiting to dock.

(Incidentally, the two minute limit doesn't apply to the docking computer as it automatically requests extensions - you can do the same on a manual approach by pressing shift-L again when you get the "hurry up" notification: though it should normally be able to dock a ship a fair bit quicker than that)

Ah, did not know that (or not anymore), could have saved me a couple of times in the early days.

So ... things to check: (I'll go to Xexedi for some testing myself, too)
- when you're at Xexedi station, what's the frame rate? (press shift-F while paused to show it)
- which OXPs do you have installed? (if you start Oolite, then immediately quit, your Latest.log file will be short enough to post up here and contain all the relevant information)
- do you get this problem at other stations with less traffic?

Erm, I've currently 191 OXPs installed, I think... Essentially everything that does not make the game harder.

About other stations: the approach is still cumbersome, next time I'll count the stops and try to remember the locations. (Did some taxi work in wherever I ended up on my first Parcel contract, (checking logs) Inonri.) But since there is no other traffic there, the computer goes right on in, though slavishly going through the whole list of waiting areas, it seems and stopping at each one. But you should check that, too, because recently I've to a few stations with other stations nearby, so then starting the computer from too far out will lead you to the nearest station, and not the one in your sights. And that corrupts my memory.

[cim]

I'd hazard to guess the stops and starts are a remainder of development stage code where bugs were still rife.

Unfortunately not - it's an intrinsic part of how the docking approach sequence is implemented.

I would tend to disagree, as people seem to be able to dock on witchfuel injection using ILS

ILS is a neat implementation, but it cheats - it doesn't turn your ship faster than its maximum turn rate, but it does within that constraint instantly set your effective pitch rate to the optimal value, whereas both player manual control and normal AI control are subject to forms of rotational inertia which make both ultra-precise and high-speed turning more difficult.

Accounting for the inertia is moderately difficult, especially if the frame rate is variable: if you set up a turn rate with the right acceleration for 60FPS, but then there's a spike in activity and the next frame takes three times as long, you'll end up undershooting the turn before you can recalculate. (Not by a lot, but at injector speeds you'll move over 100m in that 1/20th of a second, so that has to be in exactly the right direction)

But you should check that, too, because recently I've to a few stations with other stations nearby, so then starting the computer from too far out will lead you to the nearest station, and not the one in your sights.

Did you have the desired station actually targeted when starting the docking computer? If so it should have gone for that one.

[Norby]

you get regular updates about your queue position

Ah so you are not talking about the helper messages of [wiki]Traffic Control OXP[/wiki] but the core messages.

To speed up a long queue maybe I should make the ILS somewhat usable by NPCs. Not so easy, which mean a nice challenge for me, just my developing queue is long so I don't know when.

Anyway, there is an option to speedup: dock and pay the fine like the cost of ordering you to the first place of the queue.

manual control and normal AI control are subject to forms of rotational inertia

I assume this delay is a fixed value for all ships: I measured the time from 0 to max. pitch is 0.5 sec both with Cobra3 and Anaconda. At least this is not configurable like the thrust. Probably I can add this for smoothness, without handling the load spikes which maybe not a very noticeable problem.

[Mazur]

I'd hazard to guess the stops and starts are a remainder of development stage code where bugs were still rife.

Unfortunately not - it's an intrinsic part of how the docking approach sequence is implemented.

I would tend to disagree, as people seem to be able to dock on witchfuel injection using ILS

ILS is a neat implementation, but it cheats - it doesn't turn your ship faster than its maximum turn rate, but it does within that constraint instantly set your effective pitch rate to the optimal value, whereas both player manual control and normal AI control are subject to forms of rotational inertia which make both ultra-precise and high-speed turning more difficult.

Accounting for the inertia is moderately difficult, especially if the frame rate is variable: if you set up a turn rate with the right acceleration for 60FPS, but then there's a spike in activity and the next frame takes three times as long, you'll end up undershooting the turn before you can recalculate. (Not by a lot, but at injector speeds you'll move over 100m in that 1/20th of a second, so that has to be in exactly the right direction)

(I'm not suggesting to dock at injector speed, but at, say like me, 80 or so, and with some more calculations on the go, rather than stopping all the time. Like I said elsewhere, from within 3km, at speed 80, I have plenty time to focus pitch and yaw before fondling the roll
button, even time to wait for the Coriolis to match roll position.)
Ah, so that's the problem: calculations about movement are made per frame update, not per intention, and the rotation rates are connected to the frame rate., rather than the game time passed. Which makes no sense to me, as a pilot in the game you can apply two rolls speeds, both greater than a Coriolis station (in a Cobra), so if due to a freeze in the reality outside the game (to which I also count graphic updates, i.e. effective frame rates) the number of game updates drops too much, a pilot could not even roll to match the station?
And a computer cannot be trusted to maintain roll perfection, if the FPS drops too much? I'd cheat the hell out of that in the code, unless the ship can't roll fast enough to match the dock, but then I'd make Computer controlled Docking calculate the optimal distance and time to wait for the station to roll into position and gun it, timing it so that when the nose is level with the dock entrance, the ship would just fit crookedly, and be at such speed that Docking would finish before the station rolled as far as the other slanted extreme. It's a game, after all, not a test if the player can afford new enough hardware.

But you should check that, too, because recently I've to a few stations with other stations nearby, so then starting the computer from too far out will lead you to the nearest station, and not the one in your sights.

Did you have the desired station actually targeted when starting the docking computer? If so it should have gone for that one.

It was both in my crosshairs and in my ASC, and hte first thing that happened, at 32 (?), 52 (?) km away was; stop, turn around facing the opposite direction, and accelerate to top speed. Needless to say I broke that off and trundled in manually to a closer distance. As to "targeted", that has several meanings, here, since indeed my missiles get "targeted" to whatever looms largest in my crosshairs (jumpgates, moons, planets and even the local star), my crosshairs can then be moved targeting something else innaccurate enough for the missiles not to get retargeted and ones ASC can be targeted to something, and the player can have a target ("GET RICH FA$$$T!!!!"/get parcel to X in time/just get safely at the next stop/...).

As to my FPS at Xenedi, I forgot to check, but I'll tell you this: since I have a telescope, there are usually so many objects depicted in the scanner, that my precision pitch/yaw/roll all jump like unCTRLed p/y/r in a high FPS situation. So, yes, I'm thinking about dumping hte Telescope, soon, though I love the MFD (and scanner) info, but my pur olde lappie* simply can't handle that much, apparently.

* Laptop (with mock Scottish accent, for some reason).

[Mazur]

you get regular updates about your queue position

Ah so you are not talking about the helper messages of [wiki]Traffic Control OXP[/wiki] but the core messages.

Yes! Traffic Control OXP is wildly misnamed, it should be called Safe Docking Advice OXP or similar. Anyway, I threw that out post haste once I found out that annoyingly frequent advice was all it does, and the lightblulbs along the line dock-beacon were not, nor the regular Traffic Control instructions.

To speed up a long queue maybe I should make the ILS somewhat usable by NPCs. Not so easy, which mean a nice challenge for me, just my developing queue is long so I don't know when.

Anyway, there is an option to speedup: dock and pay the fine like the cost of ordering you to the first place of the queue.

Yeah, did that once, promptly got fined the whole 0.1 ₵ I had left in the bank, although the message said 0.0. (The email said 0.1).
But I'm not that kind of guy, you know?
That was my best early run: making a trip with only 0.1 left after fuelling and filling the holds as best as possible. And I think I got my first pirate that run, as well, second missile I managed to get away disappeared both red markers, and made a yellow marker appear, going away as if nothing had been happening, whistling innocently with hands in the pockets.

[cim]

And a computer cannot be trusted to maintain roll perfection, if the FPS drops too much?

Purely low FPS shouldn't be a problem unless it gets really low - we recommend 30 FPS as about the minimum playable rate, but I've forced it down to 15 in testing and still had everyone dock without issues and fairly quickly. If it's sometimes decent and sometimes really low, then there are issues, and if it gets much below 10 (either consistently or instantly) the AI can end up regularly missing its precision targets for the docking approach and having to back off to avoid the risk of crashing into the station.

(There are various steps which could be taken to adapt to low frame rates ... the problem is that if you have semi-decent FPS you basically don't need them, and if you have less then you don't really need any further complications in the calculations process)

It's a game, after all, not a test if the player can afford new enough hardware.

As 3-D games go, Oolite is pretty easy on the hardware - you don't need a high-end or modern computer for it - but OXPs can increase the load significantly (especially on old hardware), and there are limits to how much can be optimised.

The Intel GMA graphics card you have is very low spec, and that series of cards has notoriously bad support for OpenGL and shaders. There are integrated graphics cards of that sort of age which can run Oolite pretty well ... but that's not one of them.

I'd recommend:
- if you haven't already, turn the graphics settings down to "Normal Detail" or perhaps even "Minimum Detail". While your card reports driver support sufficient to run higher detail levels, it won't necessarily do it well.
- limit the number of graphics-heavy OXPs (ships, stations, planets, other ambience) as much as possible. The more different ships you have in view at once, the more graphics information needs to be processed.

FPS suffers most while docking because the planet and station are both relatively complex graphically and very nearby. You want to try to get to be consistently at least 20 FPS, ideally 30 or more, while there, which may mean uninstalling quite a few OXPs (starting a "Strict Mode" game will let you easily test the potential difference between "none" and "lots" and let you get some idea of how many you might need to take out)

(If you're already running a consistent 20+ FPS even around Xexedi station, then something else odd is going on, of course - but the symptoms sound very much like "insufficient framerate")

As to "targeted", that has several meanings

Yes, sorry. I mean "targeted with either the ident computer or an active missile lock"

[Mazur]

And a computer cannot be trusted to maintain roll perfection, if the FPS drops too much?

Purely low FPS shouldn't be a problem unless it gets really low - we recommend 30 FPS as about the minimum playable rate, but I've forced it down to 15 in testing and still had everyone dock without issues and fairly quickly. If it's sometimes decent and sometimes really low, then there are issues, and if it gets much below 10 (either consistently or instantly) the AI can end up regularly missing its precision targets for the docking approach and having to back off to avoid the risk of crashing into the station.

It's running around 11 FPS, even with clear skies, but still the same at Xexedi. I'll start up a Commander Bear, and a Commander Onlinoob, with just Addons for Beginners, and see what they do. I"m also going to drop from colourdepth 24 to 16, first, and check that out.

(There are various steps which could be taken to adapt to low frame rates ... the problem is that if you have semi-decent FPS you basically don't need them, and if you have less then you don't really need any further complications in the calculations process)

It's a game, after all, not a test if the player can afford new enough hardware.

As 3-D games go, Oolite is pretty easy on the hardware - you don't need a high-end or modern computer for it - but OXPs can increase the load significantly (especially on old hardware), and there are limits to how much can be optimised.

The Intel GMA graphics card you have is very low spec, and that series of cards has notoriously bad support for OpenGL and shaders. There are integrated graphics cards of that sort of age which can run Oolite pretty well ... but that's not one of them.

So noted. Note to self: when the ship with money comes in, get new lappie and check GPU.

I'd recommend:
- if you haven't already, turn the graphics settings down to "Normal Detail" or perhaps even "Minimum Detail". While your card reports driver support sufficient to run higher detail levels, it won't necessarily do it well.
- limit the number of graphics-heavy OXPs (ships, stations, planets, other ambience) as much as possible. The more different ships you have in view at once, the more graphics information needs to be processed.

FPS suffers most while docking because the planet and station are both relatively complex graphically and very nearby. You want to try to get to be consistently at least 20 FPS, ideally 30 or more, while there, which may mean uninstalling quite a few OXPs (starting a "Strict Mode" game will let you easily test the potential difference between "none" and "lots" and let you get some idea of how many you might need to take out)

Minimum Detail since the beginning. Nevertheless, there are rarely any ships in view at all. After all, "Space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space.". But the (telescoped) scanner seems to demand a lot of processing if there are objects to map.

(If you're already running a consistent 20+ FPS even around Xexedi station, then something else odd is going on, of course - but the symptoms sound very much like "insufficient framerate")

As to "targeted", that has several meanings

Yes, sorry. I mean "targeted with either the ident computer or an active missile lock"

Not sure about the ident computer, is that permanently listed on the Large HUD? I know I habitually disarm missile locks on friendlies. But I only initiate the computer once either of them have had lock.

(Btw, having returned to Xexedi once more, I arrived with 11 ships ahead of me and 4 Cops, so less than what I mentioned before, we are now 74 minutes further and the area around Xexedi is filled with ships, 35-40 or so. I had the "Welcome to Xexedi dock." message, which I thought was the cue to "you're about to dock", but no such luck.)

[Norby]

Not sure about the ident computer

This is a core function, press "r", then aim the crosshairs to a ship or station. If you successfully locked then the name will be listed on all HUDs. Press again if you want to lock on another ship.

Telescope maybe not for you, or at least you should turn off lightballs and other functions in the primeable menu to reduce the demand on your hardware. Telescope modify the usage of the "r" key due to can lock targets outside from the crosshairs also so you should decide you want this function or not.

[Mazur]

Not sure about the ident computer

This is a core function, press "r", then aim the crosshairs to a ship or station. If you successfully locked then the name will be listed on all HUDs. Press again if you want to lock on another ship.

Telescope maybe not for you, or at least you should turn off lightballs and other functions in the primeable menu to reduce the demand on your hardware. Telescope modify the usage of the "r" key due to can lock targets outside from the crosshairs also so you should decide you want this function or not.

Yeah, I'd found those things out after wanting to get rid of those annoying circles, and I've been using that r/r feature the last few systems, last sysfem over 800 km away. So helpful to not overshoot while jumping.

WIth all the telescope functions off or lowest possible, my FPS rose from 10 to 15 average. I also installed a newer Graphics driver, which seems to help somewhat, as well.