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.
