The 4 missing structure set seed configs are strongholds, mineshafts,
buried treasure, and ancient cities.
Strongholds use a ring placement scheme which isn't random so they
utilize the world seed by default, this adds a config to override it
for just generating the ring positions.
Mineshafts and Buried Treasure structure sets are special cases
where the "salt" that can be defined for them via datapacks has 0
effect because the difference between the spacing and separation is 1
which is used as the upper bound in the random with salt. So the random
always returns the same int (0) so the salt has no effect. This adds
seeds/salts to the frequency reducer which has a similar effect.
Co-authored-by: William Blake Galbreath <blake.galbreath@gmail.com>
HashMapPalette uses an instance of CrudeIncrementalIntIdentityHashBiMap
internally. A Palette has a preset maximum size = 1 << bits.
CrudeIncrementalIntIdentityHashBiMap has an initial size but is
automatically resized. The CrudeIncrementalIntIdentityHashBiMap is created
with the maximum size in the constructor of HashMapPalette, with the aim
that it doesn't need to be resized anymore. However, there are two things
that I think Mojang hasn't considered here:
1) The CrudeIncrementalIntIdentityHashBiMap is resized, when its initial
size is reached and not the next time, when a further object is added.
2) HashMapPalette adds objects (unnecessarily) before checking if the
initial size of CrudeIncrementalIntIdentityHashBiMap is reached.
This means to actually avoid resize operations in
CrudeIncrementalIntIdentityHashBiMap, one has to add 2 to the initial size
or add 1 and check the size before adding objects. This commit implements
the second approach. Note that this isn't only an optimization but also
makes async reads of Palettes fail-safe. An async read while the
CrudeIncrementalIntIdentityHashBiMap is resized is fatal and can even lead
to corrupted data. This is also something that Anti-Xray is currently
relying on.
Mojang has flaws in their logic about chunks being concurrently
wrote to. So we constantly see crashes around multiple threads writing.
Additionally, java has optimized synchronization so well that its
in many times faster than trying to manage read write locks for low
contention situations.
And this is extremely a low contention situation.
If the server attempts to load a chunk generated by a newer version of
the game, immediately stop the server to prevent data corruption.
You can override this functionality at your own peril.
Removing the try catch and generally reducing ops should make it
faster on its own, however removing the try catch makes it
easier to inline due to code size
Due to a bug in 2e29af3df0
which was added all the way back in March of 2016, it was unknown (potentially not at the time)
that an entity might actually change the seed of the random object.
At some point, EntitySquid did start setting the seed. Due to this shared random, this caused
every entity to use a Random object with a predictable seed.
This has caused entities to potentially generate with the same UUID....
Over the years, servers have had entities disappear, but no sign of trouble
because CraftBukkit removed the log lines indicating that something was wrong.
We have fixed the root issue causing duplicate UUID's, however we now have chunk
files full of entities that have the same UUID as another entity!
When these chunks load, the 2nd entity will not be added to the world correctly.
If that chunk loads in a different order in the future, then it will reverse and the
missing one is now the one added to the world and not the other. This results in very
inconsistent entity behavior.
This change allows you to recover any duplicate entity by generating a new UUID for it.
This also lets you delete them instead if you don't want to risk having new entities added to
the world that you previously did not see.
But for those who are ok with leaving this inconsistent behavior, you may use WARN or NOTHING options.
It is recommended you regenerate the entities, as these were legit entities, and deserve your love.
Make it so a Treasure Map does not target a structure outside of the
World Border, where players are not even able to reach.
This also would help the case where a players close to the border, and one
that is outside happens to be closer, but unreachable, yet another reachable
one is in border that would of been missed.
RegionFileCache prior to this patch would close every single open region
file upon reaching a size of 256.
This patch modifies that behaviour so it closes the the least recently
used RegionFile.
The implementation uses a LinkedHashMap as an LRU cache (modified from HashMap).
The maximum size of the RegionFileCache is also made configurable.
Vanilla stores how long a chunk has been active on a server, and dynamically scales some
aspects of vanilla gameplay to this factor.
For people who want all chunks to be treated equally, you can chose a fixed value.
This allows to fine-tune vanilla gameplay.
== AT ==
public net.minecraft.server.level.ServerChunkCache mainThread
public net.minecraft.server.level.ServerLevel chunkSource
public org.bukkit.craftbukkit.inventory.CraftItemStack handle
public net.minecraft.server.level.ChunkMap getVisibleChunkIfPresent(J)Lnet/minecraft/server/level/ChunkHolder;
public net.minecraft.server.level.ServerChunkCache mainThreadProcessor
public net.minecraft.server.level.ServerChunkCache$MainThreadExecutor
public net.minecraft.world.level.chunk.LevelChunkSection states
The size of chunks in the region format is overdetermined. In particular their size on disk is indicated by both a sector count in the header, and actual size in the body.
If their size would overflow the header field (>= 255 sectors), it can just be read directly from the body instead.
This code/concept was adapted from MinecraftForge.
By: md_5 <git@md-5.net>
