The Lycan ABS

[DerVVulfman]

BUMP!
to Version 8.9

Okay.... how often can I make these updates? Mwahahaha!!!!

First, I have to apologize as an error cropped up within the 'update_enemy_respawn' method in the 2nd page of the ABS Engine. I accidentally made events reappear on coordinates X/X rather than X/Y. Um... my bad? I fixed by using respawn_coord[0]&[1] rather than [0]&[0]. Granted, it could confuse players a lot when it comes to where they respawn, but that wasn't the intent. And another error cropped up within the 'update_enemy_respawn_enemy_delay' method. Dang missing question marks! So a very simple fix to turn a nil into a nil? was performed.

You can do these fixes on lines 267 and 277 respectively within the 3b page, or just replace the whole 3b page. Hey, that's all there is with the ABS engine being fixed.


Now for my latest endeavors in breaking the Sprite Code page into smaller and more manageable pieces.

Methods rewritten... ugh.... I forgot that I had to replace the 'update' method within the Sprite_Character class, but what could I do? The whole method was one long sucker and what I needed to insert was in the middle. Well, if anyone needs to add something new to the method, I have just broken it down into very tiny chunks, and I mean total slice and dice.

Interesting enough, I didn't have to pass variables between these new methods, so the designers of the default system must have been slipping. I made methods that checked for character refresh, separate methods that drew tiles or sprites, drew the proper animation frame, set the character's appearance and etc... all as individual modules. As of now, this should make it easier to add new code.

I didn't even TOUCH the Sprite_Duplicate class, though I could. I mean it was partially based on the Sprite_Character class, so it wouldn't take much (if any) effort.

But I did perform a very modest bit of cleanup on the Sprite_Battler class.

The Sprite_Mouse methods I added to my own 'Mousie' system was fun. I branched off individual methods that deal with the drawing/replaceing of the mouse cursor if the mouse is over any event, and I extracted some code that hendled the autobattle feature, making the mouse_pressed method appear more clean.

Then I went and targeted the Spriteset_Map, taking out small chunks from the initialize and update methods I previously aliased.
And I went after my Spriteset_Minimap addition that lets it use MiniMap DVV. Besides shortening the 'create_mmap_lycan_additions' method, I divided the 'create_events_list' method into smaller components that handle companion display.

* * *

Oh, and since I went after the Sprite_Character class, I decided to look at both Frank's MultiPose Charactersets and The Lycan ABS Paperdoll System, and guess what? These two systems that rewrote the update method in the Sprite_Character class had quite a bit cut out!

For Frank, I merely rewrote the 'update_sprite_character' and 'update_character_frame' methods from my new Sprite_Character class code while keeping the new update_direction_8 method. And for the paperdoll system, I used a new 'update_refresh_character' method and a totally different 'update_sprite_character' method with the script's collection of equipment changing code.

This shortened both add-ons quite a bit.

[Ahzoh]

I tried the demo of your system, but it says it's from an old version of rmxp...

Nevermind, I simply copied everything into a new version of RMXP proj

[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...

[DerVVulfman]

To my surprise, it is time for another...

LYCAN BUMP!
To Version 9.9

A minor glitch occurred and was missed which involved the player healing from an automated 'revive item'. This occurred in the 3rd Part of the Lycan Engine itself, the Player's page. Obviously found, fixed and re-uploaded.

[DerVVulfman]

Ladies and Gentleman, I now present you with a new

BUMP!
to Version 10.2

First off, let me now introduce you to a new name in the credits: Ahzoh. Just recently, he discovered a no-method error involving enemies. This error was due to a counter that was left out of the game class that handled ABS enemies. As such, this was an easy fix.

Then, I took a look at the ability to turn the ABS system on and off. It prevented the enemies from attacking, but not the player. As such,
I included a little bit of code to block that. And since it would be a pain to monitor the actual active switch all the time (I don't wanna make lag), I made a new script call.... actually two script calls... that can halt an enemy on the map, even if it is currently hunting the player.

So there were actually three things actually added to the Lycan ABS system. But I didn't stop there.

I wasn't fully satisfied with Frank's MultiPose Characterset system within the Paperdoll demo. It seemed to make things speed up OR slow down for the player character, so I did a little reworking. A call to an 'update_animation' method in the Lycan Database was removed and 'update_animation' and 'update_anime' methods were removed from Frank. And an 'update_animation_frame' was trimmed down to fix the actual character speed and frame rate.

But now for something completely.... different.

Within the demos, there is a new little script.... The Lycan Checker.

This script is a simple system that examines your project's database and compares it to the configured values in The Lycan ABS. If you configured a selection of weapons and happened to delete one from your database, it will inform you that you are missing a weapon from the database. If you made a skill that used up items (CONSUMABLE_SKILLS) and are missing an item in your database, it will inform you of that too!

The system will deliver you the information via pop-up or by a text file in your project's root folder.

Enjoy!

[JayRay]

I gotta say, really liking this version. Works seemlessly with what I have, even though it DOES add a little lag. But, then again, what doesn't?

[DerVVulfman]

That's only if you're adding everything and not using the built-in antilag (which I didn't turn on).... AND you can turn off some delay option features in the actions too. One could reduce the value of the mash delays and action delays to make reactions faster.

[JayRay]

built in anti-lag was turned off? *facepalm* - So guess what I get to update as soon as I get home? LOL

[Davesss]

Hi,

I'm new on this forums. Yesterday I found this awesome Action Battle System and it looked really awesome!

Anyway, I got some problems when I'm trying to start the game.

It gives first 2 alerts:

While an element is available in the System Database, no name for the SP_DAMAGE_TAG was defined.

While an element is available in the System Database, no name for the SP_CANCEL_HP_TAG was defined.

Then when I come on the menu and click on new game. It gives this error:

Script'* The Lycan ABS Hud' line 392: NoMethodError occurred.

Undefined method 'hp' for nil:NilClass


I hope someone can help me. :)

[DerVVulfman]

Your first part is the 'No names' are available messages. While this is a helpful message, it merely means that you never created actual names for the elements.

You have names for the default elements, like element 1 being fire, or element 2 being water. But this is merely saying that you have 'no' names entered for either of your SP handling elements. This is not a detrimental error crashing bug. But it is a warning for game designers.

When you're done with the Lycan Checker, you can just remove it from the demo, or merely set the CHECKER_ON value to false.

---

Now your other issue, that's unusual. When the game starts, you start with a party of 1 or more members. The Lycan Hud works by reading the lead party member and doublechecks his/her stats. The only explanation that I have is that you are starting the game with no party members.

A solution would be to create a 'dummy' player character... an actor with no name, no characterset, no kidding. THEN, if you are using some character select screen... use THAT guy. But you need an actual character on startup, even if you do not show the hud when your game starts.