Advanced: Hardcoding
Section 4.C.4
There is one final way of entering a midbattle script, which is to simply hardcode the entirety of the script itself, rather than relying on a hash. The advantage of using this method is that you are totally unrestricted in what you're able to do, as long as you have the know-how to code it. The downside is that this requires more technical grasp of Essentials and Ruby in general, and a lot of things that are simply configured automatically when entering data into a hash must now be set up manually. Because of this, setting up scripts in this manner should be reserved for more advanced users who are already somewhat competent at coding, so I'm not going to go into extensive detail here since I can assume these users can figure it out mostly by looking at examples.
To hardcode a midbattle script, you have to use the MidbattleHandlers module to set up your own midbattle handler. To do so, open the Deluxe Battle Kit plugin scripts, create a new text file and name it whatever you want. In here, you may include all of your custom handlers. Here's an example of what one of these may look like:
MidbattleHandlers.add(:midbattle_scripts, :midbattle_example_script,
proc { |battle, idxBattler, idxTarget, trigger|
scene = battle.scene
case trigger
when "RoundStartCommand_1_foe"
scene.pbStartSpeech(1)
battle.pbDisplayPaused(_INTL("You're not gonna beat me this time!"))
when "BattleEndLose"
scene.pbStartSpeech(1)
battle.pbDisplayPaused(_INTL("See? I told you!"))
when "BattleEndWin"
scene.pbStartSpeech(1)
battle.pbDisplayPaused(_INTL("No! Impossible!"))
end
}
)I'll provide a quick breakdown of the arguments used in these handlers.
Handler type This identifies whether this handler is a trigger handler, or a script handler. For your purposes, this argument should be
:midbattle_scripts, as you are using this handler to hardcode an entire script, not a specific trigger. However, if you're designing a global midbattle script, you'd want to use:midbattle_globalinstead (more on this in the "Advanced: Global Scripts" section).Script ID This is the specific ID that should be used to identify this script handler. This is what is used to actually call upon this script when entered in the "midbattleScript" Battle Rule in an event. In the above example, I used the id
:midbattle_example_script, but this can be whatever symbol you want. This should be a unique symbol not shared by any other midbattle script handler. This is what you actually enter in the battle rule to call this script. As a rule of thumb, I suggest that these ID's are always in lower case, so that you don't risk confusing them with constants entered in theMidbattleScriptsmodule outlined in the previous subsection.Proc This is where you'll actually code the battle script you want. This proc will always contain the following arguments:
The battle class. You can use this to access pretty much anything you want related to the battle.
Once your handler is set up, you may then set this script by calling it with the the "midbattleScript" Battle Rule in an event, like so:
setBattleRule("midbattleScript", :midbattle_example_script)Coding a Midbattle Handler
How I suggest setting up these handlers is by using case trigger, followed by a series of when X statements for each specific Trigger Key that you want to check for where you want something to happen. Then you can simply code whatever it is you want to happen for each Trigger Key. Though, there may be situations where there's a more efficient way to set this up. If you want more intricate examples of midbattle scripts that utilize midbattle handlers, check the plugin file [002] Midbattle Scripting/[004] MidbattleHandlers Scripts.
Something to note is that any variations of the "_repeat" or "_random" Trigger Key extensions have no use when hardcoding midbattle scripts. When coding scripts in this way, each key is automatically assumed to always trigger and always repeat indefinitely. So if you want something to only trigger once, or to only occur at a random, you have to specifically code it to do so.
While I'm at it, here's a list of methods and/or properties that you might want to reference when hardcoding your scripts to help with this as well as other scenarios, since this plugin adds a lot of new custom content which you may need to call on to make certain things happen:
Last updated
Was this helpful?