Oolite Bulletins

I've been mucking about with Oolite's source code, and added a couple of features people may like. I've put the patch on Google drive here (this is against the SVN source code):

https://drive.google.com/file/d/0B5m1zB ... sp=sharing

The features in the patch are:

1) I've made the joystick response non-linear in precision mode, so that the stick is less jumpy around the centre while still allowing the full range of movement if you move it to extremes. There are in fact four options to choose from, controlled by the STICK_NONLINEAR_OPTION parameter in OOJoystickManager.h. Setting this to 0 keeps things as they are. Setting it to 1 keeps normal mode as is, while making precision mode nonlinear. 2 makes normal mode nonlinear while keeping precision mode as is (for comparison purposes) and option 3 makes both nonlinear but precision mode more so.

2) I've added a new docking mode, which basically disables the roll dampers when activated, so you spin at a constant rate. This may make docking too easy - I've managed to dock using the keyboard using it without any trouser accidents. Anyway, I've randomly assigned it to the % key, or you can select a button in the joystick config. You can disable this feature by setting ENABLE_DOCKMODE to 0 in PlayerEntity.h.

Give it a go, see what you think.

Straight in with the boffinry, eh? Welcome aboard!

Welcome aboard, kanthoney! Way to make an intro!

I like the sounds of what you've done with the joystick code.. am inclined to agree that the keyboard tweak would probably make things too easy..

It would be nice to see joystick code unified across platforms. The Mac joystick code (src/Cocoa/OOMacJoystickManager.m) is already nonlinear, and has no precision toggle. The nonlinearity allows pretty good precision even with a game pad, although a smoother transition from the dead zone would be good.

Welcome to the board!

I don't have a joystick, so I can't test the first one, but as Jens says unified joystick code would be a very good thing.

On the second one, being able to lock your current turn rate with keyboard seems good - since you can already do it with the mouse and joystick, more or less - but I think rather than a toggle for it, what about a slightly different approach: thinking back to this thread, at the moment if you press both of an opposed pair of turn keys, you end up with a very slight turn rate in the direction of whichever key Oolite processes second, which is a bug. If that instead just kept your turn rate constant at whatever it currently was, then it would fix a slight oddity with the controls and provide roll control for docking without needing a toggle (and also let you lock pitch and/or yaw too, which might occasionally be useful). Is that approach something you'd be interested in looking at?

kanthoney wrote:

(this is against the SVN source code)

We really should get around to updating the Wiki pages to refer to the latest git repository instead - the SVN code is several months out of date. Sorry about that. (That area of the code hasn't changed that much, though)

Just to be clear - the docking mode applies to the joystick as well as the keyboard. It means that instead of holding your stick at a constant angle, you set the rotation using the stick and then centre it, which is much more civilized. The reason I mentioned the keyboard is because keyboard docking is horrendous if you're not used to it, yet I managed it first time using the tweak, so it might make things too easy.

One option is to add a piece of equipment that enables this for a couple of hundred credits, to give the Jamesons something to aspire to while they're saving up to buy a docking computer.

Where's the git mode repository? I'll check it out, and have a look at the keyboard option you mentioned.

Jens - I didn't know the Mac joystick code was different, so I might have broken that. Although looking at it now, I see OOMacJoystickManager inherits from OOJoystickManager, so I might have got away with it...

The transition out of the dead zone with the patch is super-smooth.

kanthoney wrote:

Just to be clear - the docking mode applies to the joystick as well as the keyboard. It means that instead of holding your stick at a constant angle, you set the rotation using the stick and then centre it, which is much more civilized. The reason I mentioned the keyboard is because keyboard docking is horrendous if you're not used to it, yet I managed it first time using the tweak, so it might make things too easy.

One option is to add a piece of equipment that enables this for a couple of hundred credits, to give the Jamesons something to aspire to while they're saving up to buy a docking computer.

Highly useful features not coming as standard and having to be bought is something of an Oolite tradition.

I don't necessarily mind docking being easy, either - for a genuinely new pilot, it's still a challenge because of "how do I fly this thing" and the need to then do so very precisely - better controls won't make that much difference, though they might turn a collision into a merely tense landing.

kanthoney wrote:

Where's the git mode repository? I'll check it out, and have a look at the keyboard option you mentioned.

https://github.com/OoliteProject/oolite for the main repository. We keep various components in submodules so remember to run git submodule update --init after getting it.

It might be worth looking at the comments on https://github.com/OoliteProject/oolite/issues/18 as that also relates to joystick configuration.

kanthoney wrote:

Just to be clear - the docking mode applies to the joystick as well as the keyboard. It means that instead of holding your stick at a constant angle, you set the rotation using the stick and then centre it, which is much more civilized.

Hmm.. I'm not entirely sure how I feel about that.. firstly, it seems rather counter-intuitive, as in normal flight, the way to cancel rotation is to centre the stick, and secondly, I sometimes use precision mode in combat.. if I understand you correctly, in order to cancel rotation, I would need to apply counter-rotation to the exact same value as the initial rotation.. it occurs to me that EXACTLY cancelling the initial rotation might prove to be extremely fiddly..

Diziet - the docking mode thing is separate from the precision mode tweak. You only turn it on while docking!

Ah.. my mistake.. thanks for the clarification!

So you have to manually activate it before docking?

Yep - line up with the space station, hit the % key, and your roll dampers are turned off. Move the stick right until you're going slightly faster than the station, then centre the stick. When you've caught up with the station's roll, flick the stick slightly to the left to slow down to the same roll as the station. You won't get the roll exactly right, so it's still a little fiddly, but it's less prone to going catastrophically wrong.

You can have the precision mode on at the same time, for precise docking.

And yes, I did remember to turn off docking mode once you've actually docked, although you can turn it off manually, of course.

I haven't added anything to the HUD that lets you know you're in docking mode. I should probably do that.

I've separated the patch into two (as it's two different features). These are against the main git branch:

Nonlinear joystick: https://drive.google.com/file/d/0B5m1zB ... sp=sharing
Docking mode: https://drive.google.com/file/d/0B5m1zB ... sp=sharing

I've also juggled the joystick code about a bit to fit in better with the link cim mentioned.

Also, what's the best place to send patches in future?

kanthoney wrote:

Also, what's the best place to send patches in future?

Thanks for these patches. I would say the best way to submit future contributions would be via pull requests on github. For more information on how to get set up for this: https://help.github.com/articles/using-pull-requests.

Do you intend to submit contributions to the project frequently? If so, let us know and we can maybe organize a more permanent way for ensuring that this happens.

The easiest way for us to deal with submitted patches is if they're submitted as a pull request on Github (one per feature). This has some nice tools for doing code reviews, and lets us pull the commits into our local copies as a branch for easy testing and merge the changes in automatically once they're ready, and also means you get credited on the commit as the author. If you don't have a Github account (and don't want one) then patch files like these are fine - it's just a bit of extra work for both of us if any changes are needed.

(We should really have this all documented somewhere...)