-
Notifications
You must be signed in to change notification settings - Fork 3
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
Darkroom/Pigman Grinders not working on S. #169
Comments
There is another bug: http://youtrack.sk89q.com/issue/CMDHELPER-2804 that may help shed some light on what's going on. I have not been able to personally reproduce this issue at all, but this second bug seems to be more reproducable, and may allow me to debug the situation. Assuming these bugs are actually linked (I have a hunch they are) then solving either will solve both. Now that I think about it though, does this only affect nether entities, or main world entities as well? |
I'd like to assume it affects Both Overworld and Nether entitites, as I've heard complaints of darkroom grinders not working in the overworld both this rev and last. |
And just for completeness, although LadyCailin already knows, I found that /count-entities gets the pigmen spawning again. |
I wonder if there is a weird conflict between mob limiter and CH caching entity references or something? |
I don't recall it happening on any other server running CH, so it might be On Sun, Sep 29, 2013 at 10:19 PM, LadyCailin [email protected]:
|
Well... here's the thing: the pigmen issue was shown to me a couple of weeks ago (we discussed in IRC), but we have only been running MobLimiter on Survival for the last day. So whereas MobLimiter might compound the problem, the problem exists despite it. I did wonder about caching in CH. Why exactly does CH do that? Skimming the code of CraftChunk, it appears to be efficient enough. Can we get a link to the CH caching code in here? I do note that MobLimiter explicitly specifies EventPriority.HIGHEST (something that seems pretty common in the Nerd code base and neither necessary nor always beneficial). So if CH is using NORMAL priority, CH will cache spawned entities that are subsequently cancelled out of existence. I'll go ahead and drop that event priority in MobLimiter, but as noted, that's not the whole solution. |
One further note on the caching: Other plugins also cancel entity spawning, e.g. WorldGuard in spawn. |
Heh, I found a clue in the CraftChunk source code... :P Is any CH code strongly referencing the NMS Chunk? Possibly indirectly through the entity itself? |
No, I'm not using any NMS references at all, even in the "evil" code sections. I'm directly referencing CB code, but not NMS. To be clear, I'm not purposefully caching anything. I was implying that perhaps something CH is doing is causing bukkit to do some caching or something, but I'm not manually maintaining any entity caches. I'll admit, I'm totally lost on this one, as I can't reliably reproduce anything in a test environment, and bug reports have minimal information in them and are generally vague. The assumption at this point is that it's CH, because running the get_entities_in_radius fixes it, but I wonder if there is a problem in CB itself, and CH is just able to "jump start" it? After all, the MC portions of CH aim to be light wrappers over bukkit anyways, so there's as minimal extra code as possible. |
Thanks to roastnewt, we have identified that the problem isn't with CH, it's with WG. On a server where the problem is being demonstrated, he disabled WG, the problem stopped. Re-enabled it, the problem started back. So we should begin investigate WG instead of CH. |
Did some testing turning off the WG use-creature-spawn-event setting. Did not seem to make any difference. I'll soon be using jvisualvm to dump the heap during a time of relatively low load so I can do a better analysis of GC churn and I'll look for signs of memory leaks or delayed reclamations pertaining to mobs at the same time. |
Referencing: http://youtrack.sk89q.com/issue/CMDHELPER-2795
Any techs to weigh in on this?
The text was updated successfully, but these errors were encountered: