The Lycan ABS

[DerVVulfman]

BUMP!
to Version 9.8

Again? Yes... again.

First, let me add that a slight modification was added to the Sprite Code page, particularly the new 'initialize_wrap' (line 53) I added last week. The method originally worked upon Game_Event character graphics for the map wrapping/looping system. However, it neglected other wrapped objects such as companions or treasures. The new additions to that method now include those as well as all traveling ballistic objects.

However, to allow traveling ballistic objects to go beyond the boundaries of a map when the map loops, I had to include a line of code to the 'update_movement_flag_invalid?' method (line 268) in the Game_Ranged_Base class of the Ballistics Code page itself. This allowed the system to stop checking for boundaries when the map looped.

So what does this mean?

YOU CAN NOW SHOOT ACROSS INVISIBLE MAP BOUNDARIES AND HIT YER TARGETS ON LOOPING MAPS!

Now for the rest....

* * *

For the past few weeks, I had been going through the scripts within the ABS system in an effort to break them into smaller modules. This would make attaching code for an add-on script much easier, such as adding code to the player class's update method. The manner in which the player's update method formerly appeared would have forced one to rewrite the entire method to perform a change to the code that handled a confusion or movement state. As it appears now, you can attack a smaller module used within. That was one of the reasons for these changes. Another was that a few methods used the same code. As such, breaking them into smaller components allowed some new methods to be shared and thus reduced some script size.

Well, if it weren't for all the comments I put in place. ^_^


This last venture into breaking the coding into smaller modules targeted the Game Code page, a page which has edits to the default game data handling scripts. Therein, my first target was the Game_Temp class. However, I merely separated the code that defined the wrapped maps from the rest of the initialize method. And the Game_System and Game_Event classes were literally untouched.

For the Game_Battler class, I thoroughly attacked the 'attack_effect', 'effect_skill' and 'effect_item' methods which handled the damage a target suffered when attacked during ABS combat. The routines that handled combo attacks and blue magic/skill learning now exist outside their respective methods. And routines that looked at how effective a skill or item is towards a target were also subdivided. One could now rewrite the method that determines the power or effectiveness of a skill or item merely by changing one of these new methods rather than the whole routine itself.


For thae Game_Actor, both 'can_use_skill?' and 'skill_can_use?' now use the new 'skill_requirement_check?' feature to see if a skill being used requires items stored in the party's grab bag. And the initialize method within the Game_Enemy class has a new 'initialize_enemy_comsume' which simulates the same thing for ABS opponents.

A number of changes were performed to the Game_Party class. Methods were broken off in the systems that kill off or remove actors, but larger changes occurred towards the party cycling method, breaking the system into smaller components. In fact, both 'cycle_forward' and 'cycle_backward' methods have been eliminiated in preference for the new 'cycle_direction' command. This move removed a lot of redundency, though some material handling companion forward/backward cycling couldn't easily be converted into a single method. Meanwhile, additional methods were broken down which handled member checks and refreshing map data.

It erked me, but I had the Game_Map class broken into two parts, one before the Game_Character class code and one part afterwards. SLOPPY on my part. Now both parts are together.

Within the Game_Character class, I broke away some code that affected pose frames and the movement control within the update method itself. I also made a new method that was use to generate new x/y coordinates if the character was going to be involved with looping maps. This new method was much shorter and did the work of several lines of code within the 'move_abs_object' and 'move_object_xy' methods. I broke away some code that handled automated attacking from the move_to_player method. But my biggest change was to the 'passable?' method itself, now having four new methods it calls to check on impassable events, treasure drops, companions and player objects.

Of the classes changed, the largest changes were within the Game_Player class, breaking the massive update method into even smaller chunks, setting up systems that memorized real positions, reset jump data, and handled encounter steps. For naming convention sake, the 'update_pixel_timer' method was renamed to 'update_player_movement_confuse_timer'. And lastly, the event trigger system near the bottom of the script was divided into smaller methods that checked event and companion dialog triggering.

* * *

Oh, and I changed Frank's Multipose one more time to account for the change in the party cycle system. Buhbye cycle forward/backward. Hello cycle_direction.

And that's all for now!

I'm beat...