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.
Post Reply
Message
Author
User avatar
PyTom
Ren'Py Creator
Posts: 16088
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:

Ren'Py Gripes

#1 Post by PyTom »

Here's a thread for gripes about Ren'Py. These are issues that may not rise to the level of a formal bug report, but that are making your life harder when making a game, the sharp edges that need to be filed down.

I can't guarantee that I'll address these immediately. But I do promise to read and consider them.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

fortaat
Regular
Posts: 183
Joined: Tue May 18, 2010 1:16 pm
Contact:

Re: Ren'Py Gripes

#2 Post by fortaat »

Changing the default editor is too complex, and a general pain in the ass.
Could a more simple procedure be implemented, something along the lines of "browse, and choose the .exe of the new editor"?

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Ren'Py Gripes

#3 Post by Jake »

PyTom wrote:Here's a thread for gripes about Ren'Py. These are issues that may not rise to the level of a formal bug report, but that are making your life harder when making a game, the sharp edges that need to be filed down.
Aside from documentation, which I know you're aware of and I realise isn't the easiest thing to just dive into and fix in a weekend, I think the first thing that comes to mind is the behaviour of styles. It's possibly just 'cause I know CSS and got pretty used to it at one point, but it would be nice to be able to have a style for - say - a button, and define things like the colour of a text element inside that button, or the background of the button specifically when it's inside a particularly-styled window, or other stuff like that.

It's often the case that you have to be overly verbose to style up Ren'Py. For example, if you use renpy.display_menu you can set the style for the menu window... but it seems you can't specify the styles for the buttons inside that menu, unless you go and create every element of the menu yourself and assign styles to each element individually. So you end up either having all your menu buttons the same, or writing a lot of boilerplate code/abstracting out your own menu-drawing routings to show differently-styled menus.

Instead, it would be nice to say something like "a button inside a myMenu window will have a background of this frame; a text inside a button inside a myMenu window will have this colour and font".

(Of course, I have no idea how I'd go about writing a syntax to express that, off the top of my head, and equally little idea how would be best to resolve conflicts between style declarations or maintain backwards compatibility!)
Server error: user 'Jake' not found

yummy
Miko-Class Veteran
Posts: 733
Joined: Fri Jul 07, 2006 9:58 pm
Projects: Suna to Majo
Location: France
Contact:

Re: Ren'Py Gripes

#4 Post by yummy »

Maybe if you made use of the same sort of syntax as you see in xml standard, something like anchors...
That's the first thing that comes to my mind actually. Or maybe something close to css stylesheets?

Now that I think about it the default styles provided are already close to that, but since there's no wysiwyg editor, it's bound on trial and errors, which is sometimes a pain since you have to fire up the exe several times in order to get something close to what you want to get.

Strum
Veteran
Posts: 215
Joined: Mon Sep 28, 2009 10:38 am
Contact:

Re: Ren'Py Gripes

#5 Post by Strum »

A minor gripe, not really essential or anything. Its the window icon in the top left corner. When going to fullscreen mode back to windows mode it disappears. I'd like the icon not to do that.
Image

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Ren'Py Gripes

#6 Post by Jake »

Another relatively-minor thing: when using the keys to navigate on-screen UIs, hitting 'up' from the top-most item doesn't reach around the screen and bring you to the bottom-most option. With image-maps and the like it might not be the most intuitive behaviour but it probably wouldn't annoy people either, but with things like menus it's usually expected.
Server error: user 'Jake' not found

User avatar
jack_norton
Lemma-Class Veteran
Posts: 4084
Joined: Mon Jul 21, 2008 5:41 pm
Completed: Too many! See my homepage
Projects: A lot! See www.winterwolves.com
Tumblr: winterwolvesgames
Contact:

Re: Ren'Py Gripes

#7 Post by jack_norton »

A cool new features:
- drag & drop (yes I know I already asked this, but "repetita iuvant" :D)
- would be nice if you could resize the dialogue window after the game has started. nothing fancy but putting commands like style.window.yminimum = 90 would show the effect on the next say statement :)
follow me on Image Image Image
computer games

Spiky Caterpillar
Veteran
Posts: 253
Joined: Fri Nov 14, 2008 7:59 pm
Completed: Lots.
Projects: Black Closet
Organization: Slipshod
Location: Behind you.
Contact:

Re: Ren'Py Gripes

#8 Post by Spiky Caterpillar »

Styles can be changed at run-time, you just need to call style.rebuild() afterwards (though the fact that they aren't savable may mean that style-changes don't play nicely with rollback - I haven't used run-time style changes since before 6.11 testing started, though, so don't remember the details.)
Nom nom nom nom nom LEAVES.

User avatar
jack_norton
Lemma-Class Veteran
Posts: 4084
Joined: Mon Jul 21, 2008 5:41 pm
Completed: Too many! See my homepage
Projects: A lot! See www.winterwolves.com
Tumblr: winterwolvesgames
Contact:

Re: Ren'Py Gripes

#9 Post by jack_norton »

yes I actually discovered that command today and works, but indeed I don't want to use something that is not really "standard" to avoid potential bugs :)
follow me on Image Image Image
computer games

Mikan
Veteran
Posts: 364
Joined: Sun Dec 23, 2007 12:20 am
Contact:

Re: Ren'Py Gripes

#10 Post by Mikan »

I am greatly annoyed that there is not "Mark all threads as read" next to

View unanswered posts | View active topics

in these forums.

User avatar
PyTom
Ren'Py Creator
Posts: 16088
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

#11 Post by PyTom »

"Mark forums read" is right underneath them.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

User avatar
Aleema
Lemma-Class Veteran
Posts: 2677
Joined: Fri May 23, 2008 2:11 pm
Organization: happyB
Tumblr: happybackwards
Contact:

Re: Ren'Py Gripes

#12 Post by Aleema »

Mikan wrote:I am greatly annoyed that there is not "Mark all threads as read" next to

View unanswered posts | View active topics

in these forums.
markforumsread.jpg
markforumsread.jpg (45.5 KiB) Viewed 83865 times
Though that's more of a LSF thing than a Ren'Py thing. It's not THAT far from what you're talking about.

My "gripes" are not really Ren'Py gripes, just Python stuff. So I won't post thoses. My wishlist is to have some sort of way to display two text boxes at once, but I'd only use it once or twice, so it's not that big of a deal. I think you're already working on something that could do that anyway. ui.grid is a pain in the side, but a necessary evil sometimes but I don't know if there's a way to make that easier. Would be nice if there was a more hard-coded way of controlling when the text box was present and not. I know there are "hacks" to do that, but that particular code has been a pain to deal with in the past. There are plenty of times when I think to myself about how dissolve erases all widgets from the screen, and I'd rather them not, though if there can only be one default, you picked the right one.

Uh ... um. I second making switching the default editor more easy and explicit. Some widgets cannot be shown in scrollable viewports, like ui.bars if I remember correctly. If they're drawn off screen, they will never be visible (goes the same if I do a vbox near the bottom of the screen and alter the ypos of a ui.bar above the cutoff - no show). You've fixed a lot of stuff I would have normally griped about, so it's hard for me to think of any more.

Mikan
Veteran
Posts: 364
Joined: Sun Dec 23, 2007 12:20 am
Contact:

Re: Ren'Py Gripes

#13 Post by Mikan »

I must be going nuts because I can't find it.
Oh.. Oh I see. AH there we go. No more orange juice note papers. I feel my sanity returning.
Thanks a bunch y'all. Keep up the fine work.

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Ren'Py Gripes

#14 Post by Jake »

Aleema wrote: ui.grid is a pain in the side, but a necessary evil sometimes but I don't know if there's a way to make that easier.
On that note, it would be nice to have a widget which is like ui.grid, but doesn't force the same cell size - only that all items in the same row have the same height, and all items in the same column have the same width... I guess you can usually do this with hboxes and vboxes, especially since you'll usually know how big your elements are going to be, but it would make creating UIs easier.
Aleema wrote: Would be nice if there was a more hard-coded way of controlling when the text box was present and not. I know there are "hacks" to do that, but that particular code has been a pain to deal with in the past.
IME you can use a combination of 'window hide' and 'window show', and store._window_during_transitions fairly reliably...

It'd be nice if the automatic hiding and showing of the text box during transitions also used the transitions defined for the explicit hide and show, though.
Aleema wrote: There are plenty of times when I think to myself about how dissolve erases all widgets from the screen, and I'd rather them not, though if there can only be one default, you picked the right one.
Is this just a case of drawing your UI to a layer that isn't in config.transient_layers? By default UI widgets are drawn to 'transient', IIRC, which automatically gets cleared down on every transition. If you add an extra layer into config.layers and then use ui.layer or create the Displayable versions of the UI widgets you want to use and then pass the 'layer' parameter to renpy.show, then you can definitely have UI widgets on-screen that survive dissolves or any other kind of transition/interaction...

Or maybe config.overlay_during_with?
Server error: user 'Jake' not found

User avatar
Aleema
Lemma-Class Veteran
Posts: 2677
Joined: Fri May 23, 2008 2:11 pm
Organization: happyB
Tumblr: happybackwards
Contact:

Re: Ren'Py Gripes

#15 Post by Aleema »

Jake wrote:Is this just a case of drawing your UI to a layer that isn't in config.transient_layers? By default UI widgets are drawn to 'transient', IIRC, which automatically gets cleared down on every transition. If you add an extra layer into config.layers and then use ui.layer or create the Displayable versions of the UI widgets you want to use and then pass the 'layer' parameter to renpy.show, then you can definitely have UI widgets on-screen that survive dissolves or any other kind of transition/interaction...

Or maybe config.overlay_during_with?
Huh. I probably should have thought of this, since I've worked with layers before -- and I know all too well that they'll stay on the screen no matter what the hell you do. I think it's a little more contrived then I would like it to be, so I'll keep it on the gripes list for now, but I'll mess with layers and see if it gives me the desired effect.

Post Reply

Who is online

Users browsing this forum: No registered users