ServerCore

ServerCore

384k Downloads

Causes Solar Strike entity from Arcanus to never die

CammiePone opened this issue ยท 3 comments

commented

So, this has been reported to me in Up-Mods/Arcanus-Legacy#76 and to Dark RPG in https://github.com/gamerpotion/DarkRPG/issues/42, and finally figured out it was ServerCore causing the problem.

The issue is whenever a Solar Strike entity is spawned, it doesnt go away, despite its normal behaviour being despawning after a few ticks. With Arcanus alone, the issue does not occur, but with ServerCore and Arcanus, the issue starts happening.

I have confirmed this is an issue with ServerCore 1.3.2 and Arcanus 1.30 on Minecraft 1.19.2. I dont know what change ServerCore made is causing it, but it results in people being killed when they respawn on multiplayer servers until someone runs /kill on all Solar Strike entities, so it's a pretty critical bug and likely affects other entities from other mods.

commented

I pushed a build to both Modrinth and CurseForge under version 1.3.3-1.19.2 where this issue should be resolved now.

commented

If I had to guess it would probably be related to entity activation range. How does arcanus despawn its solar strikes normally?
A potential fix for these sorts of modded entities could be to just set misc_activation_range to -1 in the config, which should include most of these "misc" entities like spells and projectiles.

Other than that I'm not sure if there's any good way of checking if an entity is modded other than checking every entity type manually. If there is I could make a new config option to exclude all modded entities from it.

commented

Alright, I figured it out. Just before V1.3.2 I had the not-so-bright idea of increasing the entity tickcount (age in yarn mappings) in Entity#tick() instead of ServerLevel#tickNonPassenger() like I used to (and vanilla does). This doesn't really affect vanilla since all entities own tick override methods call super.tick() - but solar strikes don't.

In pretty much any development build after 1.3.2 this change has already been reverted though (for obvious reasons) - which lead to some struggle to reproduce it. The issue should already be fixed in development builds though, thanks for letting me know about it.