This is a clean up commit prior to the subsystem API standardisation to simplify
the diffs. It includes all SGSubsystem and SGSubsystemGroup derived classes.
Due to e43fe82094 models in AI scenarios were
being searched down the AI/Aircraft and Aircraft paths, where in fact
they are by default a full path from FGDATA.
This fixes the problem by setting DATA_ONLY as the search order.
Other search orders can be set in the scenario file by setting
the search-order tag to "DATA_ONLY", "PREFER_AI", "PREFER_DATA"
Fix for https://sourceforge.net/p/flightgear/codetickets/2125/
Previously, selecting a non-pushback parking position from the l
auncher that did not have a ground network resulted in the
aircraft being placed in the center of the airport.
This resolves the problem by creating a default segment simply
moving forward 2m.
Assuming this should have been ‘vertical-mode’ all along, since the
corresponding other mode property is called ‘lateral-mode’. Make an
alias to the old name to keep existing scripts working.
Enhancements suggested by Nikolai Verner-Christensen - support loading
scenarios from {FG_HOME}/Scenarios, {aircraft-dir}/Scenarios and
{add-on}/Scenarios.
Additionally, allow passing the path to a scenario file to
—ai-scenario, eg —ai-scenario=/home/jmt/FGFS/my-test-scenario.xml
When a scenario defines a carrier, and —carrier is used to request a
carrier start, we now auto-load the corresponding scenario, to give
a nicer user experience.
The problem was using FLT_MAX, FLT_MAX to disable a model; this tricked OSG into thinking that FLT_MAX was a valid range and therefore didn't do the update traversal (found by Stuart).
The correct technique to disable a model is to set the min/max range to 0,0
Also generally improved the way that the ranges are managed.
If a model is marked as <usage>interior</usage> there were a number of problems.
1 - the LOD setting AI/MP interior used the distance from the aircraft; this obviously doesn't quite work for when using the model view.
2 - with the way that models are now loaded as two LOD levels only the interior from the first model loaded (usually the lowest detail) would be considered or processed because the model loader had marked itself as already run (which it had, but not for the model that was actually just loaded.
(2) above could also be the cause of other things not working because the nasal model loaded would not be called, nor would the sound path be setup. There could be other things that aren't working properly because the assumption is that there is just one model.
The fix for (1) is to use the standard OSG PagedLOD and let it handle the details, so I've changed the interior to use this and removed the distane from ownship checks.
The fix for (2) is to use a map to decide if the model that has just finished loading has already been processed, and if not then proceed as normal.
Change the single model case to always set the range on the only model rather than the constant modelHighDetail. This is a regressions caused by the change from 0 to modelHighDetail and the reordering the list. When there is only one model the setRange must always refer to model range index 0.
- This could have caused models to not display correctly.
Rework the LOD ranges.
1. The scenery ranges are now deltas (avoids overlapping values)
2. The AI/MP pixel mode now has a default radius that is 20 for Aircraft, 200 for ships, 350 for carriers. This is a simple constant in a virtual function.
3. Added the ability to set the AI/MP ranges equal which means use the low detail model.
4. Changed high detail only to be indicated by a -ve number in maxRangeDetail
5. Re-ordered the range list to go from lowest detail at [0] to highest detail at the end. This is because OSG always loads the models starting from zero on the assumption that the detail increases with the index.
This fixes the pixel mode, which previously would use the radius of the parent which would be confusingly large, and unrelated to the actual size of the model. With the simple defaults that we have the pixel values set in the ranges won't exactly match the rendered size of the model on screen, but it will be a lot closer and more importantly meaningful.
Aircraft can now set a /sim/model/fallback-model-index property that is transmitted over the MP network.
Receiving clients use this as an index into AI/Aircraft/fallback_models.xml to determine a model to use if the model path (/sim/model/path) cannot be found under Aircraft or AI/Aircraft. This allows aircraft developers to identify a suitable fallback model to be used for those who do not have their aircraft installed.
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.
/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.
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.
the current timestamp used in mp protocol and in AImultiplayer is not a good one:
it can pause, or even change speed if we change warp value.
we want it to be used for network protocol lag and jitter estimation, and
a time flowing linearly on both side is needed, here's a first introduction
of this timestamp relates to real elapsed time.
here it's initialised to the system clock, then follow the monotonic clock.
in future improvement, it will allow time synchronisation betwen mp players,
to have a very good close formation flight experience.
Jean Pellotier, 2018-01-02 : we don't want interpolation for integer values, they are mostly used
for non linearly changing values (e.g. transponder etc ...)
ref: https://sourceforge.net/p/flightgear/codetickets/1885/
Rewrite the position-init code for carrier starts, to precisely wait
on the carrier model being loaded, before proceeding with FDM init.
This allows the FDM to see the correct carrier model in the ground
cache, and hence avoids starting in the water.
To implement this, the CheckSceneryVisitor is used to force the carrier
model to be loaded while the splash-screen is visible.
This reduces the log noise in release builds, relating to AI ground-nets
with incomplete data, especially the commonly occurring ‘gate XYZ
doesn’t seem to have any routes associated with it’ message.
https://sourceforge.net/p/flightgear/codetickets/1974/
Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
AI wake code is still dead code except that it is now compiled with FG.
Input data for wake computations are extracted from the performance database. The data must be specified as follows (values are for illustration only) :
<geometry>
<wing>
<span-ft> 100. </span-ft>
<chord-ft> 12. <chord-ft>
</wing>
<weight-lbs> 90000. </weight-lbs>
</geometry>
In order to compute the AI aircrafts wake, the FDM will need access to the list of AI aircrafts as well as being able to compute their range to discard aircrafts which are too far.
Some buggy *.groundnet.xml files (as KSEA currently on TS) define the
pushback hold point for some parking positions as a node on a runway.
In this case, this the pushback hold point for parking
'North_Cargo_Ramp', defined as node 5344 in
Airports/K/S/E/KSEA.groundnet.xml, which is defined twice (second error),
first as:
<node index="5344" lat="N47 27.774559" lon="W122 18.465257" isOnRunway="1" holdPointType="PushBack" />
and then as:
<node index="5344" lat="N47 27.725747" lon="W122 18.159649" isOnRunway="1" holdPointType="PushBack" />
(due to code in flightgear/src/Airports/dynamicloader.cxx, it should be
the second one that wins, which is not on a runway but on apron in the
north cargo area)
As a consequence, when this gate is selected for an AI aircraft, the
pushback route has only one node (since the pushback hold point is then
the closest point to itself supposedly on runway!), and the
corresponding FGTaxiRoute instance has an empty 'routes' member
variable, which FGTaxiRoute::next() doesn't handle gracefully
(segfault).
It may be that an additional check/change could be desirable in
FGTaxiRoute::next() in such a case (one node and obviously no route in
the FGTaxiRoute instance), however I'm not sure how Durk wants this case
to be handled, since FGTaxiRoute::next() seems to iterate on nodes.
This fixes the bug reported at:
https://forum.flightgear.org/viewtopic.php?p=308397#p308397 and
https://sourceforge.net/p/flightgear/mailman/message/35776552/
Thanks to yanfiz and wkitty42 for the report, and to gooneybird for
inspecting the groundnet file.
Make a single Cmake value to expose the build type to code, and use
this to default a run-time ‘developer-mode’ property, which can be
over-ridden from the command line.
Use this to drive the different warning levels. Policies subject to
review, especially whether nightly builds should default to
developer mode or not.
Whilst debugging I had a cannot increment nextIt - because it was at end(). No idea if this could ever happen in flight but it still seems sensible to protect against it.
Remove uses of .str(), .c_str() and some other methods of SGPath.
Pass SGPath directly where possible, or explicitly convert to the
appropriate 8-bit encoding.
- 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.
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 ;)
This patch enables AIModels to use the size on the screen for LOD instead
of distance from eye point.
With /sim/rendering/static-lod/ai-range-mode-pixel set to true
/sim/rendering/static-lod/ai-detailed now contains the minimum size of the
model on the screen to be displayed. Values of 10-50 seem to make some sense.
- Introduce a new LOD: ai-interior
- Load a <model> with <usage>interior</usage> on-demand
- Avoid to load the cockpit of players in MP
- Default LOD is 0.0 - 50.0 meters
Firstly search model in $fg-root/AI/ path,
if not found, search model in --fg-aircraft paths,
if not found, search model in $fg-root/Aircraft path
This commit should solve the complaint "I have an aircraft in a separate Aircraft/ folder
but during MP session other user are shown with the aircraft from the $fg-root/Aircraft path
instead of this behaviour I want to see the aircraft from my separate Aircraft/ folder"
This is a work-around, probably indicates some glitch in the traffic
module flight-plans. Avoid a crash, also refine the exception logic
so individual AI objects can fail.
Nick Vatamaniuc: fix AI aircraft not updating waypoint headings when using custom flightplans.
(Commented out log-line following a non-parenthesised if() test causing problems)
If you want a scenario in a particular session of the sim, ask for
it on the command line / config files, or enable in the GUI.
Note if you had previously 'sticky' scenarios in your autosave.xml, you
will still get them until you clean your autosave, or disable them in
the GUI.
