Ren'Py 6.11.0 Public Pre-Release

[rinrin]

I tried. No GL mode. The framerate goes up to 10fps.

[PyTom]

Okay, here's another version of the GL test. It will write three lines of dialogue. If you can screenshot them or type them in and post them here, I'd appreciate it.

[rinrin]

Can't run it - it gives me an error message about line 97 of common/00gltest.rpy:
TypeError: %d format: a number is required, not unicode

(I can pm you the whole traceback.txt if you wish)

[Mihara]

Here's a fresh bug, a parsing problem in the screen language. Replication follows:

Code: Select all

screen test:
    side "c r":
        viewport id "list":
            vbox:
                for i in range(1,100):
                    text ("Line "+str(i))
                    
        # This generates an error unless you comment out "bar_resizing"
        vbar:
            yalign 0.5
            bar_resizing True
            value YScrollValue("list")

init python:
    
    e = Character('Eileen', color="#c8ffc8")

init:    
    image bg a = Solid("#f00")

label start:
    
    scene bg a
    call screen test

Upon looking at the source I found the bug itself in screenlang.py:

Code: Select all

bar_properties = [ Style(i) for i in [
        "bar_vertical",
        "bar_invert"
        "bar_resizing",
        "left_gutter",
        "right_gutter",
        "top_gutter",
        "bottom_gutter",
        "left_bar",
        "right_bar",
        "top_bar",
        "bottom_bar",
        "thumb",
        "thumb_shadow",
        "thumb_offset",
        "mouse",
        "unscrollable",
        ] ]

Note the missing comma after bar_invert. Replacing it fixes the bug.

[PyTom]

Can't run it - it gives me an error message about line 97 of common/00gltest.rpy:
TypeError: %d format: a number is required, not unicode

(I can pm you the whole traceback.txt if you wish)

Actually, can you delete environment.txt and run it again? The version (with additional debugging) will only work without it.

If that doesn't work, please send the traceback.

Mihara >>> Thanks.

[Mihara]

One more complaint about screens.

When a screen is redrawn due to renpy.restart_interaction (i.e. because of a SetVariable action triggering) and contains a lot of buttons (in my case, it's something like 25 buttons inside a viewport and six more outside it which select between which group of buttons shows inside the viewport) buttons briefly flash as focused (hovered) when they in fact aren't, when the number of buttons inside the viewport changes.
As far as I can see, this happens because the id of the focused button is remembered from the previous screen state. Upon redrawing, a different button gets this id, always the same one, depending on between which states the screen was switching, and is drawn focused for a brief moment before another button gets rightfully focused.

Manually generating unique ids for every button is not really my idea of fun.

EDIT: Nope, that's not it. Assigning every button a unique id property did not stop it.
EDIT EDIT: Ah, duh. It was "focus" and it was sufficient to assign it to button containers to stop the flashing. Still, I don't think it should happen in the first place, shouldn't focus properties be generated uniquely for boxes unless stated otherwise?

[PyTom]

It's Saturday, and that means another pre-release of Ren'Py 6.11. There are three major changes.

The first is a new "graphics acceleration" menu. This is accessed by holding down shift at startup, and allows the user to choose between automatic detection, prefering OpenGL mode, and prefering software rendering. This should make it easier to troubleshoot graphics problems.

The second is a change to the way screens migrate state between displayables. Previously, simple structural equality was used. This could cause a problem if, for example, the third component of both the load screen and the preferences screen were buttons - data could be migrated spuriously between them. Now, screen names are taken into account. So going from the save to the preferences screen won't cause data to be migrated - but if they both use a navigation screen, data will be migrated between that screen.

The third is the addition of a new default statement to the screen language. This statement is used to set the value of parameters to screens that are not provided explicitly or implicitly.

- Right-clicking at the main menu doesn't cause a spurious transition to occur.
- ui.interact will return an error when called recursively, in the same context.
- Support for old-style imagemap rectangles was removed from the imagemap picker, to prevent confusion.
- Grids report an appropriate error when overfull.
- Various documentation fixes.

Thanks to everyone who has helped with this release process. Again, my goal is to release this version, unless major problems are encountered.

[Aleema]

- Grids report an appropriate error when overfull.

This is my favorite update ever.

[Mihara]

You broke it. This script runs in 6.11i and no longer runs in 6.11j:

Code: Select all

screen test:
    side "c r":
        viewport id "testlist":
            vbox:
                for i in range(1,100):
                    text ("Line "+str(i))
                    
        vbar value YScrollValue("testlist")
label start:
    call screen test

Fails with a cryptic exception "The displayable with id %r is not declared, or not a viewport." The "%r" is not helping.

In addition, I don't see anything about previously reported:

• Joystick preferences (they're just as impossible to write a custom screen for as they were).
• A screen called with "call screen" from renpy code which has "tag menu" still lets one call up game menu over it (all the screens of which have "tag menu" as well), when the manual implies the game menu screen should either replace it or fail to be called.

[PyTom]

Joystick preferences (they're just as impossible to write a custom screen for as they were).

This isn't going to be fixed in 6.11. I need to revisit this framework, and won't have time for this before release.

A screen called with "call screen" from renpy code which has "tag menu" still lets one call up game menu over it (all the screens of which have "tag menu" as well), when the manual implies the game menu screen should either replace it or fail to be called.

What in the manual seems to imply this?

[Mihara]

What in the manual seems to imply this?

"This specifies a tag associated with this screen. Showing a screen replaces other screens with the same tag. This can be used to ensure that only one screen of a menu is shown at a time."

"The call screen statement shows a screen, and then hides it again at the end of the current interaction. "

If it can't be replaced, it is obvious it shouldn't be shown, though that is just a conjecture.

[Ivlivs]

- Support for old-style imagemap rectangles was removed from the imagemap picker, to prevent confusion.

Does this mean that I cannot use old-style imagemap rectangles in a game at all? And are the new-style imagemaps really limited to only six elements?

[PyTom]

Mihara >>> I need to write up how contexts interact with screens. Well, as I finish the manual, I'm going to document how _everything_ interacts with contexts.

Ivlis >>> Screens are the preferred replacement for old-style imagemaps. The old code still works, but I don't recommend using it in newer games.

Screens don't have a limit as to the number of elements they have.

[PyTom]

And, I've pre-released 6.11.0k. This release is largelyh thanks to Doomfest, and the dozens of reports he gave to me when he was making the interface for Cradle Song:



Cradle Song is interesting because it shows that it's possible to use the combination of screens, ATL, and styles to write complicated user interfaces in a completely declarative style, without writing any python functions. (And also because it's also a nice looking game.) So that helps validate the decisions that went into this new release.

A big change is that we're now a lot more strict about which children of a screen are given the show and hide ATL events. These now go only to the direct descendents of the screen, rather than some random subset of its dependents, which was leading to ill-defined behavior.

The second big change is that we're more strict about transferring transform and displayable state from one screen to another. We now only transfer state if the old and new displayables are (1) structurally the same, and (2) lexically part of a screen with the same name. So if we have:


Changes include:

- Fixes to a regression introduced in j, that broke user-defined say screens.
- Fix a problems that occured when screens are hidden, especially involving transtions and atl "on hide" clauses.
- Screens can be hidden by both names and tags.
- Fix a problem with window show and a say screen.
- The modal and zorder parameters to screen are now evaluated as expressions. This involved changing the signature to renpy.define_screen.
- The Show and Hide actions now take optional transition parameters, a new With action was added.
- Minor documentation fixes.

Thanks to Doomfest and everyone else who tested Ren'Py 6.11.0 "It Goes to Eleven". This is the eleventh pre-release, so perhaps it's an auspicious number?

[Ivlivs]

PyTom >> That's good to hear.

I can't wait for this new release.