Due to the changes in 1.13, clients will send a tab completion request
for all bukkit commands in order to factor in the lack of support for
brigadier and provide backwards support in the API.
Craftbukkit, however; has moved the chat spam limiter to also interact
with the tab completion request, which while good for avoiding abuse,
causes 1.13 clients to easilly be kicked from a server in bukkit due
to this. Removing the spam limit could cause issues for servers, however,
there is no way for servers to manipulate this without blindly cancelling
kick events, which only causes additional complications. This also causes
issues in that the tab spam limit and chat share the same field but different
limits, meaning that a player having typed a long command may be kicked from
the server.
Splitting the field up and making it configurable allows for server owners
to take the burden of this into their own hand without having to rely on
plugins doing unsafe things.
This patch has been applied to 1.12.2 in order to allow people using
plugins which allow clients of newer versions to connect, this is
not a common practice, however is being done as a level of nicety
given the current status of 1.13
We have a result boolean for this already, and this
method was meant to be "Try from cache, if that fails, look it up"
So NPE'ing there just wasn't correct.
In 1.13 the method previously used now returns translatable keys.
`block.minecraft.cobblestone` instead of `Cobblestone`
We just need to make sure we're translating those keys.
ideally this should of never mattered, as it will only
be hit if you teleport out of an unloaded chunk...
But apparently some people are triggering this.
See #1223
No entities were lost in this bug, just we were triggering the add entities
before they were loaded due to an inconsistent order of putting chunk into chunkmap.
Any entity that appeared to be gone on the last build will now be back.
This should not ever be used in production!!
This setting is intended for testing so you can try out converting your world
without actually modifying the world files.
This will add some additional overhead to your world, but you're
just testing anyways so that's not a big deal :)
Will store in a folder named after the current version.
PlayerData and Data folders are copied on server start, so there
may be some delay there, but region files are only copied on demand.
This is highly experiemental so backup your world before relying on this to not modify it
1.13 undesirably changed behavior here that chunk load event fired
before the entities were added to the world.
This means any plugin that spawns entities in chunk load event
causes the entities to be registered to the chunk, and then
added to the world twice.
Moves Entity Add to World to be done anytime a chunk is
registered to the Chunk Map, and ignore other calls.
Fixes#1288
* master:
Always process chunk registration after moving
Always move Entity to its new Chunk even if unloaded
If Entity is added to chunk, look up the chunk if current isnt set
Ignore Dead Entities in entityList iteration
Always process chunk removal in removeEntity
Spigot 1.13 checks if any field (which are manually copied from the ItemStack's "tag" NBT tag) on the ItemMeta class of an ItemStack is set.
We could just check if the "tag" NBT tag is empty, albeit that would break some plugins. The only general tag added on 1.13 is "Damage", and we can just check if the "tag" NBT tag contains any other tag that's not "Damage" (https://minecraft.gamepedia.com/Player.dat_format#Item_structure) making the `hasItemStack` method behave as before.
Check the `ItemMetaTest#testTaggedButNotMeta` method to see how this method behaves. (I also added some extra tests).
`hasItemMeta()` will return true if `ItemStack.getDamage() != 0` or it has the `Damage` tag or any other tag is set.
Closes#1222
This will help guarantee that entities are always in the
chunk that they are currently located at.
Should hopefully also fix Citizens triggering the "Saved to wrong chunk" message
Vanilla logic here would allow us to remvoe an entity from
its current chunk, and if it was going to move into an unloaded
chunk, that entity would not be added to the unloaded chunk.
This is bad because this will result in the entity being lost!
In almost all cases, the chunk will be loaded, but in the event
it wasn't, instead of losing the entity, load the chunk to add
the entity to it.
Hopefully will (f)ix #1280...
I'm suspicious that Citizens isn't calling things in the same order and causes the current
chunk to not be set, which then bugs removals. Though this doesn't make any sense to me,
so this likely won't fix it...
But if the isAddedToChunk is true, we really should be returning a chunk anyways if its loaded.
A spigot change delays removal of entities from the entity list.
This causes a change in behavior from Vanilla where getEntities type
methods will return dead entities that they shouldn't otherwise be doing.
This will ensure that dead entities are skipped from iteration since
they shouldn't of been in the list in the first place.
Spigot might skip chunk registration changes in removeEntity
which can keep them in the chunk when they shouldnt be if done
during entity ticking.
Should fix some cases where "Entity is still in another chunk section"
Related to #1223
Vanilla logic checks unload queue and overwrites if its in it.
we're triggering this if a chunk unloads, and reloads immediately in same tick.
Added check for unload queue to not treat as duplicate
Also fixed the config setting not even loading
