Animation Action

[DerVVulfman]

Incorrect on the assessment.

First, there are a few systems the Skill Casting system works, but most custom systems already have their own delay add-ons, so that is moot.

Insofar as that, the ACBS By Victor Sant (formerly Atoa) also has a skill casting system. But that is not the issue. The issue is that all DELAY systems, whether mine or the one built for the ACBS has the battler sprite's action delayed for a set time before going into action. This 'action' being the character stepping forward to perform their attack.

If anyone wishes to have Freddy waving his hands to channel arcane magicks to ready a spell before stepping forward to unleash a fireball, things would be fine. However, the desired effect is to have the battler first stepping forward before going through the chanting delay with its pose. Once the chanting was done, the battler unleashes the attack and then steps back. This being different from how any other delay system works.

The ACBS has several 'methods' I am looking at which govern's character movement. It would be entertaining if I could craft a variant which permits this custom delay. The delay feature built into the ABS & CBS addons use a key-phrase called 'CHANTING' which can be attached to an attack by its ID. So MY idea would be a variant called 'CHANTSTEP' to (hopefully) allow stepping forward before chanting. OR something like that. But it isn't easy.

[Steel Beast 6Beets]

Guess I was off the mark.

Reading what needs to be done, it truly sounds exceedingly complicated.

[justpassingby]

Alright. I am personally fine with no "chanting animation and wait a few turns before casting magic". And while it is not related to chanting, it is still related to animation in general which the skills category is part of.
Consider this semi-off topic.

As shown in the attachment below. I looked at Victor's/Atoa's Leon sprite sheet example but it was not really of much help in letting me know whether I can have the attachment sprite sheet be part of the normal attack animation.
Doing skills/magic animation is not hard at all. I just need patience to put things in the right place.
But not this one.
And does not matter whether it is a canon character or original character as what matters is whether it can be done or not, no?

P.S.: I should perhaps change the thread title to Animation Action so that not just Skills/Magic but also the normal Attack function animation can be discussed.

  Normal Attack Animation.png (Size: 58.95 KB / Downloads: 2)

[DerVVulfman]

Wishing to use that collection of 13 frames? It is all a matter of spritesheet styles.

The ACBS system permits the use of two different methods of sprite animation, minkoff/cybersam spritesheets and ccoa's spritestrips.

The Minkoff system as it is typically known (though his battlesystem began roughly parallel to Cybersam's) used a single file we call a sprite sheet. It is a collection of animation frames in a set format. Originally, this was a rigid format of only having four frames of animation for each visible action, each action needing to be placed in a specific row. But now most systems which use these spritesheets set up their systems to go beyond four frames, or allow one of the action poses to be a mere single frame. Yet, you were limited to only one spritesheet per battler. If you needed to add new poses or animations, you would need to actively edit that spritesheet.

The ccoa system was designed by the co-owner/founder of 'then' RMXP.Org (now HBGames) back in 2007 for her own sideview battlesystem. Unlike the other system, each battler in her system used multiple strips of animation cells. Each strip covered a single battle action, be it a weapon attack, the use of an item or casting of a fireball. But unlike the minkoff system, ccoa's battlesystem was designed to already go beyond the traditional four-frame animation protocol. While one battler may be using a sprite strip with three frames of animation for their 'idle' pose, another may have a longer 'idle' pose which lasts five frames. But while offering flexibility, it did have a drawback of requiring multitudes of individual graphic files per battler.

Personally, I have always used the Minkoff system, and for 'my' system I made a paperdoll application which may not be ccoa compatible.

Either option you choose, your single attack animation must be aligned horizontally. This means you cannot use a graphic image holds multiple rows of images for a single action as yours. For either system, you would need to slice this image into a single strip holding the 13 frames left to right.

[justpassingby]

@DerVVulfman
Ah, I see. I kind of figured that out along the way.
But the problem is that, if I am not mistaken, one sprite should be in a 192x192 box.
A maximum of 5 sprites horizontally (as it will cut off the rest after that) but vertically is Unlimited.
However, I noticed one spritesheet having 7 sprites horizontally.

So... I guess it is like this.
For skills animation, the limit for horizontal is 5 no matter what and vertical is Unlimited.

But for the main character Battle Poses of Idle, Defend, Charge Forward, Charge Back, Dying State and Dead State can have Unlimited Horizontal and Vertical Sprites for the animation to work?
I may be wrong there as I have not tested that yet.

[DerVVulfman]

If you look at the default ACBS demo, there is a 'ccoa' battler for a character named Wenia. He 'base' battler is a 91x91 single-image sprite. As her battler is set for ccoa strips, she has other graphic files, ala the strips. One for the 1st pose has 3 frames, it being 173x91. But the second image holds 2 frames being 182x91. And if you look at the 5th to 8th strips, they are 455x91 in size.

And you set her custom poses in the script like so:

Code:

Pose_Sprite['%Wenia'] = {'Base' =>[5,13,200,false],
    1 =>[3,8,true], 2 =>[2,4,false], 3 =>[2,12,true], 4 =>[1,4,true], 5 =>[5,4,true],
    6 =>[5,4,true], 7 =>[5,2,false], 8 =>[5,4,false], 9 =>[1,4,true], 10 =>[1,4,true],
    11 =>[1,4,true], 12 =>[5,4,false], 13 =>[1,4,true]}

In each [#,#,#] value after the base, the first value points out how many frames are in that particular spritestrip. The second value is the speed per frame and the third is if it loops. So if you want to use an 8-frame long strip for pose #10, it would be [8,4,true] instead of [1.4,true] as it appears.

[justpassingby]

Code:

  Pose_Sprite['%Wenia'] = {'Base' =>[5,13,200,false],
    1 =>[3,8,true], 2 =>[2,4,false], 3 =>[2,12,true], 4 =>[1,4,true], 5 =>[5,4,true],
    6 =>[5,4,true], 7 =>[5,2,false], 8 =>[5,4,false], 9 =>[1,4,true], 10 =>[1,4,true],
    11 =>[1,4,true], 12 =>[5,4,false], 13 =>[1,4,true]}

In each [#,#,#] value after the base, the first value points out how many frames are in that particular spritestrip. The second value is the speed per frame and the third is if it loops.  So if you want to use an 8-frame long strip for pose #10, it would be [8,4,true] instead of [1.4,true] as it appears.

Ah, so that means I have control over that part of the example. Will experiment after office hours again. And if things still go wacky again, I'll just take that motorbike and use it myself to get back here.

Edit: Back as expected. Things look good. However, things also went out of hand. The Battle Positions, Defend, Attack, Charge Forward, Charge Back, etc. sprite strips work rather well. At least when it is in the 91x91 box. If I were to, let's say, go for a 192x192 box as I need more space per sprite animation, things cut off like crazy. My question: What is the box limit size for the normal Battle Positions sprites? As stated, 91x91 works well but it's a bit space restricting to perform the correct animation positioning.