The goal of a TDD task is not to challenge only the best pilots. It is to design a task that as many pilots as possible can actually complete. The best pilots will naturally fly further — covering more distance through smarter route choices, longer flights, and bigger detours within the task — but the task itself should remain reachable by intermediate pilots flying lower-performance gliders.

Speed is intentionally not part of the TDD scoring system: the cup rewards flying well, not flying fast. A task that only a handful of pilots can complete defeats this principle and discourages participation.

In a Season Cup, the same tasks remain available throughout the season and pilots fly them under varied weather conditions. Tasks must therefore be sized so that they remain achievable across a wide range of conditions, not just the best days.

Two typical task shapes:

• Triangle tasks (FAI or flat triangle) — Aim for an optimised distance of 15 to 20 km. This may sound short, but a triangle requires the pilot to come back against the wind on at least one leg, which is much more demanding than flying straight. A 15–20 km triangle is a fair challenge that intermediate pilots can complete on a decent day, while expert pilots will use it as a starting point and extend their flight much further.
• Wind-driven tasks (downwind or crosswind) — Aim for an optimised distance of 35 to 40 km. With the wind doing part of the work, a longer distance becomes accessible to more pilots. Strong pilots will fly a longer flight before reaching the goal and may also continue beyond it, earning additional points through XContest distance — and through the DBF if you have enabled it.

In an Event Cup, you set the task on the day, after assessing the weather. You have direct control over the difficulty: a different task can be designed for each day, calibrated to that specific day's conditions.

The same principle applies — the task should be achievable by the bulk of the participants given the day's actual conditions — but you have far more flexibility:

• On a strong day with good thermals and consistent wind, a longer or more complex task is appropriate.
• On a marginal day, scale the task down so that the field still has a chance to complete it. A task that everyone abandons after 30 minutes is a wasted competition day.
• For a multi-day event, vary the task shapes (triangle, downwind, out-and-return) to reward different skills across the days.

When creating a cup, you must choose between two types:

• 🏁 Event Cup — A series of daily tasks. Each task is flown on a specific date, and only one submission per pilot per task is allowed. The Goal scores 200 pts if the pilot lands correctly and has validated all turnpoints beforehand, 100 pts (counted as a Turnpoint) if the Goal cylinder was reached but the pilot didn't land properly or hadn't validated every turnpoint, and 0 pts if the Goal cylinder was never reached. Distance points use a simple ratio against the best XC among pilots with the highest track points.
• 📅 Season Cup — A free-flying season where pilots can fly the same task multiple times on different dates. The Goal scores the same way as in an Event Cup (200 / 100 / 0 pts — see above). Distance points use a compression formula with a configurable DCF (Distance Compression Factor) that reduces the gap between pilots. Optionally, the organiser can enable a DBF (Distance Bonus Factor) that allows pilots who reached the Goal as a Turnpoint (100 pts) to partially or fully recover the missing 100 pts by flying significantly further than the reference distance. The overall score is the sum of the 6 best individual flight scores.

Creating a cup is a one-time step, done from the Admin panel. It only asks for the essentials — everything else is configured afterwards from Cup Details (see below).

Everything else — and every field above, if you need to change it later — is edited from the Cup Details page, in a single edit form visible to the owner, contributors, and superadmins. This includes: Name, Cup slug, Start/End Date, Organiser Name, Organiser Contact, Notify on tracklog, Description (EN/FR), DCF, DBF (enabled state and multiplier), and the full set of pilot registration & payment settings covered in 5. Pilot Registration & Payments.

DCF and DBF fields only appear for Season cups, and — as with creation — can only be changed while the cup has no submitted scores yet.

Once a cup is created, several actions are available from the cup list. Manage team is available to contributors as well as the owner — every other action below is reserved to the owner:

• 👥 Manage team — Add or remove contributors who can edit tasks but not delete the cup. Contributors receive an email invitation if they are not yet registered.
• 👑 Assign owner — Change which account is set as the cup's owner.
• 🏷 Change type — Switch between Event and Season (only if no scores yet).
• 🔁 Create same cup next year — Duplicates the cup: all tasks, the cup-level dynamic airspace configuration, DCF, DBF (enabled state and factor), Privileged Pilots and whitelist/blacklist zones, the description, and all pilot registration & payment settings — see 5. Pilot Registration & Payments for details on those. Dates are shifted by +1 year. The new cup is suffixed with -NEW so you can rename and verify it. The slug, existing scores, and the list of registered pilots are never copied — the new cup starts fresh on those.

Four methods are available, all from the Tasks panel after selecting a cup:

1. 📂 Upload .xctsk file — Upload a task file produced by XCTrack. This is the simplest method when you already have the task defined externally.
2. 📷 Scan QR code — Use your camera to scan a QR code generated by XCTrack. Useful when sharing tasks in person at a cup briefing.
3. ☁️ Cloud code — Enter a short code (typically 4 characters, e.g. baba) issued by the XContest cloud service when a task is shared. The task is downloaded from tools.xcontest.org and added to the cup automatically. This is convenient when an organiser shares a task code over chat or email.
4. 🗺 Create/Edit task — Opens the integrated Task Manager where you can build a task graphically on a map, define cylinders, and save. Once saved with the cup selected, the task is added to that cup.

Every task is either TDD or Classic. TDD tasks use the AIR³ TDD scoring system described throughout this manual (3 turnpoints in any order, optimised distance calculation). Classic tasks keep turnpoints in list order and are not scored on this TDD platform.

The rule and its enforcement differ depending on how the task is created:

• Uploading via Admin (📂 Upload .xctsk file, 📷 Scan QR code, ☁️ Cloud code) — The task is always saved. If it does not have exactly 3 turnpoints, it is saved anyway but flagged with a warning: it cannot be used for a TDD round until corrected in Task Manager.
• Task Manager, task linked to a cup — The type is an explicit choice (TDD or Classic). In TDD mode, exactly 3 turnpoints are required — the save is blocked otherwise. In Classic mode, there is no limit on the number of turnpoints.
• Task Manager, task not linked to any cup — In TDD mode, 3 turnpoints is recommended but up to 15 is tolerated (the optimisation algorithm switches internally to a slower but still exact method beyond 5 turnpoints). Above 15 turnpoints, the task automatically switches to Classic mode with a warning, since the calculation becomes too heavy.

Every task has a fingerprint that uniquely identifies its waypoints. The fingerprint is calculated from the positions and radii of all turnpoints and the Goal. It is shown in the task parameters in the admin list.

The fingerprint changes whenever any of the following are modified:

• Position (latitude/longitude) of a turnpoint or the Goal
• Radius of any cylinder
• Adding or removing a turnpoint

The fingerprint does not change when you modify the comp name, Land By time, slug, SSS time, or any non-geometric property.

When you export a task that is linked to a cup — via 📂 the .xctsk file, 📷 the QR code, or ☁️ the Cloud code, all from Task Manager — the file includes a small block of extra data (an "extension") identifying the cup, the task, and the task's fingerprint. Recent versions of XCTrack carry this data through into the pilot's IGC tracklog when they fly with that task loaded.

This makes submission smoother, since the tracklog itself can point back to the cup and task it belongs to. That said, it is a convenience for task detection, not the primary mechanism: the system first tries to identify the task purely from the tracklog's geometry — the takeoff position and which waypoints were actually crossed. The extension for task is only consulted as a tie-breaker, when that geometric detection finds more than one matching task and can't decide between them on its own.

The cup itself works differently: if no cup is selected yet in Track Analyser, the extension can pre-fill it automatically. It never overrides a cup the pilot has already selected.

Because the extension travels inside the task data itself, sharing a QR code or Cloud code that was originally generated from Task Manager keeps the extension intact for whoever receives it — nothing extra needs to be done to preserve it. A task built directly on the pilot's device, or loaded from a source other than Task Manager, simply won't carry an extension — submission then relies entirely on geometric detection, exactly as before.

From the Admin panel, the actions you can perform on an existing task are intentionally limited to safe operations:

• ✏️ Rename — Change the comp name of the task (does not affect the fingerprint).
• 🔗 Edit slug — Change the task's URL-friendly identifier.
• 📋 Copy to another cup — Duplicate the task into a different cup. Useful for reusing tasks across cups.
• 🗑 Delete — Remove the task from the cup. Only possible if conditions are met (typically: no submitted scores, or scores already removed).

Note: changing waypoint positions, radii, Land By time, or airspace settings is not done from the Admin panel. These edits are performed in the Task Manager (see below).

To edit the actual content of a task (geometry, timing, airspace), use the Task Manager. You must be logged in with an account that has edit rights on the cup (owner or contributor).

From Task Manager, you can edit:

• Position and radius of turnpoints and the Goal
• Add or remove turnpoints
• SSS Time and Land By Time
• Some airspace-related parameters

The User Management panel in the Admin panel lets you look up the people connected to your cups — their contact details, their role, and which cups they are registered to.

Start by picking a role from the first dropdown: Contributor or Pilot. A Show list button then appears — the list stays hidden until you click it, since it can be long. A second dropdown lets you narrow things down to one of your cups, with current cups listed first and past ones grouped under 📦 Previous Cups.

What you get depends on the combination:

• A role, no cup — everyone with that role who is connected to at least one of your cups. You never see users unrelated to your cups.
• Contributor + a cup — the contributors on that specific cup.
• Pilot + a cup — everyone registered to that cup, whatever their platform role. An owner or contributor who signed up to fly your cup shows up here too, which is usually what you want when you're looking at who is actually flying.

Each entry shows the person's name, email, role, and when their account was created, plus a small 🆔 badge indicating whether they have an XContest UUID on file — handy when a pilot wonders why automatic submission isn't working for them (see 7. Automatic Flight Submission). Two buttons are available per entry: ✏️ Edit user to correct their details, and 🪂 Registered cups to see which of your cups they have signed up to.

The Description (EN/FR) and Automatically send Registration email fields are always visible, regardless of the settings below — Description is simply informational text about the cup, and Registration e-mail sending is available whether or not registration is mandatory.

Everything else here only appears once Pilot registration required is enabled — and within that, the fee-related fields only appear once Enable participation fee is also checked:

Three separate e-mail templates can be customised, each available in English and French — each becomes editable under different conditions:

• Registration — always available, regardless of the other settings below. Sent to a pilot when they register (manually by the organiser, or automatically via the toggle above). Sent as typed.
• Confirmation — only available once Pilot registration required is enabled. Sent when the organiser marks a pilot's registration as confirmed. Unlike the other two, this text is appended to a system-generated e-mail that already includes a summary of the cup and links to Task Manager, Track Analyser, Score, and Overall — you don't need to repeat those in your custom text.
• Payment request — only available once Pilot registration required and Enable participation fee are both enabled. Payment instructions (e.g. bank details, amount, deadline). Sent as typed, either automatically upon registration (if enabled) or manually as a reminder (see "Managing Registered Pilots" below).

A pilot must have an account to register — if they don't, they are redirected to create one (or log in) first. The registration form pre-fills from their profile (name, email, phone, WhatsApp/Telegram availability, XContest/XCTrack username); editing these fields here also updates their platform profile. The phone number is optional, but if one is entered it must be a valid international number.

Three checkboxes set the pilot's initial automatic-submission preferences — the same Auto-submit, Incl Livetracking and Notify settings described above, editable later from the pilot list (see 6. Automatic Flight Submission for the full mechanism):

• Auto-submit — the master switch, checked by default. It requires an XContest/XCTrack username filled in below and an XContest UUID saved in the pilot's My Account: if the UUID is missing, a warning with a link to My Account appears and the Register button stays disabled until they either add it or uncheck this box.
• Incl Livetracking and Notify — both checked by default, and greyed out as soon as Auto-submit is unchecked.

They must also accept the participant disclaimer to submit. Once registered, the form is replaced by a confirmation message and an ✕ Unregister button — the three preferences above are from then on edited directly in the pilot list below, which shows their real stored values. A pilot cannot register twice for the same cup, and appears in the list with a Confirmed status of "no". The Registration and/or Payment request e-mails are sent automatically if the corresponding toggles are enabled.

Owners and contributors see a full table of registered pilots: name, email, phone (with icons if WhatsApp/Telegram are available), and XContest/XCTrack username, plus a delete button. The pilot count next to the panel title shows 12 [8] — total registered, and confirmed in brackets — whenever Pilot registration required is enabled.

Two columns are conditional: Confirmed only appears if Pilot registration required is enabled, and Payment reminder only appears if Enable participation fee is enabled — independently of each other.

• Checking Confirmed opens a choice: send the Confirmation e-mail, confirm without sending an e-mail, or cancel. If you choose to send, the dialog then shows the actual result — ⏳ while sending, then ✅ or ❌ with the error, so you know whether the e-mail really went out. Unchecking it updates silently, with no e-mail and no prompt.
• Checking Payment reminder opens the same kind of choice, and — if you choose to send — re-sends the Payment request e-mail.
• 🗑 Delete removes the pilot from the cup's list entirely and unlinks it from their profile.
• 💬 Comment — a free-text note visible only to editors, for anything you want to remember about a pilot's registration. The icon changes appearance once a comment is saved, and shows it on hover.

The XContest/XCTrack username is directly editable in this table — not just at registration — by an editor, or by the pilot themselves on their own row in the public view. A small 🆔 badge next to it shows at a glance whether that pilot has an XContest UUID on file. Clearing the username automatically switches off Auto-submit below, since a username is required for it.

Three columns control automatic submission for each pilot individually (see 6. Automatic Flight Submission for the full mechanism), all editable here by an editor or by the pilot on their own row:

• Auto-submit — the master switch: whether this pilot's flights are picked up automatically at all. Requires both an XContest/XCTrack username and an XContest UUID on the pilot's profile; the checkbox refuses to be checked otherwise. Switching it off also switches off and greys out the two columns below.
• Incl Livetracking — only editable while Auto-submit is on. Does not affect whether the pilot shows up live on the cup's Live map — that only requires the XContest/XCTrack username to be set. It decides whether the pilot's live tracking positions can be used directly to detect landing, or whether the system should wait until the flight is claimed or uploaded to their XContest account before acting.
• Notify — only editable while Auto-submit is on. Purely a notification preference: whether this pilot receives an e-mail with the result of each automatic submission. It doesn't affect whether the flight is submitted.

Pilots and other visitors who cannot edit the cup see a simplified, read-only table (name, XContest Live with its 🆔 badge, Confirmed status, and the same three automatic-submission columns shown as ✅/— for other pilots), with those three columns and their username editable on their own row, plus a ✕ Remove me button to self-unregister.

You can contact registered pilots directly from the pilot list. Selection works the same way for both channels: click the 💬 icon on a pilot's row (shown only if they flagged their number as WhatsApp), or the ✉️ icon on their email cell. The icons in the column headers select or deselect everyone at once. Two buttons appear next to 🖨 Print PDF as soon as at least one pilot is selected: 📱 WhatsApp (n) and ✉️ Email (n), where n is the number selected.

📱 WhatsApp — you write one message, then open each pilot's conversation one at a time from the list in the dialog. Nothing is sent automatically: each click opens WhatsApp with the message pre-filled, and you press send yourself. The ＋ {name} button inserts a placeholder that is replaced by each pilot's name when their conversation opens, so a single message can still be personalised.

✉️ Email — same idea, with two modes:

• One email (BCC) — a single email opens in your mail client with every selected pilot in BCC. Recipients don't see each other's addresses. The ＋ {name} placeholder isn't available in this mode, since one text goes to everyone.
• Individually — one Open button per pilot, each producing a separate email with ＋ {name} replaced by that pilot's name.

In both cases the email opens in your own mail client and is sent from your own address — these messages don't go through the platform's mail system, so they aren't recorded anywhere on the platform.

The 🗂️ Admin Log button, next to Print PDF, opens a printable log of everything the platform has recorded for this cup — both the e-mails it sent and the automatic submissions it processed. It's the place to look when a pilot says they never received something, or asks why a flight wasn't scored.

Entries are grouped by category, always in the same order: Registrations, Payment requests, Confirmations, Livetracking submissions, Pilot result notifications, and Submission failure notifications. Within each group they are listed oldest first, with four columns:

• Date — when the event happened, in your local time.
• Trigger — for e-mails, whether it was sent automatically or manually by you. For submissions, whether the flight came from Livetracking or was published on XContest by the pilot.
• Recipient / Pilot — the e-mail recipient (partly masked for privacy) or the pilot's name for a submission.
• Status — Sent/Failed for e-mails, Success/Failed for submissions, with the error message appended when there is one.

Note that messages you send yourself through the WhatsApp or Email buttons described above never appear here: they go out from your own device and mail client, so the platform has no record of them.

Pilots can have their flights scored automatically, without ever opening Track Analyser. This runs on a background service that checks XContest's Livedata API for the pilots registered to your cup, independent of your own actions as organiser — but it's useful to understand the mechanism, since pilots will sometimes ask you why a flight was (or wasn't) submitted automatically.

What a pilot needs, on their end:

• An XContest UUID saved in their My Account (requires joining XContest's "tdd" group first).
• An XContest/XCTrack username on their registration for your cup.
• Auto-submit enabled on that registration — on by default, and the switch the service actually filters on. A pilot with it off is simply skipped.

How detection works: the service checks, once a cycle, every pilot registered across all active cups who meets those conditions. Whether it acts on live tracking positions or waits for the flight to be claimed or uploaded to XContest depends on the pilot's own Incl Livetracking preference (see 5. Pilot Registration & Payments) — on by default, meaning landing is detected directly from live positions; if off, the service waits until the flight appears on the pilot's XContest account instead, whether through XCTrack's automatic claim or a manual upload. Neither preference affects the Live map, which only requires the pilot's XContest/XCTrack username to be set.

What happens on submission: the same checks apply as any other submission path (Land By time, airspace, G-record, task detection — see sections 2 and 3), and the outcome is handled differently depending on why a flight wasn't scored:

• No matching task, or a duplicate of an already-submitted flight — silently skipped. Neither the pilot nor you are notified, since these aren't really failures worth acting on.
• Multiple tasks matched and the system couldn't tell which one, or the flight was blocked (Land By time, airspace, or G-record) — both the pilot (if their Notify preference is on) and you (if Notify on tracklog is enabled for your cup) are notified, so the pilot knows to take action.
• Accepted — the usual organiser notification is sent if Notify on tracklog is enabled for your cup.

If a pilot's flight wasn't submitted automatically, they can always submit it manually via Track Analyser.