Ren'Py Is there a reference list for variables that are passed into predefined renpy screens?

[asahibito]

I am looking for a listing of the variables that are passed into the various renpy screens. For example the variable that is passed in to screen choice as items or the variables passed into screen say as who and what.

Perhaps my google-fu is weak but I just cannot seem to locate such a list. Any help would be much appreciated.

I ultimately want to be able to use those variables in my code directly.

 

[GetOutOfMyLab]

Not sure about an actual listing, but you could always go to the official github for Ren'Py and search the specific screen.

You must be registered to see the links

 

[asahibito]

Not sure about an actual listing, but you could always go to the official github for Ren'Py and search the specific screen.

You must be registered to see the links

View attachment 4070009

View attachment 4070010

Thanks for the pointer to the github.

What I am looking for is the variable that is passed into the screen choice as items not what variables the screen itself has or uses. So basically the variable X when renpy system calls choice(X) during the course of the game. What is the name of the variable X in this case?

 

[gojira667]

So basically the variable X when renpy system calls choice(X) during the course of the game. What is the name of the variable X in this case?

It's in items. Which is an iterable. If it's the first choice it's either items[0] or items[1] depending if menu makes use of a menu caption.

    vbox:
        for i in items:

Typically i.caption will be the menu string unless the dev did their screen from scratch.

 

[79flavors]

If you take a look at the source code for practically any RenPy game, you'll usually find a file called screens.rpy.

Within there, you'll find the majority of the predefined screens. From your post, screen say and screen choices are certainly included.

If you look at both, you'll find code that looks something like:

screen say(who, what):
    style_prefix "say"

    window:
        id "window"

        if who is not None:

            window:
                id "namebox"
                style "namebox"
                text who id "who"

        text what id "what"

# -----------------------------------------------------------

screen choice(items):
    style_prefix "choice"

    vbox:
        for i in items:
            textbutton i.caption action i.action

In both cases, you'll see that the parameters passed to the screen are listed in brackets after the screen name.
screen say(who, what):
screen choice(items):

Each screen is unique, and therefore what is passed to it will be unique. There's no common list of variables used, just the parameters passed along by the underlying functions. The "names" of those variables is local to the screen. I could call a screen with show screen say(my_variable1, my_variable2), but the screen itself would still think the variables are called "who" and "what".

In the case of screen say():, the what and who parameters are passed, and used as plain

You must be registered to see the links

fields.

The screen choices(): is a little more complex, as it is passed an object it knows locally as items, which looks to be a list of other objects. Each item within the list has a caption and an action property (what the RenPy documentation calls "fields"), and the caption is used as a

You must be registered to see the links

. Exactly how you'd know that items is a list and that list has objects which have properties including "caption" and "action" isn't something that will immediately jump out at you without some digging (or documentation).

On the documentation front, there is this from the RenPy documentation:

You must be registered to see the links

Which lays out all the predefined screens and what their parameters (variables) are. Again, remember the names of the variables are just the standard names.

 

[asahibito]

It's in items. Which is an iterable. If it's the first choice it's either items[0] or items[1] depending if menu makes use of a menu caption.

    vbox:
        for i in items:

Typically i.caption will be the menu string unless the dev did their screen from scratch.

If you take a look at the source code for practically any RenPy game, you'll usually find a file called screens.rpy.

Within there, you'll find the majority of the predefined screens. From your post, screen say and screen choices are certainly included.

If you look at both, you'll find code that looks something like:

screen say(who, what):
    style_prefix "say"

    window:
        id "window"

        if who is not None:

            window:
                id "namebox"
                style "namebox"
                text who id "who"

        text what id "what"

# -----------------------------------------------------------

screen choice(items):
    style_prefix "choice"

    vbox:
        for i in items:
            textbutton i.caption action i.action

In both cases, you'll see that the parameters passed to the screen are listed in brackets after the screen name.
screen say(who, what):
screen choice(items):

Each screen is unique, and therefore what is passed to it will be unique. There's no common list of variables used, just the parameters passed along by the underlying functions. The "names" of those variables is local to the screen. I could call a screen with show screen say(my_variable1, my_variable2), but the screen itself would still think the variables are called "who" and "what".

In the case of screen say():, the what and who parameters are passed, and used as plain

You must be registered to see the links

fields.

The screen choices(): is a little more complex, as it is passed an object it knows locally as items, which looks to be a list of other objects. Each item within the list has a caption and an action property (what the RenPy documentation calls "fields"), and the caption is used as a

You must be registered to see the links

. Exactly how you'd know that items is a list and that list has objects which have properties including "caption" and "action" isn't something that will immediately jump out at you without some digging (or documentation).

On the documentation front, there is this from the RenPy documentation:

You must be registered to see the links

Which lays out all the predefined screens and what their parameters (variables) are. Again, remember the names of the variables are just the standard names.

Thank you for both your detailed responses. However I am not looking for the local variables used in those screens. I am looking for the variables that are passed to the screens. For example for the choice screen what variable does renpy put all the choice information before passing it to the choice screen as a parameter? Same thing for the say screen and other all other built-in renpy screens that take parameters. I understand that each built-in screen will take its own unique parameters hence looking for a list of them all.

 

[GetOutOfMyLab]

Thank you for both your detailed responses. However I am not looking for the local variables used in those screens. I am looking for the variables that are passed to the screens. For example for the choice screen what variable does renpy put all the choice information before passing it to the choice screen as a parameter? Same thing for the say screen and other all other built-in renpy screens that take parameters. I understand that each built-in screen will take its own unique parameters hence looking for a list of them all.

I'm not even sure a variable is used. Based on what is shown here:

You must be registered to see the links

It's probably something like:

renpy.display_menu([
    ("East", renpy.Choice("east", icon="right_arrow"),
    ("West", renpy.Choice("west", icon="left_arrow"),
    ])

Basically a list of 2-item tuples.

 

[79flavors]

I am not looking for the local variables used in those screens. I am looking for the variables that are passed to the screens.

Doesn't the link I provided at the bottom not cover what you are asking?

You must be registered to see the links

Ultimately, the calling functions are going to be part of the RenPy internals, somewhere within the .py files located within the /renpy/ folder. That is... the RenPy engine itself. Not something most developers will go anywhere near.

For example, the screen say(): can be invoked by the RenPy statement,

You must be registered to see the links

.
As a developer, you'd code something like : e "Hello World.", not $ renpy.say(e, "Hello World."). RenPy (the engine) is what converts the script the developer would write into executable code.

I'm not sure that the values are held as variables anywhere before the say function is invoked. Except perhaps locally as parameters to each subsequently invoked function. I could be wrong, as I'm usually focused on explaining the RenPy scripting and not the underlying python code that makes it possible.

I can't help but think we're missing something about your question.
Perhaps it would help if you explained why you think these variables exist (separately?) and how you hope to use them.
Are you perhaps hoping to intercept the listed menu choices, so that you can alter the text to deliver something like a walkthrough? Because would usually be done via something like

You must be registered to see the links

, where the text displayed is replaced with alternative text. (and isn't the only solution, by far).
It feels like we're missing some context.

You've said, "I ultimately want to be able to use those variables in my code directly. "
What do you mean when you say "my code"? RenPy scripting language? Python code? Within a game? As a mod? If a mod, for a specific game or are you trying to write something more generic that will work for multiple games?

 

[asahibito]

I'm not even sure a variable is used. Based on what is shown here:

You must be registered to see the links

It's probably something like:

renpy.display_menu([
    ("East", renpy.Choice("east", icon="right_arrow"),
    ("West", renpy.Choice("west", icon="left_arrow"),
    ])

Basically a list of 2-item tuples.

So you are thinking it is more likely, for the screen choice case, that renpy is converting the user readable script version into a renpy.display_menu function call with the menu text during compile time. I guess it probably is doing the same thing for screen say except the engine specifically captures the last say text in a variable and provides some methods to access it.

I was hoping for more of a Javascript HTML DOM situation where I can reference the value of any element but I can see how it may be challenging for an arbitrary long and loosely structured renpy script file.

Thank you and everyone else for helping with this issue.

 

[asahibito]

Doesn't the link I provided at the bottom not cover what you are asking?

You must be registered to see the links

Ultimately, the calling functions are going to be part of the RenPy internals, somewhere within the .py files located within the /renpy/ folder. That is... the RenPy engine itself. Not something most developers will go anywhere near.

For example, the screen say(): can be invoked by the RenPy statement,

You must be registered to see the links

.
As a developer, you'd code something like : e "Hello World.", not $ renpy.say(e, "Hello World."). RenPy (the engine) is what converts the script the developer would write into executable code.

I'm not sure that the values are held as variables anywhere before the say function is invoked. Except perhaps locally as parameters to each subsequently invoked function. I could be wrong, as I'm usually focused on explaining the RenPy scripting and not the underlying python code that makes it possible.

I can't help but think we're missing something about your question.
Perhaps it would help if you explained why you think these variables exist (separately?) and how you hope to use them.
Are you perhaps hoping to intercept the listed menu choices, so that you can alter the text to deliver something like a walkthrough? Because would usually be done via something like

You must be registered to see the links

, where the text displayed is replaced with alternative text. (and isn't the only solution, by far).
It feels like we're missing some context.

You've said, "I ultimately want to be able to use those variables in my code directly. "
What do you mean when you say "my code"? RenPy scripting language? Python code? Within a game? As a mod? If a mod, for a specific game or are you trying to write something more generic that will work for multiple games?

As for context, I am definitely approaching this as a mod author. While there may be a multitude of ways to accomplish some of the things, it is more expedient to act by checking the value directly.

The reason I think such variables exist is due to the fact that the engine must somehow interpret the script and construct the screen. It must be able to store the script in some variable, act on it somehow and then input it to the screen functions. However you may be right that if any such variables exist, they may not be globals or visible at the runtime level I am working in. Now that I think about it, I wonder if some kind soul has listed all the runtime variables in globals() for a barebones, only system variables, renpy game.

Anyways, thanks again for taking the time to respond to my question.

 

[79flavors]

Okay, you're aiming beyond what I can say for sure.

You might want to look into callbacks, though which one(s) is beyond me.

You must be registered to see the links

You must be registered to see the links

You must be registered to see the links

You must be registered to see the links

...and as I already mentioned,

You must be registered to see the links

I'm not suggesting any of those are the best solution - just the only ones that I personally would look into based on my very limited knowledge of RenPy's internals and your goals.

The most common solution I've seen to modding is the final one - replacing game text with mod text on the fly using text filtering. Invariably, that is a mod per game though - rather than a generic one size fits all.

The parameters passed to callbacks is usually listed as "args" and "kwargs", in the style of def my_function_callback (*args, **kwargs):. And now you've into python territory, not RenPy. See:

You must be registered to see the links

 

[gojira667]

The reason I think such variables exist is due to the fact that the engine must somehow interpret the script and construct the screen. It must be able to store the script in some variable, act on it somehow and then input it to the screen functions.

That's core engine internals and it won't be "some variable" in the store. Ren'Py reads the AST gleaned from the RPYC files. See: lexer.py, parser.py (menu_statement), ast.py (class Scry & Menu), prediction and probably others.
class Menu in ast.py parses the menu statement in Ren'Py script. To TL:DR it, it calls renpy.exports.menu() in in exports.py which is a lower level menu command. That in turn... wait for it... calls renpy.display_menu() to show the actual menu.

As 79flavors listed Ren'Py offers a number of stable, documented API interfaces which you should make use of instead.

You must be registered to see the links

is an example of how you can change who/what styling.