Re: [Plib-devel] Re: control abstraction, continued (ad infinitum)

[Steve B. <sjb...@ai...>]

James Turner wrote:

> Okay the reason for my 'heavy handed' interface is being my goal with
> the APIs was to be able to build a GUI pretty mucch exactly like Fly!'s
> or FS2000's.

I don't know either of those.

> With a system as 'lose' as you propose, that won't be
> possible.

Explain?

What I propose would have a standardized (external) GUI tool for
setting up all the controls for *any* game.  If one specific
game wanted to have a GUI interface for tweaking it's controls
then it could simply call the API to write out the current
control settings to disk, then invoke the external GUI tool - and
when that exists simply read the file back in again to make the
new control setting active.

> Certain parameters are fixed for the control by the program, such as the
> step size and scale, whether the axis is positional or velocity, and
> having them in the control file seems pointless. (or for digitals,
> whether it is debounced)

Well, the range of a variable certainly needs to be controlled by the
application - we don't want the user to be able to configure his throttle
to deliver 200% of the maximum that the real plane has.

Personally, I'd keep things simple and have EVERY analog variable have
a range of either 0..1 or -1..+1 and let the application multiply that
by whatever it needs...however, it wouldn't hurt for the library to
handle all that stuff internally.

The step size should *certainly* be under user control (although the
application should be able to provide a default in the control file).
Some people will want to be really careful fliers and will want minutely
accurate control over (say) the flap settings - others will be 'fun fliers'
who won't want to have to push the 'Flaps-up-a-bit' button 20 times to get
from full down to full up.
 
> Further more, in order to provide a sensible GUI, the list of analog and
> digital inputs need to be complete; so the bindings which are 'legal'
> need to be specifed by the program.

Yes.  I agree.
 
> Eg for a 'flaps' analog axis, probably the 'important' bindings are
> increase and decrease; 'center' is probably useless. But without the
> program specifying these, the GUI must list all possible digital
> bindings on every analog axis. (Currently that's 5 possible bindings for
> every analog)

That doesn't seem too onerous - and the application should come delivered
with a file of 'sensible' settings.  If the flaps don't need a 'center'
preset - then the application won't set it that way in the default settings
file - and the users won't bother to change it to have a 'center' preset
unless he has a good reason to do so.

> I'd much prefer to sacrifice some configurability in order to keep the
> GUIs nice and clean since I certainly can't be bothered hacking a config
> file. (But then, I did start coding on the Mac :-)

But you'll have to write a config file parser anyway so that you can make
changes to the setup persistant between sessions.  Without that, the whole
thing just becomes a pain in the ass.

If you are going to the trouble of writing a GUI then it might as well be
useful to every application by being a standalone program as be a one-off
effort.
 
> Seriously, I think that at least scale and legal linkages need to be
> specified:
>         flaps = ctlAnalog("Flaps", 0.0, 1.0, CTL_ANALOG_POSITIONAL);
>         flaps->addDigital(INC, new ctlDigital("Raise Flaps"));
>         flaps->addDigital(DEC, new ctlDigital("Lower Flaps"));  
> 
> The scale seems important to prevent the returned values exceding the
> range the simulation / game is 'expecting'. Similarly the pos /
> velocity selector would otherwise affect the code so allowing
> customization seems unwise.

Perhaps - but as I said, providing a standardized 0..1 or -1..1 range
as the interface between library an application solves that problem
completely.

You'll also need the option to have values that wrap around so you
can accept things like heading angles that go from +180 to -180.

> And I suppose having an 'advanced' GUI that allows things like step
> size, etc to be specified is doable, but I'd still prefer that sensible
> defaults were specifed so that I could just bind my favourite buttons to
> 'increase flaps' without worrying about choosing a step size.

But sensible defaults can be provided in the configuration file rather
than being an additional burden for the application programmer and a
vast complexifier to the API between application and library.

API's need to be kept as simple and clean as possible.

> You can tell I'm not a Unix coder; I'd much rather spend a day writing
> the GUI than an hour writing a parser for your text config file format
> ;-)

But it's not an either/or situation.  You have to be able to load and
save those settings - so you'll end up spending that extra hour writing
the parser anyway.

The difference between a UNIX coder and the 'other' kinds is that we
have a philosophy that every program (or library) should do one task
extremely well - and that large packages are made from lots of little
modules glued together.  UNIX has a rich set of intercommunication
mechanisms to make that easier - but Windoze is catching up.

In Windoze (and MacOS), the philosophy is that every single program
has every conceivably bell and whistle.  This results in the kind
of bloatware that M$ do best.

In this case, taking the 'user controls configurator' out of FGFS
and making it a standalone program - with a little more generality
than it would have needed otherwise - gets you to a situation where:

a) Application writers don't have to re-invent a configuration
   GUI for every single application.

b) Users don't have to learn how to configure each and every
   application using a completely different GUI each time.

I think this is just common sense...but YMMV.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)