[Solved] Show screen and viewport problem

[Kaiza]

Hello! I just spent hours trying to make a screen that conditionally use viewport for images bigger than 1280x720.

Code: Select all

screen event_show:
    
    if img_width > 1280 or img_height > 720:
        button keysym 'K_RETURN' action Return()
        viewport:
            draggable True
            
            add "[image_path]"
                
    else:
        button keysym 'K_RETURN' action Return()
        add "[image_path]" xalign .5 yalign .5

It's pretty simple and "worked" when I tested in a clean environment. When I imported it in my actual game code, it didn't work.

I do know the reason: in the clean environment the screen above was evoked through a call screen statement, where my actual game NEEDS to evoke it through the show screen statement, because otherwise the textbox down below wouldn't appear. I imagine it's a matter of focus, please correct me if I'm wrong. Oh, and I DID try changing from the Enter key to pretty much everything, nothing works in a "shown" screen.

So I thought of splitting it into two different things, a screen for images up till the native size and a screen to use viewport for bigger images. Then I just could assign a custom key that would call the viewport screen.

Example: let's say the player gets to a simple one image, one text event, where the image is bigger than 1280x720. It would by default be evoked thru show screen. The player could then just press that custom key and done: the viewport screen would be evoked thru call screen.

Problem is I have absolutely no idea how to map a custom key with a custom action usable only when events with oversized images are showing.

https://www.renpy.org/doc/html/keymap.html won't really clarify, at least for me, how I do that.

Finally, I came up with a pretty dumb workaround. I added a button that appears on screen when an event with an oversized image is called. The player can just hit that button and it will call a screen with viewport. It works damn well, but it's not really elegant.

I'm not asking for full code, just if I'm simply missing something obvious or if it's even possible. I hope I've been clear since I'm pretty bad with screens and stuff.

Thanks in advance!

[wyverngem]

When do you set your "img_width" variable?

[philat]

...I'm confused. What's the custom key supposed to do? Just close the shown screen? You can use Hide() for that, nothing fancy about it.

[Kaiza]

When do you set your "img_width" variable?

It's set in function and returned to img_width, img_height. I also tested with "[img_width]" before the screen was shown and both variables are working just fine.

...I'm confused. What's the custom key supposed to do? Just close the shown screen? You can use Hide() for that, nothing fancy about it.

To do what my screen button does now: call the specific screen with viewport.

Edit: I felt the need to say that it's pretty to simple to make the game check if the image is bigger and automatically call the viewport, but as I said in the opening post, a called screen takes all focus on screen. That means the text/chatbox won't be seen. So the solution gotta be something the player can actively do to call the viewport. The screen button is alright as I don't really have high standards for the quality of the UI (I'm really bad), but if there's an elegant option, I would love to know about.

[philat]

No, I understand that you don't want to call the screen (other than by having a button). The question is why can't you just show the screen? What specifically doesn't work? I'm asking about the part where you said "nothing works in a shown screen".

[Kaiza]

No, I understand that you don't want to call the screen (other than by having a button). The question is why can't you just show the screen? What specifically doesn't work? I'm asking about the part where you said "nothing works in a shown screen".

Oh, my mistake, then. And thank you for giving this attention.

I don't know exactly why it doesn't work, if I had to guess I would say it's because when you call a screen, it takes all the games focus to itself. Show puts the screen together with everything else.

In anyway, when the screen in the code I provided is called, all of it's functions work. When it's evoked by a show statement, it ignores my condition and, obviously, ignores de "button" statements, since the "K_RETURN" key will advance the textbox in this situation.

It also ignores the viewport entirely, or at least the 'draggable True' statement.

I might be wrong, but I do think this is an expected limitation of a shown screen. I'm OK with that. I just want to, if possible, customize a specific keyboard button to call a specific screen.

[philat]

I don't see why it should ignore the condition. There's really no reason for it to do so as long as img_width/height are being set correctly. Also, it's not really an inherent limitation of shown screens -- it's just that the say screen uses mouse clicks and enter for its own uses (advancing), so it's probably interfering with the viewport controls. Quick and easy way around it is to use modal -- this prevents interaction with any screen other than the modal screen.

The following really should work, although I haven't tested. Let me know if there's anything odd.

Code: Select all

screen event_show:
    modal True # add this

    if img_width > 1280 or img_height > 720:
        # button keysym 'K_RETURN' action Return() # while I've never TRIED button keysym, and it seems like it should work just fine based on the documentation, the simpler and more often used statement is the key statement https://www.renpy.org/doc/html/screens.html#key

        key 'K_RETURN' action Hide("event_show") 
        viewport:
            draggable True
            
            add "[image_path]"
                
    else:
        key 'K_RETURN' action Hide("event_show")
        add "[image_path]" xalign .5 yalign .5

Also, the reason I asked is because calling screens with buttons (i.e., calling screens from within screens with a screen action) is a pain in the ass and better avoided if at all possible. It very often leads to context or save/load issues. You can get around the issues, but it's pretty complex and not really for beginners. This is also why there is no built-in Call() action (as opposed to Show() or Jump() ) even though one would expect it.

[Kaiza]

Thank you very much, this solves everything. I was blind to seeing the Key statement in the docs because I saw the Button statement and assumed it covered everything.

Have a great day!

Edit: I switched the key from 'K_RETURN' to 'K_1' so I could free up the former, but it simply won't allow me to advance the textbox until I hide the screen. Am I missing something?

Edit2: OK. I'm really bad at screens, lol. I solved this new problem by adding Return() after the Hide() action.