itch.io

Sure thing! It's not a bad feature to have; I suppose my original assumption was that if you had a touch screen device you would need the pinch zoom because you don't have a mouse wheel. But you could have buttons available also. I'll include these changes when I update the tool! There are a few steps to follow in the meantime, all in 01_zoom_viewport.rpy.

First, adjust the line self.touch_screen_mode = renpy.variant("touch") to self.touch_screen_mode = kwargs.get("touch_screen_mode", renpy.variant("touch")) in the init method.

Second, adjust this line in the event method: if inside and ev.type == pygame.MULTIGESTURE: to if inside and ev.type == pygame.MULTIGESTURE and self.touch_screen_mode:

Finally, at the bottom of the renpy.register_sl_displayable("zoom_viewport", ZoomViewport, 'viewport', 1, declaration, add the following, in the same pattern as the earlier properties: ).add_property("touch_screen_mode"

This should make it so that you can manually set touch_screen_mode False as a property of a zoom viewport, to disable touch zoom for all devices. Hope that helps!

If you're having trouble or run into any bugs with the code, post a comment here! I will try to get back to you within a few days.

Yeah this is a weird issue with the Ren'Py engine actually - if it runs into a problem during init, sometimes it still tries running the interaction callbacks, but it hasn't done all the setup (because there was an error) so it runs into a new error in the callback, and reports that instead. Usually this is because you have duplicate label names actually, sometimes due to orphan rpyc files.

You can adjust the function to

def randomize_pronouns_per_line(*args, **kwargs):
    """
    An interaction callback which will randomize the player's pronouns on
    every line, if they have selected that option.
    """
    try:
        if store.pronoun_switch_freq != "line":
            return
        ## Otherwise yes, randomize.
        randomize_pronouns()
    except AttributeError as e:
        ## Typically this occurs if there's an init time error, but should
        ## be passed along so the actual error can be reported.
        pass

and that should at least allow the error to pass through and report what really went wrong.

Internally, the music room uses actions that include SetScreenVariable and similar to set the current_track screen variable to the correct value. When you use it inside another screen, it can't directly access that variable any longer (and would usually need to be accessed via SetLocalVariable or similar). 

Two ways around this - the simplest is just to move the screen variable to your parent screen and pass it into the music room screen e.g.

screen parent_music_room():
    tag menu
    default current_track = music_room.get_current_song()
    use music_room(music_room, current_track)

and then you'll want to update the music room to screen music_room(mr, current_track): and remove the default current_track = ... line from the music_room screen. 

Second would be to adjust your parent screen so it has a transclude statement, and then have the music_room screen use your parent screen and place its contents inside the use block so they're formatted appropriately. Then the music_room screen is the "top level" screen which owns the current_track variable.

Hope that helps!

Heya! The default narrator is declared via a line like define narrator = Character(None, what_style='say_thought') in the engine - aka, it explicitly sets the what_style to say_thought. You will need to do the same if you redefine it.

I just tested a quick 8.5 project and didn't have any problems. Can you try upgrading your engine version? Make sure you've got the backend files in your project, and that you're using the special `music_bar` rather than `bar` for the song progress so that you can click to seek. Let me know if you aren't able to get it working!

Hello! If you'd like to use this tool for titles or names and such, you can, but I'd recommend the built-in outlines for dialogue text or any text-heavy things. Dialogue in particular doesn't like to be shown at a transform so that the text shaders and CPS features can work. The built-in outline property for text includes offsets, and you can supply a list with different levels of opacity or size to create more of a soft blur effect. Hope that helps!

I'm delighted to hear it! Thanks so much for sharing ✨

It should be at the top level, so, not inside a frame. You can certainly adjust the area so it appears to be inside a frame.

For the colour picker - are you using the controller version? I put out an update with color_picker_controller.rpy which you'll need to use if you'd like the bars and color picker navigation to be able to be navigated via controller.

For your screen - I think you'll want something like the event_listener screen in the controller pack, which sits on top of everything. It's added to config.always_shown_screens. If you want this mouse to work everywhere, I believe you will need to grab the mouse events and then send out a modified mouse event, otherwise you are not going to be able to do things like click and drag bars, drag and drop, or viewports. I get around this with the virtual cursor by making it a container you can put the screen stuff inside, because most games won't have a virtual cursor to navigate their entire game, and then I can pass along fake mouse events to the container's children. You're probably going to need to pass along adjusted mouse events to the entire game. I'm afraid this is about the extent to which I can assist you in this matter, however, as your question is no longer related to my tools. 

The virtual cursor isn't receiving mouse input; it's mimicking the functionality of a mouse by navigating around an image (the cursor) that can be used to focus things. If you specifically want a mouse cursor that takes over the usual game's mouse events, it's probably going to need to sit on top of everything and eat pygame.MOUSEMOTION and MOUSEDOWN/UP events so that you can use those events to control your desired mouse functionality. Then, depending on how you have your system set up, you might send modified mouse events back to Ren'Py at your desired coordinates. You will probably need to send some kind of mouse event out to the rest of the UI for things like drag & drop and edgescrolling at minimum, as they're hardcoded to listen for the pygame mouse events.

Most of Ren'Py's code to handle mouse events is in renpy/display/core.py in the Interface class.

Hey there! The stick sensitivity options will work for the virtual cursor as well, so you can adjust it that a small nudge will move the virtual cursor much farther, or that a large nudge will not move it very far if you need slower movement for precision. You can use the StickSensitivityAdjustment class as a bar value as demonstrated in the included preferences example screen.

For the TypeError, I'll direct you to https://itch.io/post/13055124 - specifically that you can remove the _game_menu_screen = "game_menu" stuff or adjust your game_menu screen.

The game directory needs to be in quotes! So, define config.save_directory = "Starcrossed" but specifically I really recommend you add some random numbers like define config.save_directory = "Starcrossed-023894873" because this is a folder that's gonna live on every person's computer who installs your game, and you want to guarantee it's unique.

What do your ATL transforms look like?

To be honest, I'm not sure this is a good use case for the controller viewport, or even a viewport at all. Given the animations you want to do, I'd probably just manually assign left/right to swap whatever card is in the center, and use ATL animations to move them to the right location. The cards wouldn't even need to be buttons; you can just have a variable track which one is selected and perform an action accordingly when the button_select action is performed.

Show the actual code, please.

The example code in the files can literally be copied into your game at whatever point you need it. It is demonstrating exactly how to make the pronoun systems work. You can delete the dialogue lines or change the choice menu text. The important part is the variables which are changed with lines that start with $. There are lots of comments in pronoun_labels.rpy to explain what the lines are doing. Does that answer your question?

What exactly does your code look like?

Ah, you're using a transform that is changing the size of the displayable. Can you try putting it inside a fixed with a set size (the maximum size of the card when it's not being flipped)?

Is it just that the viewport is centering on the button when it's re-selected? Obviously without a visual it's hard to tell; one thing of note is that all grid squares will have the exact same size, which isn't true of hbox, which may be a reason for the discrepancy in behaviour.

I looked more closely into how Ren'Py handles the FileTime time stamps - try changing the get_timestamp function in the backend as follows:

def get_timestamp(self, format=_("%b %d, %Y @ %I:%M %p{#achievement_timestamp}")):
    """
    Return the timestamp when this achievement was granted,
    using the provided string format.
    """
    if self.has():
        format = renpy.translation.translate_string(format)
        return _strftime(format, self._timestamp)
    else:
        return ""

And let me know if that works! 

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.