[simpits-tech] Falcon4 BMS: pit builder news

[Joseph Fagner]

Mark, that is great news for us pit builders, absolutely fantastic.  I might
just have to break done and get an EPIC since now there is a way to sync all
buttons.  This is some of the best news (short of the MFD issues) that we
could have ever expected.

Jay

-----Original Message-----
From: simpits-tech-bounces at simpits.org
[mailto:simpits-tech-bounces at simpits.org] On Behalf Of Mark Doran
Sent: Thursday, February 26, 2004 3:48 PM
To: simpits-tech at simpits.org
Subject: [simpits-tech] Falcon4 BMS: pit builder news

This is long so I apologize in advance for that but I hope those of you
working with hardware to control Falcon4 will find this useful.

The next version of the BMS exe for Falcon4 will provide some interesting
new facilities for the cockpit builder.  In particular, DirectX game
controller support has seen radical improvements which may have far reaching
effects on the way cockpit builders approach control inputs to the game.

BMS will now support up to 16 game controllers connected to your Windows
system.  Each of these can materialize 8 analog axes and 32 buttons.  The
current exe in testing supports mapping controls to 21 analog axes (or not
quite three full controllers' worth):

- Aileron
- Elevator
- Throttle
- Second throttle (for twin engine jet wimps <GDR>)
- Rudder
- Left Toe brake
- Right Toe brake 
- Hands-on-gain knob (aka RNG)
- Antenna Elevation
- Cursor "microstick" Fore/Aft
- Cursor "microstick" Left/Right
- HUD SYM/brightness
- Manual reticle depression
- Trim yaw
- Trim roll
- Trim pitch
- COM1 volume
- COM2 volume
- MSL volume (AIM-9 growl)
- Threat volume (RWR)
- Field of view

In addition, for the throttle axis, there is now the ability to map an
analog value on the axis travel for the idle/cutoff point.  It's just like
the afterburner detent except it sets the minimum (70% RPM) point on the
throttle curve.  The exe can be configured to use this point instead of the
old SP3 idle/cutoff key.  This is much more "natural" for engine start and
shutdown when you are working with a physical control that has the
mechanical "gate" that separates the idle/cutoff region of throttle travel
from the "idle RPM" point.  Startup sequence in this case for example calls
for engaging the JFS engine, waiting for ~25% RPM on the main engine and
then simply moving the throttle forward past the idle cutoff point whereupon
the engine lights off.  Similarly, when you retard the throttle back past
the idle/cutoff point, the engine is starved of fuel and it will shutdown.  

Use this feature with caution if you don't have a physical end stop for the
idle point - it's pretty easy to over do "slamming the throttle to idle" in
a dogfight to control overtake only to find yourself flying a glider if you
pull the handle past the idle point - using a Cougar for testing this code
I've already had this embarrassing experience!!  BTW, you set the
idle/cutoff point on the throttle the same way as the afterburner detent
except using the right mouse to click instead of a left click.  The idle
"line" is red where the AB one is green in the setup/controllers page
readout.

Most of the other new analog axes do the thing you would expect.
Exceptions.  The right toe brake channel is not active yet, we don't have
differential wheel brakes - the left channel effectively operates both
brakes simultaneously with equal pressure for now.  The Field of view gives
you an analog control to sweep the out-the-window view from the minimum 60
degree view field to whatever max width you set.

Oh, and I had better say now that the hands-on-gain knob aka MAN RNG knob
does *NOT* -- repeat *NOT* -- affect the range of the radar display in
anyway shape or form in any operating mode.  This matches the current
behavior of the knob in the USAF fleet and MLU jets elsewhere in the world.
Any issues you have with that should be directed to Lockheed Martin not BMS!
;-)

Last point on analog channel mapping: in the game setup user interface, each
controller is numbered so you can assign any of the mappable axes to any
physical axis on any of the supported 16 controllers.  Yes, that would imply
you can have pitch/roll and rudder controls, say, on separate controllers.
The weirdness with throttle axis disappearing if you connect more than one
DirectX game controller is also definitely history.

The other interesting dimension here is DirectX buttons as input mechanism.
The game now supports 512 separate joystick button inputs across the 16 game
controllers you can use.  This has very interesting potential for anyone,
like me, that has been frustrated with using keyboard (or more precisely
keyboard emulation) inputs to the game with variable results and varying
degrees of stuck mode keys etc.  Support for all those DirectX buttons now
means that you can completely control the game in flight without even one
keystroke input!

Having tried it out now, I have to tell you it's faster and more precise and
completely cures the issue with stuck or conflicting mode (CTL, SHF, ALT)
keys for control chording (if you've tried moving the airbrakes at the same
time as the target management switch with the default keystrokes.key file
you will know what I mean! ;-).

For the pit I am helping to build, we are planning to use 390 commands from
the set of over 700 that the BMS exe now supports.  This is basically all
the ones that place switch and knob controls in each of their discrete
positions plus the set that you want to have to manipulate in game views.
In terms of the game configuration to make this work, all you have to do is
place a set of lines at the end of the keystrokes.key file that describe the
internal Falcon4 commands that you want bound to each DirectX button.  The
buttons are named by number, 32 per controller starting from zero on the
first button of the first controller and monotonically counting up (add one
each time ;-) from there.  A couple of sample lines:

    SimCATI 64 -1 -2 0 0x0 0
    SimCATIII 65 -1 -2 0 0x0 0

What these lines do is bind the two positions of the stores config switch to
DirectX buttons 64 and 65 respectively which themselves are the first and
second buttons on the third controller that shows up in the Windows control
panel "game controller" applet.  Note that in doing this you are adding to
the keystrokes file so that file is 100% compatible with existing key
bindings (we found that this can be useful for testing if you occasionally
want to operate a control from a real keyboard rather than have to jump into
your pit sometimes).  Everything that appears after the "64" and the "65" is
the same for every line, BTW; "boilerplate" if you will.  The only real
gotcha appears to be that there must be one blank line at the end of the
file.

I'm sure there are solutions for this that don't use EPIC but since that's
the controller I'm working with, here's an example of how to take advantage
of this in EPL coding.  The EPIC USB can materialize multiple DirectX
controllers for you simply by placing "device" declarations in your code.
You can use the syntax of:

    #pragma hid_rpt_snd 13

To limit the number of devices Windows will see (I use 13 right now to cover
the 390 buttons I need).

Once again there are probably lots of ways to code this in EPL but I am
using a technique that maps all the DirectX buttons to "virtual" EPIC
devices rather than direct to physical switch MRBs - this allows logic code
to control whether or not you "press" a DirectX button.  That is
particularly important if you want to use techniques found in ThrustMaster
controller programs for Falcon4 that allow you to use one of the stick
buttons as a "shift" key to produce different inputs to the game from the
same button elsewhere on the stick and throttle depending on the shift
button state.

Combined with the fact that there are now in-game commands you can bind that
put the game controls in each and every separate position, this is in effect
one step closer to a command message passing paradigm than previous keyboard
based approaches that in many cases relied on "toggle" commands that easily
fell out of sync with your hardware.

  // I've done my best to get this code right but I haven't compiled it...
  // may be a little bit off but it should give you the general idea I hope

  // Make EPIC produce 3 DirectX game controller devices for Windows
  #pragma hid_rpt_snd 3
  
  // make EPIC slow-rate scan module one rows 0-15 for actual hardware 
  // switches
  definemodule(1, 1, 0, 16)
  
  // connector defines which 8-bit rows have switches connected
  connector(FIRSTEXPANSION)
  {
    modrow(1, 0);
    modrow(1, 1);
  };
  
  // connector for devices that are pure virtual, i.e. no physical hardware
  // start with a high number like 16 so that you don't bump into MRB 
  // address space that you want to use for real EPIC h/w modules
  connector(VIRTUALDEVICES)
  {
    modrow(16, 0);
    modrow(16, 1);
  };
  
  device(DirectX0)
  {
    connector(VIRTUALDEVICES);
    // analogs and buttons go here
  };
  
  device(DirectX1)
  {
    connector(VIRTUALDEVICES);
    // analogs and buttons go here
  };
  
  // now third controller device has 32 buttons starting at #64
  // since no "procedure" code is defined for the entries
  // in this device, EPIC assigns them as DirectX buttons
  device(DirectX2)
  {
    connector(VIRTUALDEVICES);
    definebutton(0, 0, SimCATI);
    definebutton(0, 1, SimCATIII);
  };
  
  // end of virtual devices, now for the ones that have real switches
  
  // For the sake of example, say I wired the stores config switch with
  // a single EPIC input bit at Module 1 Row 1 Bit 6 and the "on" throw
  // matches the CATI position with the "off" throw matching CATIII
  
  device(LandingGearPanel)
  {
    connector(FIRSTEXPANSION);
    definebutton(1, 6, StoresConfig);
  };
  
  // "pulse" turns the DirectX button on and off, you can also use
  // "= on" to turn on and "= off" to turn off if you need more of
  // a press-hold-release kind of effect
  
  Void LandingGearPanel.StoresConfig.On(void)
  {
  	DirectX2.SimCATI = pulse;
  }
  
  Void LandingGearPanel.StoresConfig.Off(void)
  {
  	DirectX2.SimCATIII = pulse;
  }

What this does is watch a switch wired at EPIC M1R1B6 and when it sees the
switch flip to "on" it blips DirectX button 64 which the keystrokes.key file
lines above bind to the command to put the Stores Config switch in the CATI
position.  Similarly when the physical switch returns to the "off" position
the EPL code blips DirectX button 65 which puts the game state back to
CATIII.

Notice also that as soon as you move any physical switch programmed like
this, the game state is automatically synced to your physical switch state.
In other words, if the game thinks the jet is set up for CATIII and you move
the hardware switch to the CATIII position, the button 65 command will do
nothing in the game since the jet is already configured that way already.

I mentioned this elsewhere before but for completeness I'll repeat it here
with the DirectX button variation on syntax.  You can also use this EPL
technique to make a single control that automatically syncs the game to your
hardware switch state.  In our code we have a "sync" button in the ICP (we
use the WX button in fact):

  void dIcp.sync.On(void)
  {
    // ...

    if (LandingGearPanel.StoresConfig)  // is "on"
    {
      DirectX2.SimCATI = pulse;
    }
    else  // switch must be in off position
    {
      DirectX2.SimCATIII = pulse;
    }

    // ...

  }

It's kind of a long function but if you do the same technique for all the
MRBs that you have wired, one button press after you enter the cockpit will
completely sync the game and your switches at any time.  NB: this doesn't
protect you from something bad happening if you have your hardware switches
set in some funky configuration that breaks the jet...the sync procedure
does just that -- it's up to you to make the physical switch state a set of
safe-to-use position combinations!

Let me know if you have questions on any of this.  Hope all you Falcon4
drivers will enjoy the results :-)

Cheers,
 
Mark.

_______________________________________________
Simpits-tech mailing list
Simpits-tech at simpits.org
http://www.simpits.org/mailman/listinfo/simpits-tech
To unsubscribe, please see the instructions at the bottom of the above page.
Thanks!