Ren'Py 6.12.1 Released

[PyTom]

Ren'Py 6.12.1 "Human Factor" is the first of a series of minor releases focusing on improving the experience of visual novel makers. This release features several improvements to the process of showing images:

* Image attributes make it no longer necessary to specify every part of a changed image.
* The say statement can change image attributes when a character speaks.
* Side images can be specified with the image statement, and can be used with NVL-mode dialogue.
* Sticky transforms allow a transform to continue through an image change.

As these new features can change the behavior of existing games, it may be convenient to disable them for in-development projects. Please see the list of incompatible changes for instructions on how to do this.

The other major improvement is in error handling. Where previous versions of Ren'Py would terminate on errors, 6.12.1 will display a screen that allows the maker to edit problematic files and reload the game, and the user to rollback or ignore the problem.

Ren'Py 6.12.1 also includes many other minor features and bug fixes, please see the full changelog for more details.

Downloads of 6.12.1 can be found at:

http://www.renpy.org/release/6.12.1

A full list of changes to Ren'Py can be found at:

http://www.renpy.org/doc/html/changelog.html

A list of changes that may require you to update your game can be found at:

http://www.renpy.org/doc/html/incompatible.html

[Suikama]

This screens thing is kinda confusing. Caught me off guard when it messed with my menus so I just took out the files, although I kinda wonder what I'm missing out on by doing that...

[PyTom]

I've just released an update, Ren'Py 6.12.1.1500. This fixes an error that some people (likely those using very old ATI drivers) have been getting:

Exception: Shader error: Fragment shader(s) linked, vertex shader(s) failed to link.

I had thought this fixed in the past, but apparently the fix was incorrect. Since this bug renders Ren'Py unusable for some people (without hitting shift at startup), I've decided to make an update. I recommend everyone update - you can do so by hitting shift+U in the launcher, at least for the next few days.

[VenusEclipse]

I really like how the engine handles errors now. Makes testing less tedious. :3

[jack_norton]

Yes the only thing I don't like is that now I have to click "Reload"; while before I could just use shift+R but of course is just a very minor annoyance compared to having to restart testing the game from beginning, in particular when coding complex stuff like RPG engines.
I also think now Ren'Py catches errors better. Before if the error was "nested" it was much less accurate, now seems it always points to the exact line where the error occurs. Thumbs up for this new release!

[PyTom]

Yes the only thing I don't like is that now I have to click "Reload"; while before I could just use shift+R but of course is just a very minor annoyance compared to having to restart testing the game from beginning, in particular when coding complex stuff like RPG engines.

I just fixed that in my development tree. You can fix it too, by adding the lines:

Code: Select all

    if config.developer:
        key "R" action reload_action

To the end of the two screens in common/_errorhanding.rpym.

[jack_norton]

Cool thanks definitely useful!

[jack_norton]

Arghhh BUG!
Whenever I go fullscreen, I see a completely WHITE screen. The music keep going and if I use commands the game is running just fine in background. Then, if I hit F to go back windowed, the whole window remains white.
I tried with 1024x768 games and works fine, but with games using other resolution (1024x576 or even 800x600) I have this bug. I don't know since when I have this problem, since I rarely go fullscreen during a new game development

[Aleema]

Arghhh BUG!
Whenever I go fullscreen, I see a completely WHITE screen. The music keep going and if I use commands the game is running just fine in background. Then, if I hit F to go back windowed, the whole window remains white.
I tried with 1024x768 games and works fine, but with games using other resolution (1024x576 or even 800x600) I have this bug. I don't know since when I have this problem, since I rarely go fullscreen during a new game development

AHH! Same here. Just updated today.
A layer of white was covering everything up, but if I clicked on something (that was supposed to be there) that changed the scene, it faded away. Weird bug.

Also, was xmaximum removed from ui.hbox()? Now my elements fall off the screen instead of overlapping, like they were before (xfill + xmaximum). ;_; If so, which widget can I set the maximum on now?

edit: not getting xmaximum to scrunch up any elements on a ui.frame() either ... was xmaximum's behavior modified? Or did you chop it? I'm going to be playing with this until I get it to work, not with screen language.

Tiny recommendation for the new error screen, which is nice, but originally you could click anywhere on the screen to reload it, and now you have to focus on a small button. Is there anyway to make the reload button larger, since it's likely going to be the most pressed button, ever?

[PyTom]

I think I know what's wrong, and I can repeat it here. I'll fix it once I get the time - probably tonight. (I don't know about Aleema's bugs, but those shouldn't have changed between 6.12.0 and 6.12.1.)

[Aleema]

If it helps, I re-downloaded 6.12.0b and the behavior returned to normal. When I switched back to 6.12.1.1500, it changed again. I have not taken any compatibility measures. Like, I have not turned image attributes off yet. (Can't find the code anymore ... Once I find it, I will update if it fixes this.)

[PyTom]

Okay, I've tracked down the white-screen bug, and 6.12.1.1501 fixes it. Re-downloading 6.12.1 (or updating with shift+U) should fix this. I'll update the website in a little bit to reflect this, but the files are up there now.

Aleema, I think I understand what's happening with your bug. Although I had forgotten in the heat of the moment, I would up redoing hbox and vbox in order to implement the new box_wrap feature. This changed what happens when the box is over-full.

The thing is, the previous behavior (I'm assuming you're talking about the behavior that occured when xfill is True) wasn't intentional on my part, but instead was the result of distributing a negative amount of empty space. The current code is cleaner than the old code, and more featureful, so I really don't want to go back, just to have compatibility with older behavior. So I'm probably not going to change the current (new) behavior.

I think if you want things to squeeze together, the best bet is to use a fixed, and just position everything using xpos and ypos.

Edit: The problems were twofold. The first was a lack of testing for what I though was a minor change - totally my fault. While I tested a little bit, I didn't go through a full test cycle, and so didn't notice the problem manifest. I'm trying to automate more Ren'Py testing, so I can just run a script an look for problems. (This is really difficult, though.) The second was a problem in the release process, which is new, as I'm using branches in a way I hadn't been in the past. I learned from this, and hopefully won't repeat it.

[Aleema]

Thank you for looking into this, sorry I did not test during pre-release.

I appreciate the suggestion, but what I was using the "xfill=True + xmaximum" setup for was to display a variable amount of character sprites depending on the number of members in the player's band. Since the sprite graphics are wide, they should overlap each other if there are more than 2, and you can have as many as 4 band members. So having a fixed position isn't exactly optimal here, especially since the width of each character sprite is different ... Looks like I have to go back to the sloppy coding I thought I got rid of. And now that I think about it, I'm sure I've used xfill+xmaximum in other places as well ... Well, damn it.

But I understand you don't want to revert to older, messier code. Not going to ask for Ren'Py to be changed for wittle ol' me. Maybe an overlapping functionality could be added in the future, though? That was a cool trick. I was happy when I found it. Automatic overlapping is so cool and useful!

edit: I'm probably just going to revert back to an older version and sacrifice the newer stuff for now ... I'll make sure to build future games with this new hbox/vbox in mind.

[PyTom]

Hold your horses. I'm coding.

[PyTom]

A user-defined displayable can be used to get back the old box semantics. Here's OldHbox, which gives back the old horizontal box semantics, as near as I could get them:

Code: Select all

init python:
    class OldHbox(renpy.Displayable):
        
        def __init__(self, children, **properties):
            super(OldHbox, self).__init__(**properties)
        
            self.children = [ renpy.easy.displayable(i) for i in children ]
            self.offsets = [ ]
            
        def visit(self):
            return self.children
            
        def render(self, width, height, st, at):
             
             self.offsets = [ ]             
             renders = [ ]
             
             for c in self.children:
                 renders.append(renpy.render(c, width, height, st, at))

             total_width = 0
             max_height = 0
             
             for r in renders:
                 w, h = r.get_size()
                 total_width += w
                 max_height = max(max_height, h)
                 
             render_offset = (width - total_width) / len(renders)
             
             rv = renpy.Render(width, max_height)
             
             x = 0
             
             for r in renders:
                 w, h = r.get_size()
                 y = max_height - h
                 
                 self.offsets.append((x, y))
                 rv.blit(r, (x, y))
                 
                 x += w + render_offset
             
             return rv
             
        def event(self, ev, x, y, st):

            for c, o in zip(self.children, self.offsets):
                xo, yo = o
                
                rv = c.event(ev, x - xo, y - yo, st)
                if rv is not None:
                    return rv

            return None    

The problem is, this isn't a really good setup - since it's actually wider than xmaximum. So here's a second go at it, which tries to make it so everything fits within xmaximum space. When there aren't enough items to fill the screen, it aligns them on the left side. When it's wider, it spaces them equally - but leaves enough space that the last item is fully shown on the right.

Code: Select all

init python:

    class SquishBox(renpy.Displayable):
        
        def __init__(self, children, **properties):
            super(SquishBox, self).__init__(**properties)
        
            self.children = [ renpy.easy.displayable(i) for i in children ]
            self.offsets = [ ]
            
        def visit(self):
            return self.children
            
        def render(self, width, height, st, at):
             
             self.offsets = [ ]             
             renders = [ ]
             
             for c in self.children:
                 renders.append(renpy.render(c, width, height, st, at))
             
             total_width = 0
             max_height = 0
             
             for r in renders:
                 w, h = r.get_size()
                 total_width += w
                 max_height = max(max_height, h)
             
             rv = renpy.Render(width, max_height)
            
            
             if total_width < width:
             
                 x = 0
                 
                 for r in renders:
                     w, h = r.get_size()
                     y = max_height - h
                     
                     self.offsets.append((x, y))
                     rv.blit(r, (x, y))
                     
                     x += w
             
             else:
                
                lastw, lasth = renders[-1].get_size()                
                spacing = (width - lastw) / (len(renders) - 1)
                
                x = 0
                
                for i, r in enumerate(renders):
                     w, h = r.get_size()
                     x = i * spacing
                     y = max_height - h
                                          
                     self.offsets.append((x, y))
                     rv.blit(r, (x, y))
                          
             return rv
             
        def event(self, ev, x, y, st):

            for c, o in zip(self.children, self.offsets):
                xo, yo = o
                
                rv = c.event(ev, x - xo, y - yo, st)
                if rv is not None:
                    return rv

            return None    

You can use these by adding them to a screen, and giving them a list of the displayables they contain.

Code: Select all

screen test2:
    hbox:
        add SquishBox([ 
            "eileen happy",
            "eileen happy",
            "eileen happy",
            "eileen happy",
            "eileen happy",
            "eileen happy",
            "eileen happy",
            "eileen happy",
            ])