The problem was that the change to make FGScenery a standard subsystem caused
the particle OSG group to no longer be inserted into the scene graph. The
solution was to convert the particle group to be set up as a standard branch of
the scene graph, alongside the terrain, models, aircraft, and interior branches.
The particle system is now set up as part of the init() subsystem function call,
so it is compatible with the new subsystem design.
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 FGData, 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 will be 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)
Being able to list arbitrary directories is a privacy violation;
existing in-fgdata uses of this are all permitted paths
(i.e. not Terrasync; FileSelector doesn't use it)
- Use setlocale() to ensure consistent handling of locales and
string handling irrespective of whether or not QCoreApplication
is invoked. Forces a the C locale for numerics and collation,
since many pieces of FG assume this.
I didn’t know about this feature when doing the original CMake files,
we can use this to target header-file includes more precisely.
(Probably more cases exist that can be changed from global to target-
specific includes)
- add a button to the main dialog, explaining how to adjust the
fg-root path via the GUI
- tweak the GUI flow to support explicitly changing the path even
when the default path is acceptable.
- because uiuc_warning_error always called exit(-1), it can be marked
no return, so Clang realises that when it’s used in the ‘else’
side of a parsing test, uninitialised variables in the enclosing
call site are safe.
(Requires Simgear update to define SG_NO_RETURN helper)
- when dynamics shuts down the ATC controllers, they clear their
traffic vectors (destroying the records), but we didn’t notify
the AI aircraft of this. Ensure the controller is cleared so
the AI aircraft shutdown doesn’t crash.
Under some conditions on my system
aircraft_paths.begin() was equal to scenery_paths.end()
This resulted in neither of them being added to read_allowed_paths
followed by failure to load Nasal scripts from the aircraft directory.
This might happen, if scenery_paths gets allocated just before aircraft_paths
in memory.
Better loop across the desired lists instead of using fancy tricks with
the iterator.
- sim-speed-up (a/A keys) offsets warp correctly. This means at 4x speed
up the warp will increase by 3 seconds for one elapsed real second.
In practice this means simulation elements timed using sim ‘current time’
will be correctly synchronised with those using simulated elapsed time.
(AI traffic being a prime example of this)
- warp-delta (t/T keys) is independent of frame rate, and works when
paused. The warp-delta values in the keybindings / GUI dialog
will need to be updated since warp-delta in now seconds-per-second,
as opposed to seconds-per-frame.
- change launcher to examine the scenery paths and hence load
ground-net files for airports to populate parking data.
- refactor ground-net XML parsing to use FGGroundNetwork only, not
AirportDynamics.
- change parenting of GroundNetwork to Airport, since it contains
immutable data now.
- when no runway use preferences XML exists, be smarter about using
available runways. Makes the common case of using two parallel
runways for arrivals and departures work, greatly improving AI
traffic behaviour.
- consistent with pause (freeze), /sim/speed-up is now applied to the
dt value for all subsystems, not just the FDM and some instruments.
For example AI traffic can now be sped-up or slowed down.
- requires both an FGData and Simgear update.
- when switching views, force an update() to ensure view position
is valid. Otherwise various subsystems such as AI traffic and the
tile manager see a request for a 0,0 location.
- when switching to model view, we still generate a 0,0
location initially - to be fixed.
Avoid intermittent race conditions on shutdown when the OSG
pager/Db thread is running. Ensure the OSG threads are stopped before
we start tearing down any scene graph nodes.
- remove some global headers from AI headers, to avoid pollution
- change how ATC owns the ‘player’ FGAIAircraft so reset works
- ensure AIAircraft controllers are cleared on unbind for reset
- ATC functions move to GroundController, which layers above
remaining GroundNetwork functionality
- dynamics owns both the groundNetwork and the ground controller.
This is for the FGProperties::getLongitudeString() and
FGProperties::getLatitudeString() functions. The previous algorithm was to
round the degrees up by the smallest fraction required to prevent a round up to
60 minutes or seconds, and then round down the final minutes or seconds by the
same fraction. The new algorithm is to detect if the final minute or seconds
will be rounded to 60 by the string formatting and, if so, the higher unit
(degrees or minutes) is incremented by one, and the lower unit decremented by
60.
As QApplication only stores a reference to argc, it may crash if
the argc passed to it goes out of scope. (One way to trigger this
is to pass an invalid --fg-root, triggering an initApp call from
Options::setupRoot.) Copy argc to prevent this.
Drop fgNormalizePath, use realpath() only
As this makes it accept relative paths, always use the returned
(absolute) version for the actual file operation to avoid check-to-use
races, or where this is not possible (NasalSGPath) explicitly reject
relative paths
Fix: do_save is a write, not a read
* Before setting /sim/aircraft-dir from the --aircraft-dir option,
canonicalize its value with SGPath::realpath() as is already done in
FGGlobals::append_aircraft_path() for the paths given with --fg-aircraft
or via the FG_AIRCRAFT environment variable.
* This fixes a bug when --aircraft-dir is used, due to the fact that
fgValidatePath() canonicalizes its 'path' argument before matching it
against the allowed patterns, and therefore will not validate paths
under the directory specified with --aircraft-dir if this directory has
been given in a non-canonical form by the user (e.g., containing at
least one symlink component).
* This fix does not lower security: the path which is canonicalized has
been explicitely given by the user. This operation is already done for
all paths specified with --fg-aircraft or via the FG_AIRCRAFT
environment variable, via Options::initPaths() which calls
FGGlobals::append_aircraft_paths().
* To reproduce the bug, create a symlink (e.g., /tmp/aircrafts) to a
directory suitable for --fg-aircraft, then run:
fgfs ... --fg-aircraft=/tmp/aircrafts \
--aircraft-dir=/tmp/aircrafts/SenecaII --aircraft=SenecaII
This will trigger many failures such as:
loadxml: reading '/tmp/aircrafts/SenecaII/Dialogs/registration.xml'
denied (unauthorized directory - authorization no longer follows
symlinks; to authorize reading additional directories, add them to
--fg-aircraft)
(from do_load_xml_to_proptree() in flightgear/src/Main/fg_commands.cxx)
I have also tested this with the ec130b4 and the 777-200ER. Same
problem, same fix.
* If one has the same aircraft in several aircraft directories,
FlightGear should not mix resources from the various aircraft
directories. For instance, if one starts FG with:
--fg-aircraft=/my/personal/dir:/path/to/fgaddon/Aircraft
and one has in /my/personal/dir/ec130 a clone of the upstream
developer repo, FlightGear should use either the upstream version from
/my/personal/dir/ec130 or the FGAddon version from
/path/to/fgaddon/Aircraft/ec130, but not some strange, untested hybrid
of both.
* This commit makes sure that when the looked-up resource starts with
Aircraft/<ac>, where <ac> is the current aircraft name [last component
of aircraftDir = fgGetString("/sim/aircraft-dir")], then
AircraftResourceProvider::resolve() doesn't search other aircraft
directories if the resource isn't found under 'aircraftDir'.
* To reproduce the bug before this commit, you may add the following
code (there is nothing specific about the SenecaII here, it's just the
aircraft I used for testing):
var file_path = resolvepath("Aircraft/SenecaII/flo-test");
if (file_path != "")
gui.popupTip("flo-test found", 2);
else
gui.popupTip("flo-test not found", 2);
in a keyboard binding for the SenecaII (for instance; you may use the
F11 binding that otherwise only prints a short message). You should
add this to the SenecaII/SenecaII-base.xml file *that will be loaded
by FlightGear*, let's say the one under /my/personal/dir in the
example above (beware of the <path-cache> in autosave_X_Y.xml). Then,
by creating or removing a file named "flo-test" in the SenecaII
subdirectory of other aircraft dirs (for instance,
/path/to/fgaddon/Aircraft in the example above), you can see that the
behavior of the loaded aircraft is influenced by the contents of
unrelated versions of the same aircraft that might be present in other
aircraft dirs (e.g., loaded /my/personal/dir/SenecaII influenced by
/path/to/fgaddon/Aircraft/SenecaII).
* Aircrafts loading resources using paths relative to the current
aircraft directory (e.g., with 'resolvepath("flo-test")') are not
affected by this kind of problem, because this scheme is handled by
CurrentAircraftDirProvider, which does not exhibit this bug.
negative latitude/longitude coordinates resulted in negative WEST/
SOUTH coordinates for the default format 0 (zero).
This should be now fixed so that
+12.3 gets formatted as 12.3N/E
-12.3 gets formatted as 12.3S/W
https://bugs.debian.org/780867
This messy approach is to minimise changes during freeze; for 3.7,
I plan to make realpath() handle non-existent files as "realpath
they would have if created now" and get rid of fgNormalizePath
This is insecure because it always (not just on Windows) converts
\ to / before .. checking. Either use the path it returns (as in
f_open()) or use an SGPath (where this conversion is already done)
Only a minor problem because the affected functions are limited to
the .sav file type
and using speed up time to allow a fine displayed predicted position
when time accelerated (no more jumping planes accelerated using the mp patch)
tell me if it's not the good pace to do such things ;)
Usage:
Add
<comm-radio>
<name>comm</name>
<number>0</number>
<eight-point-three type="bool">true</eight-point-three>
</comm-radio>
to the instrumentation.xml
If eight-point-three is disabled nor not present, previous functionality is unchanged
If eight-point-three is enabled,
set
/instrumentation/comm[x]/frequencies/[selected|standby]-mhz
to the desired 8.33 channel (118.000..136.990) or
/instrumentation/comm[x]/frequencies/[selected|standby]-channel
to the desired channel-number (0..3039).
Valid channels are:
xxx.000
xxx.005
xxx.010
xxx.015
xxx.025
xxx.030
xxx.035
xxx.040
xxx.050
xxx.055
xxx.060
xxx.065
xxx.075
xxx.080
xxx.085
xxx.090
where 118.0 <= xxx <= 136.990
Richard J. Senior:
Without this commit, unknown top-level tags in instrumentation.xml are treated
as errors and the rest of the file is not processed.
Users running Flightgear versions prior to 3.2 have experienced problems with
the comm-radio tags after downloading updated versions of aircraft from FGADDON.
Instrumentation listed after the unrecognized comm-radio tags is not processed
for these users and is inactive in the cockpit.
This commit changes the instrumentation build method so that unrecognized tags
are treated as warnings. This won't help users running older versions but
protects against the same problems occurring if new tags are added to
instrumentation in the future.
