Don't load resources for the current aircraft from several aircraft dirs
* 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:
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.
Nasal: use SG_LOG for security error messages to avoid truncation
These are often too long for naRuntimeError's 128-char limit:
http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/55B55856.2030709%40worldwideweb2.nl/#msg34319969
Torsten Dreyer [Thu, 6 Aug 2015 19:47:01 +0000 (21:47 +0200)]
Prevent 100% CPU usage for FGCom standalone
Kévin Seroux:
As reported here (http://forum.flightgear.org/viewtopic.php?f=32&t=26629),
the FGCom standalone client use 100% of the CPU when it is in OBS mode. The fact to add the shortest sleep time
(1ms) has solved the problem. With this patch, I run FGCom with 1% of CPU usage instead of 100%.
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
Security: don't follow symlinks to forbidden directories
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
Security: don't pass a string to fgValidatePath then use the original
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
janodesbois [Sat, 13 Jun 2015 09:02:30 +0000 (11:02 +0200)]
stop sending velocity and acceleration in the motion information when crashed
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 ;)
janodesbois [Sat, 6 Jun 2015 04:32:49 +0000 (06:32 +0200)]
Basic MP patch, to allow lag compensation and get rid of rubber band effect.
the fgdata part is needed to make it working. configuration for each plane
beeing done with nasal
Torsten Dreyer [Wed, 27 May 2015 11:23:45 +0000 (13:23 +0200)]
Add 8.33 kHz support to the commradio
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).
Torsten Dreyer [Fri, 22 May 2015 15:40:17 +0000 (17:40 +0200)]
Only warn about unknown tags in instrumentation.xml
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.
Durk Talsma [Fri, 15 May 2015 19:42:10 +0000 (21:42 +0200)]
Temporary fix: ground networks are not loaded when a navcache is present. But, the AI/ATC code relies on radio frequencies listed in the groundnet files. Since these are not imported into the nav cache, they remain 0.
By forcing the loading of the ground networks, I have the frequencies back. We should find a proper solution later.
Durk Talsma [Fri, 15 May 2015 16:25:16 +0000 (18:25 +0200)]
A second init() is necessary to start the ATCController. There's probably a better way to do is, but for now let's just stick to how I had it set up in early 2012.
Durk Talsma [Thu, 14 May 2015 16:15:30 +0000 (18:15 +0200)]
Fix bug when starting using the --parkpos option. Create a pointer to a ParkingAssignment object, so that the reference counter doesn't get reset to 0 when the local class is destroyed.
Singularity avoidance fix for the flightgear Viewer.
This was reported at https://sourceforge.net/p/flightgear/codetickets/1740/ and
discussed at http://thread.gmane.org/gmane.games.flightgear.devel/77562 .
The flightgear Viewer no longer causes aircraft to disappear due to the
singularity at the poles resulting in an undefined azimuthal angle.
Removed executable flags for JSBSim source files and synced JSBSim (removed warnings about comparison between signed and unsigned / modified FGInput to issue a more explicit message about unknown input types)
projects / flightgear.git / log