#paper
32502 messages · Page 33 of 33 (latest)
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]:...
Block chunks, entity chunks and POI chunks are different concepts. To block entity saving you would need to listen to https://jd.papermc.io/paper/26.1.2/org/bukkit/event/world/EntitiesUnloadEvent.html and remove those mobs
actually I'm not sure it's worth fixing it before mojang given this would break datapack changing the nested loot table and expecting it to work for those mobs and the warning is harmless.
I just don't see the use case given this will be exposed through the environmental attributes api and the tag can already be checked as well. The other isInDaylight method should probably be deprecated too given the meaning seems to have diverged across the time.
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...
The issue is also present on lower minecraft versions like 1.21.11
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```...
Keeping in mind that teleporting the player on join has always caused weird issues and side effects all around, the only supported way of changing the spawn location is by changing it in the AsyncPlayerSpawnLocationEvent, but given that the surrounding logic accounts for such thing this might just be valid
Oh thanks, didn't know the event exist.
@Lulu13022002 i add a way to expose the environment key for use in the copy of WorldCreator... if its better wait for the other PR for expose that info then you can rollback this change... but i feel this PR is ready for the first goal about create worlds with custom environments.
Fixes PaperMC/Paper#11208.
Uses the vanilla translatable shutdown message when no custom shutdown message is configured, while keeping custom shutdown messages configurable via bukkit.yml.
This is not a rich message
Fair point, I reverted that part and kept the existing legacy parsing. The PR now only changes the default to null and uses the vanilla translatable shutdown message as the fallback when no custom shutdown message is configured.
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...
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...
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"
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
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.
Sent an enquiry to mojang about it, will see what they say
Sent an enquiry to mojang about it, will see what they say
Thank you. I look forward to hearing about that :)
Ideally this is configurable in the datapack like the sea level, but doing it before mojang will cause issue if we do not match their fixes perfectly.
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.
Hi, i see the archive repo and 1.21.4 says its not the final stable version, so i think its expected in the README only show to 1.21.3
For now in draft as mache is not released yet.
I don't think this check does anything, players are not added the tracked list if their attribute is zero or less, same for the source.
This is a WAI since custom spear allow to dismount without doing damage/knockback so it's not related at all.
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?
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
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
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
/versionin the console. The Bukkit API version number is shown afterImplementing API versionstring.
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 change was for reset correctly the attack strength what its used in the getAttackCooldown method, the reset is being in the attack what is before the EntityDamageByEntityEvent now.
26.1.2.build.63-stable instead of the API one.
I don't really get what you're saying, 26.1.2.build.63-stable is the API version, it's io.papermc.paper:paper-api:26.1.2.build.63-stable
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
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.
Paper has hardforked from spigot over a year ago so this is not the Paper team's concern
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.
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);
}
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...
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?
That change was for reset correctly the attack strength what its used in the
getAttackCooldownmethod, the reset is being in the attack what is before the EntityDamageByEntityEvent now.
It works fine in Paper 26.1.2-54 , must be something wrong in Paper 26.1.2-55 I guess
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.^_^
It works fine in Paper 26.1.2-54 , must be something wrong in Paper 26.1.2-55 I guess
Like say in Paper 26.1.2-55 the reset of that cooldown is called now before that event (for parity with a pvp mechanic related to https://github.com/PaperMC/Paper/issues/13838), you can maybe use other events for that value like PrePlayerAttackEntityEvent
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```...
Tested with /summon pig ~ ~ ~ {DeathLootTable:"minecraft:entities/zombie"} and the entity in event show the loot table to being use.
Also for the cancel state the entity keep the loottable.
Missing override annotation
I wonder why this method is even called when the event is cancelled maybe check it before?
Didn't put it initially since that annotation is also missing on some other places, but will add it
The other place this method is used is for chested horse, which requires some special handling specifically when the event is cancelled, see https://github.com/PaperMC/Paper/blob/main/paper-server/patches/sources/net/minecraft/world/entity/animal/equine/AbstractChestedHorse.java.patch#L11
Sure you can add it to the other place as well.
It does the same check like here just not as an early return?
Umm right, had a brainfart here. Perhaps some residue of past handling. You'd prefer only calling the method when the event isn't cancelled?
Yes can then simplify the method to not take the event, you should also probably check shouldDropLoot before resetting the loot table since that path only ran after this check.
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?
Can you are Fix? Crash Server
This is not neither an error nor a crash
2186e1e Fix BlockRecieveGameEvent destination block - electronicboy
5c917da [ci skip] Fixed accidently test plugin changes - electronicboy
I originally did this before the hard-fork in PR #10314
Completely forgot about it until now, figured I would redo it with the requested changes
could this use the generator, to generate the enum automatically from NoiseGeneratorSettings
this also seems to miss the END and NETHER world types
But they're also valid world types in vanilla so maybe they should be included here as well
No, not easily and this type should be deprecated later once a more proper world gen api exists.
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
- Enable Anti-Xray
- Join the server
- Load chunks
- 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...
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
(The real way to go about this would be to just expose the key being used, if people want to check those against the default templated types that's their thing, but tying this to an enum in the era of registries is pretty flawed in the long run, and pretty sure this is already broken today given datapacks can define this stuff?
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.```...
What is the status on this?
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
applyFireworkEffectwas removed because that logic its only necesary forsetFireworkMeta - 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```...
Confirmed like you say the setItem use the previous item and mess with the final item being used.. also use unnecesary logic from the ItemMeta.
i make a PR for handle this https://github.com/PaperMC/Paper/pull/13891
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
This technically breaks the api but basically we have the data component api now and that app is scuffed so I think this is fine
I think obsolete is more appropriate until the item data component is not experimental
I think obsolete is more appropriate until the item data component is not experimental
hmm and the notice about use components api can be a <b>note<b> in the method o can just remove that mention?
The key is also a temporary measure ultimately the registry needs to be exposed and I don't think it's worth doing it rn. But the method should indeed stay deprecated.
apiNote is fine, also check ThrownPotion and other similar entities using item meta so it's consistent.
apiNote is fine, also check ThrownPotion and other similar entities using item meta so it's consistent.
Okay but i prefer make a new one for the ThrownPotion for keep the original intention of this PR (the fix of the issue and Firework Entity)
Did you figure it out a way to get that empty tag? I see the vanilla issue got closed.
Did you figure it out a way to get that empty tag? I see the vanilla issue got closed.
nope... unless any with the issue can tell the "history" of the world for even get that empty tag i dont see a way to get.. so im close this...
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_
Input for world names has never really be sanitized, you can create a world with name such as ../../rootworld and it will be in the parent dir. Usually this kinda is the case of just don't do it. If a malicious attacker has access to your server.properties or configuring of worlds, your server is gone either ways.
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.
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()```...
For reference, the issue its ItemStack not works in that phase of the server start, vanilla internally use other "type" of ItemStack for that phase what its current not available in Paper.
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);
}
Fixs https://github.com/PaperMC/Paper/issues/13895 where the LEFT_CLICK_AIR action is fired based in the block range but not in the entity range.
Yep looks like a duplicate of that issue, if can answer in that if the issue is still present in 26.1.2 can be good.
Adds a new event that is called when a player selects an item in a bundle.
This pretty much enables listening for scrolling above an item. Here are some usage examples for this event:
https://github.com/user-attachments/assets/0b4b5a16-7a2a-42de-8b47-37ed68246c2c
https://github.com/user-attachments/assets/982c8ae8-c2c8-4898-bd69-a1a5458b2e37
Add a comment why this is needed
(And maybe open a MJ bug)
Added in 0115042. I'm unsure whether this is a bug or behavior intended by Mojang, given how differently creative mode inventory actions are handled.
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...
I think it may be better to view this as an inventory event? As then you can instead act on a slot in an inventory so this can be better used in inventory guis.
Also, exposing the previous selected slot would be nice.
What's the actual purpose of these?
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.
How does this compare to vanilla? Generally this prolly won't be fixed because we prefer vanilla behavior.
Inventory event does make more sense as the supertype for this event: PlayerBundleItemSelectEvent now inherits InventoryEvent. Added slot and previous index/item fields.
Why modifying the line just to add the FQN?
Why modifying the line just to add the FQN?
This doesn't match any removed lines, are tou sure this is needed?
I moved the line below the Paper additions, as specified in the comment
That was unintentional, reverted in 7804af6
But you're not actually moving it if you'll look at the patch, you're just inserting the additions before it, so there's no need for this comment
Can this also be made cancellable? Also, move most of this logic to craft event factory.
Note you'll need to resend the item
Removed in a0ded529266c6fccdbd8fe96e9b8169042432fac
What's the actual purpose of these?
An option to set the List gamemode independently of the normal gamemode, similar to the Player List Name
That's the what but not the why - to disable spectator italics, or something else? Using the wrong game mode in player data for the client it belongs to has a whole bunch of bad side effects
I now moved all of the firing logic to the craft event factory; not sure how the logic could have been split up.
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`...
@Whatnoww You need check the worlds before to migrate because world and world_nether has the DIM-1 directory.. you need first (with the backup) remove the DIM-1 from the world and try again the migration
Im going to close this because based in https://github.com/PaperMC/Paper/issues/13863 its an issue where worlds to migrate share the same DIM directory.
Exists a PR https://github.com/PaperMC/Paper/pull/13872 for make more clear this error.
Thanks for your help, removing DIM-1 from under the world worked just fine.
This most likely will not be accepted. Using this for client hacks isn't something that is nicely able to be supported esp for the future.
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)
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
I don't think there was never any migration for removed configured features? I always thought the expectation was for you to just remove the invalid ones upon updating, this was previously also reported in #8277 which was closed as WAI
Please use the discord server for support next time, there is currently not enough to go off of here.
I'm leaning towards this being WAI, chunks and entities are no longer saved in the same spot so the API also shouldn't pretend that they are, is the EntitiesUnloadEvent missing anything that you'd need to solve your issue?
af0969f Fix some hunk comments pretending to include mojan... - lynxplay
I don't think this is the best way to resolve this, it would seem better to me to update the check in readModernModifications to avoid setting FORMAT_CHANGED to true if both the original renderer and the new renderer are default ones
More like a QoL update
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.
Unable to reproduce this issue with the steps you have provided, this issue is likely caused by one of your many plugins other than the ones you've already rules out.
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
Please re-test with just moonrise like Lulu asked if you still can
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
The paste has expired and the reporters account is also deleted, if this still happens in the current version then feel free to make a new issue.
Would you have any suggestions for how the administrator check could be improved in this case?
I'm leaning towards this being WAI, chunks and entities are no longer saved in the same spot so the API also shouldn't pretend that they are, is the EntitiesUnloadEvent missing anything that you'd need to solve your issue?
I forgot to reply to masmc, but yah that event works fine, thanks.
Maybe can be good add a message for notice comes from the config?
because the error just says cannot serialize and before of that the dimension....
I don't know how to install moonrise and I think it's a bit much to get me to install other software to test a bug. I've included a full description and the world download so anyone can replicate it, as long as the world download still gives the same result on paper then there is no more information required from me.
Yeah, use PrePlayerAttackEntityEvent.
The cooldown is computed before the damage is now, which is proper.
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
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.
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...
Adds documentation for the optional paper-generator project in CONTRIBUTING.md.
Changes
Documented the existence and purpose of the optional paper-generator module
Added instructions for enabling the project through paper-generator.settings.gradle.kts
This helps contributors better understand the development setup and optional project configuration available within the Paper repository.
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.
while documenting the generator, you should also document how to add things to it, when it’s useful and how to run it so that the changes you made get generated in the source
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...
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)
It would require more than that since the api allows several players to open same merchant, but most probably this needs a separate option to show the personalised costs
It would require more than that since the api allows several players to open same merchant, but most probably this needs a separate option to show the personalised costs
a little confuse if consider the builder require pass a Player to assign not?
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.
In case this was an issue when the API was added time ago i make https://github.com/PaperMC/Paper/pull/13906 with a change for make villager change the prices unless the recipe deny that..
@amownyy if wanna test the PR include a JAR with the change.
Yea seems fine
<img width="448" height="131" alt="Image" src="https://github.com/user-attachments/assets/d469dd92-2370-4809-a39d-f521bfb17112" />
There are currently no events that supply the blocks used in the creation of a golem which can be incredibly annoying to detect manually, the aim of this PR is to solve that by introducing an event exposing the blocks before a golem is spawned in.
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.
That doesn't really answer the question - to disable spectator italics, or something else? Using the wrong game mode in player data for the client it belongs to has a whole bunch of bad side effects
Yes, most likely to disable the spectator format.
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:...
This is a problem with Moonrise
and
#132
2026/5/11 19:43:09
c5eb0790f199da6c38d0a650e1e5cd5415b28185
Fork friendly byte buf correctly
paper-1.21.11-132.jar
The release is completely unrelated
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
Need a crash log, otherwise it's useless
Also looking at your list of plugins, it's just awful.
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 @ekill @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...
Yes
I used entity cleaning to restore the issue
I hope papermc 1.21.11 can fix this issue
Updated to the support series of papermc 1.21.11
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...
Thanks for the issue report, but this is most likely some kind of performance issue and not a bug.
It looks like you are repeatedly running the @e selector. This is incredibly bad for performance, as it will iterate through all entities on the server every single time
If you need further help, please use the #paper-help channel on our discord server for support with this.
I was thinking: would it maybe be a good addition for the event to expose a getSelectionDelta / getScrollDirection method to simplify the GUI scrolling handling? I'm guessing this event will mainly be used for GUI-related stuff anyway.
It does it in the other constructor where the namespace is derived from a plugin, but not when it is a string. It just runs String#toLowerCase on the namespace and key parameters, using the Locale.ROOT parameter.
The other constructor is doing that because the plugin name can be not lowercase which is valid usage. Here this is masking invalid inputs without the developer properly considering side effects
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.
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.
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.
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
-
Why wouldn't the client reflect the unswelling if cancelled, as it does if you back off from a creeper?
-
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?
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.
- 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...
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
- Have a plugin that creates/accesses ItemStacks on virtual threads (or any async thread pool)
- Multiple threads call ItemStack.getItemMeta() concurrently
- 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...
minimum reproduction? These operations are not thread safe
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?
No something in my unpick died. I'll force push over in a bit.
Fixed in latest pre release
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.
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, thedespawn-timehas 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```...