Because we worked hard for these farms, and they don't ruin the economy. Unless you liked paying more.
Understanding how the game's mechanics work and controlling our environment is what Minecraft is all about. From lighting areas properly to playing custom games like Skyblock. Making farms is one facet of the game that people like myself enjoy. Not just for the drops, but the process of understanding the way things work, finding ways of manipulating the environment, and building solutions. If making and using farms is lazy, then anyone that has used an infinite Water source is lazy also, which includes pretty much everyone who has ever played.
I have a lot of sheep, and 20 different pens scattered around my reses, most with only 10 sheep in them. Again, I can fix this for myself pretty easily, I'm just worried that this might be something common for everyone using basic pens that might be causing server lag. I'll try breaking the fence when I get home today, but I do know that jumping into that pile will spread them back out.
I don't agree, I agree with people who have built the farms based on the proper operation of a minecraft server, even if they can afk on them. The server admin has already promised to maintain game mechanics to the best of his ability. That said, I can also understand the this problem is caused by a really broken feature in the game and is beyond the scope of a server admin to correct at the moment. It would be different if there was a fix available or a plugin to take care of it. Hopefully, that will become available, but there is no solution in reach at the moment. On the other topic I was reading the path finding and goal finding portions of the craftbukkit code over the past few days, and I have some suggestions on how to debug for the sheep issue, but I am still looking at a pretty steep learning curve and can't find all of the functions that pertain to the process yet. From what you are saying, jumping into the pile causes an event that redirects the behavior. It leads me to believe that the problem is in the default path/goal and always leads to getting stuck in that corner, but you can't tell it's happening in a 1x1 pen. Still looking,... . . . . easier said than done.
*sigh* So judgmental, brighten up. Not sure why, but I feel like you have a grudge against the well off players... Oops, how did that get there? We aren't a pick and choose server. Everyone is equal to others in every way possible. That's probably the best part of this server.
!!!!!! I found a bug. I do believe it is THE bug we are looking for. I will look into how to best go about submitting the report, but first I will give the fix. In craftbukkit/src/main/java/net/minecraft/server/EntityLiving.java on line 1487 there is a syntax error that prevents the logic from doing what is intended: this is where the problem is: if (entity instanceof EntityLiving && !(this instanceof EntityPlayer) && this.ticksLived % 2 == 0) { 'this.ticksLived' is the wrong request, it should be 'entity.ticksLived'. this change should give the behavior in the comments, I think that there should be an event call to the bukkit API so that plugins can override default behavior, but that is beside the point. Currently the entity.collide method is called, which tries to push all entities colliding with the current entity one space away. With the code the way it is, with 100 sheep in the same one block pen, they will each detect 99 collisions, then they will try to move all or none of them, without any result or an listener or event handler being triggered. The correction will change so, with 100 sheep in the same on block pen, each sheep will each detect 99 collision, then they will each try to move about half of them, without any result or an listener or event handler being triggered. I am sure that there are better ways to handle this in the base code, or there should be an event thrown so that plugins can be written to change the default behavior if desired. Seeing as how I am unknown to the Craftbukkit team and have never submitted to them, I will stick with the more basic change request, and perhaps then, I can talk to someone about how it really should be rewritten. God! that is a lot of code! It took me a whole week to find this one bug. I was debugging code in my dreams.
aikar you are awesome!! and we thank you for the mass amount of time you spend helping make EMC a better place to play!! looking forward to getting more then 10fps (without optifine) on my res again
I am stuck, it's the stupidest thing, but I don't really understand github. If anyone is familiar with it and wants to help me submit this bug, I would be really love that. Otherwise, I am sure I will figure it out eventually, but i'm taking a break for tonight.
It's not a bug, I'm the one that wrote that code actually. I see what your trying to say but It won't change anything. The end result is the same. If 100 sheep are in a pin, only half of them are going to trigger collisions with the current code. The this.ticksLived % 2 is a way I divvy up entity workload over ticks, so on single game server tick, its not EVERY entity checking for collisions, but half. Then those half chosen, are allowed to collide to every other entity they see. Theres also no reason for an event here as the gameplay impact is not noticable to the player. The root corner glitch is unrelated, as it happens in vanilla too, and this code your looking at is something I added to Spigot which CB copied. Though they copied it a bit ineffeciently, running the is player and ticksLived checks every iteration, I wrote it better back in the days: https://github.com/aikar/EMC-CraftB.../net/minecraft/server/EntityLiving.java#L1396
Your code WAS better, lol, it's cool to realize I am working on code you wrote. Yeah, they really didn't go out of their way to improve on anything. So, as not to beat a dead horse, I think I will move along to another area of possible gain, which might have more potential. It stands to reason that if an animal can't even make a path to the simplest of goals, then it actually can't even move and doesn't need to bother with registering collisions. For example, if no event is triggered and it's not looking for grass, a sheep will 'wander', but if it fails at wander, it should easily be excluded from processing collisions with other non player entities, because they must be trapped in the same pen to be in a state of collision. This would drop 5000 collision events per tick in the example of our 100 sheep in a 1x1 pen. None of those sheep could move anyway. I think this should improve mob farm lag as well. I don't think I can write code this complex for this project yet. Another less complex way to go about it, would be to do a sanity check on the size of the: this.world.getEntities list, if it returns 50 entities, then we know something is up. Maybe only try to collide with a maximum number, or randomly select a percentage of that list to make collisions with. If you limited it to 10% over the first 5, it would still only take 10 ticks for a huge list of mobs to disperse when released. This promises to reduce our 100 sheep in a 1x1 pen to more like 1500 collision events. It's also a lot easier code to write and adjust as needed. This isn't exactly the same behavior as vanilla, because in single player, a gaint pile of mobs explodes in every direction when they are released. My argument is that currently, it doesn't work that way due to the need for mob limits and the lag that blows up gameplay during that type of even on a multiplayer server. I don't think it's a bad tradeoff. In normal gameplay, huge lists of entity to entity collisions don't seem to come into play, so I think the change wouldn't even be noticed most of the time. Thanks for taking the time to read and respond to my suggestions, I really am just trying to help.
This is actually what I was about to work on, is figuring a way to furthur improve the collision code, however THIS specific section is not the issue, but more so the move calls. This is going to require deeper study, sort of like you said, if it cant move, pause collisions/attempts to move. But this wont be no easy task. the move code is the heaviest piece of entity ticking, which is why I wrote the feature that reduces ticking by 95% if no player is close. SMP7's lag is not entity ticking related though, its something with the Scheduler which means Empire specific plugin code that for some reason the timings system is not picking it up properly.
I've been lagging really bad in the nether wastelands (smp1). #LaggyGhastRuinedMyBridge #SwimmingInLava #RiskyBusiness #NoFun
