I released a new version just before writing this update.  For those keeping track, I tend to do two updates a day about twelve hours apart.  I have a new born on me in the wee-morning hours, so I have nothing but time to bug-hunt.  That's another secret as to how I've managed to get this thing done - working during hours that I'm usually sleeping.

Nickle and Dime Fixes:

• Self-destruct would sometimes leave the enemy image after firing.  This is fixed now.  
• There were a few logic errors with doorways involving top/bottom floor rooms that have also been patched.  
• Dashing, jumping, weapon animations, etc. on the world map have also been disabled to make for a cleaner experience.  
• More adjustments to the HUD due to logic errors, and I believe this is finally in a state where I can put a pin in it and call it finished (famous last words, realized).  
• Exit Spell works as intended on enemies.  I think this spell is finished.
• Other minor adjustments, such as some enemy resistances fixed.

Bombs and Claws as Armor:

Two updates to weapons that I only now just confirmed.  First, bombs do take enemy defense into account.  I'm not sure why I didn't realize that, but luckily, that is a quick nerf to implement.

The larger update of the weapons was the claw.  It took me a while to think through how to implement the status ailments of the individual claws, because the actually "Claw" skill that fires runs a common event to calculate damage first, and then applies the damage algorithm.  But, I couldn't figure out how to get that common event to add status effects depending on the claw equipped.  You might be thinking, "Why not just tie those status effects to the weapon for attacking?"

This is a good time to disclose how the main character's equipment works.  According to the game engine, our hero uses no weapon.  The equipment slots for Sword, Axe, Claw, and Bomb are actually armor pieces.  I could implement four weapon slots.  If I were to add status effects to the Claw, those status effects would also work with every attack.  Also, damage would be added to everything based on the attack power of each equipped weapon.  In other words, each "weapon" in the game, when equipped, actually has no stats.  So, my solution was to make every thing and then make custom requirement codes to check those armor slots for each the four main attack skills (Sword, Axe, Claw, and Bomb), and then use a common event to figure out what the power should be.

Common events are usually run at the end of a skill, so I used Yanfly's scripts to change that around so Common Events are run first for those skills.  The common event puts the hero's attack value in a variable, then checks which "armor" the character has equipped, and attacks the correct about of battle power to the variable.  The rest is using the standard battle formula - (Atack x 4) - Defense.

However, status effects were proving to be headache inducing... until, they suddenly weren't.  Using Yanfly's plugins again, the solution was to just add some JavaScript to the notetag area which checks what "weapon" is equipped.  Add these effects as base (since you'll at least have a Cat Claw), then check for Charm Claw and add those.  If Dragon Claw, add everything.  It ended up being a much, much easier solution, and caused me weeks of frustration for no darn reason.  I think I got the code right in one try - something no one would expect.

Now, the actual field of effect of the Dragon Claw is a whole other sack of potatoes.  That's worth a post for itself along with Mega Grenades.

Petrification:

Petrification isn't standard in RPG Maker MV, and admittedly, my solution for how it works in-game still isn't perfect.  But, it does function as I intend.  In earlier builds, this wasn't the case.

Petrification was like a permanent state of standing death in those early builds.  You wouldn't be dead, but enemies wouldn't target you until there was no other target available, and then they would beat you to death.  Same with enemies; you would inflict petrification on an enemy, and then you could rail on them.  That's not proper.

Now, that's fixed.  If the Petrification state is added to an enemy, they die instantly, which is how it worked in vanilla situations.  If it is added to a player, however, they retain their HP but are still treated as a death.  This is thanks to a plugin from HIME.  The ONLY thing I cannot manage to get working correctly is the "grayscale" that should be expected in a petrification.  

I am using Walker Battlers from SumRndmDde.  Even though the battlers are facing up, they're technically in Side-View Battler mode with the positioning variables adjusted.  I have code in the state of Petrification that if a character is caught with petrification, it changes their sprite to a grayscale version.  But there is a plug-in logic conflict with the way the Actors are set up, so I don't see petrification ever having a proper grayscale color.  It is functioning fine, however, so I'm not terribly worried.

Credits:

Links to both Yanfly's, HIME's, and SumRndmDde's plugins, as wells as others, that are used are on the "Credits" options of my title screen.  Their work is outstanding, and this project really wouldn't be what it is without them.