Ladies and Gentlemen, allow me to give the battlesystem a new
to version 7.0!!!
First and foremost, I had an issue with the system requiring me to include an F12 Crash Prevention script. Until now, I have been using one by Zeriab because MrMo's ABS Ultimate suffered from the dreaded F12 bug. However, that issue has been fixed so while the demo still includes Zeriab's "Stop F12 from Resetting" script, it is an unnecessary addition and can be removed if so desired. Just consider it as a bonus script.
I cleaned up and compressed a few fair-sized chunks of code in the Spriteset_Map class handling the drawing, updating and disposal of all the sprite types as much was similiar or repetitive. A simple method that had the arrays and values passed into it was all that was needed to cover the variety involved. I later covered other sections in a similar manner.
Later, I retooled the player death system so you have three types of dead companion types to use... totally gone, semi-transparent corpses that stay on the map, or fully solid ones that remain put. While you cannot easily revive the fully removed companions, you will find it MUCH easier to use a curative to bring the other two varieties back from the great beyond. You even have the ability to have 'dead' companions available on the minimap script that comes with the demo.
Some battlesystems in the community perform rewrites of various classes, even default classes such as the RPG::Sprite class that contains the damage pop system. MrMo's ABS since it began back in 2006 likewise modified the damage pops, making it relatively incompatible with these other battlesystems. While it may be rare to find a game that contains two different battlesystems, I have been aware that a couple exist. To aid in making this system compatible with other battlesystems, I added my own set of damage pops into the RPG module rather than using and modifying the original. Not only did I handle the traditional pop, but included damage pops for SP damage that occur in MrMo's ABS and a bonus SP pop for the default system if you so desire. I even set the damage control system in the Visual Code section to be its own routine so it shortened material added to the update method in Sprite_Character. The SP Damage system in MrMo's ABS Ultimate also affects the default system, so you would not need to include my SP Damage script. I will not say that it will make MrMo's ABS Ultimate fully compatible with all other battlesystems, but it will aid game developers in achieving that goal. Additional scripting or patches may be necessary towards that for your custom systems.
For some time, you could only set up enemies that move randomly or stayed in place until their 'target' became visible. These on-screen enemies only performed and behaved based on the comments added into their 'Event Command' window as has been the way since Near Fantastica's original ABS from 2005. While that is still possible, you can now have more control over your enemies and set up a programmable routine for them by using a custom move route. New commands such as $ABS.force_enemy_attack now lets you instruct an enemy to perform a melee attack or fire off a spell in the direction they are facing, whether a viable target is in front of them or not. Likewise, you can retrieve their HP scores, reduce their SP and even make them defend themselves based off what you enter into their custom move route. While this optional addition is not a perfect manner to give exacting control over enemies, it may prove handy. Additional work may come later.
For some time, I said that I would not include jumping in the ABS, but alas I have added it. Before you ask.... NO! You cannot jump over arrows being shot at you or fireball spells. Who are you? Neo? This isn't the Matrix! ^_^ But you can jump over obstacles such as logs, rocks, even over enemies. And if you are moving, your jump can go further... moreso if you are doing a running jump thanks to the dash system. Given the strain from a Jump, you can set the system to drain the Dash system when you make a jump and prevent you from jumping if the bar is already drained. I had to create a system to ensure you couldn't just jump across a cliff edge though. Passages wasn't working out, so I decided to use tiles with counter tags as a block of sorts.
If you like that, you'll love the follow-up. Jumping attacks are now possible with melee weapons. This involved a slight rewrite to the MELEE_CUSTOM arrays, adding in a Jump value. Now, you can set up certain weapons that let you apply bonus damage to your target if you're delivering a strike from a jumping attack. This can be tricky as your actor must be swinging his weapon at the tail-end of a jump, especially if there is a delay set up from when the player hits the attack button and the actual downward 'strike' being delivered by the game_player actor. But the system is adjustable so you can set up how much time (in frames) the player has to deliver the actual strike. It won't count if the strike occurs after the jump is completed.
I guess people who used my Multiple Pose addon for MrMo's ABS Ultimate haven't noticed a glitch if you wanted full 8 directional combat but only used 4-directional sprites. Yes, there was a glitch. While you could move in all 8 directions, you could not fire missiles or attack in all 8 directions as the combat system derived the direction from the attack from the facing direction of the characters. MrMo's ABS Ultimate had that solved, but I neglected to insert routines into the addon to accommodate this until now.
As a sideline, I removed the damage pop control from Sprite_Character's update method in both the Multiple Pose and Paperdoll scripts. As I said earlier, I moved all that into its own method, so the two scripts are now more conveniently shorter. Any changes to the damage pops shouldn't require these being edited any further.
Blam! Blam! Blam! Rat-a-tat-a-tat! Does anyone want an Uzi 9mm in their game? Yes, you can now set up your game so a ranged weapon can be a fully automatic rifle. Of course, it required a reshaping of the RANGE_WEAPONS array. But big whoop! I had to make sure a few things though. Mainly that you only needed to press and hold the attack button for the weapon to have continuous fire for just that type of weapon. But I also set it up so the gun only gives a recoil kick for the first round fired, otherwise you'd be flying backwards all the time you have the button pressed. In addition, a new prefix has been added so you can have a custom characterset for automatic weapons. Unfortunately, you have no 'option' to set any custom graphic for each ranged automatic weapon. This means that if Basil fires an uzi and a AK-47, both will use the same automatic rifle characterset. You cannot have different looking graphics between the two.
You could use a single rifle-holding pose when using the MultiplePose and Paperdoll system and have individual spritesheets for your weapons. That's the only workaround.
In order to make the MultiPose system work with various poses that automatically return to the default 'normal' pose, I expanded the list of MrMo Public pose constants. In keeping with that, I also removed the wait constand from the multipose system and added it into the ABS itself. That saves me the grief of needing to change or keep track of what my WAIT value is set.
Has anyone noticed that you could only fire across water, and only if that water has a specific terrain tag applied to it? That's fairly limited. Well, it was. Now, you can set up multiple terrain types as the system now has the PASS_TAGS array. Instead of the original PASS_TAG system, you can have one or more terrain tags applied so more terrain types can let missiles fly by where you normally couldn't walk. It came in handy as missiles leaving the water that had a pass-tag attempted to enter a non-passtag terrain. They were stopped. Because the system now allows for more than one, I set both the water and normal ground (terrain tag 2) to be passable. Lo and behold, the arrow could fly over the eater and continue PAST the shore rather than stoppind dead. I don't know if anyone would actually have more than two terrain types like this, but I felt it best to increase this capability. It sure worked for me.
And I was disappointed with the system that made characters 'jump' when they were hit (or subsequently knocked the players back from the recoil of a gun). It's not that they jumped, but that there was no check system to make sure they didn't cross an impassible barrier, like the edge of a cliff. Oohhh... there could have been so many cheats on the field map if you wanted to cut across a map, simply by shooting a gun and knocking yourself backwards over a border! That had to be fixed, and quick. But I didn't want the characters to simply... not jump. Instead, I set it up so it checked how far they jumped and erased any distances that would be invalid. So you may have a recoil of 3 on a bazooka, but if you can only be knocked back 2 tiles, that's as far as you're going. In some cases, I needed the counter tiles for this too. It's related.
So, here it is. Enjoy.