At a basic level, the implementation supports two levels of LoD:
FAR from /sim/rendering/static-lod/ai-range-bare to /sim/rendering/static-lod/ai-range-detailed.
NEAR from /sim/rendering/static-lod/ai-range-detailed to 0.
(First of many digressions: If /sim/rendering/static-lod/ai-range-mode-pixel=true then instead of measuring LOD distance in meters, the size of the object in pixels is used, so the ranges are different)
The models that are loaded for FAR and NEAR depend on a combination of the availability of a model in /AI/AIrcraft/ and FG_AIRCRAFT directories.
If /sim/rendering/static-lod/ai-range-detailed=false then an AI aircraft will be used in preference for both NEAR and FAR.
If /sim/rendering/static-lod/ai-range-detailed=true then an AI aircraft will be used for FAR, and an FG_AIRCRAFT for NEAR.
Obviously if only an AI or a FG_AIRCRAFT model are available, that will be used for the entire NEAR+FAR range.
Change delay to 15 seconds; and alert that there is a delay.
The 15 second delay should be sufficient to allow the compressor to finish processing; and in anycase this is running in a thread and therefore shouldn't freeze the whole sim for the delay period.
/sim/multiplay/use-detailed-models can be used to set whether
we will prefer models from Aircraft/ (true) or from AI/ (false).
Default (set in defaults.xml in fgdata) is true.
Fixes a perf issue when opening and closing dialogs which uses
bindings, reported by Michael Danilov - huge thanks for his help
in tracking this down.
This bug was caused by the SGBinding ‘don’t delete properties’ change,
since the PUI code was copying nodes to work-around that problem. With
SGBinding fixed, the copying caused huge numbers of nodes under
/sim/bindings/gui
When releasing the RMB over a PUI dialog, we no longer get stuck in
drag mode due to the buttons map getting out of state. This is slightly
ugly work-around, better fix to follow hopefully (needs better OSG
integration)
Make the policy of using models in FGData/AI more flexible, with the
option to prefer normal data sources. Keep the existing behaviour for
everything except multiplayer aircraft, where we now prefer the data
model (presumably, an installed aircraft) over the AI one.
bool[42] and bool[72] used to have two bits (i.e. transmitted twice). This was not harmful just wasteful.
Mapped the first of the duplicated bits of each of these to new bools at the end of the list. These two properties will not be compatible with pre 2018.2.
If all bools in a block are 0 the block would never be transmitted, i.e. fix a bug whereby each block of 0..30 used to need at least one true value to transmit the block.
So far, the Linux PLIB implementation used to nuke any deadband set at
kernel level with jscal(1) as soon as the joystick was opened. This
broke joystick calibration for FG and unrelated programs, for people who
cared to tune their kernel-level deadband setting.
This fixes PLIB bug #47[1]. Note that the fix has already been in Debian
buster's plib for some time (plib 1.8.5-8 uploaded on 24 Jul 2017[2]).
[1] https://sourceforge.net/p/plib/bugs/47/
[2] https://tracker.debian.org/news/858564/accepted-plib-185-8-source-into-unstable/
