Warrior General Games

First of all, I'm not watching this in Flash. I'm watching in 20 FPS.

http://goallineblitz.com/game/replay.pl?game_id=1250394&pbp_id=7198402

It says it is 3rd & 6.5 from the opponent 48.5.

When the QB takes the SG snap in the backfield, he's catching the ball at the 48.5 (not snapping it from there), which is totally wrong. That puts the 1st down marker in the wrong spot, b/c he just about got to the marker, but was actually 4 yards short.

Has it always down this out of SG and I never noticed?

Either replay format is fine here. The issue is that the LOS is the opponent 48.5 and not the own 48.5. It just so happens that the Center is on the LOS at the opponent's 48.5, and the QB is standing on his own 48.5 at the start of the play. See what I mean?

Originally posted by VolBrian
Either replay format is fine here. The issue is that the LOS is the opponent 48.5 and not the own 48.5. It just so happens that the Center is on the LOS at the opponent's 48.5, and the QB is standing on his own 48.5 at the start of the play. See what I mean?

Totally get you. But shouldn't the 1st down marker then be at the 42 instead of the 44.5?

Yes, you're correct about that. I didn't even notice.

This is not a bug. It is a known issue that the first down marker is not always correct and may be off by a few yards on several replays. Although it may not be visually pleasing it is a known and accepted visual error.

http://goallineblitz.com/game/forum_thread.pl?thread_id=3766002&page=2#33720745

Originally posted by Catch22
Per Bort:

This is probably not fixable without changing the way data is stored and outputted, or without some sort of fudge to change the way the javascript figures out the LOS. It is estimated based on the first frame of the ball and the "to go" value.


It's a limitation in how the first down marker is done - it's hacked on by the replay engine, not provided directly from the sim data generation.

Marking not a bug first verification.

I have to agree with Nib here, nice researching

If we see the line too far away from where it should be, we'll look into it. For now, its an issue, but not a bug, and giving a second verification to reflect that.