see #5057
jury is out on whether or not this should override difficulty on preexisting worlds, but it's non-controversial that it should apply at least to newly generated worlds.
fixes#5021 and probably a bunch of other inventory related glitches
When the server initiates a window close, it does so by sending a ContainerClose to the client, which causes the
client to behave as if it initiated the close itself. It responds by sending a ContainerClose back to the server,
which the server is then expected to respond to.
Sending the client a new window before sending this final response creates buggy behaviour on the client, which
is problematic when switching windows. Therefore, we defer sending any new windows until after the client
responds to our window close instruction, so that we can complete the window handshake correctly.
This is a pile of complicated garbage that only exists because Mojang overengineered the process of opening and
closing inventory windows.
closes#5032
this is evidently not an ideal solution, and something more dynamic would be preferred so that we don't have to manually register an item for every permutation.
This required the following:
- A generation task (taskA) to already be running for any chunk (chunkA)
- A chunk (chunkB) is requested for generation, and the task (taskB) to do the generation
is commenced immediately
- chunkB generation promise is aborted (e.g. due to chunk unload) and
taskB is orphaned
- chunkB is subsequently re-requested, but ends up in the generation
queue because taskB is still running
- taskA completes and drains the generation queue
- chunkB attempts to be populated a second time, but taskB has not yet
been collected, resulting in an assertion failure.
This bug has been appearing intermittently ever since PM 4.0 release.
For most users there is no obvious effect since production servers don't
have assertions enabled; however, it's unclear what kind of weird side
effects this bug may have had.
