Activities

Activities are time-limited events, tours, rosters, and community challenges that give pilots something to fly towards. They award bonus points and badges, and appear in the Activities section of Phoenix. vAMSYS supports eight activity types — each tailored to a different style of engagement.

Accessing Activities

In Orwell, go to Operations → Activities. You need the Can See Event List permission. The Activities module must be enabled for your airline.

Activity Types Overview

vAMSYS supports eight activity types:

Type	Legs	Registration	How It Works
Event	No	Optional	Fly matching routes or airport pairs during the time window
Slotted Event	No	Required	Reserve a departure slot, then dispatch on the day with a fixed callsign
Focus Airport	No	Optional	Fly to or from a spotlighted airport
Tour	Yes	Required	Complete a sequence of legs in order
Roster	Yes	Required	Complete assigned legs with specific aircraft
Curated Roster	Yes	Required	Experience a rotation a pilot or aircraft flies in a day — shown in Flight Centre, not Activities
Community Goal	No	Automatic	All pilots contribute towards a shared target (e.g. 10,000 flights)
Community Challenge	No	Automatic	Pilots are assigned to teams competing against each other

Common Settings

These settings are shared across most or all activity types.

Presentation

• Name — activity title shown to pilots.

• Sidebar Title and Sidebar Content — optional text shown in a sidebar panel on the activity detail page. Not available for Curated Rosters.

• Tags — sub-categories for filtering in Phoenix.

• Image / Dark Mode Image — banner image displayed on the activity page. Not available for Curated Rosters.

• Description — rich text description of the activity.

Time Window

• Start and End — UTC timestamps defining when the activity is active. PIREPs must fall within this window (adjusted by Time Award Scale).

• Show From — optional; controls when the activity becomes visible in Phoenix. If not set, the activity is visible immediately.

• Time Leeway — 0 to 120 minutes of hidden grace added to both ends of the time window. Pilots do not see this value — they only see the start and end times. Useful for quietly accommodating flights that depart just before or land just after the activity window.

Time Award Scale

Determines which part of the flight must fall within the activity time window:

Rule	Meaning
Takeoff only	Departure time must be within the window
Landing only	Landing time must be within the window
Entire flight	Both takeoff AND landing must be within the window
Any part	Either takeoff OR landing can be within the window

Restrictions

Optional filters that limit which PIREPs qualify for the activity:

• Network — offline, VATSIM, IVAO, POSCON, APOC, PilotEdge, FSCloud, SayIntentions, other.

• Fleet — only specific fleet types.

• Callsign — only specific callsign prefixes.

• Ranks — only pilots of specific ranks.

• Landing Rate — minimum and/or maximum FPM.

Registration

• Registration Required — if enabled, pilots must register before their PIREPs count. Always required for Tours, Rosters, and Curated Rosters.

• Registration Start / End — window during which pilots can register for the activity.

Rewards

• Points — bonus points awarded. Can be a fixed amount or a percentage of the PIREP's base score.

• Create Badge — auto-create a placeholder badge linked to this activity. Only available during activity creation.

• Allow Repeat Participation — whether pilots can complete the activity multiple times.

Events

Fly matching flights during a time window. No specific leg order. PIREPs are matched automatically — no registration required unless you enable it. Points are awarded immediately when a qualifying PIREP is filed.

Events have two subtypes:

Airport-Based Events — configure departure and arrival airports with an operator:

• Departure airports — one or more airports.

• Arrival airports — one or more airports.

• Operator (AND/OR) — AND means the PIREP must match both a listed departure AND a listed arrival. OR means matching either a listed departure OR a listed arrival is sufficient.

Route-Based Events — configure specific routes. Each entry specifies a departure airport, arrival airport, and optionally a specific route ID.

Slotted Events

Slotted Events add departure-slot booking to an event. They behave like a standard Event for flight matching and scoring — a single departure airport with airport or route criteria — but instead of every pilot departing at once, you publish a grid of departure times, organised into Waves, that pilots reserve. Reserving a slot is the pilot's registration for the event; there is no separate sign-up step.

Newly introduced. Slotted Events are the newest activity type and are being rolled out carefully. If you are running a large flyout in the first few weeks, keep an eye on the Slot Reservations table and contact support if anything looks off.

Key terms

• Wave — a configurable group of slots with its own time window, interval, and unlock rule. Waves are how a large event is broken into manageable phases.

• Slot — a single bookable departure time within a wave.

• Reservation — a pilot claiming a slot. This is their registration for the event; releasing the slot unregisters them.

• Dispatch — booking the actual flight on event day from the event page, which hands off to the normal Dispatch page. It can be repeated.

• Per-network tracking — slots are tracked separately for each online network, so the same departure time can be held by one pilot on VATSIM and another on IVAO.

Setting up a Slotted Event

Create a Slotted Event from the Slotted Events tab in Orwell's Activities section. The standard event fields — name, dates, criteria, points, and badges — work exactly as they do for an Event.

Single departure airport — a Slotted Event must depart from one airport. Use the airport-based subtype with a single departure airport, or the route-based subtype where every route shares the same departure airport.

In the Slots section you configure:

• Networks — which online networks use slots. Each network gets its own copy of the time grid with separate ownership.

• Callsign system — how each pilot's callsign is built (see Callsign systems below).

• Dispatch window — how long before and after a slot time the Dispatch action is available. By default it opens 180 minutes before and closes 30 minutes after the slot time.

Waves

Waves are managed from the Waves tab on the event. Each wave defines:

• Name — shown to pilots on the wave panel.

• Position — the order in which waves unlock. Waves unlock by position, not by clock time, so they can be defined in any time order.

• Time window — the start and end time the wave's slots span.

• Interval — how slot times are spaced: Fixed (every set number of minutes) or Custom (specific minutes past the hour, such as :05, :13, and :40). Slot generation is end-exclusive, so back-to-back waves never produce duplicate times.

Unlock rule — each wave opens for booking in one of three ways:

• Always — open immediately, within the event's registration window.

• When the previous wave is full — opens once the previous wave (by position) is fully booked on that network. Once it unlocks it stays open, even if a slot is later released.

• At a scheduled time — opens at a specific date and time you set.

Callsign systems

A pilot's callsign suffix is reserved when they book their slot; the prefix comes from the route they select at dispatch. Suffixes are unique per network for each event. The system you choose decides how the suffix is set:

• Manual — the pilot enters their own suffix.

• Username A — the pilot's ID number with leading zeros removed. For the username RYR0049 the suffix is 49, giving a callsign such as RYR49.

• Username B — the last two digits of the pilot's ID followed by their name initials (up to two). For RYR0049 flown by John Smith the suffix is 49JS, giving a callsign such as RYR49JS.

• Generator — the suffix is generated from a pattern you define.

Username A and Username B are deterministic — each pilot always resolves to the same suffix — so they do not retry on a clash. If two pilots would produce the same callsign, the second reservation is rejected. For large events, Generator avoids this by retrying until it finds a free suffix; Username A and Username B suit smaller events where collisions are unlikely.

Managing reservations

Use the Slot Reservations tab to view, add, edit, or remove reservations. If you edit or remove a wave after pilots have booked, any reservation whose slot no longer maps to a wave is grouped separately under Outside current waves — move or remove these, as pilots cannot fix them themselves. You cannot remove a tracked network while it still has reservations.

How pilots reserve and fly

On the event page, pilots see the wave panels for their selected network, each marked Open or Locked with a count of booked slots. They reserve one slot — which registers them — and can change or release it while the wave is open.

On the day, the pilot uses the Dispatch action on their reserved slot. This opens the normal Dispatch page with the network and callsign locked to their reservation; they pick one of the event's routes, generate the OFP, and fly. Dispatch is only available within the dispatch window and can be repeated.

Scoring and participation

Scoring is identical to a standard Event. A reservation is mandatory, however: a pilot with no current or previous reservation is not scored for the event, even if their flight matches the criteria. Each pilot can hold one reservation per event — repeat participation is always off for Slotted Events.

Current limitations

• Reservations are read-only over the Operations API — they can be viewed but not created through it.

• A Slotted Event has a single departure airport.

• No-show slots are not reclaimed automatically, and there are no waitlists.

• The dispatch window is set per event, not per wave.

Focus Airport

A simplified event centred on a single airport. Any flight departing from or arriving at the focus airport qualifies. No subtypes, no route configuration — just pick the airport. Points are awarded immediately when a qualifying PIREP is filed.

Tours

Tours are multi-leg journeys that pilots complete in sequence. They are the most complex activity type.

How Tours Work

1. Staff creates a tour with an ordered list of legs (minimum 2).

2. Pilots register for the tour during the registration window.

3. Registration creates a logbook tracking progress for each leg.

4. Pilots fly each leg in order — each PIREP is matched against the next incomplete leg.

5. Legs must be flown sequentially: a pilot must land leg N before departing leg N+1. However, pilots can fly other non-tour flights in between legs — they are not limited to flying tour legs back-to-back.

6. When all legs are completed, the tour is marked as complete.

Tour Subtypes

Airport-Based Tours — each leg defines a departure and arrival airport. Any PIREP flying between those airports qualifies for the leg.

Route-Based Tours — each leg specifies a departure airport, arrival airport, and a specific route ID. The PIREP must be on that exact route, not just between the same airports.

Leg Visibility (Show From)

Each tour leg has an optional Show From date. Before this date, the leg is hidden from the pilot's tour progress view. Use this to reveal legs gradually — for example, one leg per week.

How PIREPs Match Tour Legs

A PIREP matches a tour leg when ALL of the following are true:

1. Departure airport matches the leg's departure airport (exact ICAO match).

2. Arrival airport matches the leg's arrival airport (exact ICAO match).

3. Route ID matches the leg's route ID (only for route-based tours).

4. The flight falls within the activity time window (based on Time Award Scale, adjusted by Time Leeway).

5. The pilot departed after landing the previous leg (sequential requirement).

6. All activity restrictions are met (network, fleet, callsign, rank, landing rate).

What Happens When You Edit a Tour

When you save changes to a tour's legs, the system runs a reprocessing job:

1. All bonus points from this tour are removed from every affected PIREP.

2. All logbooks are reset to Incomplete with all legs marked as not completed.

3. Duplicate logbooks are cleaned up (one per pilot).

4. PIREPs are re-matched against the new leg definitions for each registered pilot.

5. Bonus points are re-awarded where PIREPs match the updated legs.

This means:

• If you change a leg's airports, pilots who flew the old airports lose credit for that leg.

• If you add new legs, existing progress on earlier legs is preserved (assuming they still match).

• If you remove legs, the tour becomes shorter and may auto-complete for some pilots.

• The reprocessing runs asynchronously — it may take a few minutes for all pilots to see updated progress.

Tour Point Award Modes

Two settings control when and how points are awarded:

Award Per Leg	When Tour Complete	Behaviour
Yes	No	Points added to each PIREP immediately as each leg is completed
Yes	Yes	Points added to ALL leg PIREPs, but only after the entire tour is complete
No	Yes	Points added only to the final leg's PIREP when the tour is complete

Claims and PIREP Statuses

Both ACARS PIREPs (flights tracked by Pegasus) and accepted claims count towards tour leg completion. The activity system does not distinguish between them — once a claim is accepted by staff, it is processed through the same matching logic as a normal PIREP.

How each PIREP status affects tour progress and scoring:

PIREP Status	Counts Towards Leg?	Points Awarded?
Accepted / Complete	Yes	Full points
Rejected	The leg remains completed — rejecting a PIREP does not automatically revoke tour progress	Rejected PIREPs do not count towards rank progression or statistics. When the award mode is set to award on tour completion, the system pro-rates the points the same way as invalidated PIREPs
Invalidated	The leg remains completed	Invalidated PIREPs do not count towards rank progression or statistics. When the award mode is set to award on tour completion, the system pro-rates the points: it calculates the ratio of valid (non-invalidated) legs to total legs and multiplies the tour points by that ratio

Example of pro-rated points: A 5-leg tour awards 500 points on completion. A pilot completes all 5 legs, but 1 PIREP is later invalidated. The system calculates: 4 valid legs / 5 total legs = 80%. The pilot receives 400 points instead of 500.

Rosters

Rosters work like tours but with aircraft assignments. Each leg specifies a departure, arrival, and a specific aircraft the pilot must fly.

Differences from Tours:

• Each leg has a mandatory aircraft assignment (specific registration, not just fleet type).

• Registration is always required.

• Registration window is automatically set to the activity's start/end dates.

• Aircraft selection is filtered by routes available between the leg's airports.

All other behaviour (sequential completion, PIREP matching, point award modes, claims and PIREP statuses, reprocessing on edit) works identically to tours.

Curated Rosters

Curated Rosters are multi-leg activities with aircraft assignments — functionally similar to Rosters but designed to let pilots experience the rotation a pilot or aircraft flies in a day. They are shown in Flight Centre rather than the Activities page.

Key differences from Rosters:

	Roster	Curated Roster
Displayed in	Activities page	Flight Centre → Curated Rosters
Points	Configurable	Optional — configurable points, percentage mode, or leave at 0
Registration purpose	Required to earn points	For progress tracking and My Rosters
Banner image	Yes	No — shows mini route map instead
Sidebar content	Yes	No
Show From date	Yes	No
Typical use	Short-term competitive schedule	Pilot-in-a-day experience (a rotation a pilot or aircraft flies in a day)

How pilots find them: Curated Rosters appear under Flight Centre → Curated Rosters in the Phoenix sidebar. The menu item only appears if the airline has at least one Curated Roster. A red badge shows how many registered-but-incomplete Curated Rosters the pilot has.

Display: Instead of a banner image, each Curated Roster shows a mini route map. Instead of point values, it shows the number of legs and the aircraft types involved.

All other behaviour (sequential leg completion, PIREP matching, reprocessing on edit) works identically to Rosters and Tours.

Fleet-per-leg: Each leg can assign a fleet type instead of a specific aircraft. This lets pilots choose any aircraft within that fleet type when dispatching the leg.

My Rosters integration: When a pilot registers for a Curated Roster, it also appears on their My Rosters page alongside personal rosters. Pilots can track progress and unregister directly from My Rosters. See My Rosters & Personal Rosters for the pilot perspective.

Community Goals

Community Goals are collaborative targets where all pilots contribute towards a shared objective. They work fundamentally differently from other activity types.

How Community Goals Work

1. Staff defines a target — for example, "Transport 1,000,000 passengers".

2. Any PIREP that meets the goal's filters contributes automatically — no registration needed.

3. Each qualifying PIREP adds to the airline-wide progress (passengers, cargo, flights, distance, or flight time).

4. When the target is reached, the goal is achieved and completion rewards are distributed.

Count Types

Type	What Counts	Unit
Passengers	Passengers transported per PIREP	Passengers
Freight	Cargo weight per PIREP	kg
Flights	Number of qualifying PIREPs	Flights
Distance	Route distance per PIREP	nm
Flight Time	Flight duration per PIREP	Hours

Filters

Community Goals use a flexible filter system. Only PIREPs that pass ALL enabled filters count towards the goal. Available filters:

• Airport Groups — departure/arrival airport restrictions with AND/OR operators.

• Distance Range — minimum and/or maximum flight distance (nm).

• Night Takeoff / Night Landing — require night operations.

• Landing Rate Range — minimum and/or maximum FPM.

• Landing G-Force Range — minimum and/or maximum G-force.

• No Violations / Max Violations — PIREP violation limits.

• Fleets — specific fleet types.

• Callsign Prefixes — specific callsigns.

• Ranks — specific pilot ranks.

• Networks — specific online networks.

• Route Tags — routes with specific tags.

• Route Types — scheduled, cargo, charter, training, VFR, repositioning.

Rewards

• Participation Points Per PIREP — points added to every qualifying PIREP.

• Completion Points — bonus points awarded to all participants when the goal is reached.

• Tiered Multipliers — when enabled, top contributors receive multiplied completion points based on their ranking among all participants. Four configurable tiers with default multipliers:

Tier	Default Multiplier
Top 10%	3.0×
Top 25%	2.0×
Top 50%	1.5×
Top 75%	1.25×

Pilots below the top 75% still receive the base completion points (1.0× multiplier). All multipliers are configurable per activity.

• Badges can be linked for participation (first qualifying PIREP), completion (every participant, only if the goal is reached), and Top 10% contributors (shown when tiered multipliers are enabled). Badges can also be tied to the goal from the badge side using the Community badge rules — see Badges.

Community Challenges

Community Challenges are team-based competitions. Pilots are split into exactly two teams competing against each other over the same time window.

How Community Challenges Work

1. Staff defines exactly 2 teams, each with their own target, count type, and filters.

2. When a pilot files a qualifying PIREP, it counts towards the first matching team.

3. The challenge runs until the end date. Reaching 100% does not end the challenge early — teams can exceed their target.

4. At the end, the team with the highest completion percentage wins. At least one team must reach 100% for there to be a winner.

5. All rewards are distributed after the challenge ends — participation points, completion points, tier multipliers, and winner bonuses.

Team Configuration

Each team has:

• Name — team display name.

• Count Type — what to count (passengers, freight, flights, distance, flight time) — can differ per team.

• Count Target — the target number.

• Filters — same filter system as Community Goals — can differ per team.

Rewards

• Participation Points Per PIREP — points added to every qualifying PIREP during the challenge.

• Winner Bonus Points — flat bonus points awarded to members of the winning team. Distributed after the challenge ends.

• Tiered Multipliers — same tier system as Community Goals. When enabled, top contributors within each team get their winner bonus points multiplied based on contribution ranking.

• Badges can be linked for participation (first qualifying PIREP), winning (every contributor on the winning team, provided the team reached its target), and Top 10% contributors within the winning team (shown when tiered multipliers are enabled). Badges can also be tied to the challenge from the badge side using the Community badge rules — see Badges.

Only the winning team receives winner bonus points and tier rewards. The losing team receives nothing beyond per-PIREP participation points. If neither team reaches 100%, there is no winner and no bonus points are distributed.

Customising Activity Type Names

Airlines can rename every activity type in Settings → Modules. Three sections:

• Activity Names — Event, Focus Airport, Tour, Roster. Shown in Phoenix Activities page tabs and filters.

• Community Activity Names — Community Goal (singular/plural), Community Challenge (singular/plural).

• Roster Names — five labels: Roster (singular), Curated Roster (singular), Curated Rosters (plural), My Rosters, and Roster Generator. Shown in Flight Centre sidebar, page titles, tabs, filter headings, and call-to-action buttons.

Custom names replace the defaults everywhere in Phoenix: navigation, page titles, tabs, filter labels, and call-to-action buttons. When left empty, sensible defaults are used. These overrides are configured per airline in Settings → Modules under the Roster Names section.

Replicating Events

Events and Focus Airports can be set to replicate automatically:

• Weekly — new instance every week.

• Bi-weekly — every two weeks.

• Monthly — every month.

When replicated, a new activity is created with the same settings but shifted dates. You can optionally set a Repeat Until date — once this date is reached, no further replications are created.

List View

The list page has tabs for filtering by type: Current, Event, Focus Airport, Tour, Roster, Curated Roster, Personal Roster, Community Goal, Community Challenge, and VA All.

Column	Description
ID	Database identifier (sortable, searchable)
Name	Activity name (searchable)
Type	Activity type (visible on Current and All tabs)
Show From	When the activity becomes visible (not shown for Curated Roster)
Start	Activity start time
End	Activity end time
Registrations	Number of registered pilots (N/A if registration not required)
Completions	Number of pilots who completed the activity
Tags	Sub-category tags

Actions: Edit, View in Phoenix, Copy (creates a new activity with the same settings), Delete.

Roster Generator Toggle

The Roster Generator lets pilots create personal rosters. Enable it in Settings → Modules under the Roster Generator toggle. When enabled, pilots can access the Roster Generator from the My Rosters page via a "Generate New Roster" card. The generator requires at least two legs. When disabled, pilots cannot create personal rosters, and the My Rosters sidebar link is hidden unless curated rosters exist for the airline.

Flight Time on Activity Cards

Activity cards in Phoenix display estimated flight time information to help pilots gauge the time commitment. Tours and rosters show the total flight time across all legs, while airport-based events show a time range. Flight times are calculated automatically from the activity's routes.

Permissions

Permission	Grants
Can See Event List	Access to Activities management

Prerequisite: The Activities module must be enabled for the airline.

Related

• Badges — link badges to activity completion

• Ranks — restrict activities by rank

• Fleet — restrict activities by fleet type

• PIREPs — PIREPs are scored against activities

• Scoring Rules — activity points are added as bonus scores on top of PIREP scoring