Can be modified and distributed as long as the credits remain
for portuguese users: Here
Script functions
The script modifies the basic turn based system for an active time based, this affects any system that was made on Scene_Battle.
- Allows total configuration of ATB formulas and Flee speed
- Allows to modify refresh rate
- Allows skills/items to have an optional atb cost(if you do not want it to deplete the whole bar)
- Allows the atb to be by images(for those who uses images instead of windows)
- adds the flee function similar to games with the ATB system, where you need to keep a configured button pressed to run.
- Obs: Any skill that either raises ou depletes a parameter(in general speed), from the formula, will change how fast will be the atb bar, so you can create skills to make either faster or slower.
I just noticed a bug xD it work with tankentaii! just....when the atb is full this bug and...not refresh the atb XD and I block on the selected character >>
EDIT : nevermind I needed to put your script below tankentai
I just noticed a bug xD it work with tankentaii! just....when the atb is full this bug and...not refresh the atb XD and I block on the selected character >>
EDIT : nevermind I needed to put your script below tankentai
hahah I highly doutb you will want to bug fix a 4000 lines script only in japanese XD
but the reason why this compatible is because you use the turn end and the turn start from the scene battle so this why this work !
this not like moghunter atb who use the BATTLEMANAGER turn_end and turn_start for make is script ¬¬"....most atb script does that so this why most atb script are incompatible with tankentai UU!
I don't know if it's a bug or just my mistakes, but when Allow_Flee is true and I press the Flee_Input button, the game crashed with the below error log:
Akea Active Time Battle:353:in 'call_update_flee': undefined method 'screen_x' for #<Game_Actor:0x4d3cfbc>, NoMethodError
Then I've checked that line:
@back_flee_atb.x = Akea_Active_Battle::Flee_Back_Pos[0] + $game_party.members[@actor_atb_array.first].screen_xBut in the default RMVXA scripts, Game_Actor has no screen_x nor @screen_x attr_reader. So it's either a bug or I didn't use scripts that this script needs.
If it's the former, maybe using the method_missingscreen_x) check can do the job.
There is a setting named 'Has_Ator' and if you don't use a battle system which defines screen_x/y, you will need to set that to false.
----
I just tried this system in the project I'm working on, and I was surprised that it works without minimal tweaking with Yanfly's Battle Engine, Theo's SBS and with my custom animated battle HUD scripts... Quite a rare thing to happen! o.o
I encountered some weird errors, like:
- The ATB script trying to call the actor command window without a BattleManager.actor set, which should never happen I guess, so I have no idea how this happened, but a simple nil check fixed it.
- After fixing the above, I had trouble starting those ATB bars to move... Turns out if the refresh rate is not set to 1, sometimes the ATB bars will NOT move. Actors and enemies alike will be stuck waiting forever. o.o
Setting the refresh rate to 1 fixed it, so far no freezes happened.
And not an error, I guess, but a rather odd way to do... The picture based ATB bars... No matter what kind of picture I used, the ATB bars were distorted and they looked pretty bad. Is there a specific type of image I should use maybe?
For now, I changed the refresh method for the ATB sprites to my own method, but I am curious how should they look like with that zoom method you used.
And a last question:
Do you plan to add more features to this ATB system? I noticed that there is only a "wait" type of ATB right now, no "full" or "semi-wait" types. Any chance to add these in the future? *-*
Turns out you're right, maybe(and probably as I can't think of any other reason that makes sense) there's something wrong with my copy(like content loss due to copying/saving), or maybe mine's just outdated(although extremely unlikely). In my copy, no such thing exists, so that line of code will be always called
I just tried this system in the project I'm working on, and I was surprised that it works without minimal tweaking with Yanfly's Battle Engine, Theo's SBS and with my custom animated battle HUD scripts... Quite a rare thing to happen! o.o
I encountered some weird errors, like:
- The ATB script trying to call the actor command window without a BattleManager.actor set, which should never happen I guess, so I have no idea how this happened, but a simple nil check fixed it.
- After fixing the above, I had trouble starting those ATB bars to move... Turns out if the refresh rate is not set to 1, sometimes the ATB bars will NOT move. Actors and enemies alike will be stuck waiting forever. o.o
Setting the refresh rate to 1 fixed it, so far no freezes happened.
And not an error, I guess, but a rather odd way to do... The picture based ATB bars... No matter what kind of picture I used, the ATB bars were distorted and they looked pretty bad. Is there a specific type of image I should use maybe?
For now, I changed the refresh method for the ATB sprites to my own method, but I am curious how should they look like with that zoom method you used.
I haven't comprehended this script yet(just have a really vague understanding), but my wild guess is that they're compatibility issues. Of course Raizen, the script author, always knows better
I tried Moghunter's ATB and your's too, but kinda got annoyed by fixing one error after another, so I gave up on them. I even got errors with the @help_window, I mean, wtfruit, what does the @help_window got to do with an ATB script? o.o
Raizen's is stable enough, it seems, and the sprite based ATB bars made it perfect for my battle HUD, since most ATB scripts add their bars within the status window, but I have completely replaced that poor excuse of a drawing method in the status window to my own, so the ATB bars either won't show up (which is better than the next option) or my status HUD is completely destroyed by the ATB script (in the case of MOG's AT.
Not to mention that it takes way less processing time to refresh a single sprite per actor than a whole window with all the statuses of the actors redrawn every frame.
The only thing I miss from this ATB is the types of ATB (full, semi-wait and wait, or how they are called). The rest is perfect for my needs.
About the other types xD... I was doing both of them, the real active, and this one the wait...
But I noticed doing the active or full type, was making me overwrite a lot of methods... And I guess that is why these types of ATB has little compatibility with other battle scripts and this doesn't...
The images are just plain bars, I can upload a demo with them if you want xD, and I guess that's the biggest issue right now.. Or not xD.
Well but tell me if you have anything else I can help
Not to mention that it takes way less processing time to refresh a single sprite per actor than a whole window with all the statuses of the actors redrawn every frame.
I know it's off-topic, but I still want to stress that even when the atb bars are drawn on the status window, it's mostly redundant to refresh the entire status window instead of just the atb bars themselves, as long as the atb bar length and position doesn't change. If there are text on the atb bars, as long as the text content, size and position doesn't change, the text display might appear slightly buggy, but I don't think that's worth redrawing the entire status window per frame.
I think drawing the atb bars using separate sprites/viewports will be even much, much faster though(as it changes the displayed portion instead of redrawing the whole bar when changing bar length), but as I haven't benchmarked that, I'm not 100% sure on this one.
P.S.: Whenever I see an atb system script that refreshes the entire status window per frame, I'd ask why. But in most cases I failed to find any valid reason lol
About the other types xD... I was doing both of them, the real active, and this one the wait...
But I noticed doing the active or full type, was making me overwrite a lot of methods... And I guess that is why these types of ATB has little compatibility with other battle scripts and this doesn't...
I've to comprehend yours first to understand why you'd need to overwrite lots of methods, but I still think that isn't always a must. There's an atb system script supporting real active that has just overwritten 7 methods
I think the compatibility problem's due to having to handle tons of special edge cases that are specific to real active, but I still think atb system scripts supporting real active can also have excellent compatibility
P.S.: Making a compatibility fix for an atb system script can help a lot
You don't have to redraw the bitmap within a sprite to change the width/height of a sprite based bar.
You can try to use the zoom method Raizen used, or you can simply modify the src_rect directly. Both works, but I like the latter more, because I can make any shaped bars like that (filling swords, hearts, orbs, etc). Doing that with the zoom method will end up in distorted images, at least it seems so from what I saw so far.
My map and battle HUD is made like that, the map HUD looks like Diablo 1's HP and MP "bar", big spheres filling up instead of regular and boring bars, and the battle HUD uses some unusual shapes for bars.
But this went a bit off-topic, sorry! o.o
The important thing is that Raizen's ATB works like a charm, which saved me from the head-ache of troubleshooting countless errors with the other ATB scripts, so I am happy!
Thanks for the script Raizen!
Extra thanks for the customizable ATB and escape bar filling rates!
1. An actor can only input 1 action regardless of that actor's Action Times+. Maybe that's intended though
2. When an actor(but not all actors) has Special Flag Auto Battle, I can still input actions for that actor, and that inputted action will still be executed. Sometimes, after executing that inputted action, another action(which isn't inputted, so it comes from Auto Battle) will also be executed.
I've read the codes and found these:
def call_update_atb_bar return if (!@actor_atb_array.empty? && !Input.press?(Akea_Active_Battle::Flee_Input)) || BattleManager.has_action? $game_troop.alive_members.each{|member| member.atb = increment_atb(member) if member.atb >= 1000 @enemy_atb_array = $game_troop.members.index(member) BattleManager.add_enemy_order(@enemy_atb_array) Akea_Active_Battle.atb_formula(member) BattleManager.input_start turn_start return end } return unless @actor_atb_array.empty? $game_party.alive_members.each{|member| member.atb = increment_atb(member) if member.atb >= 1000 @actor_atb_array << $game_party.members.index(member) @status_window.refresh_atb start_party_command_selection return end } @status_window.refresh_atb end
Code:
def start_party_command_selection refresh_status @status_window.unselect @status_window.open if @actor_atb_array.empty? return end if BattleManager.input_start next_command else @party_command_window.deactivate turn_start end end
Code:
def next_command if BattleManager.actor if Input.press?(Akea_Active_Battle::Flee_Input) akea_atb_next_command return end @actor_atb_array.shift BattleManager.add_actor_order end BattleManager.make_actor_index(@actor_atb_array.first) unless @actor_atb_array.empty? akea_atb_next_command end
Code:
def self.make_actor_index(index) @actor_index = index end
Code:
def self.next_command return true end
Code:
def start_actor_command_selection return turn_start if BattleManager.has_action? akea_atb_start_actor_command_selection end
When an actor with Special Flag Auto Battle has reached max atb without any battler executing actions, start_party_command_selection will be called.
next_command will then be called as there's at least 1 party member having inputable? to return true, causing BattleManager.input_start to return true.
start_actor_command_selection will then be called as BattleManager.next_command always return true, causing akea_atb_start_actor_command_selection to be called as BattleManager.has_action? returns false.
BattleManager.make_actor_index(@actor_atb_array.first) sets BattleManager.actor.index as that actor(with Special Flag Auto Battle)'s index, causing that actor to be selected.
If the 2nd issue isn't intended, then the below fix might work:
def start_actor_command_selection ## ADDED TO PUSH ACTABLE BUT UNINPUTABLE ACTOR INTO THE ACTOR ORDER DIRECTLY if (actor = BattleManager.actor) && actor.atb >= 1000 && !actor.inputable? BattleManager.add_actor_order @actor_atb_array.shift # @actor_atb_array.delete(actor.index) also works end ## return turn_start if BattleManager.has_action? akea_atb_start_actor_command_selection end
I've briefly tested and so far nothing goes wrong. The Action Times+ also applies to actors with Special Flag Auto Battle(don't know if it's desirable or not) using this fix.
Edit: Scrap the above fix for the 2nd issue, as when all actors have Special Flag Auto Battle, none of them can act at all. I've improved that fix to this one:
def call_update_atb_bar return if (!@actor_atb_array.empty? && !Input.press?(Akea_Active_Battle::Flee_Input)) || BattleManager.has_action? $game_troop.alive_members.each{|member| member.atb = increment_atb(member) if member.atb >= 1000 @enemy_atb_array = $game_troop.members.index(member) BattleManager.add_enemy_order(@enemy_atb_array) Akea_Active_Battle.atb_formula(member) BattleManager.input_start turn_start return end } return unless @actor_atb_array.empty? $game_party.alive_members.each{|member| member.atb = increment_atb(member) if member.atb >= 1000 ## ADDED TO EXECUTE ACTIONS OF ACTABLE BUT UNINPUTABLE ACTORS DIRECTLY unless member.inputable? BattleManager.make_actor_index(member.index) BattleManager.add_actor_order BattleManager.input_start return turn_start end ## @actor_atb_array << $game_party.members.index(member) @status_window.refresh_atb start_party_command_selection return end } @status_window.refresh_atb end
I've tested and it works even when all actors have Special Flag Auto Battle. The only possible issue is sometimes the Action Times+ also applies to actors with Special Flag Auto Battle(don't know if it's desirable or not) using this fix, while sometimes that's not the case.
The problem with most atb in my opinion are the WAYS they are make...like it's almost like you need to overwrite everything'S when you can just define it in a new ways who make the system compatible :/
I was lucky on this shot with tankentai a script who everyone say : aWWWW tankentai suck he bugs with all the atbs and blabla
bullsh*t in my opinion. (tankentai will be the highlest compatible system you will have with your scripts xD (the ace version!)
I love your atb because you not using the battleManager module for create your system! you use the default turn_start ...and turn_end who make tankentai works like a charm with your system!
I have to admit your script is a jewel comparred to some scrapped ATB I saw on the internet...atb who are bad designed or just simply not worth the shot to make change for your system !
I knew something was off with the ATB bars (the sprited ones) and it turns out I was right! >.>
So, you have put them into the initialization of the Window_BattleStatus class. But several other classes inherit from that class (well, only one by default, more with Yanfly's Battle Engine), and all of these other classes will make an ATB bar of their own, effectively duplicating them. This is a serious performance issue, even if you update only one pack of them.
I didn't clearly see this before, because I used static X and Y positions, but realized that that will not work with my battle HUD, so now I tied the X and Y positions of the bars to the item_rect's X an Y position, and since the different windows got different positions for me, I could see the duplicates clearly.
This explained the fact that the ATB bars never actually started from 0 width visually, the duplicates were staying at their original starting position, and they were never updated, so they stayed like that forever, hiding any ATB bar state lower than the starting ATB amount.
Anyway, I moved the sprite creation into the scene itself, so no more duplicates, changed the methods in the status window to account for the change, and now it works without an issue.
You should do the same to fix this issue, it is quite a big bug after-all.
Found another interesting stuff: The turn_end triggers when an battler has executed an action, and the next 1-2 frames has no battlers executing an action, causing it to sometimes be triggered every infrequently(when all battlers have almost the same and/or extremely high agi) or frequently(when 1 battler has much, much higher agi than all the others), leading possibly erratic update_state_turns and battle event behaviors.
I've traced the code and found these:
def call_update_atb_bar return if (!@actor_atb_array.empty? && !Input.press?(Akea_Active_Battle::Flee_Input)) || BattleManager.has_action? $game_troop.alive_members.each{|member| member.atb = increment_atb(member) if member.atb >= 1000 @enemy_atb_array = $game_troop.members.index(member) BattleManager.add_enemy_order(@enemy_atb_array) Akea_Active_Battle.atb_formula(member) BattleManager.input_start turn_start return end } return unless @actor_atb_array.empty? $game_party.alive_members.each{|member| member.atb = increment_atb(member) if member.atb >= 1000 @actor_atb_array << $game_party.members.index(member) @status_window.refresh_atb start_party_command_selection return end } @status_window.refresh_atb end
Code:
def start_party_command_selection unless scene_changing? refresh_status @status_window.unselect @status_window.open if BattleManager.input_start @actor_command_window.close @party_command_window.setup else @party_command_window.deactivate turn_start end end end
Code:
def start_actor_command_selection return turn_start if BattleManager.has_action? akea_atb_start_actor_command_selection end
def self.turn_start @phase = :turn clear_actor $game_troop.increase_turn make_action_orders end
Code:
def update super if BattleManager.in_turn? process_event process_action end BattleManager.judge_win_loss end
Code:
def process_action return if scene_changing? if !@subject || !@subject.current_action @subject = BattleManager.next_subject end return turn_end unless @subject if @subject.current_action @subject.current_action.prepare if @subject.current_action.valid? @status_window.open execute_action end @subject.remove_current_action end process_action_end unless @subject.current_action end
Code:
def self.next_subject loop do battler = @action_battlers.shift return nil unless battler next unless battler.index && battler.alive? return battler end end
Code:
def turn_end if !@actor_atb_array.empty? && $game_party.members[@actor_atb_array.first].dead? @actor_atb_array.shift @back_flee_atb.opacity = 0 @bar_flee_atb.opacity = 0 @start_flee = true end akea_atb_turn_end end
Code:
def turn_end all_battle_members.each do |battler| battler.on_turn_end refresh_status @log_window.display_auto_affected_status(battler) @log_window.wait_and_clear end BattleManager.turn_end process_event start_party_command_selection end
Code:
def on_turn_end @result.clear regenerate_all update_state_turns update_buff_turns remove_states_auto(2) end
Right before a battler executes actions, turn_start will always be called, setting @phase as :turn, thus causing BattleManager.in_turn? to return true.
When process_action is called, it'll execute actions of @subject if @action_battlers has an alive battler, or call turn_end otherwise.
@action_battlers will have an alive battler right before that battler executes actions, and it'll have nothing right after so.
After a battler has executed actions, the battle will proceed to the next frame.
process_action will still be called unless another or the same battler can act, causing turn_end to be called as now @action_battlers contains nothing, causing BattleManager.next_subject to return nil.
When on_turn_end is called, update_state_turns and update_buff_turns are also called, causing possibly erratic behavior on state and/or buff/debuff turns.(It also causes battle events triggered on turn/turn end to have possibly erratic behavior)
If that's not intended, then maybe setting @phase as something new(like :turn_exec) right after executing all actions of @subject, and using a separate counter to count how many frames/executed actions in the same turn triggers the turn end, can help, although it might cause new compatibility issues. I think fixing this one while preserving this script's compatibility won't be easy nor simple(while not minding breaking compatibility will make the fix a cakewalk lol)
For example:
## ADDED TO SET @phase AS SOMETHING NEW def self.set_turn_exec @phase = :turn_exec end ## def start ## ADDED TO INITIALIZE THE TURN COUNT @turn_count = 0 ## akea_initialize_atb_variables akea_initialize_atb_states akea_atb_start end alias :akea_atb_execute_action :execute_action def execute_action akea_atb_execute_action ## ADDED TO INCREASE THE TURN COUNT RIGHT AFTER EXECUTING AN ACTION @turn_count += 1 ## end alias :akea_atb_process_action_end rocess_action_end def process_action_end ## ADDED TO TRIGGER TURN END WHEN THE TURN COUNT REACHES IT MAX @turn_count >= MAX_TURN_COUNT ? turn_end : BattleManager.set_turn_exec ## akea_atb_process_action_end end def turn_end ## ADDED TO RESET THE TURN COUNT AT THE NEXT TURN @turn_count = 0 ## if !@actor_atb_array.empty? && $game_party.members[@actor_atb_array.first].dead? @actor_atb_array.shift @back_flee_atb.opacity = 0 @bar_flee_atb.opacity = 0 @start_flee = true end akea_atb_turn_end end
The problem with most atb in my opinion are the WAYS they are make...like it's almost like you need to overwrite everything'S when you can just define it in a new ways who make the system compatible :/
I was lucky on this shot with tankentai a script who everyone say : aWWWW tankentai suck he bugs with all the atbs and blabla
bullsh*t in my opinion. (tankentai will be the highlest compatible system you will have with your scripts xD (the ace version!)
I love your atb because you not using the battleManager module for create your system! you use the default turn_start ...and turn_end who make tankentai works like a charm with your system!
I have to admit your script is a jewel comparred to some scrapped ATB I saw on the internet...atb who are bad designed or just simply not worth the shot to make change for your system !
Yes, after reading this script several times more, I realized Raizen tried to put as many codes(even quite some battler logic) into Scene_Battle as possible. Among all atb system script I know so far, that's an extreme(but it also works like a charm in some cases). If Sixth's suggestions on drawing ATB bars are used(putting their sprites in Scene_Battle directly), this script will use Scene_Battle even more heavily(again, it can be both good and bad, depending on actual situations)
The other extreme is like what you said - Putting tons of codes into BattleManager, even those that are clearly not BattleManager logic.
There are also atb system scripts trying to put as many BattleManager logic into BattleManager, as many Game_Battler logic into Game_Battler, and as many Scene_Battle logic into Scene_Battle. Those scripts clearly define what each of those classes do, and those definitions mostly conform to the default ones. Some even tried to implement some design patterns, such as MVC.
There is no such thing as "heavily using a class".
All codes executed in the battle are initiated in the Scene_Battle class. If it is not there, it won't be executed.
All method calls are done in Scene_Battle, regardless if the method is in another class or module, so it doesn't really matter where you put your new methods in.
What does matter is the number of aliases and even more, the number of overwrites you do, nothing else, aside from your update conditions.
All I did was move the initialization of the bars into a new method rather than using the Window_BattleStatus's initialization method, to prevent the mentioned sprite duplication issue.
The new method is still in the window class (but it can be moved into Scene_Battle, it doesn't really matter where it is, as long as it is NOT where it was by default), but it won't be initialized with the other classes which inherit from Window_BattleStatus.
Than, seeing as the 'start' method in Scene_Battle is already aliased, it was a one line code to put the initialization of the ATB bars there using the new method created in the window class.
As a matter of fact, this eliminates an alias method and creates a new method instead of that, so this will surely be more compatible with other scripts (not that many scripts would overwrite the initialization of Window_BattleStatus, but still, the less alias, the better).
One could create a whole new battle scene putting all the battle logic into the scene itself, rather than using the BattleManager module, and it would still be fine, providing the creator did everything right. There are plenty of examples for this, doing complicated mini-games by putting everything into the scene itself (such as Galv's minigames, which are not direct battle scripts, but they are just as complex if not more than those).
Bottom line:
As long as you do your job right, it doesn't matter where you put your methods.
In this script, right before executing battler's actions, turn_start will be called, casuing the turn count to be increased. This effectively means each turn can contain at most 1 battler action executions(1 battler might execute many actions).
Also, as mentioned before, the turn_end behavior can be erratic(sometimes called frequently, sometimes called rarely), it won't be always in sync with turn_start. Normally, after calling turn_start, turn_end will be called before calling turn_start again, and turn_start will be called before calling turn_end again. In this script, that assumption can be broken in some cases.
I tried that Auto Battle fix, but it doesn't quite work how it should, I guess.
Whenever all my actors get auto battle state, the ATB bars refresh like 100 times slower, and the last actor who executed an action will repeatedly start to make invisible actions, seemingly the same one as the last action.
I inserted many print lines to the console for many of my other battle scripts, so I can see what happens when, and indeed I see that an invisible action is constantly making a Game_Action and doing damage to some imaginary target...
No idea why this happens, but this is what slows down the ATB bars, like the bars stop for executing this invisible action, and resume after, but there is only 1-2 frames between each invisible action, so it is kinda unplayable like that.
This might be another compatibility error with either Theo's battle system or Yanfly's battle engine.
I tried that Auto Battle fix, but it doesn't quite work how it should, I guess.
Whenever all my actors get auto battle state, the ATB bars refresh like 100 times slower, and the last actor who executed an action will repeatedly start to make invisible actions, seemingly the same one as the last action.
I inserted many print lines to the console for many of my other battle scripts, so I can see what happens when, and indeed I see that an invisible action is constantly making a Game_Action and doing damage to some imaginary target...
No idea why this happens, but this is what slows down the ATB bars, like the bars stop for executing this invisible action, and resume after, but there is only 1-2 frames between each invisible action, so it is kinda unplayable like that.
This might be another compatibility error with either Theo's battle system or Yanfly's battle engine.
I haven't tested the fix with any other script except this one, so I think it's better to ensure it works on this script first, and see what Raizen thinks about that
Cartoonier cloud cover that better fits the art style, as well as (slightly) improved blending/fading... fading clouds when there are larger patterns is still somewhat abrupt for some reason.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
)
