crash-2019-03-07_09.24.09-server.txt

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@frodare If everyone is going to be away from the project for a while, might want to disable the stalebot, so that if anyone comes back to it in the future, the current issues won't have to be dug up (also reduces the chance of duplicate issues being made)

@Laike-Endaril I had that same thought and turned if off a couple weeks ago.

Good man

Hopefully someone will pick this back up in the future, but for now I'll enjoy the existing content

Since I'm here, that crash is probably due to an attack target not being null-checked immediately before accessing its internals. I haven't looked at the code, but I've seen it several times before. Several vanilla ai tasks do that though; they just get away with it because the attack target normally doesn't go from non-null to null between the task's shouldExecute/shouldContinueExecuting and its updateTask method. The exception is when some mod, usually within another ai task, sets the attack target to null (eg. to simulate stealth, passiveness, etc). The ai task engine is programmed in such a way that other ai tasks can run in-between your shouldContinueExecuting and updateTask methods, which I find somewhat annoying myself.

I don't expect anyone to do anything with all that info right now, but it could be useful sometime in the future. Also, I could be wrong about the source of the crash; didn't look into it too far. This is just something similar I've seen happen. If I am right, another mod is most likely involved; probably one that alters the ai of existing mobs