Ren'Py Gripes

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Message
Author
verysunshine
Veteran
Posts: 337
Joined: Wed Sep 24, 2014 5:03 pm
Organization: Wild Rose Interactive
Contact:

Re: Ren'Py Gripes

#511 Post by verysunshine » Sat Jun 06, 2020 3:18 pm

These are a few very small gripes, but:

- When a game is created with a light-coloured GUI, idle choice menu text is white on a white background.
- By default, text and idle textbuttons without a style are the same colour as the placeholder background.
- black_color is set to #FFFFFF by default with some GUIs.
- With Ren'py Web, would it be possible to put index.html one folder up from everything else? I have to pull it out manually.

Build the basics first, then add all the fun bits.

Please check out my games on my itch.io page!

User avatar
SypherZent
Veteran
Posts: 322
Joined: Fri Sep 02, 2016 3:14 am
Completed: Multiverse Heroes, Space Hamster in Turmoil
Soundcloud: Chrysopoeist
Location: Puerto Rico
Contact:

Re: Ren'Py Gripes

#512 Post by SypherZent » Sat Oct 17, 2020 8:56 am

I have some gripes to list... I give Ren'Py controller support a rating of 2 out of 10.
It needs to be more intuitive for us developers. It should be nearly plug-and-play.

As it is, I've had to ask three questions today regarding things that should be basic, in fact, they should be how the engine works. For example, pressing DOWN to sort through items in a viewport should automatically scroll the viewport down. Currently, it totally ignores that there is more content in the viewport. The engine doesn't provide the tools to run custom functions to move the ui.adjustment as well as perform the normal config.keymap functionality for focus left/right/up/down, yet another question I had to ask (and now wait for an answer).

Other issues:
1) repeat_K_PAGEDOWN does not work. repeat_K_PAGEUP does not work.
2) You can't use repeat_ on gamepad things like Analog Axis events for when you hold down the analog sticks, which is intuitive universally (joysticks are to be held down, not pressed many times up/down like a dpad).
3) You cannot list more than one keysym (one for keyboard, one for controller), which is stupid because naturally (and obviously) there are 3 possible inputs: Controller, Keyboard, Mouse clicks.
4) Also, default_focus and focus break really wildly given certain conditions.

I don't mean to offend anyone, but the current system is nowhere near user-friendly. And I've been working with Ren'Py for 3 years and thousands of hours, over a dozen games coded for clients and myself (so I'm not a 'noob' at this stuff). It shouldn't be so difficult to implement basic controller support to the various screens in the game.

The full controller handling (and by default, keyboard handling) should be rewritten, needs to be rewritten, in my humble opinion.

Unfortunately I don't have the time to freely (i.e. free of charge) contribute specific code examples where these things break. My time and health and finances are limited, so I'm posting my gripes here to bring awareness to the fact that these things do not work in a user-friendly/intuitive manner, so that maybe one of the people who actively develop Ren'Py can take their precious time to try and add improved controller support for things like viewports where the native functionality is failing.

User avatar
Kia
Miko-Class Veteran
Posts: 959
Joined: Fri Aug 01, 2014 7:49 am
Deviantart: KiaAzad
Skype: KiaAzad
Contact:

Re: Ren'Py Gripes

#513 Post by Kia » Sat Oct 17, 2020 1:20 pm

SypherZent wrote:
Sat Oct 17, 2020 8:56 am
1) repeat_K_PAGEDOWN does not work. repeat_K_PAGEUP does not work.
2) You can't use repeat_ on gamepad things like Analog Axis events for when you hold down the analog sticks, which is intuitive universally (joysticks are to be held down, not pressed many times up/down like a dpad).
In my opinion we need an easy way to use `KEY_DOWN` and `KEY_UP` events instead. specially in screens, just this change can improve interface interaction and minigame development by few folds.
SypherZent wrote:
Sat Oct 17, 2020 8:56 am
4) Also, default_focus and focus break really wildly given certain conditions.
I agree.
Renpy is in desperate need of something that lets the developers decide: in which order the buttons should gain focus.
I think I've tried to give a number to `default_focus` but it didn't even bothered to throw me an error.
SypherZent wrote:
Sat Oct 17, 2020 8:56 am
The full controller handling (and by default, keyboard handling) should be rewritten, needs to be rewritten, in my humble opinion.
Keyboard is easy, I've re-binded the keys in a file that I add to all of my projects. unfortunately, couldn't get any gamepad working with renpy to do the same.
SypherZent wrote:
Sat Oct 17, 2020 8:56 am
Unfortunately I don't have the time to freely (i.e. free of charge) contribute specific code examples where these things break. My time and health and finances are limited, so I'm posting my gripes here to bring awareness to the fact that these things do not work in a user-friendly/intuitive manner, so that maybe one of the people who actively develop Ren'Py can take their precious time to try and add improved controller support for things like viewports where the native functionality is failing.
I would be happy to contribute to the code and fix those issues, but the problem is: I don't know which files to edit and where to start. there is a gap of information that separates the inner workings of renpy from the common use. maybe a footnote at the bottom of each documentation page that points out which files to edit to expand or modify the functionality of the expressions in that page can be a gateway that brings in more developers.

User avatar
SypherZent
Veteran
Posts: 322
Joined: Fri Sep 02, 2016 3:14 am
Completed: Multiverse Heroes, Space Hamster in Turmoil
Soundcloud: Chrysopoeist
Location: Puerto Rico
Contact:

Re: Ren'Py Gripes

#514 Post by SypherZent » Tue Oct 20, 2020 6:03 am

Thanks for the feedback, Kia.

It would also be a huge help if the documentation at https://www.renpy.org/doc/html/keymap.html explained which button each of the Ren'Py buttons corresponds to on each possible controller (XBox, PS4, NS) since all controllers have their own names for the buttons.

Related post here: viewtopic.php?f=8&t=60402

Ren'Py uses its own names for the buttons and the Ren'Py names match none of the platforms (i.e. the 'guide' button doesn't exist in XBox, PS4, NS terminology, they each have their own names for these buttons which confuses developers).

I feel the documentation should be explicit and clear about this, otherwise each and every developer loses time on trial and error and asking on forums for help.

User avatar
SypherZent
Veteran
Posts: 322
Joined: Fri Sep 02, 2016 3:14 am
Completed: Multiverse Heroes, Space Hamster in Turmoil
Soundcloud: Chrysopoeist
Location: Puerto Rico
Contact:

Re: Ren'Py Gripes

#515 Post by SypherZent » Wed Oct 21, 2020 9:41 am

This is the last I'll post complaining about controller support. Stuff I've programmed is literally not running. It works and then it stops working. I've debugged everything.
Controller support for Ren'Py is broken and unreliable outside of the most simple cases.

Since the engine is intended for Visual Novels and not games that are more complex, I doubt it will ever get fixed.
But I felt I should voice my gripe anyway since I do have hope that someday someone will give Ren'Py controller support the care it needs.

Edit to add: The problem with unresponsive controls is linked to a severe bug with keyboard_focus, where you set keyboard_focus to None and the button is still able to be highlighted by a controller or keyboard press. This only occurs when the button is the first button defined within a screen. Moving the button's definition to the end of the screen (after other buttons that do allow keyboard_focus are defined) solves the problem. As I said above, controller support needs some serious revisiting by the Ren'Py dev team. This has cost me many precious hours of my week and very well may delay my Early Access release schedule.
Last edited by SypherZent on Thu Oct 22, 2020 8:33 am, edited 1 time in total.

User avatar
PyTom
Ren'Py Creator
Posts: 15642
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Gripes

#516 Post by PyTom » Wed Oct 21, 2020 6:12 pm

The binding between controller buttons and symbols is configurable in the gamepad rebinding screen, which is available through shift+G, Calibrate. There isn't a lot of work being done here at the moment, as there are higher priority things that I'm working on. To some extent, what Ren'Py has is a thin wrapper over what SDL provides, which is basically xinput.

In general, controllers and viewports working together is a tough problem, and one I don't have good ideas about how to address. I tend to think there isn't actually a good solution to this, and the right way to do it is at the screen level - that is, to have screens that don't require viewports, but use buttons to navigate from one screen to the next.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

User avatar
SypherZent
Veteran
Posts: 322
Joined: Fri Sep 02, 2016 3:14 am
Completed: Multiverse Heroes, Space Hamster in Turmoil
Soundcloud: Chrysopoeist
Location: Puerto Rico
Contact:

Re: Ren'Py Gripes

#517 Post by SypherZent » Thu Oct 22, 2020 8:28 am

I've already worked out all of the kinks after a few dozen hours, thankfully.

I also have the solution for you. The major problems arise when more than one screen is displayed.

Example:

MainScreen - Has key button action (Action) setup for most controller/keyboard/mouse input.
Then, while MainScreen is shown, I call another screen.

The controls don't work properly for the new screen while MainScreen is shown. Right now, it's actually unpredictable. It breaks worse if you call the other screen while holding the joystick or pressing the dpad in any direction. You have to press the button to call the new screen without touching the joystick or dpad.

The solution is for the engine, internally, to ignore all controls for MainScreen while the new screen is called ONLY IF MODAL IS TRUE.
Modal True should be telling the engine that this new screen takes priority over all other screens and it is not working that way in the context of controller support.

If the new screen could be treated as if nothing else exists (only while modal is true, because MainScreen functions with about 10-20 other screens at the same time, this only has to work for screens where Modal is true), then it would entirely solve the problem, at least, 90% of the problems that I personally experienced while adding Full Controller support to my game.

This solution I have provided actually works for 99% of the issues I had to find other ways of working around. The other 1%, I had to code my whole gameplay a 2nd time in a method that works exclusively for controller, but that was already to be expected as the current method revolved around mouse too much.

On a side note, it would also be helpful to have a new focus keyword for buttons, to be able to force the engine to target certain focusable buttons (like default_focus, but one that actually works because default_focus is very faulty and not reliable possibly due to what I described above). And, more importantly, a new screen action so we can manually define a button to change focus (i.e. we need the ability to call focus_left, focus_right, etc. via screen actions)...this screen action would allow the player to just press left/right whenever the game breaks and it would have been a huge solution that would have saved me roughly 26 labor hours.

I hope this info helps.

I'm disappointed that there are more important things on your list, as these are not so much features I am requesting but workarounds to critical bugs that should be addressed immediately IMHO, but since I was able to work around them myself it doesn't really affect me anymore. I just feel bad for anyone else who will have to go through the horror I experienced this week. In any case, I've provided all the info I can, if you need more just let me know (you can reach me on Twitter fastest).

(And thanks for your reply ^^)


EDIT: In case you think I'm crazy, here is a post that described focus functionality being totally broken (from TWO years ago).
https://f95zone.to/threads/unable-to-ge ... ton.16182/
I am still wrestling with the flaws in Ren'Py's controller support because it extends to keyboards (testers found more bugs), after 50 labor hours this week.
As I mentioned before, I rate it 2 out of 10. I don't say that lightly. I sincerely hope you move this to your priority list before more people are affected. I don't think everyone has >50k hours experience coding in over a dozen languages in order to work around these issues themselves the way I've had to do through sheer brute force, trial-and-error, and willpower (and I've almost run out of willpower).

To look at the bright side, though, I had posted regarding protecting the source code of my game thinking someone could just steal and image-swap. I guess all of these workarounds I've had to do will help to prevent that, too, since most people probably won't understand why I coded them in the first place haha. Just waiting on the help to make sure no more bugs surface with keyboard or controller, so I can finally be done with this.

User avatar
gas
Miko-Class Veteran
Posts: 838
Joined: Mon Jan 26, 2009 7:21 pm
Contact:

Re: Ren'Py Gripes

#518 Post by gas » Mon Nov 23, 2020 4:10 am

SypherZent wrote:
Thu Oct 22, 2020 8:28 am
STUFF
Sorry, but if your game is actually requiring a controller, it probably goes beyond the standard of a VNL, and so you're messing with the wrong engine.

The fact controllers are not a priority is a matter of ergonomy. Now probably you don't know being here JUST 3 years, but there was a war to introduce the history screen even if rollback was better. Why? Japanese users didn't understand the mechanic and expected for any VNL to work like... any other VNL. With the history screen. In the end, they won.

Renpy is not the "open source game framework", is a way to easily convey VNL standards. As VNL doesn't strictly require a controller, doesn't strictly require multiple contemporary selection screens, doesn't strictly need continual scrolling by analog sticks, doesn't require such stuff, such stuff is late in the priority schedule.

An hint about such logic could have been the fact controllers are quite hidden and quite not supported... While you got Live2D engine support (that now is a standard for VNL).
Being the screens mostly static, the thing you posted is also a strange case of self-injury: who was the stupid that put a button in astatic screen that the engine can't hilight? The engine or the designer?

The CDD fake people into believing renpy is a fullfledged game engine.
It isn't at all.

I tell you so, so the next time instead of messing with RENPY, you mess with PYGAME, that's actually what you're trying to do the longer way :). What you think all such CDD are?
If you want to debate on a reply I gave to your posts, please QUOTE ME or i'll not be notified about. << now red so probably you'll see it.

10 ? "RENPY"
20 GOTO 10

RUN

User avatar
SypherZent
Veteran
Posts: 322
Joined: Fri Sep 02, 2016 3:14 am
Completed: Multiverse Heroes, Space Hamster in Turmoil
Soundcloud: Chrysopoeist
Location: Puerto Rico
Contact:

Re: Ren'Py Gripes

#519 Post by SypherZent » Fri Dec 04, 2020 1:04 pm

gas wrote:
Mon Nov 23, 2020 4:10 am
Sorry, but if your game is actually requiring a controller, it probably goes beyond the standard of a VNL, and so you're messing with the wrong engine.
Yes, my game does go beyond the standard of a VNL.
It does not require a controller, but providing Full Controller Support meets a higher quality standard, which is my intent. Some consumers prefer using a controller instead of Keyboard and Mouse. Full Controller Support was simply one of the goals of the Early Access Roadmap for the game's development.

gas wrote:
Mon Nov 23, 2020 4:10 am
who was the stupid that put a button in astatic screen that the engine can't hilight?
The Engine highlights the button fine until a new screen with modal True is called, then things break.
Also, using keyboard_focus set to None is broken if the button with keyboard_focus set to None is listed first in the screen code (it still gets highlighted).
You have no idea what you're talking about. Either your English isn't that good, or your reading comprehension needs some improvement.
These issues would affect Visual Novels, just as they would affect any other game using Screen Language.

Renpy.org wrote:The easy to learn script language allows anyone to efficiently write large visual novels, while its Python scripting is enough for complex simulation games.
As it says on Renpy.org "its Python scripting is enough for complex simulation games".
And I'm developing a complex simulation game.

What I'm developing is besides the point of Ren'Py not working as intended.
PyTom already knows what game I am developing, as I sent him a Steam key prior to posting on this thread. He knew before he responded...

And I've already proposed solutions to each of the problems I discovered (the most notable being that controller should respect the screen that has modal True and ignore all others while this screen is displayed, as I mentioned above). These problems will affect VN devs at some point or another. I have also linked a forum showing that these problems have already affected Visual Novel devs in the past.

gas wrote:
Mon Nov 23, 2020 4:10 am
Now probably you don't know being here JUST 3 years
In those 3 years, I've programmed over a dozen games, counting my own as well as games for many clients.
I bet I know more about the functionality of this engine than you, as I've spent more than 8000 labor hours with Ren'Py in those 3 years.


My posts are right on topic (Ren'Py Gripes). If you have nothing constructive to contribute to the conversation, don't post anything.
Just read it and keep browsing the web elsewhere.


On a side note, I already released the Full Controller Support update for my game. And the controller support I released is better than other hugely successful titles of the same genre, including games made in Unity and other game engines. So, I'm here to post feedback for Ren'Py to be improved for other devs to not have to face the same issues I faced. I already solved my game's issues with testers helping me. My posts here are mainly intended to help others, in case anyone decides to take the initiative and improve the engine based on my feedback.

User avatar
midgethetree
Regular
Posts: 25
Joined: Wed Dec 30, 2020 3:51 pm
Completed: Appetité Amor, The Mother of Pearls
Projects: Anise Flowers, When Everyone's Watching
Github: midgethetree
itch: midge-the-tree
Contact:

Re: Ren'Py Gripes

#520 Post by midgethetree » Mon Jan 11, 2021 8:34 pm

My small gripe is that currently

Code: Select all

Preference('self voicing', 'toggle')
Preference('clipboard voicing', 'toggle')
Preference('debug voicing', 'toggle')
is equivalent to

Code: Select all

ToggleField(_preferences, "self_voicing")
ToggleField(_preferences, "self_voicing", true_value="clipboard")
ToggleField(_preferences, "self_voicing", true_value="debug")
This means turning on clipboard/debug voicing also sets the normal self-voicing toggle button as selected, and toggling off clipboard/debug voicing (say, using shift+c) sets self_voicing to None instead of False which means buttons using Preference('self voicing', 'disable') aren't selected.

I think it'd be better if they were instead equivalent to:

Code: Select all

ToggleField(_preferences, "self_voicing", true_value=True, false_value=False)
ToggleField(_preferences, "self_voicing", true_value="clipboard", false_value=False)
ToggleField(_preferences, "self_voicing", true_value="debug", false_value=False)
so turning them off sets self_voicing to False instead of None, and Preference('self voicing', 'toggle') is only selected if the value of self_voicing is True. That feels more consistent with how the 'enable' and 'disable' self voicing preferences work.

User avatar
PyTom
Ren'Py Creator
Posts: 15642
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Gripes

#521 Post by PyTom » Sun Jan 17, 2021 1:33 am

midgethetree wrote:
Mon Jan 11, 2021 8:34 pm
My small gripe is that currently
...
I agree, and this change will be in 7.4.1.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

User avatar
Kia
Miko-Class Veteran
Posts: 959
Joined: Fri Aug 01, 2014 7:49 am
Deviantart: KiaAzad
Skype: KiaAzad
Contact:

Re: Ren'Py Gripes

#522 Post by Kia » Sun Jan 17, 2021 3:32 am

I often wish I could apply general style to the content of a screen using either `style_prefix` or something similar

Code: Select all

screen nvl(dialogue, items=None):
    style_prefix "nvltest"
    ...
style nvltest_all:
    align (.5,.5)
    
Like how changing the default style works but limited to specific screens

User avatar
PyTom
Ren'Py Creator
Posts: 15642
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Gripes

#523 Post by PyTom » Sun Jan 17, 2021 10:50 am

I'll look into this at some point, but for now there's a simple workaround:

Code: Select all

screen nvl(dialogue, items=None):
    fixed:
        style_prefix "nvltest"
        ...
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
"Silly and fun things are important." - Elon Musk
Software > Drama • https://www.patreon.com/renpytom

tnoDcinaP
Newbie
Posts: 2
Joined: Fri Mar 05, 2021 8:06 am
Contact:

Re: Ren'Py Gripes

#524 Post by tnoDcinaP » Sat Mar 13, 2021 3:21 pm

Hi,

This may be more of a minor feature enhancement than a gripe.

NVL page “scroll” action is implemented as an instant jump and I don’t find it usable. Compare ebooks where PageDown scrolls smoothly with "ease" interpolation.
I was surprised that despite extensive search, I could find no discussion of this. My use case of presenting several pages of NVL to scroll through may be unusual - but that may itself be partly because the NVL page scrolling UX is not easy.
(My NVL segments use a draggable VP scrollable with a vbar. NVL sayers have interaction = False. Each NVL segment is several pages of dialogue followed by a menu at the bottom and occasionally with an inline image. The user scrolls through the pages and interacts with the menu at the end – without having to CTC after every single paragraph)

My very limited understanding of the ui. adjustment/ edgescroll code suggests no technical obstacles to future implementation of an option for smooth PageDown scrolling in RenPy as standard – albeit well beyond my abilities.

Generalisation would be interpolate option(s) for all page-scroll/ step scroll actions.

Thoughts? Thanks.

User avatar
zmook
Regular
Posts: 170
Joined: Wed Aug 26, 2020 6:44 pm
Contact:

Re: Ren'Py Gripes

#525 Post by zmook » Thu Mar 18, 2021 11:19 pm

ATL is hard to read when the animation gets at all complex:

Code: Select all

transform rise_and_fade(x=0.5, y=0.5, delay=0):
    align (x,y)
    linear 0.25*announcer.rise_time  yanchor 0.625  ypos y+0.25*(announcer.yalign_end-y)
    linear 0.75*announcer.rise_time  yanchor 1.0  ypos announcer.yalign_end  zoom 1. alpha 0.
It would be a lot more readable if I could line break those `linear` statements, but warpers don't accept blocks and line-continuation backslashes are syntax errors.
colin r
➔ if you're an artist and need a bit of help coding your game, feel free to send me a PM

Post Reply

Who is online

Users browsing this forum: No registered users