Posts: 2
Threads: 0
Joined: Nov 2009
Hi, I have the older animated battlers script you made, but for rpgmaker VX... I got it from here some months ago, and now I see that you updated a few things... I want to know which demo contains the scripts for rmvx so I can replace the old one I have been using. Thanks in advance.
Posts: 11,231
Threads: 649
Joined: May 2009
Ah. Well, you will be looking for Animated Battlers VX. It has its own thread and has also had a few more nuances added.
In fact, they both now use the same .pdf manual and share the same configuration page for convenience. :cheery: Enjoy.
- Remember to check the FORUM SCRIPT LISTINGS which is a catalog of our scripts separated by categories. Thank you -
Posts: 1,127
Threads: 43
Joined: May 2009
Hey. I have just tested the newest version of Anim Battlers with the FFX CBS and it looks like compatibility is very good.
I just had to replicate a change that I also had done in the previous version I used, and that is:
Code: if MNK_MOVING_SKILL.include?(battler.skill_used) ; full_moving = true ; end
# CHARLIE BEGIN
if MNK_MOVING_SKILL.include?(battler.skill_used) and
($game_temp.selecting_all_enemies==true or $game_temp.selecting_all_allies==true); full_moving = false ; center_move = true ; end
# CHARLIE END
if MNK_MOVE2CENTER_SKILL.include?(battler.skill_used) ; center_move = true ; end
...
in "3 - Battle System". Maybe you could add this code under an "if ($charlie_lee_ctb)" condition or something like that, in order to make users easily update the adopted Anim Battlers version in the future.
I also noticed that now the enemies' sprites are always "under" the party members' sprites. Is that intentional?
I was thinking about a feature... how about battlers that get pushed back a little when physically attacked? It helps when you don't have an animation to show.
Posts: 2
Threads: 0
Joined: Nov 2009
DerVVulfman Wrote:Ah. Well, you will be looking for Animated Battlers VX. It has its own thread and has also had a few more nuances added.
In fact, they both now use the same .pdf manual and share the same configuration page for convenience. :cheery: Enjoy.
- Remember to check the FORUM SCRIPT LISTINGS which is a catalog of our scripts separated by categories. Thank you -
Ohh no wonder I couldn't find it here lol... I'll go check it out now. Thanks a lot.
Posts: 11,231
Threads: 649
Joined: May 2009
Hyperiria:
No problem. :cheery:
Charlie:
Hm. Nice. And for implementing your snippet into the code, I will certainly look for a method of auto-detection as I did for RTAB, Trickster's systems, ParaDog and the like. :smile:
As to being under/over the other battlers, the z depth is made to equal the value of the y-position of the battlers. Who is drawn over whom is dependent on where they are positioned.
As to the being pushed back? That may be a bit difficult, though animation poses such as the white ties ripped battlers that Minkoff used in his original demo had the images themselves shifted a pixel or two a frame in the 'struck' pose.
Posts: 1,127
Threads: 43
Joined: May 2009
DerVVulfman Wrote:Hm. Nice. And for implementing your snippet into the code, I will certainly look for a method of auto-detection as I did for RTAB, Trickster's systems, ParaDog and the like. :smile:
Sure. I put that global in my example because I'm actually using it already. But just tell me what form would be better and I put it in version 2.15.
DerVVulfman Wrote:As to being under/over the other battlers, the z depth is made to equal the value of the y-position of the battlers. Who is drawn over whom is dependent on where they are positioned.
mmm... it doesn't look like that... maybe there's something not working the way it should here, must investigate...
DerVVulfman Wrote:As to the being pushed back? That may be a bit difficult, though animation poses such as the white ties ripped battlers that Minkoff used in his original demo had the images themselves shifted a pixel or two a frame in the 'struck' pose.
Yes, clearly it can be done with spritesheets, but I was thinking about when you use charactersets, 1-pose spritesheets or even still sprites. Having an option like that would be a very cheap way to get a nice looking effect.
EDIT: just corrected the snippet of code up there with "battler.skill_used" in place of "@skill_used"
Posts: 1,127
Threads: 43
Joined: May 2009
Maybe I figured out the reason of the enemies being displayed under the party members. I think it all depends on the configuration of SCREENTONE_ENEMY_MATCH and SCREENTONE_ACTOR_MATCH. When the two are different, the enemies end up in a viewport and the party members in another viewport and this messes up the z/y-coordinate based arrangement. I remember now that for the same reason I only use @viewport1 both for enemies and party members.
I guess I will add a note to the instructions stating that one has to set both SCREENTONE_ENEMY_MATCH and SCREENTONE_ACTOR_MATCH to true in order to remove this little glitch.
Posts: 1,127
Threads: 43
Joined: May 2009
I have a suggestion for the formation system. How about formations that automatically change depending on the number of battlers?
The coordinates could be set by the user with something like:
{ id => { actors_number => [ formation set 1a ], actors_number => [formation set 1b], ... },
id2 => { actors_number => [ formation set 2a], actors_number => [formation set 2b], ... }
}
Why do I think something like this would be useful? Well, it is weird when there is only one party member and he is stuck at the top of the battle field because the formation has been planned for four party members...
However I must say that there is also a way to do this with the system as it is, but it would require a script or a battle event checking the number of battlers and switching the formation id to the one planned to that number...
Posts: 11,231
Threads: 649
Joined: May 2009
Well, you could use perform a script call to change the formation before the battle starts. I mean... If X battlers, use this. If Y battlers, use that.
And you really do not want to change formations in-battle. You see, if you have a dead actor battler and wish to revive him/her, you need his 'formation spot' as a placeholder. Whether he/she is visibly dead or invisible for a collapse, the formation system will need that place kept vacant so the 'arrow' can point the battler out for a revive potion or the like.
Posts: 1,127
Threads: 43
Joined: May 2009
Well, I wasn't thinking about changing the formation based on the number of alive party members, but on the total number, including the dead ones. That would address all the issues in your scenario.
My problem with setting the formation before the battle would be adding and removing members in battle, and summons for example.
Technically, with the current code, would changing the formation during a battle work?
|