This assumes that the region is properly garbage-collected and packed, but if the file contains uncollected garbage this may not be the case, resulting in a region larger than a gigabyte.
Seed is immutable information about the world, like its generator type, generator options, name, etc. We don't allow changing any of those things, so why the fuck would we allow changing the seed? This makes no sense at all.
I'm removing this because a) its existence makes no sense, and b) it will not produce the behaviour expected from such a function (what even is the expected behaviour???)
It checks for the existence of (and creates) the world directory if it doesn't exist. But what sense does this make when the world obviously doesn't exist in this case and must be generated first?
This is problematic because child level providers can forget to override the provider name of their parents, and then override them by error. Instead, they should be used in a mapping fashion to make sure they are unique and not inherited.
Also, the old method did not permit registering multiple aliases for the same provider. This now makes that possible.
In the future, McRegion and PMAnvil will become deprecated legacy formats which we won't support for writing anymore. However, this brings complications because Anvil (which would not be deprecated) would be sandwiched between its deprecated base (McRegion) and its deprecated child (PMAnvil), complicating the implementation (particularly for PMAnvil).
This abstracts away the generic Region-based world functionality into a separate class, making McRegion, Anvil and PMAnvil all inherit from it directly. Since only the chunk formats are different, they are more accurately siblings rather than parent-child (although Anvil and PMAnvil are cousins, ish).
The cause of this was the flow decay of falling water changing, but the flow decay is ignored for falling water. This caused the block to be repeatedly set to itself, triggering local block updates, causing the disease to spread in large falling water bodies and cause immense amounts of lag.
this parameter was previously used to send blocks with a different set of flags, immediately, to players. However, the flags have been demonstrated useless and the direct sending is pointless now since packets are buffered now per session, so we might as well take advantage of the batched block update sending.
These flags are not intended for network use, instead they are supposed to be used internally by the game. For network, we only need to care about the 0x02 flag (send to players) because that's necessary for the client to render the block.
readline on Windows causes issues with console output corruption. Additionally, PM readline impl is extremely buggy and probably ought to be removed. However, have a hotfix for now.
