Ren'Py Problem with scrollbar

[monsternn]

So, i have menu with many choices so i added a viewport with scrollbars. I also wanted to see tooltip about every choice (tooltip is displayed below choices) and it works like a charm when scroll is at the bottom. However when i actually scroll up from bottom i see no tooltips and from my understanding it happens because one thingy overlaps another. So the questsion is - how to still be able to see tooltips even when i scroll choices?
here is how i display tooltip

hovered SetScreenVariable("choice_context", i.kwargs.get('tooltip', None))

and this is settings for viewport

            draggable True
            mousewheel True
            scrollbars "vertical"
            xsize gui.choice_button_width
            ysize config.screen_height -180

 

[anne O'nymous]

So, i have menu with many choices so i added a viewport with scrollbars.

Hmm. By default menu can fit 10 one line choices plus the dialog box. And it's already a lot of choices. If you need to put a menu in a viewport taking all the screen (minus the dialog box), there's a problem with the game design.
A menu shouldn't present more than 4-5 choices.

I also wanted to see tooltip about every choice (tooltip is displayed below choices) and it works like a charm when scroll is at the bottom. However when i actually scroll up from bottom i see no tooltips and from my understanding it happens because one thingy overlaps another.

What do you mean by "below choices" ?
I have a guess regarding the answer, but it don't match with your understanding ; yet I fear that it's effectively the answer.

here is how i display tooltip

hovered SetScreenVariable("choice_context", i.kwargs.get('tooltip', None))

and this is settings for viewport

            draggable True
            mousewheel True
            scrollbars "vertical"
            xsize gui.choice_button_width
            ysize config.screen_height -180

Hmm, no, this isn't how you display the tooltips. It's how you are assigning a value when a button is hovered, and how you configured the viewport.
I would want to ask how you use "choice_context", since it's how you display the tooltips, but I fear that it would make you stick on a really wrong way.

So instead I'll answer to your:

how to still be able to see tooltips even when i scroll choices?

You do it this way:

screen choice(items):
    style_prefix "choice"

    viewport:
            draggable True
            mousewheel True
            scrollbars "vertical"
            xsize gui.choice_button_width
            ysize config.screen_height -240

        for i in items:
            if "tooltip" in i.kwargs:
                textbutton i.caption:
                    action i.action
                    tooltip i.kwargs["tooltip"]
            else:
                textbutton i.caption action i.action

    $ tt = GetTooltip()
    if tooltip:
        text "[tt]"

 

[monsternn]

Hmm. By default menu can fit 10 one line choices plus the dialog box. And it's already a lot of choices. If you need to put a menu in a viewport taking all the screen (minus the dialog box), there's a problem with the game design.
A menu shouldn't present more than 4-5 choices.




What do you mean by "below choices" ?
I have a guess regarding the answer, but it don't match with your understanding ; yet I fear that it's effectively the answer.




Hmm, no, this isn't how you display the tooltips. It's how you are assigning a value when a button is hovered, and how you configured the viewport.
I would want to ask how you use "choice_context", since it's how you display the tooltips, but I fear that it would make you stick on a really wrong way.

So instead I'll answer to your:


You do it this way:

screen choice(items):
    style_prefix "choice"

    viewport:
            draggable True
            mousewheel True
            scrollbars "vertical"
            xsize gui.choice_button_width
            ysize config.screen_height -240

        for i in items:
            if "tooltip" in i.kwargs:
                textbutton i.caption:
                    action i.action
                    tooltip i.kwargs["tooltip"]
            else:
                textbutton i.caption action i.action

    $ tt = GetTooltip()
    if tooltip:
        text "[tt]"

Thx for the answer, about design its simulation game so theres a lot of actions that you can do and i dont want to separate them into groups cause there will be too much clicking that way. (I mean if there is menu and it spawn another menu and so on.)
About below choices - well, i displayed tooltips there, but its probably better in left upper angle like in your answer.

 

[anne O'nymous]

Thx for the answer, about design its simulation game so theres a lot of actions that you can do and i dont want to separate them into groups cause there will be too much clicking that way. (I mean if there is menu and it spawn another menu and so on.)

Yeah, there's clearly a design flaw here.
Saying that nobody will look at all the options is probably exaggerated, but it's clear that many will feel overwhelmed. And, of course, the best design isn't either a menu that would span another menu, it's not menu at all.
It's clearly a situation that have to be handle visually, at least in part, and with a screen.

About below choices - well, i displayed tooltips there,

This still don't tell me what "below choices" mean for you.

but its probably better in left upper angle like in your answer.

Or anywhere else you want it. There's no style applied to the text displaying the tooltip, and a

    if tooltip:
        text "[tt]"
        xalign 0.5
        ypos config.screen_height -250

is enough to place it in between the choices and dialog box.



I don't want to be rude, but with your two posts you clearly demonstrated that you aren't ready yet to make a game, especially one as complex as that imply simulations.

1. You say that you'll show something, and what you show is not this thing ;
   Displaying a variable and assigning a value to that variables are clearly not the same. You said you were showing the first, what you shown is the second.
2. You answer to "what do you mean by 'below choices'" by "below choices" ;
   That isn't an answer, it's a repetition.
3. You only see textual menu as way to present choices to the players ;
   Even a text based game rely on icons, or maps-like, for it's interface when it's needed. And here the kind of menu that bother you are clearly part of the interface and need to be presented that way.
4. I'm not sure that you effectively took a look at Ren'Py documentation ;
   You use a clearly outdated approach (hovered), with a recent one (SetScreenVariable) to achieve what can, and should, be done with the dedicated screen action (tooltip).
5. You take as granted the position of the tooltip in my code ;
   It don't looks like you imagined that applying a bit of style could change the position where it is displayed.

And I'm tempted to add that:
You don't understand that, in the code you initially wrote, the tooltip isn't shown because it's below the choices in the viewport and therefore in a part not displayed when you aren't at the bottom of the said viewport.

While surely not all point are as obvious as this for someone who's starting, the two first clearly only depend on the most basic logic. However, it turns out that making a game need logic, a lot of logic.
You were stuck on an issue relatively basic, and not too difficult to figure out. What will happen when you'll have to take count of the player choices on a long run, still apply the choice he picked ten hours ago in the game, in top of the many choices he picked since there ?

 

[monsternn]

Yeah, there's clearly a design flaw here.
Saying that nobody will look at all the options is probably exaggerated, but it's clear that many will feel overwhelmed. And, of course, the best design isn't either a menu that would span another menu, it's not menu at all.
It's clearly a situation that have to be handle visually, at least in part, and with a screen.




This still don't tell me what "below choices" mean for you.




Or anywhere else you want it. There's no style applied to the text displaying the tooltip, and a

    if tooltip:
        text "[tt]"
        xalign 0.5
        ypos config.screen_height -250

is enough to place it in between the choices and dialog box.



I don't want to be rude, but with your two posts you clearly demonstrated that you aren't ready yet to make a game, especially one as complex as that imply simulations.

1. You say that you'll show something, and what you show is not this thing ;
   Displaying a variable and assigning a value to that variables are clearly not the same. You said you were showing the first, what you shown is the second.
2. You answer to "what do you mean by 'below choices'" by "below choices" ;
   That isn't an answer, it's a repetition.
3. You only see textual menu as way to present choices to the players ;
   Even a text based game rely on icons, or maps-like, for it's interface when it's needed. And here the kind of menu that bother you are clearly part of the interface and need to be presented that way.
4. I'm not sure that you effectively took a look at Ren'Py documentation ;
   You use a clearly outdated approach (hovered), with a recent one (SetScreenVariable) to achieve what can, and should, be done with the dedicated screen action (tooltip).
5. You take as granted the position of the tooltip in my code ;
   It don't looks like you imagined that applying a bit of style could change the position where it is displayed.

And I'm tempted to add that:
You don't understand that, in the code you initially wrote, the tooltip isn't shown because it's below the choices in the viewport and therefore in a part not displayed when you aren't at the bottom of the said viewport.

While surely not all point are as obvious as this for someone who's starting, the two first clearly only depend on the most basic logic. However, it turns out that making a game need logic, a lot of logic.
You were stuck on an issue relatively basic, and not too difficult to figure out. What will happen when you'll have to take count of the player choices on a long run, still apply the choice he picked ten hours ago in the game, in top of the many choices he picked since there ?

Well, thats true that im new to renpy and these code snippets are from various forums that i find to deal with problems, its just i follow the commonly used concept - not to reinvent the wheel. So id better see and try code of other more expirienced people than try to write it myself. I understand that renpy is pretty flexible framework and i read docs sometimes but i never worked with UI as a programmer so its kinda hard sometimes to figure out what is going on.

 

[crabsinthekitchen]

You use a clearly outdated approach (hovered), with a recent one (SetScreenVariable) to achieve what can, and should, be done with the dedicated screen action (tooltip).

since 7.5 added nearrect, I find hovered with CaptureFocus and ClearFocus to be the easiest way to make tooltips appear next to buttons

button:
    hovered CaptureFocus("button_with_tooltip")
    unhovered ClearFocus("button_with_tooltip")
    action NullAction()

nearrect:
    focus "button_with_tooltip"
    fixed:
        #whatever you want in your tooltip

 

[anne O'nymous]

since 7.5 added nearrect, I find hovered with CaptureFocus and ClearFocus to be the easiest way to make tooltips appear next to buttons

You don't need to use the focus related screen actions if you rely directly on the tooltip property. Like the doc for

You must be registered to see the links

imply (but not necessary as clearly as it should), tooltip trigger a special case directly handled.
I haven't tested it, but the

You must be registered to see the links

include an example using nearrect, so I'm 99% sure that it's an implemented behavior.


This being said, you aren't totally wrong, and I should starts to address more the 7.x additions.
I tend to avoid them because sometimes the help is for an already started project, and answering "update the version of Ren'Py you use" isn't necessarily the best way to starts the answer. But in the same time, I can't pester when someone use outdated code, and systematically avoid to address it when there's newest way to do.