this might cause some delays on chunk resend as documented on master, but entities all get respawned on a resend, so this doesn't matter much. It's better than whatever side effects might come with spawning an entity in a chunk that the player doesn't have yet.
this allows assuming that a position has a valid world in places where it's never expected to not be valid. Since this is the vast majority of usages, it eliminates a lot of possible null-pointer warnings given by static analysers.
TODO: Consider whether we can make Position->getLevel/World use this behaviour out of the box in the next major version.
This reverts commit 3028832cd3.
When I created this commit, I made the flawed assumption that spawnTo()
would not be used by plugins. In addition, I was not aware that there
are some usages of spawnTo() in the core which do not check for chunk
usage, such as in Player->showPlayer().
This caused a collection of problems including memory leaks and crashes
due to disconnecting players not removing their references from viewed
entities.
The reverted commit may be the cause of #3178.
This will now throw an exception at the source instead of crashing when the entity is saved, which should put the blame on the correct plugin responsible for this.
This also includes magic method hacks to preserve backwards compatibility, since the fireTicks field is now protected.
This is better for performance because these then don't need to be reevaluated every time they are called.
When encountering an unqualified function or constant reference, PHP will first try to locate a symbol in the current namespace by that name, and then fall back to the global namespace.
This short-circuits the check, which has substantial performance effects in some cases - in particular, ord(), chr() and strlen() show ~1500x faster calls when they are fully qualified.
However, this doesn't mean that PM is getting a massive amount faster. In real world terms, this translates to about 10-15% performance improvement.
But before anyone gets excited, you should know that the CodeOptimizer in the PreProcessor repo has been applying fully-qualified symbol optimizations to Jenkins builds for years, which is one of the reasons why Jenkins builds have better performance than home-built or source installations.
We're choosing to do this for the sake of future SafePHP integration and also to be able to get rid of the buggy CodeOptimizer, so that phar and source are more consistent.
