Oolite Bulletins

1.79, Cobra MK III. I have only docked 5 times so far and it has crashed once ( I switched to look out of the rear view as I docked and the docking computer was definitely active). I have noticed that if I switch to aft view the docking computer gets confused as if resetting. It especially seems to have problems when trying to pitch up or down. It judders very fast as though trying to execute the maneuver but resetting over and over (it looks like it is stuck in a loop waggling up and down but very slightly) and only continues to dock properly when I return to the forward view. It has done this on all 5 attempts hence I haven't done all 10 tests yet.
When looking out of the forward, port and starboard views it seems to be ok though.

Edited to add: All other traffic was acting normally and shouting at me to hurry up and dock.

The Griffin GT wrote:

1.79, Cobra MK III. I have only docked 5 times so far and it has crashed once ( I switched to look out of the rear view as I docked and the docking computer was definitely active). I have noticed that if I switch to aft view the docking computer gets confused as if resetting.

I can't reproduce any of that here. <grins> The DC is trying to lull me into a false sense of security, methinks.

Strange, I just did another 5 tests, same behavior as before but I've found it always crashes if I switch into aft view after it does its final line up check and accelerates...

The Griffin GT wrote:

Strange, I just did another 5 tests, same behavior as before but I've found it always crashes if I switch into aft view after it does its final line up check and accelerates...

Just to check: you don't have Norby's "reverse up-down controls in aft view" OXP installed? I can't imagine the docking computer would cope well with that.

Thargoid wrote:

I wonder if it may be worth correlating the problem with your processor speed (or your FPS count). I've occasionally noticed things going a little weird on my low-spec machine, which I think may be a result of frame-skipping to keep up.

It's worth a look, though I've pinned my CPU to 1GHz (the lowest it will go, and the alleged minimum spec) which gives FPS in the 20-40 range, and so far the docking computer is at 8 of 8 successful dockings, in a variety of systems from a range of starting positions.

Latest.log files from people who do have crashes it looks like will be necessary to narrow this down.

Did four more tests during lunch break all successful. So my score is now 1 in 10 (which is still one too many). Whatever this issue is, it seems to be intermittent enough to be causing grief to whomever tries to test.

Ok I did 10 out of 10 successful landings in my OXP ship with the DC then on the 11th I tried to switch to my aft view and crashed. I do have Norby's "reverse up-down controls in aft view" OXP installed, haven't tried it without that yet.

log here.

cim wrote:

]Just to check: you don't have Norby's "reverse up-down controls in aft view" OXP installed? I can't imagine the docking computer would cope well with that.

Your right cim, that's exactly what it was, removed it and everything's fine. I only bought the docking computer try to help test it...

cim wrote:

you don't have Norby's "reverse up-down controls in aft view" OXP installed?

I can confirm also that reversed aft controls are confuse the docking computer when the player look backwards. All of my test failed in this case and none in other cases (looking to other direction or without reverse oxp).

I got zero docking problems in 1.79 on my desktop form about 10 try but sometimes collided on my 15FPS netbook.

Cody wrote:

As can docking at a rock hermit on torus drive!

When I tried it in 1.79 then I always flied through the rock.

I've put a patch up now which means that if the rotation isn't matched in the final stages the docking computer will bring the ship to a stop, rematch it, and then continue, rather than trying to match while approaching. This should deal with a potential problem if an unexpected stutter causes the station to rotate significantly.

Leaving aside "deliberately cross-wiring the controls" as a cause of DC accidents, what's it actually doing wrong when it crashes? Just failing to match the roll, or pitching around too? If it's just the former, I think that should be fixed now.

cim wrote:

Leaving aside "deliberately cross-wiring the controls" as a cause of DC accidents, what's it actually doing wrong when it crashes? Just failing to match the roll, or pitching around too? If it's just the former, I think that should be fixed now.

The one time I saw it happening, it was clearly a failure to match roll.

lesliev wrote:

Also, could cargo dumping not be shift-d or ctrl-d by default, or something that's less of a booby-trap?? Backspace or delete maybe?

Agreed - I've changed the default to "shift-D" for the next version.

cim wrote:

what's it actually doing wrong when it crashes?

My oxp does not know why a ship roll or pitch so force an opposite movement in every frame. Due to in the last stage DC mainly do roll and no pitch this seems to be roll only. A solution can be a "DCisActive" flag when the js code can stop reversing if the input is not come from the player.

Norby wrote:

A solution can be a "DCisActive" flag when the js code can stop reversing if the input is not come from the player.

There's one of those already - player.ship.AI. If it's "dockingAI.plist" then the docking computer is active.

Slightly off-topic: should the DC jump the docking queue? I pulled into the aegis, with only a Python and a Viper on the scanner, called for docking clearance, got told there was incoming traffic and I was number two, and the Python appeared to be heading in to dock. Then I remembered to test the DC, so I cancelled the clearance, hit the DC, and got jumped up the queue, leaving the poor Python saying 'A bit of time to relax is good... '