Having an incongruency between the server render distance and the client render distance appears to cause issues, and I have not been able to encounter such a crash.
* Implement downstream PROXY protocol support
* Clarify the configuration version updating procedure
* Bump netty-resolver-dns to 4.1.56.Final
* Update Netty to .56
* Don't increase jar size by 2MB
Co-authored-by: Camotoy <20743703+Camotoy@users.noreply.github.com>
Previously, we wouldn't send the time if the server was sending the same time with doDaylightCycle on. However, this isn't vanilla behavior (for Bedrock nor Java) and can occasionally cause irregularities. The time is now always sent to Bedrock clients, and a daylightCycle field is added to GeyserSession to keep track of the doDaylightCycle gamerule we need to send to Bedrock. Removing the map we used to store the time may also improve memory usage since this was never cleaned up.
* Allow /help to work even if command suggestions are disabled
This sends a minimal available commands packet to permit /help sending to the server.
* Fix whitespace
* Just send an empty packet
* Change variable name
The ominous banner is a separate banner type in Bedrock. If we detect the ominous banner pattern, then we set the ominous banner type in NBT. This process is also checked vice-versa, allowing the ominous banner to be pulled from the Bedrock creative menu.
* Fix boat movement on land
1.16.100 appears to now take advantage of two newer entity metadata properties, IS_BUOYANT and BUOYANCY_DATA. Without the former, moving on land will not work properly. With the former and without the latter, moving in water no longer works.
* Use offset kind of
Fixes#1496 to the best of my knowledge. Any issue regarding the spawnpoint being off in terms of radius is up to the server at this point - would not be an us situation here.
Bedrock cuts off the last 3 digits consistently every time, meaning that the keepalive returned from bedrock is never fully accurate. However, if we multiply the value by 1000, then divide by 1000 when sending back to java, the proper value is returned.
* Change version in query to use a more informative string
* Fix removal of string
* Cleaner implementation of version
* Fix build
* Make more explicit what we're replacing
Co-authored-by: Camotoy <20743703+DoctorMacc@users.noreply.github.com>
