A few small changes were implemented over the weekend of January 15, 2011:

1. HANDLING OF OUTDATED CHANGES

Starting 1/17/11 if you upload a change file from your software package that proves to be out of sync with the latest packet ID, an alert will appear in the next packet informing you that your changes were not processed. Explanation: it sometimes happens that our members upload changes thinking they are working from the latest packet when in fact they are not. In such cases, the sim does not process the changes (this has always been our policy) leaving team owners to wonder whether their submissions were ever received. We sometimes hear the refrain “my changes didn’t go through.” Almost always this is because someone was not working from the latest packet ID, so we decided to communicate that message back to you so that you can know for certain what happened when your changes are not processed.

2. OUTDATED CHANGES DURING THE TRANSACTIONS SEASON

When a member sends changes based on an outdated packet in the transactions season, the effects can be disastrous. Have you ever thought you signed all your contracts but they were not signed leaving you with an inadequate roster? This can happen when, for example, you sign contracts based on the first transactions event and don’t send them until after the second transaction event takes place. We’ve tried to help in these cases by allowing outdated change files to be processed during the transactions season so long as the incoming roster is an exact match with the roster we have on file.

3. LINEUP BUG FIX

We fixed a bug in the lineup logic. If you had your settings set to drop dead weight from the roster and personnel was actually dropped in a given league event, lineups got messed up because all the roster positions changed. We’ve implemented code to preserve lineups in these cases. Furthermore, if a player in one of your lineups got dropped (e.g., after a trade), you will receive an alert notifying you that your lineup planner has temporarily defaults to sim-generated until such time as you can fix your lineup and clear any diagnostic issues.

Effective with version 6, I wrote a little code that amounts to a small but noteworthy sim change which I realized this week had not yet been announced. I cannot guarantee that the new policy is applied in all cases, but I think it is working well. The change effects starting pitchers who have either shutouts or no-hitters in progress, or both.  Previously the outing of a SP could be interrupted based on fatigue levels or the maximum BFP (batters facing pitcher) setting, or a setup pitcher. I had received notification of concerns from at least two owners that on occasion a great pitching performance was terminated for seemingly no reason. So, for v6 I wrote code to force the SP to keep pitching in these situations. It may still be possible that a setup pitcher enters with a shutout in progress under certain situations. I don't watch enough games to know. But I wanted to put everyone on notice because the maximum BFP setting is no longer a "hard" limit like it once was.

This policy touches on one of the gray areas of simulation in my opinion. Certainly managers these days DO remove their SP after 7 innings even when they are tossing shutouts because nearly everyone has come to fear high pitch counts. It's always difficult to know how to handle these cases, especially since we cover nearly 120 years of baseball history in our sim. I do not necessarily want to start a big debate on this relatively minor issue, but as always you are free to discuss these kinds of things on the forum. If we can find consensus on something as a community it usually stimulates changes down the road as you know.