Ren'Py Hovering over a bar for tooltip

[AdventAnyx]

Hey, everyone. Me, a noob, again.
Is there a simple way (without writing classes and such) to make tooltips work over bars?

Here:


I have a working tooltips system already. Works perfectly over image- and text-buttons.
Today I discovered a fillable "Bar" thingy and want to apply tooltip to it.
It says this:

But I'm too dumb to understand what "action" should I use.

I did this:

bar:
        xpos 1100 ypos 100
        xysize(178,40)
        value goal_points
        range 100
        left_bar "images/ui/star_bar_full.png"
        right_bar "images/ui/star_bar_empty.png"
        tooltip "points = [goal_points]"

Game runs, but when I hover over my stars bar, nothing happens.
Can you help me?

 

[79flavors]

The issue seems to be that tooltip is only invoked when the displayable gains focus.
However it seems like bar never actually gains focus, since it is not an interactive UI element.

I found a bug report/issue from 2018 that seems to be about the same thing:

You must be registered to see the links

PyTom's solution there is to wrap the bar itself in a button that does nothing.
This seems to work:

    button:
        xpos 1100 ypos 100
        xysize(178,40)
        action NullAction()
        tooltip "Points = [goal_points]"
        bar:
            xysize(178,40)
            value goal_points
            range 100
            left_bar "images/ui/star_bar_full.png"
            right_bar "images/ui/star_bar_empty.png"

Though obviously have a play with it yourself.

 

[AdventAnyx]

......

Holy shit, man! The response time on the porn-games forum is like I'm actually talking to a paid customer-support.
You are fucking awesome!

Thank you, that worked like a charm.

Mind if I bother you with something else really quick?
I did not do the proper googling yet, but since you are here...

It's about ".rpyc" files. Here I stumbled upon this comment:

Spoiler

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

And it struck me like a lightning. I deleted .rpyc from time to time, as I thought they are garbage.
I won't do this anymore, but...I think deleting them sometimes solved some problems that I had. Though I'm not sure, as once I run into a problem I try everything, and I never noticed if deleting them actually helped, since I didn't value them.
But, the question is this:

As I discover RenPy slowly, I've figured the easier way to do smaller patches in the same big version is not to do this:

build.classify('game/**.png', 'archive')
    build.classify('game/**.jpg', 'archive')
    build.classify('game/**.gif', 'archive')
    build.classify('game/**.webm', 'archive')
    build.classify('game/**.mp3', 'archive')
    build.classify('game/**.ttf', 'archive')
    build.classify('game/**.mp3', 'archive')
    build.classify('game/**.ogg', 'archive')
    build.classify('game/**.rpy', 'archive')
    build.classify('game/**.rpyc', 'archive')

But instead pack the .rpy files separately. Right? Just assign another name to the archive they will be in.
Do I need to place .rpyc there too?

The goal is this:
I do a big version release, it weights a lot. To fix bugs I just do another "Build Distribution" thing, then upload the archived ".rpy + .rpyc" file separately for those who have the base game already.
And to not break people's save-games.
Am I on the right path?
Thanks again.

 

[79flavors]

And it struck me like a lightning. I deleted .rpyc from time to time, as I thought they are garbage.

I'm no expert... but... never... ever... EVER... delete your .rpyc files.

There's

You must be registered to see the links

... but basically, RenPy uses something called

You must be registered to see the links

to keep track of the source code.

I tend to think of it as a cross reference to every line of code you have. Each time you add a line, the cross reference is updated. Delete a line... same thing. Update a line... same thing. That cross reference is stored within the .rpyc files.

That cross reference is why when you load a save game, even though the code around it could have changed... RenPy is still able to work out which line to continue from.

If you delete the .rpyc files, that cross reference must be rebuilt from scratch. So when a player loads a saved game from a version before you deleted the .rpyc files, RenPy really struggles to figure out where in the code everything is anymore.

One trick, if you have deleted the .rpyc files recently, is to do the following:

• Delete all your .rpyc files.
• Unpack the latest public release of your game into a different folder.
• Copy the .rpyc files from that other folder into your current development folder.
• Run your game.

By copying the "old" .rpyc files back then running it with the updated .rpy code, the .rpyc files will be used as the starting point for the "cross reference" updates. It makes your current version compatible with the version you last distributed to the community.

Obviously... this is a last resort solution. Only do it if you've already screwed things up.

Oh... and the other "don't touch" thing is call ... from ...
When RenPy builds a project, it adds "from {insert unique label name here}" to any call statement.
It's very tempting when "cleaning up your code" to remove all those added from parameters so that the next time a build is done, all those added elements are in numerical order again.
DON'T.
Once they're added... just leave them alone forever.
You can continue to develop your game. Even delete lines where needed. But just don't be tempted to "clean" them up.
I notice from your project, that you seem to have switched off the "Add from clauses to calls" option within the build menu. That's probably fine... in so much as it obviously still works. But those from make it way easier for RenPy to figure out where it's up to when a player loads a saved game... especially if they managed to save while within a label that has been called. I know they look messy... but they serve purpose... but clearly not a critical one.

 

[AdventAnyx]

I know they look messy...

That's exactly why I deleted them after my very first release.
Like "WTF, I didn't write these! Get out!" Cleaned the code, un-checked the box, and never touched it again.

Thank you. That's very detailed, but I can't promise you I get all 100% of it.
I'm not doing that restore option for sure. Sometimes I forgot to delete .rpyc, sometimes I didn't. Finding the proper release is not an option. I'm moving on, my players better do the same

 

[79flavors]

But instead pack the .rpy files separately. Right? Just assign another name to the archive they will be in.
Do I need to place .rpyc there too?

The goal is this:
I do a big version release, it weights a lot. To fix bugs I just do another "Build Distribution" thing, then upload the archived ".rpy + .rpyc" file separately for those who have the base game already.
And to not break people's save-games.
Am I on the right path?
Thanks again.

Back to your other point...

.rpyc files are just "compiled" versions of the .rpy source files.
It's actually the .rpyc files that are used to run your game. You can ship it with just .rpyc files and no .rpy files at all (in some ways, this is recommended - because it makes it slightly harder for the morality police to check your source code for code that they might be upset about... like incest patches).

Even when the .rpyc files are stored within an .rpa RenPy archive.

If RenPy finds duplicated/conflicting versions of a .rpyc file, it does some "voodoo" to figure out which to use. I think that is based on files date/time stamps... but I don't know that for sure.
So if you've got a .rpa archive containing a script.rpyc AND a script.rpyc file in your /game/ folder - it will almost certainly use the one in the /game/, since it's likely newer.

Additionally, if you add a .rpy file after the game has been shipped with a .rpa archive. The first thing RenPy will do is compile that .rpy file to create a new .rpyc file - which, again, because it's newer... will override the version stored within the .rpa archive.

All that said, I personally think trying to distribute "patches" to existing games by getting players to unpack just the files that have changed since the latest release is pointless.
Well... not pointless... because the "patch" file sizes will be significantly smaller.
But honestly, it's a PITA to deal with the "hard of thinking" players who immediately either don't follow the instructions on how to apply the patch or unpack it to the wrong folder... or something else. You'll spend a bucketload of time dealing with stupid people, when all you're trying to do is make it easier for them to download a smaller file. (I speak from experience).
Unless your enjoy that sort of self-punishment.... just build a full version of your game each time... and distribute that. Someone else will inevitably create a "compressed" version... let them do that shit, so you can focus on the important stuff... creating your game.

Edit:
For comparison, this is my standard build options within the options.rpy:

Spoiler: My... build.classify

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

 

[AdventAnyx]

All that said, I personally think trying to distribute "patches" to existing games by getting players to unpack just the files that have changed since the latest release is pointless.
Well... not pointless... because the "patch" file sizes will be significantly smaller.
But honestly, it's a PITA to deal with the "hard of thinking" players who immediately either don't follow the instructions on how to apply the patch or unpack it to the wrong folder... or something else. You'll spend a bucketload of time dealing with stupid people, when all you're trying to do is make it easier for them to download a smaller file. (I speak from experience).
Unless your enjoy that sort of self-punishment.... just build a full version of your game each time... and distribute that. Someone else will inevitably create a "compressed" version... let them do that shit, so you can focus on the important stuff... creating your game.

I try to think positive and better of people
If I only do several lines of fixes in 1-2 files and tell them to replace 1(!) file (let's call it "allscritps.rpa"), sure they can do it, right?

 

[AdventAnyx]

Well, what perfectly worked with a simple bar, doesn't with something like:

button:
        xpos 1700 ypos 220
        xysize(200,50)
        action NullAction()
        tooltip "Drag or click to change {b}base{/b} value. The lower the easier to get the reward. Free orgasm at Zero every day. Now set to [butt_plug2_number]"     
        bar:         
            xysize(200,50)
            value VariableValue("butt_plug2_number",200)
            left_bar "images/ui/bp_bar_full.png"
            right_bar "images/ui/bp_bar_empty.png"
            thumb "images/ui/bp_bar_thumb.png"

It appears that once the Button is created, then that Bar is like "over" it. So when you hover over the bar it shows nothing, but if you hover over the tiny little pixel at the side (where somehow Button and Bar don't overlap), there you can see a tooltip.

So I had to do some bullshit like this.

button:
        xpos 1700 ypos 220
        xysize(200,50)
        action NullAction()
        tooltip "Drag or click to change {b}base{/b} value. The lower the easier to get the reward. Free orgasm at Zero every day. Now set to [butt_plug2_number]"
        text "Info" size 20
        bar:
            ypos 30
            xysize(200,50)
            value VariableValue("butt_plug2_number",200)
            left_bar "images/ui/bp_bar_full.png"
            right_bar "images/ui/bp_bar_empty.png"
            thumb "images/ui/bp_bar_thumb.png"

Technically it's the same button, but the tooltip is shown only when you hover over "Info" text...
Oh well...Maybe I'm missing something?

 

[anne O'nymous]

Today I discovered a fillable "Bar" thingy and want to apply tooltip to it.

Hmm... I'm not sure that you understood it right.

From what I get of your screenshot, you use "bar" to design a part of the screen grouping similar data. But the bar screen statement is for a progression bar ; it's not an design element like can be frame by example.

This said, the easiest answer to your question is to add an invisible button on top of the part you want to have a tooltip :

    imagebutton:
        # black 100% transparent image
        idle Solid( "#00000000" )
        xpos 1100 ypos 100
        xysize(178,40)
        # Do nothing on click
        action NullAction()
        # Ensure that the button is active
        sensitive True
        tooltip "Whatever you want"

If you delete the .rpyc files, that cross reference must be rebuilt from scratch. So when a player loads a saved game from a version before you deleted the .rpyc files, RenPy really struggles to figure out where in the code everything is anymore.

It will also break the skip feature because, for Ren'py, every single line are totally new.