The Lycan ABS

[DrHouse93]

Thanks, DVV, these are all good news!^^
You're right, I didn't know about the CTRL feature to cross impassable tiles. I guess I will have to make my game encrypted for the final/demo release.
Concerning the "bridge companions", actually I explained that bad xD: what I meant is that when companions are cornered and can't move, you can walk on their tile and stand still there, as if they're intangible and have no consistency (which is fine for ghosts, indeed, but it's a little weird for concrete beings xD)
Other than that, congrats again. Keep up your good work^^

[DerVVulfman]

Ah, well intangible 'dead' companions make more sense when you consider that a dead companion could be blocking your way out of a map. If it occurred within a tight corridor and you have no way out and no way to bring them back to life, it's basically game over. And besides, I think an adventurer could step over the corpse.

[DrHouse93]

Yes, but that applies even to alive companions xD

[DerVVulfman]

Be that as it may, it is time to do the BUMP!!!

THE LYCAN
ABS
Version 11.3

And with that, the names of Davesss, DrHouse93 and flynnmichael81 are now part of the credits...

A good number of changes were made.  Wanna know what they are???

1. A repair was made fairly quickly which allows 8-directional missile fire when not using Frank's MultiPose Charactersets for the Lycan ABS*.  While unnecessary with Frank, it was necessary to adapt the system to let missiles move in diagonal motion.
   
2. Revised handling of companion move rates, making them and their status ailments separate from that of the lead party member's.  The only thing shared between the player and companions is if the player is either dashing or sneaking.  Move rates are adjusted accordingly. **
   
3. Addition of enemy move rates based upon map-based status ailments.  These were completely missing prior to this version. **
   
4. Creation of Slowed/Hasted move rate values for enemies (related to enemy status ailment handling above).
   
5. Inclusion of Mute/Confuse/Paralysis/Delay effects upon companions and enemies which prevents the use of skills and items as they affect the player. **
   
6. Altered the Dash and Sneak code into smaller modules, some code now placed within separate Player and Companion pages of the Game_ABS engine.  Code is now smaller and more accurate.
   
7. Creation of subroutine in ABS refresh system which re-loads and creates on-map enemies.  The subroutine reduces line content by approximately 20 lines.
   
8. Creation of new 'refresh' option for enemies, permitting enemy hate group to re-detect potential targets from their hate group.  This can make enemies less single-minded towards attacking only one target and permit them to strike at targets of opportunity.
   
9. Correction of companion's fully solid death effect.  A simple fix.
   
10. Correction to fault in On Map Battle Music system.  It didn't properly sort out enemies excluded from playing music from those not excluded.
    
11. Correction to fault in Weapon Ammo system:  Missile weapons that use Ranged-Item ammunition now uses the range and speed of the item ammunition as it was meant to.  
    

---

*    Frank's MultiPose Charactersets for the Lycan ABS is an exclusive to House Slashers and Save-Point
**  A small chart within the help file shows the map effects for player/companion/enemy move states and status ailments.

[DerVVulfman]

It hasn't been long at all.  But it is now time to give The Lycan ABS a new...

BUMP!
to Version 11.7

First, there is a fix I needed to make.  I never took into account the original movement type (fixed, random, etc) for the enemies prior to them detecting a target.  They wandered, even if I set them to be fixed in place.  That made specific positioning of an enemy haphazard if I wanted specific areas guarded.  I had already fixed an area which checks to see if the enemy is frozen in place by a status ailment.  Originally I named it 'update_enemy_event_movement_frozen?', it is now 'update_enemy_event_movement_type'.  

In fact, the 'update_enemy_event_movement_type' method is a blessing as I added more than just the freeze state and predefined move type state.  If the enemy had fought and (possibly) lost track of a target (either killed it or just cannot see/hear it anymore), it may either return to its original movement style or switch to a wandering enemy mode.  In order to switch it to a wandering monster (aka RANDOM MOVEMENT), the game designer need only work with the 'Personality' comment already available.... just use Personality [9] ^_^.  

And... don't you hate it when you want some stupid guard event to walk up and down a corridor and he sees you for a time... but doesn't return to his original 'up and down the corridor' pattern?  Yeah... stupid guard.  Can't remember to walk the beat.  He can't even remember where his station even was!!!  Oh, wait.   Set a personality value of 10, and he will!  Yep, you can also just use Personality [10], and you can set up a guard or enemy event to return to their point of origin.  And to add a bit more panache, any event with a custom move route will restart from the beginning, so you don't have to worry about it trying to move left into a wall because your old custom move route said so!  It restart!  But... it does override the Personality [9] option, only going with the originally planned move route the event is designed to use.

That being said, there is a new command to the Force Movement system which lets the game designer script out what an event does by using script commands in an actual map event.  This overlooked system in itself allows for a more painstakingly detailed bit of combat.  So yes, while you have been able to make events move and attack by literally using map events to control things, you can now make enemies move by use of the new $ABS.update_enemy_force_pathfind command.

[DrHouse93]

Ehi DerVVulfman, hope you're fine^^

I'm actually having a problem with the Multipose system provided with the ABS. It works fine until the charaset has 4 traditional frames, or even 5 when setting the STAND_FRAME to TRUE. However, as soon as I use more frames (6, for example, not counting the standing one), the engine keeps moving the character in 4 frames, therefore making useless any additional frame beyond the 4th. This is my configuration:

Code:

# Pose Control - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   CHARSET_TOTAL_POSES         = 4        # Total number of poses, it's set to 4 because I haven't made the other character's  poses, yet
   CHARSET_POSES               = 4         # Standard number of poses. This is set to 4 because I don't have poses for the diagonal movement
 # Frame control  - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   CHARSET_FRAMES              = 6         # Standard number of frames
   CHARSET_STAND_FRAME         = true     # Optional 'standing' frame
 # Prefix - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Instead, this is the chara that I'm using:

Content Hidden

[DerVVulfman]

Ah, yes. That. I was working on Lycan a couple days ago. I'm sending you a preliminary REDO of the script as it was missing a method that is player related.

I was planning to unveil it a bit later... currently tied up on some things.

But what you have displayed for your poses/frames config is 100% correct.

[swickster]

Did you fix that character moving like the Flash thing? LOL

[DerVVulfman]

Its a work in progress.

[DerVVulfman]

I now proudly present a new story for...
THE LYCAN ABS
to Version 12.0

The main page now offers the original story as it was presented when the Lycan ABS was first introduced, with the new Version 12software.  But at the same time, it now has a sequel.  Quite possibly a first in that any demo showing off a singular system actually has a continuing story arc.

Version 12 has introduced some fixes into the pixelmovement system, particularly towards how it renders the Game_Party character as the player moves across the screen.  But while this worked fine for general movement controlled by the player, the character revealed a fairly humorous movement speed when controlled by the Map Event's 'Move Route' system as reported by swickster.  To offset this, a pair of commands were created that lets the game developer temporarily disable and enable pixelmovement in their game.  Still, it is entertaining if you like DC Comics 'The Flash' or wanted to mimic a Soul Reaper's 'Flash Step' right out of the anime Bleach.

Version 12 also made accommodations for a revised version of Frank's MultiPose system which lets the character use more than 4 frames per pose or action.   The issue as detected by DrHouse93 was a conflict between both the paperdoll and the ability to use more than 4 frames at a time.  This has been fixed.  So not only was a fix made to the Lycan ABS, but to Frank's MultiPose.  As a bonus, the Lycan Paperdoll was altered in the way one actually sets up their spritesheets per item worn. 

And Version 12 instituted a new option that was requested by ChickenFetus, the ability to have enemies that had a dread fear of other enemies and kept distant from them when detected.  Dubbed the Phobia system, entries were added into the Configuration section's first page.

Meanwhile, errors were fixed in regards to the Respawn system that initially required a non-existent Status ailment ID number.  To fix this, a new value was added to the Configuration section's first page under the Life/Death options header.  And other fixes were made to the system that creates 'scattergun' effects and properly controls gun recoils.

At the same time, some of the additional systems have been upgraded to newer versions.

With these changes and requests, I do wish to point out that both swickster and chickenfetus are now in the credits for version 12.0