If the playerdata contains an invalid world (missing, unloaded, invalid,
etc.), spawn the player at the spawn point of the main world.
Co-authored-by: Wyatt Childers <wchilders@nearce.com>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
For years, plugin developers have had to delay many things they do
inside of the PlayerJoinEvent by 1 tick to make it actually work.
This all boiled down to 1 reason why: The event fired before the
player was fully ready and joined to the world!
Additionally, if that player logged out on a vehicle, the event
fired before the vehicle was even loaded, so that plugins had no
access to the vehicle during this event either.
This change finally fixes this issue, fully preparing the player
into the world as a fully ready entity, vehicle included.
There should be no plugins that break because of this change, but might
improve consistency with other plugins instead.
For example, if 2 plugins listens to this event, and the first one
teleported the player in the event, then the 2nd plugin actually
would be getting a valid player!
This was very non deterministic. This change will ensure every plugin
receives a deterministic result, and should no longer require 1 tick
delays anymore.
== AT ==
public net.minecraft.server.level.ChunkMap addEntity(Lnet/minecraft/world/entity/Entity;)V
Will not run if:
Max entity cramming is disabled and the max collisions per entity is less than or equal to 0.
Entity#isPushable() returns false, meaning all entities will not be able to collide with this
entity anyways.
The entity's current team collision rule causes them to NEVER collide.
Co-authored-by: Owen1212055 <23108066+Owen1212055@users.noreply.github.com>
Fastutil maps are going to have a lower memory footprint - which
is important because we clone chunk data after reading it for safety.
So, reduce the impact of the clone on GC.
Workaround for GH-189
Relocation breaks the lookup of a resource bundle, and this is easier than forking and maintaining our own version
AFAIK this should be fine to do. Guess we'll see
I misread the code and thought the code kept looping until the mob spawn cap was hit.
Upon furthur review, this is not true, so this patch doesn't do anything sane.
Behavior may be buggy or otherwise broken, testing with the option is needed.
`fix-cannons` has been removed in favor of `enable-old-tnt-cannon-behaviors`
Use -1 to represent vanilla/unlimited.
Updated PaperWorldConfig to also update the individual worlds limit if it was set
to the new default value.
Should hopefully help #235
Because Techable keeps complaining about how this isn't thread safe,
easier to do this than replace the entire thing.
Additionally, move Saving of the User cache to be done async, incase
the user never changed the default setting for Spigot's save on stop only.
may help #284
Cleans up the lighting queue system, reducing diff and improving implementation.
We no longer stop chunk unloads due to lighting updates, and instead simply flush the lighting queue.
The cost of forcing the chunk (and its neighbors!) to stay loaded waiting for its
lighting work to finish is much greater than simply taking the hit and doing the work.
This change also helps reduce the diff and avoid bugs with missed diffs by removing
duplicated logic.
Also switches to a more effecient data structure (ArrayDeque instead of LinkedList) for the queue itself.
no obviousy bugs caused by this at the moment, but we may need to clean up process to be like
how I use to have it before vanilla did it, and we shouldn't leave this boolean in an invalid state.
