6.10 Development

[sake-bento]

Everyone is going to kill me for not thinking of this four and a half years ago.

I just added config.auto_load. This can be set to a save file, and it causes that save file to be automatically loaded when Ren'Py starts. The idea is that a developer can easily jump to their current work, and easily pick where they jump to by saving into (for example) save slot 1.

I'm off to duck and cover now.

Sounds great! We'll hold off the lynching until you release 6.10...maybe longer if we like it. ^_-

[mugenjohncel]

Wishlist time:
For imagemap based save-load screen to have a "botton" to delete save.

"POOF" (Disappears)

[PyTom]

Mugen:

Do me a favor, and file that as a bug in the bug tracker. Also, if you could mock up an interface for it, including a list of the button rectangles, that would make my life easier.

[mugenjohncel]

Working...

"POOF" (Disappears)

[Jo'ogn]

I just turned some older Renpy code into ATL. It's spiffy!

I used several overlapping Factorzooms with alpha fade in's and outs for 'sprites'. One Rotation and zooming the entire background all at the same time o_0;

ATL seems not only to perform better (according to the FPS), but also makes the whole thing much more managable and the result looks smoother with the fades (also thanks to subpixel-ness).

^_^b In other words: good job PyTom

[delta]

wishlist: show statements that reference tags without subtags should work but keep the current subtag (if an image designed as just the tag does not exist, probably). In short, sticky subtags.

Ex:

Code: Select all

show eileen happy at center
with None

show eileen at left
with charamove
#would have to write "show eileen happy at left" right now, but there's no real reason why this is necessary
#the only problem is that "image eileen = ..." may actually be defined

this makes it easier to handle images that don't change for a long time.

also, and somewhat related: hide statements should take an at clause so you can hide with moves of arbitrary direction.

[PyTom]

I've added these suggestions to my ideas file. They'll probably require some changes to rpy, so I think they'll be addressed in 6.12, which is where I'll be introducing rpy version 2.

[jack_norton]

A thing I would like (I don't think is possible) is to use the show statement with an expression. I now use renpy.show, but would be cool to be able to reference to a displayable using a function like "img%0d" % current_money and so on

[PyTom]

you can already use show expression:

Code: Select all

show expression ("img%0d" % current_money) as current_money

The parenthesis are required in this case.

[delta]

6.12, which is where I'll be introducing rpy version 2.

In light of recent developments, I don't like the sound of this at all.

[pkt]

How about adding something that lets you define UI elements and ATL from a GUI based designer?
Or auto caching images?
3d support via CrystalSpace and Celstart
http://www.crystalspace3d.org/main/PyCrystal
Loading multiple images at once with a single statement.
EI
image sprite01.png - sprite99.png

[PyTom]

In light of recent developments, I don't like the sound of this at all.

I love the way you can ask for language changes in one post, and then not like the sound of what's required to evolve the language.

How about adding something that lets you define UI elements and ATL from a GUI based designer?

This is not something I plan to work on anytime soon.

Or auto caching images?

Not sure what you mean by this. We certainly preload images, and in 6.10.2, you can pin images into the cache.

3d support via CrystalSpace and Celstart
http://www.crystalspace3d.org/main/PyCrystal

I don't think this is a direction I will be going in.

Loading multiple images at once with a single statement.

We support automatic definition of images, but not with this syntax.

[delta]

In light of recent developments, I don't like the sound of this at all.

I love the way you can ask for language changes in one post, and then not like the sound of what's required to evolve the language.

I know enough about Ren'Py to know that this change does not require a completely different language.

[PyTom]

I know enough about Ren'Py to know that this change does not require a completely different language.

There are no plans for a completely different language, but there are enough changes that versioning is still required anyway. Some other plans for rpy2:

- A blank line inside a say-statement text block will now break it into two text blocks. So one can write:

Code: Select all

e "This is the first line.

    And this is the second one."

- label, image, and definition statements can take an optional priority number.

Code: Select all

label 2 hello:
     e "This is an overriden label, as might be found in a patch."

image 2 eileen happy = "eileen_happy_hd.png"

This requires a language change, at least for the image statement, because (due to a programming bug) "2a1" is currently a valid image name, and one that I've seen people use in code.

[delta]

Well, that seems like a reasonably small change then. Am I right in assuming then that the amount of valid rpy1 scripts that will become invalid in rpy2 is tiny (limited to things like the example above, i.e. stricter naming conventions that can be fixed with a script wide search-and-replace?)