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.

Status: Draft — covers current behaviour. A few areas are still evolving (see What isn't supported yet).

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.

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. A small New Event dialog asks the event type:

  • Individual — an ordinary event.
  • Relay — reveals a Number of legs field (default 3, minimum 2). This becomes the default leg count for the relay classes you create; each class can use a different count.

Pick Relay, set the number of legs, 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 import dialog has an event type step of its own. Manager reads the Eventor event form and pre-selects the type — 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 here also asks for the event's default Number of legs.

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. You then mark which classes are actually relays at the class review step — see Importing teams.

The relay settings on the event ​

Open the event details (edit icon on the Event header card) to review two relay-relevant settings:

  • 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.
  • On the Starts tab, the mass-start switch is locked on with the note "Relay events are always mass start." Set the event's Mass Start Time here — any relay class that doesn't have a mass-start time of its own falls back to it (below).
  • Also on the Starts tab, an optional Restart time sets the event-wide restart (omstart). Every relay class inherits it as its restart 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.

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. 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.

Note: Manager does not check that a team runs each fork exactly once across its legs. Balancing the gaffles is the course-setter's job; Manager applies whatever assignment it's given.

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) 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 and Commentary. 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 (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.

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 Starts tab, 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 set its own Restart time (which wins over the event restart) or, when it has no restart of its own, tick "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 Teams page (in the event's data nav) and choose Actions → Add Team, or click an existing team's name to edit it. The Add/Edit Relay Team dialog 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).
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.
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.

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. (An empty bib arriving from a re-import is treated as "no information" and leaves the existing bib untouched — a re-import never wipes a bib you've set.)

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.

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 Team.

Importing teams ​

You rarely want to build a full field of teams by hand. What each import route gives you:

From Eventor ​

When importing from Eventor into a relay event, the class review step lets you mark each class as Relay or Individual ("Mark each class as part of the relay or as an individual side class run alongside it."). This is where you resolve the individually-entered-relay case: even though Eventor sends individual entries, you tell Manager which classes are actually relays. Where Eventor knows a class's leg count, the toggle shows it as a hint ("N legs in Eventor") and the class keeps it; otherwise a class you mark Relay gets the event's default leg count — adjust it per class in the class editor afterwards. 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.

Your per-class choices are remembered across re-imports — a class you marked Individual stays individual when you re-import, and won't be silently turned back into a relay.

From an IOF entry list (the bib convention) ​

An IOF entry list import doesn't yet read structured team entries. Instead Manager assembles teams from the bib convention: 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. See Entry list import.

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 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: the team is exported with that leg overridden to DNF and no leg time, so no unconfirmed total is published). 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.

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 re-imports (an import can't wipe your call);
  • if you don't record one, equal-time teams simply share a placing.

Official and unofficial teams ​

A team marked not official (Edit 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 *. No per-leg breakdown here yet; use the Leaderboard or Commentary for per-leg columns.
Teams pageThe working list: team, bib, class, club, members, start time, radio times, status and the official flag — columns you can reorder and hide.
LeaderboardLive team ordering with per-leg finish columns and the team total, rendered from Manager's computed leg data.
CommentaryTeam classes route to a relay result table; each runner's own splits stay visible in the feed.
Spectator TVA team summary row — the members (current runner highlighted with ▶), and the total; a team still racing shows which leg it's on. (A full per-leg spectator breakdown is still to come.)

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.
  • Structured IOF team entries and start lists. The IOF TeamEntry/TeamStart elements are neither read nor written — team assembly on import relies on the bib convention, and a relay start-list export lists each leg runner individually rather than as team entries.
  • 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.
  • Per-leg breakdown in the Results view. The manager Results page shows one row per team; per-leg columns exist only on the Leaderboard and Commentary tables so far.
  • 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.
  • Full spectator per-leg breakdown and post-race per-leg pace analysis are still to come.

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 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.