<close> block, remove autopilot helper file autopilot.nas and (re)implement
its functionality in autopilot.xml
- make AP dialog "bidirectional" and "live": all input fields are <live>
(i.e. they are updated as the autopilot settings are changed, for example
by panel actions or property browser changes)
- dialog input is only forwarded to the AP; no direct checkbox/radiobutton
handling through widget operation, instead:
- changes to the AP properties operate checkboxes/radiobuttons
This makes the AP dialog always reflect the AP state. If the AP refuses
one setting and sets it back to something else, then the dialog will
immediately react and show the actual setting.
mf:
- some minor modifications to Stuart's version :-)
- select all engines per default. This may seem less realistic (who starts
all engines on the b29 at once?), but it'll prevent oodles of bug reports.
And those who want it realistic shouldn't rely on engine 1 being selected
by default, anyway, but rather actively select every single engine.
Also: this new behavior is in line with the original intentions (see cvs
log to preferences.xml -r1.51)
- always disable tutorial-stop; enable tutorial-start if tutorial available
- don't call the tutorial selector "Wizard 1/2". There is only one tutorial
selector, the next dialog is already part of the tutorial. Also, the dialogs
don't guide you through multi-dialog setup, which is what "wizards" normally
stand for.
- use tutorial name as dialog title
- set button shortcuts (default == return, esc)
- make esc go back to select dialog
- beautify sliders & some other tweaks
functions when used in $FG_ROOT/Nasal/*.nas, because it
depends on props.nas being available; no restrictions in
aircraft files, where it will proof most useful
gui.nas: replace inefficient FPS display polling loop with listener
callback
- gui.nas: use 4-space indents like the rest of the file; waste slightly less
cycles: checking for the property shouldn't be done in a loop at
all, it only serves as a temporary solution
to pop themselves down while the simulator is paused.
The problem was with the "real time" queue in the event manager,
causing the third argument of Nasal's settimer() (a flag for "sim
time") to be ignored. Inverts the default sense of the argument, as
there are lots of uses of settimer() in the current code, almost none
of which want to use real time.
Note this fix introduces a header file incompatibility in SimGear --
be sure to update.
gear movement. gearToggle() was sending either a 0 (not handled) or a 1.
Change gearToggle() so it sends either -1 and 1 so gearToggle() will work
again.
- 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.)
- lights are by default off (what was I thinking?!?)
- setters return "me" reference by default, for easier code obfuscation:
foo = aircraft.light.new("/foo").prop().switch(1); :-)
- a few mebmers renamed; light.set() -> light.switch(); nodes are named *N
to avoid collisions and to show relations (switch() <-> switchN)
- yet more (too much?) documentation
- light class added (for lights and other pulsing/blinking objects)
- fixed and improved documentation
- all property args may be path strings or nodes
- existing nodes aren't overwritten any more
- better naming of class vars (for outside access)
Tested with the bo105 (which I fully ported to use aircraft.nas) and
the fokker70 (which are the only aircraft using the new classes :-)
Re-organisation: <diffuse>, <ambient>, <emission>, <specular> are
now groups with members <red>, <green>, <blue>, <factor>, <offset>,
and their <*-prop> forms. Additionally, there's an option <property-base>
that can be used to set a path that is prepended to all <*-prop> paths.
It defaults to an empty string. Rationale: see model-howto.html.
Changes:
o new skids (yet again)
o sun shield for the panel
o beautified exhausts
o new door handling:
"d" ... toggle selected door (default: pilot door)
"D" ... select next door (indicated with popup)
"Ctrl-d" ... remove selected door if opened (all bo105 doors can easily
get removed in RL; it is even flown without doors!)
o dropped shadow boxes (once necessary workaround for the disappearing
shadow problem, and the reason why the bo105 was so tiny in fgrun)
o automatically selects the emblem of the national Red Cross/Red Crescent
society on startup
o 5 variants, that can be switched at runtime, with different emblems,
colors(!), and extra equipment:
"c" ... switch to next variant
"C" ... pop-up material dialog, as a demonstration of the new
"material" animation, well ... and for entertainment
purposes :-)
The bo105 was and is a testbed for the "material" animation. It uses one to
change a texture at runtime. This has the advantage, that only the currently
selected texture uses up memory (unlike the textranslate method), and it
saves a lot of disk space because it doesn't duplicate all textures (unlike
the current <texture-path> method. You can change the texture in the browser:
http://localhost:5501/sim/model/bo105/material/emblem/texture
(choose one of: emblems/{red-cross,red-crescent-[lr],star-of-life}.rgb
(the built-in property browser doesn't grok it, because I used quite long
path names. Needs to be fixed in the GUI.)
I suggest to add the material.nas file to the global Nasal/ dir, not only
because the bo105 update expects it. The Nasal module creates a dialog for
material editing, which is quite useful for development purposes, for gaining
better understanding of the OpenGL color properties, and finally: it's fun.
http://members.aon.at/mfranz/material.jpg [45 kB]
The dialog needs to be initialized with a property dir where material
redirects are placed. It isn't available from the menu, but may be useful
for other aircraft. Also, it's quite small and doesn't get in the way.
If people want it removed, I can still move its contents into bo105.nas.
The bo keyboard binding says:
material.showDialog("/sim/model/bo105/material/fuselage/", "Bo105");
This is documented on top of the *.nas file.
Here are some updates to the KAP140 autopilot in the default c172. It now uses
ailerons and elevator instead of aileron-trim and elevator-trim. I've started
to "upgrade" it to the "two axis altitude preselect" version. Vertical speed
select rounds to nearest 100 fpm.
I've also modified the c172 electrical configuration to turn on the gps
instrument.
Perhaps the most important change is that the nasal script for the KAP140 has
moved from data/Nasal to the c172p aircraft subdir. So it is important that
you delete data/Nasal/kap140.nas. Having the kap140.nas script as a global
script was not a good solution. Now it is aircraft specific, and thus
included in the c172p-set.xml file. Ideally I would like it to be instrument
specific, so that it would be included whenever the KAP140*.xml instruments
where included on the panel.
typo; the SimGear "pass subproperty as first argument" shortcut
doesn't work in Nasal. This checkin is blind, but should have a high
probability of correctness.
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.
