Ren'Py 6.11.1 Pre-Released

[PyTom]

Downloading 150 changed files is a bug - it really should have only downloaded the few files that changed. I need to look into what's going on there. Since we compute the minimal change, we save bandwidth, except for truly huge upgrades, when everything has changed.

[jack_norton]

I think he got confused by the files checked and those downloaded.
When it starts, I see it reads all the files (and the count is high indeed, not sure if 150 or more). But THEN, says "downloading" and I'm pretty sure the number of files was 4 in my case.

[PyTom]

Actually, there's a line-ending problem, so the number of files downloaded on Linux is a lot higher than on Windows - when it really should be the same.

[PyTom]

Mihara >>>

Your new problem is that:

Code: Select all

    scene white with zoomvertin

Is equivalent to:

Code: Select all

with None
scene white
with zoomvertin

The mode change occurs during the second with statement, which is after the scene statement has kicked in - which means that the new scene is now white, and the transition reflects that.

I'm not sure what the right way to solve this is. My current thought is that the right thing to do is to go into with mode when the first "with None" executes. But that wouldn't work if the code was written as:

Code: Select all

scene white
with zoomvertin

Which is the currently idiomatic way of writing it. The alternative would be to have modes for scene (and probably show and hide) statements. I'm not sure I like that, either.

Suggestions are welcome.

[PyTom]

I've fixed the line-ending problem, and also Jack's problem with character spacing. I've pushed the updates up to the update server, for those who want to try them out. (It might take a few updates for the updater to consistently download a minimal set of files.)

[Mihara]

Suggestions are welcome.

If I'm getting you right, first, window is hidden 'with None', because the scene statement is detected, which does not actually trigger a mode change, then the scene statement's 'with' triggers it, but after the scene statement itself fires. And if I wrote 'with' separately, 'with None' would not exist... but then I'm not sure where the 'with None' is really coming from.

When would the mode change trigger (and to what change would it apply) in case it triggers on the first 'with None' and 'with' is written separately so 'with None' in the beginning does not exist?

[PyTom]

Actually, that's wrong. The definition of the "with" clause on a scene (or show) statement is that:

Code: Select all

scene x with y

is equivalent to:

Code: Select all

with None
scene x
with y 

The reason for this is historical - that was the behavior of the with clause before the with statement existed.

When would the mode change trigger (and to what change would it apply) in case it triggers on the first 'with None' and 'with' is written separately so 'with None' in the beginning does not exist?

The answer is - "I don't know". I can key in off that initial with None - but it may not exist. I could key in off the scene statement - but I don't like doing that, as it's a statement that might not actually do anything. The scene statement is also used implicitly throughout the startup, and I worry that interaction could be bad.

I'm very close to dropping this feature until the Ren'Py script language become more expressive.

[Mihara]

I'm very close to dropping this feature until the Ren'Py script language become more expressive.

Mmm.... Just remove 'with' from the list of modes. 'with' is not, logically, a mode, but what happens between them. That should solve any ambiguity introduced by trying to hook on 'with' while still keeping modes useful.

Instead, introduce a different way to hook exactly on the moment when the window is hidden or shown, and maybe others. A generic system of 'moments' which are not modes, but happen during them, a dictionary of functions or somesuch....

[PyTom]

The thing is - showing and hiding the window is not something that happens in Ren'Py. Instead, the window is implicitly hidden after every interaction, and shown again as part of the next interaction. So it's not something we can easily hook in on.

The thing is, being able to cause a transition on scene change is an explicit design goal of modes - so not being able to do that is annoying. (Right now, I think the best way to do this is to remove the with statement as a mode, and make scene/show/hide enter a scene_change mode.)

[Mihara]

The thing is, being able to cause a transition on scene change is an explicit design goal of modes - so not being able to do that is annoying. (Right now, I think the best way to do this is to remove the with statement as a mode, and make scene/show/hide enter a scene_change mode.)

Honestly, I'm probably not a good source of ideas, anything that lets me apply a transition during implicit hiding and showing of the window would be sufficient for what I want to do, and I don't know how else would I be using modes at the moment.

If you key in on both "with None" and "with X", the resulting mode list will be something like "with,with", right? Is that really a problem? The only question here is whether "with,with" has any special sense by itself, and I suspect it doesn't, which means that it can be condensed into a single "with".

[PyTom]

Thinking about this for a while, my gut feeling is that the sort of changes that are required to make this work are too complicate for a bug-fix release. So I'm going to release with mode as it is now, with the exception that the with mode will kick off when you do "with None". If you want mode to automatically hide the window on a transition, you're going to have to do:

Code: Select all

with None
scene ...
with transition

it will work.

I've also added to the ever-expanding Ren'Py roadmap the idea that we really should get a future-prediction phase, which will help in a lot of things. But that will be a fairly complicated thing that will probably wait for the future. (For some reason, Mihara, you seem to want to see the future a lot. )

EDIT: I've uploaded this change to the update server.

[SleepKirby]

I got 6.11.1a and then tried the Shift+U update. Went smoothly, except I noticed there were a bunch of ".old" files left over after the update. Were those supposed to have been removed by the updater? (I'm using Windows 7, by the way.)

EDIT: Ah, I went and downloaded the latest launcher/updater.rpy, then retried the update (from a fresh 6.11.1a). There are much fewer .old files now, but still a few (probably only reflecting files that were updated). For example: common/00nvl_mode.rpy.old, renpy/ast.py.old, renpy/exports.py.old, renpy/execution.py.old, renpy/character.py.old.

[Mihara]

But that will be a fairly complicated thing that will probably wait for the future. (For some reason, Mihara, you seem to want to see the future a lot. )

Considering that there is at least one code-induced quirk that I find very distracting and have no clue how to fix which is 'to be fixed in a future release', you kind of leave me no other option.

I'll report back on the mode changes later today, hopefully.

[PyTom]

SleepKirby>>> The .old files are not automatically deleted, at least for now. Build distributions should ignore them when putting together a package.

[Melkoshi]

Playing around with the notify feature. one question. Does it not support images to be displayed?