Page 1 of 1

Possible bug (#2)

Posted: Wed Jun 25, 2014 12:03 pm
by xela
I never worked with drag&drop before other than using a slightly modified version of puzzle from cookbook. Maybe it's expected behavior and I am just missing a setting somewhere.

The problem is this:

1) Show the drag screen.
2) Drag the picture to any coordinate and drop it, it will be restored (to coords) by the snap method.
3) Hide the drag screen.
4) Show the drag screen:
- The picture appears where it was previously dropped instead of it's last position where it was moved by the snap method (which is really annoying). I am fairly certain that I know how to beat this dropping the screen language (so I don't ask for a workaround, unless it's something obvious) but if this is a bug that can be fixed with the next release or a setting ignored, I would rather stick with the code in use now (combo of Python classes and Ren'Py Screen Language) because it's very readable and convenient.

Code: Select all

init python:
    coords = (20, 20)
    def dragged(drags, drop):
        if not drop:
            drags[0].snap(coords[0], coords[1], delay=0.2)
            return
        return True
        
screen buttons:
    vbox:
        align (0.5, 0.8)
        textbutton "Show":
            action Show("drag")
        textbutton "Hide":
            action Hide("drag")
    
screen drag:
    drag:
        drag_name "None"
        child im.Scale("anyimage", 50, 50)
        droppable False
        dragged dragged
        pos (coords[0], coords[1])

Re: Possible bug (#2)

Posted: Wed Jun 25, 2014 3:38 pm
by PyTom
Can you file this as a bug on the Ren'Py bug tracker?

Re: Possible bug (#2)

Posted: Wed Jun 25, 2014 4:04 pm
by xela
PyTom wrote:Can you file this as a bug on the Ren'Py bug tracker?
I think I just did (assuming that the most recent bug tracking is at GitHub). Anyway, there is another more serious issue I am trying to trace down right now (coord thing is more of an annoyance really). The new one causes Ren'Py to freeze as if it was locked in an infinite loop but it could just as easy by one of my own classes.

Re: Possible bug (#2)

Posted: Thu Jun 26, 2014 6:46 am
by xela
Just found out that putting a drag inside of any group solves this issue so this is not worth fixing as long as there are any other bugs around! My setup is working perfectly now aside from creating new drags while a screen is active doesn't seem to be updating a screen (side-effects I guess) but it's in no way an issue either (nothing that restarting interaction can't fix).