While vampirism is mostly complete, there is no valid way of becoming one, and it is lacking in unique content.

• One or more kinds of vampiric minion, created via spellcasting
• Coffins
• Wooden stakes, for vampire hunters
• Silver and garlic-tipped silver arrows, also for vampire hunters. Silver arrows also work on werewolves, and an aconite-tipped variant damages werewolves more.
• Blood bottles
• More vampiric rituals
• A way of becoming a vampire
• Some other stuff, will expand later

Wouldn't the prime vampire be the result of pissing off a gypsy or making some sort of demonic pact?

Uh, excuse me?

Just ideas of how you become a vampire. The gypsy thing was more of a joke...unless you want to add a new villager.

My vote for how to become a vampire is either a pact with a demon such as Lilith, or encountering a vampire using the crystal ball, and being bitten.

Someone more experienced than I should take a look to confirm this, but I think there is a potential problem here. If a LivingHurtEvent handler posts another LivingHurtEvent in between setting and getting the lastDamage variable, it will overwrite the value. For example, I've seen potion effects that cause a target to damage all entities in an AOE when they take damage. A vampire under this effect would calculate their final damage from an attack using the AOE base damage.

Other than that, it should work. The event bus doesn't have a queue, so it just iterates through all applicable listeners in order when an event is posted.

Yeah, it's correct. I was pretty sure there was this problem when I created this code. It will need a capability to store the intended damage on a per entity basis. This is still problematic in case something deals damage to the same entity twice in a row, as the damage will be set to the one of the inner most instance. A per entity stack of damage values might be needed

What if lastDamage values are stored in a stack? If a new event is posted while resolving the attack, it will push a new value, handle it, and pop it off, leaving the desired value untouched

Yes, that was exactly my suggestion. A per-entity stack. Dividing it per entity helps with debugging, and makes the whole thing more object oriented

Vampires are planned in the update after the diabolic update. However, some code that exists relating to them has been causing issues here and there. Regardless, this issue will be closed until then.