Code in AudioIdent::setIdent() expects that SGSampleGroup::remove() does
remove the corresponding item from _samples, however SG commit 47aae88ab
broke this assumption, which caused the bug reported at [1].
Restore the immediate removal from _samples by default. For the special
case where we do need delayed removal (i.e., while
SGSampleGroup::update() is iterating over _samples), the new optional
parameter is passed the value true. For a longer explanation, see [2].
This fixes a crash when swapping the selected and standby frequencies
for the NAV1 or NAV2 instrument (more precise description at [1]).
[1] https://forum.flightgear.org/viewtopic.php?f=25&t=40890
[2] https://sourceforge.net/p/flightgear/mailman/message/37721699/
Previously the Bounding Box of a group of building was calculated
purely based on the position of each building. Depending on the
geometry of the various buildings, this could result in a zero-volume
box, which would be culled away.
This change ensures that the BB is at least a 20x20x20 volume, by
increasing the convex hull size.
Fixes https://sourceforge.net/p/flightgear/codetickets/2542/
Update my work-around for this from last year, and handle another
case (where models are loaded directly rather using the delayed
callback via the osgDB::Pager)
Where we replaced the XMl-wrapper with an AC model in FGData or
TerraSync, accept the old path ending in .xml, to avoid many errors
loading custom scenery.
The changes to the sorting rules caused a breaking change that was incompatible.
The solution to this is to revert to being compatible with <=2020.3 but also to allow modellers to choose the new sorting rules.
I've added a new tag <defaults> which can contain either <axis-animation-vertex-order-xyz/> or <axis-animation-vertex-order-x/>. The defaults will affect all animations in the .xml and also any included models unless the included model also has a <defaults> section.
So for modelers that want to use the new definitive vertex sorting rules adding the following to the main model is sufficient.
<defaults>
<axis-animation-vertex-order-xyz/>
</defaults>
There are also a couple of new tags that can be used in the <axis> section.
1. <order-by-xyz/> - use the new sorting rules
2. <order-by-x/> - use the 2020.3 sorting rules
3. <swap-axis-direction/> - when the animation goes the wrong way this is an elegant way to fix it.
See https://sourceforge.net/p/flightgear/codetickets/2706/
- Remove the SGPath::validate() call added in commit
22779ee2c4 (first part of findPath():
when it is called with a non-null second argument).
- Remove the warning printed when the assembled path is absolute and
fails the SGPath::validate() read permission test (this caused too
much noise and confusion).
- Keep the behavior or accepting absolute, existing paths that pass the
SGPath::validate() read permission test.
This way, the 'play-audio-sample' FGCommand will continue to work with
absolute paths. If/when the built-in launcher is updated to set up the
read-allowed paths early enough, maybe we can revert FG commits
3ee54cbd72bd8f and 896be707ae558 and re-add the SGPath::validate()
call in the first part of findPath()---assuming it is deemed useful.
- Perform the SGPath::validate() test for read access before returning a
path obtained with a non-null second argument ("aContext").
- If SGPath(aContext, aResource) is an absolute path for which read
access is authorized by SGPath::validate(), return it. This restores
the possibility of using the 'play-audio-sample' FGCommand with an
absolute, read-allowed path (was lost in FG commit 8853fded2953959).
- Because a fair number of the existing uses of
ResourceManager::findPath() are not quite correct IMO, we execute the
final part where all providers are tried in turn even if
SGPath(aContext, aResource) is an absolute path (otherwise, the sim
wouldn't start because it couldn't load materials.xml---see [1]).
- The SG_LOG call will spot a few errors in calling code/data, such as
access tried for
'/Aircraft/Generic/flightrecorder/generic-piston-propeller-4.xml' and
'/Textures/Sky/cl_cumulus2.png'; since the function does not return at
this point, these incorrect absolute paths which should be relative
will still be given a chance with the BasePathProvider that has its
base path set to $FG_ROOT; thus, they will be found as before this
commit despite the new "access refused" warning (but please fix
them!).
This commit requires FlightGear commit e7594f46876fc6b0b.
[1] https://sourceforge.net/p/flightgear/mailman/message/37697516/
This will allow us to perform access control validation in SimGear. The
current implementation of SGPath::validate() is 99% Rebecca Palmer's
work (see fgValidatePath() in FlightGear commit
6a30e7086ea2f1a060dd77dab6e7e8a15b43e82d); only the coding style has
been slightly modernized here since we can now use, for instance,
C++11's range-based for loop.
This is to avoid confusion because the following commit will make
SGPath::validate(bool) replace the fgValidatePath() function from the
FlightGear repository.
- Add an explicit constructor SGSoundSample(const SGPath& file) that
directly uses the specified path instead of going through
ResourceManager::findPath().
- Reimplement the existing constructor as
SGSoundSample(const std::string& file, const SGPath& dir),
delegating to the new one.
- The first argument of the delegating constructor is now a
const std::string& instead of a const char*.
Among others, this will allow a better implementation of
FGSoundManager::playAudioSampleCommand(). More explanations can be found
here:
https://sourceforge.net/p/flightgear/mailman/message/37695786/
zhongjin
Florent Rougon