#paper
1 messages ยท Page 26 of 1
Currently the ticker can overflow naturally
thats a highly unlikely and edge case scenario. Sure the int can overflow after a staggering 3 years, but by that time you will have way worse issues with other integers which also increment by time. we can't base software on such insane scenarios
Should I just clamp the value to a minimum of zero for both the getter and setter?
just the setter:
Preconditions.checkArgument(ticks >= 0, "Ticks can't be negative");
I'm saying that mojang could change it to a long rather than an integer in the future
Again thats an highly unlikely and i don't see why mojang or any game would do that. there is not such thing as half ticks
Expected behavior
PaperSpigot 1.21.5-114-ver/1.21.5@a1b3058 (I know the new one just came out, but almost none of the plugins we use are updated yet. Ideally, this will be fixed in a 1.21.7 build.
ticks-per:
hopper-transfer: 6
hopper-check: 1
hopper-amount: 8
When using an autocrafter with hopper-amount: 8, items no longer distribute into separate unoccupied input slots as expected. Instead, all 8 items are inserted into a single slot per transfer tick. This breaks most vanilla autocrafter circuits.
Observed/Actual behavior
All 8 items go into the first compatible slot. This causes slot imbalances and prevents the autocrafter from crafting unless manually corrected. This makes it difficult to make a reliable circuit to condense iron bars into blocks.
Ideally, items fed into an autocrafter via hopper would bottleneck to one per tick to be a bit more consistent in terms of vanilla behavior.
Steps/models to reproduce
Plugin and D...
The thing just transfers an item, if we made it try to split the stack up that would defeat much of the reason why this option exists
Expected behavior
It shouldn't be a vulnerability
Observed/Actual behavior
When I'm opening my pom.xml file with Maven on Intellij IDEA, it shows me that paper-api is known as a Vulnerability about CVE-2025-48924
<img width="2425" height="362" alt="Image" src="https://github.com/user-attachments/assets/24914f07-6785-4b02-868d-01e9fbdfabb3" />
Steps/models to reproduce
1- Create Maven project
2- Add paper-api to dependencies with the paper repo.
3- Look Maven warning
Plugin and Datapack List
N/A because it's in Maven (Paper-api 1.21.7)
Paper version
N/A because it's in Maven (Paper-api 1.21.7)
Other
No response
Expected behavior
typo in craftworld equals()
public boolean equals(Object obj) {
if (obj == null) {
return false;
} else if (this.getClass() != obj.getClass()) {
return false;
} else {
CraftWorld other = (CraftWorld)obj;
return this.getUID() == other.getUID(); // uuid == uuid2 ?????????
}
}
This isn't a problem 99% of the time but i bet if a world was unloaded then loaded again this would break, .equals should be checking if its the same world, not exact same memory location
Observed/Actual behavior
a
Steps/models to reproduce
a
Plugin and Datapack List
a
Paper version
a
Other
a
21fb542 Do not write fall_distance tag unless it already e... - Spottedleaf
[PaperMC/Paper] New branch created: fix/dfu-falldamage-issue
8230a65 Dont eagerly write fall_distance on data upgrade - Owen1212055
This is mostly an issue for spawners, which check the spawn data has a size of 1 in order to apply special finalization logic when spawning the entity (giving items, etc)
Fixes #12837
[PaperMC/Paper] branch deleted: fix/dfu-falldamage-issue
Expected behavior
I simply created the server with the newest version of Paper, threw in 4 plugins- ProtocolLib, Simple Voice Chat, Veinminer, and Veinminer Enchant- and expected it to work.
Observed/Actual behavior
This error popped up in the server setup, seemingly disabling all plugins:
[19:22:23 WARN]: [MavenLibraryResolver] Use of Maven Central as a CDN is against the Maven Central Terms of Service. Use MavenLibraryResolver.MAVEN_CENTRAL_DEFAULT_MIRROR instead. java.lang.RuntimeException: Plugin used Maven Central for library resolution at io.papermc.paper.plugin.loader.library.impl.MavenLibraryResolver.addRepository(MavenLibraryResolver.java:124) ~[paper-api-1.21.7-R0.1-SNAPSHOT.jar:?] at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) ~[?:?] at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?] at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) ~[?...
These are just warning messages. Please post a full log. I see no plugins being disabled in the log excerpt you posted.
I'm not immediately convinced that invalid world instances should still be equal. That old World instance is invalid in so many ways.
I'm not understanding your issue with using the supported method, getRespawnLocation(boolean).
If the issue is the double redirect in javadoc deprecation, yeah, that can be changed.
World is an instance, not an identity; if you want identity comparisons, compare the identity. Making stale world instances equal the same as current world instances just sounds like a disaster; you should NOT be holding onto unloaded world instances
that is a false positive, we don't use the vulnerable class in apache commons.
paper itself doesn't directly depend on commons-lang, we pull it in via mojang. mojang hasnt updated it in 1.21.8-rc1 yet, but once they did we will automatically pull it in.
Actually i think it would be better to instead expose a setter for getCooledAttackStrength. so a float from 0 to 1. that seems more useful to plugins
What happens if you want to preserve the attack cooldown when changing someone's held item?
int ticks = player.getCooledAttackStrength(0F);
player.getInventory().setItemInMainHand(otherItemWithDifferentAttars);
player.setCooledAttackStrength(ticks, 0F);
The result would be undefined as the attack speed attributes could have changed.
It would requite that you do more calculations to achieve this, which would break if mojang ever changed the calculation of attack speed vs ticks. Whereas a simple getter/setter for the attack ticker would not.
This might be of utility though, so perhaps an additional method for setCooledAttackStrength?
imo replace, if someone for some reason needs to get the tick times they can just do the math on the returned/passed value.
I'm not understanding your issue with using the supported method, getRespawnLocation(boolean).
If the issue is the double redirect in javadoc deprecation, yeah, that can be changed.
getPotentialBedLocationis just deprecated cause its a bad name. beds aren't the only source of respawns, and it doesn't always return a bed location in modern minecraft.
There are two almost identical duplicated code methods, I think its an issue
did maven threaten to sue paper/spigot or are you doing this to protect the poor billion dollar corporation?
Terms of Service are the Terms of Service. doesnโt matter if itโs a multi-billion or a few thousand dollars worth company
We've done this because Sonatype has blocked a few MC hosting providers from accessing their servers due to the TOS violation. They have sent legal notices to others in the past, and I would generally not like to have to pay for a lawyer for a project I earn virtually ยฃ5 a month from.
Paper adds the capability of setting a "fixed" pose that is not updated every tick like normal. In certain situations, a plugin might have set a fixed pose and now wishes to reset the pose to a "natural" state. Sure, we could just use setPose with the current pose and fixed=false, but you'd have to wait until the next tick for the pose to update, and sometimes you need to get information from the new pose now.
This commit adds a new method for the Player class that clears the fixed pose state and immediately determines the correct pose based on the player's current state. Relevant player data, such as eye height, is immediately updated as well.
A practical example for why this is useful: In my plugin, I have a fixed swimming pose on the server-side, but obviously this doesn't carry over to the client. When the player fires a bow or launches a projectile, this would be useful to clear the fixed pose, compare the eye heights, and adjust the location of the new projectile accordingl...
This now requires a BlockPos/Entity be passed to the tryPickItem method and gets rid of the old signature. Could this be reviewed as I and others have relied on the method without a relevant BlockPos or Entity?
Is your feature request related to a problem?
Before the PDC API was a thing, a lot of plugins stored data (such as custom item IDs) directly in the item's NBT/now the custom_data component.
Nowadays the PDC API would be the way to do this, but any plugin that used to store data directly in NBT wouldn't ever be able to migrate from that, as old items could be laying around anywhere.
Describe the solution you'd like.
An "NMS API" (like the connection one for example) to let plugins register DFU fixes for their custom data, so that they are able to properly switch to modern options like PDC.
Alternatively if you wouldn't want to directly expose the DFU (and seeing as most plugins' use cases will likely be stuff like a string for custom item IDs), a registerMove("oldNbtKey", "newPdcKey") sorta setup could also work if possible (and maybe even be in UnsafeValues instead of NMS).
Describe alternatives you've considered.
Less ideal, but if the API had any way to get & set t...
22d80a3 [ci skip] Update Gradle wrapper and Fill plugin (#... - jpenilla
[PaperMC/Paper] branch deleted: chore/gradle-fill-update
One general big issue is that DFU only applies to upgrades of a data version controlled by mojang; i.e. you wouldn't be able to apply it reliably to existing worlds unless you managed to get them to install it before they updated their server
Expected behavior
-
Linking nether portals in 3D (x,y,z) for a chunk loader array in 3x3 grid. Meaning 2 chunks on overworld between the chunk the portals are in.
-
Inside 128 block range -> Portals should link to the closest portal depending on coords.
-
For chunk loaders that means Portal A drops players and items in Portal A nether side. Portal B on B nether side and so on.
-
Tested and confirmed in vanilla.
Observed/Actual behavior
Portals do link, but will sometimes forget what portal they linked to and prioritize a different one that is not alinged to it.
Steps/models to reproduce
-
Test wdl 1 in vanilla with player and also throw items (place a few blocks to catch a thrown item since portal hovers over lava).
-
Check F3 + G for mentioned chunk spacing (2 chunks).
-
Test red to red, vice versa. Blue to blue, vice versa. Red to nether blue, vice versa. Blue to nether red, vice versa.
-
Works perfectly.
-
Copy world to plain 1.21.7 #32 server and redo it se...
still broken on latest, anyone know a workaround?
There are two almost identical duplicated code methods, I think its an issue
The deprecation messages state why. There is a difference between the methods. I don't really see what the issue is
resolves #12848
redirects to the new method instead of the also deprecated one
d8cb3f5 Update DataConverter to 1.21.8-RC1 - Spottedleaf
[PaperMC/Paper] branch deleted: dev/1.21.8
[PaperMC/Paper] New tag created: 1.21.7
Stack trace
https://pastebin.com/raw/mYzd0Fj9
Plugin and Datapack List
Luckperms, FactionsSpawn, WorldEdit, WorldGuard
Actions to reproduce (if known)
Seems like if chunk loading is lagging, players can click near edge of chunk and crash whole server.
Paper version
1.21.7 32 (latest)
Other
No response
Could you send us the full log file?
I am unsure how much we can do there.
Introducing a sync chunk load is what it is. It is already scheduled at blocking priority in the chunk system.
The only potential "solution" here would be to consider clipping into an unloaded chunk a miss.
That however obviously is diverging from normal vanilla behaviour and might have unexpected outcomes.
Could you send us the full log file?
Sure, here it is: https://pastebin.com/raw/Znhq8nKX
1f93f56 [ci-skip] Improve getPotentialBedLocation deprecat... - notTamion
6fb36e3 Replace compileOnly with implementation for test v... - vjh0107
Rebased to 1.21.8 (and accidentally removed the lynx branch merge, my bad ^^)
Expected behavior
Particle speed should default to 0, NMS code for the particle command, with only a name and position argument, is:
Commands.argument("pos", Vec3Argument.vec3())
.executes(
context1 -> sendParticles(
context1.getSource(),
ParticleArgument.getParticle(context1, "name"),
Vec3Argument.getVec3(context1, "pos"),
Vec3.ZERO,
0.0F,
0,
false,
context1.getSource().getServer().getPlayerList().getPlayers()
)
)
Observed/Actual behavior
Spawning a particle with the API defaults the extra (speed) field to 1. paper-server code:
https://github.com/PaperMC/Paper/blob/6fb36e34b6bfc8442b8dbeb61cb82ad9ed39013b/paper-server/src/main/java/org/bukkit/craftbukkit/CraftWorld.java#L2166-L2169
and
https://github.com/PaperMC/Paper/blob/6fb36e34b6bfc8442b8dbeb61cb82ad9ed39013b/paper-server/src/main/java/org/bukkit/craftbukkit/entity/CraftPlayer.java#L3003-L3006
T...
Stack trace
https://mclo.gs/JpWsHI0 crush_server.txt
https://mclo.gs/6YwqQEj latest.log
Plugin and Datapack List
Plug-ins: AuraSkills, AuthMe, ChatItem, Chunky, CoreProtect, Crystal-TPA, eco, EcoEnchants, Essentials, fast-leaf-decay, libreforge, PlayerKits2, ProtocolLib, PyroFishingPro, PyroLib, SkinsRestorer, TabListPing, Vault, WildRTP, WorldBorder
DataPacks: There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
Actions to reproduce (if known)
No response
Paper version
This server is running Paper version 1.21.6-48-main@4d854e6 (2025-06-30T09:48:37Z) (Implementing API version 1.21.6-R0.1-SNAPSHOT)
Other
rng crashes. stable server work for 24> hours and suddenly crashes out for no reason
rebased to 1.21.8;
also are there any updates on this? would love to see this getting merged soon ^_^
This has been a default for ages, sadly we cannot really change that behavior without breaking many plugins in the process.
Adds a new material tag for almost all items in the creative redstone tab. Boats, wool, and bamboo raft is excluded as I don't know the relation between them and redstone and wools have a dampens_vibrations tag
One general big issue is that DFU only applies to upgrades of a data version controlled by mojang; i.e. you wouldn't be able to apply it reliably to existing worlds unless you managed to get them to install it before they updated their server
Yeah that's a downside sadly, but seeing as it's more-or-less the only solution I feel like people would be fine with adding it into their plugin and only making the actual code changes after an MC version change (unless I'm missing something and it doesn't work like that?)
This stack trace shows that the crash originates from the Minecraft server's internal world saving mechanism (DimensionDataStorage.saveLevelData and MinecraftServer.tickServer). The error message Formatting was not a
valid color: ยงm; Formatting was not a valid color: ยงn; Formatting was not a valid color: ยงo; Formatting was not a valid color: ยงk; Formatting was not a valid color: ยงl
It tells us that when the server is trying to save some data, it encounters these specific formatting codes and treats them as invalid colors.
I will take a look to see where exactly in the code we can make it so it doesn't default to crashing.
As a plugin dev, if I were in this situation, I imagine I would be doing the following:
- My plugin already would be refusing to load on newer MC versions than it recognizes, because of NMS-poking being dangerous.
- On a new major release, such as 1.22 for our current time of talking, I would use this API to ensure all chunks migrate cleanly.
- I would then leave this migrator API usage present for at least several years before even considering removing it.
I only see this having downsides for devs who have code that recklessly assumes things behave the same across versions if the code still runs.
This pull request introduces enhancements to color and formatting code validation in the Adventure library, specifically improving error handling and validation logic for distinguishing between valid colors and formatting codes. The changes aim to provide clearer error messages and better handling of edge cases.
Improvements to color and formatting code validation:
-
AdventureCodecs.java: Added logic to handle cases where a string starts with the 'ยง' character, distinguishing between formatting codes (e.g., 'ยงk', 'ยงl') and valid colors. If a formatting code is detected, an appropriate error message is returned instead of treating it as a color. -
PaperAdventure.java: Enhanced the error message in theasAdventuremethod to include the invalidChatFormattingvalue when a non-color formatting code is passed, improving the clarity of exceptions.occurs because:
- The TextColor.parseColor method in Minecraft is trying to parse formatting codes (like ยงm, ยงn, ยงo, ยงk, ยงl) as colo...
This pull request improves error handling and validation in the AdventureCodecs and PaperAdventure classes. The changes ensure better differentiation between formatting codes and valid colors, enhancing clarity and robustness in handling text color conversions.
Error Handling Improvements:
-
AdventureCodecs(paper-server/src/main/java/io/papermc/paper/adventure/AdventureCodecs.java): Added checks to identify and reject formatting codes (e.g.,ยงk,ยงl, etc.) when they are mistakenly passed as colors. This ensures that only valid color codes or named colors are processed, with appropriate error messages for invalid inputs. -
PaperAdventure(paper-server/src/main/java/io/papermc/paper/adventure/PaperAdventure.java): Enhanced the error message in theasAdventuremethod to include the specific formatting code that caused the exception, providing more context for debugging.
[https://github.com/PaperMC/Paper/pull/12863](Pull Request to fix this bug)
I made a pull request to fix this bug! @Xefoti
This does not actually fix the bug, nor is it really a bug.
The server had a scoreboard team with an invalid colour code (none colours, like m for strikethrough)
There is nothing here we can do bar I guess magically stripping those codes. Or the server administrator removing them.
Thank you anyway for the PR!
The server had a scoreboard team with an invalid colour code (none colours, like m for strikethrough)
There is nothing here we can do bar I guess magically stripping those codes. Or the server administrator removing them.
I am semi in the camp of "not much we should/could do" here, but I'll leave this open for more team opinions.
The server had a scoreboard team with an invalid colour code (none colours, like m for strikethrough) There is nothing here we can do bar I guess magically stripping those codes. Or the server administrator removing them. I am semi in the camp of "not much we should/could do" here, but I'll leave this open for more team opinions.
Why not just sanitize it? It makes it easier for less experienced server admins who want to use these plugins and may not know how to diagnose these issues. It would be pretty easy to just put in a catch right?
I mean we could sneak a custom data converter into a follow up version (1.21.9/1.22) for this.
Runtime sanitation for people using legacy colour codes in 2025 just feels bad if that makes sense.
The system has been effectively deprecated since 1.7 and the introduction of chat components.
@lynxplay
Ah that makes sense! Didn't realize it had been deprecated so long ago. That is solely on the plugin maker then.
I disagree, I highly doubt there are a lot of plugins that specifically use the default speed 1 and spawn particles like FLAME and use it as a feature.
If there has been a behavior change in last few updates then this is valid, otherwise we can't really just change defaults just because you deem it not useful.
aa4ef06 Update DataConverter constants for 1.21.8 - Spottedleaf
Like the Crafting Table, the Crafter menu uses different ID ordering than normal over the network. Unlike the Crafting table, the Crafter is weird.
https://minecraft.wiki/w/Java_Edition_protocol/Inventory#Crafter
Exact test conditions are checking getClickedInventory() instanceOf PlayerInventory, e.getClick().isRightClick(), as well as getCursor().getType() == Material.AIR, though I don't believe those are important.
The following code will fail with the current implementation, placing the item in the wrong place during an InventoryClickEvent.
InventoryClickEvent event; // example
// ...
event.getInventory().setItem(event.getSlot(), new ItemStack(Material.DIAMOND));
// OR
event.setCurrentItem(new ItemStack(Material.DIAMOND));
<img width="377" height="350" alt="Image" src="https://github.com/user-attachments/assets/124ae44d-8384-4dcb-9755-8792c3b3b9a2" />
<img width="384" height="350" alt="Image" src="https://github.com/user-attachments/assets/4e3dab93-6389-4a87-a9cd-fa1d4a9692...
I am unsure how much we can do there.
Introducing a sync chunk load is what it is. It is already scheduled at blocking priority in the chunk system. The only potential "solution" here would be to consider clipping into an unloaded chunk a miss. That however obviously is diverging from normal vanilla behaviour and might have unexpected outcomes.
Players can't move into unloaded chunks, why should they be able to interact with them? I don't think any possible vanilla feature could break from this, even then, maybe make it configurable like the player unloaded chunk movement blocker
I've implemented a fix for this on my own Folia fork that may be useful in resolving it properly
https://github.com/CallMeCarsub/Folia/blob/b22bc84294a3dcdbbbceefca58993ceeca732ba0/folia-server/paper-patches/features/0010-Fix-crafter-slots.patch
// The Crafter's result slot is indexed at the end rather than in first 10 slots
if(this.getType() == InventoryType.CRAFTER){
if(slot == 45){
// return the relevant slot (? untested)
return 9;
}
slot += 5;
}
The problem is that we don't have a mechanism to say "this plugin requires X version of MC and we should blow up initialization if it doesn't", that means that your players are going to update their servers and anything that loads in between them starting on the new version and loading up the updated version of your plugin is going to basically be lost, so you'd still be maintaining logic to have to deal with the old data; The modding ecosystem is generally much more tightly defined against MC versions so has a real advantage there in terms of making sure that people upgrade properly
An API for moving custom_data stuff into the PDC does sound fine, it would just require somewhat fairly early registration support in oder to allow people to deal with data that might load before plugins have a chance to register
I won't argue with your decision, since it's ultimately your (or your teams'). However I would still like you to consider that this behavior is different than the one in vanilla and leads to unexpected results in some particles.
Speed has defaulted to 0 for the longest time, but, changing behavior in such a core part of the API mid release cycle is generally bleh, that's the sorta thing you slip into a bit of a larger release so that devs have time to test and mitigate any issues
I think isMarkedInvulnverable or isForcedInvulnverable and isInvulnerableTo would be good names for the methods. Deprecating isInvulnerable is fine.
Expected behavior
- A resource pack is loaded on
AsyncPlayerConnectionConfigureEvent - When a
CraftPlayerinstance is created, the resource pack status for that connection is written toCraftPlayer#resourcePackStatus Player#getResourcePackStatus()returns the proper status andPlayer#hasResourcePack()returnstrueif the pack loading succeeded
Observed/Actual behavior
- A resource pack is loaded on
AsyncPlayerConnectionConfigureEvent - When a
CraftPlayerinstance is created, the fieldCraftPlayer#resourcePackStatusstaysnull Player#getResourcePackStatus()returnsnullandPlayer#hasResourcePack()returnsfalseuntil a pack is loaded during the game phase
Steps/models to reproduce
- Load a pack in an
AsyncPlayerConnectionConfigureEventevent handler - Call
Player#getResourcePackStatus()andPlayer#hasResourcePack()when the player joins the game - Get the values
nullandfalserespectively despite the pack being active on the client and the pack callback p...
I added isInvulnerableTo(DamageType) and isMarkedInvulnerable
Deprecated isInvulnerable and linked to the new methods in the docs.
I am probably overthinking this right now, but in my opinion the @deprecated note should also convey what it actually returns (damage invulnerability to generic damage and stuff)
^ the move to Connection was suggested in #paper-dev on Discord
but also I don't want to over-explain the deprecation
feel free to give a bit more context in the deprecation message. I don't have the source infront of me right now but that method seemed pretty useless anyways (given it only checks for api invuln and one more thing afaik).
Btw i think you will need to add an override for craftlivingentity which uses the isInvulnerableTo method instead of isInvulnerableToBase so all the conditions of the entity apply. (don't have the source infront of me rn like i said so im not 100 % sure)
given it only checks for api invuln and one more thing afaik
It also checks whether the entity is dead, in creative mode, and other stuff
<img width="1025" height="157" alt="image" src="https://github.com/user-attachments/assets/e04dbfb0-6641-4803-a489-42d9fc73a0dc" />
Btw i think you will need to add an override for craftlivingentity which uses the isInvulnerableTo method instead of isInvulnerableToBase so all the conditions of the entity apply.
You are right, totally forgot about that.
It also checks whether the entity is dead, in creative mode, and other stuff
Yeah tho most of that doesn't apply to GENERIC
f7c59f9 Fix broken resource pack API when configured in co... - metabrixkt
Just got a report from a player that's having the same issue. Hoping to see this fixed soon :+1:
0dad7f1 Add Bee#set/getTimeSinceSting() methods (#12792) - Umbre11as
782ce95 Allow forcing break effects when using breakNatura... - Fisher2911
This PR makes Plugin extend adventures Namespaced and implements the Namespaced#namespace() method in PluginBase.
Motivation
This allows passing a plugin instance as namespace into Key#key(Namespaced, String) (or anything that accepts a Namespaced instance). I laid out my personal use case for this in [discord](#paper-dev message) (although very very simplified), but I believe this could be useful to have in general.
Even if the benefit for my personal example is just a minor QOL thing, it seems as NamespacedKey is only actively being used in spigot code from before the hard fork and is supposed to be phased-out eventually (#10568 - although I'm unsure how up-to-date this is). So this change would also allow for an easier transition from NamespacedKey -> Key for developers.
Open questions
Should I also change the following methods in NamespacedKey to accept a Namespaced instead of a Plugin:
new NamespacedKey(Plugin, String) -> new NamespacedKey(Namespaced, String)
NamespacedKey#fromS...
I think that's a nice change. I cannot really answer your open questions, those are better of answered by a maintainer ^^, but I can tell you that you should try to not do any code cleanup in those files as that can be done by whoever finally merges the PR. You wanna keep the diff as clean as possible so it is easily reviewable.
im having it too in 1.21.7
Some things I spotted that might need fixing:
- primitives (fields params and returns) require nullability annotations
- void returns require nullability annotatins
@NonNull(nullability information in general) infront of the modifiers is allowed if it is on the same line as the method but should only be allowed AFTER the modifiers - example:@NonNull public static Xis allowed but should bepublic static @NonNull X- deprecated (not marked for removal) class are still checked which seems redundant
- there is no rule about the order of nullability annotation and
finalin method parameters, should it be@NonNull finalorfinal @NonNull - package-private and interface methods should be allowed (or even required) to have the nullability annotation not on the same line as the target
Move this logic into CraftPlayer instead of creating a new method here. Use an access transformer to make the updatePlayerPose method public
Expected behavior
Ender pearls teleport the player after a relog.
Observed/Actual behavior
Ender pearls do not teleport the player after a relog.
Steps/models to reproduce
- Have legacy-ender-pearl-behavior set to 'true'
- Throw ender pearl in a stasis chamber
- Log out of the server
- Log back in
- Flip the pearl
- Observe no teleport
Plugin and Datapack List
No plugins or datapacks
Paper version
This server is running Paper version 1.21.8-6-main@782ce95 (2025-07-18T20:26:58Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.7-10-6ea679e (MC: 1.21.7)
Other
Note: this does NOT occur if legacy-ender-pearl-behavior is set to 'false'. It only occurs when legacy-ender-pearl-behavior is set to 'true'. If the pearl is thrown while it's set to 'true', then you relaunch the server with it set to 'false', then flip the pearl, it still does not teleport you. This suggests that pearl data is permanen...
6e3a74a Update to configurate 4.2.0 - Machine-Maker
[PaperMC/Paper] New branch created: feature/update-configurate
53b4e65 enable test suites again - Machine-Maker
Makes CommandExecutor and TabCompleter functional interfaces. I don't think FunctionalInterface existed when these classes were written, but they both seem like good candidates for it. I think it would add a bit more convenience.
Pretty sure this annotation only adds some guide ropes, it has no actual functional change on usage, only on modification
Expected behavior
Cratblock.setBlockState()
if (applyPhysics) {
return world.setBlock(pos, newState, net.minecraft.world.level.block.Block.UPDATE_ALL);
} else {
boolean success = world.setBlock(pos, newState,
net.minecraft.world.level.block.Block.UPDATE_CLIENTS |
net.minecraft.world.level.block.Block.UPDATE_KNOWN_SHAPE |
net.minecraft.world.level.block.Block.UPDATE_SKIP_ON_PLACE);
if (success && world instanceof net.minecraft.world.level.Level) {
world.getMinecraftWorld().sendBlockUpdated(
pos,
oldState,
newState,
net.minecraft.world.level.block.Block.UPDATE_ALL
);
}
return success;
}
}
if ((flags & 2) != 0 && (!this.isClientSide || (flags & 4) == 0) && (this.isClientSide || chunkAt == null || (chunkAt.getFullStatus() != null```...
I mean, the set block stuff is generally a mess due to the whole fact that it's around evolving code and there are many oddball CB hacks which might not cause it to always immediatly apply; I'd guess as with everything, the question boils down to "what happens if it's removed", does it break in certain cases, etc
the flags passed into sendBlockUpdated are completely unused, I can say pretty confidently that sendBlockUpdated is called twice with the exact same parameters (excluding flags)
// oldstate comes from this.getChunkAt(pos).setBlockState(pos, state, flags) (setblockstate returns replaced block state)
BlockState state = newState;
BlockState blockState = oldState;
if ((flags & 2) != 0 && (!this.isClientSide || (flags & 4) == 0) && (this.isClientSide || chunkAt == null || (chunkAt.getFullStatus() != null && chunkAt.getFullStatus().isOrAfter(FullChunkStatus.FULL)))) { // allow chunk to be null here as chunk.isReady() is false when we send our notification during block placement // Paper - rewrite chunk system - change from ticking to full
this.sendBlockUpdated(pos, blockState, state, flags); // pos, oldState, newState
}
// oldstate comes from this.getNMS(), which calls this.world.getBlockState(this.position)
// new state identical to that which```...
There exists various states inside of setBlock which will not cause that logic to be called, it should be called later, however, is my understanding. I am pondering if there exists some cases that that duplicate logic fixes, esepcially in regards to that gating or plugins doing stuff.
Expected behavior
I use teleport flag to retain passengers and passengers are kept when you teleport from 1 world to another. (it works fine for teleporting in the same world)
Observed/Actual behavior
It literally does nothing. Teleport effects called with the retain passengers teleport flag, if the player has passengers and they are being teleported to a new world, do absolutely nothing. I get no errors, no chat messages, the player just doesn't get teleported.
Steps/models to reproduce
- Create a new papermc server (I tested it on 1.21.4 and 1.21.8)
- Make a new paper plugin and somewhere in there (probably a command/event) teleport the player to a location in the nether (or any alternate world) using teleport flag retain passengers
- Watch as nothing happens
Plugin and Datapack List
<img width="962" height="95" alt="Image" src="https://github.com/user-attachments/assets/135dfe68-6385-45e7-bbf0-bde168a60a4e" />
Paper version
1.21.8-R0.1-SNAPSHOT
O...
I don't really see how the event is broken rn. sure it fires every tick when cancelled but so does PlayerReadyArrowEvent. Is there any problem with this behavior except it firing every tick?
Expected behavior
I believe the dataconverter should be able to convert the data from json to nbt.
Observed/Actual behavior
Errors like the following just get spammed in console.
[12:37:11] [Server thread/ERROR]: [ca.spottedleaf.dataconverter.minecraft.versions.V4290] Failed to convert json to nbt: Aquatic Annihilation
com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Use JsonReader.setStrictness(Strictness.LENIENT) to accept malformed JSON at line 1 column 10 path $
See https://github.com/google/gson/blob/main/Troubleshooting.md#malformed-json
at com.google.gson.JsonParser.parseReader(JsonParser.java:116) ~[gson-2.11.0.jar:?]
at com.google.gson.JsonParser.parseString(JsonParser.java:92) ~[gson-2.11.0.jar:?]
at ca.spottedleaf.dataconverter.minecraft.versions.V4290$1.convert(V4290.java:235) ~[paper-1.21.8.jar:1.21.8-6-782ce95]
at ca.spottedleaf.dataconverter.minecraft.datatypes.DynamicDataType.convert(Dynamic...
This issue seems a bit different because it works for me to do what they did in their example, of teleporting to the same world you are already in. This issue only occurs when you travel across worlds for me.
Closes https://github.com/PaperMC/Paper/issues/12860
Makes the codec lenient on both serialization as well as de serialization.
I am also experiencing this in 1.21.8
a2d37f1 Remove invalid team colors nicely (#12874) - Machine-Maker
ea32a44 Fix issue for brand new configs - Machine-Maker
[PaperMC/Paper] branch deleted: feature/update-configurate
I don't think there is much use in changing the namespaced key ctor params, there isn't really anything Namespaced that you'd be passing in there that such a change would benefit.
Cleanup is not needed, will happen once we merge checkstyle into our CI pipeline :+1:
The PR looks good to me!
Essentially, you have an invalid item in the playerdata. The game expects JSON there, but it got a plain string ("Aquatic Annihilation"). Based on the string would guess its the name of an item. Could also be lore, content of a written book or similar though - the error is very unhelpful here.
Vanilla will fail in the same place. We can probably fix this, but it would be important to know the item got created like that in the first place so we can prevent it from happening again in the future.
Do you have any suspicion as to which plugin was originally used to create the "Aquatic Annihilation" item? If it is an item at all.
May have happened a few versions ago or similar, but any clue could be helpful.
Its not going to be the plugin in the stacktrace, thats just whatever tried to load the playerdata. The issue lies in how the item was created in the first place.
I've tried vanilla /give in various versions ranging from 1.13 to latest, and it will correctly refuse to create such...
602ea9f Restore previous PlayerToggleSneakEvent behaviour... - ookiegajwa
c8a8c0e feat(plugin): make Plugin extend Namespaced (#1286... - Emilxyz
Thank you for the PR and welcome to paper :partying_face: !
I am closing the PR as I don't think we want to pull this.
The creative mode category API might not be very complete but it should allow for some basic filtering/checking of materials against their category.
A new tag here just seems like a bandaid fix. We should expand the creative mode API instead (tho there are PRs for that).
Thank you again for the contribution!
The server has never been reset and opened in march of 2011 so I am guessing here. From what I can tell, some are from Head Database spawning in heads, players naming their items, or something else. At one point, heads from players dropped and were modified by a plugin.
The reason the environment variable for the secret was exposed was secret management in k8, especially when also applied in a multi proxy setting.
A "configure your server via environment variables instead of yml" was not really the point of the original PR so I am a bit hesitant on this PR right now.
I am receiving the same error https://mclo.gs/E128mNZ - The item below was spawned in on a 1.21.1 (or 1.20 I can't exactly remember) server using the command below.
minecraft:give @a firework_rocket{Fireworks:{Flight:1,Explosions:[{Flicker:1b,Trail:1b,Colors:[I;11546150,16351261,15961002],FadeColors:[I;3847130,3949738,8991416]}]},display:{Name:'Party Popper Firework',"italic":false,Lore:['["",{"text":"Crate","italic":false,"color":"red"}]']},HideFlags:32}
Okay I can reproduce it.
- Run
/give @s minecraft:firework_rocket{display:{Name:'Party Popper Firework',"italic":false,Lore:['["",{"text":"Crate","italic":false,"color":"red"}]']},HideFlags:32,Fireworks:{Flight:1,Explosions:[{Flicker:1b,Trail:1b,Colors:[I;11546150,16351261,15961002],FadeColors:[I;3847130,3949738,8991416]}]}}on 1.20.4 - You will get a Firework Rocket named "Firework Rocket" visually, not "Party Popper Firework". The client correctly ignores the invalid name.
- However, the server does not. Running
/paper dumpitemshows thatNamedid indeed get set to a plain string - Update the server to Paper 1.21.8
- You get the
MalformedJsonException.
Notably, vanilla DFU will just silently remove the Name property from the item instead of blowing up with an exception.
I understand that the focus of the original PR was secret management. As mentioned in my PR description, the secret alone does not suffice to configure velocity though. And I am really wondering how other people managed to get paper running on k8s without the newly introduced environment variables. K8s ConfigMaps don't work as they are mounted read only. The first thing spigot does at startup is reading and then re-writing the yaml config to disk so it crashes. Two options remain: Env variables or a persistent volume that behaves as a regular disk. The first option is contained in this PR. The second option would be ok-ish too but it's sooo hacky: If you have servers that get discarded anyways (like minigame servers), you don't want to use a persistent volume. If you use a temporary filesystem instead, you first have to create the required configuration files which isn't possible using the initSettings command as mentioned before. IMHO, env variables are the best option for configuring...
Coming from the Java Enterprise world (Application Servers, Quarkus, and Spring Boot), I might be a bit spoiled - we've had the Eclipse MicroProfile for several years now. One of its standout features is the MicroProfile Config API, which provides a flexible abstraction layer over various configuration sources. Most implementations support properties files, YAML, environment variables, and even more enterprise-specific options like JDBC, JNDI, and HashiCorp Vault - though many of those might not be particularly relevant for Paper.
I'm not sure how many people (besides me) are running Paper in Kubernetes environments, but it would be amazing to make everything configurable from any source. I'd be happy to contribute some time and share my experience from the Java Enterprise ecosystem to explore whether Eclipse MicroProfile (or a similar abstraction) could make sense for Paper.
That said, I'd love to hear the team's thoughts on this first. From what you mentioned, it seems like con...
env-based config stuff has been on the "maybe cool to have", but it would need to be integrated in some manner into the configurate configuration library. However, such a concept just seems fairly limited, especially when it comes to non-primitive entries and such. We generally won't be migrating away from configurate unless something solves something it doesn't in a substantial manner, there just isn't the demand or resources for us to cater to these sorta setups, anybody at the scale of needing such envs is generally forking to cater for their needs anyways
I've thought about setting up something where simple primitives could be overriden by environment variables. I don't want to get crazy with it, where we have some crazy way env vars can set lists or full objects. But detecting simple enough primitive values, and generating an env var key based on its path should be doable.
Have to do it in such a way to merge it into the config node without writing it back out I think, that might be harder.
An alternative we could potentially investigate a bit further is supporting ro configuration files.
In general, our migrations and defaults don't need to be written back to file, just obviously makes editing
the files worse if keys are missing and the file is not on the latest version but that can be up to the administrators then.
I believe we currently don't fail if the paper configs cannot be written to?
We presumably error very loudly but it should startup and run the migrations on the in-memory representation.
Idk if that is applicable to spigot.yml and bukkit.yml, those use a different system rn.
RO config files are one of those weird ones where I think we shifted some concessions towards (but, this is one of the areas why I kinda supported it, even if it makes no sense for most setups and is often an early warning sign something is wrong)
afaik, k8s would let you expose a config file in the container from the ConfigMap or whatever it was, but I don't have the resources to waste time learning all of that stuff yet
Unfortunately, paper does not ignore read only (in a k8s environment)
[19:11:54 ERROR]: Encountered an unexpected exception
org.spongepowered.configurate.ConfigurateException: []: java.nio.file.FileSystemException: /opt/paper/config/.7199899733415571904970619paper-global.yml.tmp -> /opt/paper/config/paper-global.yml: Device or resource busy
at org.spongepowered.configurate.loader.AbstractConfigurationLoader.save(AbstractConfigurationLoader.java:211) ~[configurate-core-4.2.0-20250225.064233-204.jar:?]
at io.papermc.paper.configuration.Configurations.trySaveFileNode(Configurations.java:113) ~[paper-1.21.7.jar:1.21.7-DEV-68488bd]
The server crashes and shuts down. Maybe it's overkill to migrate the entire file configuration to a different system. Everything that can be configured at runtime like game difficulty doesn't need to be exposed using some other configuration system. Properties that need to be set before server startup would be nice to be exposed some...
In case anyone wants to reproduce it in k8s, here's a shortened version of my setup:
apiVersion: v1
kind: ConfigMap
metadata:
name: paper-global-config
data:
paper-global.yml: |
_version: 29
anticheat:
[...]
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: paper
labels:
app.kubernetes.io/name: paper
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: paper
template:
metadata:
labels:
app.kubernetes.io/name: paper
spec:
containers:
- name: paper
image: my-registry/paper:1.21.7-26
volumeMounts:
- name: config-volume
mountPath: /opt/paper/config/paper-global.yml
subPath: paper-global.yml
volumes:
- name: config-volume
configMap:
name: paper-global-config
I'm willing to put in some time to tackle this. Before I start, it would be appreciated if someone could clarify whether this is intentionally no longer supported, or if it was indeed an oversight?
It was (intentionally) dropped by leaf during 1.21.5/6 dev with the major DFU refactors
Okay, thanks for the clarification! Then I'll homebrew something instead
This PR introduces a spatial data structure used to find the nearest player for the purposes of despawning mobs.
Currently, every mob loops over every player per tick to determine if they are:
- Eligible for despawning mobs (not in spectator mode)
- The closest player to that mob
This is effectively an O(n ^ 2) operation with per-player mob spawning.
In this PR, we construct a K-d tree (k=3) with every despawn-eligible player every tick and use that to find the closest player to determine whether the mob should despawn. This is a very efficient data structure for nearest-neighbour searches (the implemented data structure is an adapted version from the book "Algorithms In A Nutshell").
I have also changed the despawnRanges config option to be represented as an EnumMap rather than a HashMap to make it more efficient.
I considered using the NearbyPlayers class, however it raises a couple complications that made me decide against using it in the end. It stores players by...
minor, but might as well set initialCapacity to players.length here
Could but not quite an exact match because the array could end up being filled up smaller
[PaperMC/Paper] New branch created: feat/disable-ear
This option is special in that:
- On new server creation, EAR will be disabled.
- For those who already have spigot.yml, EAR will be enabled.
I tried doing this without bumping the version since I know we are planning on modifying these configs...
opinion appreciated
Why not just set the defaults to 0? That will disable it by default too, and will also only affect new servers.
Having another config option just to disable a config option seems quite convoluted and confusing to me, especially if its in the same file.
My idea with having a separate one is to make it easier for people to enable it. As you have to manually specify like 4 different values.
I would also very much like this for my server, would optimize things a ton
It's not cancellable, as stated by what the PR fixes in my messages. In addition to this, just because two events are broken, doesn't make both of them working. Firing of the event is what the entire event is for, therefore it is 'broken' if it doesn't fire properly.
It's not cancellable
How is that? I am able to keep the event cancelled just fine.
just because two events are broken
PlayerReadyArrowEvent behaving like this is intentional see #12111.
Events being fired a lot does not mean they are broken. I do agree that for EntityCrossbowLoadEvent the expected behavior of cancellation is debatable though given plugins might rely on this to e.g. delay crossbow loading this just seems like a pointless api break. if you want to have the player stop using the crossbow you can call clearActiveItem in the listener.
Great PR thank you kennytv
a5f2f61 Fix offhand item desync on cancelling interact eve... - kennytv
[PaperMC/Paper] branch deleted: offhand-desync
Adds PlayerPreTeleportEvent to address various issues with teleporting mentioned in #12093 & #10168.
Currently there is no way to handle teleporting players cross-worlds with vehicles and passengers as the PlayerTeleportEvent fires after the checks for vehicles and passengers.
Implementing this event would allow for intercepting of the teleport before it occurs and allow for the correct handling of the vehicle/passengers.
Adds PlayerPreTeleportEvent to address various issues with teleporting mentioned in #12093 & #10168.
Currently there is no way to handle teleporting players cross-worlds with vehicles and passengers as the PlayerTeleportEvent fires after the checks for vehicles and passengers.
Implementing this event would allow for intercepting of the teleport before it occurs and allow for the correct handling of the vehicle/passengers.
The goal really is to align with the vanilla teleport logic rather than the CB logic and having a bunch of hacks
Really iffy on these sorts of events. Adding in early mutation points for stuff they don't really need, like the Location, is kinda bleh. Nor should we really be returning mutable location objects in the API There is zero info on whether a teleport will succeed or not, which feels like it kinda misses the bar in terms of what it's trying to solve
The goal really is to align with the vanilla teleport logic rather than the CB logic and having a bunch of hacks
Really iffy on these sorts of events. Adding in early mutation points for stuff they don't really need, like the Location, is kinda bleh. Nor should we really be returning mutable location objects in the API There is zero info on whether a teleport will succeed or not, which feels like it kinda misses the bar in terms of what it's trying to solve
hello ๐๐ป Thank you for your reply! I understand that the goal is to align with the vanilla logic. This was mentioned by Malfrador in #12093 a feature request that I made a while ago and we both spoke in.
I also agree with not having a bunch of hacks/work arounds, but if there is no intention of implementing/aligning with the vanilla teleport logic (as its been nearly two years since the last pull request #10173 with a similar goal was created). Is it possible to be implemented and then deprecated when moved over?...
It's also questionable if such an event should be cancellable.
But yeah, when working on #10173 I more and more realised that such an event doesn't really make much sense in a way to justify adding it.
However, as stated and discussed in my PR a TeleportFailEvent might make more sense in this case as you could then prepare the entity for teleportation.
It's also questionable if such an event should be cancellable.
But yeah, when working on #10173 I more and more realised that such an event doesn't really make much sense in a way to justify adding it.
However, as stated and discussed in my PR a
TeleportFailEventmight make more sense in this case as you could then prepare the entity for teleportation.
I am personally happy with either approach. ๐คท๐ปโโ๏ธ
Its just kind of a pain that currently there is no way to deal with this and hopefully some sort of a solution can be implemented.
This PR adds a method to check if an entity should be removed on the peaceful difficulty and adds a method to change the behavior. I considered a cancellable event, however it seems like that this check is done every tick, so I decided for this approach.
The value also gets persisted in the entity data. However, I'm not sure if the data should be persisted when set to Tristate#NOT_SET. E.g. VisualFire is persisted even when set to NOT_SET, but I'm not sure if saving that data for every mob is necessary.
On the NMS side I decided to add a new method (shouldActuallyDespawnInPeaceful) as running this method in the only two places it is used is much cleaner than modifying shouldDespawnInPeaceful in every entity that implements it (like Ghast, Monster, etc.)
My usecase for this is the following: We use Entities like Zombies to represent spawn locations etc. in our setup on our map building server. However, most maps are set to peaceful so we are limited in the amount of entities t...
This is a server issue also present in vanilla (reproduce with /item replace) and doesn't just apply to the offhand but to all equipment slots.
The reason it happens is because in the player tick method broadcastChanges is called on the player's containerMenu. When you have a container open, this is the container menu, otherwise it is the player's inventory.
The player inventory menu contains the slots for equipment, while the container menu does not.
Also calling broadcastChanges on the ServerPlayer's inventoryMenu seems to fix the issue but obviously also leads to double checking of the player inventory slots.
Fixes #12798, also re-fixes #4869.
I would like to suggest adding a "resendchunks" sub-command to "/paper". This can be very useful for debugging, and a number of projects which inherit code from Paper have already added this functionality (such as DivineMC).
Can you give an example of debugging helped by this? I can't think of any plugins I've ever written that would have benefitted from this. Feels pretty niche, in "could be a plugin" territory.
Adding to this as of 1.21.8 Paper #11
Happy Ghast distance stat is broken
(what I noticed with the horse, boat & happy ghast ... the stats keeps increasing even when I'm just sitting on it, but not moving at all the other rideables just count the distance wrong when moving)
Still broken are:
- Strider (Strider distance is weirdly counting way to fast up ... but it actually stops counting when sitting on it but not moving)
- Horse
- Boat
- Pig
Note: I know that this seems to be an long standing issue, just wanted to add what I figured out. Noticed since some custom achievments popped way to early.
- Drei
[PaperMC/Paper] New comment on issue: #12868 1.21.8-6: Ender pearls don't teleport you after a relog
Did this use to work on 1.21.7-10-6ea679e for you?
[PaperMC/Paper] New comment on pull request: #12884 Fix legacy pearls forgetting owner on disconnect
Looks like the original else was there to fix a memory leak, only during some patch update it got changed to wiping the owner in general; need to double check how the entity ref object works
Is your feature request related to a problem?
Currently there's an issue with displaying items in shopkeeper/villager trades. The output section like what you'll receive does not appear causing confusion for players. This occurs on both 1.21.7 & 1.21.8
Describe the solution you'd like.
I'm pretty uneducated in this stuff idk what we'd need to do to fix this issue. However I do believe it's something that needs to be taken care of. I'm not sure if it's a paper problem or a minecraft problem at this point.
Describe alternatives you've considered.
Using deluxemenus instead of shopkeepers.
Other
https://github.com/user-attachments/assets/e0e6df74-8b58-4107-b09f-1f492032e06f
Discussion Category: Ideas
Is your feature request related to a problem?
This is not related to a problem. This would simply make it easier for me to know if there are updates to paper within the same game version or updates to a new game version.
Describe the solution you'd like.
When I run /version, paper tells me I'm running the latest version. with some additional info. I think it would be useful if that was split into latest version of paper for version X vs latest version of paper. For example, "You are running the latest version of paper for 1.21.4 (232). You are not running the latest version of paper (1.21.8-11)."
I don't know exactly how easy this would be to implement or what the exact wording should be.
Describe alternatives you've considered.
Open https://papermc.io/downloads/paper and manually check.
Other
<img width="616" height="128" alt="Image" src="https://github.com/user-attachments/assets/b057e1a8-8d87-4793-bb61-a6f7a85b5d10" />
Notice it says I'm running the latest...
There is a pr that would partially solve this, see #12589 , i think that approach could also be copied to the version command in itself too but im not sure if its doable
bfaafed Update mache for codebook 1.0.15 - lynxplay
[PaperMC/Paper] New branch created: bugfix/update-mache
See: PaperMC/mache@b8569458bb74c0c66c98a85a85a28cdec737225e
See: PaperMC/codebook@d6217a18733c0031c1f2fb565834e7d9f6e81684
1031877 [ci skip] Update mache for codebook 1.0.15 (#12887... - lynxplay
[PaperMC/Paper] branch deleted: bugfix/update-mache
Expected behavior
players on 1.8.8 are able to join and play normally, without getting kicked when their game stutters
Observed/Actual behavior
this recent paper patch is very ruthless with players on legacy clients as any sort of delay or stuttering (e.g. high ping, low fps) will cause them to get kick instantaneously after they send a keepalive packet.
Youtube demo: https://youtu.be/Vq8uhkEsET4
it also has no care for if its actually the player or the netty thread being congested, since its time between player and main thread not player and server.
Steps/models to reproduce
- Join a server with ViaVersion, ViaBackwards, ViaRewind on a 1.8.8 client
- Turn on 3D Anagylph to make your game stutter/freeze on purpose
- Wait 2 or 3 seconds
- Get kicked
Plugin and Datapack List
[03:57:09 INFO]: Paper Plugins (3):
[03:57:09 INFO]: - HuskSync, ScPaper, towns
[03:57:09 INFO]: Bukkit Plugins (28):
[03:57:09 INFO]: - *Achievem*```...
Is this an issue for Java clients using the current version, without ViaVersion?
No, just 1.8.8 clients but I havent tested other versions.
I tried this on purpur with use-alternate-keepalive set to true and it didn't seem to fix the issue.
No, just 1.8.8 clients but I havent tested any other legacy versions. I tried this on purpur with
use-alternate-keepaliveset to true and it didn't seem to fix the issue.
Just confirmed this does not occur on 1.12.2
If it has no impact on 1.21.8 players, then this feels like something to report to ViaVersion.
alright ill just do that then, thanks
Expected behavior
The projectile should keep tracking, instead of phasing to where it lands.
Observed/Actual behavior
Steps/models to reproduce
Shoot arrows while moving forward on a 1.21.8 paper server with no plugins, the arrows will desync. This bug does not happen on 1.21.8 vanilla
Plugin and Datapack List
None
Paper version
This server is running Paper version 1.21.8-11-main@a5f2f61 (2025-07-22T08:53:33Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-DEV-25e1915 (MC: 1.21.4)
Other
Maybe related to https://github.com/PaperMC/Paper/issues/12200
Hm I can't seem to reproduce this
Hm I can't seem to reproduce this
Try with some artificial ping, I noticed it more when I had lag.
Expected behavior
one time Trigger
Observed/Actual behavior
Triggering twice
Steps/models to reproduce
When I left-click an item in my inventory so that it's on the cursor, and then left-click on a free slot while holding the mouse button, slightly move the mouse, and then release the button, the ServerboundContainerClickPacket and ClientboundSetCursorItemPacket packet is triggered twice.
Plugin and Datapack List
- eco (my fork, try to fix Ghost Items)
- EcoItems
Paper version
paper 1.21.8 build #11
Other
No response
What the client sends is up to the client?
The drag is simply implemented like this.
How is this a paper issue or even remotely something we could fix?
Checking against the vanilla, dragging before placing in the same slot emits a total of three click packets.
Can you elaborate here, maybe I am missing something, otherwise this issue can be closed as this works as intended.
The moment you replied, I already suspected that. Then it's probably something wrong on the client side, not related to Paper. Can be deleted.
Expected behavior
The text "Hello" should be rainbow.
Observed/Actual behavior
I downloaded the plugin, installed it and changed PlayerCount
Steps/models to reproduce
-
Downloaded the latest version of the kernel https://papermc.io/downloads.
-
Threw it into the folder.
-
Threw the plugin
AdvancedServerList-Paper-5.7.0-b2into the plugins folder -
Went to
advancedserverlist >> profiles >> default.yml
Changed the file, adding the following to it.
profiles:
- motd:
- "<bold>Hello<reset> World!</reset> "
- ""
playerCount:
text: '<bold>Hello<reset> World!</reset> '
hover:
- ""
- motd:
- "<rainbow><bold>Hello<reset> World!</reset> "
- ""
playerCount:
text: '<rainbow><bold>Hello<reset> World!</reset> '
hover:
- ""
and when I launched it I got an incorrect PlayerCount display.
Plugin and Datapack List
[20:43:45 INFO]: โน Server Plugins (1):
[20:43:45 INFO]: Paper Plugins:...
I don't see a problem here.
The "PlayerCount" is actually a string representation of the server version, that does not, as the author of the plugin said, support text components.
This is not caused by Adventure, just a client "limitation" if you want to call it that.
ะะต ะฒะธะถั ะทะดะตัั ะฟัะพะฑะปะตะผั. ยซPlayerCountยป โ ััะพ ัััะพะบะพะฒะพะต ะฟัะตะดััะฐะฒะปะตะฝะธะต ะฒะตััะธะธ ัะตัะฒะตัะฐ, ะบะพัะพัะฐั, ะบะฐะบ ัะบะฐะทะฐะป ะฐะฒัะพั ะฟะปะฐะณะธะฝะฐ, ะฝะต ะฟะพะดะดะตัะถะธะฒะฐะตั ัะตะบััะพะฒัะต ะบะพะผะฟะพะฝะตะฝัั. ะญัะพ ะฝะต ะฟัะพะฑะปะตะผะฐ Adventure, ะฐ ะฟัะพััะพ ยซะพะณัะฐะฝะธัะตะฝะธะตยป ะบะปะธะตะฝัะฐ, ะตัะปะธ ะผะพะถะฝะพ ัะฐะบ ะฒััะฐะทะธัััั.
But then why on proxy (velocity) It works better? Although the plugin is the same..
I assume you are replying to my message.
I didn't notice that the motd is bricked as well, I thought just the version string.
The plugin probably uses adventure-platform-bukkit, that's why the components are serialized differently.
Velocity has native adventure support and the paper version of the plugin probably has spigot support which does not.
Nothing has changed, we don't need weekly updates. The only workaround would be to sanitise your inputs so that they conform to the expectations of the vanilla dispatcher
got confused on the issue, please provide minimal repro
You need not to worry about this unless the size difference is going to be huge. It will not in this case. I wrote down an explanation below (out of curiosity, chatgpt spew out the exactly same given a correct lead question)
jvm source
- Empty ArrayList = backing array literally empty object
- First addition: grow() aka grow(size=0 + 1) -> new array of size DEFAULT_CAPACITIY = 10.
- Adding 11th element to size=10 array increases capacity by oldCapacity>>1 aka ~0.5x aka +5 here
- Expanding from 15 adds +7
- Expanding from 22 adds 11
- Expanding from 33 adds 16
- To fit our potential 50th player, expand from 49 to 73 by adding 24.
- Thus final array elements = 50, but backing array has 73 slots, because it doesn't know when you'll stop.
PS: I learned to love digging thanks to a certain Shipilev. I want to further spread this approach :)
It really doesn't matter, this is one of the least intensive things in the whole PR. But I'll update it to remove any copies
got confused on the issue, please provide minimal repro
literally just player.performCommand("/home ") or any other command which uses brigadier
What even is the issue, what is different between executing the command as a player compared to #performCommand
When a player executes the command the space at the end would get trimmed off.
Fixes #12786
Tested using:
@EventHandler
public void onToggleSneak(PlayerToggleSneakEvent event) {
if (event.isSneaking()) return;
event.getPlayer().performCommand(" say Not Sneaking Anymore ");
}
Previously it failed silently, now it works as expected and prints the message.
I previously tested in Singleplayer, after testing without using integrated server I could reproduce it in vanilla.
Is your feature request related to a problem?
By default players are sent health packets for other players around them as well as animals. Players can download mods which take those packets and use them to display players/animal health. This information gives players an unfair advantage in pvp and is just extra information vanilla players don't get.
Describe the solution you'd like.
A new paper global setting which blocks these packets seems like something that would be at home in paper. Some servers display health already with TAB so it isn't something that all servers need. However, for servers which don't display player or mob health like how it is in vanilla, these mods are an unfair advantage.
This config setting would be in the anticheat section of paper global and is very similar to the existing obfuscation settings. The config would look something like this.
enable-health-obfuscation: false
overrides:
also-obfuscate: []
dont-obfuscate:
- wolf
- iron golem
A...
Stack trace
[07:48:28 ERROR]: Could not pass event InventoryCloseEvent to TestPlugin v1.0.0
java.lang.StackOverflowError: null
at java.base/java.util.Objects.equals(Objects.java:64) ~[?:?]
at java.base/jdk.internal.util.StrongReferenceKey.equals(StrongReferenceKey.java:69) ~[?:?]
at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:940) ~[?:?]
at java.base/jdk.internal.util.ReferencedKeyMap.get(ReferencedKeyMap.java:209) ~[?:?]
at java.base/jdk.internal.util.ReferencedKeySet.get(ReferencedKeySet.java:173) ~[?:?]
at java.base/java.lang.invoke.MethodType.makeImpl(MethodType.java:401) ~[?:?]
at java.base/java.lang.invoke.MethodType.methodType(MethodType.java:382) ~[?:?]
at java.base/java.lang.invoke.MethodType.dropParameterTypes(MethodType.java:692) ~[?:?]
at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentType(LambdaFormEditor.java:562) ~[?:?]
at java.base/java.lang.inv```...
Will do further testing on my side, because the PoC may be oversimplified. So far on my plugin I can replicate this all the time.
What's the reason for closing the inventory in an inventory close event? That's whats causing this endless loop.
Closing an inventory in the CloseInventoryEvent fires the CloseInventoryEvent; Closing an inventory in the CloseInventoryEvent fires the CloseInventoryEvent; Closing an inventory in the CloseInventoryEvent fires the CloseInventoryEvent; Closing an inventory in the CloseInventoryEvent fires the CloseInventoryEvent;
Yeah my bad, overlooked this entirely. In my main plugin the logic is spread across multiple files, so it was easier to overlook, but no idea how I didn't spot this when creating this simplified proof of concept.
The enderpearl checks its owner each tick, which automatically "downgrades" the entity ref to a uuid one.
We could obviously be explicit here (that might be better, but also a bit more effort), but this fixes it correctly and does not leak memory unless somehow the enderpearl stops ticking.
Not really some change in this commit doesn't apply to paper, like the vault one, for the banner this seems just redundant to clone the list twice since Banner#getPatterns already clone the underlying list. The only relevant change is the sign loading but it's not the issue reported in this ticket nor the main cause (fixed in the mentioned PR now).
Allow to use the show_dialog click event in a static action button. Deprecate key and getKey for dialogs since they can be inlined and revert the not planned cleanup done to CraftPlayer in the original PR.
I don't really know or understand the context behind the CraftPlayer changes, but the rest looks good.
Great, thank you!
<img width="658" height="121" alt="Image" src="https://github.com/user-attachments/assets/69ea750e-0410-44c7-9bcf-f538cb54065f" />
However I noticed this part right here stayed the same, are these configs immutable?
If so this should be fine however if not then they should not be referencing the configs of the state that is being copied
This was moved from ServerCommonPacketListenerImpl to ServerConfigurationPacketListenerImpl as part of
https://github.com/PaperMC/Paper/commit/7f609243907131c37d457aa367c04efbbd10f022
However, ServerConfigurationPacketListenerImpl no longer provides access to a player.
Maybe this should be done later in handleConfigurationFinished, or should we consider introducing new events specifically for the configuration phase?
The use case is to track which resource pack a player has applied on the server, so it can be properly unloaded when the player switches to a different server within the server-network.
The org.bukkit.damage package have been pretty stable for quite some time now, so I suggest to removing the @Experimental annotation
6bb9dc6 Normalize and trim spaces in Player#performCommand... - NonSwag
9ccc51d Fix legacy pearls forgetting owner on disconnect (... - Axyss
Closing this, there is a reason the discord tag is FAST.
[PaperMC/Paper] branch deleted: feat/disable-ear
Given it has been four days and I do also think this is best left up to a plugin, I am going to close this.
Thank you for your PR!
Talked with @NonSwag . Remove cancell
Change to CommandSourceStack, provides the CommandSender and more.
Make this event immutable (only for reading changes). so no cancellation or setter for difficulty.
57c1313 Allow to change despawnInPeaceful (#12880) - davidmayr
Thank you for the PR! Nice idea and really nice work :)
dbc367b Keep non-container slots synced when in container... - NoahvdAa
A few years ago I planned on making this a Paper config option, but when implementing it I found out that it's a massive pain to implement in the server directly. The only 'clean' way is to hook into the same system a plugin would use, which isn't really designed to be used by server internals.
After some internal discussion we decided that this is something that should be done by a plugin because we didn't want to maintain a messy implementation when plugins could handle it way cleaner.
That said, that was a few years ago, so maybe this is something that we do want to directly include now. I'll leave the issue open so others can comment their thoughts.
ps: I'll look into updating HealthHider :)
[PaperMC/Paper] Pull request review comment: #12541 Expose certain scoreboard related argument types
Probably better to have boolean overloads here?
The only thing resolveWritable does is one more check and a nice exception.
Having it named differently feels confusing.
[PaperMC/Paper] Pull request review comment: #12541 Expose certain scoreboard related argument types
Instead of IntIntPair, a custom interface (Operation.OperationResult probably) with a .result() would probably make the applyLeftSide obsolete.
Callers can .apply(1, 3).result() and .apply(1, 3).other if they want to use the swap operation.
The org.bukkit.damage package have been pretty stable for quite some time now, so I suggest to removing the @Experimental annotation
Is there anything that can be done in the interim from my side? I'm unable to use latest versions as the console spams infinitely with this error. Several critical plugins I have (ex. my perm plugin) check offline player files and I have ~300k player files.
why the diff so crazy? harder to audit
It was a revert of a previous commit. The audit was literally a diff against the previous state.
It was a revert of a previous commit. The audit was literally a diff against the previous state.
mb, didn't read description
Mobs from named eggs despawning is intended behaviour, check MC-54556
I am hoping there is something that can be done. I use a discord bot that relays my console to a private channel which makes it unusable. Not to mention reading the console or debugging other issues. I do not see this error when running 1.21.4.
Expected behavior
Being able to properly distinguish teleports caused by (dis-)mounting entities.
Observed/Actual behavior
When listening to the PlayerTeleportEvent and checking the teleport cause, the result is different to what I expected. When dismounting any ridden entity, the teleport cause is always TeleportCause#UNKNOWN instead of TeleportCause#DISMOUNT. Also, the Javadoc for the dismount cause states that it is 'caused by a player exiting a vehicle', but I would find it more logical if it covered dismounting all entities, since all entities can be ridden nowadays using the /ride command.
Another odd behavior is that some animals, such as horses, donkeys, mules and llamas, trigger a TeleportCause#UNKNOWN when mounting, whereas other entities, such as saddled pigs, boats, etc., do not trigger the TeleportEvent at all. It would be useful to have a TeleportCause#MOUNT for this use case.
Steps/models to reproduce
- Listen to the
PlayerTeleportEvent - Mount and dis...
having a name is irrelevant, it's all down to "does this entity have the persistence required flag set or is this a mob which should be considered persistent by the game" - i.e. nametags explcitly set the persistence required flag when setting a name on the entity
Water mobs are not considered persistent by default and so require the flag to stick around; it is also worth noting that the despawn logic works by finding the closest player to the entity (who can affect mob spawning), if the cloest person to the entity is outside of the range of the mob, it will be despawned, otherwise, if it finds nobody, or somebody is within the soft despawn range, it does nothing
Oh, okay, sorry. I always thought that naming the spawn egg and using a name tag would result in the same behavior. Then I didn't properly test that. My bad.
From a glance at the offending code, we only support proper denied writes, e.g. missing write permissions for the server user.
You could hence probably fix this by defining the files as read-only via
defaultMode: 0444 in your volumes[0].configMap.
With semi obvious node that mounting in a single file is a bit of a hack so you might also need to define the world defaults. This makes this technique kinda questionable for the spigot and bukkit config but yea.
That should throw you an agressive warning about not being able to write but it should correctly let you start the server.
The state is based on net.minecraft.util.datafix.fixes.TooltipDisplayComponentFix#CONVERTED_ADDITIONAL_TOOLTIP_TYPES.
But yea, I'd generally be in favour of making this as close to the pre 1.20.5 fuckery in terms of API consumption, we don't really need to be bound by the internal flag/migration here.
Idk if there are other components previously hidden by this flag.
I agree, this is kinda special however because of the fact that component was made unhideable for a few versions.
Expected behavior
Ctrl+Q (default mapping) should drop the whole item stack in a crafting result (for the sufficient provided materials).
Example of this being turning a stack of ink sacks to a stack of black dye. Ctrl+Q on the resulting black dye should turn all ink sacs to black dye and drop them.
Observed/Actual behavior
Ctrl+Q only drops and consumes materials for one item no matter the recipe.
Steps/models to reproduce
- Survival mode,
- Open either player's crafting inventory or a crafting table's crafting inventory
- Place enough materials for a recipe to make more than one item from that recipe,
- Press Ctrl+Q on resulting item
Plugin and Datapack List
plugins
[00:20:49 INFO]: โน Server Plugins (0):
datapack list
[00:20:57 INFO]: There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
[00:20:57 INFO]: There are no more data packs available
Paper version
plugins
[00:20:49 INFO]: โน Server Plugins (0)...
Expected behavior
When clicking the item on the inventory, the item should not desync
Observed/Actual behavior
https://github.com/user-attachments/assets/3a832a42-7d13-46df-87af-64f625983441
Steps/models to reproduce
player.inventory
.addItem(
ItemStack(Material.DIAMOND)
.apply {
setData(
DataComponentTypes.LORE,
ItemLore.lore().addLine {
Component.text("hewwo!!")
.decoration(TextDecoration.ITALIC, false)
.color(TextColor.color(24, 230, 24)) // this should be any color that has a letter in the color's hex code
}
)
}
)
Plugin and Datapack List
[01:00:42 INFO]: โน Server Plugins (110):
[01:00:42 INFO]: Bukkit Plugins:
[01:00:42 INFO]: -```...
Thanks to JavierFlores09 on Discord, the issue was tracked down! It is a bug on Adventure on the TextColor::asHexString method.
Here's the workaround while the bug is not fixed in Adventure.
static final Codec<TextColor> TEXT_COLOR_CODEC = Codec.STRING.comapFlatMap(s -> {
if (s.startsWith("#")) {
@Nullable TextColor value = TextColor.fromHexString(s);
return value != null ? DataResult.success(value) : DataResult.error(() -> "Cannot convert " + s + " to adventure TextColor");
} else {
final @Nullable NamedTextColor value = NamedTextColor.NAMES.value(s);
return value != null ? DataResult.success(value) : DataResult.error(() -> "Cannot convert " + s + " to adventure NamedTextColor");
}
}, textColor -> {
if (textColor instanceof NamedTextColor named) {
return NamedTextColor.NAMES.keyOrThrow(named);
} else {
return textColor.asHexString().toUpperCase(); // This is the```...
Thanks for investigating on the topic of Kubernetes ConfigMaps even though this is not your main concern :)
Unfortunately, the defaultMode doesn't prevent the error. After adding it, the permissions are looking good:
$ kubectl exec <my-pod> -- ls -la config
total 4
drwxr-xr-x. 2 root root 30 Jul 29 09:27 .
drwxr-xr-x. 1 root root 32 Jul 29 09:27 ..
-r--r--r--. 1 root root 3700 Jul 29 09:25 paper-global.yml
This still results in the same stack trace. Problem is that the underlying exception is a java.nio.file.FileSystemException instead of a java.nio.file.AccessDeniedException.
I should've added the complete stack trace earlier...
[09:27:51 ERROR]: Encountered an unexpected exception
org.spongepowered.configurate.ConfigurateException: []: java.nio.file.FileSystemException: /opt/paper/config/.2390207891523211899288440paper-global.yml.tmp -> /opt/paper/config/paper-global.yml: Device or resource busy
at org.spongepowered.configurate.loader.AbstractConfi```...
Interesting, I did validate my claim at least on a local kind cluster before replying o.O but yea, permissions look good. An alternative we could consider, that might be a lot easier for us to implement, is allowing definition of overrides to the config yaml files via secondary filesets.
I am thinking java -jar server.jar --paper.global.values=/some/path/not/in/server/folder which can then directly be pointed at a config map mount point.
Limiting the overriding to yaml files would solve the "how do I define a map of lists of maps in env variables" problem by simply ignoring it and should be easily implemented via the existing merge functionalities in configurate.
Those files could then 100% be read only with the server not even attempting a write-back for migration and simply ignoring outdated keys during the merge.
I am not 100% sure but the difference in behaviors might also be caused by the JREs we're using. File system handling might be a little different depending on the implementation but I'm just speculating...
Anyways I like your proposed solution especially since merge sounds like I can just specify the keys I am interested in instead of the entire yaml file?
Yea exactly, think helm chart value merging, at least that would be my vision for this.
Sounds good! The merge file path (you called it --paper.global.values= in your example) will be configurable using ENV variables, right? :rofl:
Probably need to clone to avoid issues, FluidLevelChangeEvent getter was missed too
Do not mix nullable annotations
Missing since attribute
No need to add such comments in api anymore (see getEvent too)
Testing on:
[19:15:48 INFO]: Checking version, please wait...
[19:15:48 INFO]: This server is running Paper version 1.21.8-17-main@dbc367b (2025-07-26T21:53:33Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
You are running the latest version
Extend fires properly for both sticky and regular piston but retract fires only for the regular one when there are no blocks.
Fixes #9827, also known as MC-172801
Dividing by 20.0 is necessary to preserve the default speeds of these mobs.
Probably it should be blockState2.isAir() and not blockState1.isAir()
This line doesn't need to be changed
There is also an issue with direction - for regular piston it's the piston direction for both extend and retract. For sticky one after changing the condition to blockState2.isAir() it also works for extend and retract but when retracting with a block it's inverted
Are you referring to the second return statement?
See the linked PR, it just need to be rebased.
No changes have been made to it. It's just the way Github highlights patch files.
Modified lines are the ones with two plus signs at the start and green background.
Technically Player got replaced by net.minecraft.world.entity.player.Player, probably not needed
4d44b5f Remove @Experimental annotation from the org.bukki... - indyteo
4f79e9e [ci skip] no need to ever import non-library files... - Machine-Maker
Expected behavior
My code:
`public void setAdminName(Player player, int adminLvl) {
String name = player.getName();
String displayName = switch (adminLvl) {
case 0 -> "&f" + name;
case 1, 2 -> "&2" + name + "&r \uE005";
case 3, 4, 5, 6 -> "&c" + name + "&r \uE006";
default -> "&e" + name + "&r \uE007";
};
player.playerListName(Component.text(Common.colorize(displayName + " &7[" + Objects.requireNonNull(getPlayerData(player)).getDynamicId() + "]")));
player.customName(Component.text(Common.colorize(displayName + " &7[" + Objects.requireNonNull(getPlayerData(player)).getDynamicId() + "]")));
player.displayName(Component.text(Common.colorize(displayName)));
}`
player.customName(Component.text(Common.colorize(displayName + " &7[" + Objects.requireNonNull(getPlayerData(player)).getDynamicId() + "]"))); - not change my name tag head
Observed/Actual behavior
player.customName...
This is vanilla behavior, nothing we can do here.
From the javadocs
This value has no effect on players, they will always use their real name.
Also, unrelated, don't put section signs in components! Gets messy.
And if I want to use a beautiful name tag over the player's head, what should I do?
Fixes a typo in give command that caused incorrect behavior when dropping excess items
We had the same Error on our Server and i was able to track down the conflicting Items. In our Case it have been different Items that had been set up with a Colorized Name and Lore. Originaly the Items had been provided with a Give Command over Boss Shop. The Users that have been triggering this, have not been online for Years, but i cant see a Pattern of like "Oh its the change to this Version". I used the Errordetails and NBT Studio to search through the Playerdata Files and removed the 4 Usersfiles that caused this. Maybe that Helps you on your further Investigations.
HIDE_ADDITIONAL_TOOLTIP still suppressed the armor_trim_smithing_template details in 1.21.4, but it no longer has any effect in 1.21.8.
We had the same Error on our Server and i was able to track down the conflicting Items. In our Case it have been different Items that had been set up with a Colorized Name and Lore. Originaly the Items had been provided with a Give Command over Boss Shop. The Users that have been triggering this, have not been online for Years, but i cant see a Pattern of like "Oh its the change to this Version". I used the Errordetails and NBT Studio to search through the Playerdata Files and removed the 4 Usersfiles that caused this. Maybe that Helps you on your further Investigations.
Thank you for the reply. I tried NBT editor/NBT studio. My world folder has 300,000 player files and the application crashes trying to load the save. It seems I am stuck until this is fixed.
You replaced Player with net.minecraft.world.entity.player.Player for no reason
I did not, that was originally there. Check out LivingEntity.java.patch from the main branch
Is your feature request related to a problem?
Yes, recently all MapPallette methods like matchColor have been deprecated, with the only info received was to 'use color-related methods'. I have been unable find any of these mentioned color related methods.
I require the functionality to be able to match a given color to the closest map color.
Describe the solution you'd like.
-
expose
MapPallette.colors, perhaps throughMapPallette.getColors(), so that all available Colors can be known by plugins. -
add a method like
Color MapPallette.getNearestColor(Color c)
Describe alternatives you've considered.
MapPallette.colors could be accessed with reflection, and from there on we could write our own algorithm to match to the nearest color. But this does not seem like good practice, especially because the server already has all of this logic internally.
Other
No response
What do you need the closest map color for exactly? The color related methods the javadocs point to are the ones on other classes like MapCanvas with the setPixelColor method, which already handles the matching
I use it so when i dye a paint brush, it will be set to the nearest map color, if i cant match the color to the palette it will be confusing since the colors wont match the brush color. not entirely sure if i can access a MapCanvas in that case, although all the methods i would need are in there..
Adventure 4.24.0 has been released and it includes the hex color fix :) https://github.com/KyoriPowered/adventure/releases/tag/v4.24.0
Ready to go now, PaperAdventure#FLATTENER todo will be configurable with the new SPI system for overriding defaults when 4.24.1 is released but don't wait up on that as this fixes #12902 and flattener bugs probably reported somewhere but I can't find them.
0c8efe4 [ci skip] Remove redundant adventure version speci... - jpenilla
[PaperMC/Paper] Issue opened: #12909 LEAD_BREAK sound plays even when EntityUnleashEvent is canceled
Expected behavior
The sound does not play when the event is canceled
Observed/Actual behavior
The unleash sound effect gets played repeatedly https://www.youtube.com/watch?v=LnWmlY6LeDE
Steps/models to reproduce
- Cancel the EntityUnleashEvent
- Leash to an entity
- Distance yourself from the entity so the leash snaps
- observe the sound beeing played every tick
Plugin and Datapack List
No datapacks
Test plugin
Paper version
[23:42:15 INFO]: Checking version, please wait...
[23:42:15 INFO]: This server is running Paper version 1.21.8-20-main@ec9c83f (2025-07-30T17:54:07Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
You are running the latest version
Other
In net.minecraft.world.entity.Leashable the following is beeing run on line 174:
if (d > entity.leashSnapDistanceOrConfig()) { // Paper - Configurable max leash distance
level.playSound(null, leashHolder.getX(), leashHolder.getY(), leashHolder.getZ(), Sou```...
Adds mixPotion and canMixPotion methods to simulate what a brewing stand would do.
I think it's a fair change since there's really not much potion API currently.
We are hardforked. No need for comments anymore.
Generally a fan of the concept!
Some minor formatting and logic issues.
Nullability annotations.
Fair enough, I was following the Formatting section of CONTRIBUTING.md. Perhaps it needs an update
Ah, that is only for diff in mojang classes :sweat_smile: when writing patches. you are just editing normal .java files, maybe we need to clarify that.
Expected behavior
VehicleExitEvent being called before being teleported via player.performCommand("minecraft:tp ~5 ~ ~") in the PlayerInputEvent for when the player is sneaking
Observed/Actual behavior
when doing player.performCommand("minecraft:tp ~5 ~ ~") inside the PlayerInputEvent with event.getInput().isSneak() the player already teleported when checking the location via the VehicleExitEvent and therefore area limitations aren't working.
Steps/models to reproduce
@EventHandler(ignoreCancelled = true, priority = EventPriority.MONITOR)
public void onPlayerInBoatGetsDamaged(PlayerInputEvent e) {
if(e.getInput().isSneak()) e.getPlayer().performCommand("tp ~5 ~ ~");
}
@EventHandler(ignoreCancelled = true, priority = EventPriority.LOWEST)
public void onPlayerTryExitBoat(VehicleExitEvent e) {
// this doesn't cancel when teleporting via the performCommand above since the location already changed
if(e.getVehicle().getLocati```...
record by: An ender pearl has a 5% chance to spawn an endermite when it lands. This is the only way through which endermites can spawn, without using cheats. The endermite spawns at the player's position when the pearl landsโ[Java Edition only], or at the pearl's landing siteโ[Bedrock Edition only].
in the past the endermites will spawn at the position player teleported instead of old position becuse craftbukkit move teleport behind to create event, so it spawn in wrong place.
Is your feature request related to a problem?
Events like BundleAddItemEvent and BundleRemoveItemEvent
Describe the solution you'd like.
call events in according methods
Describe alternatives you've considered.
No?
Other
No response
Seems you got tricked by parchment wrong param names for hasMix (mix doesn't do better really), potion is the ingredient and ingredient is the potion.
Is your feature request related to a problem?
startup time slow
Describe the solution you'd like.
paper aot maps
Describe alternatives you've considered.
compile manually, but has cost
Other
No response
Rebased it directly:
0003-Paper-PR-9258.patch
However (as mentioned previously in the PR and also as stated in the docs) getDirection returns the direction the blocks (and the piston head) are moved in. With the rebased patch, the direction for retract without blocks is always the piston direction itself which is not correct behaviour. The current API returns the piston-opposite direction for sticky piston retracting with blocks.
The expected solution would be to return the direction the blocks are moved in, as the current API is used by many plugins, like for example WorldGuard: https://github.com/EngineHub/WorldGuard/blob/f8415edfcd505c0d7f998261568bc082f8db0877/worldguard-bukkit/src/main/java/com/sk89q/worldguard/bukkit/listener/EventAbstractionListener.java#L409-L419
The patch adapted to the expected behaviour:
0003-Paper-PR-9258.patch
Paper uses java 21, this is not applicable to us yet.
Looks like you're right. I kind of assumed potionItem referred to the same thing in either method. Thanks
TSIA. Currently we can receive custom payloads during configuration stage, but not send them. This PR allows for that.
Is your feature request related to a problem?
Yes
Describe the solution you'd like.
A way to access all colors/pixels of a map, so that it can be retrieved for database storage or cross server synchronization.
Describe alternatives you've considered.
The current way i do this is by using reflection to retrieve the buffer field from the maps MapItemSavedData#vanillaRender.
This field returns a byte[], which represents all colors stored as indexes, but since usage of the byte indexes is recently deprecated in the API, all access to byte -> color related methods are now scheduled for removal. So i will be unable to convert the retrieved byte[] into proper colors to for example render a map from one server on another, or save the pixel data.
After the removal, i am unsure how to continue development without access to map pixel data
Other
No response
I had to separate my Userfiles in Packages too but i can tell you, it's not a recent User that is bringing the Problem. I could track down the corrupted Files to the Years 2023 and 2018. I just packed all my Playerdata Files into Years according to the Lastchanged Status. It will be quite the Task on your Side with 300k+ Files, but for me it all was a Matter of "How badly do you want to Update befor your Holidays start" ;)
During plugin creation I noticed that I can't do anything with logged off players. So here I added api to work with player .dat file that for the mostly copies the standard api of the player, excluding parts that can only work with online player.
Is your feature request related to a problem?
The ID value represents a block state property and is used as part of the type's constructor which is not marked as @Internal. It is not some unreliable internal magic value, there are reasonable justifications as to why someone may need access this value.
Describe the solution you'd like.
Remove the @Internal annotation from Note.getId()
Describe alternatives you've considered.
Using it anyway, which I can and will do. However as the value isn't really internal, there is no reason it should be marked as such.
Other
No response
The value is internal and has 0 contracts over it's stability, Mojang may completely change the numbers used to represent stuff tomorrow. The API exposes the Note entry itself, rather than the value; if you're using this numeric in the API without a replacement that takes the Note, that should be resolved
If the id is considered to be definitely unstable, then why is there a public constructor not marked as @Internal? That seems like an API inconsistency.
Additionally, from a quick glance at the wiki https://minecraft.wiki/w/Note_Block#Data_history, the representation of Note likely has not changed since 1.13, and before then it hadn't changed since it's introduction. It's safe to say it's extremely unlikely that Mojang would change it in a way that would break the meaning of the id.
It's not the role of our API to declare that some arbitrary data representation inside the server is stable, we have no inclination to try to provide support should mojang decide to change how any of this stuff works, especially with their never-ending refactoring around how a lot of this low level stuff is represented internally.
some arbitrary data representation inside the server
This doesn't really count. Minecraft uses that id on the debug screen, in give and fill commands, etc. It's not just an internal representation, it's how the game represents it to the user. It's no different to other values like Keys and Instruments (used by Note Blocks).
Those aren't really "user facing", the debug screen shows low level representations of stuff, not always values which are actually exposed within the game UI; the give/fill command has consistently changed with stuff over the years, we have no idea what mojang is likely to do when it comes to avenues like data driving around this logic, etc. The API has setters for Note rather than expecting you to pass in the raw ID for a reason.
Many projects have gotten in heat for having opt-out telemetry. For example, The Fedora Project had a large amount of criticism due to opt-out telemetry.
bStats appears to be largely a third-party tracker. Currently, Paper users do not give any explicit consent to enable bStats, which is a third-party tracker. Paper also sends a server-specific identifier. Unless this telemetry is legitimate interest, this is largely illegal in the European Union.
Many Minecraft servers run on a personal PC and then shared using port redirection software or on a LAN. This makes the issue much worse than simply a containerized server sending data from a meaningless datacenter IP address.
It is in Paper's best interest to make this telemetry opt-in. If a plugin developer really wants the data, they can likely detect that bStats is off and then prevent the plugin or server from being fully loaded, or implement their own telemetry.
metrics are an important tool in our ability to make operational decisions as a collective, removing metrics removes people votes within our ecosystem
removing metrics removes people votes within our ecosystem
This PR does not remove any metrics and instead makes them opt-in.
Which effectively removes new users from providing metrics as we have 0 mechanism of prompting users to opt in our out of providing them
Paper collects metrics via bStats. As such, we should generally follow GDPR.
The data collected falls under the legimate interest clause (pseudonymous, technical data, reasonable expectation, not overriding the fundamental rights and freedoms of the data subject), so consent is not required.
However, it still is a requirement to inform the users of the data collection and of how they can opt-out (Transparency).
The onboarding message is a good place for this, without spamming the regular startup log with information 99% of users do not care about. Showing the message once should be sufficient to inform the user.
I've added the following message below the onboarding message:
This server is collecting anonymous statistics for PaperMC via bStats.
This helps us improve our software. To disable, set 'enabled: false' in /plugins/bStats/config.yml
For more details on what data is collected, see https://bstats.org/privacy-policy
Alternatively we could add a note with...
Can confirm in 1.21.8 :(
[05:03:30 INFO]: Checking version, please wait...
[05:03:30 INFO]: This server is running Paper version 1.21.8-21-main@ed31825 (2025-07-31T02:36:28Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
You are running the latest version
I like this idea but not so much the message
It doesn't tell the user that Plugins may use bstats too and disabling it will result in plugins not submitting their stats either
IANAL, but as far as I am aware we don't need to show this notice because bStats doesn't store PII in a way that allows it to be linked to a natural person
Simply by using bStats, Paper technically shares PII with bStats, because, as stupid as it is, IP Addresses are considered PII. I'm not sure on the specifics but I suspect that because the data is shared, Paper probably does have to show a notice.
Ignoring that, it's probably better to be safe than sorry, it's only a few log lines anyway.
The IP addresses are only stored as a ratelimiting key, separate from any other information about the server. Pretty sure you don't need to disclose anything if you only use the IPs for a technical purpose like ratelimiting.
I can confirm that this is an issue that also affects 1.21.5. Items flowing within a water stream quickly lose positional accuracy outside of a short distance from the player. This significantly interferes with basic item moving mechanics and disrupts even simple machines. An option to disable/alter this EAR behavior to restore item movement consistency would be very appreciated.
In spigot.yml you can set
entity-activation-range:
misc: 16
to -1 to disable it, restoring the vanilla behaviour
I tried the following steps to attempt to replicate this:
- Spawn an item display
- Restart the server
- Alter the same item display with setItemStack
This resulted in the item display updating just fine, is it possible for you to provide a minimal code snippet that's able to reproduce this issue or at least a link to your plugin's code?
Updating the javadoc to mention the new behavior would seem simple enough
The submitters account has been deleted and the paste expired, same issue got reported over at https://github.com/PaperMC/Paper/issues/12858 so it can be tracked there.
Generally like the API addition ๐
Could of changes.
I am a bit confused here, what is the benefit of this diff?
Does this do anything beyond "saving" a single loot table lookup against the loot table registry?
If you move the , to the line of lootTable1, this is truely a single diff line.
No need for extra paper comments in there anymore since hardfork.
Additionally, it be benefitial to add an obfhelper to the loottable1 var and name it something proper.
E.g.
- LootTable lootTable1 = level.getServer().reloadableRegistries().getLootTable(lootTable);
+ LootTable lootTable1 = level.getServer().reloadableRegistries().getLootTable(lootTable); final LootTable sourceLootTable = lootTable1; // Paper - obfhelper
bf465e0 Cancel hit for all vanished entities, not only pla... - Gerrygames
setCollidable and collidable exemptions are purely server concepts, the player doesn't know it's not supposed to collide with a certain entity. The only way I can see that this could be fixed would be for the server to send team packets with collision set to never, but when dealing with plugins that may do the same it could become quite an ordeal.
I can see that the last executed task does stick around in the this.head field, and that seems to be by design, so not sure what can be done there in that department.