Current Situation / Problem
Only one X-Plane plugin can take control of TCAS targets at a time. This is a X-Plane design limitation. See Overriding TCAS and XPLMAcquirePlanes.

Suggested Solution
A separate plugin, a TCAS concentrator, acts as kind of a proxy in that it is the plugin to actually have control of X-Plane's TCAS targets, receives plane positions from collaborating plugins which draw planes (like LiveTraffic, xPilot and the like), orders these planes by distance and forwards the first 63 to X-Plane's TCAS target system.

Design Approach

Collaborating Plugin

• Can identify if there is a TCAS concentrator available and if it is in control of TCAS targets (via a provided dataRef)
  • If there is an active concentrator: Forwards all plane positions to the concentrator (via a binary dataRef)
  • Otherwise can follow the legacy approach (try to acquire TCAS control and set the TCAS targets itself)

TCAS Concentrator

• Publishes its status (has control or not) via dataRef
• Offers a binary-write dataRef, with which collaborating plugins send aircraft information
  • For performance reasons, the data should come in a binary C structure, one per aircraft
  • includes a priority as XPMP2 supports now already
  • includes a flag if the plane should appear in a TCAS map layer (see below)
  • includes a label (used in the map)
  • basic version handling needs to be included, e.g. by the classic approach of including a size field
• Keeps a list of all aircraft positions from all collaborating plugins, including a plugin id
  • Sorts by prioritized distance
  • forwards the data of the first up to 63 aircraft to X-Plane's TCAS target dataRefs
  • remove aircraft not updated for more than 10 frames (as X-Plane does it, too)
• provides a "TCAS" map layer
  • This is needed to handle the map flexibly: In X-Plane's TCAS targets handling, it is either possible to have X-Plane draw standard plane icons in the internal map automatically, or to switch that off, e.g. to have the map layer provided by the plugin. The concentrator should provide this flexibility, too. But if one collaborating plugin wants automatic plane icons, the other not, then X-Plane's standard functionality is of no use any longer.
  • There is just one map layer provided by the concentrator. (A design which creates and administers several map layers is possible...but probably overkill given the main goal of the concentrator.)
  • Icons can be chosen like XPMP2 does it already based on ICAO aircraft type (which is a TCAS target field anyway), which would be added functionality beyond X-Plane's standard approach
• Much code could be taken over from, ideally shared with XPMP2:
  • prioritized distance handling
  • TCAS target dataRef handling
  • even the TCAS fallback for pre-11.50 version could be supported
  • map drawing
  • The TCAS Concentrator plugin should be an additional target in the XPMP2 project.
• Will need a few menu items for configuration and actions:
  • Setting: try acquiring TCAS immediately at startup (this is against the TCAS plugin coordination rules, but the concentrator would do it for the benefit of many)
    • which also means: we need a config file
  • "TCAS Control" (as LiveTraffic does it) to indicate, acquire, and release TCAS control
• A simple list of admnistered aircraft is probably helpful also for debug purposes

XPMP2

• should support TCAS Concentrator automatically out of the box
  • provide a config setting to switch it off...but what for?
• A call to XPMPMultiplayerEnable should
  • return success in case an active TCAS concentrator is found and feed that in the future
  • otherwise perform as today
• Feeding the TCAS connector needs to be verified every frame: It could have given up TCAS control or have gotten deactivated
• if feed to TCAS, send all planes over there, otherwise do as now

Benefits
The planes of more than one multiplayer plugin can appear on TCAS systems and can be made available to 3rd party plugins reading this data (like map or camera tools).

Additional context
The idea has also been formulated by Kuroneko.

Current Situation / Problem
3rd party plugins cannot find out which model a rendered plane uses.
There is a use case at least for the camera plugin ABC, which asks for a value similar to what LTAPI returns through LTAPIAircraft::getCslModel().

Suggested Solution

Extend the already existing set of shared dataRefs:

• Add a shared dataRef sim/multiplayer/position/plane#_cslModel filled with XPMP2::Aircraft::GetModelName()
• Document the new shared dataRef in the developer docs

Benefits
Use cases are probably limited...but at least ABC has what it asks for. It somehow uses it to fine-tune the camera per displayed model.

Additional context
Discussed in a support thread in the context of the Remote Client. The solution will be generic for XPMP2, however, ie. for any plugin based on XPMP2.

Current Situation / Problem
See TwinFan/LiveTraffic#188
Distance up to which labels are drawn is hard coded to 5,000m at the moment. Some people like to see labels earlier.
Also, labels are cut off at X-Plane's reported visibility.

Suggested Solution
Provide a configuration option for maxLabelDist, either in the configuration callbacks or as a separate function, or as addition to the existing XPMPEnableAircraftLabels() call.

Benefits
Allows plugins to offer the user to chose when to show labels.

Additional context
TwinFan/LiveTraffic#188

Current Situation / Problem
In a networked multi-PC setup several only loosely coupled instances of X-Plane run in parallel, usually to drive different screens. Running LiveTraffic or any other XPMP2-based plugin will not guarantee that all planes are always fully aligned and placed at the exact same location. This will look ugly when planes move across screens driven by different PCs.

Suggested Solution
Synchronize plane objects across the network, driven by a master.
Basic design ideas:

• There are masters (the actual XPMP2-based plugins) disseminating position information via UDP multicst into the local network
• There is one centrally provided client plugin per networked PC, to be developed as part of the XPMP2 project, that reads those multicast messages and displays the aircraft in the networked PCs.
• The XPMP2 master shall be independent of the X-Plane master. This would allow to run the XPMP2 master on another of the networked PCs for load balancing. Or to use the same principle for networked gaming setup with several totally independent players, which still could share the same XPMP2-driven planes.
• It shall be possible to collect multicast data from different XPMP2-driven plugins, even if they run on different PCs. So the collecting client needs to be able to identify different sources and map their aircraft ids in case they are in conflict. These are in principle ideas also valid for the TCAS Concentrator #16, so parts of the code will lay the basis for that one, too.
• Standard setup shall be "zero-config": The masters will first listen to the multicast port. As soon as they receive something they will start broadcasting their own data, too. The clients will first send a "want-to-have-data" message on the multicast address and repeat that every once in a while until they eventually receive actual data.
• Masters send their configuration regularly.
  • The client needs to replicate relevant configuration settings like logging level, replace dataRefs/textures, label and map settings; as different masters could be configured differently the client needs to decide for a "best effort" config for each of these items
  • The client needs to request TCAS/AI if any master had so
• The network messages need to include per place:
  • Position, attitude
  • Model (the client needs to have the same set of CSL models installed, and it still needs to be able to do its own matching in case the requested model is not accessible)
  • Configuration, ie. the array of animation dataRefs
  • To save network bandwidth data compression shall be applied: Full data set only every once in a while (so that clients have a chance to fully synch with a new plane), diff data only inbetween, animation dataRefs only if they really change...
• Special situations that require special handling
  • Change of visibility
  • Change of CSL model
  • Removal of aircraft
  • Stale aircraft (not updated in some time)
  • Stale master (not sending in some time)
• Read/write a config file to be able to change a few parameters and enforce network functionality
  • Read by all XPMP2-based plugins, including Remote Client
  • Example provided as Resources/XPMP2.example.prf
  • Includes switch on/off/auto, port, multicast address, max msg length

Benefits
Better looking support for a networked setup

Additional context
Originally discussed as issue TwinFan/LiveTraffic#126, but now decided to be solved centrally in XPMP2 and hence moved here.

Describe the bug

XP12 replaces some multiplayer dataRefs, resulting in Log.txt output like

Line 210: [LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_pitch' has been replaced. Please use the new name.
Line 212: [LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_roll' has been replaced. Please use the new name.
Line 214: [LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_yaw' has been replaced. Please use the new name.

That dataRef names always had that spelling mistake...and now they get replaced by array(!) dataRefs, which is unfortunately a totally different naming concept:

sim/multiplayer/controls/yoke_pitch_ratio	float[20]	y	[-1..1]	The deflection of the axis controlling pitch.	
sim/multiplayer/controls/yoke_roll_ratio	float[20]	y	[-1..1]	The deflection of the axis controlling roll.	
sim/multiplayer/controls/yoke_heading_ratio	float[20]	y	[-1..1]	The deflection of the axis controlling yaw.	

So instead of requesting plane%i_yolk_pitch for 20 different names we would now in XP12 need to deal with a (proper) array dataRef. So this is way more of a coding change than just replace one string by another. To make matters worse, most multiplayer dataRefs stay the old system (plane%i_...) while only those 3 change to a float array type.

For a plugin that runs under both XP11 and XP12, we would now need version-specific processing during runtime. I am actually considering to drop support for multiplayer/.../yoke... in XP12 altogether: TCAS override is always available in XP12, so there would be no need to provide yoke details via the old multiplayer dataRefs. To be verified.

To Reproduce

Run under XP12.

Expected behavior

No deprecation messages in log or to user.

Technical Info

• OS: any
• X-Plane version: 12 alpha
• LiveTraffic version: 2.55

Log.txt

Here output from a DEBUG version, in which even the error callback is informed...though this appears to be in no way fatal:

LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane1_yolk_pitch' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_pitch' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane1_yolk_roll' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_roll' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane1_yolk_yaw' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane1_yolk_yaw' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane2_yolk_pitch' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane2_yolk_pitch' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane2_yolk_roll' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane2_yolk_roll' has been replaced. Please use the new name.
LiveTraffic FATAL ERROR CALLBACK: Dataref 'sim/multiplayer/position/plane2_yolk_yaw' has been replaced. Please use the new name.
[LiveTraffic/win_x64/LiveTraffic.xpl]: Dataref 'sim/multiplayer/position/plane2_yolk_yaw' has been replaced. Please use the new name.

Current Situation / Problem
Many, if not all, models require some additional work to unlock all features with XPMP2. They might not use correct dataRefs for all features or use unsupported parameters like passing textures as parameters.

The Python script CSL2XSB has been created to correct these issues. Documentation of what the script does is there. This requires an additional setup step by users.

Suggested Solution
Instead of having the user run a spearate script let XPMP2 do the conversions on the fly while reading the .obj models but in a lasting way:

• Replace dataRefs with dataRef names as supported by XPMP2 (provides for rotating props and the like)
• Create separate .xpmp2.obj files for each texture parameter (allows usage of X-CSL models)
• Write new copies of the files in a way that XPMP2 notices on next use that the model does not need to be converted once again, but uses the already converted version right away, e.g. by adding another extension to the file name.
• Provide configuration options for dataRef replacement and texture replacement
• Documentation:
  • xsb_aircraft.txt format of OBJ8 parameters as now the 2 texture parameters are recognized again
  • copy-on-use feature including what the config parameters mean

Alternatives
Have the user run the Python script as of now.

Benefits
All users, also less experienced not willing to fiddle with Python, benefit from feature like rotating props and a larger choice of models.

Additional context
LiveTraffic's documentation of the CSL2XSB script

Describe the bug
The multiplayer idx returned to the calling plugin is now zero-based.

To Reproduce / Source Code Example
Check XPMPPlanePosition_t::multiIdx returned for any aircraft and compare with multiplayer idx of dataRefs, it's always one too small.

Expected behavior
Should be 1-based as 0 is the user's aircraft.

Version

• OS: All
• X-Plane: All

Additional context
Report on the support forum.

Current Situation / Problem
XPMP2-Remote by default displays aircraft labels. It is neither synched with the feeding applications nor can it be configured on the client side.

Suggested Solution
Provide a 3-way switch via menu:

1. Synch with feeding clients (default)
2. Switch on
3. Switch off

Benefits
Have control over the display of labels at the remote clients.

Additional context
Mentioned a bit hidden in a review.

Hello, I'm working to change your version of libxplanemp for your new XPMP2 for my FF2Play project.
It works fine on win and linux.
On macos , the cmake try to find ../Info.plist on build folder.
Because my project use XPMP2 as a git submodule and CMakeList.txt use add_subdirectory and link directly to the XPMP2 lib.

https://bitbucket.org/FFS2/xffs2play/src/3c35645a9c8cdc19c0ac932d590fefcba002cf23/CMakeLists.txt#lines-101

I success to build by replacing "../Info.plist" by ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist in your CMakeList.txt

anyway many thanks for yours works, the lib works fine with the last Xplane beta ;-)

Sorry for posting this as an issue, it's more of a question.

On this repo you say we need to run the CSL2XSB.py script to convert X-CSL models to get all functionality, but on the CSL2XSB xplane forum page, you write that it is unnecessary.

So, I understand I can use XPMP2-based plugins without the python script, but will I have full functionality?

Thanks!

Describe the bug
the labels only appear for the planes showing on my central monitor (main monitor). Those on the 2 side monitors have no labels, but acquire them as they cross into the middle one.

Also, users consistently report (for ages already) that in VR labels are seen in one eye only. Assuming that the second eye is technically provided as a second screen, this issue is actually the same.

To Reproduce / Source Code Example
Need 2 or monitor setup. Enable Labels.
Watch labels for planes on secondary monitor.

Expected behavior
All planes have labels on all monitors.

Version

• OS: any
• X-Plane: any

Additional context
Reported in Discord's beta channel.

Current Situation / Problem
Currently, to understand how XPMP2 works and what it offers, several places need to be read.

Suggested Solution
Consolidate developer's documentation here as GitHub pages:

• File format for xsb_aircraft.txt (this is currently scattered across kuroneko's wiki)
• dataRefs supported by XPMP2 (this is partly at kuroneko's, partly at my fork)
• Provide some general "how it works" background, can base on kuronekos wiki (but shorter) and on some of my additions
  • Startup sequence
  • Model Matching (see LT FAQ)
  • TCAS support (again see LT documentation)
  • AI/multiplayer support (LT has a bit)

Benefits
Easier for developers to use (all features of) XPMP2.

Describe the bug
Engines don't rotate in the sample plugin code. I am on XP 11.5 with Vulkan.

To Reproduce / Source Code Example
Build Sample plugin and install in XP 11.5 and set it to Vulkan drivers.

Expected behavior
Engines/Props would rotate on the aircraft in front of me doing circles.

Version

• OS: Win 10
• X-Plane: 11.5 Vulkan

Current Situation / Problem
Not being singed/notarized makes running plugins on Mac difficult...users have to apply manual solution allowing XPMP2 Remote Client through Gatekeeper

Suggested Solution
Code sign / notarize.
There's a thread on X-Plane.org explaining the essence, including a script used by Laminar, which allows doing all that from within deployment scripts.

Benefits
Plugins "just work" on Mac.

Describe the bug
XP 11.50 Beta 9 introduced a bug that made X-Plane crash as soon as the map is moved a certain distance, ie. the projection parameters changed.

I could reproduce the problem with a slightly changed sample map plugin and filed a bug with Laminar. It was accepted as XPD-10825.

As a workaround XPMP2 disabled the internal map layer. Instead, X-Plane now draws some standard icons into the map for the first 63 planes.

Expected behavior
This issue is entered to remind myself to reactivate the internal map layer once XPD-10825 gets fixed and the fix published in a XP (beta) release.

Version

• OS: any
• X-Plane: 11.50 Beta 9

Current Situation / Problem

Up to XP11, planes driven by TCAS dataRefs did not produce wake turbulences. With XP12, a solution is provided:
https://developer.x-plane.com/article/plugin-traffic-wake-turbulence/

Suggested Solution

Wake dataRefs

Support the newly provided sim/cockpit2/tcas/targets/wake dataRefs. A few new attributes in the XPMP2::Aircraft will be required and linked to those dataRefs.

sim/cockpit2/tcas/targets/wake/wing_span_m	float[64]	y	meter	wing span of the aircraft creating wake turbulence
sim/cockpit2/tcas/targets/wake/wing_area_m2	float[64]	y	meter	wing area (total area of both wings combined) of the aircraft creating wake turbulence
sim/cockpit2/tcas/targets/wake/wake_cat	int[64]	y	enum	wake category of the aircraft. This is for information purposes only and is not used to calculate the actual strength of the turbulence. 0 = Light, 1 = Medium, 2 = Heavy, 3 = Super
sim/cockpit2/tcas/targets/wake/mass_kg	float[64]	y	kg	actual mass of the aircraft creating the wake
sim/cockpit2/tcas/targets/wake/aoa	float[64]	y	degrees	angle of attack of the wing creating the wake
sim/cockpit2/tcas/targets/wake/lift_N	float[64]	y	Newton	instantaneous lift force of the whole wing generated right now, in Newtons

From this post by Philipp, after asking which dataRefs really require being written to:

All of them, for an accurate wake size and strength and lifetime duration estimate. That's why they are there! The wing area, span, t/o weight are public data for all aircraft types (maybe not all military ones), so you should be able to build a lookup table for ICAO type A320 to 123sqm of wing area and 34m of wing span. The weight you could use a certain percentage of MTOW, which would also be a lookup by type. Maybe you could change the weight based on the departure/destination airports if they are known, so that a long range flight weighs closer to maximum than a short range flight.

The lift force in Newtons is weight times 9.81 almost all of the time. You set it to 0 once the weight is carried by the wheels, so you don't leave a wake when taxiing on the ground so you don't blow people of the taxi way. During takeoff you can phase it in when approaching lift-off speed. During flight, lift force should equal weight times g, otherwise the plane wouldn't fly. If you wanted to be super accurate, you could calculate the acceleration vector along a trajectory of the aircraft of a few seconds to determine turning forces (i.e. calculate the g the pilot is pulling to achieve the turn radius given the speed). But for airplanes other than military or aerobatic I don't think the difference from 1g will ever be significant.

Defaults based on WTC

XPMP2 is aware of a plane's wake turbulence category (WTC) from Doc8643 data: L, L/M, M, H, and J. So the idea is to provide some default data per WTC value.

Alternatives

In case of no change, X-Plane will always apply a default assumed plane size matching a 10t business jet (see above developer article).

Benefits

Wake turbulences...so don't fly close to the generated traffic!

Additional context

There is a long-standing issue TwinFan/LiveTraffic#59.

Current Situation / Problem
Currently, XPMP2 treats the "id" of a CSL model as defined in the OBJ8_AIRCRAFT line, as unique across all models:

EXPORT_NAME __Bluebell_Airbus

OBJ8_AIRCRAFT A320_DLH

Strictly speaking this violates the xsb_aircraft.txt specification, which "only" stipulates that the id must be unique within a package, which is defined by the EXPORT_NAME line.

Currently, if another package also defines a model named A320_DLH it will be ignored.

Suggested Solution
The other package's A320_DLH shall also be read and be available.
If now an A320 of DLH is requested, then XPMP2 will find 2 models matching the request and will pick one of them randomly.

Technically, this can probably be easily achieved by changing the definition of CSLModel::cslId from that name after OBJ(_AIRCRAFT only to a combination of EXPORT_NAME and OBJ8_AIRCRAFT name, like __Bluebell_Airbus/A320_DLH in the above example, which then would be different from, say, A320/A320_DLH as used by the X-CSL package.

Benefits
More models will be used.
Will certainly make debugging matching even more complex...

Current Situation / Problem
Each CSL model definition comes with one ICAO/AIRLINE/LIVERY/MATCHES line. Or, if there were multiple of these lines, then the last definition would win.

Suggested Solution
Allow the use of multiple such lines to define multiple matching criteria for which the model would be a match. While this will rarely make sense for different airline liveries, it can make sense to more easily allow the assignment of special liveries to a limited set of airframes.

Would look like this:

OBJ8_AIRCRAFT A320_DLH_StarAlliance
OBJ8 SOLID YES __Bluebell_Airbus/A320/A320_DLH_SA.obj
VERT_OFFSET  3.5
LIVERY A320 DLH D-AIQD
LIVERY A320 DLH D-AIQW
LIVERY A320 DLH D-AIUD

**Alternatives**
Currently, the full set of all 4 lines would need to be repeated per airframe.

**Benefits**
Makes it easier to define special liveries for a limited set of airframes.

**Additional context**
Idea came up when writing [this forum comment](https://forums.x-plane.org/index.php?/forums/topic/212454-adding-new-texture/&do=findComment&comment=1918245).

Describe the bug
CTD in the call to XPLMInstanceSetPosition:

void Aircraft::DoMove ()
{
    // Only for visible planes
    if (bVisible) {
        // Already have instances? Or succeeded in now creating them?
        if (!listInst.empty() || CreateInstances()) {
            // Move the instances (this is probably the single most important line of code ;-) )
            for (XPLMInstanceRef hInst: listInst)
                XPLMInstanceSetPosition(hInst, &drawInfo, v.data());
        }
    }
}

According to log situation seems to be:

• Model got matched:

0:53:34.341 LiveTraffic WARN  LTFlightData.cpp:2343/DetermineAcModel: Tracking data for 'A8FA3F' (man 'Cessna', mdl '402C') lacks ICAO a/c type code, but derived C402 from mdl text
0:53:34.341    LT/XPMP2 INFO  CSLModels.cpp:1085/CSLFindMatch: MATCH INPUT: Type=C402 (WTC=L,Class=L2P,Related=131), Airline=KAP, Livery=N678JG
0:53:34.341    LT/XPMP2 INFO  CSLModels.cpp:1191/CSLFindMatch: MATCH FOUND: Type=C421 (WTC=L,Class=L2P,Related=131), Airline=BGM, Livery= / Quality = 16 -> BB_GA C421_BGM
0:53:34.341 LiveTraffic INFO  LTAircraft.cpp:1191/LTAircraft: Added aircraft A8FA3F (C402 9K331), operator '', a/c model 'BB_GA C421_BGM', flight model [GA], bearing 125, distance 5.7nm, from channel OpenSky Live Online

• Model's .obj got successfully loaded

0:53:34.366    LT/XPMP2 DEBUG CSLModels.cpp:177/Load: Async load starting  for __Bluebell_GA/C421_BGM from Resources/plugins/LiveTraffic/Resources/CSL/BB/BB_GA/C421/C421_BGM.obj
0:53:36.622    LT/XPMP2 DEBUG CSLModels.cpp:234/XPObjLoadedCB: Async load succeeded for __Bluebell_GA/C421_BGM from Resources/plugins/LiveTraffic/Resources/CSL/BB/BB_GA/C421/C421_BGM.obj

• Crash...probably right after creating the instance (i.e. just 2 lines before as part of the if statement):

0:53:36.648    LT/XPMP2 DEBUG Aircraft.cpp:484/CreateInstances: Aircraft 0xA8FA3F: Instance created
--=={This application has crashed because of the plugin: LiveTraffic}==--
(Art controls are modified.)

Note the fact that art controls are modified...but in this case it looks rather like a lame excuse.

To Reproduce
Yet unclear

Expected behavior
No crash

Technical Info:

• OS: Windows 10.0 (build 18363/2)
• X-Plane version: X-Plane 11.50b14 (build 115026 64-bit) using Vulkan
• LiveTraffic version: 2.07.200712
• xPilot is also affected

Log.txt

Log_Dump_CTD_DoMove.zip

Describe the bug

When used in a master client configuration with external views (each running XPMP2-Remote), LiveTraffic (Master) sends out the position data for the remote clients on the first NIC listed in windows. When first NIC is disabled, traffic is seen on clients.

Expected behavior

Send multicast data over same nic used for external view configuration. Or have a drop down selection for which NIC to use for sending data.

Technical Info

• OS: Win
• X-Plane version: 12.07
• LiveTraffic version: 3.4.3

Log.txt

Log.txt

Current Situation / Problem
Let's assume we have:

• an live aircraft that is a B739 AUI
• any B739 model, like B739 DAL, but not a B739 AUI
• a B738_AUI CSL model

With the current matching, the B739_DAL model would be picked because of the exactly matching aircraft type. However, in this scenario, the B738_AUI would visually look better.

Suggested Solution
We need to raise importance of livery. But it cannot be raised fully above aircraft type, there must be a limit.

The limit should be related.txt. So the rule could probably be:

• Best match certainly stays matching aircraft type and livery
• Next should be "related" with matching livery
• Then matching a/c type, but non-matching livery
• Then "realated" with non-matching livery

Benefits
Looks better if "related" models with matching livery are available.

Additional context
First that based on this support thread.

Current Situation / Problem
No value for flight_id is currently transferred to the Remote Client.
Therefore, the dataRef sim/cockpit2/tcas/targets/flight_id is not populated.

Suggested Solution
flight_id is populated with what the virtual function XPMP2::Aircraft::GetFlightId() returns. Transfer this value via message to the Remote Client in a new field. That requires a new version of the RemoteAcDetailTy message and therefore handling and testing of cross-version scenarios.

On the remote side, the value can then just be stored in XPMP2::Aircraft::acInfoTexts.flightNum, from where it will automatically be used for populating the dataRef sim/cockpit2/tcas/targets/flight_id.

Benefits
dataRef sim/cockpit2/tcas/targets/flight_id filled in instances where TCAS/AI is controlled by the Remote Client.

Additional context
Thread on X-Plane.org.

Current Situation / Problem
Subsidiary airlines operate under their own airline code but use liveries (or even actual planes) of their mother companies. These often new subsidiary airlines codes aren't mentioned in the often older xsb_aircraft.txt files. As a result, planes of the subsidiary airline are rendered with a random livery although probably a matching livery for the mother company would be available.

Suggested Solution
Provide a way to match subsidiary and mother company, similar to what happens to aircraft type codes in the related.txt file, just for airline codes, like

; Aer Lingus
EIN EUK
; Ryan Air
RYR RUK

Alternatives
Lots of fiddling right in the xsb_aircraft.txt file to add AIRLINE lines under each EIN model to also allow matching for EUK.

Benefits
Better livery matching for subsidiary airlines.

Additional context
Suggested in a forum post.

Describe the bug
User report: X-Plane froze, last line in log is

LT/XPMP2 ERROR Sound.cpp:835/SoundUpdatesDone: FMOD Error 36 - 'The vectors passed in are not unit length, or perpendicular.' in FMOD_System_Set3DListenerAttributes

To Reproduce / Source Code Example
Unclear.
But can probably be forced in debugger by sending wrong coordinates into FMOD_System_Set3DListenerAttributes.

Expected behavior

1. Error shall not freeze X-Plane, check error handling.
2. Error shall not happen.

Version

• OS: Reported on Linux
• X-Plane: 12.00rc1
• using LiveTraffic 3.2.0

Log.txt
Log-Snd_Freeze.txt

Additional context
Original user report is a comment to LiveTraffic.
More discussion then tracked in a support thread.

Hello,

I'm having some troubles with this implementation. I have sub-classed the XPMP2::Aircraft class through MyAirplane class.

class MyAirplane : public Aircraft
{
public:
    MyAirplane(const std::string& _icaoType,
        const std::string& _icaoAirline,
        const std::string& _livery,
        const std::string& _modelName = "") :
    Aircraft(_icaoType, _icaoAirline, _livery, _modelName)
    {
		
    }

    virtual void UpdatePosition()
    {
        SetLocation(Position.lat, Position.lon, Position.elevation);

        drawInfo.heading = Position.heading;
        drawInfo.pitch = Position.pitch;
        drawInfo.roll = Position.roll;
    }

    XPMPPlanePosition_t Position;
};

Currently, I'm using a std::map to hold the MyAirplane objects. The issue I'm having is that any object that is inserted into my map is almost immediately destructed through the within XPMP2::Aircraft. I am able to see this because I implemented the CBPlaneNotifier and each aircraft object is created and then destroyed.

Am I going about this the wrong way? If so, what is the best way to keep a collection of planes so that I can update them?

std::map<std::string, MyAirplane*> m_Planes;

MyAirplane *aircraft = new MyAirplane(typeCode, airlineIcao, liveryStr, modelStr);
m_Planes.emplace(key, aircraft); // key is the aircraft's callsign/tailnumber

Current Situation / Problem

Currently, XPMP2 Remote Client has a menu item in the Plugins menu that shows "Active"/inactive state, but that also serves as a toggle (i.e., which users can click on to change the state to inactivate the concentrator, while leaving the plugin enabled).

In fact, the only way to toggle the plugin's "active" state, is to use the menu. (There is no command or other way to trigger this functionality otherwise.)

This results in several (albeit minor) problems:

• utility: toggling this state is probably the most common action users will perform (if they know what's good for them; since toggling TCAS on/off really doesn't do much here and may just confuse users as it did me!);
• usability: it's confusing to users to have some menu items be toggles, and others be just informational, with no UI treatment to distinguish them;
• consistency: this feature is really equivalent to LiveTraffic's "Aircraft displayed" menu item (see below), which has a command associated with it, and which looks different in the menu as a result (not to mention the label itself being different)
• integration/scripting: with the only mechanism here being a menu item (not a command), plugins such as ABC can't readily provide users with a one-click visual solution to toggle this state (which ABC has in its TCAS management menu); whereas, with a command, ABC could simply bind a menu item in ABC's visual control panel, to the command to toggle activation on/off (for example).

Suggested Solution

1. Refactor existing menu handler to pull out the Active-state toggle into its own XPLM command handler. (est. < 10 minutes of work)
2. Register a command handler for e.g. "XPMP2_Remote_Client/Aircrafts/Display" (analog to version in LT).
   • n.b.: "Aircrafts" is a misnomer, since it should be "Aircraft" (uncountable); however, this is proposed for consistency with LiveTraffic's command equivalent, but renaming commands such as "fixing" LiveTraffic is not worth the effort
3. Replace XPLMAppendMenuItem invocation for activate/deactivate toggle, with XPLMAppendMenuItemWithCommand referencing the new command registered above.

Alternatives

• In addition to the above (which is a binary proposal; i.e., there's no better solution that would address this issue), the actual menu option title (in English) could be changed to: "Aircraft displayed (...)". (I.e., identical to LiveTraffic's equivalent menu-item label.)
  • This makes the UI consistent with LiveTraffic, but moreover reinforces with users that XPMP2 Remote Client is actually rendering the aircraft after concentrating them into a single TCAS list.
• Additionally, the "TCAS" menu item could be changed to display-only, where it does not perform a toggle action, since that functionality is really subsumed by the active-status toggle behavior. (It's really an inconsistent state to have the plugin "active" with TCAS "off". So it's better to make TCAS just an informational line item, as with others below.)

Benefits

• Utility:
  • With the proposed solution, users can define a keyboard or joystick shortcut to readily start/stop all traffic (and TCAS control) from the concentrator, in one fell swoop.
• Usability:
  • Using the proposed solution (XPLMAppendMenuWithCommand()) provides a different visual treatment for menu items that effect behavior (such as "toggle"), by showing the user the command they've bound (if any); though this may not be helpful at the outset, it reinforces the distinction later.
  • This may also obviate the need for any toggle behavior for the TCAS menu item just after this, since it could just be to show status (and users would then be pushed to use the simpler traffic on/off feature).
• Consistency:
  • This makes the menu and the command (if provided) match the pattern already established by LiveTraffic, increasing user understanding of the feature, especially if the label is made consistent with LiveTraffic's menu (additional proposal above).
• Integration/Scripting:
  • This allows ABC (for example) to add a menu item to its TCAS control menu to replace e.g. "LiveTraffic TCAS on" when XPMP2 Remote Client is active, with "XPMP2 Remote Client Traffic On" since turning on LiveTraffic's TCAS doesn't make as much sense in that case. (But I still have it in, because I don't want to disable it without a way for users to do the same thing for Remote Client.) Note: I also have a separate "LiveTraffic Traffic on" that toggles on LiveTraffic's traffic display, but that would have a slightly different function here.

Additional context
(None; this is scoped only to the XPMP2 Remote Client plugin.)

Understanding this is a slippery slope that could lead to extra work that I do not intend, such as persistent settings and other commands -- this is very low-hanging fruit and is really all I think users need. Therefore, I believe a lot could be accomplished using this suggested behavior, for very little work (registering a command, changing the current toggle to be inside a command handler, and changing XPLMAppendMenuItem to ...WithCommand.

Thanks for considering this.

Describe the bug
XPMP2 does set a number of TCAS target-related dataRefs, but not

sim/cockpit2/tcas/targets/position/weight_on_wheels

This should be set to true when the plane is on the ground.

Currently, though, XPMP2 does not generically know when a plane is on the ground. This will require a new interface function Aircraft::SetOnGnd() for plugins to inform XPMP2 about a plane being on the ground.

As an additional service, this new function can be coupled with Aircraft::SetTouchDown(), which currently only directly controls the libxplanemp/misc/touch_down animation dataRef, which typically causes CSL objects to emit tire smoke. XPMP2 could offer to automatically control SetTouchDown, like in

Aircraft::SetOnGnd (bool bOnGnd, float fSetTochDownTime = NAN);

with fSetTouchDownTime being an optional parameter denoting for how long the touch_down animation dataRaf is set to true.

Todos

• Provide Aircaft::Is/SetOnGround()
• Set the sim/cockpit2/tcas/targets/position/weight_on_wheels TCAS target dataRef
• Forward the ground-flag to the Remote Client
• Couple SetOnGround() with SetTouchDown()

To Reproduce / Source Code Example
Updating this dataRef is missing in AIUpdateTCASTargets().

Expected behavior
sim/cockpit2/tcas/targets/position/weight_on_wheels should be set to true when plane is in the ground.

Version

• OS: any
• X-Plane: any

Additional context
First reported and locally implemented for xPilot in xpilot-project/xpilot#34.

Problem
This has been reported to Laminar and accepted as XPD-10727:
On Mac OS, in XP 11.50, at least Betas 3+4, and in OpenGL-mode only, X-Plane crashes after a plugin set a user's aircraft model via a call to XPLMSetAircraftModel.

Current Situation in XPMP2
XPMP2 currently includes a safeguard against this crash in form of the config item XPMP_CFG_ITM_SKIP_NOPLANE = "skip_assign_noplane". This is on most cases by default false, only in case of Mac + OpenGL this defaults to true. As a standard config item it can be overwritten by the calling application in the configuration callback.

This config item controls globs.bSkipAssignNoPlane, which in turn in function AIInitPlanes controls if the call to XPLMSetAircraftModel is actually performed.

If the call is not performed, then X-Plane's AI/multiplayer planes will be shown as configured in X-Plane's aircraft settings. If the user configured standard planes there, then they will show in the 3D world overlaid on the XPMP2 planes. Same goes for the map: Two icons stacked over each other.

Workaround: On Mac (and others if he likes) the user could copy NoPlane.acf into the Aircraft folder and then directly assign as an AI plane type. Then again would X-Plane not draw anything into "our" 3D world.

Next Steps
This issue is to track XPD-10727. If it got fixed all the code related to XPMP_CFG_ITM_SKIP_NOPLANE/bSkipAssignNoPlane can probably be removed again.

Describe the bug
After a long (2.5h) LiveTraffic session with lots of traffic, a couple of reference counters don't reach 0 during shutdown. The cars combined even stay at 8:

2:30:32.287    LT/XPMP2 DEBUG CSLModels.cpp:197/Unload: Object __XCSL_CARS/CARS_FollowMe / Resources/plugins/LiveTraffic/Resources/ShippedCSL/XCSL_CARS/ZZZC2.obj unloaded
2:30:32.287    LT/XPMP2 WARN  CSLModels.cpp:348/~CSLModel: Reference counter is 3 while object is being destroyed for __XCSL_CARS/CARS_FollowMe
2:30:32.287    LT/XPMP2 DEBUG CSLModels.cpp:197/Unload: Object CARS/CARS_ZZZC / Resources/plugins/LiveTraffic/Resources/CSL/X-CSL/CARS/ZZZC2_ZZZC2.obj unloaded
2:30:32.287    LT/XPMP2 WARN  CSLModels.cpp:348/~CSLModel: Reference counter is 5 while object is being destroyed for CARS/CARS_ZZZC

To Reproduce / Source Code Example
One way to make it very likely to happen is in LiveTraffic:
Re-load an already loaded CSL package. That will ask all flying planes to re-assess their models, but as no actually new models are available many planes will pick the very same model once again, which causes the invalid reference counter handling, see below.

Expected behavior
No such messages, reference counter should reach zero in all cases.

Version

• OS: any
• X-Plane: any

Log.txt
Log_RefCnt.txt.zip

Additional context
Discussed on Discord, but I have seen such messages in xPilot logs before but had at that time attributed to wrong implementation there. Unclear, as I don't know their implementation.

Current Situation / Problem
XPMP2 has built-in support for a set of shared dataRefs to provide textual aircraft information. This pre-dates the TCAS Override approach and hence uses an older and more cumbersome model of naming the dataRefs...but, hey, it's there.

The Remote Client cannot currently populate reasonable values there.

Suggested Solution

Transfer necessary values to the Remote Client, likely by extending the existing RemoteAcDetailTy message. (Alternative would be to use a new message...but that triggers follow-up issue for how to create new planes and how to synch starting Remote Clients.)

• Add required fields to RemoteAcDetailTy message, requiring a new version of that message
• Thorough cross-version compatibility testing (also required for #25, so deliver them together)
• Document the shared dataRefs in the developer's documentation...they are apparently yet missing.

Benefits
More info to the world, also for the remote instances. FSTramp does use it already.

Additional context
Lacking support noted when entering issue #26.

If XPMP2 matches to a different ICAO type code than what was requested it would be good for the client code to see what it matched to. I could use this to play the appropriate engine audio files.

There is currently and accessor for the model name that was matched but not for the icao type code.

Alternatives
A fully defined pointer to the cslModel would work too. Unfortunately that is just a forward declare in the end user header files

Benefits
See above