registered with dynamic_view.register() and is called in the main loop,
replacing the default plane/helicopter function. This has access to
all class functions/members and sets me.heading_offset, me.pitch_offset,
and me.roll_offset, which are then used as new view offsets.
The function can also do other things, such as call the lookat() method
to temporarily set heading and pitch. See the bo105 for an example.
While further minor changes are to be expected, the configuration method
seems to be the way to go.
- dynamic_view.nas: use aircraft.lowpass() class
This makes the dynamic view independent of the frame rate. Currently,
each filter instance reads out dt on its own, which is a bit inefficient.
I'll change that to just one read for all instances later (when Nasal
implemented predictable module loading order. :-)
- fix sliders: revisions 1.43/1.44 had introduced a mandatory <min-lb>;
if that was missing, a slider without handle was generated, and a click
on the slider lead to a crash.
-> check for both <min-lb> and <max-lb> and set default values
0, respectively 100
var min = w.getNode("min-lb", 1).getValue();
var max = w.getNode("max-lb", 1).getValue();
slider.set("min", min != nil ? min : 0);
slider.set("max", max != nil ? max : 100);
preferences.xml gui/menubar.xml gui/dialogs/rendering.xml
Added Files:
Nasal/multiplayer.nas gui/dialogs/chat.xml
gui/dialogs/chat_full.xml:
the data part of Stuarts multiplayer/chat patch
tank indices, so that changing drop tanks automatically modifies the
corresponding FDM tank capacity (and load, if it is too high).
Add the new tank stuff to the harrier config, along with a few new
items (e.g. AMRAAMs on the outboard pylons) that aren't in the 3D
model yet, but correspond to actual usage.
An IRC discussion about shavlir's (really nice) harrier model showed
that it had its own version of something like the Fuel & Weight
dialog, developed because the existing subsystem only supported
sliders and not "combo box" style selection for specific external
stores. That seemed sub-optimal, so I spent a few hours extending the
F&W dialog to do this and forward-ported the harrier to use it.
Check the harrier-set.xml file for an example. Basically, the weight
dialog reads a list of options for each weight listed under
/sim/weight[n] and manages a "selected" proprty telling us which one
is in use. The FDM code can then read out the weight-lb property as
before, and the model animations can use the selected option to
predicate drawing the appropriate 3D content. It seems to work pretty
well.
Unfortunately, this is quite jittery on some aircraft, so it uses a slower
lowpass filter. I'd like to fix that, but don't even know what causes it.
Considering /sim/time/delta-realtime-sec didn't help. :-/
entry "View->Toggle Dynamic Cockpit View" entry; state saved to autosave.xml;
there are no configuration parameters yet, but the default values work for
most aircraft; exceptions: ground steering effect of jsbsim aircraft is
jittery; yawing effect on big aircraft is too abrupt. This needs to be
configurable.
Suggestions for improvements are welcome if they are bundled with a
working diff that actually proves the claimed advantages. :-)
<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
