Ren'Py Gripes

[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.

[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]

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!)

[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]

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.

[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.

[jack_norton]

A cool new features:
- drag & drop (yes I know I already asked this, but "repetita iuvant" )
- 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

[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.)

[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

[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.

[PyTom]

"Mark forums read" is right underneath them.

[Aleema]

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 (45.5 KiB) Viewed 152995 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]

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]

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.

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.

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?

[Aleema]

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.