Note that this key does sometimes fail to work. This is caused by the
way our keyboard works ATM. On an (US)English keyboard : and ; are on
the same key. If you do Press-Shift >> Press-: >> Release-Shift -> Release-:
then not the ':' is released, but the ';'. The ':' remains registered as
pressed, so the next press fails. Another press restores the function.
We fixed this for the letter keys, as it is safe to assume that 'a' and
'A' are on the same key. Unfortunately, we can't make such assumptions
for non-letter keys. We should really track the HW-key numbers, not
the symbols printed on them!
dialog when one actually wanted to switch virtual desktops. There's no need
for a keyaboard shortcut, as the dialog is available from the menu and not
needed that often.
1) The chat menu will now select the runway closest to the aircraft
when the aircraft is on the ground, or very low (< 100ft). This
handles the case where the user has selected a runway explicitly,
e.g. 01R for KSFO take-offs for noise abatement. My thanks for
AnMaster for pointing this out on IRC. Note that above 100 ft, the
wind-appropriate runway will still be used.
2) Change to keyboard description for the - key, as pointed out by
Melchior.
- rename prop-key-handler.nas to prop_key_handler.nas (the hyphens were
intentional, exactly to *make* using it as namespace less inviting,
but times change ...)
- add property browser binding to the '/'-key for when the property key handler
is turned off (/sim/input/property-key-handler=0). If it's on, use /: or
/<property>: to open the browser.
- run keyboard event listener only when property key handler is active
I hope that the '/' key can keep this binding even after a keyboard review.
The '/' is just the most natural key for dealing with properties, and it's
far less prominent on non-US-keyboards (e.g. Shift-7 on German keyboards),
so it's not really very well suited for important aircraft functions, anyway.
But I don't insist. :-)
other than Shift-SPACE or SPACE alone). The move to Shift-Enter was bad,
as all Return combinations are filtered by open dialogs with <default>
set. SPACE remains reserved for communication functions (PTT), though, and
the property browser will be moved away if more combinations are needed for it.
- some comments in the file head
- move "fire starter" from SPACE-key to s-key
- move "open property browser" from Shift-SPACE to Shift-Enter (Shift-Return)
- implement PTT on SPACE/Shift-SPACE (with the other six SPACE/modifier
combinations unused, apart from a popup)
- add controls.ptt(v) wrapper function (v can be 1 or 2 for on, and 0 for off)
Easter-Egg:
- pressing the t-key for at least one second resets the warp delta.
This is an experimental feature that most people won't notice. It's meant
for investigating if suchlike "unorthodox" key use is acceptable. While
modifier-keys are the norm on computer keyboards, modifier-times aren't,
although we are used to them from other devices, such as alarm clocks etc.)
May later get removed without warning.
wrapper call
mf: I didn't find a trace of that /autopilot/controls-overrides/ property
in the fgfs source code and most of the data package. There are regular
complaints in the IRC channel about numpad keys 9 & 3 not working.
the same, with one exception: I (=Shift-i) doesn't only switch to the
alternative old HUD, but toggles that and the new HUD. Eventually
we may want to re-organize the HUD key bindings. Maybe after the old
HUD has been removed?
where it is desirable (it defaults to false); the <key>'s <repeatable>
setting is also used for the <mod-shift> branch, so we have to set it
as soon as one branch needs it.
- to support "old-style" gear/flap control (operation as long as button
pressed/lever pushed -> b29/hurricane), let bindings not only report
up/down, but up (-1), stop (0), down (1).
- let controls.flapsDown() ignore "stop" so as to remain compatible with
prior behavior
- adapt all joysticks/aircraft (sigh)
- some minor cosmetics in joystick configs, such as indentation fixes
Implement simple help system with global and aircraft specific dialogs:
The gui.nas changes have been discussed with Andy. All ac have a help dialog,
but some are empty. (This wouldn't have been necessary, as the system falls
back to the "Common Aircraft Keys" if an aircraft has no help defined, but an
empty dialog is less confusing and encourages to be filled with interesting
information. :-) I scanned all aircraft files for interesting performance
data and added some to the dialogs (stall speed, etc.) The Concorde and the
p51d have (over?)complete dialogs and can serve as examples. The format is
documented in $FG_ROOT/Nasa/gui.nas.
There is also a couple of other, minor fixes.
The following files have ugly MSDOS line endings:
$FG_ROOT/Aircraft/Hunter/hunter{-2tanks,}-set.xml
$FG_ROOT/Aircraft/A380/A380-set.xml
The Concorde-jsbsim.nas file is a useless copy of the real */nas file, which is
in Nasal/. I'was debugging the Concorde and wondered why changes to this file
had no effect ...
(Fixed Concorde in the help-ac.diff patch: don't use "interpol" keyword as
variable.)
I'd like to suggest that the spoiler settings are set in the same way as the
flaps are now done i.e. via Nasal, so that specific spoiler settings can also
be defined in the aircraft set file.
It was only when I was about to change the keyboard bindings for the slats
control that I remembered that there wasn't already a mapping for them in
keyboard.xml. I've _not_ added a mapping for slats as this is a bit of a hot
topic atm but as I had already added a Nasal func for the slats in
controls.nas I've left that in there. It's a trivial bit of code but I don't
know if leaving it in there is a good idea as it's code that shouldn't ever
be called until there's a corresponding keyboard mapping.
