It is overkill to create a new SecureRandom on each entity create and then use it to make a new Entity ID for every entity instance created. Instead we will just use a pseudo random UUID based off the random instance we already have.
By: md_5 <md_5@live.com.au>
1) You will not hold SpigotMC responsible for any losses or damages incurred to you by using this build
2) You will report ALL bugs to SpigotMC and not other parties
Thanks for all the support and all parties who made this update possible; especially the awesome Spigot community. Sorry for the delay, but we had to fix some crucial bugs.
Regressions in this commit:
@mikeprimm's smarter chunk ticking patch has been removed as it prevents proper redstone and other block ticking logic.
By: md_5 <md_5@live.com.au>
while some of these may of been true, they are extreme cases and cause
a ton of noise to plugin developers.
Use ApiStatus.Internal instead of Deprecated for actual internal API
that continues to have use (internally).
These do not help plugin developers if they bring moise noise than value.
Expose an entities spawn reason on the entity.
Pre existing entities will return NATURAL if it was a non
persistenting Living Entity, SPAWNER for spawners,
or DEFAULT since data was not stored.
Additionally, add missing spawn reasons.
Co-authored-by: Aurora <aurora@relanet.eu>
Co-authored-by: Jakub Zacek <dawon@dawon.eu>
Adds an event for when the server is going to destroy a current block,
potentially causing it to drop. This event can be cancelled to avoid
the block destruction, such as preventing signs from popping when
floating in the air.
This can replace many uses of BlockPhysicsEvent
Allows using ExactChoice Recipes with easier methods
Redirects some of upstream's APIs to these new methods to avoid
usage of magic values and the deprecated RecipeChoice#getItemStack
Currently OfflinePlayer#getLastPlayed could more accurately be described
as "OfflinePlayer#getLastTimeTheirDataWasSaved".
The API doc says it should return the last time the server "witnessed"
the player, whilst also saying it should return the last time they
logged in. The current implementation does neither.
Given this interesting contradiction in the API documentation and the
current defacto implementation, I've elected to deprecate (with no
intent to remove) and replace it with two new methods, clearly named and
documented as to their purpose.
This event is invoked when a player has disconnected. It is guaranteed that,
if the server is in online-mode, that the provided uuid and username have been
validated.
The event is invoked for players who have not yet logged into the world, whereas
PlayerQuitEvent is only invoked on players who have logged into the world.
The event is invoked for players who have already logged into the world,
although whether or not the player exists in the world at the time of
firing is undefined. (That is, whether the plugin can retrieve a Player object
using the event parameters is undefined). However, it is guaranteed that this
event is invoked AFTER PlayerQuitEvent, if the player has already logged into
the world.
This event is guaranteed to never fire unless AsyncPlayerPreLoginEvent has
been called beforehand, and this event may not be called in parallel with
AsyncPlayerPreLoginEvent for the same connection.
Cancelling the AsyncPlayerPreLoginEvent guarantees the corresponding
PlayerConnectionCloseEvent is never called.
The event may be invoked asynchronously or synchronously. As it stands,
it is never invoked asynchronously. However, plugins should check
Event#isAsynchronous to be future-proof.
On purpose, the deprecated PlayerPreLoginEvent event is left out of the
API spec for this event. Plugins should not be using that event, and
how PlayerPreLoginEvent interacts with PlayerConnectionCloseEvent
is undefined.
Spigot