- Properly ensures we don't try to submit chunks that already have a monitor (prevent the FAWE-freezing)
- We can't detect if "no" threads hold the chunk's monitor, but equally that would also be kinda very bad practice.
- We don't want to flush if we're setting from the main thread, as that's going to be another plugin doing it
- It's better to have a concurrent error thrown than use a concurrent set, so concurrency issues can actually be fixed rather than handled unsafely
- Only send chunk packets up to once a tick (it really doesn't use any memory to cache IntPairs).
- With enough chunks waiting to write to history, it's possible to fill the secondary fork pool up with locked threads, and thus prevent any threads from actually writing their history.
- Have both sponge and fast r/w available but default to "fast"
- Correctly "offset" entities in the schematic, and add a legacy mode for loading old FAWE schematics with entities required.
- Lazily reading means it's read in order of appearance in the inputstream so we need to read schematic version first (skip past everything) and then reset the stream. Fixes#740
- Add an FAWEVersion to the metadata
- Correctly actually return a BlockArrayClipboard when required. Fixes#454
* Full support for 3D biomes
Since we're only supporting 1.15+ there's no need to try anything other than compatibility
* this is not part of the PR
* Clipboards should still always be y 0 for biomes
(this "bug" has existed for ages)
* Several fixes to actual, probable and possible synchronocity issues
- Ensure that all edits are queued onto the same AsyncNotifyQueue by actually delegating to the parent player in PlayerProxy
- Ensure that the order editsessions are being remembered on the LocalSession is being respected by using a fair ReentrentLock
- Ensure a chunk cannot be called when an update is being called
* Don't add locks to GetBlocks
Synchronising on the LocalSession ends up being dangerous as it's a craftbukkit thread, leading to blocking issues if something goes wrong in an edit, made worse by the fact craftbukkit threads like to interfere with each other sometimes, and also cause OOMs and hanging when there are too many of them.
* Several fixes to actual, probable and possible synchronocity issues
- Ensure that all edits are queued onto the same AsyncNotifyQueue by actually delegating to the parent player in PlayerProxy
- Ensure that the order editsessions are being remembered on the LocalSession is being respected by using a fair ReentrentLock
- Ensure a chunk cannot be called when an update is being called
* Don't add locks to GetBlocks
Synchronising on the LocalSession ends up being dangerous as it's a craftbukkit thread, leading to blocking issues if something goes wrong in an edit, made worse by the fact craftbukkit threads like to interfere with each other sometimes, and also cause OOMs and hanging when there are too many of them.
* begin allowing "post processing" of chunks
- restores legacy capability to continue saving edits in the background after sending the chunks
- speeds up the edit clientside
- nail in the coffin of the terrible and staticly coded coreedit
- We should totally make IronGolem work so Core* is no longer used by anyone
* begin allowing background history saving
* Handle post processors in queues properly
* Use futures for postprocessing so we're not waiting for them needlessly
* better use of closed boolean
* Reword
* Attempt to recover from incorrectly-extensioned schematic reads
- Should help avoid #605 (I'm assuming this is the issue)
- Possible issues with the InputStream being closed/pre-read or so? Thoughts:?
* more verbose checking in the first place
* accessing clipboards should not be synchronized to LocalSession
I believe this may be the issue causing thread locks when wrapping new players. If we're attempting to run a synchronised method within the LocalSesison when initialising it, it may go wrong..?
* nullcheck within synchronisation
* Allow parallelisation of masks
Increasing performance improvement with increased masking complexity and edit size.
* Address comments
- Rename Mask#clone to Mask#copy
- Rename Mask2D#copy to Mask2D#copy2D
- Correct formatting
* cx -> centerX
* Make various operations relying on a single SingleThreadQueueExtent instance (mainly brushes) thread safe
dordsor21
