2024 FLASH SALE IS LIVE! We’re back with another limited-time flash sale!For the next 7 days, enjoy a 25% OFF discount on all our resources! Hurry up! This offer won’t last long!   BETTER DEALS ARE HERE! We’ve officially added RaytraceAntiXray to our resource site—at a better price than anywhere else! Just $16.99 USD compared to the $19.99 USD price on BuiltByBit, SpigotMC, and Polymart! and only $12.75 USD with the 25% flash sale! Don’t miss your chance to get it cheaper on our site!   MILESTONES & FUTURE PLANS We’re excited to announce that we’ve hit some major milestones!200 customers for RaytraceAntiXray and 600 customers for ImanitySpigot3!Thank you all for your incredible support—we’re committed to bringing you even better products! RaytraceAntiXray: We’re in a stable version now, tested with large player bases.What’s coming next? Support for versions 1.9, 1.10, 1.11, 1.13, 1.14, 1.15 A fully developed in-game user interface Improved plugin compatibilityWe’re targeting a 1.0 release as soon as next month, but definitely by the end of the year! ImanitySpigot3: We’re working on major updates—especially for Factions—and a complete product line restructuring.Details are still under wraps, but exciting things are on the way. Stay tuned!   That’s all for today! Make sure to grab your special offer and enjoy your experience!

ayo Spookers!

Welcome Everyone! It has been a while since ImanitySpigot3 first announced. Today we are happy to introduce that ImanitySpigot3 is fully prepared and now we are here to release the first experimental version! Please read this page completely before you start using ImanitySpigot3 experimental version. This page contains everything to help you get started and what you must know.   > ImanitySpigot 3 So here, let us introduce you what exactly is ImanitySpigot3ImanitySpigot3 is a completely recoded from scratch version of ImanitySpigot, It contains amazing new features and clean codes compared to old ImanitySpigot There is 5 Main features that makes ImanitySpigot3 a lot different then any other spigot in existen: The only Asynchronous Chunk Generation Spigot fork in 1.8 Natively Supported Java 8 - Java 16 Well Designed Knockback System That covered Simple usage to Advanced Designers Much More Extensive APIs made your Developer Life much easier DOCS Advanced World Modification System, Modify your world without TerrainControl These are main features, Of course that means there are a LOT more features! wanted to look more details? check HERE   > Why Recode from scratch? ImanitySpigot Project has been started since June 2019, During these period, New developers joined, Old developers left. And at that moment the team wasn't very experienced, Code was ugly, No proper patch management. So We believe recoding it is better choice.   > How do I start using the Experimental version? There are some changes you will need to notice first before updating. APIs are revamped. If your server or plugins somehow used the API from ImanitySpigot3, please check our API documentation and made your plugin compatible first. Configurations are also being revamped, You will need to re-configure Imanity Related Configurations before using it. All required files will be stored in the imanity folder. This version called Experimental version, which means it's NOT stable release. We are NOT responsible if there is any issue occurs on your production server. So we don't recommend you to try it on your production server unless you think it's fine.   1. Get your ImanitySpigot3 License ImanitySpigot3 License is not shared with old ImanitySpigot. To get a license, first you need a license on old ImanitySpigot. If you do, you can directly sending a Private Message to @Raisensu#6662, and use the command !transform ispigot3, and the Bot should create a license based on your old license.   2. Get Rancha (New version of launcher) JAR Rancha is a newly designed launcher of ImanitySpigot3, to get the JAR, you can directly sending a Private Message to @Raisensu#6662, and use the command !dl ispigot3 and you should be able to download the JAR. > Other Changes There is quite a lot of changes beside ImanitySpigot3 it self. First if you didn't notice, Yes, we now have a brand new Website! In the future we will be using forums to announce Updates, Changes, Addons, Knockback profiles, and More resources! You can also register an account here to ask questions or provide Suggestions! Second, we now have a documentation site that included most of the knowledge you may want to know about Imanity or ImanitySpigot3! Check out HERE Third, WE NO LONGER accept anything related to Bug Reports, Crash Reports, or Feature Request for ImanitySpigot3 in Ticket! From now on every of our product will have it own Github Issue Tracker. If you have ANY bug, crash or feature request for ImanitySpigot3 you can report it HERE   That's basically it today! We apologize for for long period of update time, But thanks to the time, We are able to provide you the new and the best update possible!   @LeeGod, @Whizyyy - Developer of ImanitySpigot3@LeeGod,@Whizyyy, @bEaN - Documentation@bEaN - System Management@thirsty - Knockback Profile Designs@Kydaix, @Blob, @Ghast, @Mixha, @SnailGaming - Internal Tester Team

xd

Introduction The ImanitySpigot Asynchronous Chunk Load and Generation system is originally inspired by the Paper Team’s 1.13 Patch,You can see their patch here. But to port this patch into a 1.8 Spigot... It’s difficult   The Old Algorithm (Minecraft 1.12 Release, the last version using this algorithm) The algorithm has separated into 2 stages 1. Terrain Terrain Generation will generate the undulation, caves, structures (such as village the mountain)’s foundation,position managing, and biomes During this stage, Most of the work is done in a ChunkSnapshotwhich is a snapshot that contains 16x16x256 blocks and Terrain generator will only be accessible to ChunkSnapshotwhich means this part is overall thread-safety   2. Population After we have the terrain and foundations, In this stage it will start populating trees, water lakes, ores, and blocks of all existing structures that are calculated from the last stage, etc And this stage differs from how the block placing  Since Mojang assume that the block of population stage can be placed across many chunksMinecraft will push chunks that have terrain generated into the Loaded Chunk List And do the population work based on chunk location So basically that means each block placing action will need to lookup for the chunk and it can also generate new chunks     Minecraft 1.13(Minecraft 1.13 Release, the last version using this algorithm)   After 1.13 released, Minecraft also kind of redesigned the system, they combined All the Stages into a bundle of Chunk FactoryWithin this factory, It stores all work in progress chunks in a separate list, And each chunk will have a stage markBefore chunk run the stageThe Factory will check if this stage requires any external chunks And try to process external chunk stages until it's ready and put into a cache chunk bundles for the stage to process Finally, when chunk has finished finalized stage, It will be pushed into Loaded Chunk List   You should be able to tell the difference from here Minecraft 1.13 will handle the cache of chunks in a separate list for the population stageAnd chunks wouldn't be pushed into Loaded Chunk List before all stages completedWhich is inaccessible before full chunk completed. which makes it much simpler to move the work off from Main Thread     The Solution of ImanitySpigot (oh! I have an idea!)   So to achieve Asynchronous chunk generationWe also need to have our caching system and let the population stage works within our cache Here is a simple chart ans some explaination on how our system works: (This system is 80% inspired by PaperSpigot & 1.13 Minecraft with minor tweaks) This is a very simplified chart to let everyone understand the system easilyBut there is much more going around itCurrent there are 5 stages:1. Empty - The Stage without any process available, This stage will not be saved2. Terrain - The Stage that chunk terrain generated3. Populated - The Stage that population is completed4. Lighting - The Stage that lighting is populatedBut as we making it we are thinking Is it necessary to have it within this system?After sometimes of analyzing, We think that this feature is useful if you want an accurate as it's not accessible before all completedBut also it could slowdown chunk generate speed, so we leave it toggle-able5. Spawn Creatures - The Stage that creature being summonedIf Lighting wasn't populated, this stage wouldn't be called.6. Finalized - The Stage that the chunk has been marked as ready But there is a downside for the systemIf you have looked at the chart carefully, You should notice that getChunkAt Vanilla will block the thread until the async process finished, It is for thread safety sake since normally vanilla getChunkAt expected to getChunkAt Immediately without a callback, And to keep chunk generate safe, All we can do is to block the thread and finish work on the worker, which means the getChunkAt Immediately function is generally much slower then single thread handlingSo If there are many calls to the getChunkAt Immediately function, It could cause potential diff spikes!We also notice the issue, So we will also change the Minecraft structure to fit the callback getChunk, But most of the plugin probably doesn't care about that! So we will also need to create some debug system to log if any getChunkAt Immediately were called so people can recognize what getChunkAt Immediately is unintentional and can cause lag spikesAnd we will also need to create a guide on how to optimize server around async chunk... This feature is getting more complex now :^) OK, While we understood what and how to achieve it, we begin to work on the systemBut we were soon faced with the most difficult problem of all...   I Hate Minecraft (Why?! Minecraft?!)   We quickly notice that something seems to be wrong... Originally we think that basically, we build the system and it could go wild, but afterward, we notice Minecraft’s Block Populator system Remember that what I say at introducing the Population Stage in the Old algorithm? Yep, Even tho we finished the caching system we also need to make the population stage works with our caching system, And Minecraft literature contains a million of classes sharing the same code bases that aren’t friendly to our async structure After noticing it, we quickly realize how time-consuming this will beand why there still isn’t any async chunk generation spigot fork until this day... But after all... We didn’t give up we took all of our time to fix this 7-year-old thing to fit our structure The process is extremely painful, with Hours of repetitive work and sometimes a weird error will appear and you don't even know why it occurs... Definitely not a fun process at all :^)   Result (This part is kinda for developers) In the end, We still achieved it in a good way!By creating new classes for each populator of the original Minecraft code base,We were able to be compatible with most of the plugin if they do NMS thing to those classes,But it doesn't mean the Asynchronous Chunk Generation system will work on Custom World Generator Plugins   IT IS IMPOSSIBLE TO MADE PLUGINS WORK AS ASYNCHRONOUS WITHOUT MODIFYING PLUGIN IT SELF   Since most of plugins shares similar idea as Minecraft Generation algorithm, We cannot expect that those plugins can work with our way And unlike Spigot or PaperSpigot, most of the plugins on Spigot forums or MC-Market forums wouldn't want to collaborate with us and just modify code their selfSo it's either we opening pull requests to their repository (But more likely they will reject us) Or we fork them, tho both isn't an easy task too :^)So if Custom World Generator Plugin is playing a big role in your server this system is not for you, but remember that ImanitySpigot still works with those plugins, just Asynchronous Chunk Generation will not be applied. Even tho this structure works correctly as we expected, There is still a lot of small issues around it, If you ever seen Minecraft codes, you know that Minecraft likes to share things, A lot of fields were shared between multiple classes/objects in some unnecessary way, makes it very not thread-safe when it comes to multi-threading. These minor things is actually annoying to say the least, It is very easy to be ignored, sometimes you didn't even modify it, and it just become the source of errors...       Overview (That sounds like a complex feature! But what does it means for the Spigot overall?) Here is an example video, this is a comparison in between async chunk enabled & disabled As you can see from the video, while async chunk enabled, the TPS still staying above 19.85TPSwhile async chunk disabled, when you just fly out 10 chunks, the TPS flashing number freezes, in this case TPS in siderbar isn't even accurate, since Minecraft doesn't have time to calculate TPS since it's just lagged out It is normally for both to see void, since LunarClient 8x is really fast, none of them can follow the speed of itTho the generation speed on the left is significant faster since async chunk generator wouldn't get slowdown by Main Thread worksBut generation speed aside, For the performance it self, Async Chunk basically dominated non-async chunkThese test are done without pre-loaded chunks, view distance is 10. localhost. Summary   Benefit of Asynchronous Chunk Generation:- Zero Lag spike while loading chunk is possible- Loading chunk is overall faster compare to disabled- More flexible feature for customers to utilize! Downside of Asynchronous Chunk Generation:- Much more hardware consuming, Requires both more RAM and Better Processor- tho "Zero Lag spike while loading chunk is possible" but customer also need to know how to utilize it, otherwise it's could done reverse effect What kind of server might find it useful?- Factions- 2B2T kind of server- Or any kind of server that need a lot of chunk generationsAlright! That's basically what I have for you today!I hope you enjoyed this devlog and probably received something from it!