Oolite Bulletins

I tried out the Mouse Control feature of Oolite today. I have some suggestions. First of all, Most Mice today have a scroll wheel. Why not make this control the speed? And second, many mice have web navigation buttons on the side. They're just two small buttons where the thumb can easily get to them. How about linking them to the Torus drive and the fuel injectors?

Mouse wheel controlling speed when mouse control is active is coming up.

As for the other mouse buttons, sorry. I don't have a new fancy mouse here so I cannot test at all. It should be possible to do though, although the question then becomes: why torus and injectors and not something else.

another_commander wrote:

Mouse wheel controlling speed when mouse control is active is coming up.

Great news! I am another mouse commander so I am really looking forward to this

You should be able to test it in tomorrow's build.

Note: Not available for Mac, since mouse wheel support has not yet been coded in for this platform.

Great, I will give it a try and report any issues. Many thanks.

another_commander wrote:

You should be able to test it in tomorrow's build.

Working like a charm, thanks for yet one more new feature!

Working like a charm...

<nods>

another_commander wrote: ↑Sat Jul 22, 2017 11:37 am

Mouse wheel controlling speed when mouse control is active is coming up.

As for the other mouse buttons, sorry. I don't have a new fancy mouse here so I cannot test at all. It should be possible to do though, although the question then becomes: why torus and injectors and not something else.

So make it configurable. I said Torus and Fuel injectors because that would allow for almost keyboard-less flight. Someone else though may want to use them to arm and fire missiles, or who knows what else.

As for fancy mouses, I saw several cheap mouses yesterday at Walmart that had the 2 side buttons. They are usually programmed for web navigation.

byronarn wrote: ↑Sun Jul 23, 2017 7:33 pm

I saw several cheap mouses yesterday at Walmart that had the 2 side buttons.

I bought mine in a local megastore (Auchan) with Laser sensor (2000dpi), two additional buttons on left side and was only $7. Thank you China!

byronarn wrote:

So make it configurable. I said Torus and Fuel injectors because that would allow for almost keyboard-less flight. Someone else though may want to use them to arm and fire missiles, or who knows what else.

In the meantime, you can also use a program to assign a keyboard key to a mouse button. On Linux, you can use xbindkeys, and I am sure something like this exists also for Windows and OS X.

another_commander wrote: ↑Sat Jul 22, 2017 7:17 pm

Note: Not available for Mac, since mouse wheel support has not yet been coded in for this platform.

I can implement this for Mac, but how is it supposed to work?

When I get a scrollWheel event, it comes with a delta, which has greater values when turning the wheel faster. But the interface is such that I can only report up/down/neutral.

I can make it so that if I get a larger delta, it keeps reporting up/down longer before it starts reporting neutral again. But this means lag.
If I don't, it takes a lot of scrolling to go from stationary to full speed.

Alternatively, I can make it so that when you 'nudge' up or down from neutral, it keeps reporting that direction until you nudge in the opposite direction, and then go back to neutral, essentially making the wheel a 3-position rocker switch.
[EDIT} The rocker switch approach would be horrible for chart zooming though.. [/EDIT]

This part from the SDL library source shows how it is supposed to work on Windows: The variable move contains the delta value of the mousewheel movement, but as you can see it is not used for anything other than determine whether the wheel was moved up or down. This is what is returned to the game and this is basically why the game interface is designed with three states in mind: up, down or neutral. I guess that in order to make it behave the same on the Mac, you just need to handle it similarly, i.e. if delta > 0 send a wheel up state, if delta < 0 send a wheel down and if delta == 0 send state neutral.

Actually using the delta value could be a good idea, but it means that we would have to rebuild SDL for Windows (and most probably Linux too) to somehow keep track and return also the value of move above.

Thanks. That looks simpler than what I came up with in the mean time.

Please have a look at this: https://github.com/jobi-wan/oolite/comm ... 6401c4322d
It takes into account the delta-Y of the scroll wheel event, and for damping it takes into account the delta-T of the game tick.
I tried to do a best-of-both-worlds: the delta determines how long it keeps reporting up/down, but moving in the opposite direction resets it immediately, much like the keyboard controls do, although these obviously don't have a delta.

(I have a plane to catch [no, not Delta ] and will probably not be able to respond until later tomorrow.)

From a very quick look, it appears functional, but I am not sure about the GameController entry, maybe that needs to be guarded with #ifdef for Mac-only use.

We can take a closer look at this once 1.86 is out. This could be the first 1.87 feature.

Yes, this does not compile where gameView has no updateControls. #if OOLITE_MAC_OS_X -ing it would make it compile.
But it would be nicer if I didn't need it at all.


Edit to add: This one is much more in line with the implementation on SDL:
https://github.com/jobi-wan/oolite/comm ... bb5d816b01