ATC-pie user guide: Difference between revisions

v1.7.1
(v1.7.0)
(v1.7.1)
Line 49: Line 49:
=== Tower view window ===
=== Tower view window ===
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
[[File:ATC-pie-screenshot-towerViewing.png|thumbnail|Tower viewing, following a departing aircraft]]
This feature allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any, otherwise defaults to somewhere over the airport to allow towering of all available airports. It is disabled in CTR mode. Additionally, more views can be hooked up to your scene.
This feature allows you to overlook your airport and the connected or simulated traffic, like a controller from a tower viewpoint. It allows to choose from the tower positions specified in the source data if any (X-plane seems only to allow for one, but feel free to declare more for ATC-pie), otherwise defaults to somewhere over the airport to allow towering everywhere. It is disabled in CTR mode.
There are two ways of activating a tower view. You may let ATC-pie start its own suitably configured FlightGear process, or have it connect to an external viewer, manually set up and accepting connections.
There are two ways of activating a tower view. You may let ATC-pie start its own suitably configured FlightGear process, or have it connect to an external viewer, manually set up to listen for traffic and accept telnet connections.


'''Running internally''' only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].
'''Running internally''' only requires FlightGear installed on your computer. A basic installation is enough, but you will need the [[scenery]] for your airport if you want anything exciting to see (and not sea!). Also, aircraft will only be drawn properly if the appropriate [[Aircraft|models]] are available. In FlightGear sessions, the models required are those flown by the pilots. For all other session types, models are chosen according to the ICAO type designators of the aircraft and the specifications in <code>icao2fgfs</code>. Read <code>CONFIG/acft/Notice</code> to understand how ATC-pie chooses models and liveries for its viewers. Aircraft and scenery locations can be filled in the ''System'' settings dialog if they are not in your [[$FG_ROOT|FlightGear root directory]].
Line 59: Line 59:


=== Additional scene views ===
=== Additional scene views ===
You can connect '''additional viewers''' to your session, for example placed around your airport for exciting camera footage of challenging landings. You will not be able to control those viewers from ATC-pie like the tower viewer, but you will be able to activate/stop the connection from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>), read at start-up and on explicit reload (''System'' menu).
You can hook up '''additional viewers''' to your session, for example placed around your airport for exciting camera footage of challenging landings. You will not be able to control those viewers from ATC-pie like the tower viewer, but you will be able to activate/stop the connection from the ''View'' menu. Additional viewers are registered by their host+port address, from the ''View'' menu at run-time or from a custom settings file (see <code>CONFIG/Notice</code>), read at start-up and on explicit reload (''System'' menu).


Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
Every such viewer registered on host ''XXX'' and port ''YYY'' should be running on ''XXX'' and started with options <code>--multiplay=out,TTT,HHH,PPP</code> and <code>--multiplay=in,TTT,,YYY</code>, where:
Line 193: Line 193:
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* instruct taxi routes by dragging out of radar contacts when they are considered on the ground (low enough or squawking GND);
* the dockable instruction panel works regardless of voice vs. mouse selection;
* the dockable instruction panel works regardless of voice vs. mouse selection;
* if the aircraft is connected to CPDLC, you can be prompted to send the instruction through the data link.
* if the aircraft is connected to CPDLC, you can choose to be prompted to send the instruction through the data link (see ''General settings'' dialog, CPDLC tab).


Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.
Instructions from the panel are always issued to the callsign entered in the top field, which should fill automatically on aircraft or strip selection when a callsign is known. Therefore, make sure you do not mess up your strip links or your instructions will realistically be acknowledged and followed by the wrong aircraft.
Line 231: Line 231:


For most interactions to work while respecting both approaches as much as possible, the following principles and restrictions apply to strip exchange:
For most interactions to work while respecting both approaches as much as possible, the following principles and restrictions apply to strip exchange:
* ATC-pie users can only hand over strips that are linked to a radar contact;
* ATC-pie users can only hand over strips to OpenRadar that are linked to a radar contact;
* aircraft under ATC-pie control are not shown as "owned" to OpenRadar users;
* aircraft under ATC-pie control are not shown as "owned" to OpenRadar users;
* handovers from ATC-pie will fail if an OpenRadar user is claiming ownership on the linked radar contact;
* handovers from ATC-pie will fail if an OpenRadar user is claiming ownership on the linked radar contact;
Line 249: Line 249:


=== FSD sessions and compatibility with Euroscope ===
=== FSD sessions and compatibility with Euroscope ===
Euroscope is a popular program to control on VATSIM, a flight simulation network which, although made incompatible with it today, is historically based on the FSD protocol. For a long time Euroscope allowed to connect to "plain" FSD servers, until it started being tailored more specifically for VATSIM, and closed the door to outside FSD connections. Older versions are still around, which ATC-pie is able to interact with, but only to a limited extent:
Euroscope is a popular program to control on VATSIM, a flight simulation network which is historically based on the FSD protocol, although made incompatible with it today. For a long time Euroscope allowed to connect to "plain" FSD servers, until it started being tailored more specifically for VATSIM, and closed the door to outside FSD connections. Older versions of Euroscope are still around, which ATC-pie is able to interact with, but only to a limited extent:
* sending a strip to Euroscope will result in a loss of all strip details but the callsign (which must be connected), the only information left to the recipient being the FPL details for that callsign if any (strip changes made after FPL data retrieval are therefore lost);
* sending a strip to Euroscope will result in a loss of all strip details but the callsign (which must be connected), the only information left to the recipient being the FPL details for that callsign if any (strip changes made after FPL data retrieval are therefore lost);
* receiving a strip from Euroscope is supported, but the sender will see the hondover pending (never "assumed");
* receiving a strip from Euroscope is supported, but the sender will see the hondover pending (never "assumed");
* who-has requests will remain unanswered.
* who-has requests will remain unanswered by Euroscope.


ATC-pie clients interact normally between each other, but note that CPDLC is not supported by the FSD protocol.
ATC-pie clients interact normally between each other, but note that CPDLC is not supported by the FSD protocol.
Line 315: Line 315:
== Teacher & student connections (ATC tutoring) ==
== Teacher & student connections (ATC tutoring) ==


This connection type is made to bring an ATC student and a teacher together for tutorial sessions. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.
This session type is made to bring an ATC student and a teacher together for tutorial sessions. To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. The teacher creates and manipulates traffic for the student to work with, controls the weather and decides on the ATC neighbours. Strip exchange and ATC text chat is possible, either between both parties ("offline" exchanges) or between the student and the virtual ATCs (in-sim coordination). All exchanges are monitored by the teacher, and transparent to the student. The teacher can also snapshot traffic position situations to recall them later.
 
To '''set up a session''', the student must connect to the teacher, so make sure the teacher's session is running first. Only one student can connect to a teacher at a time. To communicate via voice during the session, the two parties may use nearby FGCom frequencies, but a private channel on [[Mumble]] is also an option to avoid interfering with other users sharing the same server. The best choice is probably to tune into unused (guard or secondary) FGCom frequencies for in-simulation transmissions, and to open a separate channel for teacher–student conversations.


When '''playing teacher''':
When '''playing teacher''':
265

edits