• Do not use Discord to host any images you post, these links expire quickly! You can learn how to add images to your posts here.
  • Reminder: AI-generated content is not allowed on the forums per the Rules and Regulations. Please contact us if you have any questions!
New Battle Animation Editor (v22 preview)

Resource New Battle Animation Editor (v22 preview) 2.1.6

Maruno

Essentials dev
Essentials Developer
Joined
Apr 5, 2017
Posts
571
Maruno submitted a new resource:

New Battle Animation Editor (v22 preview) - An advance preview of the new battle animation system and editor that will be in Essentials v22.

V9ql6eVh_o.png

Description​

This plugin contains the new battle animation system and editor I've been working on for Essentials v22. It's been in development a long time, and is the last big thing to sort out before the release of Essentials v22.

This new animation system revolves around particles, which appear and disappear, move around, change colour and all that fun stuff. This is different to the existing...

Read more about this resource...
 
So, I played around with it for a bit, and I got this error when I scrubbed the time bar too far to the right.

Ruby:
Expand Collapse Copy
[2026-03-01 18:32:09 -0500]
[Pokémon Essentials version 21.1]
[v21.1 Hotfixes 1.0.9]

Exception: NoMethodError
Message: undefined method `+' for nil:NilClass

Backtrace:
[New Animation Editor] 006_Timeline.rb:665:in `update_time_bar_control'
[New Animation Editor] 006_Timeline.rb:640:in `update_controls_and_particles'
[New Animation Editor] 006_Timeline.rb:756:in `update'
[New Animation Editor] 007_AnimEditor_refresh_update.rb:320:in `block in update'
[New Animation Editor] 007_AnimEditor_refresh_update.rb:317:in `each_pair'
[New Animation Editor] 007_AnimEditor_refresh_update.rb:317:in `update'
[New Animation Editor] 007_AnimEditor_refresh_update.rb:350:in `block in run'
[New Animation Editor] 007_AnimEditor_refresh_update.rb:347:in `loop'
[New Animation Editor] 007_AnimEditor_refresh_update.rb:347:in `run'
[New Animation Editor] 001_AnimationSelector.rb:550:in `apply_button_press'
 
I had recently made a few small changes to the current animator to ease the creation of move anims but this looks really interesting. I'll try it in my personal project tomorrow, see if it runs with the other plugins and changes I made, otherwise I'll use the blank dev branch of essentials. I'll be back with some anims, review and if I happen to have any, ideas or changes I think would be good to have.

Thanks for now, really itching to play around with this!
 
Via the new animation editor, we can look into porting animations from the following resources (with credits to the original authors and graphics rippers, of course):

NocTurn's ~45 HGSS-style animations (with credit to NocTurn and SpritersResource.org): https://eeveeexpo.com/resources/650/
  • Also includes status effects for Sleep, Paralysis, Poison, and Confusion
  • Ignore ones already covered by Essentials, such as Tackle and Defense Curl
Luka SJ's Elite Battle: DX: https://luka-sj.com/res/ebdx
  • Includes many common animations, such as for Stat Up, Stat Down, HP up, and Shiny sparkles
  • Many are accurate to the DS games, such as Flare Blitz, Close Combat, Flash Cannon, Earthquake, and Hydro Pump
Deluxe Battle Kit (DBK) by Lucidious89: https://eeveeexpo.com/resources/1470/
Hope this helps
👍
 
Something I noticed immediately, though this is pretty minor and really just a visual thing:

In 002_AnimEditor_SettingsMixin.rb, line 28 and 29,
the :user_sprite_name and :target_sprite_name are "DRAGONITE" and "CHARIZARD", which is perfectly fine on it's own.
:user_sprite_name => "DRAGONITE",
:target_sprite_name => "CHARIZARD",

However, if someone opts to use the Animated Pokemon System plugin from Lucidious89, the pokemon sprites are all replaced by sprite sheets.

Perhaps you'll consider changing the sprite names to "DRAGONITE_anim" and "CHARIZARD_anim", and include copies of these , so there is no conflicts like this? Pokemon cry SE files as well ofc.

The editor looked like this with the sprite sheets, a bit jank, but easy to address.
JPX7U25.png

Edit: This breaks again when changing the "User graphic" or "Target graphic" inside the Editor Settings, the only fix being to delete the "debug_settings.rxdata" file which serves as settings "save file", located in appdata/roaming/"NameOfFanGame".

RbjNs3w.png





Features I'd like to have:
  • Mouse Wheel functionality in the upper area, where the sprites, background and particles are visible:
    • Using the mouse wheel scroll should adjust the angle of the particle, scroll up being counter-clockwise and scroll down being clockwise.
    • Holding SHIFT while scrolling should adjust the angle a greater amount.
    • Holding CTRL while scrolling should increase/decrease zoom.
  • After reading about the bug regarding mkxp-z, that's probably not gonna be doable in a way I imagine it to work, so perhaps we can instead use regular old keys like Q/E for angle adjustment and two other keys for zoom adjusment?
  • CTRL+A to select all text in all text fields, deleting letters one by one gets annoying fast.
  • Search bar when selecting the graphic for the particle. Scrollings gets annoying fast.
  • Change aspect ratio to 16:9. I know Essentials usually works with 512x384, but does the entire editor interface have to be constrained to that? If you extend the bottom area, the timeline, but leave the canvas up top untouched, would it be possible to grant more "screen area" for the timeline below?
 
Last edited:
The learning curve has been a bit rough, especially without documentation, but I managed to get a somewhat "ok" animation for Fire Blast done.
The issue I came across is: One of the particles was initially an emitter, but I then changed it to regular particle during editing. When saving, it doesn't seem to remove the "SetEmitting =" lines inside the pbs file for the particle.

<Vortex Spinner>
Graphic = vortex 2
Focus = User
SetZ = 0,5
SetZoomX = 0,50
SetZoomY = 0,50
SetColor = 0,DC9800FF
SetEmitting = 0,true
MoveAngle = 0,30,-180
SetEmitting = 30,false
MoveOpacity = 30,57,0
SetEmitting = 45,true

This causes an error during compilation:

[2026-03-04 17:22:51 +0100]
[Pokémon Essentials version 21.1]
[v21.1 Hotfixes 1.0.9]

Exception: RuntimeError
Message: Particle "Vortex Spinner" isn't an emitter but has an "Emit"-type command.
File PBS/Animations/FIREBLAST.txt, section Move,FIREBLAST
[Move,FIREBLAST]



Backtrace:
[New Animation Editor] 001_Compiler_CompileAnimations.rb:233:in `block (2 levels) in validate_compiled_animation'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:224:in `each'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:224:in `block in validate_compiled_animation'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:221:in `each'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:221:in `validate_compiled_animation'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:182:in `block in compile_battle_animations'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:111:in `each'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:111:in `compile_battle_animations'
[New Animation Editor] 001_Compiler_CompileAnimations.rb:469:in `main'
999_Main.rb:32:in `mainFunctionDebug'
999_Main.rb:19:in `block in mainFunction'
003_Errors.rb:79:in `pbCriticalCode'
999_Main.rb:19:in `mainFunction'
999_Main.rb:49:in `block (2 levels) in load_scripts_from_folder'
999_Main.rb:48:in `loop'
999_Main.rb:48:in `block in load_scripts_from_folder'
Main:31:in `eval'
Main:31:in `block in load_scripts_from_folder'
Main:28:in `each'
Main:28:in `load_scripts_from_folder'
Main:42:in `block in load_scripts_from_folder'
Main:41:in `each'
Main:41:in `load_scripts_from_folder'
Main:46:in `<main>'
-e:in `eval'

Manually removing the faulty lines fixes the error.

Here's how the move looks.

imgur vid 1
imgur vid 2



I see the potential of the new editor, especially with the emitters and interpolation handling a ton of movement and adding smoothness, but it'll take some time becoming good/fast with it.

What I would love to see is an "orbit" option for the emitter, which makes particles "rotate" around a point with adjustable distance.
If this is already possible, I'd be glad to hear how to accomplish that.
 
Last edited:
Something I noticed immediately, though this is pretty minor and really just a visual thing:

In 002_AnimEditor_SettingsMixin.rb, line 28 and 29,
the :user_sprite_name and :target_sprite_name are "DRAGONITE" and "CHARIZARD", which is perfectly fine on it's own.
:user_sprite_name => "DRAGONITE",
:target_sprite_name => "CHARIZARD",

However, if someone opts to use the Animated Pokemon System plugin from Lucidious89, the pokemon sprites are all replaced by sprite sheets.

Perhaps you'll consider changing the sprite names to "DRAGONITE_anim" and "CHARIZARD_anim", and include copies of these , so there is no conflicts like this? Pokemon cry SE files as well ofc.
I don't know how that plugin works, and I have no real desire to find out to add compatibility with it.

Please don't use imgur to share images. Imgur blocks people in the UK from accessing it, so they can't see those images without using a VPN.

Features I'd like to have:
  • Mouse Wheel functionality in the upper area, where the sprites, background and particles are visible:
    • Using the mouse wheel scroll should adjust the angle of the particle, scroll up being counter-clockwise and scroll down being clockwise.
    • Holding SHIFT while scrolling should adjust the angle a greater amount.
    • Holding CTRL while scrolling should increase/decrease zoom.
  • After reading about the bug regarding mkxp-z, that's probably not gonna be doable in a way I imagine it to work, so perhaps we can instead use regular old keys like Q/E for angle adjustment and two other keys for zoom adjusment?
The extra canvas functionality could be: mouse wheel to zoom in/out, and right-click-and-drag to change the angle. Mouse wheel + Ctrl would zoom in/out faster (Ctrl is the standard "do it faster" button), and there's no need to add something similar for changing the angle. Although maybe the mouse wheel shouldn't be used because it's relatively easy to knock by accident. I've made a note of this, but it's low priority.

  • CTRL+A to select all text in all text fields, deleting letters one by one gets annoying fast.
  • Search bar when selecting the graphic for the particle. Scrollings gets annoying fast.
  • Change aspect ratio to 16:9. I know Essentials usually works with 512x384, but does the entire editor interface have to be constrained to that? If you extend the bottom area, the timeline, but leave the canvas up top untouched, would it be possible to grant more "screen area" for the timeline below?
Added functionality for text boxes is on the list, although I think anything involving selecting text will be a bit tricky. A filter box for graphic/SE choosing windows should be added soon.

Your comment about changing the aspect ratio doesn't make sense. It's as wide as it needs to be, and it's as tall as possible while still fitting on your monitor. It's a coincidence that this ends up being a pretty square window. There's no way to give more space for the timeline - the canvas has to exist and be the size it is, and there's no other thing taking up height that could be used for the timeline.

The learning curve has been a bit rough, especially without documentation, but I managed to get a somewhat "ok" animation for Fire Blast done.
I want to make a page on the wiki that explains everything. I just haven't gotten around to it yet. It would help to know which specific topics are more difficult to understand so that they can be prioritised.

What I would love to see is an "orbit" option for the emitter, which makes particles "rotate" around a point with adjustable distance.
If this is already possible, I'd be glad to hear how to accomplish that.
An example of what you want to do helps.

"Helix" is used by the Sand Tomb animation that comes with the plugin. Since the speed property for it dictates how quickly the emitted sprites move vertically, Just use a speed of 0. You can't vary the orbit radius of a given sprite, though. However, this will only make the particle move left/right in its orbit, not up/down.

Alternatively, you can use "NoMovement" and instead define a custom movement like you would for a regular particle (changing X and Y). This gives you full control over how the sprites will move, but won't let you spawn sprites in a random part of the orbit like "Helix" can. You can cheat that randomness in by having multiple emitters, each with different movement commands designed for different starting positions.
 
The extra canvas functionality could be: mouse wheel to zoom in/out, and right-click-and-drag to change the angle. Mouse wheel + Ctrl would zoom in/out faster (Ctrl is the standard "do it faster" button), and there's no need to add something similar for changing the angle. Although maybe the mouse wheel shouldn't be used because it's relatively easy to knock by accident. I've made a note of this, but it's low priority.
These would be great, thanks!

Added functionality for text boxes is on the list, although I think anything involving selecting text will be a bit tricky. A filter box for graphic/SE choosing windows should be added soon.
Perhaps change DEL to instead delete all text in the textbox? If that works and is easier to do, would be great. I just really want a way to delete all the letters at once instead of one by one.

Your comment about changing the aspect ratio doesn't make sense. It's as wide as it needs to be, and it's as tall as possible while still fitting on your monitor. It's a coincidence that this ends up being a pretty square window. There's no way to give more space for the timeline - the canvas has to exist and be the size it is, and there's no other thing taking up height that could be used for the timeline.
I couldn't find the right words to describe what exactly I wanted, but here are some images, maybe they'll help? If not, or simply too much work for too little benefit, that's unfortunate but understandable for the general userbase.
widenededitor.png

But I don't even know if this is doable, I know that changing the width/height in the 001_Settings.rb does actually work for the game without any issues. Though naturally, given that pretty much all of Essentials is built around the screen being 512x384 baseline, including all the graphics etc. I can see why remaking all of these would be a huge time sink.

widenedscreen.png
I thought that it'd maybe be possible to "temporarily change the screen width in-game" for the editor, and simply have the bottom area of the editor be wider than the canvas area. Upon exiting, the game would simply use the regular width again.

An example of what you want to do helps.

"Helix" is used by the Sand Tomb animation that comes with the plugin. Since the speed property for it dictates how quickly the emitted sprites move vertically, Just use a speed of 0. You can't vary the orbit radius of a given sprite, though. However, this will only make the particle move left/right in its orbit, not up/down.

Alternatively, you can use "NoMovement" and instead define a custom movement like you would for a regular particle (changing X and Y). This gives you full control over how the sprites will move, but won't let you spawn sprites in a random part of the orbit like "Helix" can. You can cheat that randomness in by having multiple emitters, each with different movement commands designed for different starting positions.
Does this help?
Sprite.png
Sprite2.png



Using the NoMovement emitter like you recommended works alright, but I still think a dedicated circular emitter with options such as distance from emitter would be better. That way I could easily make a repeating circular motion animation that "closes in" on the emitter or "spreads out". But maybe I'm simply not using the emitter properly or optimally.
The 2nd video creates more of a "spiral", but that's not what I want, I want a circle of particles closing in or expanding out.

EDIT: Actually, simply creating a graphic that has multiple particles arranged in a circle and adjusting angle+zoom could work...
 
Last edited:
I couldn't find the right words to describe what exactly I wanted, but here are some images, maybe they'll help? If not, or simply too much work for too little benefit, that's unfortunate but understandable for the general userbase.
widenededitor.png

But I don't even know if this is doable, I know that changing the width/height in the 001_Settings.rb does actually work for the game without any issues. Though naturally, given that pretty much all of Essentials is built around the screen being 512x384 baseline, including all the graphics etc. I can see why remaking all of these would be a huge time sink.

widenedscreen.png
I thought that it'd maybe be possible to "temporarily change the screen width in-game" for the editor, and simply have the bottom area of the editor be wider than the canvas area. Upon exiting, the game would simply use the regular width again.
The canvas in the editor is the same size as the game window normally. If you make your game widescreen, the canvas will be that widescreen.

I don't want to make the editor window wider than it already is, just for the sake of showing a few more keyframes at once, though. As you've shown, this would require putting unsightly empty space in the top left and right corners, and I think the number of keyframes we can see at once is already fine.

Does this help?
Sprite.png
Sprite2.png



Using the NoMovement emitter like you recommended works alright, but I still think a dedicated circular emitter with options such as distance from emitter would be better. That way I could easily make a repeating circular motion animation that "closes in" on the emitter or "spreads out". But maybe I'm simply not using the emitter properly or optimally.
The 2nd video creates more of a "spiral", but that's not what I want, I want a circle of particles closing in or expanding out.

EDIT: Actually, simply creating a graphic that has multiple particles arranged in a circle and adjusting angle+zoom could work...

The same new emitter type that has this movement could also be used for part of Flash Cannon's animation, and also the first part of Flame Wheel (although that could also be achieved with a NoMovement emitter).

It's on the list. I need to properly sit down and ponder what options it will need, and whether improvements can be made to the similar Helix emitter type. It takes some time to figure out and implement.
 
Back
Top