Hello there,

I am the developer of "Damage Indicators (DI)". I recently had a plugin customer report to me a minor issue caused by explosive spells within your plugin.

The purpose of my plugin is to display the amount of damage done to entities, I do this by creating an ArmorStand Entity with a custom name that displays the amount of damage done. After a short period of time I remove this hologram from the world for obvious reasons. However, if a DI hologram gets hit with an explosive spell that destroyed it (and the spell that destoyed it auto restores blocks/entities it destoyed over time), the DI hologram may reappear.

I am hoping to work with you in some way so we can resolve these issues. You have an amazing plugin here and I would love for our plugins to be compatible.

Take care,

dSevvv

Hey, thanks for reaching out!

I'd be happy to add some integration, your plugin sounds cool. Do you tag your armor stands in some way (bukkit metadata, persistent metadata, etc) that would let me identify them?

Thank you so much for the quick response!

I'm glad you asked, I do in fact add some identifying data within the ArmorStand's PersistentDataContainer. This way you don't even need to add the plugin as a dependency.

For the free plugin you would go about checking if an entity is a hologram like so:

boolean isDamageIndicator(Entity entity){
    //get a reference to the "DamageIndicatorsFree" plugin
    Plugin plugin = Bukkit.getPluginManager().getPlugin("DamageIndicatorsFree");
    //create NamespacedKey
    NamespacedKey key = new NamespacedKey(plugin, "hologram");
    //check if plugin is null or disabled
    if(plugin == null || !plugin.isEnabled()) {
        return false;
    }
    //check if entity is an ArmorStand object and then cast
    if(!(entity instanceof ArmorStand armorStand)){
        return false;
    }
    //get the armorStand's persistent data container
    PersistentDataContainer container = armorStand.getPersistentDataContainer();
    //check if the armorStand has the key
    if(!container.has(key, PersistentDataType.STRING)){
        return false;
    }
    //check if the armorStand's value for the key is "damage_indicator"
    if(!container.get(key, PersistentDataType.STRING).equalsIgnoreCase("damage_indicator")){
        return false;
    }

    return true;
}

I just pushed an update for both the free and premium versions of the plugin to make things more consistent between the two. For the premuim plugin, it's virtually the exact same process but instead of checking for the plugin "DamageIndicatorsFree" you would check for "DamageIndicatorsPlus". I would greatly appreciate if you added support for both!

Please let me know any concerns you may have. I am a fairly new developer so if this is a poor way of going about this I would love some advice on how to improve.

Thank you! That seems totally doable. Persistent metadata would probably be my choice for tagging things (it's what I use for my mobs and NPCs) so I don't think it's a bad decision :)

Can I ask what spell you used if you were able to reproduce this issue? I've tried Boom and Grenade but so far haven't been able to get an armor stand to stay around.

You're welcome, I love bug reports from other developers, you were a pleasure to work with as well :)

Hey Nathan, I asked the customer who found the bug and this is what they responded with.

Thank you, that was helpful!
Seems like the problem is actually specific to when the entity gets lit on fire by a spell, not explosions.

There will be a fix in the next dev build. I am making it so spells can't combust (or damage, while I was at it) entities the spell isn't allowed to directly target.

In general this includes armor stands by default.

I will also add a specific check in for your metadata as well, though, since targeting armor stands is something a spell can choose to do, if the spell creator wishes it. For instance, guns in the war configs will target armor stands so that they are able to damage vehicles.

TYVM!

Cheers for the quick responses, and clear communication. It was a pleasure to collaborate, if you ever have any projects in the future that you're considering needing help on, please feel free to reach out.