Hi @rio
Thanks for the suggestion — and good observation that you don't need full McMahon support to cover 80% of the use cases. Adjustable starting points are essentially the missing primitive, and from there McMahon, late-entry compensation and a few other scenarios fall out naturally.
I think it's doable. The main technical wrinkle is that the pairing engines (bbpPairings, py4swiss) won't accept "free" points in the TRF — every point has to be tied to a round result. So under the hood we'd model the bonus as virtual byes inserted before round 1 (e.g. 1.0 bonus = one full-bye round, 0.5 = one half-bye). The user just sees "starting points = X"; the TRF gymnastics happen behind the scenes.
Before I scope this out, a few questions for you (and anyone else following the thread):
- Primary use case — is it McMahon (bonuses by rating band, set before round 1), or is it more about late-entry fairness (giving a player joining at round 3 some points to start from)? Both are doable, but the UX is different and I'd prioritise the one that matters more to you.
- Granularity — would integer bonuses (1, 2, 3 points) be enough for a first version, or do you need half-points (1.5, 2.5)? Integers are noticeably simpler to implement.
- Tiebreaks — in your tournaments, should the virtual bonus rounds count toward Buchholz and similar tiebreaks, or be ignored? Standard McMahon convention is to ignore them (only real opponents count), but I want to confirm before coding.
- Real examples — could you share 1–2 concrete tournaments where this would have helped? Even a rough description (number of players, rounds, how you'd have assigned bonuses) is enough. I'd use them as test cases to make sure the implementation actually solves the problem rather than something I imagined the problem to be.
Once I have answers I can give you a more concrete timeline. Thanks again for the well-thought-out request.