Ren'Py Weird Renpy bug in Go minigame

[RandyTyr]

I would like to include the "Go"-minigame from here:

You must be registered to see the links

in my AVN, but I am encountering a weird bug.

When I download the project and use the exe to play the game, it works just fine. However, if I run the scripts from the Renpy-application, then the clicks to place the stones are not properly executed. For many (but not all!) locations, clicking on a location actually places the stone on the location to the north.

Any theories why the compiled game would work, but the individual scripts coming with it not? (Recompiling it myself keeps the bug around).


I've tried looking at the code, but I get a headache from that. Maybe a braver person than I can make sense of it.

 

[anne O'nymous]

Any theories why the compiled game would work, but the individual scripts coming with it not?

Not a theory, a fact based on a quick test: The game is build for Ren'Py 8.x branch, and your game for Ren'Py 6.x/7.x branch.

The issue is that Python 2.x and Python 3.x are incompatible, having different syntax, and sometimes behavior, for the same instruction.

By example, there's this:

    def coord_to_square(coord):
        x, y = coord
        file = int(x / INTERSECTION_LEN)+1
        rank = int(INDEX_MAX - (y / INTERSECTION_LEN))+2 # rank 1 not working?
        if (y > 18*INTERSECTION_LEN): # ^ ugly solution, TODO: clean up later!
            rank = 1
        return file, rank

With Python 2.x, the result of a division of two integers will be an integer rounded to the lowest value. But with Python 3.x, the result will be a float. Therefore, this function will return different values with Ren'Py 6.x/7.x, than with Ren'Py 8.x.
This is still solvable since in both the division will return a float if at least one of the value is a float.

So here, a fix for Python 2.x could be:

    def coord_to_square(coord):
        x, y = coord
        x *= 1.0
        y *= 1.0
        [...]

This force both x and y to become float, and Python 2.x division to return the same value than Python 3.x one.


I haven't really looked at the code, it's just what a quick look shown me. So there's possibly other issues.
But at least you can try to fix all the divisions and look how the game works after this.

 

[RandyTyr]

I had foolishly dismissed that angle based on the age of the game. But I'm indeed running 7.4.1 locally, and divisions being rounded vs not sounds like a very plausible cause for the observed behaviour. I'll try that and report back.

Edit: You were spot-on. Fixing the premature rounding in the rank calculation made the error go away. Many thanks for your help!