9 replies to this topic

[Moosh]

This is a tutorial on large combo animations, and specifically the A.SkipX and A.SkipY properties in the combo editor, which can be a little unintuitive and easily misunderstood. Even one of the ZC devs was a little confused recently, so you know this is some real nonsense. My goal here is to show both how to properly animate large FFCs / scripted draws and explain a little bit how it works the way it does. So let's get right into it.
 
A.SkipX

Here I have a sheet of example sprites, a four frame 4x4 and a four frame 3x3. When I set them to an animated combo and place it on an FFC...


It doesn't animate right at all. This is because the FFC uses the tiles extending down and to the right from the combo's current animation frame. With a normal animation, that top left corner is only advancing one tile at a time and so we get this weird effect you see here. To fix this, we want it to advance four tiles at a time (since the graphic is four tiles wide) and this is where A.SkipX comes in.

Here we set A.SkipX to 3, telling it to skip over three tiles when animating. Paired with the one tile it advances as it animates this gives us the four tile spacing we need.

And it works like a charm. So basically, any large graphic you want to animate, you set the combo to the top left tile and A.SkipX to its tile width minus one.
 
A.SkipY

Now we're doing something a little more complicated. That four frame animation I did before is a little jumpy at the end because it's actually meant to duplicate the middle two frames for a total of 6. But now the animation fills up more than one row of tiles along the top and the results are once again...

Pretty buggy.

It might not be entirely clear what's going on here. The above image shows the frames as we want them to display going blue, red, green, blue, red, green from left to right, top to bottom...

ZC does not naturally understand this and only shifts that last frame one tile down, causing the buggy effect. So this is where we use A.SkipY.

Like with A.SkipX, we set the A.SkipY to the sprite's tile height minus one. Unlike A.SkipX, this skip is only applied when the top left tile wraps across the right edge of the table. So the sprites will still progress left to right unless you set a large A.SkipX to tell them otherwise.

And once again everything is working fine. But in this case, the tile width of the table was evenly divisible by the width of the tile block. It worked for 4x4, but what about 3x3?


The 3x3 animations are messier looking, but you can wrap a frame around the right side of the table just fine. It just works.

Of course nothing's stopping you from just treating the 3x3 animation as a 4x4 if you prefer not to have frames getting cut off.
 
So that's basically A.SkipX and A.SkipY. Hope this helped.

Edited by Moosh, 07 August 2019 - 11:05 AM.

[ywkls]

So, if I understand this correctly; A. Skip X works all the time, but A. Skip Y only works if the value of A. Skip X is greater than zero and the animation takes more than one horizontal row of tiles? Seems very non-intuitive.

[Lüt]

A. Skip Y only works if the value of A. Skip X is greater than zero and the animation takes more than one horizontal row of tiles?

Second part only.

A.SkipY is applied when an animation hits the end of a tile row and progresses to the next one, unlike A.SkipX which is applied every frame of the animation.

[Emily]

So, if I understand this correctly; A. Skip X works all the time, but A. Skip Y only works if the value of A. Skip X is greater than zero and the animation takes more than one horizontal row of tiles? Seems very non-intuitive.

ASkip Y tells it "How many extra rows do I go down, instead of just going down 1 row, when I reach the edge of the page?"

[ywkls]

So, in order for A. Skip Y to work while A. Skip X is zero, the animation has to continue for that tile on the next row down?

In any case, it's no wonder this has confused so many for so long.

It's akin to rocket science.

[Saffith]

An animation normally advances one tile at a time. When it reaches the end of a row, it moves on to the next row, because that's where the next tile is.
A.SkipX means when advancing to the next tile, skip this many. A.SkipY means when advancing to the next row, skip this many. That's all there is to it.

[Deedee]

If you want to animate downwards, just set A.SkipX to 19.

Also, I've noticed buggy behavior where using A.SkipY can lead to you having to set the A.Frames to double their current amount in order to animate correctly. Be aware of that.

[Moosh]

Also, I've noticed buggy behavior where using A.SkipY can lead to you having to set the A.Frames to double their current amount in order to animate correctly. Be aware of that.

Yeah, I considered adding a mention of this but for a couple reasons. First of all, Rob was already fixing it in 2.55 as I was writing this. Secondly, nobody should ever do this. Every time someone designs around a ZC bug, 2.55 grows more convoluted. Let's do our part and report stuff before Rob and Zoria have to grandfather it in.

[Emily]

Yeah, I considered adding a mention of this but for a couple reasons. First of all, Rob was already fixing it in 2.55 as I was writing this. Secondly, nobody should ever do this. Every time someone designs around a ZC bug, 2.55 grows more convoluted. Let's do our part and report stuff before Rob and Zoria have to grandfather it in.

I mean, it will need to be fixed on a backwards-compatibility QR regardless, because who knows how long it's been there or who's done things with it. I found the issue; the formula which calculates "Have we finished yet?" doesn't calculate the ASkipY properly, thus prematurely resetting the animation. When we fix this, all old quests will not be fixed, unless the questmaker goes into `Quest->Rules->Backwards Compatibility` and unchecks the box for "Broken ASkipY framecount" (or something similar; name not finalized)

 

But yeah, instead of building around a bug, the proper thing to do is report it. Bug reports are accepted both on PZC via the "ZC Development -> Bug Reports" subforum, as well as in the ZC Dev Discord.

Feature requests are also accepted on the discord, and in the "ZC Development -> Feature Requests" subforum on PZC.

 

If you have something to report/request, please DO post it. Bug reports we need to have in order to know there's something to fix, and some feature requests end up being MUCH easier to add than you might think (while others much more difficult, to be fair), but you never know unless you request!

[Timelord]

@Staff, please pin.