1.77, problem docking, dying, reloading, crashing . . .

[cim]

Did you know the docking computer came with a free laser cooling booster? *sigh*)

Smivs hands cim a roll of gaffer tape to seal the can of worms...

*tape* *tape* *tape*

Right... where were we?

failing to rotate

Do you get a comms message along the lines of "beginning final approach" or "now entering Laenin space dock" at any point? Or do you just plough into the station before that happens?

[richard.a.p.smith]

failing to rotate

Do you get a comms message along the lines of "beginning final approach" or "now entering Laenin space dock" at any point? Or do you just plough into the station before that happens?

Hm. Not sure, I don't look at that text, usually, sometimes I notice it but you see it 10000 times and then you stop seeing it! Certainly such messages were appearing in general but whether it was or wasn't when crashing I'll need to check. It'll probably start working again now that a can of worms has been opened. Rich.
Okay I just tried three times at Laenin although it didn't crash. I got communications messages twice on each attempt which is normal. The autopilot is really having a hard time, it's all over the place, I think that is causing the crash, it isn't falling asleep/stopping its rotation, I think it's just trying to get the approach right but is messing up, then there's another problem that arises after the crash. The crashes occur when just before the entry point of the station dock it turns so far the Cobra won't fit and rams the station. Just now it started to rotate but after the entry point so the shields went and I lost some computers but didn't die. Rich

[cim]

The crashes occur when just before the entry point of the station dock it turns so far the Cobra won't fit and rams the station. Just now it started to rotate but after the entry point so the shields went and I lost some computers but didn't die. Rich

Could you check the frame rate at late docking stages, please? Low frame rate could cause autopilot inaccuracies, in theory.

I've been testing at Laenin and there have been no problems here for me.

[richard.a.p.smith]

The crashes occur when just before the entry point of the station dock it turns so far the Cobra won't fit and rams the station. Just now it started to rotate but after the entry point so the shields went and I lost some computers but didn't die. Rich

Could you check the frame rate at late docking stages, please? Low frame rate could cause autopilot inaccuracies, in theory.

I've been testing at Laenin and there have been no problems here for me.

I just tried twice at Laenin and the autopilot killed me both times. The first time the frame rate was resolutely at 99 although in the last 20 or so seconds I was distracted by, er, Kung Fu Panda.

I got the whizzing through space thing after pressing 2 right after the press space screen. Exit and reload Oolite.

The second time I paid more attention and it was resolutely at 99 right up to the point of death. This time, though, I pressed space, then 2, then I got the normal f2 screen.

Is all this related to my ability to not get a mobile telephone signal no matter where I am, what 'phone I have or what network it's using? Wolfgang Pauli was known for a similar sort of effect.

Rich.

[richard.a.p.smith]

I just noticed some more weird docking computer behaviour. This is a different saved game. I'd used up all the fuel with i and then wanted to hit c to go and get a glass of wine as soon as S appeared. It appeared, I pressed c. The station was right in the cross-hairs. The autopilot slowed down to a stop and pitched until the station was a red square about halfway under the mid-point of that little compass thing. A few moments passed and the ship accelerated to maximum speed until S disappeared. I've not seen this before. Normally in that situation the ship maintains maximum speed until the station is well within the main scanner display, then the autopilot does whatever it does. This is surely not expected behaviour. Whether it's related to the crashing I can't say but it is a bit of weirdness with the autopilot. Rich.

[richard.a.p.smith]

One other thing I'll do is put the game on a USB stick and try another machine with a different graphics chipset; this one is an Intel whateveritis . . . at least I think the other chipset is different. Rich.

[richard.a.p.smith]

It's not restricted to Laenin, I got the same thing at Anbeen with a different save game, but I don't know if I can see any sort of pattern except that whatever the problem is it comes up a lot at Laenin. Keep forgetting to try on a non-intel graphics machine, if I have one. Rich.

[richard.a.p.smith]

I just did two successful docks with an nvidia-equipped computer and am seriously beginning to think it's related to the graphics chip. Some suspicions before but there was much less realigning of the ship's attitude both times compared with the intel machine. Makes me think it's to do with how the thing is drawn by the graphics chip. Could it be something like this? The other difference between the machines is one's 32 and one's 64 bit. Rich.

[Diziet Sma]

It sounds like this would be a good moment to find out just what the problematic graphics card is.. could you please post the top portion of the Latest.log from that machine? Everything above the line "AddOns", please.

[richard.a.p.smith]

It sounds like this would be a good moment to find out just what the problematic graphics card is.. could you please post the top portion of the Latest.log from that machine? Everything above the line "AddOns", please.

Here it is! Thanks for responding. Rich.
Opening log for Oolite version 1.77 (x86-32) under Windows 6.1.7601 Service Pack 1 64-bit at 2013-03-27 23:35:05 +0100.
2 processors detected.
Build options: spoken messages, mass/fuel pricing.

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

23:35:05.718 [display.mode.list.native]: Windows native resolution detected: 1366 x 768
23:35:06.016 [joystick.init]: Number of joysticks detected: 0
23:35:06.017 [rendering.opengl.version]: OpenGL renderer version: 3.1.0 ("3.1.0 - Build 8.15.10.2361"). Vendor: "Intel". Renderer: "Intel(R) HD Graphics Family".
23:35:06.017 [rendering.opengl.extensions]: OpenGL extensions (102):
GL_NV_primitive_restart, GL_ARB_texture_env_crossbar, GL_EXT_abgr, GL_ARB_shadow, GL_IBM_texture_mirrored_repeat, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_EXT_blend_minmax, GL_EXT_draw_buffers2, GL_ARB_texture_env_add, GL_ARB_draw_elements_base_vertex, GL_ARB_sampler_objects, GL_EXT_framebuffer_blit, GL_EXT_transform_feedback, GL_ARB_texture_env_dot3, GL_EXT_framebuffer_object, GL_EXT_blend_subtract, GL_3DFX_texture_compression_FXT1, GL_NV_conditional_render, GL_ARB_vertex_array_bgra, GL_EXT_texture_snorm, GL_ARB_multitexture, GL_EXT_stencil_wrap, GL_ARB_texture_border_clamp, GL_ARB_framebuffer_sRGB, GL_ARB_texture_env_combine, GL_EXT_framebuffer_multisample, GL_EXT_texture_env_add, GL_EXT_packed_pixels, GL_SGIS_texture_edge_clamp, GL_ARB_depth_clamp, GL_INTEL_performance_queries, GL_ARB_uniform_buffer_object, GL_ARB_depth_texture, GL_SGIS_texture_lod, GL_ARB_occlusion_query, GL_ARB_transpose_matrix, GL_NV_texgen_reflection, GL_EXT_stencil_two_side, GL_ARB_seamless_cube_map, GL_ARB_shading_language_100, GL_ARB_texture_compression_rgtc, GL_EXT_gpu_program_parameters, GL_EXT_texture_shared_exponent, GL_EXT_rescale_normal, GL_ARB_map_buffer_range, GL_ARB_pixel_buffer_object, GL_EXT_secondary_color, GL_ARB_copy_buffer, GL_ARB_half_float_pixel, GL_EXT_blend_equation_separate, GL_EXT_draw_range_elements, GL_EXT_texture_lod_bias, GL_EXT_texture_filter_anisotropic, GL_ARB_half_float_vertex, GL_EXT_texture_swizzle, GL_SGIS_generate_mipmap, GL_ARB_texture_rectangle, GL_ARB_texture_non_power_of_two, GL_ARB_point_sprite, GL_EXT_packed_depth_stencil, GL_ARB_vertex_shader, GL_EXT_texture_compression_s3tc, GL_EXT_texture_integer, GL_ARB_depth_buffer_float, GL_ARB_sync, GL_ARB_draw_instanced, GL_ARB_vertex_buffer_object, GL_WIN_swap_hint, GL_ARB_color_buffer_float, GL_ARB_shader_objects, GL_EXT_texture_array, GL_ATI_separate_stencil, GL_ARB_framebuffer_object, GL_EXT_packed_float, GL_ARB_compatibility, GL_EXT_texture_rectangle, GL_ARB_texture_rg, GL_ARB_fragment_shader, GL_EXT_fog_coord, GL_EXT_texture3D, GL_ARB_window_pos, GL_ARB_fragment_program, GL_ARB_vertex_program, GL_EXT_texture_env_combine, GL_ARB_point_parameters, GL_ARB_texture_cube_map, GL_EXT_bgra, GL_EXT_compiled_vertex_array, GL_ARB_multisample, GL_ARB_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_texture_compression, GL_EXT_multi_draw_arrays, GL_ARB_fragment_coord_conventions, GL_ARB_texture_float, GL_EXT_blend_func_separate, GL_EXT_texture_sRGB, GL_EXT_shadow_funcs, GL_EXT_clip_volume_hint, GL_EXT_blend_color, GL_NV_blend_square
23:35:06.037 [rendering.opengl.shader.support]: Shaders are supported.
23:35:06.103 [searchPaths.dumpAll]: Unrestricted mode - resource paths:
Resources

[another_commander]

It is extremely unlikely to almost certainly impossible that the graphics card be responsible for weird autopilot behaviour. It has to be a game configuration related issue, be it OXP or core bug or whatever. The card itself just displays graphics and any non-conformance associated with it can result to crashes or graphics not showing up properly, but not changes to the way the game's logic works. The autpilot code is the same throughout all ports and gfx cards have no way of influencing it. At least that's what I think, based on the information I've seen so far and with just a few autopilot tests from my side (all of them successful). By the way, I am also running on an Intel HD gfx.

[richard.a.p.smith]

Hello

Thanks for the response. I am not saying it really is the chip, just that I can't see another explanation - there must be a reason, if the autopilot is not supposed to kill you at all then something about that installation is not working as it should.

The installation was 1.77 on the intel machine. With or without any oxps the autopilot keeps killing me and it seems to be at Laenin. Then there's this odd flying through space business, maybe that's separate, presumably is.

I copied the folder to a USB stick and using that on the nvidia machine I have no problems, admittedly with the oxps, not tried it without, but the same save game worked twice in a row whereas it killed me the previous two attempts on the intel machine.

In general with the nvidia machine there is still adjustment of the ship's attitude but not once it's inside the docking bay entry point and that is clearly what was happening when the crashes occurred on the other machine.

The reason for suggesting the chip was if there is something slightly different about the dimensions of the cobra, so it thinks the ship is off-centre when actually it isn't, or something like that, and tries to adjust. Like in some OSs/programmes, colour 0 is white but in others it's black, some little thing that the intel set does differently. Or it's a setting in the display which somehow upsets the routines for automatically adjusting the ship's attitude that is present on one but not the other. The display itself is very slightly different, with MilHUD the little circle showing planet/sun/nav beacon/etc is more clearly defined on the nvidia display and noticeably more blurred on the intel display - only a bit and most things appear okay.

The only other significant difference I can see is 32 bit vs 64 bit OS. There just doesn't appear to be any other possible explanation.

Ta, Rich.

[richard.a.p.smith]

By the way, I am also running on an Intel HD gfx.

Can you list the exact settings you use with the intel hd control panel? See if there's a difference? Rich.

[cim]

Then there's this odd flying through space business, maybe that's separate, presumably is.

Probably some values not being reset properly on death. Try the latest nightly build from http://terrastorage.ath.cx/oolite/status_win32.html and see if it fixes that one, as I did explicitly reset a few more.

I agree with another_commander that graphics card is phenomenally unlikely because of the way display code and simulation code are separated within Oolite. But, if we're looking for hardware differences, perhaps it could be a floating point calculation bug. Maybe there's some imprecision somewhere that most machines don't get (so CPU rather than GPU differences). Possible test for that: add the "Your Ad Here" OXP to get Constores at the witchpoints, and see if the DC can dock reliably with those at systems where the main station is risky.

[Cody]

Unconnected, but I had an oddity with the DC this evening (r5655) - it docked my Cobra III at a Griff Coriolis crossways to the slot (if you see what I mean). I rarely use the DC, so don't know if this is common or not. Are Griff's docks a trifle generous, size-wise? Even if so, it felt wrong.

Even more unconnected: I docked with the hud display disabled, re-enabled it after docking, and the previous comms messages/docking approach messages appeared at the top of the screen - and remained there, instead of fading away. Only way to remove them was to launch and hit the comms key.