External View Selection

[kanthoney]

The camera is now dependent on delta_t to fix the problem mentioned with low-end machines. This does break operation during pause mode, however.

[another_commander]

Good stuff and I saw that you re-enabled freelook while paused, which is sweet. I'll have to check the delta_t fix tomorrow, when I'll get my hands on a not-so-fast machine.

[Commander_X]

Heads up*: switching to other app -> switching off Caps Lock -> switch back to Oolite -> the external view camera motion won't activate (regardless of switching on and off Caps Lock).
[*]Tested on Windows 7/64bit; mouse switched, no Alt-Tab -- I'm usually running everything in windows.

[kanthoney]

That works fine in Linux. I haven't tried it in Windows.

I've fixed the problem with the annoying flickering with some camera angles, so that's one roadblock out of the way. It turns out it was my fault, of coourse.

[Commander_X]

True -- it works fine in Linux.

[another_commander]

Argh... If that Caps Lock state code works fine on Linux and not fine on Windows, then it means that the SDL implementation of how the keystate is handled must be different. I was hoping to not have to introduce more platform-specific code as a fix, but I am not in the mood to go debug SDL right now.

@Commander_X: in SDL/MyOpenGLView.m, isCapsLockOn method, could you try to replace

Code: Select all

return (SDL_GetModState() & KMOD_CAPS) == KMOD_CAPS;

with

Code: Select all

return GetKeyState(VK_CAPITAL) & 0x0001;

I believe this should fix it on Windows.

[Commander_X]

@Commander_X: in SDL/MyOpenGLView.m, isCapsLockOn method, could you try to replace

Code: Select all

return (SDL_GetModState() & KMOD_CAPS) == KMOD_CAPS;

with

Code: Select all

return GetKeyState(VK_CAPITAL) & 0x0001;

I believe this should fix it on Windows.

That it does. (didn't check the impact on Linux, though).

[another_commander]

This will not work on Linux, it is a Windows API call, but thanks for confirming. We can use separate code paths for Linux and Windows. Fix going in very soon.

[kanthoney]

I've added some mouse controls. Sorry if you were halfway through implementing them!

[another_commander]

Good thing you went ahead, between work and irrelevant bugs popping up I didn't manage to start doing anything. I just tested it and it works OK, but... (drum roll) there is a little bug related to mouse control. The camera requires the left mouse button to be pressed in order to be manipulated, but when in mouse control, left button is also the main weapon. So the ship fires continuously (and moves too) while the camera is moving around it, which is probably not what we want to have. A possible fix could be to deactivate mouse control when Caps Lock is down in external views.

[kanthoney]

Ah. Yes. That would make for better screenshots, though, as hordes of angry pilots descend on you...

The problem with disabling the laser when caps lock is on would be if you forget to put caps lock on (as I'm always doing) and then shoot the station you're lining up for a screenie. We could disable the mouse button for firing in external view mode, and if you really need to fire then use the keyboard.

[another_commander]

Hmm, not sure. This would probably confuse people who expect the laser to fire when they click. Having conditions such as "you can fire but only if not on external view" sounds to me like complicating things. The interface should be as uniform as possible. Additionally, it is not only a problem of the LMB, the entire ship is moving while the camera is moving in mouse control so disabling only the laser would solve only part of the problem.

When in mouse control, moving the mouse should move the ship and enable fire in both internal and external views, because this is what has been happening till now. Moving forward, we could consider disabling mouse flight in external view at the moment the player toggles Caps Lock and at the same moment passing control of the camera to the mouse, without the need to have mouse button down. This would make it similar in functionality to the keyboard equivalent. We could use the right mouse button to re-center the mouse, just like we do in normal flight, for making extended length camera rotations. This would also release Shift for using it for e.g. rolling the camera left/right when it is held down and the mouse is moved left/right. Toggling Caps again would pass control from the camera back to the ship.

This is just a few thoughts thrown together; we need to think about it a bit, I guess. I think it is important that the interface remains as uniform as possible and as close as possible to what people are already used to.

[another_commander]

Just tested with (example for roll)

Code: Select all

if((((mouse_control_on && !mouse_x_axis_map_to_yaw) || numSticks) && !keyboardRollOverride) && !capsLockCustomView)

instead of

Code: Select all

if(((mouse_control_on && !mouse_x_axis_map_to_yaw) || numSticks) && !keyboardRollOverride)

and repeated for pitch, yaw and fire laser controls and the result looks pretty good now, without having to go into great further modifications.

[kanthoney]

I've just tidied the code up a bit (removing magic numbers, that sort of thing). We just need to add your laser fix and probably tweak a few parameters and we should be ready to think about merging.

[another_commander]

OK, fix is in and as far as I am concerned we can go ahead and merge. I believe we can fine tune parameters better after getting input from our trunk users. I'll let the honor of merging to you. Great job.