this could be observed by pressing E and immediately clicking a chest, which, if timed correctly, would lead to the chest lid closing, but the inventory being opened anyway.
we don't need to check this on a bit by bit level if the integers are the same.
this saves 2-3 microseconds per packet on my machine, which doesn't sound like much, but it adds up when there are lots of players.
closes#5154
this hack sends only the bare essential data to create the tiles in LevelChunkPacket,
and then separately sending the full tile data using BlockActorDataPacket afterwards.
This is necessary because the client doesn't handle items correctly in NBT when chunks are sent without using the SubChunkRequest system.
In 4.6 this is observed with incorrect items shown in item frames; in 5.0 it's seen with items simply not showing up at all (difference due to modernization of the serialization format in 5.0).
this allows stuff like smithing tables to work without needing any extra hacks.
Implementing enchanting or anvils would require some extra work, but I don't plan to implement those under the legacy transaction system anyway.
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.
I previously avoided this due to being unsure of the effects; however, it's clear that we already use typed properties on Threaded things in other places anyway, and the only known issues are with uninit properties, and arrays.
the current data management system uses case-insensitive names, so we can't allow different players with the same name in different cases to join, or we will have duplication exploits.
This typically only applies to offline servers, since Xbox Live doesn't permit reuse of a username, same case or otherwise.
closes#4965
