Ren'Py 6.10.1 Released

[PyTom]

Engine advances are supposed to make life easier, not harder. For me this is not a rare case, and I am quite annoyed that 6.10.x already breaks things all over the place with changed defaults and outright bugs.

6.10.x added a lot of things, but didn't break much. (With the exception of a bunch of scaling related breakage that I haven't totally fixed yet.) ATL not working the way you desire is not the same thing as it being broken.

I'm actually curious as to what you're doing that this isn't a rare case. Would it help if I added a "default position" that is used when a scene or show statement is not supplied with an at clause or ATL block?

[delta]

I use it to move and dissolve sprites at the same time when the top transition is already used form something else (usually another move).

In any case, the thing that bugs me the most about this is that it's so treacherous - it only shows up when skipping. That means things that look perfectly fine in normal development can break when skipping, which means you have to specifically test for that too. And that is insane. That is not the only problem though, and it all would be neatly avoided if you would go the more logical path and preserved animations of transform properties as well. Anything THAT would break already got broken in 6.10 anyway.

[luminarious]

Why not pre-calculate where the image would end up post-ATL? When the animation is skipped, the image would be put there without any effects..

[PyTom]

delta>>>

This also shows up when clicking, and perhaps when auto-forwarding, as well as skipping.

The problem is, there's no good way to preserve animations of transform properties, in the general case. For example, take:

Code: Select all

show eileen happy:
    xalign 0.0 yalign 0.0
    linear 3.0 xalign 1.0 yalign 1.0
    repeat

"..."

show eileen happy:
    xalign 0.5

What should the behavior at the end of this be? I really don't want to have two ATL blocks executing at the same time for the same image, with one of them having half of its side-effects expressed.


luminarious>>>

ATL is powerful enough that this can't be done in many cases. It's also a bad behavior for the general case, as it means that we couldn't start a transition at the current position.

[delta]

What should the behavior at the end of this be?

xalign stops animating and is fixed at 0.5, the rest continues. Not that hard.

I really don't want to have two ATL blocks executing at the same time for the same image, with one of them having half of its side-effects expressed.

I'd be inclined to agree with you more if you wouldn't specifically tout holding over the properties themselves as a feature (which it is... except when it isn't). So the ATL blocks are already not atomic. I just don't think of these in terms of "blocks" at all, but to consider each property and its animation just as a more refined version of the property with half a dimension added.

In general, the question here is this one:
Is it logical desirable behavior that clicking too fast or skip mode stops ATL blocks?
And the answer is no.

Also, I think the "precalculate the ending position" outcome is at least worth considering, because it's easy to detect if it's possible (does not contain repeats), and if it doesn't the problem is bigger than this anyway.

we couldn't start a transition at the current position.

And I don't understand this one.

[PyTom]

xalign stops animating and is fixed at 0.5, the rest continues. Not that hard.

I'm not sure I like that, though. We have code that appears to be updating two properties, but with your semantics, sometimes will be updating only one property. That seems kinda weird to me.

What I think is going on here is that I'm thinking of ATL as a script that runs and updates properties, while you're thinking of transform properties as being largely independent, with ATL being a means of varying those properties over time. (Am I right?)

There's also the problem that we have multiple non-independent properties. For example, the xpos property can be updated when the pos, xalign, align, angle, and radius properties are set. This is good and necessary, as these properties are not independent of each other... but it does mean the interactions could become very complex.

That makes me want to shy away of a model in which the animation of some, but not all, transform properties are overridden.

I'd be inclined to agree with you more if you wouldn't specifically tout holding over the properties themselves as a feature (which it is... except when it isn't). So the ATL blocks are already not atomic.

We have a model in which one ATL block runs at a time, per image tag. It's the properties that are held over, not the running ATL.

I just don't think of these in terms of "blocks" at all, but to consider each property and its animation just as a more refined version of the property with half a dimension added.

I don't believe this is the right model to have.

In general, the question here is this one:
Is it logical desirable behavior that clicking too fast or skip mode stops ATL blocks?
And the answer is no.

Well, the real problem is not "clicking too fast" or "skip mode", it's "running a show statement". And I think it's fair that running a show statement that changes what is being shown should also change the ATL block associated with what is being shown.

Showing a second image early will always be a bit of an edge case. It's not clear to me that there is behavior that is better than the current one (which requires the game-maker to resolve this edge case). I don't believe that the current proposals are better than the current behavior.

I am wondering if there needs to be a variant of the show statement that changes the image being shown while keeping around the ATL state, and if that would help with most of this.

we couldn't start a transition at the current position.

I meant to say "transform" instead of "transition".

[delta]

I give up. Like with the issue of center not being the same as the default position and nothing inheriting from it, I will uphold that it is terrible but if you don't want to believe me I won't waste my breath.

[lorddon]

I give up. Like with the issue of center not being the same as the default position and nothing inheriting from it, I will uphold that it is terrible but if you don't want to believe me I won't waste my breath.

Or you could be, y'know, positive and constructive in your criticism rather than coming across as having a giant chip on your shoulder. Tom wants to improve things but nobody is forcing you to use the software.

[JinzouTamashii]

Or a laser beam in your eye, delta...

Geez, isn't your game supposed to be about helping crippled girls and being nice to your neighbor and all that shit? I've played through approximately half of KS and I loved it, but I have no idea how you can come across so embittered and cynical... then again, I'm not trying to manage a team composed mostly of bored 4chan internet HAET machine hackers on steroids and calling it a doujin team, either...

tl;dr lolwut, I can see the pixels from here! Totally not a shoop, you guys! Go troll /x and /b and /ic some moar!

Hey, guyz, guyz, why do we have user-editted online documentation and a Cookbook in the first place? Mizu~u...

Laughter is the spice of life, but irony makes for a very bitter soup when you use too much of it!

Code: Select all

In other words, if you have a problem: make a new topic calmly, file a bug report, and help others whenever you can. 

The hardest thing I ever did was try to collaborate with Zone on the you-know-whatsits on H-Key because we had the same kind of skill-sets—but it's hard to be equal partners when both artists are somewhat headstrong... kind of like running a D&D campaign with two DMs.

You just know that someone's going to be rerolling a new character soon. D: http://xkcd.com/393/

[delta]

I think if you'd actually make a game sometime instead of giving "pro" advice all the time, you'd understand what I'm talking about a little better, you clown.

[A Terrible Rabbit]

You two are seriously opposite extremes.

[jack_norton]

EDIT: nevermind, delta had posted about this already!!! should read whole thread before posting

[jack_norton]

Seems to me that Frame() is broken badly. At least, the engine crashes if you display an ui.frame with one set as background with TypeError: surface() takes exactly 2 arguments (1 given). This is definitely new in 6.10.1.

P.S. it only happens if tile is set to True.

Yes, if you set tile=False it works fine.
To be honest I don't seem to find the difference in the gfx with that value set to True/False, the result seems identic to me ?

[jack_norton]

I found another odd behaviour in 6.10.1 : I am using a simple overlay to display buttons on screen:

Code: Select all

    def overlay():
        if showbar==1:
            ui.textbutton("{image=gfx/people.png}",xalign=1.0,ypos=642,yminimum=40,clicked=ui.callsinnewcontext("showinventory",0))
            ui.textbutton("{image=gfx/quest.png}",xalign=1.0,ypos=685,yminimum=40,clicked=ui.callsinnewcontext("show_quests"))
            ui.textbutton("{image=gfx/loadsave.png}",xalign=1.0,yalign=1.0,yminimum=40,clicked=ui.callsinnewcontext("_game_menu_save"))

the problem is that if I change the variable value in game, is NOT reflected instantly like before, but "the next step" !!!
To explain better, the script of the story:

Code: Select all

1        r "Ahahaha you're scared eh?"
2        $ showbar=0
3        l "Well is just a simulation, but..."
4        r "Come on, weren't you eager to fight? Now show me what you can do!"
5        "While playing this battle, try to pay attention to the various damage types and the role they have in determining the outcome."

the bar is NOT hidden when the line 3 is shown, but when the 4 is!!! before it would happen immediately.

[dott.Piergiorgio]

Only two minor things related to the eileen demo:

first, the menu: after the new feature, the "previous" features are a bit mixed up. Will be nice to have the features menu in their chronological order, showing also the growth of Ren'py (well, there perhaps my historian mindset, but anyway....)

Another, more along the line of fun/joke, I suspect that the demonstration of playing movies like picture (a great new feature, anyway... ) should be put in the left side instead of rightside, because of the tales about alleged ancient advanced civilization )

seriously, this new capability of playing movies embedded in the game screen open many interesting possibilities (think about TV screens or scenes inside a movie theather...) so is perhaps the best new feature.

Best regards from Italy,
Dott. Piergiorgio.