Settings - Debug

The "Debug" tab of the Settings dialog

Are you sure you want to be here?

This is advanced stuff for people trying to help uncover issue or for CSL model builders trying to test their models.

Settings - Debug

Setting	Default	Description
Filter for...hex code	Empty	Filter all flight data for one specific aircraft. Good for code debugging purposes. The same search options as in an A/C Info Window apply: Transponder Hex Code, Registration, Call Sign, Flight Number, SquawkCode, Index.
Log.txt: Set Log Level = "Debug"	Disabled	Has the same effect as setting Log Level = "Debug" in the Advanced Settings. When deactivating here, Log Level is reset to Warning. Provided as a courtesy, in case users search here when asked to set Log Level to Debug.
Log.txt: Log a/c positions	Disabled	If Logging Level is Debug and an aircraft is selected, enabling this setting produces detailed output into Log.txt with positional information on that selected aircraft and the queue of tracking data. This output allows a developer to understand why an aircraft moved the way it did. An aircraft is selected if it is filtered (see previous option) or if it is selected in an A/C Info Window.
Log.txt: Log model matching	Disabled	This places some lines of debugging information into Log.txt about how the multiplayer library picks a CSL model. Might be temporarily interesting if you want to figure out why some planes aren't rendered as expected.
LTRawFD.log: Log raw network flight data	Disabled	With this option a separate output file named LTRawFD.log is written into X-Plane's system folder including each network request and the corresponding response as raw uninterpreted data. This would allow analysing anomalies like "rocket planes" or hovering planes if the logging period covers such behavior. Note 1: Unlike Log.txt, LTRawFD.log is never overwritten but appended to. You'll need to clean it up yourself from time to time if using this option. Note 2: This option is not written to the config file but returns to disabled with restart.

Forced Model Matching

These are options for CSL model builders to test their models with LiveTraffic. Each of the 3 fields overrides the otherwise variable strings that LiveTraffic hands over to the multiplayer library to feed into the model matching algorithms.

Or in other words: You can force LiveTraffic to pick a specific model regardless of the actual aircraft as per tracking data. You can read about the details of the matching process here.

These settings affect which model is picked for all newly created aircraft. So you'll have to wait for the next new aircraft to be created to see an effect.

Changes to the settings are announced in the message area. If you fill all three fields for an exact model/livery match make sure to also tab out of the last field to make LiveTraffic accept the value.

There are no validations on data input. This is meant for debugging purposes: You can test whatever you like.

Only filled values are overwritten; clear values will be filled with real information as per received tracking data. To return to standard processing clear all three values.

These settings are not written into the config file, hence latest on startup LiveTraffic is back to standard processing, i.e. without forced values.

You definitely want to have Log model matching enabled and watch Log.txt live while testing (see Tips on Testing for how to open a terminal window and keep watching).

Field	Intended content
ICAO a/c type	The ICAO aircraft type as per ICAO Doc8643. Matches the ICAO line of xsb_aircrafts.txt.
ICAO operator/airline	The operator, usually the airline, as an ICAO airline code. Matches against the AIRLINE line of xsb_aircrafts.txt
livery/registration	A text specifically identifying an individual livery. LiveTraffic fills the registration (tail number). So it is theoretically possible to define up to one CSL model per airframe for most realism. Matches against the LIVERY line of xsb_aircrafts.txt.