Feature Request: Multiple tracks

[jmslagle]

Howdy! So here's an odd use case.

At our districts, we tend to have enough scouts we run them on 3-4 tracks. We'd want to essentially schedule it as if it were 9 or 12 total lanes, but they run their groups of 3.

I tried to figure out a way to handle this with groups and subgroups, but I can't figure out a way to ensure each scout races each lane at least once doing it, not to mention having to have timers on multiple tracks going at once.

Pie in the sky? My PHP is a bit rusty to try to hack that in myself.

[jeffpiazza]

It turns out this use case (having multiple tracks) really isn't that odd, especially for next-tier (district-level) races.

I've been involved in events in which the racers were partitioned by rank, and e.g. Tigers race on this track, Wolves on that track. That can work as basically two separate DerbyNet instances for events that just happen to be at the same time; some code changes would allow combining results, e.g., so the two instances could share a projector.

I'm not sure I understand the "groups of 3" part of your description. Does a cohort of 3 racers continue to race on the same track, or does each racer end up racing in each lane of each track?

How have you handled this situation in the past?

[jmslagle]

Right now it's all manual using excel and we just use places instead of times.

It's usually 40-60 kids per group (den). If it were simply the case of combining data from the various SQLite instances I could handle that :)

However, the previous guy running this has some giant excel monster that ensures each kid runs on each lane of each track 1 time (So with 4 tracks each kid runs 12 heats - 1 on each lane of the 4 track) and it's staggered out who they run against.

The tracks right now have simple 1, 2, 3 times on them, but I'm sure I could get better timers or switch to a couple 4 lane tracks with real timers on them.

The biggest thing is support in the app for it. I had considered just trying to tell the app I had 9 lanes (if we run 3) but then it's going to expect that all 9 are racing against each other each heat and it'd expect to get timing results from a single timer.

The second one could actually likely be handled with an abstraction layer where you indicated you had X lanes, and then there was a mapping that said these of the X are on the same "track" and run heats across all of them at once.

But it'd be nice to be able to handle this is a better way - even subgrouping the dens and then having each subgroup run each "track" would work, but it looks like the SQL tables ETC are fairly set on a single timer (TimerSettings would need extended to have a TimerID, and there'd likely need to be the concept of a "Track" with a TimerID associated, and then we could schedule a subgroup to each track and tell it each subgroup runs each track? That seems like a decent elegant way?

That make sense at all?