Guys who are forced to the ML squad but are upcoming FAs could be released for the playoff roster.

Available here: http://www.tangotiger.net/bsrexpl.html

The big plus of this will be ensuring that strikeouts are considered more valuable than other outs for pitchers.

Running on different computers can result in different output due to history being stored on one pc but not the other.

This may be solved by allowing configuration of history location and using Dropbox, or maybe by using a Dropbox or Google drive api.

The replacement level is based upon the out dated slot selection method. Update it to something more relevant.

Determine how to use stolen bases as a beneficial tactic.

Possible approach:

• Develop a regression based on stolen base success vs rating
• Work out the break even point given the lineups based on http://www.fangraphs.com/blogs/the-changing-caught-stealing-calculus-2/ (with the important formula being Break Even Rate = 0.590 + 3.33 x (HR/PA))
• Produce a list of players who have the 'green light' to steal.

Expand bullpen selection to use CL/SU slots as well as MR. Also possibly include LR.

Currently selection can be suboptimal when there exists a player with great hitting but has defense slightly worse than the cut off for a position. Modify the defense setup so that defense doesn't have a cut off.

This may require a few different modifications as well, such as how we determine which position gets displayed for a player, and how we determine which slots a player is valid for.

Currently it seems like with some DH lineups there is a better lineup available.

Perhaps this is due to the process for choosing a DH lineup being, selection 8 defenders, then add the best hitter. Sometimes that best hitter becomes part of the defense, when there is actually a player with a better hitting+defense combo for that position on the bench.

Not sure if this is worthwhile yet, but when setting up the bullpen we currently take into account clutch/consistency/duration differently for each slot. Perhaps we should attempt to value a pitcher as MR/SU/CL rather than just MR.

This way we can move on to other tasks while waiting for a page to load.

This probably needs a limited ThreadPool type executor to run the Futures, rather than making a possibly infinite number of page requests at one time.

Look into including scalaz.

https://github.com/scalaz/scalaz

The CaseInsensitive class looks like a good starting point (for text based ratings)

Currently configuring which site is run is set up by editing code. Create a way of doing this that doesn't involve code editing. Perhaps an interactive prompt, with command line overriding possible.

https://github.com/lstephen/ootp-ai/blob/develop/src/main/java/com/ljs/ootp/ai/stats/PitcherOverall.java#L86

https://github.com/lstephen/ootp-ai/blob/develop/src/main/java/com/github/lstephen/ootp/ai/ootp5/site/SinglePlayer.java#L100

At the moment we don't provide diagnostic info (assuming it was something where we should proceed on, for example a TimeOut). Provide better exceptions for those types of errors so that we can fail on the other cases (e.g., an error parsing the page)

Clear the cache before running.

It should be possible to trigger this through an environment variable (e.g., OOTPAI_CACHE_CLEAR)

Simplest strategy: Anyone with a 5 (OOTP6) or A (OOTP5) bunt for hit rating should be given the green light to bunt for a hit.

There are different formulas for each of SP/MR/SU/CL that take into account endurance, consistency, and clutch. The team position report can present pitchers ranked by these.

As a future step perhaps the affect of endurance/consistency/clutch could be separated.

From people's research OOTP may use separate regressions based on if a rating is x. Develop a 'Split Regression' which is effectively two linear regressions.

Perhaps the Real type for calculations. Predictability is probably the most interesting thing to us rather than exactness.

https://github.com/non/spire

Allow configuration for info such as cache location and output directory via environment variables.

The end goal is to allow running through construi and jenkins.

Seems to be outdated.

Instead of hittingWithDefenceScore it should be including a score based on a defensive ratings.

Instead of combining age and size into a single score it should be using a compound ordering

It seems as though clutch ability is favored too strongly.

Develop output that provides info on how the lineup is scored and then tweak to be more reasonable.

They are no long maintained and should not be used for essential functionality.

In cases where a player is forced to the ML roster but is not on the 40 man we wish to release him. In some leagues an immediate release is not possible.

For these leagues we wish to produce rosters that have this player on the ML roster but also produce a list showing which players should be released.

Selection and percentage chosen should be based upon InLineupScore.

Should also be able to remove stuff up choosing a backup by slot, as we should now be able to order the entire bench for each position.

Produce a report that lists the best players by position on the roster. Take into account hitting and defense.

This can not be a simple addition, otherwise position players become more valuable than pitchers.

Perhaps it can be done by calculating an 'average' fielding and then +/- vs late. Then, in theory, the average batter is still worth the same as an average pitcher.

Generate spring training plans for OOTP5 and 6 leagues.

Externalize league config so a new/changed league doesn't require a code change.

Allow configuration of changes files so that a shared location can be used. See #2 for a similar change with history files.

Upgrading from 1.7.x -> 1.8.x causes breaking changes.

We don't have to consider a player as a possible substitution in the line if their best InLineupScore is worse than the worst InLineupScore in the current starters.

Currently an SP with a lower value may be chosen over another because of a higher endurance. Modify value such that it reflects this. Similar to #72 an 'average' endurance may need to be calculated such that an average SP is still worth the same as an average position player.

In the league batting/pitching history we record ratings for players. We can compare players between years to see how ratings change each year. From this model we can see how each rating changes on average each year and produce more accurate predictions for how a player will age/develop.

Instead of using Defense.getPositionRating for the 2nd person on the depth chart we could use that divided by 2 (theory being for the 3rd person to play the first two must both be fatigued).

If this proves successful can investigate bring back the 3rd spot on the depth charts (using Defense.getPositionRating/3). It is unlikely that many 3rd spots would be used.

The mix of positionFactor along with an unweighted defense seems off.

It should probably reuse the same scoring as used in the team position report.

Look into whether it's important that the bench scoring be considered less than starter scoring. I suspect it might be, as the best 25 man roster probably considers lineup + bench score.

This includes investigating whether to make use of sbt or maven.

The advantage of sticking with maven is the already in place migration process. The disadvantage might be less mature support for scala.

Also to be investigated is how reports (such as code coverage) work with scala

Currently uses it's own scoring calculation rather than reusing one.