but as this is an integral part of FlightGear, I don't want to push for it.
Try out and comment. It's available under "Debug/Property Browser". Note,
that this isn't the slow pure-Nasal implementation, but a regular dialog
using a c++ based widget. Only the handling is done in Nasal, so there should
really be not performance degradation compared with the old dialog.
Easter Eggs: some entries work differently when the Control-key is pressed:
"." -> toggle output of SGPropertyNode flags
".." -> go to root (not just one dir level)
bool entry -> toggle bool entry value
has to be given before a --wp or --flight-plan option to work.)
- let the "Remove" button remove the first entry by default, not the last.
(Note that you can remove any entry if you selected it in the list first.
Likewise you can insert a new waypoint at any position by selecting the
respective entry.)
<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.
not only more consistent, but also makes the autopilot dialog act more like
the real device). Add a few rules. Move the checkboxes to the left, as it's
usually done in GUIs for switches that enable/disable a group of widgets.
leave edit field!, press <Return> to execute; as an example try
screen.log.write("hello world"), or f16.canopy.open() in the F16,
or bo105.doors[3].move(0.3) in the Bo105 etc.
