Oolite Bulletins

This will take some getting used to (and plenty of testing), but I'm favouring a setting of 0.4 at the moment.

Anyone else been testing this? Any other comments? I see the default setting is 1, btw... yes?

Cody wrote:

I see the default setting is 1, btw... yes?

For now, yes.

cim wrote:

Cody wrote:

I see the default setting is 1, btw... yes?

For now, yes.

I use 1

I find strange to have accuracy depending on max_pitch value - the bigger pitch means lower accuracy. However, it should be exactly opposite.

Mad Hollander wrote:

I find strange to have accuracy depending on max_pitch value - the bigger pitch means lower accuracy. However, it should be exactly opposite.

I would expect more sensitivity in the centre zone, for those very fine twiddly sort of manoeuvres for what it's worth. I've not been testing this - been drawn back to the Dark Side - but it sounds very interesting and I'm looking forward to trying it.

Smivs wrote:

... been drawn back to the Dark Side...

<chortles> Have a cookie!

I've been using it on 1 as well. However, since Cody likes a lower setting, I vote for being able to set values via a slider or similar.

Smivs wrote:

I would expect more sensitivity in the centre zone, for those very fine twiddly sort of manoeuvres for what it's worth.

That's exactly what it does.. the further you deflect the stick from the neutral position, the less non-linearity is applied. It allows for very fine control, even set on '1'.. it's possible to apply very gentle pressure and have the crosshairs drift across the target so slowly that it takes a couple of seconds to be sure your ship is even turning at all.

Mad Hollander wrote:

I find strange to have accuracy depending on max_pitch value - the bigger pitch means lower accuracy. However, it should be exactly opposite.

The pitch value refers to the pitch rate of change.. so of course that translates to lower accuracy.. it's a measure of how quickly the ship's pitch can change, not of the accuracy factor. The lower the pitch rate-of-change, the better the accuracy.

Just to let everyone know, I'm working on a configurator screen for this, with more tweakable parameters, and allowing for different settings for each axis.

If things go *really* well, you could end up with an option for a spline-based profile, where you set lots of control points like the ones earlier in the thread. That might be a tad ambitious though. Wish me luck!

Wishing you LOADS of luck.. especially with that spline-based profile thingy! If you can manage it, that would be très cool..

Preview!

Here's the main joystick screen, with additions for deadzone setting and an option for editing joystick profiles:

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

Deadzone setting is obvious. Select the Edit Profiles option and you get this screen:

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

And here's the spline type profile option, with control points set by click and drag:

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

I've a few minor glitches to sort out, then it's onto a session of flight testing to make sure there are no hideous crashes (either of the program kind or the spaceship kind). Then I'll submit a pull request.

One of these glitches has me a bit puzzled, so I'd like to pick the brains of the main developers if I may. I've got a set of control points for the spline (each an NSPoint wrapped in an NSValue) stored in an NSArray, which I want to save in user defaults. However, my version of GNUstep seems to have a real problem saving NSValues in user defaults - even an innocent, do-nothing line like

[defaults setObject: [NSValue valueWithPoint:NSMakePoint(0.0,0.0)] forKey: @"Test"];

causes segfaults and exceptions and things. Is this a known problem? Or am I doing something noob? I'm running Linux (Slackware, but it's the same on my Debian laptop).

Looking good - well done.

Kudos! Those are looking really good!

The only request I have, is that you make the deadzone configurable for each axis separately, please.. some give more trouble than others.

(perhaps incorporate them with the axis profiles, rather than on the main page, if that makes it simpler)

Looking at those screenshots yet again, (can't help myself.. it's like a dream come true! ) I've just had a thought.. (and yes, in today's 41°C+ heat here in Australia, it hurt! )

Once implemented, this joystick profiler could do away with the need for precision-mode for joysticks.. which would be cool.. it would free up a button on my stick for other uses..

Thoughts and opinions?

kanthoney wrote:

Preview!

Wow! That's very impressive. Looking forward to seeing it.

However, my version of GNUstep seems to have a real problem saving NSValues in user defaults - even an innocent, do-nothing line like

[defaults setObject: [NSValue valueWithPoint:NSMakePoint(0.0,0.0)] forKey: @"Test"];

The problem is that NSValue is an opaque type - like the C void* though slightly safer - so its contents can't be reliably translated into the defaults, which can only store a few scalar types, arrays and dictionaries. Probably easiest would be to use a two-value array or an x/y dictionary for storage.

cim wrote:

Wow! That's very impressive. Looking forward to seeing it.

Hehe.. you'll have to buy a 'stick now, just so you can play with the profiler!