The Lycan ABS

[Davesss]

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.

Thank you! Learned something again. :)

[DrHouse93]

Hey DerVVulfmann, thank you so much for your awesome ABS!^^
I'm having a problem, though. I have version 10.2 (the latest) and I set my enemies (Zombies) to use a skill rather than the ordinary attack, which deals no damage but it stuns the target (allowing other zombies to bite it and infect it. He can also be bitten by the zombie by whom he's been grabbed, but I'm working on that, since I have no idea how to implement such an effect). However, the problem is, when my companion is grabbed by the zombie, I'm also stuck and can't move (as if I have the stun state, too, even if no icon is shown). Don't know if it's a bug or I have some bad settings

Hope you can help me^^

[DerVVulfman]

Yarrrrrrr.....* It's not a bad setting, but an overlooked issue.

To allow the companions to keep pace with the player, I tied the movement systems together. However, that is unfortunately affected by the status ailment systems which guess needs a bit more work.

Looks like version 10.3 will be in the works soon. So much for 10.2 being the final version, eh?

Since you made your first post, your account will fully upgrade and you'll have access to your UserCP and PM service soon.

[DrHouse93]

These are both good and bad news xD
Good:
The problem will be fixed
Bad:
I have already customized a lot the ABS, I hope I don't have to start over again T_T xD
By the way, other reports: even if I set the companion's death pose to 3 (fully solid with pose), when killed they become transparent (they're temporary using the default charsets, don't know if this changes something). And also, if they reach an unpassable spot, you can walk over them like if they're ghosts xD

EDIT: When sneaking, it's possible to walk on unpassable spots, such as water
When talking with companions and the Mode-7 Edit script is enabled, it says this:
Script MGC Mode7 Edit NoMethodError
undefined method "spriteset" for #<Scene_Cmd_Dialog:0x2892408>

[DerVVulfman]

Issue 1 Synopsis:

Player becomes slowed/unresponsive as if suffering the same ailment that is applied to a party-member companion.

Issue 1 Playthru Examination:

Regardless of whether it be the player or the companions, movement related status ailments affect the whole active party. If the player is afflicted, so to will the companions.

Issue 1 Code Examination:

The routine that checks which status effect is being checked (update_status_effect_determinant) doesn't check to see if the effect applies to the current actor. And the later methods (reset_move_states on down ) apply the effects to the player, which is then tied to the companions.

Issue 2 Repair Concepts:

Fixing the determinant method only requires one statement. Insofar as the update_status_effect... methods, I need to create a new set of values for each actor(movable, move_speed and old_speed) That way, individual actors have their own speed systems to control within these methods. Dash and sneak triggering for companions is still going to be based on the player.

Was it really Christmas that I last updated the system???

[flynnmichael81]

Hi DerVVulfman,

First off I'd like to say thanks for your ever present presence throughout the RMXP world. It seems that whenever I Google whatever I'm trying to accomplish on the game I come across your scripts, or comments on forums, and they have helped me more times than you can imagine.

Anyhow... Forever I've been using variations on MrMos ABS. Mostly his NeoABS but in the recent game I'm playing around with I decided to try his 5.5 edited by you (I had no idea that this existed or I'd have come straight to this.) Having now found this version I have torn out the old scripts and have replaced them with the new version and for the most part it is working beautifully. The only issue I'm having is with diagonal movement: the player moves fine on the diagonal but ranged attack ammo seems to become invisible when being fired on the diagonal (still works fine on the straight). The attack does still seem to work however but I get no image for it. I've also tested it in the demo version (10.2) provided and the same thing occurs for me.

I'm wondering if you've added some sort of provision for a second set of graphics for diagonal firing and I'm missing it. Any advice would be gratefully received!

Cheers!

[DerVVulfman]

Okay... Keep em coming. It's great to hear from people, even bug reports. Oh, and the both of you are going to be in the credits for the next version of Lycan.

Insofar as your problem with the arrows? An easier fix than you may know.

Within 5 - Game Code, the passable? method begins on line 2342. It has a regular set of routines that look for the upcoming x/y positions so it can see if the next position for a character is valid.
Replace

Code:

new_x = x + (d == 6 ? 1 : d == 4 ? -1 : 0)
new_y = y + (d == 2 ? 1 : d == 8 ? -1 : 0)

With

Code:

newxy = $ABS.get_newxy(x, y, d)
new_x = newxy[0]
new_y = newxy[1]

The new code recognized all 8 directions, using a method I already penned within the Game_ABS engine.

Oh, the actual attack of a single diagonal missile did not work. As it was deemed an invalid direction, the arrow wouldn't go any further than the shooter himself.

[DrHouse93]

I think I found another bug (or don't know if I messed up something with my configuration...). When adding different values to the STATES_EFFECTS (for example, DELAY_EFFECT) it doesn't do anything on map. E.g.:
I found an Hunger/Thirst system (as you already know^^) and I set that when Hunger reaches a certain level, the appropriate status ("Hungry") is inflicted. This status should delay the player's movements, so I added its id on the DELAY_EFFECT array. But when the status is inflicted, nothing changes: the player can still move at normal speed, even if it can't dash or sneak. Furthermore, if he's switched with a companion, and the companion dash/sneak is true, he can do that as if it doesn't have the status at all. Other effects (such as stat reduction), as well as the default Delay status work, though

[cardcafe]

All of this is... Interesting.

[DerVVulfman]

Hey, I figure you guys need a little heads-up.

First, I did get that diagonal shooting arrows working as you can see. But that was something overlooked in the base system. For diagonal-angled 8-pose graphics, you would need the Frank MultiPose script that is in the Paperdoll system. At least I remembered to put it in that script. Still, the newer demo for that version will have the proper updates when I get done.

Second, I went after the player vs companions motion system. That one was a bit more in-depth. Not only did I have to attack the sneak/dash system, but the status ailment on-map system, party rotation system and add some values to the Game_ABS and Game_Companions class so rotations and saved values were possible.

** Oh, companions that are dazzled or blinded... may suffer an optional movement ailment. Like... the player cannot see by being dazzled, but any companion dazzled acts as if confused and waddles about. Blinded players cannot see a darkened screen... but companions get slowed a lot. Sound like a plan? **

And, it was a simple fix to get companions to be fully solid at 255 opacity. My bad. Simple goof on my part... I must have trimmed something out during cleanup (and some things are needing cleaning still).

Now... um... Running my demo, I do not see the issues with Sneak allowing you to walk on impassable tiles such as water. The water around the entire swampland is impassable with sneak. HOWEVER... there may be something you are not aware. The CTRL key, by default, allows one to walk over impassable tiles when in test-play mode. Even the water-impassable system I added for Lycan allows the game developer to walk across them with the CTRL key when test playing. If you set your Sneak system to use the CTRL button, you'll walk on water in test play. BUT... it won't be an issue with an encrypted game.

Getting your companion to act as a bridge when they're dead? I don't know how you did that. Your companion shouldn't be able to cross impassable tiles either, so how did that happen? I mean, you can use $game_companions[index].moveto(x, y) to place them like tiles on the map, but that's about it. (It's covered in the help file under Additional Script Calls).

As to the rest... not yet tested/confirmed/identified/squashed.

Not bad for really getting to this in a day. BUT... I'll probably be tied up with the Weekly Gazette till Sunday. Forum Occupational Hazard. AND... I'll have to rewrite the CHM/HELP file a bit, and add to the credits.