Adrenaline Icon

Running Ad-Hoc Races

Test your TrackLang-built tracks instantly by running ad-hoc races directly from the Track Developer. Build a track, deploy it to your phone, and race with friends in minutes—no full event setup required. Perfect for rapid iteration, testing track geometry, and validating timing configurations before publishing tracks publicly.

What Are Ad-Hoc Races?

Ad-hoc races are quick, informal races you run directly from the Track Developer to test tracks you're building. They're similar to Basic Races but integrated into the track development workflow—perfect for validating your TrackLang code before making tracks public.

Key Characteristics

  • Run directly from Track Developer—no event creation needed
  • Deploy track to your mobile device via QR code or URL
  • Invite friends to join via phone (similar to Basic Race workflow)
  • Test timing zones, finish line detection, and track geometry in real-time
  • Results are informal (not stored permanently like official events)
  • Iterate quickly: race, spot issues, tweak TrackLang, race again

Ad-Hoc vs. Basic Race: Both are informal, non-rated races. The difference is context: Basic Races are run from event pages for casual competition. Ad-Hoc Races are run from Track Developer for track testing.

When to Use Ad-Hoc Races

  • Testing new tracks: Validate TrackLang geometry, timing zones, and finish line positioning
  • Iterating on designs: Make changes to TrackLang, redeploy, and test immediately
  • Verifying timing accuracy: Ensure lap detection works correctly with your track layout
  • Previewing before publishing: Test tracks with friends before making them available to the public
  • Training & demos: Show others how your track works without creating a full event
  • Proving track functionality: Demonstrate that your TrackLang code produces a working track

How to Run an Ad-Hoc Race

Step 1: Build Your Track in Track Developer

Create or edit a track using TrackLang:

  1. Open the Track Developer
  2. Write TrackLang code defining your track's start/finish, timing zones, and geometry
  3. Preview the track on the map to verify layout
  4. Save your track (even if it's a draft/work-in-progress)

Step 2: Initiate Ad-Hoc Race

From the Track Developer interface:

  1. Look for "Run Ad-Hoc Race" or "Test Track" button
  2. Click to start the ad-hoc race session
  3. Track is prepared for deployment to mobile devices

Step 3: Deploy to Mobile

Get the track onto your phone (and friends' phones):

  • QR Code: Scan QR code displayed in Track Developer to open race on your mobile device
  • Direct URL: Copy race URL and open in mobile browser
  • Share with friends: Friends scan the same QR code or use the link to join

Step 4: Race on Mobile

Once everyone has joined on their phones:

  1. Enter rider names/numbers (simple registration)
  2. Start automated timing on each device
  3. Race like you would in a Basic Race—ride the track, cross timing zones
  4. View live results as riders complete laps
  5. Finish race when testing is complete

Step 5: Review & Iterate

After the race:

  • Check if lap detection worked correctly
  • Verify finish line was properly triggered
  • Identify any timing zone issues (missed crossings, false triggers, etc.)
  • Return to Track Developer and adjust TrackLang code
  • Run another ad-hoc race to test changes

Ad-Hoc Race Workflow

Typical Development Cycle

  1. Write TrackLang: Define track geometry, timing zones, start/finish
  2. Preview: Check track layout on map
  3. Run ad-hoc race: Deploy to phone, race with friends
  4. Identify issues: Missed laps? Wrong finish line? Timing zone too wide?
  5. Fix TrackLang: Adjust coordinates, zone radii, or finish line position
  6. Repeat: Run another ad-hoc race to verify fixes
  7. Publish: When track works perfectly, publish it for public use

Iteration speed: Ad-hoc races enable rapid testing. You can go from "spot problem" to "fix code" to "test again" in minutes, making track development much faster.

What to Test During Ad-Hoc Races

Finish Line Detection

The most critical test. Does crossing the finish line properly trigger lap completion? If not, adjust finish line coordinates or radius in TrackLang.

Timing Zone Coverage

Ensure timing zones capture riders as they pass. Too small = missed crossings. Too large = false triggers. Test by riding and checking live data.

Timing Accuracy

Verify timing positions align with actual track layout. Poor location accuracy can cause missed zones even if TrackLang is correct. Test in various weather/tree cover conditions.

Lap Counting Logic

Does the system correctly count laps? Test with multiple laps to ensure consistent lap detection every time a rider completes a circuit.

Multi-Rider Scenarios

Test with multiple riders to ensure the track handles concurrent racers. Check for interference or missed detections when riders are close together.

Track Geometry

Visually confirm track shape matches expectations. Does the map display accurately represent the actual riding surface?

Differences from Basic Races

Similarities

  • Both are informal, non-rated races
  • Both use mobile devices for automated timing
  • Both support multiple riders
  • Neither affects rider Elo ratings
  • Both provide live timing and results

Differences

  • Launch context: Ad-hoc races start from Track Developer; Basic Races start from event pages
  • Purpose: Ad-hoc = testing/development; Basic = casual racing
  • Track status: Ad-hoc can use unpublished/draft tracks; Basic uses published tracks only
  • Results persistence: Ad-hoc results may be temporary; Basic Race results might be saved (implementation-dependent)
  • Iteration workflow: Ad-hoc is designed for rapid code-test-fix cycles; Basic is for one-time casual races

Best Practices for Ad-Hoc Testing

  • Test with friends: Multiple riders reveal issues you might miss solo testing (zone congestion, concurrent lap detection, etc.)
  • Ride the full track: Don't skip sections. Every part of the track needs timing validation.
  • Test at race speed: Timing behavior differs at walking speed vs. racing speed. Test realistically.
  • Document issues: Note GPS coords where problems occur so you can adjust TrackLang precisely
  • Test in various conditions: Tree cover, buildings, and weather affect location accuracy. Test when/where races will actually happen.
  • Multiple laps: Always test at least 2-3 laps to confirm lap detection is consistent
  • Edge cases: Test scenarios like DNF, starting late, or riding backwards to ensure robust behavior

Troubleshooting Common Issues

Finish line not triggering

Symptoms: Riders cross finish line but lap doesn't complete

Fixes:

  • Increase finish line zone radius in TrackLang
  • Verify finish line coordinates match actual track start/finish
  • Check location accuracy on device—poor signal can cause missed detection

Laps counted incorrectly

Symptoms: Extra laps recorded, or laps not counted

Fixes:

  • Timing zones too close together—separate them more in TrackLang
  • Finish line zone too large—riders trigger it from wrong part of track
  • Location drift—test in better conditions or adjust zone sizes

Mobile device can't join race

Symptoms: QR code or URL doesn't load on phone

Fixes:

  • Ensure mobile device is connected to internet
  • Verify QR code is scanned correctly (try manual URL entry)
  • Check if ad-hoc race session is still active (sessions may timeout)

Track geometry doesn't match real track

Symptoms: Map shows track in wrong place or shape

Fixes:

  • Verify TrackLang coordinates are accurate (use GPS coordinates from actual track)
  • Check coordinate format (decimal degrees vs. degrees/minutes/seconds)
  • Ensure proper order of waypoints in TrackLang code

After Testing: Publishing Your Track

Once ad-hoc testing confirms your track works perfectly:

  1. Return to Track Developer
  2. Mark track as "ready for publication" or change status from draft to published
  3. Submit track for review (if required by platform)
  4. Once approved/published, track becomes available for event organizers to use in official races
  5. Monitor feedback from event organizers and riders to identify any issues that only appear in full events

Success indicator: A well-tested track should have zero lap detection issues when used in official events. Ad-hoc testing is how you achieve this confidence.

Common Questions

Can I run ad-hoc races on unpublished tracks?

Yes! That's the whole purpose. Test draft tracks before publishing them.

Do ad-hoc race results count toward rider ratings?

No. Ad-hoc races are non-rated, just like Basic Races. They're for testing, not official competition.

How many people can join an ad-hoc race?

Typically unlimited, but practical limit depends on track size and how many mobile devices you have. Test with at least 2-3 riders for best validation.

Do I need to be at the physical track to run an ad-hoc race?

Yes, for proper testing. Automated timing requires you to physically ride the track. You could theoretically test from elsewhere, but results won't reflect real-world timing behavior.

Can I edit TrackLang while an ad-hoc race is running?

Not recommended. Finish the current race, make edits, then start a new ad-hoc race to test changes. Live editing during a race may cause unpredictable behavior.

Are ad-hoc race results saved?

Usually not permanently. They may be visible during the session but aren't stored long-term like official event results. Ad-hoc races are for testing, not record-keeping.

What if my track works in ad-hoc but fails in real events?

This is rare but can happen due to location variance or different race conditions. If reported, run more ad-hoc races under similar conditions (more riders, different weather, etc.) to reproduce and fix.

Related Topics

Tags
trackdevelopmentad-hocracestesting

Was this information useful?

Help us improve our documentation by rating this article and sharing your feedback.