#paper

32502 messages · Page 33 of 33 (latest)

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

When a chunk is unloaded and ChunkUnloadEvent#setSaveChunk(false) is called, entities should not be saved.

Observed/Actual behavior

I noticed when the chunk unloads, and reloads... the previous entities are there, along with a new batch of entities.
For example im standing in a chunk that spawned 4 pigs.
When I log out/in... there's a new batch of pigs along with the pigs from the last chunk generation. Each time I do this, more and more piggies.

<img width="966" height="620" alt="Image" src="https://github.com/user-attachments/assets/f0199c3c-42be-468f-b68f-f159797603fb" />

Steps/models to reproduce

simple listener:

@EventHandler
public void onChunkUnload(ChunkUnloadEvent event) {
    event.setSaveChunk(false);
}

Plugin and Datapack List

[09:41:21 INFO]: ℹ Server Plugins (10):
[09:41:21 INFO]: Paper Plugins (5):
[09:41:21 INFO]: - CorePlugin, SkBee, SkBriggy, SkNMS, StressTestBots
[09:41:21 INFO]: Bukkit Plugins (5):
[09:41:21 INFO]:...

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

When a player is teleported to a different world during the PlayerJoinEvent, settings like the worldborder should be correctly updated to the client for the target world.

Observed/Actual behavior

There is a desynchronization between the client and the server regarding the world border. When a player logs in and gets teleported to a different world on join, the server correctly updates the border internally, but the client only updates partially.

From the player's perspective, the world border center and size appears to be the old targeted world's one, producing issue like making it seem as though the player is outside the border or running against an invisible wall. Running /worldborder center outputs the correct coordinates, confirming the server recognizes the right center.

Switching to a different world and returning resolves the desynchronization completely.

Steps/models to reproduce

Prepare a server with at least two different worlds (e.g., w...

#

its because this got reverted

<img width="2683" height="521" alt="Image" src="https://github.com/user-attachments/assets/a72dcd13-bcfc-4746-8ae3-82f72f15bcf4" />

And issue is PlayerList#placeNewPlayer

        // calls PlayerJoinEvent
        ....
        player.sentListPacket = true;
        player.suppressTrackerForLogin = false; // Paper - Fire PlayerJoinEvent when Player is actually ready
        ((ServerLevel)player.level()).getChunkSource().chunkMap.addEntity(player); // Paper - Fire PlayerJoinEvent when Player is actually ready; track entity now
        // CraftBukkit end

        //player.refreshEntityData(player); // CraftBukkit - BungeeCord#2321, send complete data to self on spawn // Paper - THIS IS NOT NEEDED ANYMORE
this--->this.sendLevelInfo(player, serverLevel);

        // CraftBukkit start - Only add if the player wasn't moved in the event
        if (player.level() == serverLevel && !serverLevel.players().contains(player)) {
            serverLevel.addNewPlay```...
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Is your feature request related to a problem?

Yes.
So I wrote a datapack, which pulls my world's lowest Y to -256.
After many attempts and asking a few AIs to help me with figuring out lava, lava kept pooling around -54Y.
Turns out Mojang hardcoded this value.
I reported it as a bug, and it was closed saying "request a feature, this isn't a bug"
Which I find funny, they give us the control in a datapack to go down to -2032Y, but our caves will be full of lava.
My bug MC-307994

Someone commented stating another bug MC-237017
This one (same issue as mine) remains open, so that's good news that its not closed, but bad news is in 5 years it hasn't been fixed.

Describe the solution you'd like.

In net.minecraft.world.level.levelgen.NoiseBasedChunkGenerator:

<img width="1020" height="237" alt="Image" src="https://github.com/user-attachments/assets/3bc715c0-b04d-45c7-bb2e-e7d3737a74b0" />

This is the hardcoded value. Id love to see a config option for this, or another alternative...

rustic folioBOT
#

Minecraft gives us the ability in data packs to modify the min Y of a world.
Unfortunately when dropping the Y to a lower value, caves with always be flooded with lava.
This is due to a hardcoded lava level.

I reported it as a bug, and it was closed saying "request a feature, this isn't a bug"
Which I find funny, they give us the control in a datapack to go down to -2032Y, but our caves will be full of lava.
My bug MC-307994

Someone commented stating another bug MC-237017
This one (same issue as mine) remains open, so that's good news that it's not closed, but bad news is in 5 years it hasn't been fixed. It's also confirmed.

Rather than hardcoding the lava level at a strict -54, this PR aims to take the min Y of the noise settings and add 10.
So min Y being -64, it still results in -54.
If a datapack (such as mine) drops it to -256, the result will be -246.
I have tested this on my own server with said datapack, and works perfectly.

Ref issue #13878...

rustic folioBOT
#

This really feels like this falls into the annoying "maybe makes sense but I'm not entirely sure it should be our job to make this, especially as we have no idea who might be surprised by it"

I totally get what you mean, I've just run out of ideas on how to make this work.
Only alternative I currently have is my own patch for myself.
I just do wonder how many others have run into this issue and it's gone unmentioned.

I can't think of any negative side effects from this, nor any alternative, but I'm all ears.

#

negative side effects would be a datapack gen setting applying in a way it didn't in the past, which will impact generation for new chunks, etc

Yeah that's fair.

Let's use this scenario (before this PR).
Say I wrote a datapack that pulls Y down to -128.
Old chunk is going to be -64
New chunk is going to be -128
Lava is going to flood the new chunk's caves from -54 downwards.
No one can use new deeper caves. Total waste ... sad face.

Post PR:
Same as above, but caves won't be flooded, player will be able to go down to newer, lower levels, happy face!
Only pitfall is players will be able to jump out of the new chunk since the old chunk didn't go down to that new level.

Datapacks that alter things like this typically shouldn't be put into old worlds, but we all know things happen.

I really wish Mojang didn't hardcode this in the first place. its so odd its not part of the datapack like everything else.

rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] New branch created: feature/vineflower-12.0.0
rustic folioBOT
#

Before this change, the Bukkit ItemStack passed to the event is constructed from a Bukkit Material, which relies on the Bukkit mapping from blocks to items being the same as the Minecraft mapping from blocks to items.

However, it is not the same.
For example, new ItemStack(Material.POTATOES) does not give an ItemStack of type Material.POTATO as it should.
So a flower pot block created as new FlowerPotBlock(Blocks.POTATOES, properties) will crash the server.

After this change, the Bukkit ItemStack passed to the event is constructed from the Minecraft ItemStack, which relies on the Minecraft mapping from blocks to items being correct.

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

This is a WAI since custom spear allow to dismount without doing damage/knockback so it's not related at all.

Hello, I don’t quite understand this situation.

Some servers use boats or minecarts to display mobs or build mob farms. Even when players do not have permission to attack entities, they can still use spear charges to dismount mobs from vehicles.

Is there currently any proper way to prevent this behavior? Or would it be better to create a feature request for something like a SpearChargeDismountEvent?

rustic folioBOT
#

Is your feature request related to a problem?

When the attack event caused by SpearCharge is cancelled, the entity will still dismount from boat and minecart.
https://github.com/PaperMC/Paper/issues/13583

Many players trap various mobs inside minecarts and boats for display purposes, and some mob farms also rely on this mechanic. However, SpearCharge can now bypass protection in these areas; while it cannot deal damage to the mobs, it is able to force them to dismount.

Describe the solution you'd like.

Added SpearChargeDismountEvent, which provides access to the SpearCharge attacker. Region protection plugins can perform fine-grained permission checks to allow or prevent the dismount event

Describe alternatives you've considered.

Or make EntityDismountEvent able to capture the attacker, if an attacker exists.

Other

No response

rustic folioBOT
#

Expected behavior

EntityDamageByEntityEvent should getAttackCooldown correctly

Observed/Actual behavior

Attack with hand is always 0.1, and attack with sword is always 0.039999995

Steps/models to reproduce

@EventHandler
public static void onEntityDamageByEntityEvent(EntityDamageByEntityEvent event) {
    if (event.getDamager() instanceof Player player) print(player.getAttackCooldown());
}

Plugin and Datapack List

test plugin only

Paper version

Paper 26.1.2-63
since Paper 26.1.2-55 after #13856

Other

No response

rustic folioBOT
#

Expected behavior

Bukkit.getBukkitVersion() and Server.getBukkitVersion() functions are supposed to return the current version of Bukkit API which is implemented by server software (here Paper-server). For instance 26.1.2 or 26.1.2-SNAPSHOT or 26.1.2-R0.1-SNAPSHOT.

In all former versions (before 26.1.2), it worked perfectly. Example: 1.19.4-R0.1-SNAPSHOT

Observed/Actual behavior

For 26.1.2 servers, the version number returned is the server one: 26.1.2.build.63-stable instead of the API one.

Steps/models to reproduce

Two possibilities:

  • Invoke the Bukkit.getBukkitVersion() in a plugin
  • Type /version in the console. The Bukkit API version number is shown after Implementing API version string.

Plugin and Datapack List

BlockLocker, CMILib, DecentHolograms, Essentials, EssentialsAntiBuild, EssentialsChat, EssentialsSpawn, GroupManager, Multiverse-Core, Multiverse-Inventories, Multiverse-Portals, PlaceholderAPI, pvparena, Residence, Vault, WorldEdit, WorldGuard

##...

#

That means developing a specific way to parse it and compare it if I need to provide specific version features.

You can use https://jd.papermc.io/paper/26.1.2/io/papermc/paper/ServerBuildInfo.html#minecraftVersionId() or https://jd.papermc.io/paper/26.1.2/org/bukkit/Bukkit.html#getMinecraftVersion() for alternative representation if you want, that would be kept with what mojang is providing

#

That means developing a specific way to parse it and compare it if I need to provide specific version features.

You can use https://jd.papermc.io/paper/26.1.2/io/papermc/paper/ServerBuildInfo.html#minecraftVersionId() or https://jd.papermc.io/paper/26.1.2/org/bukkit/Bukkit.html#getMinecraftVersion() for alternative representation if you want, that would be kept with what mojang is providing

Both methods are not available in common Bukkit API, for instance they don't exist in Spigot.

rustic folioBOT
#

There isn't a bukkit API version and hasn't for a decade, the API and the Server are versioned together, we no longer use SNAPSHOT releases; We're not semver compliant and that was never something that was garaunteed

During many years Spigot and Paper returned the same result when a Bukkit API method was called. This was useful and make possible interoperability between server software. That's how an API is supposed to work.
Now, if it's a design choice and not a bug, I respect that. I was here to report what I thought was an issue, not to impose anything.

rustic folioBOT
#

Leaving this longer messages for those interested in more details:

During many years Spigot and Paper returned the same result when a Bukkit API method was called.

Bukkit died in 2014.

For years, Paper was based on Spigot, so it did whatever Spigot did.

When Paper split from Spigot at 1.21.4, it became possible for Spigot and Paper to have different classes/methods entirely or to have same-named methods return different values. If a developer wishes to support the 95+% of modern servers running Paper and also the under 5% of servers on Spigot, they should be writing code to handle each, because there are deviations (sometimes significant!).

Minecraft 26.1 was a major versioning shift in MC, making it a great time to also properly adjust the versioning values you get from the API:
Considering the last R1.0 was on MC 1.6.4, dropping the R0.1 bit is reasonable. Including build numbers is great, because sometimes an API method appears later on than the first working builds, so a pl...

rustic folioBOT
#

That event feels overly specific, but I don't mind having a generic EntityStabEvent with toggles for damage, knockback and dismount along the attacker. Maybe something like this:

if (!event.getAttacker().hasPermission("plugin.dismount")) {
event.getActions().remove(Action.DISMOUNT);
}

that can be a thing for EntityLungeEvent or that event its to early?

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

That event feels overly specific, but I don't mind having a generic EntityStabEvent with toggles for damage, knockback and dismount along the attacker. Maybe something like this:

if (!event.getAttacker().hasPermission("plugin.dismount")) {
event.getActions().remove(Action.DISMOUNT);
}

So long as I can obtain the attacker, I don't mind what the event is called.^_^

rustic folioBOT
rustic folioBOT
#

Using the following listener, the logged loot table currently matches the default loot table of the entity, not the actual loot table used:

    @EventHandler
    public void onEntityDeath(EntityDeathEvent event) {
        if (event.getEntity() instanceof Mob mob) {
            this.getSLF4JLogger().warn("Entity {} died with loot table: {}", mob.getName(), mob.getLootTable());
        }
    }

During my test, the Pig I modified did drop rotten flesh despite the console printing entities/pig loot table

[02:11:45 INFO]: roro1506_HD issued server command: /data merge entity 62185aec-e858-4945-a41a-6e21107085b7 {DeathLootTable:"minecraft:entities/zombie"}
[02:11:45 INFO]: [roro1506_HD: Modified entity data of Pig]
[02:11:47 WARN]: [Paper-Test-Plugin] Entity Pig died with loot table: minecraft:entities/pig

This PR fixes this issue

[16:12:32 INFO]: roro1506_HD issued server command: /data merge entity c3c71d92-632f-49d3-a682-fd062b85f884 {DeathLootTable:"minecra```...
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

No WARM

Observed/Actual behavior

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by org.joml.MemUtil$MemUtilUnsafe (file:/X:/MinecraftServer/libraries/org/joml/joml/1.10.8/joml-1.10.8.jar)
WARNING: Please consider reporting this to the maintainers of class org.joml.MemUtil$MemUtilUnsafe
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release

Steps/models to reproduce

Start Server
Use JDK 25

Plugin and Datapack List

No have

Paper version

ver
[18:46:07 INFO]: Checking version, please wait...
[18:46:08 INFO]: This server is running Paper version 1.21.11-132-ver/1.21.11@c5eb079 (2026-05-11T11:43:09Z) (Implementing API version 1.21.11-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.11-131-6d5b910 (MC: 1.21.11)

Other

Can you are add this update to papermc 1.21.11?
Can you are Fix this?

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

No errors in the console

Observed/Actual behavior

I'm just flying around the world and this error appears in the console:

<img width="1090" height="330" alt="Image" src="https://github.com/user-attachments/assets/0fb12b60-7f4e-4f18-8e47-8ff148c20384" />

Steps/models to reproduce

  1. Enable Anti-Xray
  2. Join the server
  3. Load chunks
  4. View the console

Plugin and Datapack List

[03:25:10 INFO]: ℹ Server Plugins (61):
[03:25:10 INFO]: Paper Plugins (1):
[03:25:10 INFO]: - PlugManX
[03:25:10 INFO]: Bukkit Plugins (60):
[03:25:10 INFO]: - AntiHealthIndicator, AuraSkills, AutoMessage, BanItem, BigDoors, BookExploitFix, BreweryX, ChatSpy, Citizens, CommandAPI
[03:25:10 INFO]: CoreProtect, CustomCrafting, DeluxeMenus, dtlTraders, dynmap, Dynmap-Towny, EasyPayments, Essentials, EssentialsProtect, EssentialsSpawn
[03:25:10 INFO]: FastAsyncWorldEdit, GoldEconomy, GSit, HeadDatabase, ImageFrame, Interactions, Kostyl, KostylTWO, LicuhaDe, LiteBans
[03:2...

rustic folioBOT
#

The issue here is that world types aren't a thing anymore, these are just templates, effectively; said template used for the end/nether and the others are applied to the overworld.

Not really sure I like the surfacing of this stuff as a result of that, the underlying concept of a world type no longer exists, this is just trying to marry an outdated deprecated concept with it's replacement cousin which works differently in a sense

rustic folioBOT
#

Expected behavior

The firework should always use the data from the new item.

Observed/Actual behavior

The old firework data is retained. Note that this only occurs when updating the firework's item, i.e. setting an item on a firework that already has an item.

Steps/models to reproduce

Use Firework#setItem on a firework entity that already has an item set. Can be done at any time during its life.

Here's a small example that should summon a green firework, but summons a red one instead.

ItemStack first = ItemStack.of(Material.FIREWORK_ROCKET);
first.setData(DataComponentTypes.FIREWORKS, Fireworks.fireworks()
        .addEffect(FireworkEffect.builder()
        .withColor(Color.RED)
        .build()));

ItemStack second = ItemStack.of(Material.FIREWORK_ROCKET);
second.setData(DataComponentTypes.FIREWORKS, Fireworks.fireworks()
        .addEffect(FireworkEffect.builder()
        .withColor(Color.GREEN)
        .build()));

location.getWorld().spawn(location, Firework.```...
rustic folioBOT
rustic folioBOT
#

This PR closes https://github.com/PaperMC/Paper/issues/13890 and also handle a few things i notice when check the class...

  • setItem set the item but also use any previous ItemMeta for set the item again, the PR just remove the use of ItemMeta in setItem because currently its not necesary (thanks Components)
  • the helper method applyFireworkEffect was removed because that logic its only necesary for setFireworkMeta
  • a cleanup of comments and imports

I make a few tests for this changes...

The issue reported where the second item was ignored

final Location location = player.getLocation().clone().add(0, 1, 0);
ItemStack first = ItemStack.of(Material.FIREWORK_ROCKET);
first.setData(DataComponentTypes.FIREWORKS, Fireworks.fireworks()
    .addEffect(FireworkEffect.builder()
        .withColor(Color.RED)
        .build()));

ItemStack second = ItemStack.of(Material.FIREWORK_ROCKET);
second.setData(DataComponentTypes.FIREWORKS, Fireworks.fireworks()
    .addEffect(F```...
#

I would argue then that this is more a temporary solution for people to be able to detect the different types and being able to create CAVES, FLOATING_ISLANDS and DEBUG from WorldCreator while a better more improved system can be made

I've made commits now to add a method to get the key and re-deprecated the getWorldType(), but I think the added world types should be kept for creating new worlds until said better system is made

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Related to a comment this PR set obsolete the use of PotionMeta in Potion entities, also remove the use of them in the "Craft" classes because are not necesary.

I test this PR with the follow cases...

For use a ItemMeta and set to the potion

final Location location = player.getLocation().clone().add(0, 1, 0);
ItemStack first = ItemStack.of(Material.LINGERING_POTION);
first.editMeta(PotionMeta.class, meta -> {
    meta.addCustomEffect(new PotionEffect(PotionEffectType.REGENERATION, 10 * 20, 10), true);
});

final LingeringPotion entitySpawned = location.getWorld().spawn(location, LingeringPotion.class, entity -> {
    entity.setPotionMeta(((PotionMeta) first.getItemMeta()));
});

PotionMeta meta = entitySpawned.getPotionMeta();
player.sendMessage(meta.toString());

Set the ItemMeta but use the item

final Location location = player.getLocation().clone().add(0, 1, 0);
ItemStack first = ItemStack.of(Material.LINGERING_POTION);
first.editMeta(PotionMeta.```...
#

Expected behavior

users not being able to set

level-name=

and it leading to creation of a world with empty string as a name, leading to plugin errors, because there was an assumption that world name is not an empty string.

Observed/Actual behavior

level-name=

results in creation of the world in the server root directory.

level-name=../

will attempt to create the world in the parent directory and

level-name=/home/someuser/world
will create it on the absolute path

all cases are likely to break plugin configs relying on the world name

### Steps/models to reproduce

1. start a clean server
2. set `level-name=` in server-properties
3. see all the world files dumped in the server root directory

### Plugin and Datapack List

n/a

### Paper version

n/a (present in vanilla, [bug report](https://report.bugs.mojang.com/servicedesk/customer/portal/2/MC-308240))

### Other

_No response_
rustic folioBOT
rustic folioBOT
#

Back here because I found the Statistics api. Statistics can be edited using an OfflinePlayer instance. This might be due to their api being a bit more exposed than the player.dat file, but it just creates an empty file for them if they didn't have one already. This makes me think the best implementation for this is to just create the .dat file when a dev edits a player's PDC. Like with stats, the write operation can happen when a value is changed.

rustic folioBOT
#

Stack trace

https://api.mclo.gs/1/raw/HMf1QmP

Plugin and Datapack List

my own plugin

Actions to reproduce (if known)

I wrote these

builder.base(DialogBase.builder(Component.text("选择存档", NamedTextColor.WHITE))
                            .canCloseWithEscape(false)
                            .body(List.of(
//                                    DialogBody.plainMessage(Component.text("这是一条测试信息")),
//                                    DialogBody.plainMessage(Component.text("这是一条测试信息2"))

                                    DialogBody.item(new ItemStack(Material.DIAMOND))
//                                            .description(DialogBody.plainMessage(Component.text("钻石一个")))
//                                            .height(1)
//                                            .showDecorations(true)
//                                            .width(1)
//                                            .showTooltip(true)
                                            .build()```...
rustic folioBOT
rustic folioBOT
#

Expected behavior

A PlayerInteractEvent with action = LEFT_CLICK_AIR must be triggered

Observed/Actual behavior

PlayerInteractEvent is not being triggered

Steps/models to reproduce

/attribute @p minecraft:entity_interaction_range base set 10
https://youtu.be/NhFysJaVHiA

Plugin and Datapack List

none

Paper version

the second-to-last one; it doesn't make sense

Other

This can be fixed by adding the same check as in hitEntity, but replacing entity with block and entityInteractionRange with blockInteractionRange.

else if (gameType != GameType.CREATIVE && result.getHitBlock() != null && origin.toVector().distanceSquared(result.getHitPosition()) > this.player.blockInteractionRange() * this.player.blockInteractionRange()) {
                CraftEventFactory.callPlayerInteractEvent(this.player, Action.LEFT_CLICK_AIR, this.player.getInventory().getSelectedItem(), InteractionHand.MAIN_HAND);
            }
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

The server should automatically convert names for keys regarding feature seeds in paper-world.yml configurations in each world folder from their 1.21.11 format to their 26.1.2 format, respectively.

Observed/Actual behavior

When upgrading the server from 1.21.11 to 26.1.2, some feature seeds can not be deserialized from the paper-world configuration file because the name of the key of the feature seed is different across the versions. This causes an error like this to be shown for each feature seed that can't be deserialized:

[14:59:04] [Server thread/ERROR]: [MapSerializer] Could not deserialize key minecraft:pale_forest_flowers into net.minecraft.core.Holder<net.minecraft.world.level.levelgen.feature.ConfiguredFeature<?, ?>> at [feature-seeds, features]: Missing holder in ResourceKey[minecraft:root / minecraft:worldgen/configured_feature] with key ResourceKey[minecraft:worldgen/configured_feature / minecraft:pale_forest_flowers]

Steps/models to reproduce...

rustic folioBOT
rustic folioBOT
#

I feel your pain. After spending a lot of time digging into this, it's clear that the "bridge" the developers mentioned in the commit has indeed collapsed for all of us.

Since it seems we're left to "cross this bridge" on our own without any one-click fix or config toggle from the server side, I've found a workaround. For those of you using mineflayer, you can simulate the missing epsilon by slightly adjusting the client-side physics.

Just add this to your bot's spawn/init logic:


if (bot.physics) {
  bot.physics.playerHalfWidth = 0.302; // Restores the tiny gap needed to jump
}

It's a "client-side band-aid" for a "server-side wound," but it works. Until (or if) the devs decide to prioritize our experience over "pixel-perfect" collisions, this is the way.

#

Just a heads-up for everyone implementing this workaround:

If the Paper devs eventually decide to revert these changes and restore the epsilon, this client-side fix might cause slight "over-padding" (making the bot feel slightly wider than normal), which could potentially interfere with very tight navigation.

To keep your code maintainable, I suggest making this a configurable toggle in your bot's settings rather than a hardcoded value:

const usePaperCollisionFix = true; // Set to false if the server is updated/fixed

if (bot.physics) {
  bot.physics.playerHalfWidth = usePaperCollisionFix ? 0.302 : 0.3;
}

This way, you can quickly switch back to vanilla physics without hunting through your code if the server-side "improvement" is ever undone.

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

I am having a similar issue with the following stack trace:

`---- Minecraft Crash Report ----
// There are four lights!

Time: 2026-05-21 18:19:38
Description: Exception in server tick loop

java.lang.RuntimeException: Failed to migrate world storage for world_nether
at io.papermc.paper.world.PaperWorldLoader.getWorldInfoAndData(PaperWorldLoader.java:65)
at io.papermc.paper.world.PaperWorldLoader.loadInitialWorld(PaperWorldLoader.java:150)
at io.papermc.paper.world.PaperWorldLoader.loadInitialWorlds(PaperWorldLoader.java:139)
at net.minecraft.server.MinecraftServer.loadLevel(MinecraftServer.java:650)
at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:382)
at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1301)
at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:304)
at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.io.IOException: Refusing to overwrite existing migrated file ./world/dim`...

rustic folioBOT
#

i find myself in need of an event like this but for a different reason, im building a progression system and would have liked to grant skill xp when a player repaired items in an anvil. Using InventoryClickEvent as said above is very unreliable (lets say the bottom inventory cant hold the item and the click type is shift click, i would need to test the entire inventory, for example) and has the possibility for false flags. a dedicated use event would be really nice.

PrepareAnvilEvent can't be used for this either since it only gets fired when the anvil recalculates stuff (at which point the result slots are empty if the anvil is used)

rustic folioBOT
#

Is your feature request related to a problem?

related to #13575

The grindstone and the anvil are the only workbenches who don't have a 'use' event related to their 'PrepareResultEvent' event.
e.g. PrepareSmithingEvent has SmithItemEvent, PrepareItemEnchantEvent has EnchantItemEvent, etc.

I require this functionality to be able to award skill xp for a progression system, for example.

Describe the solution you'd like.

Add GrindstoneItemEvent, (and AnvilUseEvent #13575), so that these actions can be properly detected,
or a more generic CompleteResultEvent, that would apply to all PrepareResultEvent events, when a result is completed.

Describe alternatives you've considered.

Listening to the InventoryClickEvent, but this requires hacky prediction of whether the item will actually leave the result slot.

Other

No response

rustic folioBOT
rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] branch deleted: feature/vineflower-12.0.0
rustic folioBOT
rustic folioBOT
#

I am unable to reproduce any of the behaviors you've mentioned, and since you also have not provided any other information than that there's really nothing we can do here. What you're describing does sound like what some naive lag "fixing" plugins might cause, but you claim you're only running essentials, so, yeah

#

Wouldn't this just be addRotation? Which, fair addition, I am just not very happy with the method name and parameters, they look to be copying internals one to one and seem very clunky.

//edit: Might not have said this nicely, there is obviously a different in the method as ServerPlayer makes use of those booleans to send the relative update packet instead. This is purely about naming of the API method.

if renamed to addRotation, the relative parameters will look more confusing, or you mean method like addRotation(yaw, pitch)?
I'd prefer just keep it. I added a note, which may be better

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

The key that the server says cannot be deserialized is found in the paper-world.yml config before upgrading, and disappears after upgrading, so it is correct that they are getting removed. However, upon checking the paper-world.yml after upgrading, I found many keys with similar names to the ones that got removed, many of which just have the word "patch_" removed from the beginning of the key (ex: minecraft:patch_pumpkin -> minecraft:pumpkin). I cannot say for certain that the old and the new keys with similar names are used for the same thing when generating the world, but if they are, Im not sure changing feature seeds is healthy for the world...

Also, I counted 25 keys that could not be deserialized and got removed, and the server only regenerated 22 keys after the 25 keys got removed, so three keys were completely removed from the config

rustic folioBOT
#

The past issue was marked as WAI as the error is kinda expected when stuff doesn't miss, there isn't any real means of automating the upgrades of this stuff too well, so it kinda falls by the wayside; That stuff is all backed off of Mojang's registries, and given that this is all basically generation stuff which doesn't get serialised, there is no migration logic inside of vanilla at all, and nothing we have to hook.

rustic folioBOT
#

Is your feature request related to a problem?

I currently have 27 worlds loaded on my Paper instance, but aside from the three main worlds, the rest are archive worlds in past 10 years. The three main worlds run on local high-speed NVMe SSD storage, while the archive worlds are mounted to the world path via Samba/CIFS from a slow HDD NAS on the local network since my players only visit these worlds during nostalgia events, there is no player activity on them at other times.

Due to the NAS's heavy workload (continuous backups, deduplication, compression, and checksumming) and the fact that it runs on HDDs, its I/O performance is poor. Although Paper's chunk system handles these slow read operations effectively, preventing them from affecting the game server itself, the operation to save level.dat still runs on the server thread. This causes the server to experience a spike in lag every so often (when you have a lots worlds, it will keep and continuously). Although these spikes las...

rustic folioBOT
rustic folioBOT
#

Expected behavior

I expect to see the speed not reset when the ender pearls are dropped.

Observed/Actual behavior

I see that when I flip the ender pearl, the speed is reset, although it shouldn't be.

Steps/models to reproduce

when a player goes forward or flies on elites and throws an ender pearl forward or throws an ender pearl into a vortex charge on elites, his speed slows down and he hovers in the air for a while or just stops on the ground, that is, slows down

Plugin and Datapack List

No

Paper version

26.1.2-65

Other

there is an example of the Pearl Momentum Fix plugin, but the problem is that because of it, players have a bug that sometimes they can just jump or take off on the spot, this should not happen, but the description of the plugin is correct and it needs to be done because the plugin does not cope with it.

rustic folioBOT
rustic folioBOT
#

Expected behavior

When opening a villager merchant menu for a player using the Paper API, I expected the villager's reputation-based trade behavior to work the same as when the player normally interacts with that villager.

For example, discounts or price changes caused by villager reputation should be applied to the trades shown in the merchant menu.

Observed/Actual behavior

When opening the merchant menu using MenuType.MERCHANT.builder(), the villager's reputation-based trade behavior does not appear to work.

The menu opens successfully, but the trades do not reflect the villager's reputation data for the player.

Code used:

MenuType.MERCHANT.builder()
    .merchant(villager)
    .checkReachable(false)
    .build(player)
    .open();

### Steps/models to reproduce


**Steps/models to reproduce**

```markdown
1. Start a Paper server with a plugin that opens a villager merchant menu using the Paper menu API.
2. Get or spawn a villager with trades.
3. Give the player a reputa...
rustic folioBOT
#

Well the logic for reputation is when you interact with the villager (before create the inventory to show), in the case of the MenuType you directly build the inventory then that step are ignored (like in HumanEntity#openMerchant)

Not sure for my if was intended or not... if its not intended then a fix can be call that method in HumanEntity#openMerchant and the CraftMenu#openMerchantMenu (used by the open() method in the MenyType API)

rustic folioBOT
#

Talking in discord about the Villager and the inventory this PR handle a behaviour noticed in https://github.com/PaperMC/Paper/issues/13905 where the methods to open inventory related to Villager ignore the update price for reputation or hero of the village, the only "breaking" change here is if user dont expect to get that change of prices, but just need use https://jd.papermc.io/paper/26.1.2/org/bukkit/inventory/MerchantRecipe.html#setIgnoreDiscounts(boolean) for make clear dont wanna updates in the prices.

Thanks @Y2Kwastaken and @masmc05 for the help with the Inventory behaviour.

Can close https://github.com/PaperMC/Paper/issues/13905

rustic folioBOT
rustic folioBOT
#

Currently the only way to get the entities loot on death is using EntityDeathEvent#getDrops, but that also includes drops from things like chest horses, boat chests, blocks held by enderman, etc.

If you only want to mutate that entities loot table you have to manually handle every edge case which is painful to say the least.

EntityLootGenerateEvent is intended to solve the gap.

rustic folioBOT
#

Stack trace

Plugin and Datapack List

Only have plugin!

pl
[10:28:58 INFO]: ℹ Server Plugins (43):
[10:28:58 INFO]: Paper Plugins (4):
[10:28:58 INFO]: - AdvancedServerList, MCKotlin-Paper, paper-language-kotlin, surf-serverbrand-customizer
[10:28:58 INFO]: Bukkit Plugins (39):
[10:28:58 INFO]: - ActionGlass, AnarchySpawn, AntiCheatAddition, AntiLoggedInFromAnotherLocation, AttackCooldownRemover, AttributeSwapFixer, BlockChat, BlockReports, Bunnysquad, BushRehab
[10:28:58 INFO]: LHTab, Milk, NewJoinMessages, NoChatLagServer, NoSleep, OtherBedRegen, OxygenGamemodeLock, packetevents, ProtocolLib, ReducedDebugInfo

Actions to reproduce (if known)

Can I add the repair update to papermc 1.21.11?
Moonrise is a big problem
Some cheating clients, such as PacketFly, can also experience the same crash

Paper version

ver
[10:29:28 INFO]: Checking version, please wait...
[10:29:28 INFO]: This server is running Paper version 1.21.11-132-ver/1.21.11@c5eb079 (2026-05-11T11:...

#

The symptoms are simple
A certain core of the CPU is running at 100% lag
[10:33:45 INFO]: UUID of player StoodMusic58914 is d1793670-3689-3b2a-8b70-c5ecabd45331
[10:33:50 WARN]: [ca.spottedleaf.moonrise.patches.chunk_system.level.entity.EntityLookup] Entity uuid already exists: 64b08d5b-9cec-4a20-8cf9-53dfb04c815e, mapped to Skeleton['Skeleton'/9295, uuid='64b08d5b-9cec-4a20-8cf9-53dfb04c815e', l='ServerLevel[world]', x=-196.50, y=79.92, z=301.35, cpos=[-13, 18], tl=0, v=false], can't add Skeleton['Skeleton'/29296, uuid='64b08d5b-9cec-4a20-8cf9-53dfb04c815e', l='ServerLevel[world]', x=-196.50, y=79.92, z=301.35, cpos=[-13, 18], tl=0, v=false]
Moonrise crashes again after entering the same chunk

#

kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:05 INFO]: UUID of player SM_Games is 6adde1b9-ac7d-37a4-8c21-a58b5dd98e0b
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:07 INFO]: Killed 31 entities
kill @e
kill @e
kill @e
[10:44:07 INFO]: Killed 718 entities
[10:44:07 INFO]: Killed 573 entities
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e

kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:10 INFO]: Killed 28432 entities
kill @ekill @e
[10:44:10 INFO]: Killed 28449 entities
kill @e
[10:44:10 INFO]: Expected whitespace to end one argument, but found trailing data
kill @ekill @e<--[HERE]
kill @e
kill @e
kill @e
kill @e
[10:44:11 INFO]: Killed 14545 entities
kill @e
[10:44:11 INFO]: Killed 10364 entities
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:13 INFO]: [+] SM_Games joined the server.
Welcome to SM.SMP
kill @e...

#

kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:05 INFO]: UUID of player SM_Games is 6adde1b9-ac7d-37a4-8c21-a58b5dd98e0b
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:07 INFO]: Killed 31 entities
kill @e
kill @e
kill @e
[10:44:07 INFO]: Killed 718 entities
[10:44:07 INFO]: Killed 573 entities
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
kill @e
[10:44:10 INFO]: Killed 28432 entities
kill @Ekill @e
[10:44:10 INFO]: Killed 28449 entities
kill @e
[10:44:10 INFO]: Expected whitespace to end one argument, but found trailing data
kill @Ekill @e<--[HERE]
kill @e
kill @e
kill @e
kill @e
[10:44:11 INFO]: Killed 14545 entities
kill @e
[10:44:11 INFO]: Killed 10364 entities
kill @e
kill @e
kill @e
kill...

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

How is it valid usage because of the namespace being lowercase? The key in the other constructor is made lowercase automatically, so I thought this would be acceptable.

It is made lowercase automatically when supplying an input because you do not control the input directly. Most plugins have a uppercase letter in their name somewhere which is a valid thing, and it would be a breaking change if every author would have to change this in order to use NamespacedKey. When specifying the namespace manually, you are in control, so this is no longer an issue and the correct requirements are enforced

#

because you do not control the input directly
You do though? I was talking about the key, not the namespace. You directly control the key, but it is still made lowercase. Should this change be removed?

When specifying the namespace manually, you are in control

I haven't been talking about the namespace, I've been talking about the key.

In both scenarios, you have full control over the key, but it is still changed to be made lowercase when the plugin class is specified. I also made the namespace string be lowercase because I though it'd be weird to throw errors for a capitalized namespace but not for a capitaized key.

rustic folioBOT
#

I mean, we cannot really remove it now as it already exists in the plugin constructor of NS without breaking backwards compatibility. that bit of the namespaced key constructor was inherited from spigot,

I agree with the above comments tho. Manually and quietly changing the key to lowercase seems only harmful when developers should very much be forced to use correct casing for these inputs.

rustic folioBOT
#

There's currently no event that fires when a creeper's swell level changes, and there's currently no way to stop a creeper from swelling. CreeperIgniteEvent does not fire when a creeper primes due to proximity, EntityExplodeEvent only fires at the end of swelling, and GenericGameEvent of type GameEvent.PRIME_FUSE doesn't allow for cancelling and doesn't fire for individual swell steps.

The proposed CreeperSwellEvent fires whenever a creeper's internal swell level changes, and it also differentiates different reasons for the swell: PRIMED (proximity or ignition), FALL_DAMAGE (falling from a height), or CUSTOM (plugin adjusting swell).

Fixes #12620

#

There's currently no event that fires when a creeper's swell level changes, and there's currently no way to stop a creeper from swelling. CreeperIgniteEvent does not fire when a creeper primes due to proximity, EntityExplodeEvent only fires at the end of swelling, and GenericGameEvent of type GameEvent.PRIME_FUSE doesn't allow for cancelling and doesn't fire for individual swell steps.

The proposed CreeperSwellEvent fires whenever a creeper's internal swell level changes, and it also differentiates different reasons for the swell: PRIMED (proximity or ignition), FALL_DAMAGE (falling from a height), or CUSTOM (plugin adjusting swell).

Fixes #12620

#
  1. Why wouldn't the client reflect the unswelling if cancelled, as it does if you back off from a creeper?

  2. I see you're firing a swell event on cancelled explosion. Bizarre edge case question: What happens if someone is always cancelling explosion events and then cancels that specific post-cancel swell event as well? Will the creeper be continuously trying to explode?

rustic folioBOT
#

After reading your reply, I noticed a bug that would let a primed creeper's swell level to continue to change even if the event was cancelled. It happened because cancelling the event set the final swell change to 0, so the vanilla logic kicked in and continued to increment the swell level. Now, the tick function will instead check for a nonzero swellDir to decide whether or not to fire the event and handle its cancellation state.


  1. Why wouldn't the client reflect the unswelling if cancelled, as it does if you back off from a creeper?

The client does render an unswell, but it seems like the client is only programmed to render a full swell in one direction. For example, if I use this code in a plugin to only allow a creeper to swell half-way:

@EventHandler
public void onCreeperSwell(CreeperSwellEvent event) {
    if (event.getCurrentSwell() + event.getFinalSwellChange() > event.getMaxSwell()/2)
        event.setCancelled(true);
}

the client still sees the...

rustic folioBOT
#

Expected behavior

ItemStack.getItemMeta() should work safely when called from multiple virtual threads concurrently.

Observed/Actual behavior

CraftMetaItem.updateFromPatch() throws NullPointerException at line 547 because ImmutableCollections$SetN.contains() receives a null argument. This happens when multiple virtual threads call getItemMeta() concurrently (via a plugin's async processor).
The UI still renders after a retry, so it's non-fatal but produces log spam.

Steps/models to reproduce

  1. Have a plugin that creates/accesses ItemStacks on virtual threads (or any async thread pool)
  2. Multiple threads call ItemStack.getItemMeta() concurrently
  3. NPE in updateFromPatch

Plugin and Datapack List

ℹ Server Plugins (43):
Paper Plugins (1):

  • FancyHolograms
    Bukkit Plugins (42):
  • 3DManeuverGear, AdvancedReplay, AlonsoLevels, AneCustomToast, AntiPopup, BrickThrower, Economy, ExtraSpecialItems, FakeBedWars, FakeExItems
    FakeRush, FakeServer, Gen-Splitter, Item...
rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] New branch created: dev/26.2
#

Were paper-server/patches/sources/org/apache/logging/log4j/core/appender/AsyncAppender.java.patch or paper-server/patches/sources/org/apache/logging/log4j/core/appender/AsyncAppenderEventDispatcher.java.patch intended?

#
[PaperMC/Paper] branch deleted: dev/26.2
rustic folioBOT
rustic folioBOT
#

I could maybe see a use case for being able to set one part of the rotation relative and the other absolute, which wouldn't be possible with just an addRotation(yaw, pitch) method. I'm not immediately a fan of the current proposed method since I dislike having ambiguous boolean parameters in methods, something like a setRotation(Something.relative(2f), Something.absolute(90f)) could fix that.

#
U5B

From: https://github.com/PaperMC/Paper/issues/12986#issuecomment-3217402824
Hi, any updates? I've come up with another fix: let projectiles force-load the chunk they're in. Once that chunk can tick, the despawn-time has enough time to remove the projectile. For safety, we could cap how many chunks a single projectile can load. Does that sound feasible to you?

I have come up with a different solution plugin-wise. Since World.getEntities and World.getEntitiesByClass return all accessible entities, we can loop through all entities and exclude the ones that are ticking.

This code will remove all entities in non-ticking chunks, which is not good, but this could be a starting point if you are still having this issue
(I also have not benchmarked it at all)

for (final var bWorld : Bukkit.getWorlds()) {
	if (bWorld.getPlayers().isEmpty()) {
		continue;
	}
	final var list = bWorld.getEntities();
	final var chunksToLoad = new LongArraySet();
	for (final var entity : list) {
		if (entity```...