Unintentionally killing the enemy in one shot.

[mikejkelley]

Character is firing a semi-auto. I've made sure to set the raycast interval to 0 and to reset my raycasterWhatHit game obj var to an empty game object each time the mouse button is released.

The enemy's health manager is set up as in the attachment. Health is 100, damage is 34. In game, health becomes -2 with one shot, indicating that the event is running until it satisfies the less than condition.

Why isn't it running once then exiting?

[mikejkelley]

I feel like I've tried everything...

[Lane]

It is running once and exiting, then probably running several more times.

Whats triggering it? If it returns to the CheckIfHit state and the conditions for being hit are still met then its going to do it again, this can happen and usually be avoided by adding a Next Frame Event somewhere in the pipeline.

[mikejkelley]

I raycast from a gun and store the hit object in a global var. I make sure the raycast repeat interval is 0 (and have tried it w/ 1000 too). I have a next frame event that loops back to wait for input where I set the global game obj. var as an empty game obj. to make sure the enemy doesn't think it's being repeatedly hit. Still, they're dying before they're time.

[mikejkelley]

*their.

Ok, so I eliminated the greater than float compare and used a next frame event to exit out of the state. It works now, but why? Is float compare just that janky?

[Lane]

I would have to see the entire system to tell whats wrong with it.

But theres a number of things that could be happening, most likely its keeping a variable stored from the raycast (so it doesnt matter how often it casts) and using that to fire the hit event and reduce health and does it several times.

Just speculation though since I've seen that kind of thing happen on my own systems I figure it could be happening here. If you examine how each variable associated with the whole loop is working then you'll probably find some little kinks.

[mikejkelley]

Thanks for helping me troubleshoot this. I still don't understand why this was happening. The subtract health action was not set to "every frame (in the img it is but when tested it wasn't)" and there was nothing that would have made execution re-enter the subtract health event multiple times. Oh well.