Easy to use Offensive Power Rankings (OPR) program for mid-regional scouting

5:42 EST (v2): Updated with more DLLs in the binary zip which will hopefully allow it to work.
6:27 EST (v3): Updated with sorting and a reduction in verbosity.

I’ve spent a bit of time recently cleaning up my offensive power rating code and adding a few new features that I felt would be useful this year. The application is attached, as is the source code.


  1. Automatically downloads current results from usfirst.org, parses them, and outputs the results, with only 3 parameters from the user (which regional, which year, and which statistic you want)
  2. Three statistics: Offensive Power Rating, Defensive Power Rating, and Estimated +/-. The +/- is simply the OPR minus the DPR. It may or may not actually be useful (or correct!).
  3. Easy to use, by my standards. Just double click, enter the parameters it asks for, and it’ll download match results itself. Can also be run from a script with command-line parameters for people that want their statistics automated.
  4. The parsing code is written so it can be used before a regional is complete. Obviously this reduces the accuracy of the outputted stats, and it doesn’t even work before each team has played 2-3 matches. But this can be useful for the friday-evening scouting meeting to pick out diamonds in the rough.


  1. There are people that don’t believe OPR will be useful this year. I disagree with them, but keep that in mind.
  2. OPR does not indicate just a robot’s performance, but a whole team’s performance. If a team has a weak robot but a stellar human player, they might still have a high OPR.
  3. Having a high OPR in this game means very little without also having a low DPR. If you score 80 points in a match but always give away 100, you are not useful to your alliance.
  4. I don’t know how accurate the +/- stuff is, it is a result of me playing around. Hopefully some teams out at regionals right now can compare with their scouting data and give feedback.

A high OPR might indicate:
-A robot that is very effective at getting balls into enemy trailers
-A HP that is very effective at getting balls into enemy trailers
-A robot that does the grunt-work at supplying empty cells so that its alliance can always score a couple super-cells
-Any robot that just ‘greases the wheels’ of its alliance, resulting in higher scores

A low OPR (yes, it can even be negative) might indicate:
-An otherwise good robot that takes a lot of penalties
-A robot that simply doesn’t score much
-A robot impedes its alliance-partner’s progress at scoring

A high DPR might indicate:
-No-shows or broken robots that spend whole matches with a stopped trailer, thus getting filled up
-Robots that tend to get into positions where they get scored on
-Robots that tend to get their alliance partners into positions where they get scored on
-Robots with no auto mode
-Generally, high DPR means low mobility. It is a robot that gets scored on a lot.

A low DPR might indicate:
-A mobile robot that can effectively keep its trailer out of trouble
-A lucky robot

Really, I should have called DPR something else, because a high DPR actually means you’re very bad at defending your trailer.

Without further adieau, the attachments:

OPRNet Source.zip (9.26 KB)
OPRNet - v3.zip (766 KB)
OPRNet Source v3.zip (9.52 KB)

OPRNet Source.zip (9.26 KB)
OPRNet - v3.zip (766 KB)
OPRNet Source v3.zip (9.52 KB)

Sounds interesting. Before I download, what did you compile it with and for what platform (Windows XT I assume)?

Visual Studio 2005, developed on Windows XP, though I’m pretty sure it’ll work on Vista as well. It makes heavy use of Windows API functions for the internet stuff, I think you’ll need the windows SDK to compile it.

I got this error :
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.

Thanks. I have the SDK.


Try grabbing the Visual Studio 2005 redistributable:

I’m going to update the .zip with the DLLs I think are necessary, but I don’t have high hopes.

It appears there is a problem with the manifest for the program. When I viewed the dependencies using Dependency Walker, it provided these errors:

Error: The Side-by-Side configuration information for “c:\documents and settings\1880337\my documents\downloads\OPRNET.EXE” contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

MSVCP80D.DLL and MSVCR80D.DLL seem to be the dlls mentioned by the warnings.

When I googled them, I found several mentions of people getting that error and solving it by selecting the “Embed Manifest” option when compiling. I don’t know whether this correct or relevant.


  • Sam

Edit: Tried installing the redistributable, made no difference.

I think there are two problems:

  1. The .exe I zipped is the debug version, and so looks for debug DLLs that most people won’t have
  2. Some (most?) people won’t have the VS2005 redistributable anyway.

Next time you do this sort of stuff, PM me so I can develop a mac version alongside yours!

I may try to port this one

Most of the math stuff should be easily portable, its just the downloading that is heavily dependent on windows.

Edit: here’s the math library I used.

jama.zip (69.7 KB)

jama.zip (69.7 KB)

Runs on my vista system


Just posted a v3 revision that sorts the output, reduces how much pre-statistic stuff it spews, and fixes a bug where the command-line version would pause for input.

please add a “verbose” option that I can turn off :slight_smile:


Results from Jersey below (go 1923!!) :

OPR     1923    31.6079
OPR     708     29.8004
OPR     25      26.0054
OPR     816     25.0949
OPR     1006    24.1073
OPR     2753    23.9246
OPR     136     23.6915
OPR     1218    22.9299
OPR     223     20.6492
OPR     869     19.7636
DPR     136     32.7112
DPR     11      29.109
DPR     1616    26.7029
DPR     869     26.0814
DPR     223     25.7706
DPR     1048    24.3491
DPR     486     21.5663
DPR     219     20.9251
DPR     1617    20.6711
DPR     2344    20.3672
PlusMinus       1218    24.2442
PlusMinus       1923    22.7624
PlusMinus       102     21.6363
PlusMinus       2753    20.7922
PlusMinus       25      19.8969
PlusMinus       75      16.9573
PlusMinus       708     14.669
PlusMinus       423     14.5928
PlusMinus       816     11.5961
PlusMinus       1366    9.48648

I only listed the top 10, you’ll have to download this cool chunk of code yourself to see the rest.

Also, can you reverse the sort on DPR? (since lower is better, they should be at the top of the list)

great work, thanks.

This is pretty cool. I’m debating whether or not to use this or the matrix system I spent the last couple weeks setting up. I guess depending on the delay, doing it by hand is probably faster though, even if it is a pain. Anyway, seems to work fine on my vista system, and I didn’t have to compile it with the SDK or anything. One question, though. Is it supposed to close after you enter a command after it gives you the requested stats?


you’re supposed to run it from a terminal, so the window doesn’t close.

if you run it from a command line, then you can give it the parameters all at once as well.

I wanted it to pause at the end if the user double-clicked on it. I couldn’t remember the “press any key to continue” API call, so I did it in the poor man’s way:
int a;

My friend and I were talking, and if you use the match points from the opposing alliance in the calculation, you can find the approximate number of points scored ON a robot during matches. Could be useful this year.

That’s the DPR calculation. It can be phrased as “DPR is the average number of points that a team’s presence adds to its opponent’s score.” aka, DPR is the average number of points scored in a robots trailer. It should be lower for highly mobile robots, and very high for no-shows or robots whose strategies or drivetrain tend to get them scored on.