Scoring assist and putout combinations

[OhioTex]

Also, I think the GDP (and GTP) for batters is being handled correctly as it is.. it is a sub set of possible fielder DP (TP) credits.. it is restricted to only ground balls and only force/ reverse force plays by rule (plays were runner really had no choice, batter got him). Different from this scenerio2 here were runner took a calculated risk and defense made the play.

Another case when fielders involved in double play but no GDP is short pop to shallow outfield doubles up runner trying to retouch. Eg 8-6 DP. This is not a ground ball nor a force not a for batter, but is a double play for defense..

[TurboAg]

OhioTex, should this thread be moved to the "Issue Reporting" forum to get more FTM attention? I haven't seen any aknowledgement from them on this forum.

[FTMSupport]

We are reading along to see user feedback. For most double plays, everything is handled just fine with our current logic. The "pickle" situation is one where we may need a little more thought. The problem is we do not want to complicate the interface - especially for something that does not come up very often. We will put this issue on our enhancement list and definitely keep fitting it in with all the other priorities.

[PetroGuy]

Since there are always going to be some issues that can't be resolved automatically by the software, I think the idea mentioned upthread for a DP or TP 'wizard' would be a good idea. The normal interface and Quick Outs would still be used the majority of the time, but a DP or TP button could be added to the Quick Outs menu that would let the user specify exactly what happens. The 'wizard' would simply ask where the ball was hit; which runner made the first out and where; who handled the ball to put out this runner; who made the next out and where; who handled the ball to put out this runner (with the fielder holding the ball from the last runner already selected).

This would fit in quite well with the score it as you see it nature of iScore and allow users to 'fix' issues with out order and putout assignments themselves.

[OhioTex]

Like the Wizard idea. nice build on Petroguy..

[TurboAg]

The 2nd most importatnt point of the whole thread is that a DP (or TP) somehow must be credited to the fielders, but not charged to the batter in these scenarios. So, the "wizard" would have to recognize that that it is not a force/reverse force DP and score the stats accordingly.

[bmclaurin]

Here are two workarounds:

1) Record it as you saw it (i.e., 6-3-2-5-1 DP), and then manually edit the stats to move the first putout from F5 to F3.

2) Record the sequence as 6-3-2-5-3-1 DP (note the extra '3' as the next-to-last number in the sequence). All stats (assists, putouts, and DP's) are assigned correctly with no manual editing necessary. In fact, you don't even need to include the first '3' in the sequence in this case because a fielder cannot get more than one assist on the play, but leaving it in there is more reflective of the actual sequence, so I would leave it there. You can add a note to explain what actually happened, although unfortunately the notes don't currently appear on the scorecard...hint-hint, FTM.

I believe the previous poster was correct in that iScore seems to use the last two fielders in the sequence for the putouts in this scenario.

Barry

[Aimee]

The other stat that I question whether it is handled correctly is the RBI when scored as a double play as in the scenario three I posted, see the quoted text. The double play is not a force out or reverse force out - say the third scenario is scored DP6-3-5 where the 3rd basemen tagged out the runner from second after the runner from third scored.

I tried a third scenario as well to see what happens with the RBI stat on the batter if a run scores and scoring it the two ways we're discussing under scenario two. Runners on second and third where the batter grounds out SS to 1st, the runner at third scores, and the runner from second gets caught between 2nd and 3rd. If the play is scored as a double play, the batter is not credited with an RBI, but if scored as two separate outs, the batter is credited with an RBI.

10.04 Runs Batted In
A run batted in is a statistic credited to a batter whose action at bat causes one or more runs to score, as set forth in this Rule 10.04.
(b) The official scorer shall not credit a run batted in
(1) when the batter grounds into a force double play or a reverse-force double play; or
(2) when a fielder is charged with an error because the fielder muffs a throw at first base that would have completed a force double play.
(c) The official scorer's judgment must determine whether a run batted in shall be credited for a run that scores when a fielder holds the ball or throws to a wrong base. Ordinarily, if the runner keeps going, the official scorer should credit a run batted in; if the runner stops and takes off again when the runner notices the misplay, the official scorer should credit the run as scored on a fielder's choice.

[bmclaurin]

Aimee, by rule, BR should be credited with an RBI for the reason you cited (i.e., although a DP, it is not a force DP nor a reverse force DP). You are also correct that iScore does not properly credit an RBI based on my testing of that scenario. Good find. In the meantime, you can obviously manually edit the RBI stat.

Barry

[FTMSupport]

If you do not want the batter to be credited with an RBI use held up at home or on the throw instead of advanced by batter for the reason the rubber was safe at home.