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.
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!
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.
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.
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.
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.
Sure! A ZoomGallery has the method tap_toggle_UI which will hide/show the UI when tapped. It's the default value of the single_tap_event property. At its most basic, that method is just toggling self.show_ui = not self.show_ui. So, you too can make a button with the action ToggleField(zg, "show_ui") in your ZoomGallery.
For your second question, you're welcome to style the screen you set with zg.screen or similar however you like. If you'd like an easy way to get the name/variant number of the currently showing image, you can add the following to the ZoomGallery class (I put it around line 978):
def get_image_name(self):
"""
Get the name of the image currently being displayed by the
ZoomGallery.
"""
return self.unlocked_images[self.current_index].name
def get_image_variant(self):
"""
Return the index of the currently showing image variant.
"""
return self.unlocked_images[self.current_index].image_index
Then you can get the name you declared the image with via zg.get_image_name() and the index via zg.get_image_variant(). Mostly I'm envisioning you could use this information to make a dictionary of the descriptions you want for the images, or just a series of if/else statements.
For the RPA file - there's code at the end of the files that archives it. If you don't remove that, it'll package the files into an rpa file for release automatically.
Hey there! The bubbles assets are not included, but they are CC0 and you can find them at https://cassala.itch.io/bubble-sprites which is linked in the Credits section.