* Stabilise MoveToWorld
* Fix comments and deprecate ScheduleMoveToWorld
* Enhanced thread safety for m_WorldChangeInfo
* Return unique_ptr from cAtomicUniquePtr::exchange
* cWorld now calls entity cEntity::OnAddToWorld and cEntity::OnRemoveFromWorld.
Allows broadcasting entities added to the world from the world's tick thread.
This also factors out some common code from cEntity::DoMoveToWorld and cEntity::Initialize.
As a consequence, cEntity::Destroy(false) (i.e. Destroying the entity without broadcasting) is impossible.
This isn't used anywhere in Cuberite so it's now deprecated.
* Update entity position after removing it from the world.
Fixes broadcasts being sent to the wrong chunk.
* Fix style
* cEntity: Update LastSentPosition when sending spawn packet
* Add Wno-deprecated-declarations to the lua bindings
* Kill uses of ScheduleMoveToWorld
* Terminate android build script early if any step fails
* Remove deprecated android types
* Use android NDK cmake support rather than cmake android NDK support as that support is better supported
* Android uses GNU strerror_r?
* Fix compilation
* Rebase
* Fix final issues
* Drop submodule changes
* Revert change
* Parentheses
* Lower api levels
* Don't use GNU strerror_r for Android
Co-authored-by: Mat <mail@mathias.is>
* WebAdmin improvements
* Remove stray div tag
* Revert path change
* Remove buildserver link
* Further simplification
* Reduce horizontal padding
* Add svg icons
* Remove unneeded css
* Make login and logout icons colored
* Use same capitalization for Log in and Log out
* Remove leftover code from old Webadmin design
* Remove more leftover code from earlier Webadmin versions
* and don't add earlier leftovers back...
* PR test
* Fix max width overflow
* Add missing css changes
This finally restores my ability to compile on Windows and Linux from the same source folder (on a network drive).
LibEvent broke this long ago by writing a config file into the source folder, rather than build folder. Now it's finally fixed.
The algorithm was designed so All portals must be facing the center, no matter which block had the eye inserted in last.
Note: Still need to create a block entity so that portals don't become invisible when you relog.
Addresses part of #3445Fixes#3695
Currently the player is spawned immediately in front of them.
Simply changing `cNetherPortalScanner::OutOffset` to 0.5 wasn't enough, as the player would always be spawned on top of the portal, however checking for non-solid blocks instead of air fixes this.
Closes#4236
CMake now creates a header file in the build directory under the path "include/Globals.h" which just includes "src/Globals.h" with an absolute path. Then instead of adding "src/" to the include directories, it adds "include/".
#include "Globals.h" still works by including the build generated file and any other src-relative path will not work.
This is my attempt to fix#4112. The root cause of the issue was that the lapis slot was treated exactly the same as the enchanting slot, so it on the server side it would only ever slot one item.
My fix is to check if its the second slot in the window, then check if it's lapis (it would slot whatever). If it is lapis I call the base click handler.
Problem: On a new server the players folder was not created on windows.
Root Cause:
`GetUUIDFolderName` was returning a folder structure for players with `/` while CreateFolderRecursively was checking for `\\` for win32.
The fix is to recognise both forward and backward slashes as file separators on windows.
Fixes#4284
* Replace cWorld::FindClosesPlayer with cWorld::DoWithClosestPlayer
* Implement experience reward splitting into the orb sizes used in vanilla
* Modified speed calculation in cExpOrb::Tick to make the orbs fly towards the player
Fixes#4216
Along with a call to `destroyentities`, this fixes#4271
I'm guessing the intention of this code was to modify the normal spawning of ocelots. However, `cEntity::SpawnOn` is actually called to send the entity to an individual client. That means this code was run for every single player, every time they were sent a chunk with ocelots in it. Thus, the ocelots population would grow exponentially as players log in and move around.