Vampirism - Become a vampire!

Vampirism - Become a vampire!

16M Downloads

Vampirism's mobs are not considered hostile by all mods

maxanier opened this issue ยท 16 comments

commented

As Vampirism's creatures are only hostile to the opposite faction I did decide to make them not implement IMob.
However, this causes problems with other mods, which don't know/cannot know if the entity is hostile.
See for instance #190 or #48.

To find a solution, I've decided to work on an addition to Forge which adds a way for mods to detect if a entity might be hostile. See MinecraftForge/MinecraftForge#4071

commented

It is very hard to find a reasonable solution for this

commented

Darn. So it seems it's a known issue then. since slashblades mod doesn't know about the vamps being hostile by default so it won't strike them. :<

commented

I am sorry, but I still haven't found a reasonable way of solving this

commented

Have you given any more thought to this issue? Implementing IMob would be fantastic. It would basically resolve any compatibility issues with mods that check entity's instance type

OMT
Reliquary
IE
TE
RFTools
OC

Are a few mods that we use specifically that never "see" the Vampire mobs because they aren't classified as regular mobs

commented

xReliquary has something called mob charms, and while you have the charm in your inventory, all mobs of that type ignore you. Would it not be possible to do something similar for Vampirism?

Something like

vampires:
if instanceof(player) && isVampire(player) // ignore the player

hunters:
if instanceof(player) && !isVampire(player) //ignore player

This way humans and hunters are ignored by vampire hunters, and vampire ignore player vampires.
Vampires already target mobs and villagers, so that wouldn't have to change.
You would basically transition from a faction type system to checking the mob type of vampire/hunter's targets. Similar to how zombies only target players/villagers!

I'm sure you've already thought of something along these lines, so what part am I missing?

commented

I still could not come up with a real solution for this.
Yes, if they would implement IMob they would be considered hostile by almost all mods. But that would also mean that the vampire hunter you might want to be trained by or the friendly vampires living in your vampire castle would be attacked too.

This multiple faction system is just not intended and therefore it is very difficult to implement good mod compatibility.

I guess right now, it would be ok to classify vampires as hostile, as they are not really useful for anything, but that might change

commented

I assume xReliquary hacks the AI of the other mobs to ignore players holding the charm. This is not the cleanest solution and I think it would not help us much anyway.

Imagine the following scenario:

  1. You have a modded pet which actively attacks everything evil (IMob) to protect you.
    Vampirism's mobs also implements IMob (suggestion)
    a) You are a vampire.
    Your pet would start attacking every vampire it runs across, even though they are passive towards you. This is not the end of the world, but if you are e.g. wandering though a vampire forest your pet would be dead very quickly.
    b) You are a hunter.
    Your pet would start attacking every hunter it runs across, even though they are passive towards you.
    You want to level up to level 2 by talking to a vampire hunter. It would be attacked by your pet anyway.

Yes both scenarios are not the worst thing, but still significant.

  1. Vampirism's mobs do not implement IMob (current situation)
    Pet does nothing.
    Smart thirdparty mods could, however, detect that the player is attacking another entity or is being attacked and therefore let the mob attack.
    In addition other mods could add (very simple) integration for Vampirism to allow targeting vampire or hunters. (The other way around is very difficult, since these IMob checks are usually hardcoded)

So basically it is a trade-off decision whether to implement IMob or not. Although I could probably add it for the always hostile boss mobs.
Maybe I am missing something, but I can't think of any way to improve either approach.

I am still like the current approach slightly better, but that could change at some point of course.

commented

What modded pets are you thinking of particularly?

This seems like you're solving a problem that isn't your problem. You're adding mobs that have they're own behavior and AI, and it's up to other mods to decide how to react to them.

You're mod adds mobs both passive/aggressive, you implement IMob like most mods do, with AI dependant on the player's alignment. And as long as there is some simplistic way to check the player's alignment for other mods, that's about all you can do. Otherwise you're basically trying to support every mod that adds pets/custom AI at the same time.

Vanilla wolves only actively attack skeletons, and I can't seem to think of any other pets that would need specific exceptions like this.

This could be resolved simply by adding some sort of custom blacklist support on the other mod's side, instead of trying to find a universal way to resolve it in this mod.

Currently all mods ignore Vampires, regardless if its targeting entities, preventing entities from spawning, automating interactions with them through machines because they all check for IMob, and the Vampirism mobs are not of that type. By converting to IMob you would stop have issues/tickets opened that say "vampirism doesn't work with mod X", instead you'd get tickets similar to "I'm a Vampire, but my pet from mod Y attacks other vampires". Those tickets could be handled on the other mod's side, because it's their custom AI/mob initiating the interaction.

Two questions:

  • Do Vampires ignore entities for sucking blood if that entity is a pet of a Vampire?
  • Is there a simplistic way to check if a pet's owner/player is a vampire/hunter?
commented

I would not say that I am trying to solve a problem here that is not mine.
By implementing IMob I am basically declaring "Hey, this mob is very evil, and has no other use".
So I'm "responsible" if other mods target your friendly neighbourhood vampire or somehow otherwise mess with the system.

But you are making the good point that it is easier to fix on the other mod's side.
It should be quite easy to implement blacklisting or compatibility with Vampirism. However, I doubt that many mod authors are willing to do so.
In addition this would also solve the problem without me adding the IMob interface, since they could just add a check for IMob and IVampire or something (which is more intuitive than selecting IMob and then filtering vampires).

But given the fact that there does not seem to be an universal solution from Vampirism's end I will consider adding the IMob interface again.

About the questions:

  1. No (as far as I can remember). I will check if there is a Vanilla interface allowing me to get the owner of a pet. I so I will add that check.
  2. As long as you have access to the player object (which might not be the case e.g. for turrets) it is e.g. simply
    VReference.VAMPIRE_FACTION.isEntityOfFaction(player)

There should be a couple more methods to easily check if an entity is hostile against a player (or another entity).

commented

Revisiting this, vampires could be explained as feral and blood-crazed due to being in the wild for so long, attacking anything that comes near. Still thinking about a justification for the hostile hunters though.

commented

That is a really interesting idea, but all the swapping back and forth might be difficult.
Furthermore it might confuse players if the treatment of certain mobs is inconsistent over time.
But I will have a closer look

commented

I don't think there is really an elegant answer to this due to core limitations in what is considered a "mob" without a lot of custom work, but the above should at least address SSP, and might work as at least the foundational groundwork for SMP.

commented

My suggestion, if possible, would be to create an extension class of your base class for both hunters and vampires, and implement IMob on the extension, not the base class, but otherwise not add any (or much) additional logic in the child class aside from implementing the interface. Then when spawning new mobs, use the base class (without IMob) if all nearby players are friendly, and the extension class (with IMob) if they are not. You may also need to swap them for a different instance (that either does or does not implement IMob) if the players nearby change up, and this might get tricky on multiplayer servers particularly in high traffic areas, but this would at least give baseline mob/non-mob support under the most common and general circumstances. It likely needs quite a bit of additional logic to cover all edge cases though.

commented

Alright, I will give mopsyd's idea a try for 1.14. But I will try to keep it simple.
3 Config options:

  • Always IMob
  • Always non IMob
  • Smart (IMob depending on players faction, falls back to non IMob on servers)

Let's see how this works out

commented

I added a wiki entry to summarize this issue
https://github.com/TeamLapen/Vampirism/wiki/IMob-issue

commented

Going to close this.
In SP this should work acceptable.
On servers it still doesn't do much, but there isn't much we can do.