Example

This may be spoken as:

“Speedbird one two three.”

General Aviation

Use the aircraft registration.

Example

This may be spoken as:

“Golf Alpha Bravo Charlie Delta.”

Important Rules

• The callsign filed in the flight plan must match the callsign used to connect.
• Do not change callsign during the flight.
• Avoid using a callsign already connected.
• Know the airline’s spoken telephony name.
• Do not connect using only an aircraft type, such as A320.

---

17. Aircraft Type Code

Use the correct ICAO aircraft type.

Examples:

• B738 – Boeing 737-800.
• B38M – Boeing 737 MAX 8.
• A319 – Airbus A319.
• A320 – Airbus A320.
• A20N – Airbus A320neo.
• A359 – Airbus A350-900.
• A306 – Airbus A300-600.
• A388 – Airbus A380-800.

This information helps:

• Controllers understand aircraft performance.
• vPilot select suitable model matching.
• Other pilots see an appropriate aircraft.
• Flight plans represent the correct capabilities.

---

18. Filing a Flight Plan

Create the flight in SimBrief and review it before filing.

A normal IFR flight plan includes:

• Callsign.
• Departure airport.
• Destination.
• Alternate where applicable.
• Aircraft type.
• Equipment code.
• Cruise speed.
• Cruise altitude.
• Route.
• Remarks.
• Estimated en-route time.
• Fuel endurance.

IFR pilots must file a flight plan before flight.  

Filing Procedure

1. Generate the SimBrief flight.
2. Open the VATSIM flight-plan page or supported filing integration.
3. Import or copy the SimBrief data.
4. Confirm the callsign.
5. Confirm departure and arrival.
6. Confirm aircraft type.
7. Confirm requested cruise altitude.
8. Check the route.
9. Check equipment information.
10. Add useful remarks.
11. Submit the flight plan.

Do not file the plan without reviewing it.

---

19. Useful Remarks

Remarks may include relevant capability information.

Examples

Only include information that is accurate and useful.

Writing “new pilot” may encourage controllers to slow down or provide additional explanation, but it does not remove the pilot’s responsibility to operate the aircraft safely.

---

Understanding Frequencies

20. Controller Positions

Depending on the airport and airspace, available controllers may include:

• Delivery.
• Ground.
• Tower.
• Departure.
• Approach.
• Centre or Control.
• Radio or Information positions in some regions.

Not every position will always be online.

A higher-level controller may cover several lower-level positions.

For example:

• Tower may provide clearance and taxi if Delivery and Ground are offline.
• Approach may cover Tower.
• Centre may cover multiple airports and lower sectors.

Check the controller’s information before calling.

---

21. Controller Information

vPilot displays connected controller positions and frequencies.

Before transmitting:

1. Select the controller.
2. Read the controller information.
3. Check the covered airports.
4. Check any published text instructions.
5. Tune the frequency.
6. Listen before speaking.

Do not call a controller merely because they are visible if your airport is outside their coverage.

---

22. Radio Discipline

Good radio technique means:

• Listen before transmitting.
• Think before pressing push-to-talk.
• Use the full callsign initially.
• Keep transmissions brief.
• Read back required instructions.
• Avoid unnecessary conversation.
• Do not speak over other pilots.
• Correct mistakes calmly.

A useful structure is:

Who you are calling – who you are – where you are – what you want.

Example:

“Heathrow Delivery, Speedbird one two three, stand five two five, information Alpha, IFR to Palma, request clearance.”

---

Clearance

23. Preparing for Clearance

Before requesting clearance:

• Flight plan filed.
• Route loaded.
• Departure charts open.
• Current ATIS obtained where available.
• Expected runway reviewed.
• SID reviewed.
• Pen and paper ready.
• Aircraft powered and controllable.

Do not request clearance while still trying to choose the aircraft or create the route.

---

24. IFR Clearance Example

Pilot:

“Heathrow Delivery, Speedbird one two three, stand five two five, information Alpha, IFR to Palma, request clearance.”

Controller:

“Speedbird one two three, cleared to Palma via the CPT departure, runway two seven right, climb altitude six thousand feet, squawk five two one four.”

Readback:

“Cleared to Palma via the CPT departure, runway two seven right, climb altitude six thousand feet, squawk five two one four, Speedbird one two three.”

Read back:

• Destination clearance.
• SID or routing.
• Runway where issued.
• Initial altitude.
• Squawk code.
• Any special restriction.

---

25. When You Do Not Understand

Do not guess.

Use phrases such as:

“Say again for Speedbird one two three.”

“Confirm initial altitude six thousand feet?”

“Unable that routing, request vectors.”

“Stand by.”

Controllers would rather repeat an instruction than watch an aircraft follow the wrong clearance.

---

Pushback and Start

26. Requesting Pushback

When ready:

• Doors closed.
• Ground services finishing.
• Beacon ready.
• Clearance received.
• Aircraft capable of starting.

Example:

“Heathrow Ground, Speedbird one two three, stand five two five, request push and start.”

Controller:

“Speedbird one two three, push and start approved, face west.”

Readback:

“Push and start approved, face west, Speedbird one two three.”

Do not begin pushback before approval when under active ground control.

---

27. Pushback Direction

Understand instructions such as:

• Face north.
• Face west.
• Tail left.
• Tail right.
• Push onto a named taxiway.
• Long push approved.
• Push at your discretion.

Use the airport diagram to understand the resulting aircraft position.

---

Taxi

28. Taxi Request

After engine start and checks:

“Heathrow Ground, Speedbird one two three, ready to taxi.”

Controller:

“Speedbird one two three, taxi holding point N11, runway two seven right, via Alpha and November.”

Readback:

“Taxi holding point N11, runway two seven right, via Alpha and November, Speedbird one two three.”

---

29. What Must Be Read Back

Always read back safety-critical instructions, including:

• Runway assignments.
• Hold-short instructions.
• Runway crossings.
• Taxi route.
• Altitude.
• Heading.
• Speed.
• Squawk code.
• Take-off and landing clearances.
• Frequency changes where confirmation is needed.

---

30. Runway Crossing

Never cross a runway unless specifically cleared.

Controller:

“Speedbird one two three, cross runway zero nine, continue via Bravo.”

Readback:

“Cross runway zero nine, continue via Bravo, Speedbird one two three.”

If uncertain:

“Confirm cleared to cross runway zero nine?”

---

31. Lost During Taxi

Stop safely and ask.

“Heathrow Ground, Speedbird one two three, uncertain of position, request assistance.”

Do not continue moving while trying to guess the taxi route.

---

Departure

32. Contacting Tower

When instructed:

“Speedbird one two three, contact Tower one one eight decimal five.”

Readback:

“One one eight decimal five, Speedbird one two three.”

After switching:

“Heathrow Tower, Speedbird one two three, holding N11, runway two seven right, ready.”

---

33. Line-Up Instruction

Controller:

“Speedbird one two three, line up and wait runway two seven right.”

Readback:

“Line up and wait runway two seven right, Speedbird one two three.”

This is not a take-off clearance.

Do not begin the take-off roll.

---

34. Take-Off Clearance

Controller:

“Speedbird one two three, runway two seven right, cleared for take-off, wind two six zero degrees eight knots.”

Readback:

“Cleared for take-off runway two seven right, Speedbird one two three.”

The runway must be included in the readback.

---

35. Departure Handoff

Controller:

“Speedbird one two three, contact London Control one two seven decimal eight.”

Readback:

“One two seven decimal eight, Speedbird one two three.”

Initial call:

“London Control, Speedbird one two three, passing four thousand feet, climbing six thousand feet.”

Include:

• Callsign.
• Current altitude.
• Cleared altitude.

---

En-Route Control

36. Altitude Instructions

Controller:

“Speedbird one two three, climb flight level three six zero.”

Readback:

“Climb flight level three six zero, Speedbird one two three.”

Do not climb until instructed unless operating outside controlled service where your flight plan and airspace permit it.

---

37. Heading Instructions

Controller:

“Speedbird one two three, turn left heading two one zero.”

Readback:

“Left heading two one zero, Speedbird one two three.”

Enter selected heading promptly and verify the aircraft turns in the correct direction.

---

38. Direct-To Instruction

Controller:

“Speedbird one two three, proceed direct KONAN.”

Readback:

“Direct KONAN, Speedbird one two three.”

Before executing:

• Confirm the waypoint.
• Check the resulting route.
• Ensure no unexpected sharp turn or discontinuity appears.

---

39. Speed Instruction

Controller:

“Speedbird one two three, maintain two five zero knots.”

Readback:

“Maintain two five zero knots, Speedbird one two three.”

If unable:

“Unable two five zero due turbulence, minimum two eight zero knots, Speedbird one two three.”

Never silently ignore an instruction.

---

Arrival and Approach

40. Preparing Before Descent

Before calling or entering destination control:

• Weather reviewed.
• Arrival chart open.
• STAR programmed.
• Expected approach programmed.
• Minimums set.
• Landing performance calculated.
• Aircraft ready for runway change.
• Fuel checked.

Controllers may change the runway or procedure.

Students must be able to update the aircraft without losing control.

---

41. Arrival Contact

Initial call example:

“Palma Approach, Speedbird one two three, flight level one one zero, descending flight level eight zero, information Charlie.”

Include:

• Callsign.
• Current level.
• Cleared level.
• ATIS code where appropriate.

---

42. Arrival Clearance

Controller:

“Speedbird one two three, descend altitude four thousand feet, cleared MJV arrival.”

Readback:

“Descend altitude four thousand feet, cleared MJV arrival, Speedbird one two three.”

Check:

• The STAR is correctly loaded.
• Constraints remain valid.
• The altitude selector is set.
• The correct flight mode is active.

---

43. Vectors for Approach

Controller:

“Speedbird one two three, turn right heading two four zero, descend three thousand feet.”

Readback:

“Right heading two four zero, descend three thousand feet, Speedbird one two three.”

Use selected heading and altitude modes.

Do not continue following the programmed route when ATC has issued vectors.

---

44. ILS Clearance

Controller:

“Speedbird one two three, turn left heading two zero zero, cleared ILS approach runway two four left.”

Readback:

“Left heading two zero zero, cleared ILS approach runway two four left, Speedbird one two three.”

Confirm:

• Correct runway.
• Correct ILS.
• Correct course.
• Suitable intercept altitude.
• Approach mode armed at the correct time.

---

45. Landing Clearance

Controller:

“Speedbird one two three, runway two four left, cleared to land, wind two three zero degrees seven knots.”

Readback:

“Cleared to land runway two four left, Speedbird one two three.”

Do not land without a landing clearance when Tower is controlling the runway.

If no clearance has been received approaching the runway threshold, call Tower.

---

Ground Communication After Landing

46. Leaving the Runway

After vacating:

“Palma Tower, Speedbird one two three, runway vacated via Alpha six.”

The controller may transfer you to Ground.

Do not stop on the runway to reconfigure the complete aircraft.

---

47. Taxi to Stand

Controller:

“Speedbird one two three, taxi stand one zero four via Alpha and Mike.”

Readback:

“Taxi stand one zero four via Alpha and Mike, Speedbird one two three.”

Keep the airport diagram open until parked.

---

48. Disconnecting

After parking:

• Parking brake set.
• Clear of taxiways.
• Engines shut down or aircraft safely secured.
• No further ATC instruction expected.

Disconnect using vPilot.

Do not remain connected unattended for a long period at a busy stand.

---

Operating Without ATC

49. UNICOM

When no controller covers the area, pilots commonly use the network’s designated advisory frequency shown by current VATSIM procedures and client information.

Because VATSIM frequency-management policies can change, students must use the current frequency displayed or prescribed by VATSIM rather than relying permanently on an older course recording.

UNICOM is not air traffic control.

Pilots use it to broadcast useful position and intention information.

---

50. Useful UNICOM Calls

At the stand:

“Heathrow traffic, Speedbird one two three, pushing stand five two five, facing west.”

Taxi:

“Heathrow traffic, Speedbird one two three, taxiing to runway two seven right via Alpha and November.”

Departure:

“Heathrow traffic, Speedbird one two three, departing runway two seven right via the CPT departure.”

Approach:

“Palma traffic, Speedbird one two three, ten-mile final runway two four left.”

Vacating:

“Palma traffic, Speedbird one two three, vacated runway two four left.”

---

51. Poor UNICOM Use

Avoid:

• Broadcasting every small cockpit action.
• Making excessively long calls.
• Saying only “taking off” without identifying the runway.
• Reporting a position without airport name.
• Treating UNICOM like a controller.
• Issuing instructions to other pilots.
• Arguing over right of way.

Only transmit information that helps nearby traffic understand your intentions.

---

Emergencies and Communication Problems

52. Declaring an Emergency

If a simulated emergency develops and you want ATC assistance:

“Mayday, Mayday, Mayday, Speedbird one two three, engine failure, maintaining five thousand feet, request immediate return to Heathrow.”

A less urgent situation may use:

“Pan Pan, Pan Pan, Pan Pan…”

Give:

• Callsign.
• Nature of problem.
• Current position or altitude.
• Intentions.
• Assistance required.

---

53. VATSIM Emergencies Are Optional

Controllers may assist with realistic emergency handling, but network traffic and controller workload take priority.

A controller may ask you to:

• Discontinue the emergency.
• Move elsewhere.
• Disconnect.
• Continue without special handling.

Pilots must comply.

Do not create an emergency solely to disrupt a busy event.

---

54. Radio Failure

If voice transmission fails:

1. Check push-to-talk.
2. Check the selected microphone.
3. Check the tuned frequency.
4. Check aircraft radio power.
5. Use vPilot text where necessary.
6. Inform the controller briefly.
7. Follow received instructions if possible.
8. Disconnect if safe operation cannot be maintained.

Example text:

55. Simulator Failure or Loss of Control

If:

• The simulator freezes.
• Controls stop responding.
• The aircraft becomes unstable.
• A CTD appears imminent.
• Position is no longer accurate.

Disconnect from VATSIM immediately.

It is better to disappear safely than continue disrupting active traffic.

---

Online Etiquette

56. Professional Behaviour

Good online etiquette includes:

• Being patient.
• Listening carefully.
• Using brief transmissions.
• Respecting controllers and pilots.
• Admitting mistakes.
• Asking for clarification.
• Preparing before connection.
• Avoiding arguments on frequency.
• Using text only when necessary.
• Following the Code of Conduct.

---

57. Do Not Pause in Controlled Flight

Avoid using simulator pause while actively connected.

Pausing can cause:

• Separation problems.
• Aircraft appearing stationary.
• Traffic conflicts.
• Confusion for ATC.
• Client disconnection depending on circumstances.

Disconnect first if a long pause is necessary.

---

58. Do Not Slew or Teleport

Do not use:

• Slew mode.
• Teleportation.
• Developer relocation.
• Instant altitude changes.
• Time acceleration that makes tracking unsafe.

while connected in active airspace unless explicitly permitted by current network rules and coordinated where necessary.

---

59. Monitor the Radio

Do not leave the computer while under ATC control.

Remain able to:

• Respond promptly.
• Follow frequency changes.
• Adjust altitude.
• Change runway.
• Stop taxiing.
• Execute a go-around.

---

STEP 3 – PERFORMANCE AND COMPATIBILITY TESTING

Testing VATSIM, vPilot and Model Matching

---

60. Establish a Baseline

Before connecting, record:

• Average FPS.
• 1% lows.
• MainThread status.
• RAM usage.
• VRAM usage.
• CPU usage.
• Network usage.
• Frame-time behaviour.

Use the same airport, aircraft, weather and camera position for every test.

---

61. vPilot Performance Test

Test the following conditions:

1. Simulator running without vPilot.
2. vPilot running but disconnected.
3. vPilot connected with no nearby traffic.
4. vPilot connected at a busy airport.
5. Controller audio active.

vPilot itself should normally have a small direct performance impact. The larger effect usually comes from the number and complexity of displayed traffic models.

---

62. Model-Matching Performance

Compare:

1. Default fallback models.
2. FSLTL Base Models.
3. Alternative model library where installed.

Record:

• Loading time.
• FPS.
• 1% lows.
• VRAM.
• RAM.
• MainThread.
• Number of visible aircraft.
• Missing-model errors.

High-resolution or poorly optimised models can increase:

• VRAM consumption.
• Draw calls.
• Loading times.
• Panning stutters.
• CPU workload.

---

63. Traffic-Density Testing

Test at:

• A quiet regional airport.
• A moderately busy airport.
• A major event or hub.

Record the approximate number of visible aircraft.

As traffic increases, expect additional demand from:

• Model loading.
• Aircraft animation.
• Lighting.
• Position updates.
• Sound.
• Rendering.
• Network data.

The objective is not to achieve the same FPS in every environment. It is to find a stable configuration for busy network operations.

---

64. CPU and MainThread Load

Monitor:

• MainThread status.
• Total CPU usage.
• 1% lows.
• Frame-time spikes.

If performance falls sharply with many aircraft present, test:

• Lower simulator ground-aircraft settings.
• Reduced model-draw distance where supported.
• Lower airport worker density.
• Reduced Object LOD.
• A lighter model library.
• Less complex premium scenery.

Do not disable VATSIM traffic merely because a premium airport and maximum scenery settings overwhelm the MainThread.

Balance the complete environment.

---

65. VRAM Usage

Model matching loads exterior aircraft textures into graphics memory.

Monitor VRAM:

• With no nearby traffic.
• With ten nearby aircraft.
• At a large event.
• With day and night lighting.
• With a premium airport.

Signs of VRAM pressure include:

• Texture pop-in.
• Blurry aircraft.
• Heavy camera stutters.
• Delayed model appearance.
• Large frame-time spikes.

---

66. Network Stability

Monitor:

• vPilot connection status.
• Ping or latency where visible.
• Disconnect messages.
• Voice stability.
• Simulator scenery streaming.
• Other downloads.
• Wi-Fi strength.

For best results:

• Use Ethernet where possible.
• Stop large downloads.
• Avoid streaming high-bitrate video during busy flights.
• Prevent cloud backup from saturating the connection.
• Keep vPilot permitted through the firewall.

A vPilot disconnection does not always mean VATSIM itself is at fault. Local network, firewall and congestion should also be investigated.

---

67. Audio Performance

Test:

• Incoming ATC audio.
• Outgoing microphone quality.
• Push-to-talk delay.
• Multiple simultaneous stations.
• Simulator sound balance.
• Headset stability.

Check for:

• Clipping.
• Very low volume.
• Echo.
• Background noise.
• Wrong microphone.
• Audio device changing during the flight.
• Bluetooth quality reduction.

Use a wired or stable wireless headset for important online flights.

---

68. Frame-Time Testing

Average FPS may remain acceptable while traffic creates frame-time spikes.

Monitor:

• Taxi at the terminal.
• Looking towards parked traffic.
• Panning across the apron.
• Take-off during a busy event.
• Arrival when models load.
• Landing with ground traffic nearby.

Record where the spikes occur.

If stutters happen only as new traffic appears, model loading is a likely contributor.

---

69. FSLTL Conflict Test

To use FSLTL with VATSIM:

• Keep the Base Models installed.
• Load the correct VMR.
• Do not launch the Injector.

The official FSLTL guide specifically states that its Injector should not be used during a VATSIM session.  

Test Procedure

1. Disable MSFS Live Traffic.
2. Keep FSLTL Base Models installed.
3. Leave FSLTL Injector closed.
4. Connect to VATSIM.
5. Confirm one version of each nearby aircraft appears.
6. Check vPilot model-matching messages.
7. Monitor FPS and MainThread.

---

70. BeyondATC and Other Injector Conflicts

Before connecting to VATSIM, disable traffic injection from:

• BeyondATC.
• FSLTL.
• AIG.
• MSFS Live Traffic.
• Other real-time traffic programs.

BeyondATC may still be used in another offline workflow, but its ATC and traffic functions should not compete with live VATSIM controllers and network traffic.

---

71. Duplicate-Traffic Test

Signs of duplicate traffic include:

• Two aircraft occupying the same stand.
• One VATSIM aircraft plus one live-traffic copy.
• Duplicate callsigns.
• Aircraft moving differently despite identical liveries.
• Severe traffic-related FPS loss.

To diagnose:

1. Disconnect from VATSIM.
2. Confirm all simulator traffic is off.
3. Stop every injector.
4. Reconnect using only vPilot.
5. Confirm duplicates are gone.
6. Reintroduce no additional injector.

---

72. Model-Matching Errors

Common vPilot messages include:

• Model not found.
• No matching model.
• Invalid VMR rule.
• Default model unavailable.

Check:

• The referenced model library is installed.
• The VMR points to models that actually exist.
• The correct simulator path is scanned.
• The fallback model is valid.
• The VMR order is sensible.
• Old rules have been removed.

A VMR cannot display an aircraft model that is not installed.  

---

73. MSFS 2020 vs MSFS 2024 Comparison

If both simulators are installed, test them separately.

Do not assume model libraries and Community Folder paths are shared correctly between both simulators.

---

Common Problems

vPilot Does Not Connect to MSFS

Check:

• Simulator is running.
• Flight is fully loaded.
• Current vPilot version.
• Correct simulator package location.
• Firewall permission.
• Administrator or user-permission conflicts.
• MSFS 2024 path detection where relevant.

---

Cannot Hear ATC

Check:

• Correct frequency.
• Aircraft radio has electrical power.
• Correct audio output.
• COM1 selected.
• Volume controls.
• vPilot audio settings.
• Headset connection.

---

ATC Cannot Hear You

Check:

• Correct microphone.
• Push-to-talk assignment.
• Microphone level.
• Windows privacy permission.
• Frequency selected for transmission.
• No stuck or conflicting binding.

---

Other Aircraft Are Invisible

Check:

• Model library installed.
• Model scan completed.
• Valid fallback selected.
• VMR enabled.
• Correct Community Folder.
• Simulator traffic settings.
• Aircraft may be outside visual range.

---

Wrong Aircraft Models Appear

Check:

• Correct aircraft type entered by the other pilot.
• VMR priority.
• Model-library coverage.
• Airline livery availability.
• Fallback behaviour.

Perfect model matching is not always possible.

---

Duplicate Aircraft Appear

Disable:

• Live Traffic.
• FSLTL Injector.
• AIG injector.
• BeyondATC traffic.
• Any other traffic source.

---

FPS Drops at Busy Airports

Check:

• Number of visible aircraft.
• Model texture resolution.
• Premium airport complexity.
• Object LOD.
• Static aircraft.
• Airport workers.
• VRAM.
• MainThread.

---

Frequent Disconnects

Check:

• Ethernet or Wi-Fi.
• Firewall.
• Router stability.
• Background downloads.
• VPN.
• vPilot update.
• Wider VATSIM service status.

---

Student Practical Assignment

Complete a Supervised VATSIM Flight

Choose a short route of approximately 45–60 minutes.

Use an aircraft you already understand well.

---

Part 1 – Setup

VATSIM CID recorded: Yes / No

Code of Conduct reviewed: Yes / No

vPilot installed: Yes / No

Simulator: MSFS 2020 / MSFS 2024

Microphone tested: Yes / No

Push-to-talk tested: Yes / No

Model library:

VMR installed: Yes / No

Other traffic disabled: Yes / No

---

Part 2 – Flight Plan

Callsign:

Spoken callsign:

Aircraft type:

Departure:

Destination:

Cruise altitude:

Route:

Flight plan filed: Yes / No

---

Part 3 – Communication

Confirm:

☐ ATIS reviewed.

☐ IFR clearance requested.

☐ Clearance read back.

☐ Pushback approved.

☐ Taxi route read back.

☐ Hold-short instructions followed.

☐ Take-off clearance received.

☐ Departure frequency contacted.

☐ Altitude instructions followed.

☐ Arrival prepared.

☐ Approach clearance read back.

☐ Landing clearance received.

☐ Runway vacated.

☐ Taxi to stand completed.

☐ vPilot disconnected after parking.

Part 4 – Performance Test

Final Assessment

Answer:

• Was the account and client configured correctly?
• Could ATC hear the microphone?
• Could all instructions be understood?
• Were readbacks accurate?
• Did model matching work?
• Was duplicate traffic avoided?
• Did traffic cause measurable FPS loss?
• Was the network connection stable?
• Which area needs more practice before the next flight?

---

Student Checklist

VATSIM account created.

New-member requirements completed.

Code of Conduct reviewed.

vPilot installed.

MSFS 2020 or MSFS 2024 detected.

Microphone configured.

Headset output configured.

Push-to-talk assigned.

Model library installed.

VMR rules configured.

FSLTL Injector disabled.

Simulator Live Traffic disabled.

Correct callsign selected.

Correct aircraft type entered.

IFR flight plan filed.

Clearance phraseology practised.

Pushback and taxi calls practised.

Departure communication understood.

En-route instructions understood.

Arrival and approach calls practised.

Landing and ground communication understood.

UNICOM use understood.

Emergency procedure understood.

Online etiquette understood.

Model-matching performance tested.

Network and audio stability tested.

Duplicate traffic ruled out.

---

Lesson Summary

You have now configured and used VATSIM with Microsoft Flight Simulator 2020 or Microsoft Flight Simulator 2024.

Remember:

• VATSIM is a live human network, not an automated ATC add-on.
• vPilot is the approved MSFS pilot client.
• IFR pilots must file a flight plan.
• The connected callsign must match the filed callsign.
• Students should understand their aircraft before joining controlled airspace.
• Listen before transmitting.
• Read back all safety-critical instructions.
• Ask the controller to repeat anything you do not understand.
• Do not cross a runway without clearance.
• A line-up instruction is not a take-off clearance.
• Do not land without clearance when Tower is active.
• UNICOM provides traffic information but is not ATC.
• Model libraries display traffic; VMR files provide matching rules.
• FSLTL Base Models can be used, but the FSLTL Injector should remain off.
• Disable all other traffic injectors while connected.
• Busy-network performance depends heavily on model count, airport complexity, CPU load and VRAM.
• Disconnect immediately if the simulator becomes uncontrollable.

---

Knowledge Check

1. Which pilot client is approved for MSFS 2020 and MSFS 2024?
2. What is a VATSIM CID?
3. Why should a pilot review the Code of Conduct?
4. Why should students know their aircraft before connecting?
5. What is the purpose of push-to-talk?
6. What does model matching do?
7. What is the difference between a model library and a VMR file?
8. Why must the FSLTL Injector be disabled?
9. How should an airline callsign be entered?
10. Why must the connected and filed callsigns match?
11. What information must an IFR flight plan contain?
12. Which items normally require a full readback?
13. Why is “line up and wait” not permission to take off?
14. What should a pilot do when an instruction is unclear?
15. What is UNICOM used for?
16. Can pilots issue instructions to others on UNICOM?
17. What should a pilot do after losing simulator control?
18. Why can model matching reduce performance at busy airports?
19. What normally causes duplicate traffic?
20. What evidence confirms that the system is ready for a full online flight?