For FGAIBallistic objects affected by wind, speed vector denotes airspeed.
However, submodels initialize the speed vector using ground speed of the
parent aircraft, instead of its airspeed.
In effect, this means that wind is added to the initial airspeed,
or 'wind is applied twice on initialization'.
This was very noticeable when releasing a submodel with strong sidewind:
the submodel immediately starts drifting laterally at the speed of wind.
Fix the issue by subtracting wind vector from initial speed in
FGSubmodelMgr::transform for submodels affected by wind.
AirportDyanmics::innerGetActiveRunway can unfortunately return an
empty string even when it return ‘true’. Check for this in the wrapper,
and switch to the fallback, to avoid returning a bogus runway to
other parts of the code.
Sentry-Id: FLIGHTGEAR-39
Avoid 'findShortestRoute' exception by checking both the start
and end nodes are valid first. Doesn't fix the error but avoids
a traffic shutdown.
Sentry-Id: FLIGHTGEAR-2F
When starting at an airport, but not at parking or a runway, create
an empty AIFlightPlan, and ensure the AIManager code doesn’t choke on
empty FPs.
Add a unit-test which simulates the C172 tutorial reposition logic,
which is a little gnarly.
When reachedEndOfCruise fails, return true, so we trigger the next
phase of the flight. Without this we get stuck logging the error
message, but not progressing the flight.
Add a number of properties set by both AI Traffic and Swift aircraft:
gear/gear[0..5]/position-norm
surface-positions/flap-pos-norm
surface-positions/spoiler-pos-norm
surface-positions/speedbrake-pos-norm
controls/lighting/beacon
controls/lighting/cabin-lights
controls/lighting/landing-lights
controls/lighting/nav-lights
controls/lighting/strobe
controls/lighting/taxi-lights
Also improve take-off behaviour
Fgtape:
If multipayer replay is active we write multiplayer packet information to
fgtape files. We also add /sim/replay/multiplayer to the properties written
to fgtape file so at load time we knows whether to expect multiplayer
packets.
New builds of fg can load and replay old recordings.
It is expected (but has not been tested) that old builds of fg will be able
to read new fgtape recordings where /sim/replay/multiplayer was unset or
false (currently the default).
Old builds of fg will not be able to load fgtape recordings that include
multiplayer data.
Avoid incorrect removal of multiplayer aircraft when replaying:
We now clear multiplayer motion history when we jump forwards or backwards
during replay. This ensures that multiplayer code doesn't remove
multiplayer aircraft because of inconsistent-looking time stamps.
We preserve some multiplay information when purging recorded information
to save space. This ensures that when replaying we get frequent enough
packets to avoid the multiplayer code thinking that multiplayer aircraft
have disappeared.
Re-work how position-init and ATC-manager work together to do
parking assignment and fallback (when the parking is unavailable).
Improve the logic for the reposition case, and teach ATC-manager about
reposition explicitly.
When the parking is unavailable, explicitly fall back to best-runway
selection in finalizePosition.
Add many additional position-init tests, to cover all of this.
This adds the names of the available parking positions/catapults
to the property tree, so we can build a suitable in-sim list
of parking positions for users to select from.
Allow selecting carriers from scenarios, and starting at either a
parking position, or a distance offset from the FLOLS (effectively
a crude ‘on-final’)
Extend the —carrier startup option to accept a runway ident of FLOLS,
in conjunction with the existing —offset-distance argument.
Requires corresponding SimGear change. With this last round, we work
with FGData on non-Latin1 path on Windows. (Final fixes are for
Nasal io.readfile, which needed io.stat to work, and SGSky allowing
correct SGPath use)
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/
