A Brief and Expedited Walkthrough of the Animation Editor (part 2) (Patreon)

Hello. We're back. Let's continue, and see just how salty I get along the way.
This is a good program, I promise. sort of.

We'll talk about cells next. Each graphic in the animation area is a cell, including the battlers. You can tell, because the cells have white boxes around them, and are indexed:

Cells can be dragged around with the mouse or tapped about with the arrow keys as instructed by our pitiful Help screen from last time. You'll notice the Pokemon graphics have lock symbols on them by default, but we can unlock them and move them if we want. There are some things we can't do with Pokemon cells though, like delete them outright. Each frame can have up to 30 cells at a time (counting the battlers). The selected cell turns black instead.

You might be wondering how the animation editor handles the extra battlers for Doubles.
And frankly, me too.
(in other words, it doesn't, which sucks)

The cells have a natural onion skin effect, which in animation means that you can see the traces of other frames. Here is frame one, where I've added an extra strike:

Here is frame 2: 

On this frame, the strike has moved slightly, but you can see the blue outline of the cell from where it was on the previous frame. This helps us see motion from frame to frame.

Right clicking a cell opens this menu. Many of these options are intuitive, and we will go over Properties in a minute. The Renumber option allows us to organize the indexes on each frame. Notice how on frame 1, the strike cell I added was number 3, but on frame 2 it is number 5. This is because when adding a cell it just uses the next lowest number available, and there were extra graphics on frame 2 that weren't on frame 1. Using Renumber, I could make frame 2's strike set back to number 3. Then if I wanted to edit this strike across multiple frames, I would just need to ask for the number 3 cell in those frames. 

"Define Path" brings up this menu: 

This feature allows us to set an auto-generated path or curve over several frames and easily arrange a motion for a given cell. A feature like this is a wonderful idea, and I applaud their initiative in making.

Unfortunately it is next to useless.

The "Define Path" option of "Define Path" (eye rolling here) is not so bad-- you select a point A, a point B, and the number of frames to take to get there, and then it makes  a beeline. However, this is outclassed by another method we'll discuss later. 

The "Define Curve" option, on the other hand, would be incredibly helpful. When selected, you can set point A, point B, and up to two points between them to define a shape to get there. It looks like this: 

The cell should then follow that path over the given number of frames. Since this automatically positions the distance traveled each frame by a mathematically correct amount, it could be incredibly useful. Even more so since Mde in particular absolutely hates making curves with a firey passion since they never seem to come out right for him. This tool could solve all his problems. 

But it does not. It is garbage. 

Firstly, you can -only- set two waypoints along the way, which is decidedly not enough, especially for circling motions. However, since you could just run this command multiple times, that is not the worst. The real problem is that when it draws the cells to the location, it places them on these points by their upper left corner, instead of their center, as one would expect. Since our graphics are always positioned in the center of the cells (for various reasons-- that is the correct way to do it) we then have to visually guess what the proper offset for the top left corner from the center would be. This is easier said than done, and makes this entire tool require more effort than it's worth, as the guesses are usually wrong and need to manually corrected and the entire thing comes out looking awkward anyway. 

So fuck that.

But as I am writing this I may ask Marcello to look into how difficult it would be to fix that tool...
you know, now that we're ~900 animations in........

...let's move on.

This is the cell properties menu. It exists separately for every cell on every frame. I'll go over each attribute:

• Pattern-- which graphic it uses.
• X-- the left-right location of the (upper left corner -.- of the) cell.
• Y-- the top-bottom location of the (blahblahblah) cell
• Zoom X-- horizontal magnification % of the cell.
• Zoom Y-- ^ that but vertical. these go up to 1000.
• Angle-- rotates the cell by this many degrees, from 0 to 359
• Opacity-- how visible is the cell. 255 is max and default; 0 is completely invisible.
• Blending-- 0, 1 or 2. 0 is no change. 1 is Add blending mode, great for light effects. 2 is Subtract blending mode, which in turn is for shadowy stuff. These aren't subtle, but can be very handy.
• Flip-- flips the image horizontally. useful for making opps without duplicating graphics.
• Priority-- What's displayed on top or bottom. The options are: Back, Front, Behind Focus, Above Focus. One would expect Back and Front to mean "behind everything" and "above everything" whereas the Focus options would separate the two battlers into different Z-values. Unfortunately we have not found a practical difference between these two pairs of options in practice.
• Focus-- the main causes of almost every glitchy animation we have. Four options: User, Target, User and Target, and Screen. Screen means they show on the screen exactly as they show in the editor. This is nice for status effects and such, but can't be used for normal moves since Double Battles etc change targets' locations in a battle. "User" and "Target" are self explanatory with a caveat I'll discuss later. "User and Target", which I dearly wish was named something else, is ideal for beams and such that reach from one Pokemon to another. However, setting everything in an animation to this actually tends to fix most problems.
• Set Blending Color-- adds a slight glow effect, per colors. This looks weird most of the time.
• Set Color Tone-- tint the graphic a certain color. For both of the above, the menu looks like this:

...with "alpha" replacing Gray Tone on the blending one. You will notice that we, once again, have to click these numbers up or down to the values we want, which is incredibly inconvenient. Moreover, there are no tools to automatically set this across multiple frames, so we have to do this for every single cell on every single frame if we want to have like a fading color. The reason ir is like this is because we are a doomed species, cursed to suffer for all of eternity.

The caveat I mentioned about User and Target is in different kinds of moves. For instance, let's take a move like... Charge. Charge is a self-targetting move, and the user should probably glow as part of the animation. So, a normal reasonable thing to do would be to edit the attacker's cell properties to have that color glow, and to add the graphics in cells around the user,  and call it a happy day.

Unfortunately, this editor is neither normal, nor reasonable, so this is not how we have to do things. 

This is a self-target move. And, as far as the animation editor is concerned, the graphic that looks like the opponent in the animation editor is always the target. Anything we do the player-pokemon in editor will not show up in-game. Therefore, although we need to have the cell graphics around the attacker, the glow effect has to be applied to the opponent in the editor. For charge, it looks like this:

Strictly speaking, the attacker here does not need to glow in order for this to work on game, but I only learned this upon making this animation. The attacker's properties are completely ignored since the attacker is the target, and not the user. Therefore I just copied them over to the opponent, once again, frame by frame and click by click : I
#salt

There are also cases where -neither- pokemon can be edited. I less-than-fondly recall an incident where Inuki broke himself over the Toxic Spikes animation. His vision was to have the attacker turn purple with poison energy, and then spew poison spikes onto the field. However, no matter what he did, be it to the player or the opponent Pokemon in the editor, the Pokemon in-game would not change color at all. Eventually we figured out that this is because Toxic Spikes targets the field rather than a Pokemon. Since there is no target, nothing about the battlers can be edited. It was about this time that Inuki whatever will to live he had remaining, and he has never been the same since.

Now, let's finally come back around to the rest of our buttons on our side menu:

We have already talked about the bottom five, so let's move upwards from there.

The Entire Slide button shows this menu: 

This tool allows us to move all cell graphics across multiple frames around an animation. This is good for re-positioning a whole animation if it was a little too far to the side of a target or something. We tell it how much to move, and what frames to move on, and it does its thing. It is also useful for making opp versions, since we can use it to move an entire set of cells from being around one pokemon to being around another. The difference between two pokemon is X+ 256 and Y- 128, or the reverse for going the other direction. 

The Cell Batch button produces this menu:

This allows us to edit a specific group of cells on a specific group of frames and mass-change their properties. It is almost very helpful. Unfortunately, that little top left menu lags like a bajeesus, meaning it is incredibly tedious to click the right numbers in. This is because god hates us. You will also notice that color tone/blending is excluded from the list of properties we can change. This is because we are creatures of sin. Still, this is an important tool, especially for correcting the mistakes of the next one.

The Tweening (refering to: in-beTween) button produces this window:

This is very similar to Cell Batch in that it affects a set group of cells in a set group of frames. It is worth noting that unlike Cell Batch, this menu does not lag, and is in fact a pleasure to use. It is very smooth and responsive, and clicking number in does not feel like a chore at all on it. It is an example to all menus in this editor, however I continue to be baffled as to why there is such a discrepancy. 

Whereas Cell Batch affects the given cells and frames and changes them to a specific number, Tweening fades these values between them. The frames should be a start and end point and then it can smooth out all of the properties in the cells between those frames in a mathematically proportionate values. This is incredibly good for movement (position) and opacity. I mentioned before that the Define Path tool was outclassed-- this is what beats it, since it also handles all of these other elements, and does multiple things at once.

Unfortunately, nothing in this editor is sacred, and so the idea that something could actually be as useful as it is intended to be is actually fake news. In this case, it is what I can only assume is a bug with Tweening that causes every cell affected by it to be set to Screen Priority, making it glitch out when played in game. The priority can be reset using Cell Batch, but as we have already discussed, Cell Batch is a miserable laggy experience that I would wish on no one.

The Copy Frames and Clear Frames buttons are fairly simple. Delete everything in the given frames-- or copy the set of frames to overwrite whatever is after the frame you ask it to put them after. These are okay features functionally, but not especially useful.

The Paste Last button immediately copies the last frame onto the current one. This is the simplest button here (aside from Help, but let's not talk about that anymore) but one of the most useful, since we can then continue whatever motion or coloring we want from the last frame easily.

The Cel Focus brings up this small menu:

These are of course, the potential focuses. It might be reasonable to conclude that this sets a property for the animation as a whole. For instance, maybe it could tell Toxic Spikes to look for the user instead of pretending like attacking pokemon are social constructs. But it does no such thing. What this does is set the default focus that new cells are made with. Unfortunately, since Tweening is so incredibly useful but also glitches to set everything to Screen anyway, this menu is entirely useless, and I have not used it in at least thirty one years.

Last but far from least is the SE and BG button:

I call these Cues. If the animation were a stage play, then the cells are the actors on the stage, and the properties are their costumes. However, what goes on with the Sound and Lighting isn't done by the actors, but by the backstage crews based on cues in the script. That is basically what this menu is. "At X Frame, do Y with either a sound or a background."

Therefore this menu is critical in every single animation. Unfortunately it also lags if you get more than a few cues on it, and can take half a minute to even open at all. Naturally. 

The bottom part lists the frame you are currently creating a cue for. The Set Frame button allows you to change a previously created cue to the number selected above. Deleting Timing deletes the cue.

The top part lists all the cues that exist so far, so you can edit or add new ones. A sound cue menu looks like this:

The Play User's Cry is a very nice option. The rest is a list of sounds that must be scrolled through. Although Page Down and Page Up work here too, it still takes a while when you, as we do, have 1,856 sound files and counting. It is worth noting you have to be pretty particular about finding the sound, and then selecting it to load into the right screen, and then click okay, as it will not save the cue with the right file otherwise. I have backed out too early many times, and been forced to scroll through 1,856 sound files once yet again. 

The background and foreground cues are effectively identical, just one is behind and one is in front. Their menus look like this. We choose a file, and we assign some properties for it. A separate option, the fg/bg editing cues, allows us to change those properties over several frames. It looks like this:

Let's talk about this for just a moment though. As you can see, properties that a background has are the position, the opacity, and the coloring. However, if it is has not been made abundantly clear by now half of this editor is glitched, and this menu was one of the worst examples of it. 

The color properties for backgrounds did not work at all. No matter what we tried to do with them, there was no change.  Further, as work went on we discovered that the positioning of the background was also glitched when moving it. It would stagger and reset and go in random directions and bug out in all kinds of way unless, we discovered, we moved it exactly a multiple 130 pixels at a time. To this day I do not know why this was the case, but it worked for us. You will find if you check the animations in E16, that many animations with moving backgrounds move them to a multiple of 130 pixels. 

So basically, out of the three properties we could change, only one of them actually worked. Whoopee. 

Fortunately after E16 we got Marcello on the case with this error, since it was preventing us from properly handling moves like Earthquake and Magnitude. Marcello took a dive into our animation code, and found the cause of the issue. He made some changes and passed it back to us, and we tested it out. Sure enough, not only did he fix the positioning glitch, he also fixed the BG-coloring for us!! That really opened some doors.

It also closed some doors. One door in particular-- the main one. Because he accidentally made it so that the editor crashed whenever we tried to save animations. Oops.

So we had him fix that. And we tested his fix, and saving worked!! And so we went back to happily animation-- only to find that it was still crashing. But only sometimes. We'd later figure out he'd partially fixed the glitch, but it made the animation crash after any time we used the Play Animation button. Of course, we only use that after doing a decent amount of work anyway, so that sucked. 

But then we fixed that too! And now things are good again. With that much anyway. The rest of the editor is still a disaster.

But with perseverance and dedication, we can handle anything. We've made almost 900 animations with the state it's in now, so I'd say there ain't a whole lot more that can stop us, ne?

I think I'll have Marcelllo take a look at the tweening and define curve bugs... but I'll make sure we don't try to save anything in the mean time ^~^