Front Office Football Central - View Single Post - Groundhog learns Python

Groundhog · 08-14-2014, 06:08 PM

Spent a good 2 hours tracking my first bug last night. It ended up being related to a change I made a few days ago, which was to split all common sequences like screen calculations (success, fouls, etc.), shots, passes, etc. - basically things that will occur in a majority of plays - into their own sections of my sim's loop. This means I need to code them exactly once, and then direct the loop to that sequence when required. I do this using two variables, one is "gamestate" which is a sequence of decimal numbers that is used to point the loop to the correct segment of code. Whenever the loop is sent to one of these other sequences, a variable named "returnstate" is used to point the loop back to the next sequence of the play.

A non-code example of how the loop looks:

Code:

Loop
    1.0 - jump ball
        run jump, set possession
...
    50.0 - pick n roll
        send loop to "101.1" to set common variables 
        for the play then point it to return.
        actions a, b
    50.1 - pick n roll
        actions c, d
        send loop to "103.1" for screen and point it
        to return.
...
    101.1 - common variables
        generate possession-specific variables, then
        return to play.
    103.1 - action the screen/calc fouls
        calculate screen results, then return
        loop to pick n roll.

The bug was to do with a variable named "isopen", which tracks whether the ballhandler is open during the each step of the play. I set the defensive strategy to go under screens, which is supposed to lead to the ballhandler being open for one step of the play. This was working fine, but once I split everything out into it's own gamestate "elif" block, the player was open coming off the screen but, if they attempted the 3, the PbP was displaying a contested shot rather than open.

The issue was that I had a small block of code that checked the defender's reaction to the screen (over, under, etc) that then determined the "isopen" value. With all the cutting/pasting I'd gone through the last couple of days, I'd sliced this function in half, which was resetting the value of "isopen" just prior to calculating the shot. This meant that the ball handler was making the decision to shoot based on the fact that they were open, but the shot itself was being calculated as a contested shot.

08-14-2014, 06:08 PM	#34
Groundhog Coordinator Join Date: Dec 2003 Location: Sydney, Australia	Spent a good 2 hours tracking my first bug last night. It ended up being related to a change I made a few days ago, which was to split all common sequences like screen calculations (success, fouls, etc.), shots, passes, etc. - basically things that will occur in a majority of plays - into their own sections of my sim's loop. This means I need to code them exactly once, and then direct the loop to that sequence when required. I do this using two variables, one is "gamestate" which is a sequence of decimal numbers that is used to point the loop to the correct segment of code. Whenever the loop is sent to one of these other sequences, a variable named "returnstate" is used to point the loop back to the next sequence of the play. A non-code example of how the loop looks: Code: Loop 1.0 - jump ball run jump, set possession ... 50.0 - pick n roll send loop to "101.1" to set common variables for the play then point it to return. actions a, b 50.1 - pick n roll actions c, d send loop to "103.1" for screen and point it to return. ... 101.1 - common variables generate possession-specific variables, then return to play. 103.1 - action the screen/calc fouls calculate screen results, then return loop to pick n roll. The bug was to do with a variable named "isopen", which tracks whether the ballhandler is open during the each step of the play. I set the defensive strategy to go under screens, which is supposed to lead to the ballhandler being open for one step of the play. This was working fine, but once I split everything out into it's own gamestate "elif" block, the player was open coming off the screen but, if they attempted the 3, the PbP was displaying a contested shot rather than open. The issue was that I had a small block of code that checked the defender's reaction to the screen (over, under, etc) that then determined the "isopen" value. With all the cutting/pasting I'd gone through the last couple of days, I'd sliced this function in half, which was resetting the value of "isopen" just prior to calculating the shot. This meant that the ball handler was making the decision to shoot based on the fact that they were open, but the shot itself was being calculated as a contested shot. __________________ Politics, n. Strife of interests masquerading as a contest of principles. --Ambrose Bierce Last edited by Groundhog : 08-14-2014 at 06:10 PM.