Quote:
Originally Posted by Green Potato
We're currently breaking it down into scenarios, most of which cause ball numbers to be a non-issue:
1. Nobody does balls: easy.
2. One team does balls: use the API.
3. One team goes high, one low: Still, just use API.
4. Multiple teams go low, 1 or 0 high: Pit scout maximum carrying capacity, make best guess on percent of maximum dumped.
5. Multiple teams go high: This is the tough one. Try to get a good angle, and take your best guess.
|
This is not a bad way to go about it, it is probably the most logical, least amount of work on the end user, and simplest to denote in a form of some sort. it does have quite a few moving parts. The most accurate/least-work way will be to take use the total amount of balls and try to solve the overconstrained system, similar to OPR, but that is never truly accurate as well.
One word of caution, the API sometimes take a few minutes for the match to update, this could cause an annoying backlog of paper slips, complicated implementations utilizing a network link, or editing of data within an app. I would spring for clear communication among the scouting team and use the values that appear on the official score at the end of the match. This always happens prior to the next match and you solve most of the negative points of the API at the cost of another user input.
I am thinking rough multiples of 5 or 10 balls should provide data with a reasonable degree of certainty. the fewer buttons that have to be pushed or tally marks to be made the better. Eyes-on-field = more better.
Regards,
Skye Leake