Ren'Py Jump and navigation issues.

[9thCrux]

I'm having troubles using Jump to build a navigation system, let me try to explain:

Lets say that an option in a dialog menu sends me to navigate a hallway, a screen I have previously made with a background and imagebuttons that send me to other screens just like the previously mentioned hallway, the text menu seems to work as intended; I have the option to go to the hallway...

But as soon as I click to go to the hallway the screen just blinks and throws me back to the main code.

What can I do to make the screen stay and wait for the player to click on an imagebutton, to make the screen wait for input?

The screen instructions are just:
-add image (background).
-imagebuttons (doors) .

When I use call instead of jump the screen stays in place but when I use jump seems like Ren'Py displays the background and imagebuttons but instantly moves to what is next in the main code.

An example of what I'm trying to do would be a point-and-click game in which you move between rooms by clicking on doors.

Is kind of confusing, do I need to make a screen within a label to call the label so the screen stays? Not sure what to do...

 

[Porcus Dev]

What can I do to make the screen stay and wait for the player to click on an imagebutton, to make the screen wait for input?

Use "modal" to prevent the player from clicking off the screen

sceen my_nav_screen:
    modal True
    ....

 

[anne O'nymous]

When I use call instead of jump the screen stays in place but when I use jump seems like Ren'Py displays the background and imagebuttons but instantly moves to what is next in the main code.

Hm... Do you show the screen, or do you call it ?

 

[79flavors]

It sounds like you need to use both call screen and modal True, as both replies already say.

modal to make THIS screen be the only game UI element the user can click on right now...
... and call for much the same reason. (show just puts the screen on the screen and leaves it there)

In my limited experience any "I need the user to click something now"... is call screen. I can't really think of any examples where you WOULDN'T code that with modal True.

Any "Put this on the screen and the user can click on it anytime they like (or never)" is show screen.

Not that I'm adding much to the potential solutions here... just stating things in a different way.

 

[9thCrux]

Hm... Do you show the screen, or do you call it ?

In the current navigation system in my game I use call to call the navigation system from the main label or main code.
And I use show withing the navigation system to move between screens or locations.
By the way, I use hide to get rid of the previous screen when moving to a new one.

 

[79flavors]

show for navigation would be more like an open world game where there are icons along the bottom of screen to pick which room to go to next. The actual icons would be a screen of their own, displayed using show.

You'd show those naviation buttons/tiles pretty early on and just leave them there for the majority of the rest of the game.

That doesn't sound like the solution you're going for... hence my thought that you might be wanting call screen throughout.

 

[9thCrux]

It sounds like you need to use both call screen and modal True, as both replies already say.

modal to make THIS screen be the only game UI element the user can click on right now...
... and call for much the same reason. (show just puts the screen on the screen and leaves it there)

In my limited experience any "I need the user to click something now"... is call screen. I can't really think of any examples where you WOULDN'T code that with modal True.

Any "Put this on the screen and the user can click on it anytime they like (or never)" is show screen.

Not that I'm adding much to the potential solutions here... just stating things in a different way.

Damn, almost every time I see your replies I learn or understand more about Ren'Py. Thank you!

I'm going for a sandbox game where players can do repeatable events to boost stats, so is like having a main story and free-roam that eventually lead to story progression.

I may be wrong but if I use call is Ren'Py going to need a return statement later on?

I quoted this from one of your posts:

"jump is "go somewhere, never come back". Control passes to wherever you've told it to jump to.

call is "go somewhere, come back if you ever encounter a return statement". Control passes to wherever you've told it
to "call" and behaves just like a jump... unless it runs into a return statement - in which case control passes back to
wherever the call was made from."

Every time you use call, it adds the current program location to what I think of as a call stack. Every time it runs
into a return, it pulls the latest entry off the call stack and goes there. It's the reason you can put calls within
calls and create all sorts of levels of complexity. It's also the reason why not including a return statement where
you planned to can lead to all sort of really bizarre shit happening that's really difficult to keep straight
in your head. Not least, because the last thing RenPy does as you finish your game is return to the core RenPy code...
Anything left outstanding on the call stack... and things will get more than a little confusing."

 

[anne O'nymous]

I may be wrong but if I use call is Ren'Py going to need a return statement later on?

He (and also me) don't talk about call but about call screen, which is something totally different.

show screen display the screen, then pass the control to the next statement in the label, while call screen display the screen, then wait that the screen return to the label, before passing to the next statement.

 

[79flavors]

I may be wrong but if I use call is Ren'Py going to need a return statement later on?

Yeah. great ain't it. And confusing.

I'm sure there's some logic to it... but call screen doesn't require an explicit return.
And since that screen may include actions including jump is sounds even worse.

But that's how it is. They are entirely different beasts.

When you're calling a label - you need a return statement. With a screen, you don't. (Maybe RenPy is handling it for you?).

I figure that without actions within the screen (and definitely modal), that screen would just return to the line of code after the call screen statement. Or at least, that's how my limited brain copes with it... Because yeah... that the syntax is call without return makes my head hurt. Just count it as an exception to the rule and pretend you never gave it a second thought.

 

[anne O'nymous]

When you're calling a label - you need a return statement. With a screen, you don't. (Maybe RenPy is handling it for you?).

It's simpler than that... (Mwahaha as if) call screen don't change the flow of the code. You were in "start:21", you'll stay in "start:21" until the moment the screen will be closed.

Because yeah... that the syntax is call without return makes my head hurt.

Technically there's a return, since call screen is initially designed to works like this :

screen myCalled():
    vbox:
        textbutton "Choose this" action Return( "this" )
        textbutton "Choose that" action Return( "that" )

label whatever:
    call screen myCalled
    if _return == "this":
        "You chose this"
    else:
        "You chose that"

But effectively it can also works without return if you Jump from it ; but if you Call from it, then there's still a return somewhere :

screen myCalled():
    vbox:
        textbutton "Call there (click first)" action Call( "there" )
        textbutton "Jump here" action Jump( "here" )


label start:
    call screen myCalled
    "Try again"
    call screen myCalled

label there:
    "You are there, but you'll return where you were."
    return

label here:
    "And now you're here."
    "And it's the end."
    return    # <- This will end the game

 

[9thCrux]

He (and also me) don't talk about call but about call screen, which is something totally different.

show screen display the screen, then pass the control to the next statement in the label, while call screen display the screen, then wait that the screen return to the label, before passing to the next statement.

Seems like that is part of my confusion, for what you describe seems like I should use show screen to have the background image displayed and also execute additional instructions within the same label; like dialogs, variables checks/changes and more.

Yeah. great ain't it. And confusing.

I'm sure there's some logic to it... but call screen doesn't require an explicit return.
And since that screen may include actions including jump is sounds even worse.

But that's how it is. They are entirely different beasts.

When you're calling a label - you need a return statement. With a screen, you don't. (Maybe RenPy is handling it for you?).

I figure that without actions within the screen (and definitely modal), that screen would just return to the line of code after the call screen statement. Or at least, that's how my limited brain copes with it... Because yeah... that the syntax is call without return makes my head hurt. Just count it as an exception to the rule and pretend you never gave it a second thought.

I see, call screen doesn't really need a return statement.
It seems like a real pain to try to keep track of a logical path when using more branching code within a call or call screen statement...

I need to remember to use modal...

I think is better to use label because you close it and return to a main path, sort of saying.

And I agree; Ren'Py branching is making my head hurt.

 

[79flavors]

[...] seems like I should use show screen to have the background image displayed and also execute additional instructions within the same label; like dialogs, variables checks/changes and more.

Think of show as being something which is permanently added to the screen until you remove (hide) it.

So if you had a row of navigation buttons (or arrows, or whatever) - those would be their own screen, added as an overlay to the whatever background you're currently showing.
So when you enter the area where those buttons are needed, you'd do your usual scene to display the background image and then do show "navigation screen". You can do more and more scene's to change the onscreen primary image. A new scene doesn't remove the navigation panel you added with show.

In an open world game - that navigation panel would be shown on the screen very early on within the game and just left there.

If you were doing more of a maze like navigation, I would expect that to be more likely to done using call / modal True.

If that makes any sense?

And I agree; Ren'Py branching is making my head hurt.

Just pretend call screen doesn't feature the word "call". It gets much simpler to think about when you can separate screens and labels in your head when thinking about branching logic. I tend to think of "call screen" as more of a jump - but that's how I've primarily used it in linear games.

Even with an open world game, you can still use call / modal True.
Just think of each screen as a room. You display the whole screen using "call screen" and that screen includes imagebuttons (doors). Each imagebutton jumps to a new label (a new room).
So you end up with something like: (untested code).

EDITED to reflect Ann's idea about using action Return()

Spoiler: Using action Jump()

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

Spoiler: Using action Return()

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

The reason I use the scene to show the background image rather than including the background image within the screen definition is because I probably want to display some lines of dialogue, etc BEFORE the player gets the option to click on any of the doors. This way, they can only move to another room after I let them (by using call screen.

I'm effectively just making a big maze.