NoLagg

Version: 1.90.4 | CB 1.7.2
Quote from lenis0012:NoLagg has not been updated since 1.7.10, for more info, check BKCommonLib
Description
NoLagg is made out of multiple completely separate components which you can enable and disable freely. Together they offer:
- Send chunks more gracefully with lowered network stress and reduced processing spikes Read more...
- Remove entities, resend chunks in case of chunk holes and clean up server memory Read more...
- Examine server tick rate performance with deep view into per-tick processes of the server Read more...
- Stop a large amount of items from spawning and spawn at a later time to avoid frozen clients Read more...
- Stack items with a configurable per-world radius Read more...
- Fix lighting errors that cause clients to recalculate lighting (and thus lag) Read more...
- Keep track of server performance such as entities, tick rate, memory and more Read more...
- Fix various bugs the server has (Patches component)
- Schedule autosaves and force data to be written to disk to prevent data loss on server crash (Saving component)
- Limit the amount of entities allowed to spawn per world or globally Read more...
- Watch events closely to warn when plugins execute main-thread methods from another thread Read more...
- Show a detailed message explaining the cause for a server freeze (lock) [read more]
- New TNT execution algortithm that is not only more efficient, but also avoids server freezes Read more...
Important
When first installing NoLagg, open up config.yml and disable components you do not need. This is very important, as some components may conflict with other plugins you use, or may not function on the type of demand you have. If you get a warning message [Severe] followed up with a stack trace in the log, this has to do with the main thread not having responded within 10 seconds. The warning is NOT an error and is no bug, and not a bug related to NoLagg. To disable this feature, disable 'threadlocknotifier' in the config.yml. This feature is mainly intended to notify you what plugin is causing the server to freeze, may it ever happen. It is used to debug plugins in general, as they may get stuck for whatever reason. If NoLagg DOES show up in there, it is a bug you should report.
FAQ
Separating into jar files
NoLagg consists of multiple components you can individually enable and disable. Reasons for not publishing it as a separate jar file for every component can be read here. Please don't ask to separate the components, I will just link you to here.
Spigot server
Not all components are needed when you use the Spigot server. The ItemStacker, ItemBuffer, Spawn Limiter, Thread Checker and Thread Lock Notifier components are not needed, since Spigot has it's own implementations to deal with that. If you still wish to use one of these components, you can, but it's best to disable the Spigot alternative then.
The other components (such as TNT, Chunks, Lighting, Common, etc.) are not implemented in Spigot (yet?) and offer additional functionality.
PTweaks
Since people keep asking about this, I went ahead and compared the two plugins. I am not going to discuss which is better in functionality, I'm just going to state which features overlap and which do not. Both plugins offer a TNT-lag solving solution, feel free to choose which solution you like better. (the solutions are different) Both plugins also offer a way to change when and how chunks are saved, NoLagg adds to this that you can configure when the server writes data to disk. PTweaks offers a way of showing used memory, NoLagg Monitor too with a bit more information. Again, preference. Chunk Persistence is something PTweaks offers and NoLagg does not. Reason I excluded it from NoLagg is that the implementation used up more processing power than that it solved (I did have this for a while). If you want to give it a try, PTweaks is your answer. Monster Limiter is incorporated in NoLagg as well but then for all entities, and more options. ChunkEdits is a tricky one: NoLagg chunks does something similar, with the difference being that it also changes at what rate chunks are sent, which is the main feature NoLagg chunks offers. In addition, the ability to increase the amount of threads running to process chunk packets and the re-using of packet raw data offers some benefits PTweaks does not offer.
Then there are a lot of other features NoLagg has and PTweaks does not, such as examining server tick rate, item stacker, item buffer, fixing lighting, cleaning up server memory, resending chunks, removing entities on command and others (see description).
In short: Both plugins offer some overlapping features, and you need to pay close attention to the configuration of PTweaks and NoLagg and disable things that conflict. Having two TNT explosion altering plugins is going to have strange results, for example. Compare the functionality, decide, and enable in NoLagg what you do not want in PTweaks, and vice versa.
NoLagg showing up in error stack traces
The examine component inserts various hooks into the server to gather measurements. Specifically, you will find that the following lines show up now and then. These hook classes do absolutely nothing when not examining and can not be the cause for any issues, unless the stack trace ends there (first line after the exception shows this stack trace)
- org.timedbukkit.craftbukkit.*
- com.bergerkiller.bukkit.common.internal.ChunkProviderServerHook
Video
Here is a video by BlueDevonMovies (lenis0012):
Metrics
This plugin sends server count statistics to MCStats.org. You can (globally) opt out in the PluginMetrics/config.yml file.







-
View User Profile
-
Send Message
Posted Jan 31, 2012@cvxx7q
Okay. But for me, its not a problem of loading chunk. Its some duplicated and removed chunk permanently ! . Stopping the server doesnt solve the problem .. :/
-
View User Profile
-
Send Message
Posted Jan 31, 2012@Barakuun
well if 1.58.8 is scrambling ur chunks its worth trying the beta, the only issue i have had is that the chunks wont load until i'm really close (like say flying, i have to land to make chunks render)
-
View User Profile
-
Send Message
Posted Jan 31, 2012@cvxx7q
For me : 2012-01-31 13:20:41 [INFO] This server is running CraftBukkit version git-Bukkit-1.1-R3-b1846jnks (MC: 1.1) (Implementing API version 1.1-R3) 2012-01-31 13:20:43 [INFO] [NoLagg] Loading NoLagg v1.58.8. 2012-01-31 13:20:44 [INFO] [NoLagg] NoLagg version 1.58.8 is enabled!
i dont know if i can take the 1.58.9 cuz i see beta ...
-
View User Profile
-
Send Message
Posted Jan 31, 2012@Barakuun
22:30:34 [INFO] This server is running CraftBukkit version git-Bukkit-1.1-R3-1-g690c3fb-b1848jnks (MC: 1.1) (Implementing API version 1.1-R4-SNAPSHOT)
22:30:35 [INFO] [NoLagg] Loading NoLagg v1.58.9.
22:30:35 [INFO] [NoLagg] NoLagg version 1.58.9 is enabled!
-
View User Profile
-
Send Message
Posted Jan 31, 2012@cvxx7q
and wich version of nolagg do you use?
-
View User Profile
-
Send Message
Posted Jan 31, 2012@Barakuun
im running 1.1-R4
-
View User Profile
-
Send Message
Posted Jan 31, 2012@cvxx7q
For me too. And the hols and duplocated chunk is not very cool :/
I got no new message of error since yesterday but i just want to know if there is a possibility that the duplicated/removed chunk can appear again ! And what do i need to do to correct this ! (sorry for my bad english)
-
View User Profile
-
Send Message
Posted Jan 31, 2012@Barakuun
thats new to me :S
-
View User Profile
-
Send Message
Posted Jan 31, 2012Hi guyz,
Since a few days i got some chunk duplicated or removed ! Holes in building, part of building duplicated a few blocks away !
I update my craftbukkit (recommanded 1.1 RC3) and the last Nolagg . I see thoses errors in my server :
-2012-01-30 19:17:35 [SEVERE] java.lang.NullPointerException 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressQueue.isAlive(ChunkCompressQueue.java:45) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.nextQueue(ChunkCompressionThread.java:27) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.run(ChunkCompressionThread.java:164) 2012-01-30 19:17:35 [SEVERE] java.lang.NullPointerException 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressQueue.isAlive(ChunkCompressQueue.java:45) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.nextQueue(ChunkCompressionThread.java:27) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.run(ChunkCompressionThread.java:164) 2012-01-30 19:17:35 [SEVERE] java.lang.NullPointerException 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressQueue.isAlive(ChunkCompressQueue.java:45) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.nextQueue(ChunkCompressionThread.java:27) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.run(ChunkCompressionThread.java:164) 2012-01-30 19:17:35 [SEVERE] java.lang.NullPointerException 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressQueue.isAlive(ChunkCompressQueue.java:45) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.nextQueue(ChunkCompressionThread.java:27) 2012-01-30 19:17:35 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.run(ChunkCompressionThread.java:164) 2012-01-30 19:17:45 [SEVERE] java.lang.NullPointerException 2012-01-30 19:17:45 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressQueue.isAlive(ChunkCompressQueue.java:45) 2012-01-30 19:17:45 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.nextQueue(ChunkCompressionThread.java:27) 2012-01-30 19:17:45 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.run(ChunkCompressionThread.java:164) 2012-01-30 19:17:45 [SEVERE] java.lang.NullPointerException 2012-01-30 19:17:45 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressQueue.isAlive(ChunkCompressQueue.java:45) 2012-01-30 19:17:45 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.nextQueue(ChunkCompressionThread.java:27) 2012-01-30 19:17:45 [SEVERE] at com.bergerkiller.bukkit.nolagg.sending.ChunkCompressionThread.run(ChunkCompressionThread.java:164) ======
With the update of the version of bukkit and Nolagg do you think the chunk are going to continue to duplicate/remove ?
IS there any way to solve this ? ====
-
View User Profile
-
Send Message
Posted Jan 31, 2012@bergerkiller
itsw been working fine for me on CB1.1-R3 ;) i will nag you if it breaks (of course) XD
-
View User Profile
-
Send Message
Posted Jan 31, 2012@predawnia Yup, I added support for the latest version. Someone told me that configuration of Orebfuscator is acting odd, but code-wise I couldn't spot anything wrong with it. (it does exactly the same as without NoLagg)
@Smiley43210 I'm not sure, you can try it though. (buffered chunk loader is removed, so no fear of having world corruption anymore)
-
View User Profile
-
Send Message
Posted Jan 30, 2012@bergerkiller
Is 1.58.9 compatible with CB1.1-R3?
-
View User Profile
-
Send Message
Posted Jan 30, 2012@bergerkiller
Is this version 1.58.9 now compatible with Orebfuscator? :)
-
View User Profile
-
Send Message
Posted Jan 30, 2012@bigscary It doesn't use ANY type of distance. It uses a pre-calculated algorithm which generated indices for chunks, and my custom chunk comparator quickly sorts all coordinates in one go. It is as optimized as possible, all I use is a subtract to sort them.
EDIT
I uploaded 1.58.9 official version. Buffered chunk loader has been removed in favour of stability. The TNT handling code got significantly improved; it can now detonate tnt faster without a tick rate loss. By scheduling the lighting updates in an async task it also reduces the processing time needed, and makes the chunk sending during explosions occur as it is supposed to be.
-
View User Profile
-
Send Message
Posted Jan 30, 2012@bergerkiller
Try manhattan distance instead of real distance? Not precise, but pretty close and no square root involved.
-
View User Profile
-
Send Message
Posted Jan 30, 2012So I had a bad experience. I see that the chunks directly ahead of me are sent to my client first which is kind of nice, since I don't have to worry about walking into the unknown. But the other chunks very close to me and in my field of view take much longer to load than they did in Vanilla, to the point that I'm often walking on a "path" of visible ground with nothingness on both sides. Please consider updating the chunk prioritization so that more nearby chunks in the field of view are loaded sooner.
Also, I got lots of stack traces trying to run the latest release build against 1.1 R1, so I uninstalled it for now. I'll give it another go when you guys release for 1.1 R3.
Thanks for the effort, I think it's a valuable project!
-
View User Profile
-
Send Message
Posted Jan 30, 2012@cvxx7q Yup I am going to remove chunk buffering. Improving the tnt detonation feature a bit more, it was too laggy as was needed.
EDIT
Um...just found out it spends 20 ms every tick just to calculate square roots. Wut?
-
View User Profile
-
Send Message
Posted Jan 30, 2012@NikoKun
probably test on a loopback, ;)
-
View User Profile
-
Send Message
Posted Jan 30, 2012I'm guessing I should wait for the next update, before using any chunk-related features on the latest RB 1846, or risk corruption?
Just checking. ^_^;
-
View User Profile
-
Send Message
Posted Jan 30, 2012@GarretSidzaka If you HAVE to run it on another thread (timers, threads, async), you will have to synchronize your collections. Synchronization works by adding a synchronized block around your code, pointing to the 'lock' object that is checked. You can look for more related articles if you wish.
Important: ALL functions that use this collection need to have themselves synchronized, otherwise it will not work. You can send me a PM on Bukkit(Dev) if you want to know more, as it is quite complicated.
Someone told me that beta 4 (GitHub) fixes the slow sending (again), but I am not sure of that. I will probably remove the buffered chunk loading to keep things simple, right now I face the fact that it is impossible to tell if a chunk can be re-used at all.