New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LivingSpawnEvent.AllowDespawn gets ignored #4485
Comments
That type of code usually is just mean to make sure you don't call it every tick (because of performance concerns). Since despawning isn't really urgent there is no need to despawn exactly on any given tick so if you just check once every few ticks that is acceptable. I personally use the % modulo operator instead but I think this code simply means it will only check once every 32 ticks (basically about once every 1.5 seconds). Looking at the code, it seems to be just doing the event version of the despawning once every 1.5s and doing the regular depawning (if entity is far away from the closest player, or if it is is sort of far away for a long time from the closets player). Definitely I think the logic could be clearer, but I think the idea is that you can prevent despawning with the event easily because every 32 ticks you get a chance to reset the idleTimer to 0 whereas if you let it get to 600 then there is a chance that closer entities might be despawned. Interestingly though I think the logic is that entities that are very far cannot be prevented from despawning by the event. Anyway, what aspect of it makes you think it is a bug? |
In my case, I'm trying to use it to spawn zombies about ten chunks out, or the maximum loaded Chuck range, for my mod. Falling back to the vanilla logic will remove the zombies instantly, however I have found that making them persistent will keep them active the whole time. Alternatively a way to remove persistence would be just as helpful but I didn't see a simple solution without reflection so I figured I would ask about this. My mod is aiming to have zombie hoards lurking around and I want the player to be able to see them coming and decide how to react to them. To actually answer you question though, I did not fully understand bit masks but you have help clear that up. I Thought that the bit mask was there just to prevent spawns from not following vanilla despawn rules from the time they are spawned , which it is doing, but not necessarily the intent. |
This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions! |
This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue. |
Hello. I'd like to re-activate this issue. I believe it is a bug and it needs to be fixed. The solution is very easy. In EntityLIving:despawnEntity(), remove this check: (this.idleTime & 0x1F) == 0x1F |
The possible error resides in EntityLiving with forge version 1.12.2-14.23.0.2515 (latest as of now)
In the method EntityDespawn, before calling the event the logic (idleTime & 0x1F) = 0x1F is checked preventing the if statement from being true most of the time and falling back to vanilla spawn methods.
The text was updated successfully, but these errors were encountered: