Possible bug (#2)

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Post Reply
Message
Author
User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Possible bug (#2)

#1 Post by xela » Wed Jun 25, 2014 12:03 pm

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])
Like what we're doing? Support us at:
Image

User avatar
PyTom
Ren'Py Creator
Posts: 15893
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Possible bug (#2)

#2 Post by PyTom » Wed Jun 25, 2014 3:38 pm

Can you file this as a bug on the Ren'Py bug tracker?
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug (#2)

#3 Post by xela » Wed Jun 25, 2014 4:04 pm

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.
Like what we're doing? Support us at:
Image

User avatar
xela
Lemma-Class Veteran
Posts: 2481
Joined: Sun Sep 18, 2011 10:13 am
Contact:

Re: Possible bug (#2)

#4 Post by xela » Thu Jun 26, 2014 6:46 am

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).
Like what we're doing? Support us at:
Image

Post Reply

Who is online

Users browsing this forum: No registered users