meshO Manager

Appearance

Relay events ​

Audience: Event organisers and timing operators running a relay competition.

A relay is a team event: one team entry is run by several people in sequence, one per leg, each handing over to the next. Manager treats a relay as a first-class event type from creation through to results and export. This page is the full picture — how a relay differs from an individual event, how to set one up, build and import teams, run the day, and read the results.

How a relay differs from an individual event ​

Almost everything you already know about running an event still applies. The relay-specific differences are concentrated in a few places:

AreaIndividual eventRelay event
Event typeIndividualRelay — chosen at creation, fixed for the life of the event
EntryOne competitorOne team, made of leg runners
ClassOne course poolSame, but the class has a number of legs (2 or more)
StartDrawn, allocated, or punchedMass start per class; punched starts are ignored
BibsFree-form, per competitorTeam carries the base bib; each leg's bib is derived as {teamBib}.{leg}
ResultFinish − startComposed from the legs: per-leg times, a team total, and a team status
RankingBy race time / projected timeBy legs completed and progress; finished teams by team time
ExportOne fileScoped to relay or individual classes — never both in one file

A relay event can also hold ordinary individual classes alongside the relay classes — see Mixed events.

Tip: A team that shares one card and runs the loops of one course in any order — a star relay, common at school and training events — isn't set up as a relay event at all. See Star relays.

New to the terms? A leg is one runner's portion of the relay; the changeover is the handover from one leg to the next. See the glossary.

Creating a relay event ​

From scratch ​

Click New event on the Events page — and, if you have Eventor configured, Create manually…. The New event dialog asks for a name and a date, then the event type:

  • Individual — an ordinary event.
  • Relay — reveals a Number of legs field (default 3, minimum 2) and a Mass start time (hours and minutes, required). The leg count becomes the default for the relay classes you create; each class can use a different count.
  • Multi-stage — a carnival or knock-out made of several events; not a relay. See Multi-stage events.

Pick Relay, set the number of legs and the mass start time, and click Create. Manager creates the event in Setup mode and opens it at its dashboard.

Warning: The event type is immutable once the event exists — you cannot convert an individual event into a relay or vice versa. Switching would invalidate the event's classes and teams, so Manager doesn't allow it. If you picked the wrong type, create a new event.

From Eventor ​

When you create an event from Eventor, the type is a toggle under the event list rather than a step of its own. Manager reads the Eventor event form and pre-selects it — an Eventor relay event (single- or multi-day relay form) suggests Relay, anything else Individual — and you confirm or change it before the event is created. Choosing Relay also asks for the event's default Number of legs and its Mass start time.

Note: Some clubs run a relay where each runner enters individually rather than as a pre-formed team (Eventor sends individual entries, not team entries). Eventor's payload doesn't flag this as a relay — Manager can only guess from the event's name — so check the pre-selected type rather than trusting it before you import. Every class of a new relay event is created as a relay class, with its leg count taken from Eventor's own count where it gives one and the event's default otherwise. Turn any class that should be individual back into one on the Classes page afterwards — see Importing teams.

The relay settings on the event ​

Open Event details (the button on the event header card on the dashboard — see Editing event details). A relay event has a Relay tab in place of the Starts tab an individual event has, because a relay is always a mass start and there is nothing to switch. It holds:

  • Default relay legs — the leg count new relay classes are seeded with. Changing it doesn't retroactively change existing classes; it only affects classes created afterwards.
  • Mass start time — the event's mass start. Any relay class that doesn't have a mass-start time of its own falls back to it (below).
  • Restart — switch it on and set a Restart time for the event-wide restart (omstart): "Waiting runners in every relay class restart together at this time, unless a class overrides it." Every relay class inherits it unless the class sets its own time or opts out — exactly the way the mass start is inherited.

Relay classes ​

A relay class is just a class with two or more legs. You create and edit classes the same way as in an individual event (see Classes and courses) — the relay-specific controls live in the Edit Class dialog.

Relay or individual (the class kind) ​

In a relay event each class is either a relay class or an individual side class. The Edit Class dialog shows a Class type chooser (Relay / Individual):

  • Relay reveals Number of legs — the number of runners in a team for this class. The minimum is 2 ("Relay classes have at least 2 legs.").
  • Individual turns the class into an ordinary single-leg class run alongside the relay — "normal starts, bibs and individual results".

Note: The class type chooser only appears in a relay event. In an individual event every class is single-leg and there's nothing to choose.

Not the same as a class whose competitors do every course. Edit Class also offers Competitors do: All courses — one person running several courses one after another on one card, such as a Duo class at an MTBO (a ride, then a run). That is an individual class, not a relay: there is one competitor and one card, and the parts are separated by a changeover control rather than a handover to another runner. A relay class can't use it ("A relay class cannot run its courses one after another. Choose course pool, or make it an individual class."). See Classes whose competitors do every course.

Manager decides "is this a relay class?" purely from the leg count: more than one leg means relay. There's no separate hidden flag to get out of step with the number you see.

Number of legs ​

  • New relay classes start at the event's Default relay legs.
  • You can set any count of 2 or more per class — classes in the same event can have different leg counts.
  • Setting a class to 1 leg makes it an individual side class.

Changing a class's kind ​

  • Individual → Relay: allowed any time; set the leg count.
  • Relay → Individual: refused while the class still has teams ("… still has relay teams. Delete its teams before changing it to an individual class."). Delete the class's teams first, then change it. (Teams can only belong to a relay class — Manager won't let a team sit on a single-leg class.)
  • Changing a relay class's leg count (say 3 → 4) is allowed even with teams, but the teams are not resized to match. A team whose roster doesn't match the class's leg count can't be classified — it stays unranked until you edit each team and fill (or remove) the legs. Manager recomputes the class's teams immediately when you save the change.

Courses and forked legs ​

A relay class holds a course pool exactly like an individual class — one row per physical course. Relay legs are very often run on forked (gaffled) course variants, so a class typically has several courses in its pool, one per variant.

There are two ways a leg runner ends up on the right course:

  1. Course locks by bib and leg. If your course-setting software exports per-runner course assignments in its IOF course file, Manager imports them as course locks — each leg runner is pinned to their assigned course. Runners are matched by bib number, so import the start/entry list (which carries the bibs) before the course file. See Locking a competitor to a course.
  2. In the team dialog. When you build a team by hand you can pick each leg's Course (and its Variation, if the course has forks) directly — see Building teams.

If a leg isn't locked to a course, Manager checks the runner's download against every course in the class pool and keeps the best match — the same pooled behaviour as an individual class.

Balancing the forks across a team ​

When the courses have fork variations, you can pin each leg to a variation and let Manager check the team covers every fork:

  • In the team dialog. Once every forked leg has a specific variation (not Auto), the Legs section says either "Variations are set correctly — every sector's forks are covered across the team." or lists the forks that are missing or assigned more than once, with a Fix button. While every leg is still on Auto, a Set variations button assigns a balanced set for that team.
  • For every team at once. On the Relay teams page, Actions → Set variations… randomly assigns a balanced set of variations to the teams of one relay class or all of them. Options: Overwrite variations already set, Keep every team's last runner on the same final variation, and Avoid same-leg runners sharing a variation where possible. A team whose leg count doesn't match the forks is skipped and counted. The action is only offered when some course has variations.

A leg left on Auto is checked against every variation and keeps the best match, so you don't have to pin variations at all. Manager doesn't stop a team running the same fork twice — the check above is advice, and balancing the gaffles is the course-setter's job.

Not the Legs page. The Legs page under event data is something else: the stretches between pairs of controls, with their distances and untimed road crossings. See Leg distances.

Radio controls per leg ​

Radio controls in a relay are configured on the class, tagged by leg — leg 1's radio controls are separate from leg 2's, even where the physical control code is the same. On the live surfaces (Leaderboard, Spectator screens, Commentary) Manager compares teams only at the radio controls their courses genuinely share — matched by control code and visit number, not by position — so forked legs still compare fairly. Each competitor's own non-shared radio splits stay visible in Manager. See Controls and radio controls.

Start times for relays ​

Relay start timing is simpler than individual timing, because the model is fixed:

  • Every relay class starts by mass start. The whole field in a class sets off together at the class's mass-start time. Set it in Edit Class by switching on Class mass start and entering the Class mass start time (the dialog notes "Relay classes start by mass start; punched starts are ignored"). A class with no mass-start time of its own falls back to the event's mass start; give a class its own time to stagger it.
  • Punched starts are ignored for relay legs. A runner punching a Start unit doesn't change their timing — the class mass start is always the anchor.
  • Every leg is timed from that one mass start S. That's what makes the results maths work: a runner's clock is the time since S, and the per-leg times fall out as the differences between successive finishes.

To stagger classes (a wave start), give each class its own mass-start time — 10:00 for one, 10:15 for the next. See Start times for the mass-start controls in general.

Warning: Edit Class also offers Exclude this class from event mass start when the class has no mass start of its own. On a relay class that leaves it with no start at all, so its legs get no times and its teams no result. Give the class its own mass-start time instead.

Restarts (omstart) ​

Large relays almost always restart waiting runners at a cutoff time, so a team whose incoming runner is very late isn't left standing indefinitely. Manager supports this at the event level with a per-class override — the same shape as the mass start:

  • Set it once for the whole event. On the event's Relay tab, switch on Restart and set a Restart time. Every relay class inherits it, so a single cutoff applied to the whole field takes one setting.

  • Override or opt out per class. In Edit Class, a relay class can either switch on Restart and set its own Restart time (which wins over the event restart) or, when it has no restart of its own, switch on "Exclude this class from the event restart" so it never restarts even though the event does — useful for an elite class you want to leave running. A class with neither shows the inherited event time it will use.

  • At the effective restart time R, every runner still waiting starts together. A leg's start is therefore whichever is earlier: its normal changeover, or the restart. In the maths, start_i = min(changeover_i, R).

  • The team's official total is the sum of its leg times, each leg timed from its own start (a restarted leg from R, not from the late changeover). When every changeover was normal this is exactly finish-minus-mass-start. When a leg was restarted it is larger than the wall-clock finish-minus-mass-start — because the restarted runner overlapped the still-out incoming runner, and the sum-of-legs counts that runner's full time on course, which the wall clock would otherwise hide. This is the whole reason the total is summed from the legs rather than read off the finish clock.

    Worked example. Mass start 10:00. Leg 1 runs 10:00→10:30 (30 min); leg 2 runs 10:30→12:30 (2 h); leg 3's runner is still waiting at the 12:00 restart (leg 2 hasn't arrived), so they start at 12:00 and run to 13:00 (1 h). Team total = 30 min + 2 h + 1 h = 3 h 30 min — not the 3 h you'd read straight off the 10:00→13:00 finish clock, because leg 3 and leg 2 were on course together between 12:00 and 12:30.

Declaring or changing a restart time — at either level — immediately recomputes every affected team — you don't need to re-download anything.

Note: A restart time that is at or before the class mass start can't be applied (it would put a waiting runner before the start) — Manager ignores it and logs a warning. If a restart you set has no visible effect, check that its time is genuinely after the class mass start and that the class actually has a resolvable mass start.

Warning: Live ordering of teams while a restart is in effect is approximate — the live ranking compares wall-clock punch times, which a restart deliberately breaks. The finished team totals are exact; only the in-progress ordering of restarted teams is a best-effort estimate.

Building teams (by hand) ​

Open the Relay teams page (in the event's data navigation) and choose Actions → Add team…, or click an existing team's name to edit it. The Add relay team / Edit relay team dialog is laid out like Edit competitor: the team's details on a Details tab, and — once the team exists — a Radio punches tab listing every radio punch its runners have made, earliest first, with the leg and runner each came from. Changes on Details are kept only when you press Save, whichever tab you are on. The Details tab has:

FieldWhat it does
Team NameThe team's name (required).
BibThe team's base start number. Each leg runner's bib is derived from it (see Bibs). Two teams can't share a bib.
ClassThe relay class the team runs in — the picker only offers relay classes. You must pick the class before you can assign runners.
ClubThe team's club (optional).
LegsOne row per leg: the Runner (picked from the competitors in the team's class), plus a Course picker when the class has a course pool and a Variation picker when the chosen course has forks. See Balancing the forks for the check shown under the legs.
Official teamOn by default — "eligible for official placings and awards". Turn off for a composite / out-of-club team that races but shouldn't take an official placing (see Official vs unofficial).
Photo finish — judged orderOnly appears when this team is tied with another on exactly equal totals — drag the tied teams into the judge's finishing order (see Photo finishes).

The number of leg rows follows the class's leg count. You can save a partially-built team — leave a leg's runner unset and fill it in later; the empty slot still holds its leg position.

Note: A runner must be a competitor in the team's class to appear in the Runner picker. Import or add the competitors first, then build the teams.

The unique-runner rule ​

A relay team's members are distinct people: a competitor may run at most one leg, of at most one team.

  • A roster that puts the same runner on two legs is rejected ("The same competitor cannot run more than one leg.").
  • A runner already on another team can't be added to a second — Manager names the clashing team ("Competitor is already a member of another team"). The Runner picker also leaves out anyone already chosen on another leg of the same team.

This is enforced everywhere teams are written — the dialog, and every import path — so a roster that breaks the rule is never saved. Because runners are unique, a runner's position in the roster is their leg number (row 1 = leg 1), with no ambiguity.

Team bibs ​

In a relay event, bibs work top-down from the team:

  • You set the team's base bib (e.g. 42) in the team dialog.
  • Manager derives each leg runner's bib automatically as {teamBib}.{leg} — 42.1, 42.2, 42.3 — and keeps them in sync whenever you change the roster or the base bib. A runner removed from a team has their derived bib cleared.
  • A leg runner's bib is therefore read-only in the Edit Competitor dialog for a relay event. That dialog shows the runner's Relay team panel instead — their team name, leg, bib, and start time — all read-only. To change a relay runner's bib, change the team's bib.
  • To clear a team's bib entirely, empty the Bib field and save; the members' derived bibs clear with it.
  • Numbering a whole field at once. On the Relay teams page, Actions → Assign bibs… gives each relay class a bib range — set Start from, and Reset each class to a round number (or Continuous (no reset)) — and numbers the teams of each class in order from that class's First bib. Teams that already have a bib are left alone unless you tick Overwrite bibs already assigned, and the dialog won't apply while two class ranges overlap or a number is already used by another team.
  • The event-wide bib allocation leaves relay classes alone, because their bibs come from the teams.

When you can edit teams ​

Team editing is for before the start — create teams, assign runners to legs, reorder or clear legs. Mid-race substitutions, reserves, and re-ordering legs after the start are not supported yet (see What isn't supported yet).

To delete a team, open it and use the Delete button in the edit dialog. Actions → Delete all teams… on the Relay teams page removes every team, with its relay result; the runners stay as competitors but lose the bib and leg they took from their team.

Note: Deleting a competitor who sits on a team doesn't delete the team. The leg's runner shows as missing (—) and the team drops back to in-progress — it can't be classified until you repair the roster in Edit relay team.

Importing teams ​

You rarely want to build a full field of teams by hand. Files are imported from the Import dialog (also under Actions → Import… on the Relay teams page) — see Importing event data. What each import route gives you:

From Eventor ​

Where Eventor has team entries, Manager builds the teams from them directly, runners on their legs, and the import summary counts the Relay teams it made.

There is no per-class question during the import: every class it brings in is treated as a relay class, with Eventor's own leg count where Eventor gives one and the event's Default relay legs otherwise, and the import warning names the classes it adjusted. Set any genuine individual side class to Individual in Edit Class afterwards. That choice is remembered: a class you have made Individual stays individual when you re-import, and won't be silently turned back into a relay.

Where runners entered individually, you then form the teams — build them in the team dialog, or, if the entries carry team.leg bibs, re-import them as an IOF entry list so the bib convention assembles them.

From an IOF entry list ​

An IOF entry list that carries team entries is imported as teams: each team with its runners on their legs. Manager reports how many teams it imported, and warns rather than guesses about anything it can't place: a runner entered on two teams (the later team's leg is left empty), a leg naming several runners (parallel legs aren't supported — the first is placed), a runner with no usable leg number, or two teams on one bib.

Importing the same file — or the same Eventor team entries — again rebuilds the teams in its classes rather than adding them twice. The rebuilt teams are exactly what the file says, so changes you made to those teams by hand are replaced: rosters, and a team bib, Official team setting or judged order the file doesn't carry. Make those changes after the last re-import.

The bib convention ​

An entry list with no team entries, in a relay event, is assembled by the bib convention instead: entries whose bibs follow the team.leg pattern (42.1, 42.2, 42.3) are grouped into one team (base bib 42) with the leg numbers taken from the suffix. Manager reports how many teams it assembled, and warns about any malformed group (a lone runner, a gap or duplicate in the leg sequence) rather than stitching runners onto the wrong legs. It's never applied to a class you've marked Individual, whose dotted bibs are just bib numbers. See Entry list import.

From an IOF start list ​

An IOF start list with team starts gives the teams already in the event their bibs, matched by their runners. A relay always starts with the class's mass start, so the leg start times in the file don't change anyone's start.

From an IOF file with no designation step ​

An IOF file import has no class-review step, so in a relay event Manager treats every imported class as a relay class and warns you, naming each adjusted class. Flip any genuine individual side classes back to Individual in the class editor afterwards — the warning tells you exactly which classes to check. (Classes you've already set to Individual stay individual on a re-import.)

Tip: Whichever route you use, glance at the Relay teams page and the import warnings afterward. A missing runner, a wrong leg count, or a class that should have been individual all show up there.

Running the event ​

On the day, each leg is an ordinary card-download and radio-punch flow — with a few relay specifics.

One card per leg; shared and hire cards ​

Each leg runner carries their own card and produces their own download after their leg. Different runners on a team may reuse the same physical card across legs (common with hire cards), so the same card number can appear in several of a team's downloads.

Because a card number isn't unique within a team, Manager can't assign a shared-card download by card number alone. Instead, a runner who already has a download (or a final result) keeps it, and a new read of the same card goes to the next runner on that card who doesn't have one yet — preferring a runner who is still out on course. In practice: read the legs in the order they ran and each download lands on the right runner. If reads arrive out of order, check the assignments and move a download from the download history if needed. See Downloading cards and Hire items.

Radio punches and provisional results ​

Radio punches are tagged to the leg that produced them and feed the live team position. When the final leg's radio finish arrives — before the card is downloaded — the team shows a provisional result (an OK/time marked provisional, the same convention as an individual provisional-OK: no unconfirmed total is published — the results file won't go out until that leg's card is downloaded or the leg runner is set DNF or overtime, and if you publish anyway the leg goes in as DNF with no leg time). The final result replaces it once the leg's card downloads. See Radio punches.

Note: A radio punch carries only its card number, so when several team members share one card, Manager gives a live punch to the member it believes is currently on course. If that guess is ever wrong (unusual leg overlap, a restart), the live picture self-corrects as the cards are downloaded — the downloads are authoritative.

A leg runner's own time ​

A leg runner's stored race time is the team cumulative (time since the mass start) — that's the aggregation model's input. On individual-facing surfaces (the competitor list's race-time column in a relay event) Manager shows the runner's own leg time instead, so a leg-3 runner's column reads their leg, not the whole team's elapsed time.

How relay results are calculated ​

Leg times and the changeover ​

Let S be the class mass start and Fᵢ leg i's finish time of day:

QuantityHow it's computed
Leg 1 timeF₁ − S
Leg i time (i > 1)Fᵢ − Fᵢ₋₁ — from the previous runner's finish (the changeover)
Team totalFₙ − S — equivalently, the sum of all leg times

Because every leg is anchored at the same mass start, these telescope: the leg times always add up to the team total. A restart changes a leg's start to the restart time where that's earlier (above), and the total stays the sum of leg times.

Note: If corrupt or mis-edited data would make a leg's finish land before the previous one, Manager breaks the changeover chain for that leg rather than showing a negative split. A leg time never goes negative on the results. It also raises an alert — "Team … leg … finished before its changeover, so its time cannot be right. The team will not get a result until the leg start or finish time is corrected." — so the team isn't mistaken for one still on course. Correct the leg runner's time and the alert clears.

When a leg fails ​

  • No restart declared: a leg with no finish (DNF/MP) stops the chain — that leg and every leg after it get no time (radio splits may still record). The team can't classify anyway (below).
  • Restart declared: a waiting leg anchors at the restart instead of stalling, so later legs still get times. The team still can't be classified until every leg finishes OK.

Classification and team status ​

  • Team status is the worst of its legs. Any leg MP makes the team MP; any DNF makes the team DNF; the team is OK only when every leg is OK.
  • A team is classified (rankable) only when it has run the full number of legs and every leg is OK. A team missing a leg, or with any non-OK leg, isn't ranked and shows no team total.

Live ranking of in-progress teams ​

While teams are still out, Manager orders them by:

  1. Legs completed (OK finishes) — more is better;
  2. then the furthest shared radio control reached on the current leg;
  3. then the earliest wall-clock time at that control.

This uses only controls the teams genuinely share, so it stays correct under forked legs, and it degrades gracefully when radio coverage is sparse. Finished teams rank by their team total; unclassified teams sink below them.

Note: Relay classes show no projected finish times — not for the team, and not for its leg runners. Don't look for the projected-time column you'd see in an individual class; the live order comes from the shared radio controls instead.

Behind times and split rankings ​

Per-leg behind times and split rankings compare each leg runner only against the same leg at the same control. Because splits are cumulative from the mass start, a split ranking on legs 2+ reflects the team's aggregate position at that control (which team is winning) rather than that runner's isolated leg pace — the right question to ask live. Cross-runner leg-pace comparison ("the fastest third leg of the day") is a post-race analysis Manager doesn't compute today.

Photo finishes (judged order) ​

Where two classified teams finish on exactly equal totals, the chip time can't separate them — IOF rules say the finishing order across the line decides the placing. Record the judge's call in the team dialog: open any of the tied teams, and a Photo finish — judged order section appears listing the tied teams — drag them into the order they crossed the line. Manager then gives them distinct placings in that order. The judged order:

  • can never overrule a faster time — it only breaks an exact tie (the section only appears when a tie exists);
  • survives a start-list import, but not a re-import of the team entries, which rebuilds the teams (see Importing teams);
  • if you don't record one, equal-time teams simply share a placing.

Official and unofficial teams ​

A team with Official team turned off (in Edit relay team) still races, still shows its result, and still sorts by its time — but it takes no official placing and doesn't consume a placing number. Official placings close over it: if an unofficial team would have been 2nd, the next official team is 2nd, not 3rd. Use this for composite or out-of-club teams that run for interest.

Mixed events: relay and individual classes together ​

A relay event may contain both relay classes and ordinary individual classes — an open or enter-on-the-day class run on the same day belongs in the relay event, not a separate one. The rules:

  • Each class is designated Relay or Individual (at Eventor import, or in the class editor).
  • Individual side classes behave exactly like classes in an individual event: editable per-competitor bibs, allocated/imported/punched start times, and eligibility for the start draw (which only ever draws individual classes — it skips relay classes).
  • Exports never mix the two kinds. When you export results, a start list or an entry list — or upload to Eventor — from a mixed event, Manager asks which kind the file should contain (relay or individual). A file only ever holds one kind.
  • On-screen surfaces (Results, Leaderboard, Commentary, the spectator results) happily show both, rendering each class according to its kind.

Where relays appear ​

SurfaceWhat it shows for relays
ResultsOne row per team in each relay class — place, team, club and total time, with provisional results marked * — and the team's runners beneath it: leg number, name, the runner's own Leg time, and the team's time at that changeover. The same rows go into the PDF and the print view. Leg runners never appear as rival individual rows. Group by Course lists individual classes only; read relay classes grouped by class.
Relay teams pageThe working list: Team, Bib, Class, Club, Competitors, Variations, Start time, Last seen, Status, and an optional Official column — columns you can reorder and hide, with class and status filters. Last seen is the team's latest radio punch, shown only while the team still has somewhere to be: once every runner is back (or the team is out of it with nobody left on course) the cell is empty. A runner checking in at the changeover doesn't count until the team's earlier leg has handed over to them. Every punch is on the team's Radio punches tab. The search box finds a team by its name or bib, or by a member's name or leg bib (101.2).
LeaderboardLive team ordering with per-leg finish columns and the team total, rendered from Manager's computed leg data.
CommentaryThe feed follows the teams. A mass start or a restart names the class; radio punches, changeovers and team finishes name the team, with the leg and runner beneath, and place it against the other teams. A class's pop-over shows the relay result table.
Spectator site and kioskClass results show each team with its members (current runner marked ▶), per-leg radio splits and leg finishes; a team still racing shows which leg it's on. The start list is one row per team — bib, team name and its runners in leg order. Official results show a team summary row with its members and total. The analysis graphs compare one relay leg at a time, or All legs pooled.
Result labelsWhen result labels are printed, a relay runner gets the relay layout: their name, team and leg, and their own leg time. See Relay labels.

Not yet supported ​

These are known gaps — plan around them:

  • Mid-race changes. Substituting a runner, adding a reserve, or reordering legs after the start isn't supported. Build and correct teams before the mass start.
  • IOF results import. Manager exports IOF relay results but doesn't import them — you can't rebuild a relay's teams and times from another system's results file.
  • Multi-day / stage relays. A multi-day relay's individual days work normally, but times carried forward between stages aren't modelled.
  • Patrol / group ("Team") events — where members run together with no per-leg changeover — are a separate, not-yet-built scenario. Everything on this page is about ordered-leg relays. (A team that shares one card around loops in any order is supported, as a star relay.)

Common mistakes ​

  • Picked the wrong event type. The type is fixed at creation — you can't convert. Create a new event.
  • A class that should be individual is being treated as a relay. After an IOF file import (or if you missed it at Eventor import), open the class and set it to Individual. The import warning names the classes to check.
  • Can't turn a relay class individual. It still has teams — delete the class's teams first.
  • Editing a relay runner's bib doesn't stick. Relay bibs are derived from the team. Change the team's bib instead.
  • A restart has no effect. Its time must be after the class mass start, and the class must have a resolvable mass start. A restart at/before the mass start is ignored.
  • Teams won't rank. A team is only classified once it has run every leg and all legs are OK — one MP or DNF leg keeps the whole team unranked. The same happens when a team's roster doesn't match the class's leg count (after a leg-count change) or a leg's runner was deleted — repair the roster in Edit relay team.
  • Export refuses / asks which classes. A mixed event can't export both kinds at once — choose relay or individual for the file.
  • Bib assembly warnings on import. Entry-list team assembly needs clean team.leg bibs. A gap, duplicate, or lone runner is reported rather than guessed — fix the bibs and re-import.