Yeah, it's been long time, and in that span I realized just how bad of a programmer I am, and how that worked in my benefit.
Behold: almost a month of programming:
I self-deprive myself, but there's a lot going on behind-the-scenes here.
So I started working on the code fro grabbing, and realized that a lot of my existing content needed reworked.
With the post above, I had the wonderful idea to try to set the enemy class to base off of an abstract base class. This will work good for setting up different enemies to behave differently, but I messed up in not transferring all of the content from the prototype enemy over to the new class, including how health was handled.
(There's a lot of garbage in here that needs cleared, but the main ones are EnemyBase, Hopper (the enemy to the right), and EnemyBehavior (the prototype with health).
I transferred functionality, then realized while testing that Unity's GetComponent function doesn't like returning an inherited class if you specified the generic type to be its parent. Which meant one of two things: either leave the classes split and set EnemyBehavior to a better name and dedicate it to player->enemy interactions, or use some magic with reflection to try to find whatever type was attached to the enemy. The results of this split are shown in the gif - the enemy to the left has the EnemyBehavior shown off but no associated AI, and the one to the right has the Hopper class and not the EnemyBehavior (so it, effectively, has no health). Since there's no issue with having one or both on an object, this means that, besides enemies with a primitive AI, I can also add in things like static destructible obstacles (like a box that drops an an item) and "triggered" environmental hazards of a stage (such as falling rocks in a cavern or an erupting steam vent) that can't be defeated in combat.
The sideways enemy after the guy to the left gets hit is an entirely new item defined as a grab-able drop that inherits a defeat sprite from the enemy. For the sprite itself, I made a placeholder based off of a teenager with a katana he bought at a flea market, because that's pretty non-threatening. Normally, the dropped enemy disappears after it lands back on the ground, but I locked that behind a flag for now since I need to work on "grabbing." One of the functions of the game will be the ability to grasp enemies while they're in the air, then launch them either to the side for a more powerful ranged attack, or downward to thrust yourself into the air a little bit. (Can you tell there's a Klonoa influence here?) This being a non-enemy object is why the projectile "lingers" a bit when rubbing up against it, rather than registering as a hit and returning to the player, though I should add in a safeguard against that...
The projectile itself was largely fixed. The "lingering" after an attack is completely intentional - the grab function checks within a certain range of the projectile, so this allows the player to more easily grab anything hit by the damage radius of the attack, even if the character himself is outside of range (this is possible since the game is an endless runner (right now for testing I just have the level speed set to 0)). Grabbing can be done while "lingering" or if the projectile isn't encumbered (attacking or holding onto something).
(Levelspeed 12. Look ma, no breaks! If you look over to the left of the red dot, you can see the player character respawning from dying a few times after the building he's on despawns, or just spawning over a pit (which needs fixed). I also haven't updated the building prefabs to use the new enemy type, but the spawns for those need reworked entirely anyway and those are placeholders regardless. Since I'm not working with scrolling yet, the player's speed doesn't update with the level, so this state is completely unplayable.)
From here, I need to work on actually transferring the grabable object over to the player's grasp, then working out "throwing" it (the functionality for launching it is there, but there's no way to "tie it" to the player's control as of now). Internally, the game recognizes already the downed object as something that can be grasped, but it doesn't quite know what to do with it, especially since I've only just now gotten the rigidbody for the character's projectile to work correctly. In other words: actually finish the stuff I wanted to get done since last update.