Ren'Py Modal screen [SOLVED]

[JohnDupont]

Hello, I'm currently using something like this.

label:
    call screen A
 
screen A:
    use screen B
    use screen C

screen C:
    modal True
    button:
        clicked Hide("screen C")

Sadly, I can click through screen C and I don't understand why.

Do you have a solution?

Spoiler: EDIT: I had another problem but I solved it. Try to find my mistake if you want.

You don't have permission to view the spoiler content. Log in or register now.

 

[anne O'nymous]

label:
    call screen A

screen A:
    use screen B
    use screen C

screen C:
    modal True
    button:
        clicked Hide("screen C")

First, the solution to your problem is : move "modal True", from C to A.

But renpy.loadable is a Python statement and it doesn't work in a screen.

renpy.loadable works perfectly fine in a screen.


But all this said, perhaps that, instead of passing by so many trial and error, you could just read the documentation ? It come with the SDK and is located on the doc folder. It will be better than browsing the web and trying outdated solutions that will lead to more errors than anything else.
I mean, I know that you haven't read it, the "clicked" action is depreciated since so many years now, that it was already removed from the doc of the 6.14.0 version released in August 2012.

 

[JohnDupont]

First, the solution to your problem is : move "modal True", from C to A.

It doesn't work, I can click on screen B through screen C. My bad, I guess my explanation wasn't good enough.

renpy.loadable

works perfectly fine in a screen.

Yes, it was my bad.

But all this said, perhaps that, instead of passing by so many trial and error, you could just read the documentation ? It come with the SDK and is located on the doc folder. It will be better than browsing the web and trying outdated solutions that will lead to more errors than anything else.
I mean, I know that you haven't read it, the "clicked" action is depreciated since so many years now, that it was already removed from the doc of the 6.14.0 version released in August 2012.

Despite the doc on renpy.org being the first thing I turn to, I don't always find the solution I'm looking for or even understand everything.
I saw "clicked" somewhere long before I even wrote a line for a Ren'py game. It worked and I couldn't find the difference with "action" on the net, therefore it stucked.

Thanks, Anne.

 

[anne O'nymous]

It doesn't work, I can click on screen B through screen C. My bad, I guess my explanation wasn't good enough.

There's something that I don't understand here. What's the purpose of displaying two (I assume clickable) screens at the same time, if you want one to not be clickable ?
That you have screen B as regular user interface, and want sometimes to have screen C displayed over it, while preventing player to continue clicking on screen B, I can understand it. But the two at the same time goes over my capacity of understanding.

So, the main problem here seem to be more in the design of your code, than anywhere else. Fix the problem at the level where it effectively happen, and it will probably also fix the issue you've with the modal property.

Despite the doc on renpy.org being the first thing I turn to, I don't always find the solution I'm looking for or even understand everything.

Because it's a documentation, not a cookbook. It's meaning is to teach you how to use Ren'py, then if you still can't figure by yourself how to do this or that, it will be time to search. But most of the time, you don't need to search.

I saw "clicked" somewhere long before I even wrote a line for a Ren'py game. It worked and I couldn't find the difference with "action" on the net, therefore it stucked.

Because there's no difference. It's just a change of word, introduced when the "alternate" property appeared. It seem to the author that "action/alternate" was more explicit that "clicked/alternate", since both are the result of a click.
So, technically speaking, both "action" an "clicked" can be used for the same result. But this will last until the PyTom will decide to reworks Ren'py in more depth and remove all the depreciated content. And like he want Ren'py 8 to works with Python 3.x instead of Python 2.x, it's the right time for him to make this big cleaning.

And this is why you should effectively read the documentation, and not just browse it. Whatever if you don't understand the difference. The documentation don't talk anymore of "clicked", so you don't use it anymore yourself.

 

[JohnDupont]

There's something that I don't understand here. What's the purpose of displaying two (I assume clickable) screens at the same time, if you want one to not be clickable ?

Screen C is partly transparent. I want screen B to appear behind screen C.
I probably don't need to use a screen now that I think of it. EDIT: No, I do need screen or I'll have a problem while hovering.

Because it's a documentation, not a cookbook. It's meaning is to teach you how to use Ren'py, then if you still can't figure by yourself how to do this or that, it will be time to search. But most of the time, you don't need to search.

Because there's no difference. It's just a change of word, introduced when the "alternate" property appeared. It seem to the author that "action/alternate" was more explicit that "clicked/alternate", since both are the result of a click.
So, technically speaking, both "action" an "clicked" can be used for the same result. But this will last until the PyTom will decide to reworks Ren'py in more depth and remove all the depreciated content. And like he want Ren'py 8 to works with Python 3.x instead of Python 2.x, it's the right time for him to make this big cleaning.

And this is why you should effectively read the documentation, and not just browse it. Whatever if you don't understand the difference. The documentation don't talk anymore of "clicked", so you don't use it anymore yourself.

You're right: It has been time for me to read the ren'py doc throughly, and probably a lot of Python tutorials too, for a while.

But will I still be modding in 3 months?

 

[Rich]

Because it's a documentation, not a cookbook. It's meaning is to teach you how to use Ren'py, then if you still can't figure by yourself how to do this or that, it will be time to search. But most of the time, you don't need to search.

Phrased differently, what's on renpy.org is a "reference," meaning it tells you all the "what each bit does", not a "tutorial", which would tell you the "how to accomplish your goals using those bits." (And even then, some of the lesser-used items are glossed over. I've had to go to the source code a few times to try to figure stuff out.)

This is, unfortunately, one of the "problems" of the Internet - if you do a search, you'll turn up stuff that's years and years old and which doesn't apply to the current state of Ren'py. (Completely true for a LOT of other software as well.)

Thus, the general recommendation (to anyone who reads this thread, not just you) is that when you get a sample, go back to the current docs and see if all the parts of it are still listed. PyTom is pretty good at removing from the documentation stuff that he doesn't want you to use any more. If you can't find it on the documentation site, then you probably shouldn't use it. (In some cases, he leaves stuff in the tool itself so as not to break existing code, but best not to write new code with undocumented stuff.) He's not quite so good at providing lists of "and this is what you should use instead" in an easy-to-find form. (You have to go search the change logs, which isn't fun.) But few developers like to write documentation. LOL. I've been toying with starting a site devoted to that kind of thing. Depends on whether I get sufficiently inspired...

But will I still be modding in 3 months?

...only The Shadow knows.... Mwaaaaah-haaaaaa-haaaaa

 

[anne O'nymous]

Screen C is partly transparent. I want screen B to appear behind screen C.
I probably don't need to use a screen now that I think of it. EDIT: No, I do need screen or I'll have a problem while hovering.

Honestly, I fail to understand what you try to do ; but it's probably because of me, I have too many things in mind actually. Can't you give a more explicit example than the one you already gave ? At least one that show why screen B is so important and what it should do in accord with screen C.

You're right: It has been time for me to read the ren'py doc throughly, and probably a lot of Python tutorials too, for a while.

But will I still be modding in 3 months?

It depend. Me by example, I modded for Fallout during a year, then stopped, I also modded for this or that for way less time. And now it's more than a year and half that I mod for Ren'py and I don't see me stopping, even if I'm slower actually.
But one thing is sure, if modding mean struggling with Ren'py, then you'll stop fast. Simply because it's not a pleasure to do it. So, giving a try to the documentation can't be a bad thing.

 

[JohnDupont]

Spoiler: Example

You don't have permission to view the spoiler content. Log in or register now.

What I had in mind was: When you call the background screen, the foreground screen appears too.
The foreground screen is modal (to avoid hovering over the background screen) and hides after an action by the user.
The goal is to:
- Make the foreground screen the first the user sees (could be a message for example)
- Keep the background screen in sight (because, first, the thumbnails need some time to load and, second, the background screen is the important screen)

I'm using foreground and background to make things clearer: I divided screen A into multiple screens (including screen B) because it was easier for me to organize.

 

[anne O'nymous]

What I had in mind was: When you call the background screen, the foreground screen appears too.

Among many other possibilities, this one should works (Warning, I wrote it on the fly, I could have made typo):

screen blabla:
    use screen B
    # The whole screen will become a 100% transparent button
    # that do nothing when clicked. So it will intercept all the click 
    # the player attempt to do to the background buttons, while
    # still showing the said background.
    imagebutton:
        idle Solid( "#00000000" )
        xpos 0 ypos 0
        xsize config.screen_width ysize config.screen_height
        action NullAction()
    # Then on top of this, you display the screen C
    use screen C

 

[JohnDupont]

Among many other possibilities, this one should works (Warning, I wrote it on the fly, I could have made typo):

screen blabla:
    use screen B
    # The whole screen will become a 100% transparent button
    # that do nothing when clicked. So it will intercept all the click
    # the player attempt to do to the background buttons, while
    # still showing the said background.
    imagebutton:
        idle Solid( "#00000000" )
        xpos 0 ypos 0
        xsize config.screen_width ysize config.screen_height
        action NullAction()
    # Then on top of this, you display the screen C
    use screen C

Sorry to reply so late, I've been really busy and only tried your solution today.

I found out that action Hide("screen C") doesn't work ; probably because it's used and not shown?
Anyway, I stopped using use screen C and switch to using a variable to make this "screen" disappear. It's seems to work fine.
I'll need to set up how this variable gets reseted to have a better control over how often the "screen" appears. I have a few ideas.

Thank you.

 

[anne O'nymous]

I found out that action Hide("screen C") doesn't work ; probably because it's used and not shown?

Yes.
Used screens aren't at all independent screens, but a full part of the screen that use them. When you have something like this :

screen A:
    use screen B
    use screen C

screen B:
    text "I'm screen B"

screen C:
    text "I'm screen C"

For Renpy it looks like you had :

screen A:
    text "I'm screen B"
    text "I'm screen C"

which lead, like you've discovered it, to let Ren'py think that the screens B and C aren't shown.