each other out. The problem is this: if we press, for example, "Ctrl-a", but
release the "Ctrl" modifier button *before* the "a" button (which nobody does
intentionally, but which happens all the time), then we don't get the RELEASE
signal on "Ctrl-a" (keycode 1), but on the "a" (79). But "a" hasn't been
pressed, so the signal is dropped. And who releases "Ctrl-a"? Nobody!
So the next PRESSED signal for "Ctrl-a" is ignored, too. It is still
"pressed" after all, isn't it? That's the reason for the occasional
non-functioning of keys.
Due to the nearing 0.9.9 release, I only commit a crude last-minute fix.
It's not as intrusive as it looks, and shouldn't be "dangerous" at all.
It only makes sure that when we get an unexpected RELEASE for one letter
key ("a") that the two twins "A" and "Ctrl-A" are released if they are
still in "pressed" state.
The proper fix will be to let fg_os{,_sdl}.cxx always report presses on the
same key ("a", "Shift-a", "Ctrl-a", "Alt-a", and other combinations of
modifiers) as the *same* key (97), only with modifiers appropriately set.
- automatic detection of axis directionality, so that axis inputs are appropriately inverted only when necessary
- fixed trim axis names for better understandability
- fixed signs for flaps up/down property increments
- button 0 was previously used for skipping axes and buttons in both loops. Now button 0 can be assigned a binding (e.g., brakes). Instead, moving any axis during the button-assignment-loop indicates skipping.
- The user is now told how to skip a control.
- use new removeChildren() to remove the named js nodes that we don't
need any more (they are now *really* removed, not just detached), and
- move it into postinit(). (getChildren() returns a SGPropertyNode_ptr,
so all nodes are refcounted and, thus, after the last sg/props change
no longer removable in that scope ;-) Maybe we'll need an alternative
getChildren() that returns SGPropertyNode* ...
- This doesn't do what the author though it would do:
if (modifiers&KEYMOD_RELEASED == 0) ... (see below)
- MSVC and type fixes
mf:
fixing this uncovered an old bug: the "key pressed" branch was
actually never executed -- always only "released". And that is why
the <repeatable> property didn't work. And *that* was the reason
why the Spitfire's starter didn't work with freeglut, and Vivian
had to write a nasty workaround for it.
block (this required to move most of init() into postinit())
- undo the "which" pseudo-namespace workaround, and do it proper:
- let all nasal code in a joystick config file be executed in its own
namespace. This allows to define functions in the init block that
can be used throughout the driver file, and to write state variables
in one binding, while reading them in other bindings, all without
having to make sure that the values aren't lost in between, or collide
with another joystick driver's code.
For this the input subsystem creates a namespace for each joystick:
"__js0" for joystick 0, etc. The two leading underscores are there to
avoid collisions with user defined modules (similar to internal compiler
variables). The namespace shouldn't be used explicitly, at least not in
releases, and not from outside code, except for testing purposes, for
which it can be useful. (If using the Cyborg joystick as js[0], you
can read the modifier level as "__js0.modifier" from any nasal context.)
to the joystick index (x in /input/joysticks/js[x]) both when initializing
nasal init blocks & whenever updating the joystick. That's the only way to
make these nasal contexts aware of the joytick for which they were called.
And that's useful if a js maintains common variables, such as modifiers or
state variables, that should be shared between the namespace-less bindings
and initialization code. And, yes, it's over-engineered ... :-)
its own data, and can distinguish itself from other instances of the
same js driver. This property is removed after script execution.
Example:
self = props.globals.getNode(getprop("/input/joysticks/this"));
(no need to list the paths explicitly in $FG_ROOT/joysticks.xml any more)
- move identified js nodes to /input/joysticks/js[0-9], but
- don't overwrite already set joystick data there
- remove all nodes when they aren't used any more
- add "id" node, which contains the js id that lead to the selection
of a "named js" config
- add "source" node containing the path of the used js config file
- execute all nasal script groups at initialization time
input.cxx allocates memory for js->getNumAxes() axes and for jsCaps.wNumButtons
or MAX_JOYSTICK_BUTTONS buttons per joystick. But it doesn't check if some
xml config defines bindings for more axes/buttons, in which case it writes
to unallocated memory and causes crashes. This is a real world example:
sidewinder-force-feed-pro.xml defines 7 axes, but only newer versions of
this js do actually have that many. Older ones (-> gameport) don't. The patch
drops unused and unusable bindings.
motion.
- Track a timeout value so we can optionally hide the mouse pointer after
some user specified timeout period.
- in doMouseMotion() always update m.x and m.y even if we return early because
pui wanted the event. Without this, we can't reliably detect motion vs.
inactivity.
- in _update_mouse() add a dt parameter so we can decriment the timeout value
in "real" time.
- in _update_mouse() optionally hide the mouse pointer if m.timeout goes to
zero. Restore the pointer (and the timeout counter) if the mouse is moved.
anymore. Instead Frederic Bouvier suggests to add a <number> tag to
the axis definition which accepts values for <windows> and <unix>
for now but which can be extended later on:
<axis>
<desc>Rudder</desc>
<number>
<unix>2</unix>
<windows>3</windows>
</number>
<binding>
<command>property-scale</command>
<property>/controls/flight/rudder</property>
<offset type="double">0.0</offset>
<factor type="double">1.0</factor>
<power type="double">2.0</power>
</binding>
</axis>
command bindings accessible from XML. This still probably isn't a final
solution (which would drive the HUD from propery values), but it's a step
in the right direction anyway.
the keyboard modifiers outside of a key event handler, so adding the
fgGetKeyModifiers() call to doMouseMotion was broken. The user could
see "phantom" modifier keys.
controls in the cockpit vs. which wheels they apply to. FlightGear now
sets /controls/gear/brake-left, /controls/gear/brake-right, and
/controls/gear/brake-parking. It should be up to the FDM to sort out
which wheels under which circumstances are affected by these controls
and ultimately what happens to the physical motion of the aircraft.
to handlers which might want to assign it to a SGPropertyNode_ptr for
reference counting (Nasal does, for instance, to prevent garbage
collector interactions). If that smart pointer is then destroyed,
that will free this object while it is still live.
Simply use a SGPropertyNode_ptr here; the code ends up smaller as a
bonus, since FGBinding no longer has to deallocation for _arg.
Frederic Bouvier:
First, MSVC 7 bombs when a value greater than 255 is passed to
issomething(), so I copy k to a char (unsigned ) kc before calling
them.
Second, with my french keyboard, and I thing this is the same for
a great number of countries, some characters from the regular ASCII
set can only be get with ALt Gr that appears to be CTRL+ALT.
Especially, I can't select the second engine because '@' is
AltGr+'' nor all because '~' is AltGr+'' (and I have to hit space
after otherwise I can get or that are not used in french) and
FG try to cope with the modifiers.
So, currently, we have to mask out CTRL and ALT modifiers when they
are together. The current bingings don't allow 2 simultaneous to
be declared so it shouldn't break anything.
This patch adds an "interval-sec" property which allows fixing an interval in seconds (or fraction of seconds) for the repeats for emulated axis controls (digital hats) on joysticks.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
Here are the two modifications I had to make to get flightgear (just
updated from CVS) to build. The first one is for being able to specify
SimGear's location at the ./configure command line, and the second one
is to be able to link.
menubar. This one allows regular command bindings, with the
(temporary) condition that every menu item must have a unique text
label. The new menubar is disabled by default; to enable it,
configure --with-new-menubar.
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
Indeed, there was no check for panel visibility in the input code. I
guess we've never noticed because nothing was fighting for the same
real estate in the past. This one-liner appears to fix the problem.
[also converted all tabs to spaces for Norm Vine]
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Removed configuration option --with-new-environment and
FG_NEW_ENVIRONMENT macro.
Added configuration option --with-weathercm and FG_WEATHERCM macro.
FGEnvironment is now the default; use --with-weathercm to get the old
weather.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
The FlightGear patch is to take account the change in the getChildren
function that now returns a vector<SGPropertyNode_ptr>. If the
removeChild functionnality is to be added in FlightGear, all those
SGPropertyNode * floating around should be changed to
SGPropertyNode_ptr.
MSVC fix from Bernie Bright:
You can keep the enum private if you add the following declarations
immediately afterwards:
struct mouse;
friend struct mouse;
It seems that MSVC doesn't grant the nested mouse decl. any special
access privileges to its surrounding class.
