What's up, RMers?

[DerVVulfman]

WORK HAS NOW BEEN REKINDLED UPON THE LYCAN ABS!

There have been a number of things that have been looked at, first being its compatability with the RMXP SDK version 2.4. It appears that its revised Sprite class created a method which didn't exist within the default Sprite class. And my Lycan ABS created s method within Sprite_Character with the same name. This resulted in an error, which was easily fixed just by changing the name of my method.

As simple as I made the 'main' processing method of the Lycan ABS's HUD script, it appears that some custom Map scripts had issue detecting whether it was disposed or not. So a minor fix was put into place.

The Paperdoll system... ah, yes... the Paperdoll system.... Not everyone uses multiple poses with their ABS, opting to use a simple 4-by-4 characterset, but still want the whole Paperdoll option. Initially, the paperdoll script required Frank's MultiPose script. But now, with some additions and modifications, it doesn't. The paperdoll script, in fact, checks for the actual existence of the Multipose's config module and the values within. And if it doesn't find any, it falls back upon tried and true default values.

Oh, DerVV... DerVV... DerVV... You found a bug in the ABS after all this time. And it was a feature you created years before! Ah, years ago, I worked with MrMo's ABS to create the 'ABS Ultimate' package. This was a package that included many features in the Lycan ABS, including treasure drops. Up until that point, MrMo's ABS didn't have them. But my work upon his system fixed that. However, when I recreated by option for treasure drops, I neglected to properly set up how items left behind were to be dropped upon the screen if the items were (a) grouped together and (b) not to be scavanged from a corpse to loot. It was something overtly simple... doh!

NOW to describe the FUN NEW ADDITIONS!

DIAGONAL ACTIONS has been redone and with a major change. If the system is set to normal four-directional actions, the player and the enemies can only use normal cartesian movement. And with that, they can only attack straight ahead and in only the four directions permitted. Up until this point, the option for Diagonal Actions only permitted the player and enemies to move in eight directions and performed a sort-of- sweep melee attack in front of themselves. The only caveat is that a player, if armed with a keyboard script that permitted 8-directions, can fire missiles in all eight directions while the enemies only four. This is no longer the case.

The new option with DIAGONAL ACTIONS now permits eight directional movement for all parties, sweeping attacks, and eight directional missile fire... even for the enemies!!! Let me tell you, I died a good number of times in Crag Canyon with those damned bushwhackers around there. Oh, I can alter things by setting individual delays in action after they CHOOSE to fire... sort of like setting which one is a faster draw of the gun. But now, things have gotten cranked up in the missile combat.

STRAFE! STRAFE! STRAFE! STRAFE! STRAFE!

Yes, you can now STRAFE with Lycan! Currently, I set the STAFE key to the SHIFT key, and my character stays locked facing one direction while it moves side to side! AND I can fire while strafing too! No more do you have to just move forward and turn to fire at a target... unless someone takes strafing out of their game.

Don't worry about having the gun kick you backwards into a wall. The same KICK system doublechecks to make sure you don't go "INTO" a wall or out the other side. Well, just as long as you don't set the STRAFE key to 'Ctrl' and are playing in Debug mode. Hehehe.. after all, debug mode lets you walk THROUGH walls. That kinda messes it up.


So do I have any more plans for the Lycan ABS? Certainly!!!

The Lycan ABS does simulate various status effects that can be applied to both the player and the enemies. However, some of the status effects have had little effect upon enemies, those dealing with enemy vision or hearing. Granted, a 'hearing' ailment has little effect for the player, so that is not likely to effect enemies. However, a feature that dims/hampers the player's screen should also affect enemy's 'Vision' options. Yeah, the BLIND_EFFECT slows enemies doewn, but doesn't affect their vision.

HASTE and SLOW... ah, fun ones in a sideview battlesystem with AT bars... so to should these be added for the ABS. In the ABS, you have a delay option called the MASH TIME. This gauges how often the player or enemy can perform an action. If I make the system HASTE this mash time, the delay should be shortened so attacks can be made more rapidly. And if SLOWED, the reverse! Optionally, a feature of similar nature should be set up for actual after-choice delays. I did mention the cowboy with the quick-draw, right?

So... any thoughts? ^_^