![]() # the player has not explicitly hidden the interface.Ĭonfig.overlay_screens.append("quick_menu") # This code ensures that the quick_menu screen is displayed in-game, whenever Textbutton _("Prefs") action ShowMenu('preferences') Textbutton _("Q.Load") action QuickLoad() ![]() Textbutton _("Q.Save") action QuickSave() Textbutton _("Save") action ShowMenu('save') Textbutton _("Auto") action Preference("auto-forward", "toggle") Textbutton _("Skip") action Skip() alternate Skip(fast=True, confirm=True) Textbutton _("History") action ShowMenu('history') # Ensure this appears on top of other screens. After doing so, it should look something like this. What you’re going to want to do is take the screen out of that if statement block, since you don’t really need it anymore. # If there's a side image, display it above the text. Your Say screen should now look a little something like this. At the very end of this screen, add use quick_menu. Make sure your project is not launched as well.įirst, navigate to your Say screen. Basic Fixįor all of these tweaks, we’re going to be working exclusively in the screens.rpy file, so open that up. But, oh no! When it hides, the quick menu is still there! You want everything gone when you hide that window. You want to hide the dialogue window for something. If I had the ability, I'd ban you from ever touching one of my games, given your obvious lack of respect for the people who create them.You’ve started a new Ren’Py project. What's not right is getting up on a high horse and throwing around personal insults because someone's vision of how their work should be made doesn't exactly match your own preferences. Will it stop some people? Sure, but that's their right. Will I be annoyed if I can't roll back to read something I missed? Sure. ![]() And what about minigames? Rollback could completely confuse any programming related to that.Įven without thinking of all the technical reasons, I think 'artistic vision' is a good enough reason all on its own. There are also scenes with lots of animations that could get destroyed by rollback. My first thought is certain persistent variables that could get really messed up by rollback. There's plenty of legit reasons to disable things like this. That means players can still roll back to read anything they might have accidentally clicked past, but can't use that to change choices. However, if you really do want to keep the players from using rollback to change choices, then it's best to use the first option. Like someone else mentioned, most players are going to abuse saves to get around disabled rollback anyway. Unless you have a really good reason to disable it (like a persistent variable that would mess up really badly if a player rolled over it), then it's best to leave it as-is. Very important to note that most players expect rollback. You could also disable rollback entirely by putting the code define config.rollback_enabled = False at the top of your script. You can also allow rollback, but block players from rolling back past menus. To do that, use something like the example here. The one I recommend the most is setting it so the players can roll back, but can't change choices during rollback. There area a few ways that you can do this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |