* End crystal placement
* End crystal placement - fixed error and added some comments
* Removed unused includes
* Update src/Items/ItemEndCrystal.h
Co-authored-by: Alexander Harkness <me@bearbin.net>
* End Crystal placement, early-return pattern enforcement
* End crystal Item finish?
* Small changes
Fixed a crashbug in ender crystal destruction.
According to vanilla 1.16 testing, end crystals don't place if any entity intersects the box, not just other end crystals.
Check return value of SpawnEnderCrystal.
Add header in SeeMake.
Cafe Stile Redux.
* The stylechecker relies on CMakeLists
* There is another
Co-authored-by: Alexander Harkness <me@bearbin.net>
Co-authored-by: Tiger Wang <ziwei.tiger@outlook.com>
First one: add missing exception handler in ProcessProtocolIn
Second: remove faulty logic dealing with incomplete packets.
`a_Data = a_Data.substr(m_Buffer.GetUsedSpace() - m_Buffer.GetReadableSpace());`
was incorrect; it attempted to apply a length derived from m_Buffer to an unrelated a_Data. Its purpose was to give cProtocol the data the client sent, minus initial handshake bytes. However, we can use the knowledge that during initial handshake, there is no encryption and every byte can be written unchanged into m_Buffer, to just call cProtocol with a data length of zero. This will cause it to parse from m_Buffer - wherein we have already written everything the client sent - with no a_Data manipulation needed.
Additionally, removed UnsupportedButPingableProtocolException (use of exception as control flow) and encode this state as m_Protocol == nullptr, id est "no protocol for this unsupported version", which is then handled by cMultiVersionProtocol itself.
+ A cPlayer, once created, has a strong pointer to the cClientHandle. The player ticks the clienthandle. If he finds the handle destroyed, he destroys himself in turn. Nothing else can kill the player.
* The client handle has a pointer to the player. Once a player is created, the client handle never outlasts the player, nor does it manage the player's lifetime. The pointer is always safe to use after FinishAuthenticate, which is also the point where cProtocol is put into the Game state that allows player manipulation.
+ Entities are once again never lost by constructing a chunk when they try to move into one that doesn't exist.
* Fixed a forgotten Super invocation in cPlayer::OnRemoveFromWorld.
* Fix SaveToDisk usage in destructor by only saving things cPlayer owns, instead of accessing cWorld.
* Fix AppVeyor IA32 builds
> The default target platform name (architecture) is that of the host and is provided in the CMAKE_VS_PLATFORM_NAME_DEFAULT variable.
AppVeyor uses AMD64. Oops.
* del cmakecache
* -
* +
- Removed RemoveFromAllChunks. On destruction cWorld::RemovePlayer calls RemoveClientFromChunks already, and there's no need to manually clear the chunk lists.
Loaded entities are directly moved into the chunk data, instead of having to go through cWorld, as if they were just spawned. This avoid dirtying the chunk.
+ Add type-safe container for states
* Split registry Blocks into BlockTypes, BlockStates so the block types enumeration can be #included without too much penalty
* Ensure Registry uses type-safe container
* Replace DoWithNearestPlayer with bounding box search (avoid iterating through all players in world).
* Do line-of-sight checks from eye-to-eye.
+ Added LOS and LOS lost timer to target lost checks, in addition to distance.
* Turn off global-constructors warning. These are needed to implement cRoot signal handler functionality
* Add Clang flags based on version lookup instead of a compile test. The CMake config process is single threaded and slow enough already
* Reduced GetStackValue verbosity
+ Clarify EnchantmentLevel, StayCount, AlwaysTicked, ViewDistance signedness
+ Give SettingsRepositoryInterface a move constructor to simplify main.cpp code
- Remove do {} while (false) construction in redstone handler
* Fix lilypad displacing block above
Side fixes:
* Fix lilypad displacing half slabs
* Fix lilypad being placed on flowing water and non-water blocks in
general
Co-authored-by: Tiger Wang <ziwei.tiger@outlook.com>
