itch.io

Good catch! I'll add a check for that in the next release.

I've got it on my to-do! Unfortunately I just have a lot of things to do 😅 But it's in the issues page of my repo. The example you gave was missing a few things for me to make it run properly, but I was able to reproduce a pretty basic example by popping some ATL on buttons in a controller viewport. I will let you know if I have any updates!

Spoke too soon actually; try replacing the following function with these modifications:

def get_all_children(d, xoffset, yoffset, width, height):
    """Return all the children, grandchildren etc of d."""
    children = [ ]
    offsets = [ ]
    sizes = [ ]
    if not hasattr(d, "children"):
        return children, offsets, sizes
    for i, child in enumerate(d.children):
        ## Render it to get the size
        # cr = child.render(width, height, 0, 0) ## Caused some weirdness with bars
        cr = renpy.render(child, width, height, 0, 0)
        sizes.append((cr.width, cr.height))
        children.append(child)
        offsets.append(d.offsets[i])
        if hasattr(child, "children"):
            ch, of, sz = get_all_children(child, d.offsets[i][0], d.offsets[i][1], cr.width, cr.height)
            children.extend(ch)
            offsets.extend(of)
            sizes.extend(sz)
    new_offsets = [ ]
    for of in offsets:
        new_offsets.append((of[0]+xoffset, of[1]+yoffset))
    return children, new_offsets, sizes

Let me know if that fixes your problem. I still need to do a bit more testing to make sure other aspects of the viewport work as expected, but this did solve the bar problems for me.

Thanks for the detailed bug report!

I'm currently investigating this; I don't have any particular answers yet, though the problem appears with a regular bar as well as a controller bar, so it seems to be a problem specific to the controller viewport. Strangely, it doesn't always appear either - you'll notice that the bars that come with the preference screen included in the template don't have this problem. I've been able to tentatively narrow it down to something going wrong in the render method. I'll keep plugging away at it when I have time. In the meantime, you might play around with copying over the preference screen controller_bar layout and adjusting it to find a version that works.

Interesting! Looks like something that changed between engine versions. You can update these functions in the backend file:

def _tts(self, *args, **kwargs):
    return self.parent_class._tts(self, *args, **kwargs)
def _tts_all(self, *args, **kwargs):
    return self.parent_class._tts_all(self, *args, **kwargs)

And that should fix it.

Ah, I see - none of those buttons have valid controller events. Thus, the game has no way to look up events associated with those buttons. IconButton is intended to have a mapping both for keyboard and for controller. If you just want to make a mouse & keyboard button with no controller equivalent, there's no need to use IconButton at all, since most of its conveniences are tied to picking the right icon set and allowing for remapping, none of which is offered for keyboard shortcuts. You can just make your own imagebutton with a keysym.

Have you modified or removed custom events, or added your own icon buttons to the screen? It looks like it's trying to find a pad event, and there isn't a match.

Ah it should be `scroll="viewport"` as a string. The fact that it doesn't complain about Viewport is just 'cause you're setting it to the name of a class, which does exist, but isn't what the screen is expecting.

Have you updated ICON_FOLDER = "backend/controller_support/controller_ui/" at the top of controller_config.rpy to point to where you have the controller icons? It looks like you've put the files into your own subfolder, so you'll need to update the path where it can find the icons as well.

If you're plopping this into an existing project, you probably don't want to take the screens with it! Or make sure you just have one copy of the screens. While the error message doesn't specify, I imagine you might be running into an issue where the game_menu screen included with this project doesn't have some of the arguments that the game_menu screen in a default Ren'Py template has. 

No worries! If you're using the basic screen provided in the template, then the simplest is to add a "page" variable in the screen, and use that to adjust which images are displayed. I recommend just manually adding the buttons, unless you're familiar with `for` loops already! So, a very basic version might be:

screen gallery():
    tag menu
    default page = 1
    add HBox(Transform("#292835", xsize=350), "#21212db2") # The background; can be whatever
    use game_menu(_("Gallery"))
    fixed:
        style_prefix 'gal'
        ## Organize the gallery images into a grid
        grid 2 2:
            if page == 1:
                add g.make_button("xia_cg_1", "xia_cg_1_thumb")
                add g.make_button("xia_cg_2", "xia_cg_2_thumb")
                add g.make_button("xia_cg_3", "xia_cg_3_thumb")
                add g.make_button("xia_cg_4", "xia_cg_4_thumb")
            elif page == 2:
                add g.make_button("zoran_cg_1", "zoran_cg_1_thumb")
                add g.make_button("zoran_cg_2", "zoran_cg_2_thumb")
                add g.make_button("zoran_cg_3", "zoran_cg_3_thumb")
                add g.make_button("zoran_cg_4", "zoran_cg_4_thumb")
            # add more elif page == 3 and so on if you have more
    
    hbox:
        yalign 1.0
        ## Either directly set the page, e.g.
        textbutton _("Page 1") action SetScreenVariable("page", 1)
        ## Or have buttons to go to the next/prev page e.g.
        if page < 2: # We have 2 pages total
            textbutton _("Next") action SetScreenVariable("page", page+1)
        if page > 1: # Make sure it doesn't go below 1
            textbutton _("Next") action SetScreenVariable("page", page-1)

Hope that helps!

Hmm, you're right. You can add

if current_t <= 0:
    self.restart()

just under the line that sets current_t in the render method, around line 133, and that should fix it. 

You can run achievement.clear_all() (https://www.renpy.org/doc/html/achievement.html#achievement.clear_all) to clear all achievements.

Can you elaborate? I'm not sure I follow what you're seeing. Do you have actual code to reproduce what the problem is?

All right, unfortunately I don't really have any further actionables - it sounds like things are set up properly if you see multiple achievements from the gallery, so it probably makes sense to debug around the time you're trying to grant your achievements. Do you have any LinkedAchievements or similar? Usually in a case like this, where you automatically grant an achievement if two others have been earned, LinkedAchievement is useful. I'd also include some debug lines like "Do you have ending_A achievement? [ending_A.has()]" to see what the values for everything are. It might be that you already have ending_C's achievement accidentally or something, so its popup is not appearing.

It's likely showing both popups in the same place on top of one another - if you look at the default achievement_popup screen, there's a special bit:

## Allows multiple achievements to be slightly offset from each other.
## This number should be at least as tall as one achievement.
default achievement_yoffset = num*170
frame:
    style_prefix 'achieve_popup'
    ## The transform that makes it pop out
    at achievement_popout()
    ## Offsets the achievement down if there are multiple
    yoffset achievement_yoffset

That yoffset bit makes sure that if there are multiple achievements shown at the same time, they get offset so they're not stacking on top of each other. Make sure you have that code, or something similar, in your own popup screen!

Just delete

if config.developer:
    action a.Toggle()

from the screen. Note that because of the "if config.developer" part, clicking on achievements will not grant them in a proper build; only during development for testing.

I don't know if I'd include it directly since the bubble assets aren't part of the pack, but I can show you the properties I used:

For the farthest back bubbles, I use a small image and I have an AlphaMask to make sure they appear behind some of the midground and foreground elements. I use the following properties:

    particle_size=8,
    xspeed=(-10, 10),
    yspeed=(-20, -10),
    yacceleration=(10, 20),
    flutter_width=(100, 200),
    flutter_xtime=(4, 8),
    damp_xflutter=-1.0,

For the midground bubbles:

    xspeed=(-10, 10),
    yspeed=(-50, -30),
    yacceleration=(30, 40),
    flutter_width=(100, 200),
    flutter_xtime=(4, 8),
    damp_xflutter=-1.0,
    origin_points=[(400, 1.0), (1200, 1.0)],

And for the foreground bubbles:

    xspeed=(-10, 10),
    yspeed=(-100, -40),
    yacceleration=(30, 40),
    flutter_width=(100, 200),
    flutter_xtime=(4, 8),
    origin_points=[(0.0, 1.0), (0.05, 1.0), (0.1, 1.0), (0.85, 1.0), (0.9, 1.0), (0.95, 1.0), (1.0, 1.0)],

As with the existing examples, it's most helpful if you have multiple layers where the farthest back layers move the slowest and have the most particles, and the foreground layers move the fastest with the fewest particles. I used origin points here to make it appear that there were particular places the bubbles were coming from, but you could also just let it start at the bottom of the screen depending on what your background looks like. The acceleration is good for an effect like this, to make the bubbles move faster as they rise.

Hope that helps!

I'm not really concerned about this, no. Ren'Py's developers value backwards compatibility, so it's unlikely we're going to lose functionality. If some parts need tweaking following the change, I'll simply make an update to the tool, and you would be able to continue using this initial version on any earlier Ren'Py engine releases. In general I try to avoid modifying engine internals wherever possible, and if I do (often to fix bugs) I always ensure that if I need to change how the tool accesses that part, your "front-end" code using my tool won't have to change. So, I wouldn't be worried about it.

Hey there, yup this is possible! I suggest you put your animations into a screen which you reuse in your other UI screens as the background. For example:

screen falling_bg():
    add "example_snow_background"
    add "example_snow_midground"
    add "example_snow_midground2"
    add "example_snow_foreground"
screen preferences():
    tag menu
    use falling_bg() id 'falling_bg'

The key here is `use falling_bg id 'falling_bg'`- the ID will mean that Ren'Py knows it's the same background across any other screens you use it.

Note that if you're using the default Ren'Py template, you'll need to figure out where to put the background since by default the game menu screen that's reused everywhere comes with its own overlays.

Also there were some issues with Sprite animations in screens in earlier versions of 8.5 in particular; make sure you're on 8.5.2 or later if you can.

You're welcome to update the code however you like, but, would it not be sufficient to just have `if platinum_achievement.has()` for your gallery or any other screens?

Have you tried this with a general viewport? Ren'Py doesn't pass ATL events to displayables inside containers, so that may be what you're seeing. Otherwise, if it works with a regular viewport and not the controller viewport, if you can make me a short reproducible code section I'll look into debugging it.

Thank you! I'm glad the demonstration helped. There are a lot of possible ways to use the tool and properties to tweak it, so I wanted to have a visual way of demonstrating how it all works. Plus it's nice to have some preset examples to just plop into your scenes, like the fireflies!

If anything, this sounds like it would be a "situational"-category event, given that it's only active during minigames. You're also welcome to add your own categories and define their compatibilities when you add new events. Or, if you don't need your minigame keys to be remappable, it's fine to just hardcode it with pygame events.

Yikes, what a thing to have happen. Thanks for the updates!

A nifty little tool! I appreciate all the effort you put into documenting what the different values do and organizing the file into sections. Plus the example label making it simple to see how it all works. I hope to see some cool cinematic effects with this in the future. Thanks for making it!

What a lovely UI! I really like the animated squiggle effect underneath the buttons, and the quick menu icons. I don't usually see quick menus at the top of the screen, so it's a fun change. Thanks for submitting this!

Lots of variety here! The shader additions really make for some unique effects now, too and add a lot to the overall ImageDissolve effect. Like others here I immediately zeroed in on the halftone effects for a project I was working on - a great choice for any comic or manga inspired UI.

This is a HUGE accomplishment as a pack. Thank you so much for taking the time to not only organize all the voice talent, but also the files in an easily understandable way. There's an amazing amount of variety here. Thanks very much for making it!

Ooh this will for sure be handy for any kind of horror or murder mystery style VN. Excellent theming. I feel like you could have fun putting different filtered CGs in the photo buttons on the main menu too. Thank you for making it!

What an excellent pack! I love some good UI SFX, and I'm sure this will help a lot of people get started with adding sounds to their buttons. Thank you for making it!

Hello again! This isn't a feature I'm interested in implementing. You're welcome to grab the code from all examples seen during the tutorial in the labels themselves. All of the ImmersiveParticles declarations and such can be used exactly as-is, including the ones shown via show expression. 

Hello, the latest update to the code puts most of the backend into a namespace where reasonable.

The first one is really out of the scope of what I can help with for this tool. You can potentially look into nearrect for positioning the new screen appropriately, or style your buttons instead of opening a new screen.

For your second question, you can use buttons that have the Scroll action, if I understood you. Generally if they're using the mouse though, it won't make sense to have buttons which set focus elsewhere. You might be better served having a variable keep track of what button is "selected" and style it based off of selectedness rather than hover state. Then you can execute the appropriate button action based on which button is selected.

You're welcome to add back the navigation shortcuts via `key` or similar. You can also adjust the UI shown at the top to style it however you like in the screen itself. And yes, I understood you weren't looking for the name - hence the suggestion to make a dictionary so you can use the name to get a description, or a series of conditions. It's helpful to have the name so you know what image is displaying and can adjust the description accordingly.

Just played the game this was from! Great job on the aesthetics of this, and on the game! Very cohesive 💖

These are excellent! I'm particularly fond of "Swinging that Electro." And thanks for splitting up the tracks too - it's fun to experiment with dynamic audio like that. 

Excellent job with these! I particularly appreciate the time of day variations with the different light reflections. The balcony one reminds me of Cloud's sector 7 room in FF7R 😯 Better view though!

These backgrounds are lovely! I'm particularly fond of the foggy one. Thanks for including the preview PDF also to help choose which images to download.

Very lovely illustration! The texture on the gradient parts in particular gives it a printed-on-paper sort of aesthetic. Thanks for releasing this!