The Lycan ABS

[GwenBlanketKnight]

I am so glad to see that all these years later you are still working on this ABS system.

[JayRay]

That explains why I've been seeing 5 guests with the same Virginia IP address every day. I guess it's not Langley (CIA Headquarters)

And now that I got someone in my apartment building to start doing RPG Maker stuff, you might have someone else from my IP showing up... gotta love that apartment wifi.

[DerVVulfman]

It has been years. But now it is time for a
BUMP
to Version 12.5

First, it was noticed that companions may actually revive when they shouldn't after being slain. Said party members would continue to move about and attack as if nothing had happened and shrugged off being... essentially... dead. And indeed, there were also issues where enemy attacks may not fully register on the companions, said party members not knowing if they were dead or not. These were actually two separate issues, neither hard to track down. Noth just required a line or two of code to fix this issue

Most work on skills were for the benefit of the player. But for enemies and allies alike, it was thought they would use melee combat or ranged attacks instead, and not close-quarters melee skills such as cross-cut or leg sweep. Healing and curative close-quarters spells worked fine, but nothing combative. Herein, there was an issue that was overlooked. Sujabes467 of Save-Point.org noticed that companions lacked the ability to use any skills defined in the BASIC_SKILLS array other than healing. It took some time, but new methods were added to accommodate melee skills defined within the BASIC_SKILLS array.

Meanwhile, a new little two-parameter array has been injected into The Lycan ABS. This simple array turns on or off the enemy-detection systems, so you can craft 'shoes of silence' letting the player only be detected by sight... or a 'cloak of darkness' allowing the player to be heard, but not scene.

Code:

$ABS.player_detectable[0]  = true/false         # Handles audio
$ABS.player_detectable[1]  = true/false         # Handles visual
$ABS.player_detectable     = [false,false]      # Just hides anything

I wouldn't think that this would be TOO difficult to employ.

When one fires a gun, or uses an extremely powerful or mighty a weapon, they may be kicked backwards. This is handled by the KICK argument within the weapon's related control arrays (Weapons, Skills, etc). It was recently considered that heroes or enemies strong enough should not have to worry about such an issue. So a new value was added to the 2nd configuration page: ANTI_RECOIL_STR.

The anti-recoil strength argument indicates how strong an actor or enemy has to be in order to withstand the kick of a gun or like weapon. In its current default setting, characters must have at least 100 strength to avoid the kick. Anything weaker, and they will be knocked backwards.

* * *

On other notes, a minor fix was applied to the Lycan AT Bar script so the system would not crash if an enemy combatant was killed and erased. This almost never occurred, but was possible. So a minor bandage was applied to the bar drawing system.

And the demos had been using MultiSlots! version 3.0 for some time. Now updated, they use MultiSlots! version 3.5. No configuration changes needed between the two.

* * *

On a side note, you can see Jill having clothes equipped in her menu display within the Story 2 Demo just as Bill has his within Story 1. Granted, they aren't actually Jill's...

[DerVVulfman]

[DerVVulfman]

BUMP
to Version 13.1

Did you think I was done?  Wrong.

The close-quarters combat system using the BASIC_SKILLS setup still had issues.  While companions were now able to properly cast and use skills connected to the BASIC_SKILLS setup, the system that delivered the actual skill effect and damage was not working. The skills were still being performed by melee actions.  That was unfortunate, but not too much of a problem that I couldn't fix.

Also related to skills is the issue that companions would be totally unable to attack if they had no usable skills and was ordered to use skills only.  For this, an option was created to let companions forget the command to use skills only and let them deliver melee attacks.  This is configurable of course.

Another issue with companions and their skill use had appeared, and that pertains to skills actively used.  The typical system would attempt to use the first skill it would come across before the next.  And given that the first skills an actor gains has the lowest SP cost, no further skills would even be encountered. That was, to me an issue, and one I had to rectify. So I decided to set up two alternate methods in which the companions may choose which skill to use.  The first I choose to call 'Reverse Database' where the IDs of the player's allowed skills are sorted in reverse order, so essentially the last skill in the Skill database would be chosen first.  And the second option I added is a Scrambled Order system.  In that, the list of skills the companion would use would be re-arranged each time they wished to use a skill, and the choice of skill would indeed be random.

Classic RPGMaker XP does not have a scramble function within the Array class. However a suitable and simple set of methods now exists within the Array class of this package.

In a related issue, I found that the Hotkey and companion control system had issues where some of the commands were not properly responding.  This was an easy fix.

I cleaned up the hate and fear systems, systems that force an enemy combatant to attack a target, or to run in fear of it.  But along with that, I also allow enemies to become afraid of other enemy types.  Wolves may become afraid of bears, Imperial Stormtroopers afraid of vampires, and so on.

And in connection, a new enemy controlling comment has been added.  This new command comment feature allows enemies stop their attack on a chosen target at regular intervals.  The benefit is that the detection system will kick on and let the enemy choose (what is likely) the closest target to face.