Minecraft has a lot of different methods between private and public to determine if structures can be placed. We cannot possibly cover all of them whilst also ensuring issues do not arise with generic "true"s
* fix: some improvements to GET chunk writing
- ensure levelChunk is loaded before giving to copy GET - this is not necessarily guaranteed to be nonnull if two edits overlap. Whilst not advised, such an easy failure should not occur when two edits collide
* Prevent writing chunk sections when FAWE is also sending packets for a chunk and vice versa
- alter IntPair hashcode to be more often unique
- Utilise ConcurrentHashMap for free synchronisation
* Minor comment changes
* Use one-per-world-instance FaweBukkitWorld to store world chunk map
* Add a BiomeCategories API (#2338)
* Add a BiomeCategories API
* licenses
* Use a supplier to retain the lazy-load & dynamicness of the existing system, but still retaining the inversion of control that this PR was intended to provide
* Minor fawe adapter cleanup
* Actually add the new files?
* Fixes
---------
Co-authored-by: Maddy Miller <mnmiller1@me.com>
* fix: improve biome setting to avoid writing directly to chunk
- Removes possibility of writing to the LevelChunkSection biomes PalettedContainer whilst it is being read for sending packets
- I believe this occured mostly on clipboard operations where blocks are written before biomes, so chunks are being sent whilst writing biomes
- This would explain why the error reported in the below issue (and others) is/was so rare
- Of course I could be completely wrong about all of this, but given the line in LevelChunkSection#write that the error seems to consistently occur on is when writing biomes to the packet, and that the only place I can find in FAWE where we write to a "live" PalettedContainer is for biomes, I am reasonably confident that this is the cause
- Should address #2729
* Remove self-refraction-check
- remove ChunkHolder locking concept as this is no longer needed
- previously we obtained the copy from chunk GET on finalize, meaning the copy could be replaced by a "newer" one (bad)
- work around this issue by introducing concept of "unique" keys to map chunk GET copies to
- correctly handle resetting of various chunk-related classes to actually allow pooling to work
- remove chunks as they are submitted when flushing a SingleThreadQueueExtenting
