Allow multiple, space-separated waypoint specifications to be added to a
route, rather than having to type each one and press the add button
each time.
If no waypoint is selected as the insertion point, show a message
and leave the waypoint input intact, rather than just clearing it.
Update the help label to reflect the change and include a note of how to
create offset waypoints using a radial and distance.
At the suggestion of Gilberto AGOSTINHO, add
button bindings for throttle, mixture and prop
to the joystick configuration dialog.
Specific use-case is users of game-pads, but also
useful to users with a single throttle axis on their
joystick.
This follows from http://thread.gmane.org/gmane.games.flightgear.devel/78650 and
resolves the sign bug https://sourceforge.net/p/flightgear/codetickets/1778/ .
Combined with a matching change to the flightgear repository, this changes the
HUD formats from the current set of 3 (note that the text in brackets is not
shown in the HUD preferences PUI dialog, but is show here for reference):
0) Decimal degrees (37.618890N -122.375000W)
1) Degrees, minutes (37*37.133N -122*22.500W)
2) Degrees, minutes, seconds (37*37 08.0 N -122*22 30.0 W)
to (here the text in brackets is shown in the PUI dialog):
0) DDD format (37.618890N 122.375000W)
1) DMM format (37*37.133'N 122*22.500'W)
2) DMS format (37*37'08.0"N 122*22'30.0"W)
3) Signed DDD format (37.618890 -122.375000)
4) Signed DMM format (37*37.133' -122*22.500')
5) Signed DMS format (37*37'08.0" -122*22'30.0")
6) Zero padded DDD (51.477500N 000.461389W)
7) Zero padded DMM (51*28.650'N 000*27.683'W)
8) Zero padded DMS (51*28'39.0"N 000*27'41.0"W)
9) Trinity House Navigation (51* 28'.650N 000* 27'.683W)
Add valid ranges for day based on selected month and year taking into account leap years.
With this change it should no longer be possible to enter an invalid date.
Added combobox for the month (using name).
Added sliders for all date components (year is between 1971 and 2037 to avoid invalid values in time_t).
Relabelled easing, added a bit of layout context with some ruling.
Magnetic declination being "the direction of the horizontal component of
the magnetic field measured clockwise from north" according to
MagneticField(1), it must be substracted, not added, from true bearings
in order to obtain the corresponding magnetic bearings.
Example illustrating the bug:
Start at KSFO, open Equipment -> GPS Settings, enter KHTH as the
destination and click on "Search". Before the bug fix, the dialog
gives a bearing of 85, whereas the correct magnetic bearing is 58.
Digging a bit further, the true bearings/azimuths for the shortest
path (geodesic line) from KSFO to KHTH are approx. 71.5 at KSFO and
73.8 at KHTH. This can be verified with two independent libraries
(GeographicLib and PROJ.4):
% echo "37d37'08N 122d22'30W 38d32'45N 118d38'00W" | \
GeodSolve -i
71.44943076 73.75785283 343987.398
% echo "37d37'08N 122d22'30W 38d32'45N 118d38'00W" | \
geod +ellps=WGS84 -I -f '%0.3f'
71.449 -106.242 343987.398
(-106.242 + 180 = 73.758: -106.242 is the "back azimuth" at KHTH for
this path)
The bearing of 85 given by the code in gui/dialogs/gps.xml before
this commit is indeed 71.5 + magnetic declination at the starting
point (KSFO), whereas it should be 71.5 - magnetic declination.
Another, more experimental way:
Start FlightGear with:
fgfs --aircraft=ufo --disable-real-weather-fetch \
'--metar=KSFO 070956Z 36000KT 10SM FEW023 11/07 A2977 RMK AO2 SLP080 T01060067' \
--lat=37.61867421 --lon=-122.37500761 --heading=71.45931
(just in case wind influences the ufo, I have no idea whether this is
the case or not...)
During your flight, progressively increase your heading (as seen in
the HUD, i.e., true heading) so that it smoothly changes from 71.5 at
KSFO to 73.8 at KHTH. You should arrive pretty close to KHTH, whereas
the initial heading of 85 given by the GPS Settings dialog is way too
high, be it interpreted as a magnetic heading (which was visibly the
intention---it would be nice to write that in the dialog BTW) or as a
true heading (in which case the result is even further from the
correct value).
expose the ai-range-mode flag to the static-lod dialog.
PagedLOD culling based on distance seems to be more reliable than that based
on projected screen size.
This is merge request #20
MP Patch first step fgdata part: nasal to check wich planes we are
displaying in the futur, with a distance check , one plane each frame.
The change introduced in commit 8c7fc119 to go to the last checklist
on open causes a problem when the first checklist has multiple pages.
If the last opened checklist did not have multiple pages, the previous
and next page buttons are still shown.
This commit runs the same binding as used by the combo box to reset
the visibility of these buttons immediately before the page is
displayed.
The change introduced in commit 8c7fc119 to go to the last checklist
on open causes a problem when the first checklist has multiple pages.
If the last opened checklist did not have multiple pages, the previous
and next page buttons are still shown.
This commit runs the same binding as used by the combo box to reset
the visibility of these buttons immediately before the page is
displayed.
Now that request-metar/clear-metar commands work properly, use those
instead of direct manipulation of metar properties. Also, don't write
to properties intended for read-only use.
- Needs FlightGear compiled with -DENABLE_PACKAGE_SYSTEM.
- Shows only first 100 available aircrafts.
- Now progress indication on install/remove (need to reopen
dialog afterwards)
Replaces existing Nasal/failures.nas script with a programmable failure
manager. The failure manager allows dynammic creation and removal of
failure modes, on demand activation and a flexible set of triggers.
The public interface can be found in Nasal/FailureMgr/public.nas
Aircraft/Generic/Systems/failures.nas provides a library of triggers and
failure actuators ready to use for programming the failure manager.
A compatibility layer is included under
Aircraft/Generic/Systems/compat_failure_modes.nas.
This compatibility layer is currently loaded on startup and programs the
FailureMgr to emulate the former behavior (same set of failure modes and
compatible interface through the property tree).
This first milestone is only intended to replace the failure management
engine underneeth with minimum visible changes, and hopefully no aircraft
breakages. Future milestones will build upon this to add a Canvas based
procedural GUI and example integration on aircrafts.
Fix the main bugs, add features and convert most of the layers.
Move/refactor some things as well. Add a canvas map dialog next to the
built-in one -- it's not 100% functional but it's quite close actually.
As before, the excitement has been taking place at our team clone.
https://gitorious.org/fg/canvas-hackers-fgdata/commits/0b4cc84
(topics/canvas-map-dialog branch this time, current HEAD in above URL.)
Features:
- Various configurable styles.
- Working scroll bars, thanks to Tom
- Adequate REPL-ness.
See the wiki for more information!
http://wiki.flightgear.org/Interactive_Nasal_Console
N.B. This makes some (sane) changes to other Nasal files, including
expanding some of the Canvas API.
Replace the temporary UI with real solutions, in the view dialog
(for tooltips/popups) and a new 'input config' dialog accessed via
the file menu.
Make the mouse-cycle popup explicitly optional since some people
strongly dislike it.
* make into singleton class
* make sure FOV changes take place *immediately* when required
* current FOV is scaled with changes, though being preserved: resizing
window and going back ends up with the same FOV
Restore pre-2.12 functionality where GPS search was persistent across
opening and closing the GPS dialog. Since the state is now in Nasal
we need to ensure a couple of variables outlive the dialog itself.
Now tile refresh is gone, this dialog is much simpler.
(Scenery can still be reloaded from the Rendering dialog or sim reset,
but the pager will always wait on TerraSync)
Extend the canvas.Window class to create a simple window decoration
if a type for it (currently every type maps to the same style) is
given. It supports moving the window by dragging inside the title
bar and setting a window title.
- Fix bug when opening weather dialog when in manual mode.
- Move buttons to be opposite the appropriate radio buttons
- Keep buttons visible at all times.
- Update description to account for recent Basic Weather -> ALS integration.
These are then attached to buttons on the checklist dialog allowing
the user to ask the computer to execute the checklist step, which
they can observe.
State is saved to autosave.xml, and --disable-scenarios still avoids
loading any scenario at launch. At runtime scenarios can be added or
removed as normal.
Drive off the 'show view names' checkbox in the view dialog for now, this might
evolve into a generic 'on-screen hints' control to avoid an explosion of
GUI checkboxes.
Also add a GUI checkbox (oh the irony...) to disable mouse flight-controls, to
keep AndersG and Emilian happy.
This is temporary (hopefully!), to allow experimentation with different UX options in the near future. Right now it basically does nothing. As part of this, factor mouse-mode cycling into a separate command, and add some feedback. Feedback mechanism needs work, currently abusing the copilot facility.
Checklists may now be split into individual sections made up
of <pages> containing the <item> tags. Each page is displayed
individually with Previous/Next buttons to allow navigation.
Checklists items also support <marker> tags. These display
a marker when a ? button is pressed next to the checklist item.
The format is identical to that of the tutorial system.
Checklist items now support a <condition> element that evaluates
when the checklist item is complete, and is used to provide color
coding in the checklist dialog.
Fix bug 940, where GPS remains in active LEG mode when the route is cleared. (there is an associated flight gear code change). With this fix, the work-around in the GUI dialog is no longer required.
- first stab at refactoring the map.nas module, and trying to let the API evolve according to our requirements
- split up the module into separate files (some of them will disappear soon)
- split up the "drawing" loops into separate functions so that they can be individually called
- move actual "drawing" to map_layers.nas
- introduce some OOP helpers to prepare a pure Layer-based design
- prepare helpers: LayeredMap, GenericMap, AirportMap (TODO: use a real "Layer" class)
- move airport features (taxiways, runways, parking, tower) to separate layers (i.e. canvas groups)
- avoid using a single update callback and use different layer-specific callbacks to update individual layers more efficiently
- add some boilerplate hashes to prepare the MVC design
- allow lazy updating of layers, where canvas groups are only populated on demand, to save some time during instantiation, i.e. loading an airport without "parking" selected, will only populate the layer once the checkbox is checked
- extend the original code such that it supports showing multiple airports at once
- add some proof of concept "navaid" layer using SVG files for navaid symbols (added only NDB symbol from wikimedia commons)
regressions:
- runway highlighting needs to be re-implemented
- parking highlighting will be done differently
- enforcing a specific drawing order for layers is currently not explicitly supported, so that taxiways may be rendered on top of runways
Also:
- integrated with the latest changes in git/master (HEAD) -i.e. metar support
- further generalized map.nas
- partially moved instantiation from Nasal space to XML space (WIP)
- create "toggle layer" checkboxes procedurally in Nasal space
- prepared the code to be better reusable in other dialogs (e.g. route manager, map dialog etc)
- completely removed the "highlighting" (runway/parking) feature for now, because we talked about re-implementing it anyhow
- Change timer to listener for zoom level.
- Correct course information so it is the course TO the selected airport
- Default to the closest airport, rather than the preset.
- Display taxiways
- Display different surface types
- control over components (taxiways, parking positions, towers) displayed
- include distance and course to airport.
