Another thing, if doing things in a BlockEntity like every 20 ticks, try and offset that interval per block. (Same for entities work, offset interval work for every entity). This way all the blocks or all the entities do not all do the work in the exact same tick and cause a lag spike. Spread it out

Though it probably depends more on the exact use case to determine the best solution there. If uncertain, it is always a good idea to profile the game with a worst case setup and see where the bottleneck is with your implementation.

That isn't too bad to do iirc. The ticking block would do the check every 20 ticks or so and call the level's method to get entities within a range. This loops through existing entities in the chunks it intersects to see if in range. Do this as few times as needed and try to cache results when able.

Direct neighbors like 6 blocks, check the blockstates themselves. This will be fast enough since at 6 blocks, you won't see much difference. POI is better when scanning a radius of 10+ blocks or so. Scans that can be crippling to do. (just 10 square radius is 8000 blockpos to check already!)

This is the same system Villagers use to find nearby beds and workstations very quickly without bringing the game to a crawl. The POI system is designed for this so you do not need to iterate over every position looking for your block, which is slow to do as getChunk and getBlockState has overhead.

This also goes for goal classes as well for any goal-based mob or animal. Goals are loaded right away when entity spawns so they too need to use the entity's RandomSource to be worldgen safe. Vanilla bee's own goals have this bug which is why I mixin them to make them worldgen spawning safe.

To be clear, for many of the logspams we see, the slowness is on world load, server join, starting game, and any resource reloading . The more logging that happens, the more time the computer has to spend writing to an increasingly larger log file. The times start to add up.

We have seen too many mods that just fill the logs with mod compat recipe errors because they forgot to add this condition check. Ideally, everyone would know about this condition and keep the logs clean so only actual errors show up. Makes it easier for pack makers and players to find real problems

Also, logspamming is bad for performance. Really. Especially on Windows iirc. Just please try to keep the amount of logspam down for your mods. I beg of you

Doing this optimization for Bumblezone caused my Gazebuzz Cluster's layout generation is go from about 3 seconds to around 1.5 seconds. And that structure has a huge number of pieces to spawn and like 28 Jigsaw Blocks to check in every piece. Lots of Jigsaw match-up checks.

After optimizing the features in my Bumblezone mod some more, worldgen is even faster now!

The caves are pretty much the main thing taking up worldgen time now but I doubt I can make them faster without losing the cave shape I like.

#minecraft #mcdev #modding

Special thanks to Malte and ThatGravyBoat for working hard to make a NeoForge/Forge mitigation mod that will strip certain mod's sensitive config fields from ServerConfigs's sync to the client.

www.curseforge.com/minecraft/mc...
modrinth.com/mod/serverco...

#mcmods #minecraft #modding

This was one of the common complaints iirc back when the config overhaul was done back in like forge 1.14. The neo team is a bit divided on the two ideas we could do to make sure devs knows exactly what is synced and isn’t.

Still trying to figure out this bluesky stuff lol

Until then, please read the Javadoc for the config types when deciding which one to use.

Thank you.

Edit: This does also impact Forge all the way back to around 1.14 when the config system was redone to have synced SERVER configs. So be sure to double check your older mods as well.

or roll out your own storage/config of the data.

There is talk of possibly renaming the SERVER config to be more clear that it is synced unlike the other configs or rework it so syncing is a separate option from the config type.

There has been several mods found to have been accidentally exposing their private configurations to clients due to the syncing of SERVER configs. If you have been storing something private in SERVER configs, I urge you to swap to COMMON configs that are unsynced

Message from the picture:
Hello, for those of you who use SERVER configs, please note that these configs are synced from the server to clients when they client connects. This means that these configs are not suitable for storing private info such as passwords, API Keys, webhooks, tokens, or secrets

Character limits goes brrr. I’ll divide it up as replies then