Ren'Py 6.10.0 Released

[PyTom]

Ren'Py 6.10.0 "You Ain't Seen Nothing Yet", the first release on our path to Ren'Py 7, had been released. This release's biggest new feature is ATL, the Animation and Transformation language. Superseding more than a dozen special-purpose displayables, ATL provides a simple yet general way of defining images that change over time.
Along with ATL, this release:

* Comes with the start of the new tutorial game.
* Keeps track of image positions.
* Adds a define statement, making init blocks often unnecessary.
* Adds a pause statement.
* Adds support for Arabic and Hebrew.
* Allows images to be used as displayables.
* Can automatically define images.
* Can automatically load a saved game at startup.
* Allows save games to be deleted.
* Adds an image location picker to the developer (shift+D) menu.

along with many other features and bug fixes. Downloads of 6.10.0 and a full release announcement can be found at:

http://www.renpy.org/wiki/renpy/releases/6.10.0

[PyTom]

6.10.0a is still somewhat unfinished. I still need to spend another few hours on the tutorial game, cleaning up loose edges. I'm also waiting for some new art of Lucy... for now, I'm using temp art from Lucy's Revenge. But the actual engine itself has been finished and tested, so I wanted to get it into people's hands to try out.

[jack_norton]

Woot downloading now!
I saw on your twitter you were considering using it for other things beside new releases. What do you mean?

BTW: the ATL language tutorial looks great!! I think is the best addition you ever made to Renpy. Doing complex animation sequences will be ultra-easy now

[Papaxibe]

Hello Pytom, and thanks for the release!

You can't realize how much I am happy. I like animations too much, and the ATL is the answer to my pray.

Now... the problem:

When I create a New Project, the first screen asking the name appears, I type the name and press Enter, the following screen, The Choose Theme, crash when I move the cursor over the word Roundrect, and the bellow traceback shows:

Code: Select all

I'm sorry, but an exception occured while executing your Ren'Py
script.

TypeError: 'NoneType' object is unsubscriptable

While running game code:
 - script at line 249 of renpy-6.10.0/launcher/choose_theme.rpy
 - python at line 279 of renpy-6.10.0/launcher/choose_theme.rpy.
 - python at line 106 of renpy-6.10.0/launcher/interface.rpy.

-- Full Traceback ------------------------------------------------------------

  File "C:\Programas\renpy-6.10.0\renpy\bootstrap.py", line 260, in bootstrap
  File "C:\Programas\renpy-6.10.0\renpy\main.py", line 308, in main
  File "C:\Programas\renpy-6.10.0\renpy\main.py", line 92, in run
  File "C:\Programas\renpy-6.10.0\renpy\execution.py", line 230, in run
  File "C:\Programas\renpy-6.10.0\renpy\ast.py", line 557, in execute
  File "C:\Programas\renpy-6.10.0\renpy\python.py", line 927, in py_exec_bytecode
  File "renpy-6.10.0/launcher/choose_theme.rpy", line 279, in <module>
  File "renpy-6.10.0/launcher/interface.rpy", line 106, in interact
  File "C:\Programas\renpy-6.10.0\renpy\ui.py", line 69, in interact
  File "C:\Programas\renpy-6.10.0\renpy\display\core.py", line 1513, in interact
  File "C:\Programas\renpy-6.10.0\renpy\display\core.py", line 1822, in interact_core
  File "C:\Programas\renpy-6.10.0\renpy\display\core.py", line 1129, in show
  File "C:\Programas\renpy-6.10.0\renpy\display\render.py", line 773, in render_screen
  File "C:\Programas\renpy-6.10.0\renpy\display\render.py", line 143, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\layout.py", line 508, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\render.py", line 143, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\layout.py", line 508, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\render.py", line 143, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\layout.py", line 508, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\render.py", line 143, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\layout.py", line 787, in render
  File "C:\Programas\renpy-6.10.0\renpy\display\render.py", line 117, in render
  File "C:\Programas\renpy-6.10.0\renpy\style.py", line 557, in getter
TypeError: 'NoneType' object is unsubscriptable

While running game code:
 - script at line 249 of renpy-6.10.0/launcher/choose_theme.rpy
 - python at line 279 of renpy-6.10.0/launcher/choose_theme.rpy.
 - python at line 106 of renpy-6.10.0/launcher/interface.rpy.

Ren'Py Version: Ren'Py 6.10.0a

I start Renpy program again. The project was created, and everything is normal... But if I clicked in Choose Theme again, the crash occurs.

Thanks for attention

[Alex]

I`m sorry, if this is an offtopic...
typo?
Some sample interpolations are:

show logo base:
# Show the logo at the upper right side of the screen.
xalign 0.0 yalign 1.0

# Take 1.0 seconds to move things back to the left.
linear 1.0 xalign 0.0
http://www.renpy.org/wiki/renpy/doc/ref ... n_Language

[delta]

Just so I get this right: The old positions and motions functions are implemented as Transforms now as well, right? So I don't need to rewrite my huge effects library to ATL to get any forthcoming performance benefits?

P.S. Found one misbehaviour: If you use a with transition inside an image statement ATL block, that transition does not become a part of the displayable (like in the old TransitionAnimation), instead it's executed like a verbatim in-script with statement (i.e., it blocks text display for as long as it's executing). I don't think that's how it's supposed to work.

Disregard that, my error.

[PyTom]

Just so I get this right: The old positions and motions functions are implemented as Transforms now as well, right? So I don't need to rewrite my huge effects library to ATL to get any forthcoming performance benefits?

This was postponed until the next major release, but it will eventually be the case. ATL was major enough I wanted to do a release that focused on it. Performance-wise, ATL performs as well as a Transform does. (ATL just wraps a transform, internally.) The goal for 6.11 will be to rewrite everything in terms of Transforms, and then GL-accelerate them.

While the old functions are superseded, they should remain supported for the forseeable future. There is one minor difference between this and the older release. The new semantics is that when we show an image at a Transform, and then replace that image, we wrap the new image in a transform (if it wasn't wrapped already), and the initialize the new-image-transform to have the same properties as the old image. This gives a form of "location memory"... if we do:

Code: Select all

show eileen happy at right
"..."
show eileen concerned
"..."

The second image will be shown at the right, not the center. This is because left, right, etc... are now Transforms, not Positions. You can redefine them as Positions yourself if you want to retain compatibility with 6.9.3.

Alex>>>

Can you elaborate on what you consider the typo to be?

Papaxibe>>>

Will be fixed in 6.10.0b.

[delta]

So basically, redefining left, right, and center should fix the" minor" (i.e., hundreds of) cases of broken positions I have right now? That's nice to know.

Also, if NO position is given, I hope it defaults to what is defined as center, not to what is now the new center? Because that would be pretty catastrophic.

[delta]

Thinking more about it, pretty much everything that ever used a mix of predefined positions and literal Position() is now broken. Considering that this is in no way, shape or form "minor", wouldn't it make more sense to just reimplement Position() as a Transform and not punish everyone for making the mistake of trying to actually use Ren'Py's advanced functionality again?

Also, isn't this pretty much config.sticky_positions? Why force this ages-old config setting to be on by default and ignore it now?

P.S. Of course I can just reimplement my custom positions as Transforms too, but I don't see any easy way of using a Transform on the fly like "show x at Position()".

[PyTom]

The thinking is that Position is now basically obsolete. What's more, mixing Position and Transform isn't supported: older code should use Position, and new code can use Transform. So the difference in behaviors makes sense.

The motivation behind "sticky" positions for Transform is that we want to allow the following code:

Code: Select all

show classroom:
    xalign 1.0

"The classroom was filled with people."

show classroom:
   linear 5.0 xalign 0.0

"Many of them look like refugees from various anime shows. These sort of cameos break immersion in the game."

There's actually a difference between this and config.sticky_positions. With sticky positions, we kept around the old position and motion functions. So if something was moving, it would keep moving. (Actually, I think it would restart moving --- an even worse behavior). With Transforms, we keep the position (and the various other properties), but we stop animating it.

That being said, I do agree that there needs to be a syntax for giving literal positions to Transform. So I'll be adding code that allows one to write: Transform(xalign=0.5, yalign=1.0). (And so on for the other properties we allow.)

The "no position" case is kinda special. Showing something without a position doesn't show it at center, it shows it at a set of defaults (which amount to the same location on the screen, but can be changed and don't have this sort of memory).

The solution for longer-term projects like KS is to just work entirely with Positions and the various other special-case functions. They'll still be supported for a very long amount of time, and there's no reason not to use them. ATL can still be used, but in special cases where it is not mixed with older code. Newer projects should switch to ATL/Transform, as they are superior to the older code.

[JinzouTamashii]

It's going to be hard relearning it all! LOL. I bet the next release will be out by the time I start to adjust to it... it's a good thing that I've been slacking off on coding the visuals but part of the reason was this. Downloading right now!

If we're not using JEdit, can we still use Shift+R and Shift+D? I'm using an ancient version of SciTe from a year or so ago, but I never actually took the step of integrating it because I didn't want to.

[delta]

Code: Select all

They'll still be supported for a very long amount of time, and there's no reason not to use them. 

You know my position on this. It's bad enough to deal with higher-level functionality that doesn't get used much (and hence is often less than bug-free), and it's even worse to do that with functionality that is considered obsolete on top of that. I'd much rather have a clean break with an assisted transition to the programming paradigm of the week.

Not to mention that the older scripts are still broken by default. There isn't even an official compatibility mode this time, so if I have to go through the whole script and fix every error anyway, I can just spend the same work on making it current.

In short, you're glorifying a backwards compatibility model that isn't even backwards compatible.

[PyTom]

There isn't even an official compatibility mode this time

Sure there is: config.script_version = (6, 9, 3)

You don't want a compatibility mode. You want a mode where you can mix the new and old constructs, and (with the semantics being somewhat different) that's not something I'm willing to support.

[delta]

Actually I just want fixes for crippling bugs without having new functionality that I don't need forced down my throat.

Can you guarantee that setting config.script_version will behave exactly like the given version, minus the bugs that version had?

[PyTom]

I make no guarantees, but that's the intent of config.script_version.

That being said, I've added the code required to make left/right/etc Positions to the 6.10 web page. Adding this code (and not using Transform or ATL) should be enough to make your code work.