Hi EMC-Team, I'm having lag problems with mining. Every 4th or 5th block I mine drops its block only after 2 or 3 seconds, which is kind of annoying. Additionally I get these errors in my console: [Client thread/ERROR]: Item entity 4135435 has no item?! Is it me or is it the server? (I'm connected to Frontier Wilderness smp9)
This is either server lag or network lag between you and the server. Hard to say which one. As for the Item entity error; I wouldn't be concerned about that to much - I suspect it might have to do with EMC's meta information on items/blocks (incompatible with SP stuff)
I need the feedback from someone with more experience, or I won't learn, so I'm fine with it. You said that the move code needed some work, but I don't know what part in particular you have in mind, Or, you could offer me a completely different direction, but I really am interested in helping with some stuff. Please advise.
So I have been looking at the wrong branch of craftbukkit. I blame it on github, but really it's me. Might be more useful to use the right repository. Learning curve is steeper than I thought.
well, if you look at mine, youll see EMC specific changes, but if you wanna know the exact code were running, thats what you need to see. Theres probally also not much you can do about movement, unless you find ways to improve things more with like getCubes and the ray tracing and all
I was getting unholy lag today, and then I checked my task manager and found I had java client 32 open like 6 times >.> It's probably only me, but meh
That is one thing I can say for sure is not on the server end of things. Well, i really am most interested in working on the EMC specific code, because it gives me incentive to keep working even when it gets tough. I have some ideas about how to better manage the amount of movement calls, but I need to take some time to look at the correct code before I start suggesting things that you have already fixed again. I look forward to the challenge. As for getcubes and ray tracing, I haven't even looked at any of that yet, but at least I'm moving in a better direction again. For my own understanding of what is going on, I really need to build myself a test server to hack on, cuz asking you to try out my suggestions would become very wordy and drawn out. Once I get that far, I'm planning to get mumble going on my end so that we can chat about some things. For the moment, I still have a good bit to learn.
another good idea is to join the Spigot IRC channel at irc.spi.gt #spigot we discuss things in there.
Was checking out spigot irc. I will follow in the background and hopefully pick up a few things. I did a pull request with the changes I envisioned for reducing collision calls. Please give it a chance on your test server if you would humor an old man like me.
So status update, I've pushed out a change based on the idea just_five_fun provided. This will greatly reduce the impact clustered mobs can have on the server, with very little impact to gameplay. Essentially the number of collisions an entity can have in a single game tick is now limited. For normal things, they wouldn't be colliding much anyways, but in town there should be no noticable difference. In the wild I have the value much lower, and have 1 report that something may be affected with 1x1 cave spider pens, but I'm looking into it.
You can add one more report to that. I just tried to use my cave spider grinder and found it working at much reduce efficiency. Before about 95% of the spiders would become trapped in a single block, which made killing them easy and fast. Now only between 10 and 20 spiders get trapped in the block, even if 200 are trying to get in, so the process of killing them has become very slow. Before I start looking for ways around this I want to know if this change is close to definitive, so I can start the painful process of tearing down the grinder to try and find an alternative solution, and if so I like to know if anyone has a cave spider grinder design that is still efficient under the new rules.
The change is not definitive. It was based on my still developing understanding of the mob AI code. I believe we should be able to make an adjustment to improve performance and still maintain your expected behavior. Most of the mobs have a larger size bounding box than the cave spiders, so I believe this is the root of the issue. I am just guessing, but I bet they just move up and down a lot more than before. It doesn't really matter yet. At some point I would like to take a look at the behavior and study how limits can be more specific for spiders. The easy solution without reading too much into it, is to exclude cave spiders from the new limits system. Then a more specific block of code for spiders could be developed with community feedback. Honestly, no one expected this issue, and I doubt anyone would ever known to code for it until the change was pushed out to the general public. Thanks for your feedback and pardon our breaking your build. Aikar will need to be the one to code the exclusion, but seeing as how he has just been working on that block of code, I think he will know what to do.
Wouldnt you be able to drop them into a 2 block down hole? Wouldnt this negate the collisions since they are forced in and it only affects them after they are in it?
spiders can climb walls. It might actually be better to force the spiders to climb up to the kill zone when the see the player. I did that and it works smoothly.
Thanks for the input about the climbing, but I still expect that we will work to revert to the familiar spider behavior for now. It's actually up to Aikar, and I think he will have to see how much server load the spiders actually use. I doubt he has ever singled out spiders for performance testing.
new status update - after much work into debugging some code, I had enough code added to pinpoint it was dynmap (our live map system) that was a culprit of the problem. So, I immediately made changes to dynmap configuration to slow down how much it will render at once, and it seems to be helping even smp7... But... It uncovered a more confusing problem. The reason dynmap was killing the server so bad was because it triggers chunks to load a lot, and something is seriously wrong with parts of SMP 7 that causes chunks to load A LOT slower, like up to 30-40x slower! Most servers seem to average 1 ms per chunk load, but i was seeing numbers up to 40ms for a single chunk on smp7 :/ This is a serious problem... I've added more debug code to better detail each section of the chunk load process to see where its costing alot. so will need more time to furthur dive into this, but with dynmap on reduced throughput, it should help a good bit.
It shouldn't be the LLO railways. Most of them(mainly the ones built by shavingfoam/btribble) have the torches spaced as far away as possible. It's all a very efficient design.
