Ren'Py 6.11.0 Public Pre-Release

[Mihara]

...and another one.

When I define a "screen yesno_prompt" all the yes-no prompts resulting from screens that I have overridden conform to the defined screen.

Except the one yes-no prompt that results from clicking the OS window close button. That stays default as it was and won't change. Ways to override that one prompt through screens are not documented as far as I can see.

[backansi]

ui.imagemap doesn't work in 6.11.0f. It just shows the ground image, and can't be dismissed.

[PyTom]

How are you using ui.imagemap? It was never documented, so it changed behavior in 6.11, with the old version being renamed to ui.imagemap_compat.

[backansi]

How are you using ui.imagemap?

Code: Select all

label start:
    $ ui.imagemap('ground.jpg', 'hover.jpg', [(100, 100, 300, 400, "eileen"), (500, 100, 700, 400, "lucy")])
    $ ui.close()            
    $ d = ui.interact() 

I've just tested this and that to find difference between older version and new one to rewrite some guides that I've written for korean renpy users.
And I thought it would work fine because I could not find this problem in incompatible changes document.

It was never documented, so it changed behavior in 6.11, with the old version being renamed to ui.imagemap_compat.

Ah-ha. So I should edit guides about that, then.
(and the changed behavior, it could be documented in new renpy documentation, right? The older reference just says it has same parameters as renpy.imagemap.)

[Mihara]

NVL mode needs more love.

Code: Select all

init:

    $ e = Character('Eileen', color="#c8ffc8", kind=nvl)

    image bg red = Solid("#f00")
    image bg blue = Solid("#00f")
    
    python:
        config.window_hide_transition = pixellate
        config.window_show_transition = pixellate

label start:

    scene bg red
    
    e "In this example, the NVL window is supposed to hide before the following dissolve - with a pixellate. At least, that's what you would expect, right?"
    
    show bg blue with dissolve

    e "As you can see, nothing gets pixellated, NVL window ignores config.window_*_transition setting."

[Jake]

Code: Select all

    e "In this example, the NVL window is supposed to hide before the following dissolve - with a pixellate. At least, that's what you would expect, right?"

As it goes, have you tried that outside of NVL mode? Last time I checked (pre 6.11), it didn't use those transitions for the ADV-style window either. Not unless you explicitly used 'window hide' and 'window show'.

I assumed it was because otherwise, a half-second transition might take three times as long 'cause Ren'Py was waiting for the text box to move in and out as well, although I agree that it would be preferrable if it was at least an option to have the window transitions occur when it was hidden for any reason, by any method...

[shahab96]

There seems to be something wrong with my screens.

Code: Select all

label start:
    stop music
    $ h_aff=0
    $ r_aff=0
    $ povname = ""
    $ is_male = True

screen menu_001:
        window:
            background "#000000"
            
        frame:
            align (0.5, 0.5)
            
            has vbox
            
            text "Choose your gender"
            # I commented these out because I wanted to show you what exactly I needed, but the code dosn't actually work
            # textbutton _("Male") action is_male=True
            # textbutton _("Female") action is_male=False
    
screen input_screen:
        window:
            background "#000000"
          
        frame:
            align (0.5, 0.5)
            
            has vbox
            
            text "And what would you like your name to be?"
            input

When I select start game from the main menu it goes simply fades out and fades back in. I think it is because it doesn't even see my screens and there is no "jump chapter1" since i deleted it from this page. The code above is the entire page on which "label start" is located. Is it a ren'py problem, or am i just being noob again?

EDIT: Also, how can I set the string inputted from "screen input_screen:" above into the variable povname?
EDIT AGAIN: Ok, the screens weren't showing because i was being noob...but when i use

Code: Select all

show screen input_screen

and run the game, the screen will come for exactly 1 second and then fade out to the main menu.
One more edit: I just noticed this, but if you leave the input above blank, it will fade out, then fade back in, and then it will take the input until you press enter. Earlier I was trying to type my name before the screen faded out, lol.

[jack_norton]

I found a minor alignment bug. My code is very simple:

Code: Select all

            ui.hbox(2,xalign=0.5)
            for i in range(len(Party)):
                with ui.vbox(xmaximum=235,xfill=True):
                    if tmpHero[Party[i]][2]>0:
                        ui.image("gfx/rpg/"+Hero[Party[i]][0]+".png",xalign=0.5)
                    else:
                        ui.image(im.Sepia("gfx/rpg/"+Hero[Party[i]][0]+".png"),xalign=0.5)

if the hero has HP>0, was active when battle ended. If not, was KO so doesn't get experience and is displayed with the Sepia image manipulator. The problem is that the alignment seems wrong:

the one in the middle was KO, and as you can see, is not centered like the others.

[Spiky Caterpillar]

When Ren'Py starts, switches modes, or the window is moved, occasionally it will fail to render the cursor. When it does this, button highlights appear to respond to mouse motions, but no cursor graphic is drawn. If I'm in windowed mode, the cursor will reappear once you move it onto the window manager's window border (or beyond the window border), and once it's reappeared it stays visible. If letterboxing black borders are present, moving the cursor onto them does not make it reappear.

I can reproduce it by moving the window around manually several times until the cursor disappears, or by switching into and out of full screen mode repeatedly until the cursor disappears. The offending test machine is the usual debian testing amd64 dual-core box, using a 6.11.0f game started from the launcher. I'm not using a custom cursor.

[Mihara]

Cute little bug. Hard to make a reproduction example for, because of the proportional fonts. (that is, I can show the code but that would involve uploading the font and a lengthy definition of my font parameters to hit on a specific case)

NVL mode, character object has a defined what_suffix (a Unicode closing quote symbol). Said suffix can get wrapped onto the next line if the line ends with "{i}word?{/i}" and has an NVL page end ctc indicator after it.

I'm not sure which is to blame, but here's a few possibilities:

• The closing tag of the italics is detected as a spurious whitespace.
• Same happens to the question mark.
• It just naturally happens with the suffix.
• The most likely one -- Unicode characters \u201c and \u201d are not disallowed for wrapping when they should be or are otherwise treated as whitespace.

Can we have that bit customizable with a config or style option? That would prevent similar problems in the future in a generic way.

[PyTom]

Jack >>> That's not a behavior change. ui.image only applies properties if it creates a new image. im.Sepia is already an image, so we ignore the property. (If you add it to im.Sepia, then you're fine.)

Spiky >>> I can't repeat this. What window manager are you using?

Mihara >>> The closing tag of the italics is the problem. I won't address this until I rewrite Text, which is something I'm scheduled to do.

[Jake]

A couple of graphical problems, all witnessed on OSX using the latest version (I literally downloaded it about ten minutes ago):

This first one shows a grid which is too wide to fit on the screen... but in full-screen mode, it spills over into the pillarbox area:

Grid Displayable too wide for screen spills outside of display area in fullscreen

The too-wide grid shows even in the game menu (I guess this is to be expected, but still...):

A too-wide Grid showing past the game menu

The second problem is when I have an entirely black BG, fullscreen again:

Fullscreen + black BG = not entirely black

Right up against the edge of the display area, just inside of the pillarbox, there's a single-pixel line of grey either side; here it is zoomed in 400%:

screen3b.jpg

4x zoom of border problem

(10.3 KiB) Not downloaded yet

Looking closely at it, it actually alternates between two shades, which leads me to believe it may be the new transparent-background showing through. I suspect this probably means that the big quad/whatever for the Solid BG is being drawn slightly too small...




The first problem was caused by creating a 'Grid' displayable and populating it with Text displayables which happened to be wide enough to not all fit on-screen at once. (I don't know if this is also a bug, since it's placed inside a Window which in turn is drawing only so wide as the screen - it's the same Window which has that blue graphic in a Frame for its BG.
(On the subject of Grid, I noticed the Displayable still isn't documented; is that intentional? Should I not be using it? I inferred that it must be there just 'cause ui.grid existed and all the other ui functions have Displayable equivalents. I also notice that despite there being no param to tell it to do that, and no mention of such behaviour in the ui.grid docs, it seems to be sizing itself so that all the columns are the same width... is that intentional?)

The second problem was as simple as:

Code: Select all

init:
  image bg black = Solid("#000")
label start:
  scene bg black

The Grid behaviour is identical in 6.10, with the obvious exception that it doesn't draw off-screen because it can't; the BG problem is new for 6.11.

[Mihara]

Can confirm the grey line.

In fact, on extreme zooms (480=>1200, which is the fullscreen on my 1920x1200 monitor) small errors seem to crop up which cause edges of images to be off by one real, rather than native, pixel, readily visible when I'm overlaying a fullscreen transparent image over a scene which already contains smaller sprites -- then their bottom edges peek out from beneath the edge of the fullscreen image during some scenes.

[PyTom]

Jake - I can't repeat the grid problem. Are you using any sort of a Transform on the grid or the window containing it?

I've seen the vertical lines before as well, but I don't know what's causing them. (My current theory is that it's rounding in the graphics card.)

[jack_norton]

I see vertical lines too, it's weird. I don't have them in my robot sprites 439px wide, while I have on the other 460px. It's barely noticeable but is present indeed.