I've been having a strange bug with Dynamic Stealth, which is that sometimes a mob that has a weapon will just walk up to me and never attack. It looks almost like they're about to attack and then cancel over and over again. I think this is caused by a conflict with Rough Mobs 2. I'm not sure if its just Rough Mobs 2 or some conflict with mobs with unorthodox weapons held, like a zombie with two weapons. I've also seen this happen with the Skeleton warrior from Primitive mobs but that might have just been rough mobs 2 affecting it again.

No, this is confirmed for the primitive mobs skeleton warrior (from my own experience playing my own indev modpack). I hadn't looked into it because I figured it was just their mob being glitchy on its own.

I'll have to look into this one.

Oh, and if you have any specific cases of x mob with x weapons, it will help me debug the issue faster

Hi Laike-Endaril. I've taken over Rough Mobs 2, which is now open source. https://www.curseforge.com/minecraft/mc-mods/rough-mobs-revamped I'll look into this issue, but any help you can provide will be great. My github is here - https://github.com/p1ut0nium-git/Rough-Mobs-Revamped

Hey @p1ut0nium-git, it's been a while, but iirc the issue was that the logic for switching from ranged to melee and the logic for switching from melee to ranged were both using the same distance, so at that exact distance, it would basically freeze up due to switching back and forth repeatedly. I don't remember for sure though.

Basically, my fix was to detect the Rough Mobs weapon switching AI task and remove/replace it with my own AI task, which uses two different ranges; one for switching from melee to ranged and a different one for switching back.

Here is the relevant commit (also linked above; it's a relatively small commit):
ba6c0c6

Feel free to take any code you want from there. In theory, if you replace the existing Rough Mobs weapon switching AI task with that one directly, it should work, but I don't know if the one in Rough Mobs does anything else aside from switching weapons (though I assume not based on the task class name).

If you want a version of DS that does not replace the AI task just tell me and I'll build one. If the native Rough Mobs AI task ends up compatible without needing replacement, I'll remove the replacement code from DS.

I believe I've found the issue for the skeleton warrior from primitive mobs, but it would be something to solve from their side, and the dev has not been doing anything minecraft related since January, so I'm not going to bother trying on that one for now. Wanted to look into it first since it had just one mob with the issue, and might give me a clue for what to look for in Rough Mobs' code.

I'll go download the Rough Mobs code and look into it

I just realized Rough Mobs 2 is closed source. They will have to look into this from their side if you want a solution. I'll post some details here before I close this though, and create an issue on their tracker with a link to this thread, so they can use it for reference. If Lellson (the rough mobs dev) responds/contacts me after looking through stuff I can work toward a solution from my end too.

REFERENCE INFO

1. Dynamic Stealth overrides the canSee() method of all entities in order to enforce the stealth system. There are a lot of other systems in DS as well, but my intuition tells me that this is the related part from my side.
2. Dynamic Stealth can and will change the current attack target of an entity to null in between your ai task's shouldExecute()/shouldContinueExecuting() and updateTask() methods. In this case, I think the issue is canSee() though, and not the attack target, but I'll mention this just in case. I have a filter that I can add modded AI tasks to which gets around this to some extent, but the real solution is to always do a null check on the attack target in the same method that you're using it in. Other mods may inject AI that does something similar, so the only real solution is a null check. And it's just good java practice. And I'm tired of seeing it done wrong, if you haven't figure it out :P
3. Keeping 1 and 2 in mind (mostly 1), here's what I found in Primitive Mobs:
   This flag, which is based on canSee() is being used as a condition for a timer reset a few lines down. I have a feeling that's what is causing the issue for the skeleton warrior.

Lellson, if you read this and want me to make an alteration in my code, feel free to poke me and I'll see what I can do. I can also answer any questions regarding DS code ofc. It has a lot of non-obvious things going on in the backend.

Here is the link to the issue on the Rough Mobs 2 tracker:
https://minecraft.curseforge.com/projects/rough-mobs-2/issues/46

I'm having the same issue in pack I'm trying to make and for me this is a blocking issue with including DS in the pack. I'm willing to try and see if I can solve this myself and then submit a pr, but before that have you figured out a easily replicated case for this bug? I've tried just spawning in skeleton warriors but its very unreliable

It's an intermittent issue, which makes debugging more of a pain.

I'm fairly certain it has something to do with how they're handling weapon swapping for AI tasks (in relation to the canSee() method, probably), but as I said, Rough Mobs 2 is closed source. Technically I could rip their jar open and dredge through obfuscated code, but I'd really rather not, for multiple reasons.

So I tried fixing this by this approach: if a mob has seen a player at least once, it gets a 1 second grace period for canSee. The 1 second timer resetting every time it spots the player.
This is of course taking into account some obvious checks such as the player existing, being within some reasonable range, etc. There are some edge cases to this, where in the player is still attacked once before the 1 second buffer is depleted. But that is easily written off as mobs having even a modicum of intelligence and just attacking where it would be reasonable for you to exist.
Well, that was the idea, but unfortunately, I've been really struggling to implement this. A combination of not knowing minecraft/forge's code that well as well as being unfamiliar with your codebase has slowed down my efforts significantly. If you think the above idea is worth using, please give it a shot. Otherwise, I'll keep plugging away at this when I can, and hopefully have some results to show further down the road.

I'd rather not use that workaround since it wound introduce other compat issues. I really think this one needs to be solved from their end, since the root issue is their AI task.

I suppose I could create a new AI task and replace theirs with it, possibly. I'll look into AI task replacement as a possible solution at some point (reopened)

This should now be fixed in the latest release (082)