- bring fixes to 1.16
- Fix for all lighting where it only set sky lighting if not present, even if it was trying to set block lighting (unlikely to have caused issues as block lighting seems always to be present, but wrong nonetheless)
First noticed incident of operations ruining ChunkSections. Do not build and use this unless you're testing.
Rushed some of the changes, gotta sleep. Would be nice to get a review of this one from @mattbdev and @dordsor21
- Very basic implementation of the SideEffects system. Will definitely need fine tuning for it to be functional, but is not considered a priority in my opinion.
- Minor changes to the World interface and World implementations related to the SideEffects system. Shouldn't be the cause of any new bugs but be on the lookout.
- Included debug in BukkitImplLoader.java to assist contributors in understanding what needs to be implemented for the adapter to load properly.
Still very WIP but we're a few steps closer. So far, this is coming along better than I anticipated. Hopefully we can keep the momentum.
This commit will allow the branch to build properly but the plugin will not function properly due to the lack of a proper adapter implementation. Proceeding will require the implementation of the SideEffects system from upstream (865c3a24d2 (diff-8fd33296e427c87d0296ad7f3ccc050a)).
* Use a long to refer to the volume of a region, and rename the method to getVolume
* Fixed issues noted in review
* Forgot to floor
* Fixed review notes
* Can use a long here rather than BigDecimal
* Improve javadocs
* style
(cherry picked from commit 328030fd6281e58a4ea1d0cdd0a2e274da90afbe)
* Start work on lighting engine (does not build)
* Implement getLighting
* Setting, flushing light etc works. Getting light should be working..?
* Better queue/chunk handling
* Use correct location for lighting update
* Correct set location, remove debug
* cleanup a little
* Fix fixlight
* Apply to all versions for the numpties
* Remove lighting extent if not using
* Actually bitmask blocks when setting in chunks
* Initialise Maps and Dequeues with inital size
* format
* Documentation maybe
- Should ensure the server doesn't tick the chunksection while we're editing it
- Basically using the old issue with FAWE breaking block ticking by setting this to zero :)
- Revert back to default FAWE behaviour where placed blocks do not tick by default (until a restart, or another edit is done in the same chunksection without changing the block)
* Increase performance slightly when trimming.
If the chunk section is all one blocks (common in plotworlds) it'll be a nice little boost.
* Cache whether blocks are ticking or not. Greatly reduces the time required to create a palette
* collapse 5 lines to 2.
* Also apply to 14 and 15 for the numpties
* Cleanup
Actually ignore the exception - remove my debug print.
Remove double semi-colon
* Apparently 1.14/15 matter too still.
The main functionality of WorldguardFlag.java was ported to Worldguard.java. This *shouldn't* break functionality of either the Worldguard or WorldguardFlag features, but users should be cautious and provide prompt feedback if any unintended changes are found.
* Fix FAWE killing chunk ticks. Also allow ticking for set blocks.
* Reduce for-loop to being one loop in createPalette
* set the value in the set array and break so we don't continue onwards in the set's ordinal switch statement
- Re-read chunksections the first time they're "loaded" for an operation
- Reset the chunksection if there are block changes when setting blocks via reflection
- These are maybe gonna affect performance a bit? Idk. Seems to be alright for me
- These are maybe gonna make more issues? Yeah maybe, but I couldn't find any
This commit should properly synchronize the initialization of the adapter's ibdToStateOrdinal (the char array FAWE uses to convert NMS IBlockData objects to an internal ordinal for chunk operations) so references to this array do not push incorrect characters down the line.
Potentially fixes#373Fixes#363Fixes#332
I run a fork of paper which replaces the visibleChunks and updatingChunks
field for gc performance reasons - visibleChunks is updated via
cloning updatingChunks, and at high chunk counts this causes gc issues
due to the humongous allocation. Unfortunately the only solution is to
not clone the map - which is why the field is removed.
Instead of BukkitAdapter#getPlayerChunk using the visibleChunks field,
it now uses a MethodHandle for PlayerChunkMap#getVisibleChunk. This method is
present on spigot & paper (only protected on spigot - which is why reflection is required),
and I preserve the same thread-safety it provides in my fork - so this solution
will not break compatibility with craftbukkit, spigot, and paper.
Removed LoggingChangeSet since it wasn't functional and the majority of it was commented out.
Migrated a lot of RunnableVal implementations to Suppliers for improved readability and a very small speed improvement.
Changed Lock to subclass ReentrantLock since that is the only subclass DelegateLock should be using. The lock should also never be null so I added an annotation in the constructor.
I also removed some code and replaced it with PaperLib code to just clean up things a little bit.
Adapter updated to 1.15.2, mostly a clone of 1.15 / 1.15.1's adapter. I encountered no issues from this, but the field names for our reflections may need to be double-checked for accuracy in this Minecraft version.
This reverts commit 376f241b7dfbe3cf221adaae340661d0c9a5c81f.
Spigot bad. Also LP bad. This really shouldn't be necessary but it's
probably safer due to all the weird shit spigot and LP do.
(cherry picked from commit 68d48148d3df6e01815d05c462ba22498734fdc4)
- Removed duplicated dependencies
- Credited important contributors
- Updated website with an actual website
- Update DummyFawe internal version to 1.15.2
