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/
Build a high resolution texture containing coastline
data that will be mixed with the landclass texture
in the ws30 shader.
Replaces the previous approach of creating a separate
coastline mesh.
Until we have a way to mark techqniues as permanently disabled,
remove this check, since it generates false positives. Especially,
see model-combined technnique n=9.
Pass the full path to the XML file, not is containg directory, through
effects, so that it's available for error reporting. Convert to an
actual directory when using the path to lookup other resources.
simgear/screen/video-encoder-internal.hxx:
Fixed initialisation of AVRational instance to work on Windows.
simgear/screen/video-encoder.cxx:
av_log(): vasprintf() is not available on Windows so use fixed buffer on
Windows.
The assumption is that all images coming from Canvas should be excluded from inclusion into the DDS texture cache.
Previously there was special logic that only excluded transparent images of Canvas origin but this was probably wrong.
Due to an error I made in 7ac90850 all AxisObject-based translate animations were inverted.
I think this correctly fixes the animations so that a value of zero is the 'start' vertex of the axis and a value of 1.0 is the 'end' value of the axis.
Start and end are now defined on the lowest x,y,z that aren't equivalent (within 0.01mm)
see: https://sourceforge.net/p/flightgear/codetickets/2706/
refs: https://sourceforge.net/p/flightgear/codetickets/2674/
Because disabling threaded GC wouldn't result in exactly the same allocation and GC due to changes I made to the GC as part of the threaded GC work the only safe thing to do is to remove it all.
Once we have figured out if it is the threaded GC causing the problem or not then we will at least know what needs fixing.
