MasterMind
Member
Is this merge possible? I know the other overdrive script is out, but I need something more along the lines of SephirothSpawn's.
RTAB + SephirothSpawn's Advanced Limit Breaks
- Thread starter MasterMind
- Start date
DerVVulfman
Sponsor
Seph's own limitbreak system is an SDK script. Now while some of his SDK scripts like Equipment Skills are compatible without any edits, his limitbreak script invokes 'defs' only referred to in the SDK system. That, and his Game_Battle defs don't alias anything but overwrite existing ones. Unusual in that he didn't use aliases there. The additions must be in the MIDDLE of the defs.
MasterMind
Member
So basically, what you're telling me is that this merge can never happen because the RTAB was not made for the SDK?
DerVVulfman
Sponsor
Nope. Not at all...
Best bet would be to write a separate 'RTAB/Sephiroth Limit Break' script that combines RTAB'S Game_Battler defs and Seph's Game_Battler defs into it's own def. Then to write a NON-SDK Scene_Battle class with the RTAB defs... with the additions presented by Seph.
It'll just take some time (easier to use RTAB as the model). And be sure and check RTAB's usage of calls that need the " [battler] " phrase that's used by RTAB in things like self.damage[battler] where normal default battle scripts use self.damage.
Best bet would be to write a separate 'RTAB/Sephiroth Limit Break' script that combines RTAB'S Game_Battler defs and Seph's Game_Battler defs into it's own def. Then to write a NON-SDK Scene_Battle class with the RTAB defs... with the additions presented by Seph.
It'll just take some time (easier to use RTAB as the model). And be sure and check RTAB's usage of calls that need the " [battler] " phrase that's used by RTAB in things like self.damage[battler] where normal default battle scripts use self.damage.
MasterMind
Member
I think I can do this. I'll be posting in the RGSS help forum if I need help, because this is no longer a script request. =)
DerVVulfman
Sponsor
A new scripter is born. :D
Just remember that RTAB's system is designed with the additional 'local' value of battler in their defs. This differenciates RTAB's action-timer system with the default system's use of a globally defined @active_battler value. battler had to be defined as a local value so reactions between multiple battlers won't become crossed as the default @active_battler value would have.
Just remember that RTAB's system is designed with the additional 'local' value of battler in their defs. This differenciates RTAB's action-timer system with the default system's use of a globally defined @active_battler value. battler had to be defined as a local value so reactions between multiple battlers won't become crossed as the default @active_battler value would have.