[Solved] Cycle images with button independant of text

[kde]

I imagine there is a pretty straight forward way to do this that I am just not getting.
Basically I have two images, a zoomed out and zoomed in version and want to have the user click a button to zoom in or out (or hell even a button for zoomed and one for un-zoomed), regardless of the state of the text dialog.

From what I can tell ren'py doesnt seem to have a dedicated thread for separate actions, and before I go writing that type of thing I figure to ask what I am missing.
So far I have tried using defined python functions accessing renpy.show / hide and it sticks images on the layer, but as soon as the conversation passes that screen call I lose access to the textbuttons as interaction objects (the name stays, just no interaction).

The button overlay is a simple screen with two textbuttons:

Code: Select all

screen zoom_out_select():
    vbox:
        textbutton "Zoom" action Show("zoomed")
        textbutton "Normal" action Show("normal")

then two separate scenes for the zoomed / non zoomed screens

Code: Select all

screen zoomed():
    $ renpy.show("z")
    $ renpy.hide("norm")


screen normal():
    $ renpy.show("norm")
    $ renpy.hide("z")

At the moment they are python fragments but have played with using add and calling custom methods. But since I lose functionality of the buttons after a single selection its a bit academic. Anyway mostly I just feel like I am missing a pretty simple trick here so any help is appreciated.

[kivik]

I think we need a little more information, as it's a bit open to interpretation what you're trying to do at the moment. The impression I'm getting is that:

You have an image that's displayed on top of everything (not background image, not part of the scene), and you want to be able to click a button to toggle whether it's zoomed or unzoomed version.

Another interpretation I have is that the image is actually part of the scene (say the background), and you wanted to click a button on the hud that toggles the zoom view of it.

I could be off completely as well! If you can clarify we can suggest how to go about doing it

[kde]

They are separate images, so the idea is just to have clicking the button swap the images entirely with the images being the entirety of the display (not as part of a BG or composite). So calling them background images that get changed would be a suitable analogy.
The main thing I am after though is to have the dialog be separate to the image/button displayed. If it was a repetition or something that wouldn't be a problem I could jump around labels.
Flow idea is:

• Scene loads the Normal image

• Dialog for the label / scenario starts as usual

• Button is loaded as overlay (either toggle capable or two separate buttons)

The Player can then click through the dialog as normal. If they click the zoom button it zooms in without changing or effecting dialog, if they click again (or other button) it returns to normal. At the end of the dialog sequence a new scene is loaded, discarding the current view and layers.
As I say I think I am probably overthinking it but renpy just does some stuff a bit weird to me.

[trooper6]

There are lots of ways to do what you want.

If the image you are wanting to zoom should be the background image, what I'd do is:

1) Create the image as a ConditionSwitch Image, also create an isZoomed variable.
2) Create a screen with a button whose action is to toggle the isZoomed variable.
3) Show the screen.

Let's pretend this image you want to create is a treasure map.
It looks like this:

Code: Select all

image tmap = ConditionSwitch(
    "isZoomed == False", "images/tmap_normal.jpg",
    "True", "images/tmap_zoomed.jpg")

# Define variables
default isZoomed = False

screen zoomtoggle():
    textbutton _("Zoom") action ToggleVariable("isZoomed")

# The game starts here.

label start():
    scene tmap
    show jack at left
    j "look at this cool map behind me!"
    show screen zoomtoggle()
    j "now you can toggle to zoom in if you want!"
    j "test over"
    return

[kivik]

Nice, that's a much better solution that one that I was typing up

Only thing to add is you could add true value and false value to the ToggleValue function: https://www.renpy.org/doc/html/screen_a ... leVariable

This means you could even use a dynamic image without using ConditionSwitch at all.

[trooper6]

That is true kivik. For the OP, that code would look like this:

Code: Select all

image tmap = "images/underpass_[isZoomed].jpg"

# Define variables
default isZoomed = "normal"

screen zoomscreen():
    textbutton _("Zoom") action ToggleVariable("isZoomed", true_value="zoomed", false_value="normal")

# The game starts here.
label start():
    scene tmap
    show jack at left
    j "hello"
    show screen zoomscreen()
    show perry at right
    p "back at you!"
    j "how interesting"
    p "game over"
    return

[kde]

Ah OK, thanks for those will give it a try, looks like I was misunderstanding how the event handler was operating. Appreciate the multiple alternatives, as a coder I am more interested in understanding how its trying to do things than just have a "use this" response. Thanks.

[kivik]

Ah OK, thanks for those will give it a try, looks like I was misunderstanding how the event handler was operating. Appreciate the multiple alternatives, as a coder I am more interested in understanding how its trying to do things than just have a "use this" response. Thanks.

Yeah the control flow with screens can be a bit confusing to the uninitiated - but I think, assuming since your code didn't work - screens only trigger actions based on user input or timers, so the renpy.show() probably didn't get trigger.

The brilliant thing in your case is that images can be dynamically changed by variable changes, so you can solve that. In other situations, you can get the screen to call a function: https://www.renpy.org/doc/html/screen_a ... l#Function

Typically in most other scenarios, you'd just call / jump to a label which would interrupt the current dialogue.


It's really interesting seeing people try out different ways of doing things when they first start - that's one of the reasons I'm currently quite active in the forums as it lets me think about different problems I may encounter down the line.