265
edits
ATC-pie FAQ: Difference between revisions
v1.3.1
Mickybadia (talk | contribs) (v1.3.0 released) |
Mickybadia (talk | contribs) (v1.3.1) |
||
| Line 9: | Line 9: | ||
You only see an aircraft on your screen if your radar picks up a transponder signal from it. The two following cases will therefore prevent you from seeing a connected aircraft: | You only see an aircraft on your screen if your radar picks up a transponder signal from it. The two following cases will therefore prevent you from seeing a connected aircraft: | ||
* The aircraft is out of radar range, i.e. under the radar floor (minimum signal pick-up height) or too far out. Open the ''General settings'' dialog, check the NM range setting and set the floor to "SFC" to pick up all signals. | * The aircraft is out of radar range, i.e. under the radar floor (minimum signal pick-up height) or too far out. Open the ''General settings'' dialog, check the NM range setting and set the floor to "SFC" to pick up all signals down to the ground. | ||
* Its onboard transponder is turned off; see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Alternatively, you can switch on the primary radar system if you want to see all aircraft's positions, or activate the "radar cheat mode" if you want to go the radical way ([https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3]). | * Its onboard transponder is turned off; see [https://www.youtube.com/watch?v=kpPzRiwzx9Q&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb&index=1 ATC-pie video tutorial 1]. You should tell the pilot to switch it on. Alternatively, you can switch on the primary radar system if you want to see all aircraft's positions, or activate the "radar cheat mode" if you want to go the radical way ([https://www.youtube.com/watch?v=lSyH88HR-4w&index=3&list=PL1EQKKHhDVJvvWpcX_BqeOIsmeW2A_8Yb tutorial 3]). | ||
NB: If the aircraft model does not | NB: If the aircraft model does not implement a transponder, ATC-pie will simulate one according to the fallback mode you have selected in the FlightGear system configuration tab. If that setting is "off" and no cheat or primary radar is activated, a non-equipped aircraft will be invisible as well. Like in real life. | ||
=== Connected pilots do not receive my text messages. === | === Connected pilots do not receive my text messages. === | ||
This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol". It will come at the expense of network throughput, but everybody should be able to read you. | This happens with pre-2017.2 clients if you are using the latest protocol to encode properties. Tick the FGMS system option to "use the legacy protocol" for property encoding. It will come at the expense of network throughput, but everybody should be able to read you. Tell those pilots to upgrade their client as well. | ||
=== FGCom radio is not working. === | === FGCom radio is not working. === | ||
| Line 117: | Line 117: | ||
What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. If you like to do so and want a way to visualise and distinguish them, the best thing to do is to stack your inbound strips on racks named after your STARs. Racks are indeed not only a way of categorising traffic, but above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself, like one could use runway-specific racks at large airports to keep track of separate landing sequences. You can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown. | What people seem to be after when asking this question is a way to organise inbound traffic '''on arrival''', using STARs to manage multiple approach paths. If you like to do so and want a way to visualise and distinguish them, the best thing to do is to stack your inbound strips on racks named after your STARs. Racks are indeed not only a way of categorising traffic, but above all meant for efficient traffic sequencing. Every rack represents its own sequence of ordered aircraft, which is perfectly suited to control separate approach paths in parallel. With this technique, placing a strip on a STAR-named rack basically serves as the "assignment" itself, like one could use runway-specific racks at large airports to keep track of separate landing sequences. You can set a colour to each rack for quick identification on the scope. Besides, turning on the approach spacing hints will help you optimise the separation times in the sequence all the way to touchdown. | ||
If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are copied onto strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar | If you otherwise meant to '''plan routes''' before they are flown, you are looking for something you should not be doing. Routes are lists of waypoints and instructions to follow between the two end airfields. Normally pulled straight from properly filed flight plans, routes are copied onto strips prior to departure, then modified as the flights progress and passed along with handovers. Standard departure and arrival procedures (SIDs and STARs) can be referred to in those routes, but only by their entry or exit navpoints. They should not contain full procedure names like FUBAR1A since those depend on the active runways and might change any time before flying the corresponding leg. For example, routes ending with a STAR should end with "FUBAR STAR", which means that waypoint FUBAR is an entry point from which a published STAR must be followed. The keyword "STAR" is in fact a mere specification for the last route leg. Similarly, routes of the form "SID DUMMY ..." specify their first leg as a standard departure to the first waypoint DUMMY. "SID" and "STAR" keywords are recognised by ATC-pie and accounted for in the second line of the radar tag when appropriate (see feature note on routes). | ||
One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" in your strip comments. It will pop up with the strip mouse-over tooltip, and create a custom <code>$sid</code> alias that will automatically be expanded in your sent messages when that strip is selected. | One meaningful wish regarding this question is for easy '''reference in text chat''' messages. Firstly, using racks in the way suggested above, you can use the <code>$rack</code> alias which is substituted by the name of the rack on which the current strip selection is stacked. Otherwise, if the selected strip's route is found to contain "SID"/"STAR" keywords placed in the first/last route leg specifications, text aliases <code>$wpsid</code> and <code>$wpstar</code> will respectively expand to the first/last en-route waypoints of that route. For example, assuming route "SID DUMMY more route spec FUBAR STAR" in the selection, <code>$wpsid</code> will be replaced with "DUMMY" and <code>$wpstar</code> with "FUBAR". Now if you specifically want to assign a full procedure name like FUBAR1A to a contact and refer to it in a generic text chat message, include a line "sid=FUBAR1A" in your strip comments. It will pop up with the strip mouse-over tooltip, and create a custom <code>$sid</code> alias that will automatically be expanded in your sent messages when that strip is selected. | ||