Describe the bug
If FlightModels.prf is edited on Windows it might be written with CRLF line endings. That's OK on Windows, but won't work when copied to Mac: Reading the file fails. It interpretes too many non-empty lines before the first section and finally gives up.

Note that many other files in the system, like e.g. in the Bluebell package, just have LF endings and they work fine on Mac and Windows.

To Reproduce
Save FlightModels.prf with CRLF line endings and start LiveTraffic on Mac.

Expected behavior
Handle a CRLF file correctly.

Technical Info:

• OS: Win & Mac
• X-Plane version: 10
• LiveTraffic version: 0.8.x

Log.txt

LiveTraffic 1543183966.3 WARN  LTAircraft.cpp:692/ReadFlightModelFile: Format mismatch in '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf', line 1: Lines before first section ignored
LiveTraffic 1543183966.3 WARN  LTAircraft.cpp:692/ReadFlightModelFile: Format mismatch in '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf', line 2: Lines before first section ignored
LiveTraffic 1543183966.3 WARN  LTAircraft.cpp:692/ReadFlightModelFile: Format mismatch in '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf', line 4: Lines before first section ignored
LiveTraffic 1543183966.3 WARN  LTAircraft.cpp:692/ReadFlightModelFile: Format mismatch in '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf', line 9: Lines before first section ignored
LiveTraffic 1543183966.3 WARN  LTAircraft.cpp:692/ReadFlightModelFile: Format mismatch in '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf', line 10: Lines before first section ignored
LiveTraffic 1543183966.3 WARN  LTAircraft.cpp:692/ReadFlightModelFile: Format mismatch in '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf', line 13: Lines before first section ignored
LiveTraffic 1543183966.3 ERROR LTAircraft.cpp:726/ReadFlightModelFile: Could not read from '/Users/birger/Applications/X-Plane 10/Resources/plugins/LiveTraffic/FlightModels.prf': Too many warnings

Current Situation / Problem
Only one multiplayer client can actively run at a time. Other clients like XSquawkBox, X-IvAp, or PilotEdge take control of multiplayer aircrafts and never release it. That makes it difficult to have such clients run in parallel to each other or to LiveTraffic. This behaviour requires users to move plugins in and out of the plugins folder. Issue #39 eases live a bit by having LT delay acquiring multiplayer planes, but still requires other MP clients to be off.

Suggested Solution
Multiplayer planes are required for the TCAS hack only. So it might be possible to offer an option not to use multiplay planes, i.e. dispense with the TCAS functionality, but still use LT for drawing 3D planes.

This will require quite some changes to the xplanemp library.

Alternatives
Move plugins in and out of the plugin folder...

Benefits
Parallel usage of LiveTraffic and at least one other multiplayer client.

Current Situation / Problem
When the flight path track changes the simulated a/c will actually change track immediately at the point the two flight path segments meet. There is some code to have the heading change of the aircraft (yaw) appear smooth, but track doesn't change smooth.
This is most obvious with ground movements while taxiing but is they same in the air.

Suggested Solution
Aircraft should fly/roll curves.
Challenge is that that would mean not to meet the position where currently the two flight segments meet. This is quite a change in the underlying design of how the aircrafts are moved, which is always from one from pos to one to pos, to be reached by a target timestamp.
However, code determines 'have reached to pos' not by location but only by comparing timestamps. So maybe that design change is not so fundamental after all...

• Add Bezier curves algorithm as a kind of another MovingParam in LTAircraft, which returns a position based on a timestamp input
• Pos handling will change quite a bit: We might still maintain from and to positions, but the actual drawing position ppos will mostly be returned from a Bezier curve, which will no longer be a point on the straight line between from and to.
• Change heading and track implementation: Ideally it should be first derivative of Bezier curve and heading and track would be identical again.
• Change roll implementation: Ideally it should relate to second derivative of Bezier curve with some reasonable max bank angle restriction.

Benefits
More realistic curves. Especially on the ground movements currently look awkward.

Current Situation / Problem
LT reads Doc8643.txt, which comes with the XSB package, is strictly speaking under an EULA, and is pretty outdated.

Suggested Solution
Provide and read the CSV file available from OpenSky Network, which seems to be more accurate (e.g. includes A20N already).

Benefits
More reliable aircraft type info also on newer models

Some channels provide origin/destination/flight code.
Provide these details in the livetraffic/ac dataRefs.

Current Situation / Problem
All coordination calculations use spherical calculations involving expensive trigonometrical functions.

Suggested Solution
Change to planar calculations ("flat earth"). Given that we rarely look farther than 50km this is a very fair approximation.

Benefits
Performance

Current Situation / Problem
OpenSky seems to be able to return ground service vehicles. Currently they appear as A320 and obviously they have no Doc8643 entry.

Alternatives

1. Filter them out.
2. Find a way of displaying a ground vehicle...would need an OBJ8 for that.

Additional context
4B5C1B's master data, found at LSZH Zurich, is:

{
    "acars": false,
    "adsb": false,
    "built": null,
    "categoryDescription": "Surface Vehicle \u2013 Service Vehicle",
    "country": "Switzerland",
    "engines": "",
    "firstFlightDate": null,
    "firstSeen": null,
    "icao24": "4b5c1b",
    "icaoAircraftClass": "",
    "lastSeen": null,
    "lineNumber": "",
    "manufacturerIcao": "",
    "manufacturerName": "",
    "model": "",
    "modes": false,
    "notes": "",
    "operator": "",
    "operatorCallsign": "",
    "operatorIata": "",
    "operatorIcao": "",
    "owner": "",
    "regUntil": null,
    "registered": null,
    "registration": "",
    "selCal": "",
    "serialNumber": "",
    "status": "",
    "timestamp": 1527559200000,
    "typecode": "",
    "vdl": false
}

Describe the bug
On a MacOS 10.12 installation LiveTraffic can't be loaded with error Symbol not found: __ZTISt18bad_variant_access.

To Reproduce
Start X-Plane with LT on a MacOS 10.12 system.

Expected behavior
Starts successfully.

Technical Info:

• OS: macOS: Version 10.12.6 (Build 16G1618)
• X-Plane version: X-Plane 11.26r2 (build 112601 64-bit)
• LiveTraffic version: 0.80 beta

Log.txt

dlerror:dlopen(/Users/admin1/X-Plane 11/Resources/plugins/LiveTraffic/64/mac.xpl, 6): Symbol not found: __ZTISt18bad_variant_access
  Referenced from: /Users/admin1/X-Plane 11/Resources/plugins/LiveTraffic/64/mac.xpl
  Expected in: /usr/lib/libc++.1.dylib
 in /Users/admin1/X-Plane 11/Resources/plugins/LiveTraffic/64/mac.xpl

OpenSky provides a downloadable database:
https://opensky-network.org/datasets/metadata/aircraftDatabase.csv
(Already downloaded)

• Clarify licensing: Are we allowed to use the file?
• Design first:
  • The file doesn't seem to be sorted in any way. How should we speed up access? Read all ICAOs in memory with their file location so we can seek there?
  • How to update the file? Leave it to the user? Make a function to do so? (maybe separate issue)
• Add a channel, which uses this file as a database
• For each query the file is to be accessed (it's 80MB and too big to be cached in-memory).

Describe the bug
If the request to OpenSky Network returns with no aircraft (but otherwise technically correct), then

• LiveTraffic produces an error (LTChannel.cpp:318/ProcessFetchedData: JSON: List of aircrafts (states) not found)
• increments the error counter, and
• will disable the channel after five empty responses.

To Reproduce
Restrict search distance, find a location/time with no traffic, and start the OpenSky channel.

Expected behavior
No error, no disabling of channels.

** Suggestion **
The response received actually looks like this:

{"time":1541978120,"states":null}

The code for not finding aircrafts needs to be enhanced to handle this null case.

Log.txt

LiveTraffic 1541977992.3 DEBUG LTChannel.cpp:252/FetchAllData: OpenSky Live Online: Sending HTTP: https://opensky-network.org/api/states/all?lamin=49.920&lomin=8.359&lamax=50.145&lomax=8.709
LiveTraffic 1541977992.6 DEBUG LTChannel.cpp:267/FetchAllData: OpenSky Live Online: Received 33 characters
LiveTraffic 1541977992.6 ERROR LTChannel.cpp:318/ProcessFetchedData: JSON: List of aircrafts (states) not found
LiveTraffic 1541978012.6 DEBUG LTChannel.cpp:252/FetchAllData: OpenSky Live Online: Sending HTTP: https://opensky-network.org/api/states/all?lamin=49.920&lomin=8.359&lamax=50.145&lomax=8.709
LiveTraffic 1541978012.7 DEBUG LTChannel.cpp:267/FetchAllData: OpenSky Live Online: Received 33 characters
LiveTraffic 1541978012.7 ERROR LTChannel.cpp:318/ProcessFetchedData: JSON: List of aircrafts (states) not found
LiveTraffic 1541978012.7 FATAL LTChannel.cpp:98/IncErrCnt: OpenSky Live Online: Channel invalid and disabled after too many errors

Currently, landing lights and strobe lights are always off.

In most areas, landing lights are to be turned on below FL100, let's say below 100.000ft altitude. This is true for airliners at least.

Strobe should be on when switching to Take Off.

Both Landing Lights and Strobe should be Off when switching from Rollout to Taxi.

• Design
  • Landing lights below FL100 also for GA? No
  • New Flight Model parameter needed: LIGHT_LL_ALT ? Just an altitude or a boolean switch for lights below a FL vs below a height AGL? (separate issue?)
• Implement, likely in LTAircraft::CalcFlightModel
  • Add to A/C info, i.e. new data ref livetraffic/ac/landing_lights
  • Flying phases: Check for altitude
  • Take off / Landing: On
  • Taxiing: Off
• Test flying below, above, taxiing and transition between these

Describe the bug
In stringification for debug output, like detailed position information, LT is using Unicode characters for horizontal and vertical arrows.
In a Windows PowerShell terminal this produces garbage. Also, the way NAN is stringified in Windows looks different but might be OK. Check after the other stuff is fixed.

To Reproduce
Produce detailed positional debug output into Log.txt and watch with PowerShell command Get-Content .\Log.txt -Wait -Tail 30.

Expected behavior
Should be readable

Screenshots
\ltflightdata.cpp:758/AddNewPos: DEBUG MERGED POS ( 40.648, -74.193) 850f GND_OFF {-nan(ind)°, -nan(ind)↕︎, -nan(ind)↔︎} [1543103620.0 into updated TS 1543103620.0

Technical Info:

• OS: Windows 10
• X-Plane version: 11
• LiveTraffic version: 0.8.181125

Log.txt
\ltflightdata.cpp:758/AddNewPos: DEBUG MERGED POS ( 40.648, -74.193) 850f GND_OFF {-nan(ind)°, -nan(ind)↕︎, -nan(ind)↔︎} [1543103620.0 into updated TS 1543103620.0

This is probably way too early in the development to make this suggestion, but …

X-Plane can connect to Foreflight and PilotEdge sends its traffic to ForeFlight, which shows it (if traffic is enabled in Foreflight). PE has a .ini file containing only the local network IP address of the iPad/iPhone on which ForeFlight Mobile is running.

Feature request: would LT do the same please?

Can do.

Todo list:

• ForeFlight documentation
• Configuration for
  • Sending user plane's data
  • Sending live traffic
  • port
• UI Settings for the same
• Broadcast send capability
• Thread for sending (standard 10-20s call isn't sufficient, Foreflight requires updates more often)
  • User's plane GPS
  • User's plane attitude
  • Live traffic planes
• Documentation (warning: if RealTraffic broadcasts, it always also broadcasts Foreflight data on 49002! So parallel operations is somewhat difficult)

A/C Info (as available per dataRef already) shall be displayed in a floating window.

• Design:
  • Support multiple windows (at least don't hinder extending the code to multiple windows later)
  • How to select the a/c? Based on which field (hex transponder, call sign, flight number)? --> all of them, plus registration. User enters a string a LT compares against all 4 fields.
  • Will we provide a list / a dropdown? The latter would require to implement them, probably based on available code TestWidgets.cpp by Sandy Barbour. Forked into issue #21
• Implement
• Test

Current Situation / Problem
No way of identifying Beta version.

Suggested Solution
A Beta version should be identifiable as such.
Its usage should be limited just to avoid them being sent around too far to too many people for too long.

Benefits
More restrictive handling of Beta versions during selective testing phases.

Current Situation / Problem
Currently, LiveTraffic looks into the hard-coded path plugins/XSquawkBox/Resources/CSL to find CSL packages. If XSB is installed elsewhere that will fail.
Checking X-IvAp paths is not even implemented yet.

Suggested Solution
Walk all plugins, search for "Resources/CSL" and just take that.
Make multiple calls to XPMPLoadCSLPackage to load additional CSL directories if there is more than one.

Benefits
Independence if individual user's setup.

** Still to do **

• Settings UI tab with 5 or so edit fields for the paths, and checkboxes for enable/disable
• ...and maybe a 'Load' button to load a package on demand
• LTMainInit: Ability to startup and show the settings UI even if CSL init failed

Describe the bug
Aircrafts change heading more or less smoothly when the flight path's track changes, but they don't roll into curves, they always stay wings level.

To Reproduce
Look at aircrafts flying curves, e.g. starting from KLGA 13 they'll turn right pretty soon.

Expected behavior
Shall roll into the curve while changing heading.

Technical Info:

• OS: Mac
• X-Plane version: 10 and 11
• LiveTraffic version: pre-alpha

Current Situation / Problem
Timeout for network requests not set specifically, using CURL standards, which apparently is 0 (eternally).

Suggested Solution
Add option CURLOPT_TIMEOUT in LTOnlineChannel::InitCurl
We should probably make that a parameter, though

Benefits
More robust network handling.

On a clean installation of XP 11.26, with LiveTraffic 0.81 and Bluebell CSLs + required xsquawkbox files, I tested this morning at my "home" airport Centennial (KAPA), comparing to the traffic that appears on Flightaware. LiveTraffic shows the correct number of nearby planes, the correct registration number and their approximate locations, but NOT the correct type. KAPA is essentially a GA airport but LiveTraffic only displays Airbus and Boeing airliners.
For example, the screenshot attached shows an airliner with registration N5306U, which on Flightaware is identified as a C172. The A/C information window when this registration number is entered has a blank field for the a/c type (sorry forgot to take a screen shot of the A/C info window).

Log.txt

Describe the bug
The 2 config callback functions MPIntPrefsFunc and MPFloatPrefsFunc currently only return one config value: debug/model_matching. This one does work and is linked to LiveTraffic's config value livetraffic/dbg/model_matching.

But according to documentation in the comments of XPMPMultiplay.h two more config values are to be returned:
* section key type default description
* planes full_distance float 3.0
* planes max_full_count int 50

To Reproduce
Suggest debugging / debug-logging which calls are really being made.

Expected behavior

• Return a reply to all meaningful config values.
• link the above values to new LT config values.
  • For max_full_count add livetraffic/cfg/max_full_num_ac
  • For full_distance add livetraffic/cfg/full_distance

Technical Info:

• OS: all
• X-Plane version: all
• LiveTraffic version: all

Current Situation
Aircraft seem to move back and forth, turn left/right.
Especially when different channels are combined.
Also see bug #11 .

Suggested Solution
We might need a logic to just remove an ill-looking pos from dequePos, like:

• Heading turns more than 90° but with next pos we would fly straight (<30°)
• VSI would switch between down/up, but with next pos we would keep or level

Alternative
Don't allow mixing channels for any one aircraft...but how would we decide that we need to switch channels when coverage of current channel fades and another one seems better? How would we define 'better'?

Benefit
More realistic looking landings.

Additional context
Look at this example: there is a position, which goes backward, and then we suddenly accelerate to 450+ knots:

22:53.054 LiveTraffic DEBUG LTFlightData.cpp:667/AddNewPos: DEBUG POS DATA: a/c A7C849 SimTime: 1534968806.1 - 2018-08-22 20:13:26
a/c A7C849 ppos: ( 40.790, -73.867) 54f GND_OFF {211°, 7↕︎, 0↔︎} [1534968806.1] Y: -0f Phase: 61 Final
posList:
( 40.790, -73.867) 91f GND_OFF {211°, 2↕︎, 0↔︎} [1534968795.0] <211°, 0m @ 0kt, -202ft/m>
( 40.790, -73.867) -0f GND_ON {212°, 7↕︎, 0↔︎} [1534968822.0]
posDeque:
( 40.788, -73.869) -0f GND_ON {211°, 2↕︎, 0↔︎} [1534968799.7] < 31°, 323m @ 28kt, -0ft/m>
( 40.790, -73.867) -0f GND_ON {212°, 0↕︎, 0↔︎} [1534968822.0] <212°, 1846m @ 461kt, 51ft/m>
( 40.776, -73.878) 7f GND_ON {206°, 0↕︎, 0↔︎} [1534968829.8] <204°, 340m @ 19kt, 0ft/m>
( 40.773, -73.880) 7f GND_ON {204°, 0↕︎, 0↔︎} [1534968865.4]

Current Situation / Problem
In LoopCBAircraftMaintenance we catch top-level exceptions. First attempt is to re-init the plugin. If that fails with exception, however, currently we re-throw the exception, means: we die and take the sim with us.

Suggested Solution

• Try disabling myself, i.e. the plugin LiveTraffic. XPLMDisablePlugin should do so.
• Need to test if a plugin can disable itself.

Benefits
A bit more resilience.
This is the only place left, in which the plugin would die from exceptions.

Current Situation / Problem
livetraffic/dbg/log_raw_fd is only switcheable via DataRef

Suggested Solution
In Beta versions only, provide an advanced settings option

Benefits
Beta testers could more easily provide network logs, e.g. to analyse the "rocket" issue

Current Situation / Problem
OpenSky delivers no flight route information in the data LT queries.

Suggested Solution
Add a separate query to get that information:
https://opensky-network.org/api/routes?callsign=DLH1ML
delivers something like

{
    "callsign":"DLH1ML",
    "route":["EDDM","LIMC"],
    "updateTime":1543443973000,
    "operatorIata":"LH",
    "flightNumber":1864
}

Note that these routes are manually added by supportes of OpenSky Network and are not 100% reliable and complete.

To be decided if technically this is yet another OpenSky channel or be integrated with the existing master data channel as a second request.

Benefits
Flight and Route information.

Describe the bug
LiveTraffic apparently can't handle some CSL packages, which X-IvAp is said to handle without warnings.
These warnings don't render LiveTraffic unusable, so issue has lower prio.

To Reproduce
One package now available to me is "B732_OBJ8_CSL". Starting with this package installed should produce warnings.

Expected behavior
No warnings. Package should be recognized.

Complication
X-IvAp is no longer public code. xplanemp is and reads those files, but there are many forks, I'm not on the latest one as I don't understand their changes any longer.

Screenshots
If applicable, add screenshots to help explain your problem.

Technical Info:

• OS: [Mac/Win/Linux]
• X-Plane version:
• LiveTraffic version:

Log.txt
Extract showing some successful and then some unsuccesful loads.

XSB: Loading package: G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/SF260/xsb_aircraft.txt
XSB: Loading package: G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/Sherpa_ver8_CSL/xsb_aircraft.txt
XSB: Loading package: G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/StinsonAT19_V8_CSL/xsb_aircraft.txt
XSB WARNING: Parse Error in file G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/AT-11_OBJ8_CSL/xsb_aircraft.txt line 10.
              OBJ8 SOLID YES __AT11/MAIN.obj 87M_TEX.png.
XSB WARNING: OBJ8_AIRCARFT command takes 1 argument.
XSB WARNING: Parse Error in file G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/AT-11_OBJ8_CSL/xsb_aircraft.txt line 16.
              OBJ8 SOLID YES __AT11/MAIN.obj MSJ_TEX.png.
XSB WARNING: OBJ8_AIRCARFT command takes 1 argument.
XSB WARNING: Parse Error in file G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/AT-11_OBJ8_CSL/xsb_aircraft.txt line 22.
              OBJ8 SOLID YES __AT11/MAIN.obj NAV_TEX.png.

Current Situation / Problem
Show/Hide aircrafts and opening A/C Info Wnds is only possible via menu. Cumbersome.

Suggested Solution

• Make both items a XP command, so that standard XP key/button assignment options apply.
• Check for other menu items, too
• Close all a/c info windows (new menu item)
• Show/Hide all a/c info windows (new menu item)
• A/c labels on/off
• In XP11 also make use of XPLMAppendMenuItemWithCommand so that key bindings become visible

Benefits
Easier access to these options.

Current Situation / Problem (follow up to #9)
Aircraft selection for a/c info window or in settings is currently by typing only: transponder, registration, call sign, flight number...
As there is no list of aircrafts to choose from the user has to know somehow that the aircraft is there. Currently only possible by reading the labels of the displayed aircraft, which only works for aircrafts closeby.

Suggested Alternatives

• List window, which just lists all aircrafts with some values. Real benefit with
  • customisable columns with live data
  • filter options to limit displayed a/c (like distance to viewer, a/c type...)
  • action from there like "Open Info Wnd" or "Copy trsp to Clipboard"
  • will finally require to adapt a ListBox into TFWidgets.cpp, see TestWidgets.cpp by Sandy Barbour
• Click on a/c
  • Challenge: Don't know if it is possible to map aircrafts 3D-coordinates to the 2D coordinates a mouse click has. Meaning: Unclear how I would identify the closest aircraft.
  • (Above TestWidgets.cpp has a solution to temporarily receive mouse clicks in the entire screen...they use it to close a drop down box)

Benefits
Enables the use to see and select from all aircrafts currently being handled by LT.

ADS-B does not provide a separate web service for master data, at least not officially. But the standard web service to query flight data also provides all necessary master data for an a/c.
Is potentially required for implementing the stream channel (see #5).

• Add a separate channel for master data by ADS-B Exchange
• Check out how to combine/distribute work with the other existing master data channel(s). If one channel can't serve an aircraft then the entry should stay in the work list to be served by another activated channel.
• Test combined with Flightradar24 (which doesn't provide master data in the flight data web service), in combination with FR24 Master Data and stand-alone.

Describe the bug
check online live data landings (they still look funny at times...)
Sometimes we also see back-and-forth movement around touch down
(could technically be because of inserted touch-down pos with ts < next pos but physical position beyond)
'to'-pos after touch-down might be on taxi way (off runway) already with heading turned away
maybe that position is even reported slightly airborne (esp. with Flightradar24)

To Reproduce
Watch online live data landings.
It might be an issue with mixing several channels.
Also, Flightradar24 data often seems to 'hover' over the runway and touch down very late.

Expected behavior
Shall not look funny:

• COnstant negative VSI
• touch down more or less at beginning of runway
  Maybe we need to be more radical in forcing to follow negative VSI to grnd...
  Also see enhancement #12.

Technical Info:

• OS: Mac
• X-Plane version: 10.x
• LiveTraffic version: pre-alpha

Log.txt

Describe the bug
If LT fails to init (and returns 0 on XPluginStart), X-Plane 11 crashes after initialization, attributing the crash to another plugin, in my case Landing Speed.

If, however, we take LT out of the plugin directory, everything works fine. So it has to do with the failed start of LT, though it is yet unclear if LT does something wrong or XP11 can't handled failed plugin startup properly.

To Reproduce

1. Force a failure in LT startup, like e.g. missing file (rename lights.png)
2. Start XP, click on "Resume last flight"

Expected behavior
No crash.

Technical Info:

• OS: Mac 10.14
• X-Plane version: 11.26r2
• LiveTraffic version: 0.81.1812 5

Log.txt
Log.txt

Describe the bug
A clear and concise description of what the bug is: What's wrong?
Some ac slide sideways across a runway to line up or while landing/taxiing. Others as we have discussed, have been rocketing up and down (yoyo effect)

To Reproduce
Just start xplane on a particular busy runway

1. Location: LSZH RW 28
2. Tuesday, Dec 4th, approx 4pm (1600)
3. Usually an a319 or a320
4. A Log.txt file with log level (Settings/Advanced) set to 'Debug' INCLUDED
5. I will try to upload a video (4min) oops! NOT POSSIBLE HERE..will try YouTube or?? Ask me if you'd like me to package and send it to you in a zip 👍

Expected behavior
explained already

Screenshots
INCLUDED ;)

Technical Info:

• OS: Windows 10 64 Pro
• X-Plane version: 11:30b6
• LiveTraffic version: 0.81.20181202

In photos 1,2 and 3 you'll see the sliding sequence:

Log.txt

Log.txt
Attach your Log.txt file, if reproducible then please reproduce with log level (Settings/Advanced) set to 'Debug' first.

Current Situation / Problem
LiveTraffic does not automatically start showing aircrafts, but requires to to be activated via menu command.

Suggested Solution

• DataRefs.cpp: Provide a config option to allow auto-start, which is to be written to the config file
• Provide a check box in the Basics tab of the Settings UI.
• Read that option during plugin init. At the last possible chance enable aircraft showing.

Alternatives
Always auto-start...some might not like it.
Never auto-start...others might not like it.

Benefits
Those, who want auto-start have their live aircrafts right away.

Describe the bug
In Log.txt lines of severity error and above the source code file and line number is printed. In Windows it includes the full path, which includes personal information of the person who built the package, which is unacceptable.

To Reproduce
Produce debug output to Log.txt, first lines appear already after Startup if log level is Debug.

Expected behavior
Source file name, but no path.
Check out https://docs.microsoft.com/en-us/cpp/build/reference/fc-full-path-of-source-code-file-in-diagnostics?view=vs-2017

Technical Info:

• OS: Win 10
• X-Plane version: 11
• LiveTraffic version: 0.8.181125

Log.txt
Certainly not...don't want to publish my personal data...

The a/c label is compiled in LTFlightData::ComposeLabel and is currently fixed to ICAO hex transponder code + ICAO a/c type + call sign.

The label attached to an a/c shall be configurable based on a number of attributes both from master data and live data, like in addition to the default above: flight number, altitude, height AGL, flight phase, speed...

Note, however, that xplanemp sets a size limit on the label (35 chars?). As we had changed xplanemp already we could certainly lift that limit and maybe even add several lines... (this might be moved to another issue)

• Settings UI
  • list all possible fields, also include live data fields
  • simple solution first: just select by check box, order of fields is then pre-defined
• Compute Label
  • LTFlightData::ComposeLabel()
  • Include title of a/c info window (which is label) in 1s update of window

Current Situation / Problem
The first 50 a/c that become available are shown. In busy airports like KLGA we hit the 50 limit easily...how do we ensure that we draw the a/cs closest to us?
If the limit is hit and a new aircraft becomes available right in front of the viewer we wouldn't draw it.

Suggested Solution
We should kick out far away aircrafts in favour of newly appearing nearer aircrafts:
When a new aircraft becomes available (LTFlightData::CreateAircraft) but would not be displayed due to the max-a/c-limit check if the farthest-away a/c is farther away than the new one. If so remove the farthest-away a/c and create the new one.

Alternatives
n/a

Benefits
Most relevant aircrafts displayed.

Additional context
n/a

Describe the bug
In a clean install with no XSquawkBox installed previously or alongside, the package is missing essential files, which are also not included in the Bluebell package:

• related.txt, the fact that I included an amended version was meant as a curtesy to copy over an existing install, not as an essential delivery
• Doc8643.txt
• Lights.png

Apparently, in my installation survived an old XSquawkBox install. Unfortunately, XSquawkBox comes under a pretty restrictive EULA. It is not freeware. The xplanemp library used to read CSL models and display them is freeware, but not the final xsb package. And only the xsb package includes the 3 files mentioned above. So strictly speaking they are under EULA, too.

To Reproduce
Clean install, i.e. remove all plugins and follow instructions.
It will not find essential files and bail out during plugin init.

Expected behavior
Package and instructions match and enable a clean install.

Technical Info:

• OS: any
• X-Plane version: any
• LiveTraffic version: aby

Possible Solutions
First of all confirm, which file are really really necessary.

1. EULA allows copying content with written permission. So try obtaining a written permission to copy, modify, and distribute those 3 files.
2. In the end, we probably only talk about the related.txt. Because:
   • lights.png: In the XSquawkBox FAQs it reads that the old lights are phased out and should no longer be used with modern OBJ8 packages (which the Bluebell one is). So very likely the lights.png is no longer necessary. The call to XPMPMultiplayerInitLegacyData requires a path to this file, but likely it's content doesn't matter. Will try with the LiveTraffic logo ;) ... and then probably just take out all that code and, thus, remove the necessity.
   • Doc8643.txt: See issue #24: I'd like to use another file anyway as it is more up-to-date. So this issue becomes more important now. Will include it in the next milestone.
   • And then...quite honestly...related.txt needs an overhaul anyway and might need adaptation re the Bluebell package, now that I understood it came with XSB. So I probably create a new one anyway.

ADS-B provides stream data, i.e. continuous updates, see section "Live Data via TCP Connection" of ADS-B Data page.

• Design first: Does it make sense to create new FD objects from the stream? The data provided can be quite scarce, seems like only changed fields are transferred. Maybe we need to combine with the classic request/reply stream? In a form requesting one specific aircraft as a starting point? Maybe it is sufficient to just query a/c master data?

• Add the channel to the configuration options

• Provide an option to switch between the 5 different types (they vary in update interval, technically in the port to connect to)

• Connect to the data, select based on distance (we need to do that ourselves as the stream just streams all flight data available worldwide), and feed the updates into mapFD.

Describe the bug
XSquawkBox (XSB) wants to acquire multiplayer planes during initialization by a call to XPMPMultiplayerEnable. In a standard install LiveTraffic (LT) is initialized before XSB, because it is first in the alphabet. Hence, XSB can't acquire the planes as LT has them already.

Even with tricks like disabling/re-enabling the plugins in the plugin admin XSB will never try to re-acquire the multiplayer plugins. So there is no way the access to the multiplayer planes and hence the successful working of the plugins could be handed back and forth between the plugins. This is bad design on the XSB side...let's make it better on the LT side.

So currently recommendation is to move plugins to a plugins_disabled folder and have only one of them active in the plugins folder. That's cumbersome.

To Reproduce
Install both XSquawkBox and LiveTraffic (which is, at least temporarily (see #38), current installation procedure). Fire up X-Plane and watch the Log.txt

WARNING: XSquawkBox did not acquire multiplayer planes!!

in Log.txt.

Expected behavior
Some better handling of keeping both plugins in parallel. We can't change XSB, but we should enable to startup X-Plane with XSB working properly and allow a handover to LiveTraffic by disabling XSB in the plugin admin.

Technical Info:

• OS: any
• X-Plane version: any
• LiveTraffic version: 0.8.181130

Todo

• Delay the call to XPMPMultiplayerEnable until LTMainShowAircraft.
• Make sure that if LT can't acquire multiplayer planes (because XSB [or X-IvAp for that matter] is still running) this shows up as an error to the user.
• Allow to move LT to any plugin folder like ZZLiveTraffic to ensure it starts after XSB. This will mean to change the way we find our resources like the FileModel.prf (and the files affected by #38).

Describe the bug
After insertion of an artificial position (touch-down, roll-out) due to no more available live data, newly received live data with timestamp before the artificial touch-down pos is ignored because the touch-down/roll-out point is, by that time, the current to-position. And we never insert new live data before current to-pos.

To Reproduce
Difficult...need an approaching aircraft with temporarily no more live data, and then after inserting the artificial pos live data needs to come in again.
Reducing the buffering time dramatically might help.
Or delaying the new live data with the help of the debugger.

Expected behavior
New pos should be inserted if current to-pos is 'only' an artificial position (and is after current simulated time). The artificial point needs to be removed then cause the basis for its calculation has changed.

Technical Info:

• OS: [Mac/Win/Linux]
• X-Plane version:
• LiveTraffic version: 0.8.181127

Log.txt
(It actually can be seen in Log files: Insertion of artificial touch-down as well as ignoring new live pos is both logged when logging of detailed position data is on.)

Situation
Channels have an error count. A channel is inactivated if the error count exceeds a value (5) to prevent dealing with inop, faulty data.

As there is no reset to this counter it will inevitably happen that channels got deactivated after hours of flight time as there always are minor flaws in the data.

Suggestion
Reset the counter regularly.
Too make it not too complex: Decrement the counter by one after every error-free reception.

_{Sent with GitHawk}

Current Situation / Problem
Track and Heading is always the same.

Suggested Solution
Consider wind: Especially in cross-wind situations heading should be into the wind to keep track.
Could be a fairly simple logic like 'Add some degrees of heading (sounds like flight model parameter) per knot cross wind component'

Benefits
Cross wind situations look more realistic.

Describe the bug
A clear and concise description of what the bug is: What's wrong?
After taking off from LEBL and circling around to my heading, as I passed over the airport I could see planes lined up for landing. They looked spaced correctly, however, one plane came from behind and overtook the others at a high rate of speed. I was doing 250-270kn, not much faster than the plane in question.
To Reproduce
Steps to reproduce the behavior:
Take off from 07r at LEBL at approx 1500hr...weather was clear but windy..circle around at 3500ftagl over airport heading 250

I attached my log (debug was set) and a photo, while it was possible to read in flight, unfortunately, the photo is hard to distinguish the details. (Next time I will write it down!)

Technical Info:

• OS: Windows 10 64 pro
• X-Plane version: 11.26
• LiveTraffic version: 0.81.20181202
  Log.txt

Finish up moving constants from Constants.h to configurable DataRefs.

• Double-check that all relevant constants are now converted to DataRef members.
• In all code replace the constants with the DataRef members and remove the constants

...which is a replacement for DataRef Editor, see X-Plane Downloads.

It is supposed to work exactly the same way as DRE, also informing the plugin about my custom dataRefs works the same way. I just assume that the plugin signature is different, so we have to add an outer loop to LoopCBInformDRE to support bot DRE and DRT.

• Add signature for DRT
• Install DRT and test for both XP10 and XP11
• Test with both plugins installed and with either plugin installed

Describe the bug
Log entries and error messages from the multiplayer library still say 'xsb'/'xsquawkbox'.

To Reproduce
Just fire up X-Plane on a Windows platform

Expected behavior
Should read "LT" / "LiveTraffix"

Technical Info:

• OS: Win
• X-Plane version: Any
• LiveTraffic version: 0.81.20181202

Log.txt

XSB: Loading package: G:\X-Plane 11 (1)\Resources\plugins\LiveTraffic\Resources\CSL/BB_Repaints/xsb_aircraft.txt
LiveTraffic 1543869126.9 DEBUG src\LTMain.cpp:321/LTMainInit: LTMainInit initialized

Reason
Forgot to pull and recompile xplanemp on Windows.

Current Situation / Problem
Weather is configured in X-Plane, which might be configured to use current real weather or a given weather file, but is not synched with historic data if such is used in LiveTraffic.
If especially wind direction doesn't match then landings/take offs could be simulated from the 'wrong' runway the user wouldn't use for his/her arrival/departure.

Suggested Solution
Read and use historic weather, maybe from sites like
http://www.ogimet.com/metars.phtml.en
http://www.ogimet.com/display_metars2.php?lang=en&lugar=EDDL&tipo=SA&ord=REV&nil=NO&fmt=txt&ano=2018&mes=04&day=27&hora=10&anof=2018&mesf=04&dayf=27&horaf=11&minf=0&send=send
when running with historic data.

Alternatives
Manual workaround:

• Document how to fetch historic weather info and set it manually in X-Plane
• Create custom weather files.

Benefits
Correct weather for historic flights, especially meaningful for correct active departure/arrival runway.

Current Situation
Light pattern is constant assigned with EADS type. In LTAircraft::CalcFlightModelwe set the light pattern in preparation for the GetPlaneSurfaces callback. There:

// FIXME: Identify Airbus/GA for correct patterns surfaces.lights.flashPattern = xpmp_Lights_Pattern_EADS;

Suggested Solution
Available patterns as per XPMPMultiplayer.h:
enum {
xpmp_Lights_Pattern_Default = 0, // Jets: one strobe flash, short beacon (-*---*---*---)
xpmp_Lights_Pattern_EADS = 1, // Airbus+EADS: strobe flashes twice (-*-*-----*-*--), short beacon
xpmp_Lights_Pattern_GA = 2 // GA: one strobe flash, long beacon (-*--------*---)
};

• Tell Boing from Airbus. A lookup in Doc8643::manufacturer should do.
• Tell GA from big ones...that's more difficult. We could make this a flight model setting: LIGHT_PATTERN
• As we are at it: Store a reference to the Doc8643 object in LTAircraft.

Benefit
More realistic lights.

Current Situation / Problem
No Time info

Suggested Solution
Show sim time in a/c info wnd

Benefits
Eases assessing information, also for bug reports with screenshots.
Allows assessing age of information

Current Situation / Problem
There is no version numbering yet. This will make dealing with user reports difficult.

Suggested Solution

• Introduce an alphanumerical version number
• display the version number in the Settings UI
• include the version number in a log message during initialization

Benefits
User knows / can look up version and attach it to reports.
Version is identifiable from Log.txt.
Git tags can be aligned with product version.

Describe the bug
A/C Info Window does not include the aircraft's squawk code.

To Reproduce
Open such a window and see it's missing...

Expected behavior
Should display a/c's squawk code.
Is available in FDDynamicData::radar.