265
edits
ATC-pie FAQ: Difference between revisions
version update
Mickybadia (talk | contribs) (Organised in sections; added questions (came with r10)) |
Mickybadia (talk | contribs) (version update) |
||
| Line 21: | Line 21: | ||
=== FGCom radio is not working. What is going on? === | === FGCom radio is not working. What is going on? === | ||
If you are using external clients, i.e. FGCom instances running outside of ATC-pie, you must troubleshoot them there. This section assumes you are trying with '''internal''' radio boxes. If you do not understand this distinction, the latter case is yours and you should read on. | |||
First, try an echo test: | |||
# Bad FGCom setting | * check that your sound is on, your volume loud and your microphone working (e.g. system sound monitor picking up a signal); | ||
#: Verify the path to your FGCom executable in the system settings | * close all open ATC-pie sessions and open a single instance; | ||
* start the echo test from the ''System'' menu. | |||
If you hear yourself when you speak, you may skip directly to item 3 below. Otherwise start with 1. | |||
# Bad FGCom version/path setting | |||
#: Verify the path to your FGCom executable in the system settings. It should point to the right executable file under <code>resources/fgcom</code> and suit your operating system (see <code>Notice</code> file there). All three Linux, Mac and Windows versions are initially packaged with the program. | |||
# FGCom server down | # FGCom server down | ||
#: This can happen, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code>. | #: This can happen, unfortunately even for up to a few days. Check for responses from the server, e.g. with <code>ping fgcom.flightgear.org</code>. | ||
| Line 31: | Line 36: | ||
#: If the server is up (responding to ping), check for errors in the logged FGCom output files in the <code>output</code> directory. | #: If the server is up (responding to ping), check for errors in the logged FGCom output files in the <code>output</code> directory. | ||
# Port mess-up on your side | # Port mess-up on your side | ||
#: If you are running multiple instances of ATC-pie, make sure you have no more than one radio box on every port. In any case, | #: If you are running multiple instances of ATC-pie, make sure you have no more than one radio box on every port. To check what port a radio box is using, see its "on/off" button tooltip. You can change your FGCom settings from the system settings dialog. In any case, you should only choose available ports, not reserved by your operating system. Typically, ports from 16661 and counting up work fine. | ||
=== Tower view is not starting. The menu option is ticked but nothing happens. === | === Tower view is not starting. The menu option is ticked but nothing happens. === | ||
| Line 46: | Line 51: | ||
If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either: | If you know what IPv6 is and that your network configuration will allow it, try using IPv6 addresses. Otherwise, the solution is either: | ||
* for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local address; | * for the teacher to configure his router to forward TCP packets from his router's IP and chosen service port to his local host address; | ||
* or to create a virtual network, using a third-party VPN service. | * or to create a virtual network, using a third-party VPN service. | ||
| Line 76: | Line 81: | ||
If you otherwise meant to '''plan routes''' before they are flown, you are probably 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 contact info box when appropriate (see feature note on routes). | If you otherwise meant to '''plan routes''' before they are flown, you are probably 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 contact info box when appropriate (see feature note on routes). | ||
One last meaningful wish regarding this question is for easy '''reference | One last 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. | ||
=== | === Can I access ILS frequencies? === | ||
Not with built-in features. But if you want a quick and integrated reading of ILS frequencies, you can look them up once and write them in the local notepad which will be saved when you close ATC-pie. Using the following format one runway per line will even create local text aliases for convenient shortcuts in chat messages: <code>ils05=111.11 MHz</code>. See [[ATC-pie_user_guide#Text chat|custom text aliases]] for more. | |||
=== How do I customise the GUI and colours? === | === How do I customise the GUI and colours? === | ||