jonesguy14 / footballcoach

Android App for playing/simulating/recruiting as a college football coach
Other
34 stars 8 forks source link

Game Log Always Reports Passing TDs as Happening on 1st Down #36

Closed destilla closed 8 years ago

destilla commented 8 years ago

I caught an OT game doing something weird: It reported that on 1st and 10 from the 77 a team threw a touchdown pass.

That has to be impossible though, because the lowest yardline you can have be a 1st down in OT is 85 (we start at the 75 and there are no ways to get a 1st other than gain 10 yards)

I checked a few more and saw that they were happening with passing touchdowns and usually it was if a TD happened on first down. I wrote a quick play by play debugger to show me what was happening on each play and run a few weeks to check OT. I figured I broke something about overtime.

The play by play debugger calls a modified version of getEventPrefix (less breaklines) at the top of runPlay(), and then reports on how many yards were gained, how much time ran, and the new getEventPrefix at the bottom of runPlay(). This is what I got:

image

The part circled in blue is what you would see without the debugger there. So here's what you're looking at:

On first down, Cal gains 0 yards. The debugger reports Cal gained 0 yards and that the new down and distance is 2nd and 10 from the 75.

Second down. Cal throws a TD. getEventPrefix reports that on 1st and 10 from the 75 Cal threw a 25 yard TD.

I checked other OT games to be sure and found stuff like this

image

By color:

Black: 3rd and 9 on the 89, Det gains 2 yards.

Red: Debugger confirms its 4th and 7 from the 91

Blue: gameEventPrefix reports that Det scored a 9 yard TD on 1st and Goal.


Anyway I'm pretty sure I found the culprit -- When a passing play happens, regardless of whether or not a TD is scored, passingPlay() checks to see if the yards gained are more than the yards needed, and sets the down and distance to 1st and 10.

Then, after the XP is kicked, the score is added to the game log with getEventPrefix(). By then, the down and distance have already been set to 1st and 10, so it reports that the TD happened on 1st and 10 (or Goal).

destilla commented 8 years ago

I just wrote a novel for probably like 2 lines of code, but I have my gf coming over in a bit and need to make my place less bachelor-y, so I can't take care of it right now (And also I am too verbose....and also I like to justify my findings)

If it's still up later I'll put in a fix and test it.

Also I left in the line that forces OT by mistake. So...woops.

jonesguy14 commented 8 years ago

Wow, looks like you are right again. Just ran some games on my phone that still has 1.21 on it and the same problem occurs: any passing touchdown that is greater than 10 yards (i.e. wasn't X and Goal) is recorded in the game log as being thrown on first down. I never noticed before but there was a game just now where the ALA QB threw 11 TDs, and literally every single one was on first down. So yes, this is a problem lol.

I may be able to take a look at this tomorrow but Easter weekend is busy for me. But I appreciate your keen eye yet again!

jonesguy14 commented 8 years ago

Pretty confident this commit fixed it: 85eca4087bc83b299d3c4eb4b20036a2efb7d204

Am unable to test right now, but basically I added this line: if ( gameYardsNeed <= 0 && !gotTD ) { // Only set new down and distance if there wasn't a TD gameDown = 1; gameYardsNeed = 10; }

Like you said it was a simple fix but is hard to spot so thanks again! I also removed the line that would always set scores equal for testing OT.

jonesguy14 commented 8 years ago

I was looking at the code again because I thought it might be a problem for rushing too, and I think there was since I was doing the same thing, just rushing TDs for >10 yards are much more rare.

So I ended up looking at that and realizing that my last commit didn't fix the problem since it would do gameDown++ even it a TD was scored, so all the TDs would probably be on 2nd down instead.

This commit fixed it for real (hopefully): e92b213ddf9f1e2872895c80530f67b36ba14a44

Again I haven't tested it but just wanted to get it out, I think the problem should be resolved now. Basically I only did the gameDown checking if a TD or fumble didn't happen, so the log for TDs/fumbles would hopefully be on the correct down now.

destilla commented 8 years ago

Haha, well I can only take so much credit for the keen eye. I completely missed it too, until the overtime scenarios I was faced with were presenting me impossible situations (a team got sacked 3 times and then on first and 10 threw a 29 yard touchdown from the 71 in OT....what...lets check the code). From there it's just stepping through what's going on.

I checked out the code in your commit, and it looked like it should fix things. But to be sure I added the play by play debugger locally and took a look at it a few game logs (* SCORING PLAY * is getEventPrefix() + score log ):

image

Passing looks good.

image

Rushing looks good! Good fix!

Weekends are busy for me too, I basically get an hour or so Saturday mornings, and a little time Sunday night. If I do anything exciting though, I'll fill you and share the code.

Have a great Easter! I hope whatever you enjoy whatever your plans are go well and that it's a relaxing weekend.

jonesguy14 commented 8 years ago

Fixed with commit e92b213ddf9f1e2872895c80530f67b36ba14a44