Thanks for continuing to work on the idea! All the best, Verdox
#paper
1 messages ยท Page 22 of 1
@kennytv why was this closed?
With the incoming addition in 1.21.5 of the cactus flower, I'd be interested in hearing how we want this PR to integrate with the cactus flower.
As lynxplay mentioned in the old commit, with a system like this, its entirely possible for some crop ages to be skipped. With the cactus flower only being able to grow with a crop age of 8, skipping an age would entirely disable the possibility of cactus flower growth, which would obviously be problematic if not intended.
We could make it so that if the modifier for cactus or a hypothetical modifier for cactus flower is modified than it changes the condition from requiring that the age be 8 to being a 1/16 chance instead, but that would feel a bit odd for this pr to replace one system of breaking how vanilla grows crops to a different alternative when modifiers are applied.
Alternatively we could just scale down the pr to simply modify the age to 15 on a cactus before applying the old instant growth logic and not improve the modif...
The master branch was deleted as we have now been on the post paper hardfork layout for 4 full months and this PR hasn't been updated for it.
70452b5 Initial draft for tracking affected block pos - lynxplay
f225858 Fix firework entity not being removed when Fire... - Doc94
37b9ca1 Add flush parameter to World#save (#12330) - Strokkur424
515e12c Check if BUNDLE_CONTENTS is present in Inventor... - notTamion
Probably wanna note here that this class doesn't aim to expose every single config option in existance, only select ones.
We could check isFinite if we want to also cover infinity, assuming that's even possible. Only have some nitpicks about the comments.
+ this.setDeltaMovement(Double.isNaN(this.deltaMovement.x) ? 0 : this.deltaMovement.x, Double.isNaN(this.deltaMovement.y) ? 0 : this.deltaMovement.y, Double.isNaN(this.deltaMovement.z) ? 0 : this.deltaMovement.z); // Paper - remove NaN values before usage in saving
+ Math.abs(_double) > 10.0 || Double.isNaN(_double) ? 0.0 : _double, Math.abs(_double1) > 10.0 || Double.isNaN(_double1) ? 0.0 : _double1, Math.abs(_double2) > 10.0 || Double.isNaN(_double2) ? 0.0 : _double2 // Paper - avoid setting NaN values
5a6ab97 Add config to remove player as vehicle restrict... - ShaneBeee
Add period at end of this line
Remove period at end of this line. Also, semicolon? Are we that fancy?
Also this one says "Server" while most other things say "server"
Remove period at end of this line. Also, semicolon? Are we that fancy?
102c8bb Add config for updating equipment on player act... - notTamion
f0388e2 Call EntityPushedByEntityAttackEvent for Mace A... - Doc94
c37b890 More deferred requireNonNull message creation - kennytv
310f522 Add unsupported config option and internal API ... - kennytv
6ea4202 Send all attributes on respawn (#12274) - notTamion
2d3a138 [ci skip] Refine recipe management API document... - NonSwag
[aaaeb4e](https://github.com/PaperMC/Paper/commit/aaaeb4e1e6477b0a6d586f70e7392...
pigs walking thru leaf litter sometimes get thanos snapped:
[12:53:07 ERROR]: Entity threw exception at world:-674.6602878873133,65.0,2295.449999988079
java.lang.NullPointerException: Cannot invoke "org.bukkit.Material.isAir()" because the return value of "org.bukkit.block.Block.getType()" is null
at net.minecraft.world.entity.Entity.move(Entity.java:1078) ~[main/:?]
at net.minecraft.world.entity.LivingEntity.handleRelativeFrictionAndCalculateMovement(LivingEntity.java:3105) ~[main/:?]
at net.minecraft.world.entity.LivingEntity.travelInAir(LivingEntity.java:2931) ~[main/:?]
at net.minecraft.world.entity.LivingEntity.travel(LivingEntity.java:2923) ~[main/:?]
at net.minecraft.world.entity.LivingEntity.aiStep(LivingEntity.java:3487) ~[main/:?]
at net.minecraft.world.entity.Mob.aiStep(Mob.java:491) ~[main/:?]
at net.minecraft.world.entity.AgeableMob.aiStep(AgeableMob.java:151) ~[main/:?]
at net.minecraft.world.entity.animal.Animal.aiStep(Animal.java:6...
i think a better name would be something like PlayerAttackDamageEvent considering this event is called for all hits and not just critical ones
Well, but the only purpose of this event is to manage "criticallity" of hits... It can make non-critical hit critical and vice versa... I think therefore Critical should be part of the name...
This note will be inherited by the player class which may seem confusing, we may want to have some javadocs in the player class override for this method still.
"One sound event" in these three classes reads kind of weird, it seems better without to me.
You could use Util.COLLISION_EPSILON as a constant rather than adding a diff on change.
Couldn't this be moved into the block attached entity class itself?
why not expand on the event then? considering afaik we won't a nice way to modfiy e.g. the base damage of a specific attack. i just don't think we should call the event CriticalAttackEvent or similar because that is not what it is. it gets called when the damage gets calculated, so why should we restrict ourselves to have it only handle the criticality when it could expose more than just that.
why not expand on the event then? considering afaik we won't a nice way to modfiy e.g. the base damage of a specific attack. i just don't think we should call the event CriticalAttackEvent or similar because that is not what it is. it gets called when the damage gets calculated, so why should we restrict ourselves to have it only handle the criticality when it could expose more than just that.
See the reasoning above. I think having a separate event is good here because damage logic should not be consolidated like the current damage event.
See the reasoning above. I think having a separate event is good here because damage logic should not be consolidated like the current damage event. It should only control criticality in my opinion.
i am not saying we should'nt make this a seperate event (with "the event" i meant the event we are going to be adding), i am saying this event could expose more than just criticality considering the event is placed right around where this stuff is calculated and passed to the hurt methods which then call the damage events. we would'nt be consolidating/forcing this stuff into that event via trickery at all because the event is already placed nicely for that. either way i still don't think PlayerCriticalHitEntityEvent is the best name for this.
Adds Entity#isTrackedBy, allowing for checking if a player is currently tracking an entity without having to get the set of all tracking players.
thats what i did initially though then i also have to additionally check for block collisions to ensure the order stays the same so i thought it might be easier to just move this to where the entities are still returned. but yeah this is not optimal either
Looks good! might be nice to mention something in the ignorePassable jdocs (at least on the builder) that its equivalent to setting the block collision mode to the respective value
doesn't really mater, afaik bukkit did it a lot? paper not so much
Changes the Command#testPermissionSiltent method to call Command#getPermission instead of directly referencing the permission object.
This way it is also possible to override the Command#getPermission method if someone chooses to do so.
ehh feels like a purpur thing to me
Hello, I believe I have found a solution to this problem. Can I get assigned, please?
We don't assign issues to non contribs, you are more than welcome to open a PR.
ea5c252 register new items for item meta and update hol... - Lulu13022002
Is your feature request related to a problem?
I just encountered an error when programming a plugin that the main world is not unloaded. The problem is because Bukkit currently needs the main world to do things like calculate ticks (I was told), and in some cases it is really annoying to use alternatives for your plugin, for example I just wanted to write a system where the world is unloaded, deleted, and then regenerated. But that doesn't work without a server restart, which means I would have to use an alternative.
Describe the solution you'd like.
I would like it if all important things like tick calculation or rather everything that needs the main world is moved, or somehow programmed so that the server no longer needs the main world.
Describe alternatives you've considered.
Alternatively, if unloading doesn't work, it would be good to include an option to regenerate worlds without having to delete them first.
Other
No response
28daa6c update adventure codecs, fixes click and hover ... - MiniDigger
Provide the error you encountered
Mojangs game server is not written with the concept that the main world can disappear, and I'm generally not sure that it's worth it for us to invest into the work for this, especially with the backlog of other world system related issues in regards to how mojang manages its data lifecycle
Provide the error you encountered
That's the point, there is no error. If the ChunkHolderManager would tell me that the main world can't be unloaded, that would be fine. But I've been sitting here for 2 hours trying to find a solution as to why the main world is not unloading properly.
The generally used "alternative" here is to code around that by keeping the single main level as minimal as possible (e.g. void, no entities, no time, no weather) and just accept it as a "semi" no-op.
As cat stated, redoing this is not as simple as flipping a switch in one place. We should probably then correctly throw something if someone attempts to unload the main world.
UnloadWorld Method would tell me that the main world can't be unloaded, that would be fine.
It was telling you that, but most probably you were ignoring the returned boolean
e50bb66 make Phantom#anchorPoint nullable - Lulu13022002
Seems fair, the NamespacedKey checks are slightly more restrictive than vanilla and doesn't allow an empty key here (adventure keys are fine).
This also affect the data component api with the following items:
- (item meta only) minecraft:netherite_sword[item_model="minecraft:"]
- minecraft:stone[attribute_modifiers={modifiers: [{amount: 0.0d, id: "minecraft:", operation: "add_value", type: "minecraft:attack_damage"}]}]
The problem still occurs after switching to Java 21.
https://mclo.gs/KK77SIQ
Isn't this just pointing at another deprecated method?
Expected behavior
Villagers pathfind correctly to nearest reachable blocks
Observed/Actual behavior
Villagers pathfind in a straight line to blocks, and if stuck on a wall/ceiling/floor, do not give up on the block or find a different route.
I haven't seen these problems in single player, only on my Paper server, but frequently, villagers targeting a bed will end up behind their house staring at the wall instead of going around to the front door. I have also had issues where villagers will refuse to use stairs or slabs to go upstairs or downstairs to get to the block they are targeting, and will instead stand directly above or below the block and never be able to reach it.
Steps/models to reproduce
Create a scenario where the shortest path between a villager and their target block is blocked by some means, where an alternative (possible) path would require walking farther away from their target. Observe the villager getting stuck near their target block, but unable...
Duplicate of https://github.com/PaperMC/Paper/issues/12043
Also happens on vanilla servers/singleplayer, just seems to be slightly rarer.
I want to add this was apparently a Java bug, and was fixed in java23+
Probably a solution won't be needed if minecraft or paper drops support for Java21 in the future
+1 for at least having it as an option. I spend far too much time trying to convince villagers they can't walk through walls lol
This looks like a non standard JVM; the thing also blew up drawing an
image, first guess would be to try disabling the GUI, otherwise, might be
plugin related; generally hard to say what is going on entirely
On Mon, 24 Mar 2025 at 21:54, Cric_Hammel @.***> wrote:
The problem still occurs after switching to Java 21.
https://mclo.gs/KK77SIQโ
Reply to this email directly, view it on GitHub
https://github.com/PaperMC/Paper/issues/12309#issuecomment-2749488039,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJMAZGC7C2JD7E4WG7QIHT2WB5J5AVCNFSM6AAAAABZEBDFUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBZGQ4DQMBTHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
[image: CricHammel]CricHammel left a comment (PaperMC/Paper#12309)
https://github.com/PaperMC/Paper/issues/12309#issuecomment-2749488039The problem still occurs after switching to Java 21.
https://mclo...
Is your feature request related to a problem?
Expand the current non-existent armadillo api to support some of its data
Describe the solution you'd like.
Expose the Armadillo#isScared, Armadillo#isRolledUp methods as well as the ArmaDillo#ArmadilloState class for anyone who might need it
Describe alternatives you've considered.
None, I haven't considered any
Other
No response
#12031 #12277 there are already prs open for this.
e21bf45 fix chunk-gc plugin ticket config - MiniDigger
32fef5d do the fix in Ticket record getter instead - MiniDigger
0d8dad6 Quick cursory update of ItemStackDataComponentTest - electronicboy
0f1f084 Update ItemStackDataComponentEqualsTest - electronicboy
34dfd5e add perm for test command, fix some tests - MiniDigger
740abe1 Update CraftSmithingTransformRecipe - electronicboy
de93fda Merge branch 'update/1.21.5' of github.com:Pape... - electronicboy
c02ad46 Update SmithingTripRecipe - electronicboy
0a5ea70 Also bundle mc source change from last commit - electronicboy
Seems fair, the NamespacedKey checks are slightly more restrictive than vanilla and doesn't allow an empty key here (adventure keys are fine).
This also affect the data component api with the following items:
* (item meta only) minecraft:netherite_sword[item_model="minecraft:"] * minecraft:stone[attribute_modifiers={modifiers: [{amount: 0.0d, id: "minecraft:", operation: "add_value", type: "minecraft:attack_damage"}]}]
Should we search in the API?
I've collected some name suggestions from discord not sure which one to use, but maybe the original Tamion's one (PlayerHitCriticalityEvent) is probably the best. Any other suggestions/ideas?
PlayerHitCriticalityEvent
CriticalHitEvent
PlayerCriticalHitDetermineEvent
PlayerDetermineCriticalHitEvent
PlayerCriticalHitDecisionEvent
PlayerCritDecisionEvent
Expected behavior
When calling player.getBedSpawnLocation(), if the player's respawn block is Anchor, the API will run normally as usual
Observed/Actual behavior
Anchor's charging is abnormally reduced
Steps/models to reproduce
- Go to nether
- Place an Anchor and charge it, then right-click to set the respawn point.
- Call API:
player.getBedSpawnLocation() - Observe the problem to occur
Plugin and Datapack List
[17:46:08 INFO]: โน Server Plugins (3):
[17:46:08 INFO]: Bukkit Plugins:
[17:46:08 INFO]: - LetsExpand, PlugManX, spark
Paper version
version
[17:46:28 INFO]: Checking version, please wait...
[17:46:30 INFO]: This server is running Paper version 1.21.4-221-main@c467df9 (2025-03-24T00:18:41Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-DEV-bc157c7 (MC: 1.21.4)
Other
No response
Expected behavior
When player.getBedSpawnLocation() or player.getRespawnLocation() is called, the API will be running as usual if the player's respawn block is Anchor
Observed/Actual behavior
The API works normally, but Anchor's charging is consumed abnormally
Steps/models to reproduce
- Go to nether
- Place an Anchor and charge it, then right-click to set the respawn point.
- Call API:
player.getBedSpawnLocation()orplayer.getRespawnLocation() - Observe the problem to occur
Plugin and Datapack List
[17:46:08 INFO]: โน Server Plugins (3):
[17:46:08 INFO]: Bukkit Plugins:
[17:46:08 INFO]: - LetsExpand, PlugManX, spark
Paper version
version
[17:46:28 INFO]: Checking version, please wait...
[17:46:30 INFO]: This server is running Paper version 1.21.4-221-main@c467df9 (2025-03-24T00:18:41Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-DEV-bc157c7 (MC: 1.21.4)
Other
I observed th...
Expected behavior
Entity selector arguments show tab completion options like @p when I have the minecraft.command.selector permission.
Observed/Actual behavior
No completion but the command still works.
/lp verbose states that I have access to selectors and the give command.
Steps/models to reproduce
Do not be op.
Have minecraft.command.give permission.
Have minecraft.command.selector permission.
Try to tab complete /give @p
permissions.yml for testing, but it happens with luckperms too
minecraft.command.give:
default: true
minecraft.command.selector:
default: true
Plugin and Datapack List
None
Paper version
This server is running Paper version 1.21.4-221-main@c467df9 (2025-03-24T00:18:41Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
Other
No response
This was not a duplicate fully. The related issues mentioned do not include isScared nor isRolledUp. Additionally they force reliance on the states, which if minecraft ever changes functionality can hurt. Example can be seen within panda isScared, where it checks checks if it has the gene worried and if the current level is thundering
But I do acknowledge where you're coming from
Requests for such methods can be made on the existing issue or pr, otherwise we have two issues for functionally the same thing, which we'd rather not have
[PaperMC/Paper] New branch created: feat/snbt-stack-serialisation
e327618 Cursory conversion towards using SNBT for ItemS... - electronicboy
Applied requested changes
So, another bit that came up in some related discussion is that this concept also applies to e.g. sweeping edge attacks.
They also find themselves with similar "computation" logic in the attack bit.
Might be something to keep in mind when deciding between event naming, event layout etc. Not that I have much time for that rn, but for future reviews on this PR, the concept ought to be considered.
So, another bit that came up in some related discussion is that this concept also applies to e.g. sweeping edge attacks. They also find themselves with similar "computation" logic in the attack bit.
Might be something to keep in mind when deciding between event naming, event layout etc. Not that I have much time for that rn, but for future reviews on this PR, the concept ought to be considered.
Well I am not sure how this can be aligned other than naming the event specific enough for crits. It would be nice to have crits and sweaping under one event, but I don't think that can be done easily. Or you had some solution in mind to unify those two under one event?
Heh I didn't have a solution in mind no.
Yea we can either look to unify these, making it potentially harder if they split, or we maybe look for a name that like, can just replace "Critical" with "Sweeping" or something and then they can be semi sister events. But yea, as said, for future people to just keep in mind when they review it.
I'd hate to name it something to specific to crit and then the sweeping edge one comming 3 commits later is named completely differently even tho they sit in the same logic bit.
Ah. got you! I will keep that in mind!
Expected behavior
This is a somewhat recent "breakage", this behavior changed sometime after 1.21.3 (unsure when in 1.21.4)
Calling PlayerTeleportEvent::getTo(), modifying that object and calling setTo() should modify the teleport destination.
Frankly simply calling getTo() and modifying it should also modify the teleport destination given it is returned by ref, however my plugin always called setTo anyway.
Observed/Actual behavior
Unless the result of getTo() is cloned before passing it to setTo() the teleport destination is unchanged.
Steps/models to reproduce
public void onEvent(PlayerTeleportEvent event) {
Location dest = event.getTo();
if (dest == null) {
return;
}
dest = event.getTo(); // cloning this object here restores correct behavior
dest.add(0, 8, 0);
event.setTo(dest);
}
Plugin and Datapack List
[22:19:37 INFO]: โน Server Plugins (2):
[22:19:37 INFO]: Bukkit Plugin...
So far I haven't been able to reproduce the bug. Does it persist when you change the event parameter's type from PlayerTeleportEvent to PlayerMoveEvent?
Not an vanilla issue. Tested on vanilla, purpur 1.21.4, paper 1.21.4 and spigot 1.21.4 with same world. Works perfectly on Spigot and Vanilla, can't find their beds on Paper & Purpur
Can't exactly test in-game right now, but from looking at the code, this is valid and should only happen when teleporting with ender pearls
This fork adds Leaflitter and Wildflowers from the new 1.21.5 Update by updating specific bukkit classes
This fork adds Leaflitter and Wildflowers from the new 1.21.5 Update by updating specific bukkit classes
We do not accept PRs while we are activing updating paper.
Is your feature request related to a problem?
ProjectileLaunchEvent isn't called for eye of ender being launched for some reason
Describe the solution you'd like.
make it call ProjectileLaunchEvent or PlayerLaunchProjectileEvent
Describe alternatives you've considered.
No valid workarounds
Other
No response
Ender eyes are not projectiles, you can listen to the PlayerInteractEvent, check for right click action and the interacted item type. Is there a use case for a new event that this approach doesn't cover?
db92de8 rework main entry point, fix class loading issu... - Lulu13022002
Depending on your use case, it's also possible to cancel the StructuresLocateEvent to prevent it from being thrown entirely
Looks good. test plugin changes and print statement need to be removed on merge
2df1dc4 Update ItemType manually for 1.21.5 - lynxplay
fa0dd15 add missed nullability annotations - MiniDigger
I think it would be better if we moved the removal of the items past the dropAllDeathLoot call so we don't remove those items at all before we know the event was cancelled. this way. this would also restore parity with other entities which also have the event called with their equipment/items still on
b92137c load the PDC for new block entities - Lulu13022002
Introduces a new option in WorldCreator to enable or disable bonus chest generation.
So how about:
PlayerResolveCriticalHitEvent or PlayerResolveCriticalAttackEvent
and potentially in the future PlayerResolveSweepAttackEvent
?
Ender eyes are not projectiles, you can listen to the PlayerInteractEvent, check for right click action and the interacted item type. Is there a use case for a new event that this approach doesn't cover?
predicting whether the interact event will work is near impossible, you need to check material.isinteractable but there are 100000 edge cases and it depends what you have in offhand or if you are sneaking etc etc, we need a proper postplayerinteractevent that runs after interaction and includes the interactresult
for example, im already using playerinteractevent to prevent people throwing eye of ender, but if they right click on a villager or cauldron it throws the pearl, because my code is checking the clicked block isnt interactable already.
[PaperMC/Paper] New branch created: chore/cleanup-c
-
for CraftEntity#teleport the event is called twice only for cross world teleports. This was fixed by adding a check before the event call in CraftEntity#teleport to check if the destination and current location are of the same worlds and if they are, we don't call the event and the event is fired from vanilla teleport.
-
for vanilla tp class, the event call is entirely removed and the event will be called from vanilla teleport.
[PaperMC/Paper] branch deleted: chore/cleanup-c
Welcome to paper :partying_face:
It appears you commit / generate a whole slew of completely unrelated and invalid changes.
Please make sure to remove them so we can review your PR change.
What is your XY here over simply preventing the EntitySpawnEvent?
That will prevent consuming the stack too.
What is your XY here over simply preventing the EntitySpawnEvent? That will prevent consuming the stack too.
i have an eye of ender for hub selector, people can throw it, losing the selector
Yes, cancel the EntitySpawnEvent then. Prevents the consumption of the item.
I would suggest rebasing this PR or creating a new one
I would suggest rebasing this PR or creating a new one
I don't want to create a new one because this is my first PR and its number is 12345. I will look into rebasing the codes
cf1455e Ignore private methods in MaterialReroutingTest - kennytv
Is your feature request related to a problem?
During the implementation of a custom explosion, where I wanted more control over the blocks actually involved in the explosion, I came across a lack of API. Basically, you are currently only able to explode manually using boolean World#createExplosion(...) and its many many overloads. You cannot actually retrieve the blocks that would be broken by a theoretical explosion, and perform your own logic, so not exploding certain blocks, or running some sort of operation on them instead of just removing them.
Describe the solution you'd like.
I'd like a new collection of methods, List<Block> World#getExplodedBlocks(...), which run the underlying ServerExplosion#explode() logic until the this.calculateExplodedPositions() part, and then returns. Perhaps instead of it being a List<Block>, it could be more versatile and instead be a record class, which also contains data for stuff like potential fire locations (if fire is ena...
This fixes issue #10323. Currently, the respawn sequence of the Ender Dragon has a noticeable lag spike, likely caused by the method findExitPortal() being poorly optimized, and calling the method find() (which is an expensive method, in terms of server execution time) multiple times, unnecessarily.
Solution: fix index incrementation and direct the search to the most likely spot first, instead of iterating over various blocks, calling find() without first checking whether it makes sense to call it for the instance of the block considered. Also, pre-fetching the relevant chunk does improve following computations.
Good afternoon (at least where I live). I believe this patch fixes this issue smoothly, without affecting gameplay negatively, on the contrary. Me and my colleague have tested this thoroughly and found no game-breaking behaviour. Please let me now, in case there is anything out of the ordinary.
Yeah, sorry, my primary use case is around pearl use - I probably over-trimmed the example
What is the use case here, why you can't use the setter?
Someone on discord complained that you can't override the getter. I thought it makes sense to do either.
Is your feature request related to a problem?
Like Enchantments and, more similarly, Painting Variants, certain mob variants are now data-driven as of Minecraft 1.21.5. Those being:
- Wolf
- Cat
- Frog
- Chicken
- Cow
- Pig
With this list ever-expanding, exposing this functionality will give plugin developers the opportunity to easily add new forms of these entities with the help of a resource pack - something that has previously been possible only through mods, and is only now possible with data packs.
Describe the solution you'd like.
A new RegistryEntry and RegistryEventProvider for each of the new mob variants to allow dynamic registration of new mob variants during the bootstrap phase.
Describe alternatives you've considered.
This is currently easily possible through data packs, however the ability to add "new" mobs in a way is something that plugin developers have dreamed of since the early days of server-side modding.
Other
No response
This issue likely arose from the method findExitPortal(), which has been optimized. This optimization will ensure better server performance during the respawn sequence and smoother gameplay.
Signed-off-by: Afonso Jacinto
afonso.mendonca.jacinto@tecnico.ulisboa.pt
this is the cause of the issue right?
It is possible for a Sound to be custom where it doesn't have a Minecraft NamespaceKey as a Holder.Direct. This will cause the serialization of CraftEquippableComponent to throw the following error:
java.lang.IllegalStateException: Cannot get key for this registry item, because it is not registered.
at io.papermc.paper.util.OldEnumHolderable.lambda$getKey$0(OldEnumHolderable.java:71) ~[purpur-1.21.4.jar:1.21.4-2406-4a3b139]
at java.base/java.util.Optional.orElseThrow(Optional.java:403) ~[?:?]
at io.papermc.paper.util.OldEnumHolderable.getKey(OldEnumHolderable.java:71) ~[purpur-1.21.4.jar:1.21.4-2406-4a3b139]
at org.bukkit.craftbukkit.inventory.components.CraftEquippableComponent.serialize(CraftEquippableComponent.java:84) ~[purpur-1.21.4.jar:1.21.4-2406-4a3b139]
I believe instead of failling is this manner, we should add a check the sound's NamespacedKey for null just like model and camera-overlay attributes.
Making it lose the sound is not nice at all, I think the proper alternative solution is the https://github.com/PaperMC/Paper/tree/feat/snbt-stack-serialisation which uses proper serialization for such objects
I understand, but I need it for backward compatibility at the moment, and it will take some effort for my plugins to adopt this new system. I think this change makes sense instead of erroring out the entire item stack serialisation process.
d6c81da Add flag to simplify remote matching logic - kennytv
3cb8529 Add flag to simplify remote item matching logic - kennytv
2552abf fix message mutation in PlayerSetSpawnEvent - Lulu13022002
Expected behavior
I expect structures to generate when I return true for shouldGenerateStructures()
Observed/Actual behavior
I noticed when doing some generator stuff, that structures aren't placed into the world when ChunkGenerator#shouldGenerateDecorations() return false.
I did some digging and came to the realization why this happens.
Structures are broken up into 2 parts:
-
StructureStarts = This is an early stage in the generation steps. Minecraft decides which types of structures will go where.
When usingshouldGenerateStructuresreturned as true... this stage decides it will place a structure there. -
StructurePlacements = Later on in the chunk generation steps, in the same stage that decorations (features) are placed, the structure pieces are also placed.
After seeing this in the code I realized ifshouldGenerateDecorationsreturns false (thus preventing features from being placed), the structure piece placements are also skipped.
When this happens, t...
The exit location passed to PlayerTeleportEvent/PlayerTeleportEndGatewayEvent in ServerPlayer#teleport(TeleportTransition) needs to be cloned, as it is later compared in case it was changed. Not cloning it results in the ability for plugins to mutate it but such changes will be ignored, as the instance of the Location being the same results in a successful equality check.
It is not necessary to clone the location in other instantiations of the event (or subclasses) as those are not compared afterwards to change the outcome.
Fixes #12340
lynx can cherry-pick this commit for the 1.21.5 branch
New features
- Item Creator--allows developer to more easily create custom items
- Animal Creator--allows developer to more easily summon animals
Features
- Streamlined process of creating items with custom meta
- Streamlined process of summoning animals
Welcome to paper :partying_face:
Thank you for your first PR.
We are not interested in these kinds of utility helpers, especially since helpers like ItemType#createItemStack already exist, which allow modification of itemstacks in a few lines.
If developers require these locally, they can create those, otherwise there is a slew of available utility libraries out there :)
Welcome to paper ๐ฅณ
Thank you for your first PR.
We are not interested in these kinds of utility helpers, especially since helpers like ItemType#createItemStack already exist, which allow modification of itemstacks in a few lines. If developers require these locally, they can create those, otherwise there is a slew of available utility libraries out there :) Thank you anyway for the suggestion!
Thanks for the quick response! I'll try to come up with something unique and try again!
I am going to close this regarding the above solution.
If more specific needs come up, a new issue should be opened, but this usecase can be solved by the EntitySpawnEvent.
I see how changes to the instance fields x, y, and z of exit would be ignored were newExit.equals(exit) to return true, since the condition !newExit.equals(exit) would consequently evaluate to false. They would be ignored in the sense that they would have no effect on the teleport transition resulting from tpEvent; teleportTransition would not be reassigned, so its value would remain what it was when teleportTransition was passed to ServerPlayer#teleport(TeleportTransition).
But if I'm not mistaken, newExit.equals(exit) does not necessarily return true if newExit and exit refer to the same instance of Location. Location#equals(Object) contains if statements that check via bitwise comparison if this location's x, y, and z fields have the same numeric values as the argument's x, y, and z fields, respectively. Thus, as long as a plugin successfully mutates one of those fields of exit before the invocation of equals in the conditi...
Expected behavior
The player's items should drop normally
Observed/Actual behavior
When the player dies, the item is dropped, but the inventory is keep?
Steps/models to reproduce
1.I compile Paper 1.21.5
2.launch server(gamerule KeepInventory is not open)
3.get some item
4.Find a way to kill yourself
5.Items in the inventory are keep, but you can drop your item
Plugin and Datapack List
[10:18:32 INFO]: โน Server Plugins (12):
[10:18:32 INFO]: Paper Plugins (2):
[10:18:32 INFO]: - AdvancedServerList, HuskHomes
[10:18:32 INFO]: Bukkit Plugins (10):
[10:18:32 INFO]: - CatSeedLogin, DecentHolograms, GSit, PlaceholderAPI, SkinsRestorer, TAB, ViaAprilFools, ViaBackwards, ViaRewind, ViaVersion
[10:19:15 INFO]: There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
[10:19:15 INFO]: There are no more data packs available
Paper version
[10:20:49 INFO]: This server is running Paper version 1.21.5-DEV-update/1.21.5@2552abf...
dca4aab add util methods to CraftChatMessage - MiniDigger
Looks like it is indeed pretty much client sided, I have the same issues in vanilla.
I don't think we can fix this.
87c9d9b be more lenient on url parsing for legacy format - Lulu13022002
4a9bd2e Correctly clear items in PlayerDeathEvent - lynxplay
Resolved in https://github.com/PaperMC/Paper/commit/4a9bd2e37028fcc42f52fef40ac31b374743fbb5, thank you for the report <3
fixes #12353
Please feel free to let me know if any other simpler fix is possible
So, the boolean check there might want to respect the bukkit ChunkGenerator#shouldGenerateStructures method.
Similar to how the applyBiomeDecoration method in CustomChunkGenerator respects shouldGenerateDecorations
a70f774 fix unsaveable launched trident - Lulu13022002
Normally NoGravity is checked in getGravity but fishing bobbers don't call or override it with an appropriate value.
Nevermind, the client prediction makes this too glitchy to be useful.
Stack trace
To be honest, I'm not sure whether this issue should be fixed by Paper or if the plugin developer needs to update their plugins. Currently this happens to Axiom and Noxesium.
DiscardedPayload function is changed in build-222.
Everything works fine in build-221.
[21:32:19 ERROR]: Error occurred while enabling AxiomPaper v4.0.2 (Is it up to date?)
java.lang.NoSuchMethodError: 'void net.minecraft.network.protocol.common.custom.DiscardedPayload.<init>(net.minecraft.resources.ResourceLocation, io.netty.buffer.ByteBuf)'
at AxiomPaper.jar/com.moulberry.axiom.AxiomPaper.onEnable(AxiomPaper.java:160) ~[AxiomPaper.jar:?]
at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:280) ~[paper-api-1.21.4-R0.1-SNAPSHOT.jar:?]
at io.papermc.paper.plugin.manager.PaperPluginInstanceManager.enablePlugin(PaperPluginInstanceManager.java:202) ~[paper-1.21.4.jar:1.21.4-222-9b1798d]
at io.papermc.paper.plugin.manager.PaperPluginManagerImpl.enablePlugin(PaperPluginMa...
Needs to be fixed on the plugins end. We simplified that logic in a recent commit (9b1798d6438107fdf0d5939b79a8cf71f4d16e2c)
This pr only fixes the vanilla tp firing the EntityTeleportEvent twice.
Just came across this issue while making a plugin that needs to check if a player is inside a structure.
It would be VERY neat if this was going to be changed.. Currently I need to calculate/fix the position myself as good as I can but natively would be very so much better.
Expected behavior
Abilities shouldn't change
If the player is in survival or adventure mode and are able to fly, that behavior should persist across dimension teleports
Observed/Actual behavior
When teleporting across dimensions, the abilities are reevaluated
For reference
CraftPlayer#teleportcallsPlayerList#respawnL1511PlayerList#respawncallsPlayerList#restoreFromL2052PlayerList#restoreFromcallsServerPlayerGameMode#setGameModeForPlayerL93
Steps/models to reproduce
- Set the player's game mode to survival or adventure
- Allow the player to fly (Player#setAllowFlight)
- Teleport the player into a different dimension via Player#teleportAsync important
- Player is not able to fly anymore
Plugin and Datapack List
plugins: Tweaks
datapacks: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
Paper version
This server is running Paper version 1.21.4-222-main@9b1798d (2025-03-27T13:35:40Z) (Implementing ...
Spark Profile
https://spark.lucko.me/xttFcIZuCd
Description of issue
This event is quite hot so calling .clone() in every listener has a measurable performance impact, it'd be nice if we get a method that returns the spawn location directly without clone()
Plugin and Datapack List
N/A
Server config files
N/A
Paper version
Paper 1.21.4 BUILD 222
Other
No response
The spark report is unavailable/expired, please reupload it. 10 microseconds is not going to slow down the tick rate of the server (0.02% of an acceptable MSPT!), the location is cloned is so plugins can't just modify it, affecting other plugins' readings, but without the actual spark report there is little to go off of.
wait. it is not done. I will inform it is ready for review when I end all of rebase procedure
I did it. I am now the master of rebase. I am ready for review.
The spark report is unavailable/expired, please reupload it. 10 microseconds is not going to slow down the tick rate of the server (0.02% of an acceptable MSPT!), the location is cloned is so plugins can't just modify it, affecting other plugins' readings, but without the actual spark report there is little to go off of.
Is there a more efficient way to prevent mob spawns in certain areas? I am aiming for zero cost plugins, i.e don't show up on spark report, I have mostly been successful except for this where seems to be no possible workaround
Opening a PR because I generally forgot to and we might want more discussion on this;
I am planning to add an "sv" tag incase we want to change the format here or something, but, this is how this currently looks:
item:
==: org.bukkit.inventory.ItemStack
components: '{"minecraft:written_book_content":{"title":{"raw":"Jon"},"author":"The
Destroyer","pages":[{"raw":"hi"}]}}'
count: 1
DataVersion: 4325
id: Minecraft:written_book
It's worth noting that I referenced the vanilla codec for what to serialise, and followed the logic which follows and adds the DV onto that; There was maybe a talk of extracting out the top layer of components;
==: org.bukkit.inventory.ItemStack
components:
minecraft:written_book_content: '{"title":{"raw":"Jon"},"author":"The Destroyer","pages":[{"raw":"hi"}]}'
minecraft:max_damage: '20'
sv: 2
count: 1
DataVersion: 4325
id: minecraft:written_book
I generally want to avoid...
Welcome to paper ๐ฅณ
It appears you commit / generate a whole slew of completely unrelated and invalid changes.
Please make sure to remove them so we can review your PR change.
Again, would need to see a real spark report, plus corresponding code, to have a sense with what we're dealing with here in terms of configuration, environment, hardware etc. Having attempted to reproduce this issue myself, even after configuring high spawn rates, heaps of things showed up on the spark report without location cloning being one of them (and the way that the way profiling works means that there is always a chance, even if miniscule, that your plugin shows up in a report even if it doesn't do anything intensive). Exposing the uncloned location is not something we want to do, and without information on how to make this reproducible, spending development time in problems that don't exist is not something we aim for.
Hey! I have implemented this locally for chickens so far, and I'd be happy to make a PR for it. That way you can give feedback on what I have, I can improve it, and implement the other mob variants.
Yeah, you can open a PR. The biggest things to decide is representing spawn conditions as well as the modelandtype. Cause some of those types probably have use outside the registry API.
#12350 Currently only implemented Chicken variants as a way to gather feedback before adding the rest. I'm especially wanting opinions on the best way to implement SpawnConditions to the API, as those have intentionally been left out of this, but right now custom mob variants are given SpawnPrioritySelectors.EMPTY.
ModelAndTexture has been separated into Model and Texture for API purposes, as the vanilla-defined models are not entirely the same across each mob and are unfortunately stored as enums. assetId is required, and model will default to NORMAL.
Done! #12364 I agree with you, especially on the SpawnConditions. I was a little stumped on the best way to go about adding that myself, so they have been intentionally left out while we brainstorm ideas.
Hello, has this been implemented yet? As I am currently seeing myself finding this exact need.
Discussion Category: Ideas
Expected behavior
Successfully inflicts damage to the entity with the second weapon's enchantment and weapon characteristics, as well as the first weapon's base damage, and the attack cooldown is calculated based on the first weapon. e.g. Kill a zombie in a video (base damage from the sword plus enchantment damage from the mace)
Vanilla Features Available in vanilla and paper1.21#206 and earlier
https://github.com/user-attachments/assets/03fe9091-33eb-41c4-bd67-ca8fd000b420
https://github.com/user-attachments/assets/24b73255-29d0-465e-b22e-50a49353e0b1
Observed/Actual behavior
The damage dealt to entities is only the base damage and stat damage of the second weapon, and does not count the base damage of the first weapon, and the attack cooldown is calculated according to the second weapon, for example, zombies cannot be killed in the video
https://github.com/user-attachments/assets/1f5eaa4a-259e-4cb2-940f-dc80cbfa3dc6
https://github.com/user-attachments/assets/61271140...
This is a bug, not a feature; there is a configuration option to restore the functionality of this bug
Adding my own additional user report in case it helps.
This same thing occurs in EntityDamageByEntityEvent when calling Event#setCancelled(true) and then LivingEntity#damage() on the target with the DirectEntity and CausingEntity set on a DamageSource builder. If the target dies from the LivingEntity#damage(), both events will trigger a DeathEvent and send their death messages, unless you wrap your LivingEntity#damage() in a BukkitRunnable with a 1 tick delay.
Expected behavior
Observed/Actual behavior
For example if a plugin prints a stack trace to the console, it looks like this.
[00:00:00 WARN]: java.lang.Example: Example message
[00:00:00 WARN]: at MyPlugin-1743417635640.jar//com.example.myplugin.Example.hello(Unknown Source)
[00:00:00 WARN]: at MyPlugin-1743417635640.jar//com.example.myplugin.MyPlugin.test(Unknown Source)
...
[00:00:00 WARN]: at net.minecraft.server.MinecraftServer.tickServer(MinecraftServer.java:1596)
[00:00:00 WARN]: at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1302)
[00:00:00 WARN]: at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:329)
[00:00:00 WARN]: at java.base/java.lang.Thread.run(Thread.java:1583)
As you can see, the remapped plugin has no line numbers but the normal minecraft and java code does.
- Example.hello(Unknown Source)
- MinecraftServer.tickServer(MinecraftServer.java:1596)
Ob...
The bug
If the result slot of a crafting grid is taken, and no recipe exists for the craft, the input materials get duplicated.
This happens when, for example, PrepareItemCraftEvent is used to override the result slot using inventory.setResult(). That is useful for creating dynamic recipes, like dye mixing, something that isn't yet possible to do with regular json recipes.
https://github.com/user-attachments/assets/e44e56f6-334d-459b-8283-7364af82f55f
Why it happens
The issue is in the ResultSlot#getRemainingItems method, which gets called when the craft result is taken. It is used to add remainder items to the crafting grid (e.g. water bucket -> bucket).
private NonNullList<ItemStack> getRemainingItems(CraftingInput input, Level level) {
return level instanceof ServerLevel serverLevel
? serverLevel.recipeAccess()
.getRecipeFor(RecipeType.CRAFTING, input, serverLevel, this.craftSlots.getCurrentRecipe()) // Paper - Perf: Imp...
Iโve added snakes to Minecraft! Feel free to adjust, remove, or modify any features as needed. Iโm also open to any feedback or suggestions for improvement. Hereโs a bit more about what Iโve done:
-
Snake Movement: The snake moves towards the nearest player within range.
-
Bite Mechanic: The snake can bite players, dealing damage.
-
Hissing Sound: The snake plays a hissing sound when active.
How is this in paper scope ๐ญ๐๐ผ
How is this in paper scope ๐ญ๐๐ผ
cuz why not
This is not in the scope of Paper, nor does this cater to the design of the API or its namespacing, etc
Expected behavior
Hello,
I'd like to report what I believe is a bug in Paper where an exception is raised by a simple method call.
Observed/Actual behavior
[19:41:24 ERROR]: Could not pass event InventoryOpenEvent to Protect v2.4.6
java.lang.IllegalStateException: No numeric custom model data
at com.google.common.base.Preconditions.checkState(Preconditions.java:513) ~[guava-33.3.1-jre.jar:?]
at org.bukkit.craftbukkit.inventory.CraftMetaItem.getCustomModelData(CraftMetaItem.java:1417) ~[paper-1.21.4.jar:1.21.4-138-5395ae3]
at Protect-2.4.6.jar/org.mineacademy.protect.operator.Rule$RuleCheck.check0(Rule.java:418) ~[Protect-2.4.6.jar:?]
at Protect-2.4.6.jar/org.mineacademy.protect.operator.Rule$RuleCheck.checkPlayerInventory(Rule.java:260) ~[Protect-2.4.6.jar:?]
at Protect-2.4.6.jar/org.mineacademy.protect.operator.Rule.filter(Rule.java:200) ~[Protect-2.4.6.jar:?]
at Protect-2.4.6.jar/org.mineacademy.protect.operator.Rule.filterOpenContainer(Rule.java:148) ~[Protect-2.4...
The problem here is that ItemMeta is inherently flawed, what hasCMD checks is not what getCMD checks; Not really sure what would be a solution here which isn't just returning bad data, I'd suggest migrating from using that method in modern versions
I understand that ItemMeta is poorly done, but I don't think plugin authors should receive an error by just calling it. A short term fix would just be to silence this error.
Thanks for the suggestion, can you please provide a pointer what I can call instead?
We cannot silence the error.
What would the method return in such a case? 0? -1?
A plugin would believe it has a custom model data int, when it doesn't.
[PaperMC/Paper] New branch created: jd/getCustomModelData-deprecation
672e346 Deprecate ItemMeta#get/setCustomModelData - electronicboy
The API is no longer able to properly reflect the internal state here
References #12369
The issue is that the only botch here is to return invalid state, which either breaks the old API, or, breaks the new API; Best option long run is to just deprecate the entire CMD set of methods inside of IM and use the DataComponent API. The IM methods are not able to properly reflect current state at all.
0037997 git lied to me - electronicboy
Expected behavior
Spectral arrow should spawn with the yaw provided in the location to world.spawn()
Observed/Actual behavior
it always spawns with 0 yaw, resulting in the arrow moving sideways unless facing south direction
Steps/models to reproduce
SpectralArrow spectralArrow = arrow.getWorld().spawn(player.getEyeLocation(),
Plugin and Datapack List
N/A
Paper version
This server is running Paper version 1.21.4-DEV-main@c467df9 (1970-01-01T00:00:00Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are 1 version(s) behind
Download the new version at: https://papermc.io/downloads/paper
Previous version: 1.21.4-DEV-894631f (MC: 1.21.4)
Other
also occurs for regular arrows
getEyeLocation uses the entities yaw, not the yaw of the 'head' or whatever, I think this is like a WAI
Right, appreciate the explainer. I'll look into the DataComponent API then!
The server explicitly uses the set_rot spawn config for (most) projectiles.
If you want them to move a certain way, you ought to use the launchProjectile/teleport them yourself after.
I don't think there is merit in change this long standing API behaviour.
Expected behavior
Virtual world borders set to specific player would act as normal world border, taking damage when outside of the world border and not glitching when global world border is smaller then player's one.
Observed/Actual behavior
When player has virtual worldborder, server doesn't check if player is inside or outside of the worldborder which causes, that player doesn't take damage when outside but still takes damage if outside the global world border.
Steps/models to reproduce
Using this code, I'm able to set player's world border to be visible only to him with specific center and size (virtual world border).
Checking that position is always in relation to global world border, which creates weird invisible border, if the global one is smaller than player's one that he can see.
I didn't found any other way how to set virtual worldborder to certain player with allowing to check its position and dealing damage afterwards. (If it is possible, than correct ...
This was implemented as a visual thing only by spigot; would maybe need to expand the API out a little bit to cover this sorta usecase, not sure how viable/tenable it would be to deal with, and could easily be reprelicated by a plugin checking if their player is in the box of the border
Yea, spigot started something and didn't finish that sadly. It works good until player gets outside of his "visual" wb, causing him not to die and be able to place blocks 1 block further that it should. It would be really nice, if this gets fixed or recreated with new working API.
You can do this easily by just checking the player location yourself as specified above.
I'd argue this is a feature request.
I'm not saying there is no other way how to keep player inside his box (kinda simple task), it would be nice, that in feature, this would be one of the fully working ways how to do it. If I had more time, I would rework that API, but currently other projects have to be done asap. So, yea, this is wrongly tagged issue, shoud be feature request, my bad.
[PaperMC/Paper] branch deleted: update/generators
[PaperMC/Paper] New branch created: fix/gen-circular-deps
8153c56 remove paper-api dependency (wip) - Lulu13022002
getEyeLocation uses the entities yaw, not the yaw of the 'head' or whatever, I think this is likely a WAI
no try it yourself, spawning arrow with location of any yaw will always have its yaw be 0
Yes as stated, the server specifically does not copy yaw/pitch onto projectiles when spawed via this method.
This is expected behaviour of the spawn method, not a recently introduced bug.
Yes as stated, the server specifically does not copy yaw/pitch onto projectiles when spawed via this method. This is expected behaviour of the spawn method, not a recently introduced bug.
why? it does for all other entities, how are you meant to cleanly spawn an arrow facing a certain direction? teleport? ๐คฎ
Projectiles are expected to come from an entity source, anything else is going to basically be a case of setting that information onto the arrow entity manually. The vanilla ctors' do not handle this and instead rely on everything calling a method which sets the vector and other attributes on the arrow. This is generally not behaviour worth deviating from, you'd need to apply some form of vector anyway
@lynxplay @electronicboy
I'd glad for you to take a look whenever you are not busy guys. thanks for your patient.
The current logic for the portal gets the portal blocks incorrectly. It retrieves blocks in a diagonal line, as seen below (the two lime wool are part of this incorrect line). This PR changes the variable used to correctly align the blocks retrieved.
[PaperMC/Paper] Pull request opened: #12374 Fix floating warning log when the kick event is canceled
Currently, the floating kick log is sent before the PlayerKickEvent is fired, resulting in incorrect and potentially spammy logging when the event is properly cancelled. This PR fixes the issue by moving the logging to be sent after the event logic.
You should use fully qualified names to avoid imports in NMS code...
Generally in favour of a schema version, the name sv sounds rather unfun for it, the couple of characters schema or something would take are not gonna break our necks.
Auto import issues... Fixed!
That's fair, but generally this event call is weird because:
- the blocks around the portal are not really created at this point (i get why it's exposed but that will conflict with 2)
- plugins can't mutate the new block states here unlike the other call of the events
Yea, I just wasn't sure if I go for paper:schema_version or just s..._v... or what, so, figured I'd push before I went to go bed or be productive
Is your feature request related to a problem?
Enchantment descriptions aren't i18ned
Describe the solution you'd like.
Enchantment descriptions are sent to the client in the registry (which I guess got left out when doing i18ns because they don't contain appearant rich text). So I think we can reconfigure the player's registries with rendered translated text each time they switch locales
Describe alternatives you've considered.
Render the enchantments into item lore. Not a neat solution though.. and if I wanna be rigorous I'd have to re-render the lore each time a new player picks up the item / switches locales
Other
Apart from enchantments, I found the following registries with rich text
painting_variantinstrumenttrim_materialtrim_patternjukebox_songadvancementbanner_patterndoes not contain rich text. It stores the translation key prefix, not the text(the suffix is a dye color)
Discussion Category: Ideas
This has already been suggested/discussed, but ItemStack contents cannot be modified on the fly due to how aspects like Creative Mode work. This would generally be destructive or require fairly excessive network time translation of stuff; this is generally just not something that we deem viable or are comfortable with.
Discussion Category: Ideas
If this were to be implemented, it should be optional, or it would probably break plugins.
I, for example, use this feature to make the world border disappear for players when they are not near it and expect it the virtual border only be visual. I want the global world border to be the only border to actually do something (so the opposite of your use case)
My testing was for lighting an already-created (player-built) portal, meaning the obsidian already exists in that context. Looking at the code for exit portal generation, I can't seem to find where the obsidian is actually set in the level. In my case, though, I'm able to modify the obsidian because it's not modified by the portal's creation.
[PaperMC/Paper] Issue opened: #12377 enable-item-obfuscation option makes fireworks effect invisible
Expected behavior
fireworks explosions show blast effects
Observed/Actual behavior
fireworks explosions don't show blast effects if enable-item-obfuscation is true
Steps/models to reproduce
- modify paper-global.yml
anticheat:
obfuscation:
items:
enable-item-obfuscation: true
- launch a fireworks rocket
Plugin and Datapack List
[02:32:44 INFO]: Server Plugins (5):
[02:32:44 INFO]: Bukkit Plugins:
[02:32:44 INFO]: - AuthMe, ForceResourcepacks, SkinsRestorer, ViaBackwards, ViaVersion
Paper version
version
[02:29:59 INFO]: Checking version, please wait...
[02:30:00 INFO]: This server is running Paper version 1.21.4-222-main@9b1798d (2025-03-27T13:35:40Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-211-6ea4202 (MC: 1.21.4)
Other
No response
Expected behavior
Attack strength should be reset on player actions (such as item swap)
This should be an extension of https://github.com/PaperMC/paper/issues/12257
Observed/Actual behavior
it doesn't reset
Steps/models to reproduce
Reproduce steps are same to https://github.com/PaperMC/paper/issues/12257
Plugin and Datapack List
[02:32:44 INFO]: Server Plugins (5):
[02:32:44 INFO]: Bukkit Plugins:
[02:32:44 INFO]: - AuthMe, ForceResourcepacks, SkinsRestorer, ViaBackwards, ViaVersion
Paper version
version
[02:29:59 INFO]: Checking version, please wait...
[02:30:00 INFO]: This server is running Paper version 1.21.4-222-main@9b1798d (2025-03-27T13:35:40Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-211-6ea4202 (MC: 1.21.4)
Other
No response
Yea, of course it would have to be as optional or with some kind of settings per WB with defaulting to visual-only so it doesn't break any logics others use.
Changes between generated comments will be lost. Registration is now done in RegistryEntries in the generator module. I have some plan later to move that over a json file but for now that should do it. The registry don't need to be delayed too.
Previously, Zombified Piglins did not properly reset their aggression after a player's death, causing some to remain hostile. To fix this, an instance of the ResetUniversalAngerTargetGoal class is now an attribute of the ZombifiedPiglin class and its start() method is called upon player death(in the startPersistentAngerTimer method). This ensures that only ZombifiedPiglin entities within a range are being reset. Additionally, the expected behavior of Zombified Piglins has been updated to consistently use this reset mechanism, ensuring proper forgiveness behavior.
Video showing the problem solved:
https://www.youtube.com/watch?v=LxUmljnKg40
The video is in Portuguese, due to the fact I am still in college and doing this for a course. Sorry for the inconvenience.
Not sure if this is worth testing, as this API is generally "obsolete" with our new API and I am not sure if introducing changes is the best.
This doesn't fix the issue (considering the issue isn't marked as accepted and i am personally not able to reproduce it i am not sure there even is an issue). It actually instead causes the server to deadlock if PigZombieAngerEvent is cancelled and there is at least one other zombie piglin around as startPersistentAngerTime -> resetUniversalTarget#start -> forgetCurrentTargetAndRefreshUniversalAnger -> startPersistentAngerTime after which the entire thing will repeat now from the other entity.
I think we should additionally reset aboveGroundTickCount when the server attempts to disconnect a player to prevent the event from being spammed
This did actually fix the issue in my personal build and did not deadlock the server at all. I have no idea what is happening on your side. Can you guide us with steps to reproduce that deadlock?
Hello notTamion, I have a video I recorded for my course to confirm that this was indeed a bug. The recording was made before the 'solution' was implemented.
The video is very poor quality, but if you skip to the minute 7:04, where I died for piglins, I respawn, go through the nether portal and after a "tick" they start attacking me without me doing anything to them.
The video is still made in Portuguese, I apologize for that inconvenience.
Link: https://www.youtube.com/watch?v=FTUF9b1ps8A
Update: Fixed the boolean check to also trigger event and allow teleport for null worlds in CraftEntity#teleport
Can you guide us with steps to reproduce that deadlock?
- cancel PigZombieAngerEvent via a plugin or debuggery
- spawn 2 zombified piglin next to each other
- hit one of them in survival mode
- see the console for StackOverflowErrors
i do not see how this could fix the issue. As the only time your code actually gets run is when the event is cancelled, in which case it leads to a deadlock. I will take another stab at reproducing the issue later.
Thank you, I have made the proposed changes and went forward with implementing the rest of the data-driven mob variants in a similar way to that of the Chicken Variants from before.
Is your feature request related to a problem?
Not really. Just new API that would be nice.
Describe the solution you'd like.
Minecraft 1.21.5 added a new feature for "strict" placement of structures using the structure block and /place template command.
Strict placement allows for the structure to be placed without block updates, ex: water not flowing.
Looking into how the command/structure block do it, it would be as easy as changing this line:
https://github.com/PaperMC/Paper/blob/9b1798d6438107fdf0d5939b79a8cf71f4d16e2c/paper-server/src/main/java/org/bukkit/craftbukkit/structure/CraftStructure.java#L100
changing the flags from 2 to 2 | (strict ? 816 : 0) and adding in a method parameter for strict
Describe alternatives you've considered.
Nothing I can think of!
Other
No response
PlayerList#broadcastAll(Packet, Player) is not thread safe and can result in errors like this:
[15:04:46] [Async Chat Thread - #91/ERROR]: Chain link failed, continuing to next one
java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
at java.base/java.util.concurrent.CopyOnWriteArrayList.elementAt(CopyOnWriteArrayList.java:390) ~[?:?]
at java.base/java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:403) ~[?:?]
at net.minecraft.server.players.PlayerList.broadcastAll(PlayerList.java:982) ~[spigot.jar:1.21.3-DEV-020e886]
at net.minecraft.server.network.ServerGamePacketListenerImpl.lambda$resetPlayerChatState$16(ServerGamePacketListenerImpl.java:3667) ~[spigot.jar:1.21.3-DEV-020e886]
at net.minecraft.util.TaskChainer.lambda$append$0(TaskChainer.java:26) ~[spigot.jar:1.21.3-DEV-020e886]
at net.minecraft.util.FutureChain.lambda$append$1(FutureChain.java:25) ~[spigot.jar:1.21.3-DEV-020e886]
at java.base/java.util.concurre...
Thoughts on expanding the scope of this event? I like the idea of being able to provide/replace a projectile in any scenario, like the linked
EntityGetProjectileForWeaponEventfrom the patch above, and have a similarEntityLoadsProjectileEventin my fork (and its feature patch), though I also feed the default projectile into the event.
I would go with PlayerSelectProjectileForWeaponEvent or something along that way, but other than that, I also vote for calling this event generally when selecting a projectile regardless of whether you have any valid projectiles in your inventory or not...
e327618 Cursory conversion towards using SNBT for ItemS... - electronicboy
8746259 Convert to json instead - electronicboy
060b305 Merge branch 'update/1.21.5' into feat/snbt-sta... - electronicboy
d6baa74 Merge branch 'feat/snbt-stack-serialisation' of... - electronicboy
0ab4d7f Add support for reading back v2 schema type, mi... - electronicboy
Is it papers goal to maintain a persistent/reliable api for internal minecraft classes like these? My team is working on a plugin that calls the data() method on this record and it broke after this commit. The fix is trivial with the use of reflection, but it's still not great having a plugin fail after a seemingly small and trivial change.
No. Internals change whenever we see fit. There is 0 guarantee internal fields remain the same at all at any point in time.
The API for this behaviour is the plugin messaging API, which remained stable.
Internals are not API and do not have stability guarantees between versions or even builds.
Is your feature request related to a problem?
A Custom Registry API would allow plugins to share custom data through the use of Custom Registries. Developers would be able to create custom registries via a new RegistryKey.custom method, use it in a RegistryEvent through a RegistryEvents.custom(RegistryKey) method, and access it through RegistryAccess.
While niche, this could help plugins depending on eachother share data between them.
Describe the solution you'd like.
I'm not sure on what the exact semantics should be, what I have here is just a concept, but I would like to propose a new RegistryEvents.custom(RegistryKey) and RegistryKey.custom(NamespacedKey). This would allow you to modify a custom registry introduced by a plugin. If a registry of the name does not already exist, a new one should be transparently created behind the scenes. The custom registries behind the scenes could just be simple HashMap<NamespacedKey, T> where T is the value type of the...
Only certain registries are modifiable by the server in a way that the client would recognize. This list from the Minecraft Wiki shows which ones can be modified through data packs, and unfortunately the ItemType registry is not one of those. Most of those that you can edit through data packs have an API exposed through Paper already, and for those that don't, Paper offers the ability to load data packs that can (see Registries). It seems that we get more and more of these with each update, though, so maybe one day we'll get the option to truly add custom items.
When a player has an open inventoryโsuch as with a merchant or anvilโand
places items in it, or has an item on their cursor, closing the inventory typically
returns those items to the player's main inventory. However, if the player dies with
the inventory still open, the items are dropped onto the ground.
This usually isn't a problem, as their entire inventory would be dropped anyway.
But when keep inventory is enabled, these items should return directly to the player's inventory
to prevent valuable items from being accidentally droppedโespecially
in spawn areas where keep inventory is active.
I don't think this is worth a feature patch.
Can you please merge this into the per-file patches, thanks!
Generally, I like the concept tho, a config option with vanilla behaviour is also 100% something I am favour of as implemented in this PR :+1:
I do kinda get the idea of using this system to bypass for the usual circular dependency that is b depends on a, a consumes data from b.
The fact that these registries may contain non-api types is a bit worrying tho, as the server needs to purge such registry when plugin a shuts down due to any form of reason (e.g. creates registry in bootstrap, dies in onEnable, is disabled, registry needs to be purged to not keep class references to a closed classloader).
Using the actual internal vanilla registry for this is also a kinda out there impl, I don't know if that would remotely work out nicely.
It might be worth attempting this tho I kinda doubt there is much to gain here when plugin a could just expose its own form of registration. Even with this kind of registry creation b still needs to depend on a for a) loadorder and b) the actual type of the registry. Not much is gained here outside of plugin a not having to create a registration concept, which, it might be ben...
Expected behavior
entity that die next to Sculk Catalyst will not generate exp
Observed/Actual behavior
exp still generate
Steps/models to reproduce
- place Sculk Catalyst
- kill a entity
- look exp spawn
Plugin and Datapack List
None
Paper version
9b1798d6438107fdf0d5939b79a8cf71f4d16e2c
Other
Link LeavesMC/Leaves#452
The problem lies in the outdated API support
org.bukkit.event.entity.EntityDeathEvent deathEvent = this.dropAllDeathLoot(serverLevel, damageSource);
if (deathEvent == null || !deathEvent.isCancelled()) {
//if (entityliving != null) { // Paper - Fix item duplication and teleport issues; moved to be run earlier in #dropAllDeathLoot before destroying the drop items in CraftEventFactory#callEntityDeathEvent
// entityliving.awardKillScore(this, damageSource);
//}
// ...
So how about:
PlayerResolveCriticalHitEvent or PlayerResolveCriticalAttackEvent and potentially in the future PlayerResolveSweepAttackEvent
?
Actually I think this should be one event, since you never crit & sweep at the same time. Maybe just PlayerAttackEntityEvent and you can modify the "attack type"
Is your feature request related to a problem?
For example, I want attack_knockback's max value increase to 50 from 5
Describe the solution you'd like.
There's net.minecraft.world.entity.ai.attributes, and spigot had added config section like org.spigotmc.SpigotConfig.attackDamage there in
public static final Holder<Attribute> ATTACK_DAMAGE = register("attack_damage", new RangedAttribute("attribute.name.attack_damage", 2.0, 0.0, org.spigotmc.SpigotConfig.attackDamage));
We can have our max attribute config too
Describe alternatives you've considered.
No
Other
No response
So how about:
PlayerResolveCriticalHitEvent or PlayerResolveCriticalAttackEvent and potentially in the future PlayerResolveSweepAttackEvent
?
Actually I think this should be one event, since you never crit & sweep at the same time. (There are 2 different sound effects for crits & sweeps specifically) Maybe just PlayerAttackEntityEvent and you can modify the "attack type"
It would be cool, but those two mechanics are at two a bit different places so either both of the apis would be very limited or it needs to be split in two events.
Also it would be good to remove Experimental ApiStatus from CustomModelDataComponent and its derivatives as well
So how about:
PlayerResolveCriticalHitEvent or PlayerResolveCriticalAttackEvent and potentially in the future PlayerResolveSweepAttackEvent
?Actually I think this should be one event, since you never crit & sweep at the same time. (There are 2 different sound effects for crits & sweeps specifically) Maybe just PlayerAttackEntityEvent and you can modify the "attack type"
It would be cool, but those two mechanics are at two a bit different places so either both of the apis would be very limited or it needs to be split in two events.
I made this. I would say it's way better
Thank you for the report and the linked PR!
We are pretty swamped with the 1.21.5 update right now, but should get to it once that lands.
[PaperMC/Paper] Draft pull request opened: #12389 Add ability to disable Bukkit permissions handling
PR Details
Information
This PR intends to add the ability for server to disable Bukkit permissions checking for commands. With this will be able to fix some problems with permission levels checking in Bukkit.
Technical comments
The PermissibleBase#hasPermission(@NotNull String inName) is a Bukkit method that checks the permissions of a property, from the comment of @zml2008 permissions model predates the numbered op levels we can assume it should be thought as a refactor in the future. Because the Bukkit implementation does not allow levels of permissions.
Note: The modifications are made in the less affecting way possible, we know this might induce into some configurations changes to unintended behavior. With this I want to ask: I should enhance the hole system or only change the minimum to fix the issues
Why do not approach the full solution?
IMHO; this should be thought, when the project has fulfill all the major goals and all the important dis...
I mean, just disabling the perm system for a select set of commands, IMHO, is just a non starter; The actual fix here would probably be to make op levels mapped over to perm nodes in order to let perm plugins deal with this stuff more fluently/properly, I just don't know if there is much care to put up the engineering effort to implement and maintain such a mechanism which basically hasn't been used for well over a decade due to much better solutions existing
The update only includes a new configuration for MiniMessage,
specifically one to prevent it from emitting virtual components.
As virtual components break the generated component tree, items quickly
become unstackable with items generated before adventure 4.18.
Plugin developers may construct their own mini message instance which
will emit virtual components if they so choose.
[PaperMC/Paper] branch deleted: feature/adventure-4.19
I agree, @electronicboy, I think Fix for is not the right terminology; I'll edit the main PR comment. Nevertheless I think this should be integrated because various reasons
- You can give a workaround to servers admins with the corresponding warnings, in the issue mentioned and possible others in the future or that we have not located yet.
- In this case more configuration does not make too much harm, or do you think the configuration property is misleading?
- We follow the WoW <sup>1</sup> of small PRs, into making the system better little by little as needed.
But yes, I also agree that the permissions handling should be factorized and I understand there is no motivation, in the sense of putting the engineering effort to it, by the Paper's team. But if anyone wants, in the future, made the refactor by his own; having more context from other issues and PRs where maintainers can reflect there opinion, might be useful and more convenient.
FYI: This change is motivated by...
Also having a config value to disable a mechanism that is no longer consider in use, quoting @electronicboy [...] mechanism which basically hasn't been used for well over a decade due to much better solutions existing [...], seems appropriated
Expected behavior
If you reduce the damage in EntityDamageEvent, the entity should not lose his invulnerability between hits.
Observed/Actual behavior
If you reduce the damage in EntityDamageEvent, the entity does not have invulnerability between hits.
Steps/models to reproduce
@EventHandler
public void onDamage(EntityDamageEvent event) {
event.setDamage(event.getDamage() * 0.9);
}
@EventHandler()
public void onHit(EntityDamageByEntityEvent event) {
player.sendMessage(String.valueOf(event.getFinalDamage()));
}
Plugin and Datapack List
CMI, CMILib, floodgate, LuckPerms, PlugManX, ProtocolLib, TestDamage, Vault, ViaBackwards, ViaVersion
Paper version
This server is running Paper version 1.21.4-224-main@0cf7315 (2025-04-07T12:01:39Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Other
No response
No, not resolved. Still reproduced on latest paper.
Have you tried without other plugins
Stack trace
https://mclo.gs/uD0hbaI
Plugin and Datapack List
[03:50:32 INFO]: โน Server Plugins (62):
[03:50:32 INFO]: Paper Plugins (1):
[03:50:32 INFO]: - PaperTweaks
[03:50:32 INFO]: Bukkit Plugins (61):
[03:50:32 INFO]: - AdvancedBan, AntiCombatLog, AutoReplant, AxGraves, AxPlayerWarps, BigSpender, ChestShop, Chunky, Citizens, CMILib
[03:50:32 INFO]: CraftEnhance, CrazyVouchers, CrisTreeCapitator, CustomJoinMessages, DamageDisplay, DecentHolograms, DiscordSRV, dynmap, Dynmap-Towny, Essentials
[03:50:32 INFO]: EssentialsWarpGUI, floodgate, Geyser-Spigot, GeyserSkinManager, GrimAC, GSit, HarvestEXP, Hurricane, ImageFrame, ItemframeSnipper
[03:50:32 INFO]: Jobs, LuckPerms, Maintenance, motdgg, NBTAPI, PlaceholderAPI, PlayerEconomy, PlugManX, SimpleScore, SimpleTpa
[03:50:32 INFO]: SkBee, SkQuery, Skript, sleep-most, Strings, SynkLibs, SystemChat, TAB, Themis, ToolStats
[03:50:32 INFO]: Towny, TownyFlight, Vault, VeinMiner, ViaBackwards, ViaRewind, ViaVersi...
It looks better, if it works, I will only be glad. Let's wait for the team.
So how about:
PlayerResolveCriticalHitEvent or PlayerResolveCriticalAttackEvent and potentially in the future PlayerResolveSweepAttackEvent
?Actually I think this should be one event, since you never crit & sweep at the same time. (There are 2 different sound effects for crits & sweeps specifically) Maybe just PlayerAttackEntityEvent and you can modify the "attack type"
It would be cool, but those two mechanics are at two a bit different places so either both of the apis would be very limited or it needs to be split in two events.
I made this. I would say it's way better
I am not sure whether the knockback should be part of the enum. IMO you can crit & knockback and sweep & knockback... Maybe a separate boolean?
Is your feature request related to a problem?
In the โspigot.ymlโ file, the โentity-activation-rangeโ option refers to a horizontal range. Within this horizontal range, the vertical range from Y-64~Y319 is also considered part of the activation range.
Adding the "vertical-entity-activation-range" option allows for more flexible control over the size of the activation range.
Describe the solution you'd like.
Add the "vertical-entity-activation-range" option in the "paper-world-defaults.yml" file.
vertical-entity-activation-range:
animals: 64
monsters: default
raiders: default
misc: default
water: default
villagers: default
flying-monsters: default
Setting it to โ64โ means that the vertical activation range is 64, while the horizontal activation range will use the value set in the โentity-activation-rangeโ option in the โspigot.ymlโ file.
Setting it to "default" means maintaining the default behavior of th...
Discussion Category: Ideas
I am unable to reproduce this with the latest Paper + EssentialsX. Are you sure this is not caused by one of you plugins messing with auto-completion?
I am not sure whether the knockback should be part of the enum. IMO you can crit & knockback and sweep & knockback... Maybe a separate boolean?
In vanilla, a kb attack requires the player to be sprinting, and crit/sweep requires that the player is not sprinting. However, when you do a kb attack, unlike crit/sweep, the normal attack sound effect is also played so I'm not really sure what vanilla is doing here (or what it's intending to do) but it kinda suggests the possibility. Also kb attacks don't involve extra particles or anything so it wouldn't be hard to implement.
(I'm busy these days. Maybe this weekend)
Have you tried without other plugins
yep
Sadly a duplicate of #11393 with still kind of not a good solution.
Expected behavior
Player falling from high place should play "fall" sound
Observed/Actual behavior
Player falling from high place doesn't play "fall" sound
Other types of entites play "fall" sound correctly
Steps/models to reproduce
- Jump from a high place
Plugin and Datapack List
pl
[18:08:18 INFO]: โน Server Plugins (0):
datapack list
[18:08:32 INFO]: There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
[18:08:32 INFO]: There are no more data packs available
Paper version
version
[18:08:42 INFO]: Checking version, please wait...
[18:08:43 INFO]: This server is running Paper version 1.21.4-224-main@0cf7315 (2025-04-07T12:01:39Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-222-9b1798d (MC: 1.21.4)
Other
No response
Stack trace
Client crash log: https://mclo.gs/ISyq09d
Plugin and Datapack List
Server startup log: https://mclo.gs/tFtTBJK
No plugins/datapacks
Actions to reproduce (if known)
Fly around with anti x-ray enabled, experience client crashing
<details>
<summary>Anti x-ray config used when the crash happened</summary>
anticheat:
anti-xray:
enabled: true
engine-mode: 1
hidden-blocks:
- coal_ore
- deepslate_coal_ore
- copper_ore
- deepslate_copper_ore
- raw_copper_block
- diamond_ore
- deepslate_diamond_ore
- emerald_ore
- deepslate_emerald_ore
- gold_ore
- deepslate_gold_ore
- iron_ore
- deepslate_iron_ore
- raw_iron_block
- lapis_ore
- deepslate_lapis_ore
- redstone_ore
- deepslate_redstone_ore
lava-obscures: true
max-block-height: 64
replacement-blocks:
- stone
- oak_planks
- deepslate
update-radius: 2
use-permission: false
</details...
This is a vanilla issue, iirc?
I did a search and it was a vanilla bug. I guess I'll just have to wait for vanilla to fix it.
I mean, there is nothing wrong with fixing it in Paper. Doesn't seem like it'd be something disruptive if it got fixed
I mean, there is nothing wrong with fixing it in Paper. Doesn't seem like it'd be something disruptive if it got fixed
okay
Expected behavior
Cow is spawned by calling any of the spawn overloads including those requiring class reference instead of EntityType (in this case Cow.class).
Observed/Actual behavior
Since the Commodore changes for 1.21.5 introduced in cb0676a4028d56003feb71aff18cedf9254ba95d, all references to the class Cow are replaced by AbstractCow in pre-1.21.5 plugins, making it impossible for old plugins to spawn a cow, unless they use EntityType or get the entity class dynamically.
[19:56:39 ERROR]: Error occurred while enabling ExamplePlugin v1.0.0 (Is it up to date?)
java.lang.IllegalArgumentException: Cannot spawn an entity for org.bukkit.entity.AbstractCow
at org.bukkit.craftbukkit.CraftRegionAccessor.createEntity(CraftRegionAccessor.java:495) ~[paper-1.21.5.jar:1.21.5-DEV-cb0676a]
at org.bukkit.craftbukkit.CraftRegionAccessor.spawn(CraftRegionAccessor.java:416) ~[paper-1.21.5.jar:1.21.5-DEV-cb0676a]
at org.bukkit.craftbukkit.CraftRegionAccessor.spawn(Cr...
This PR aims to add an option to place structures without doing block updates.
This was something Minecraft added in 1.21.5 to Structure Blocks as well as the /place template command.
While I understand the team is not wanting PRs for 1.21.5 yet, I just wanted to get this done as early as possible.
I'm ok with the PR sitting here til the team accepts 1.21.5 PRs.
This feature has been requested by users of my plugin for over a year now, so Im super excited to have this.
I did test with my plugin locally and it works like a charm :)
Side note:
I did a test on 1.21.4 for this, it technically works as well, but only like 50/50.
For example:
- Fences didn't connect as expected (yay)
- Water still flowed (boo)
- I didn't test other blocks but it felt a bit unstable, so I didn't want to do the PR for 1.21.4 due to instability.
Closes #12381
Is it worth having some sort of PlacementOptions object instead of having multiple different methods with ~10 arguments each?
Who doesn't love 10 arguments ๐ฌ ... jk, but yeah that might be a better idea.
Update:
Ok, I made a placement class.
I haven't filled in the Javadocs yet. I wanted to get opinions on how I made everything before I filled in javadocs.
(ie: just want to make sure the structure is what Paper would expect)
Expected behavior
https://github.com/user-attachments/assets/db622436-3ca4-427a-8b77-cde39dbc77bb
same as vanilla
Observed/Actual behavior
https://github.com/user-attachments/assets/c74ff915-d4a0-4f3d-a6e6-bbfffb301bcf
Steps/models to reproduce
See Observed/Actual behavior
Plugin and Datapack List
pl
[05:12:04 INFO]: โน Server Plugins (0):
datapack list
[05:12:11 INFO]: There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
[05:12:11 INFO]: There are no more data packs available
Paper version
ver
[05:12:02 INFO]: Checking version, please wait...
[05:12:02 INFO]: This server is running Paper version 1.21.4-224-main@0cf7315 (2025-04-07T12:01:39Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Other
No response
Previously the server attempted to compute the block placed by using the
BlockPlaceContext. This approach however fails on replacable blocks, as
the BlockPlaceContext computes this during its construction, which
happened after the actual world modification.
The commit reworks this approach and now stores metadata in the
InteractionResult which can later be read.
The diff is structured to allow for easy future expansion of the tracked
metadata.
Resolves: #12399
Expected behavior
I've found a issue with PlayerChunkLoadEvent, if i join the server, the nearby 4 chunks of the player doesnt go through the event for some reason. I want to spawn entities with packets when a player approaches x chunk and remove it when they move away
This is the expected:
https://cdn.discordapp.com/attachments/555462289851940864/1359566103793369258/56e53accb20696f802d92bd011174126b5e3154e_2025.04.09_-_11.29.03.04.mp4?ex=67f7f21a&is=67f6a09a&hm=11964fe06dee25d4e0ae1a02e88303a5040ca60aeccb0435fc530b0cf6d3ea0b&
(Actually works if i go far away and i come back but no when i join the server) Wheni join the server, it should send me those chunks so I can spawn it. I already fixed it using playerjoinevent, but it's still unexpected behavior.
Observed/Actual behavior
can we also move the transformers onto the PlacementOptions? Or we could do this similarly to PositionedRayTraceConfigurationBuilder
At first I didn't think that would make sense, but yeah... it does make sense.
I have moved them ๐๐ป
Is your feature request related to a problem?
It is related to a problem specific to me, but it might help some others out also. For context, I have a custom "coins" item on my server. In its PDC, it has a value that represents how many coins (my server's currency) the item is worth. If two coins in entity form are near each other I want them to merge and have their values in their PDCs to be added together, in a similar way to how identical items merge in vanilla.
Describe the solution you'd like.
I think in order to achieve what I want (described in the previous field), I would need an ItemAttemptMergeEvent or similar that gets fired whenever the game checks to see if two item entities within range should merge, at which point I could write my own logic for the adding of the PDCs and the despawning of one of the items.
Describe alternatives you've considered.
Writing my own logic for constantly checking if item entities next to each other are coins maybe? This s...
cdad49b Do not mark plugin tickets as forced; keep corr... - Spottedleaf
a1c4fc9 Add generic ticket identifier - Spottedleaf
745881b Update Moonrise common for 1.21.5 - Spottedleaf
e9d00eb Apply Moonrise patch - Spottedleaf
ef0f0d1 Copy Moonrise 1.21.5 update over - Spottedleaf
cc0f25c Apply more feature patches - kennytv
e7b684e fix - kennytv
[71ccae0](https://github.com/PaperMC/Paper/comm...
Hi @notTamion, thank you for the detailed reply and for taking the time to test the code.
Iโve carefully followed the exact steps you outlined to reproduce the potential deadlock:
Cancelled the PigZombieAngerEvent via a test plugin
Spawned two Zombified Piglins next to each other
Hit one of them in survival mode
Everything ran smoothlyโno deadlocks, no StackOverflowError, and the server remained stable throughout. The reset behavior worked as expected.
If it helps, Iโd be happy to record and share a video showing the test from start to finish, including the plugin setup and console output, to confirm that the issue doesn't occur on my end.
Let me know if you'd like me to go ahead with that.
Also, it would be my pleasure to share the plugin I used to cancel the PigZombieAngerEvent, in case it helps with reproducing or debugging the issue on your end. Just let me know!
Expected behavior
Durability bar goes down naturally for tools and items when being used.
Observed/Actual behavior
Durability bar is not going down but durability is still dropping. I've found on newer versions of paper 1.21.4 this is happening to me on my server end, durability on items just doesn't update until the item breaks or you drop it and pick it back up or if you use a firework with an elytra that also updates the item for some reason.
Downgrading to a older paper 1.21.4 fixes the issue, not sure how far down we have to go but i just picked a random older version.
Steps/models to reproduce
Download newest paper.jar and use tools.
Plugin and Datapack List
I want to add that I removed all these and still had this problem however it's possible there was left over data from them somewhere in the server.
Plugins
Chunky - Precompiles chunks for a smoother server.
CoreProtect - Logs everything in the server, this includes opening chests, placing/removing...
Viaversion and or viabackwards was the issue, removing jar + folders from those plugins solved it.
Expected behavior
1.21.4.153 behavior
Observed/Actual behavior
somehow the dmg way higher than it should be. it looks like it applies multiple times.
i tested, picked a wolf by code, set the dmg to 0. Bukkit.getServer().getPluginManager().callEvent(EntityDamageByEntityEvent), then it kills a 7.6*10^10 hp dragon under 2 sec(should last 500 + sec). tested on more mobs. all the same. i event tryed to cancel EntityDamageByEntityEvent and somehow mobs still die. fun fackt, .sethealth() is the same. i tried with a repeated timed bukkit task to sethealth() on a clean mob. same result.
Steps/models to reproduce
i do not understand the problem well enough... look the "actual behavior" part
Plugin and Datapack List
plugin: my own writen.
datapack: vanilla, file/bukkit, paper. these 3 are the default.
Paper version
1.21.4.224-0cf7315
Other
No response
EntityDamageByEntityEvent damage = new EntityDamageByEntityEvent(wolf, target, EntityDamageEvent.DamageCause.CUSTOM, playerC.dmgNums.petDmg);
Bukkit.getServer().getPluginManager().callEvent(damage);
this code was an alibi code, it did not applied dmg and it not worked properly but i could send at least send some data to the event
because all entity.damage() method cant damage every mobs (dunno why), but sethealth() yes. i forced sethealth in that event only when damagecause was EntityDamageEvent.DamageCause.CUSTOM
this code works in 1.20.1-1.21.4.153 versions well, but above 154 not
callEvent doesn't do any modification of damage, etc, this is all generally going to be down to whatever plugins are doing with the event itself in terms of mutating player state
so the question, why does dmg? i tried to call it with an event.setcancel(true) inside every EntityDamageByEntityEvent event to be sure it turned off completly but still does dmg. if i dont do the call, no extra dmg
Because you have some plugin listening to the event doing some damage to the player, we can't really see what that is
ok so, any chance of reverting the difference between 1.21.4.153 -- 1.21.3.154?
the only new in 154 is
Cleanup damage source a bit (#12106)
the problem exist in all 154+ but in 153 and below no problem.
No, we're not going to revert a commit fixing a set of issues because of 1 issue without any reproduction information, we would need to see what is doing damage stuff in your server in response to that to determine what we want to do
If this were to be implemented, it should be optional, or it would probably break plugins.
I, for example, use this feature to make the world border disappear for players when they are not near it and expect it the virtual border only be visual. I want the global world border to be the only border to actually do something (so the opposite of your use case)
i mean optional are not necesary if when create the virtual world border the damage is 0
ok, i found the problem. EntityDamageEvent >> inside this event i had an if statement
if(event.getDamageSource().getDirectEntity() == null)
i used it to check if its entity, or environment dmg. the dmgsource changed in newer versions, so this is where and what happened. anyway, thx for help, this helped me to fix my code. ticket is closeable
have a nice day!
correction: it doesn't completely deadlock the server as it will exit the loop after some time due to the stated StackOverflowError. however it still hangs the server for a few seconds
https://github.com/user-attachments/assets/ae582df3-16c5-4aae-9b30-a4b09a6d86fa
Expected behavior
just exploding and pushing entities away
Observed/Actual behavior
wind charge upon impact after throwing destroys terrain.
Steps/models to reproduce
get a wind charge and throw it at the ground
Plugin and Datapack List
- WebhookLogger-Paper-4.0.1.jar
- veinminer-paper-2.4.2.jar
- veinminer-enchant-2.2.2.jar
- TreeFeller-1.25.1.jar
- Terra-bukkit-6.6.1-BETA+83bc2c902-shaded.jar
- TeaksTweaks-v2.0.7-mc1.21.4.jar
- tabtps-spigot-1.3.26.jar
- RoseStacker-1.5.32.jar
- ProtocolLib.jar
- knockbacksync-bukkit-1.3.6-dev-b106.jar
- FreedomChat-Paper-1.7.2.jar
- creeper-recover-1.1.0-spigot.jar
- BoundlessForging-1.0-SNAPSHOT.jar
Paper version
This server is running Paper version 1.21.4-224-main@0cf7315 (2025-04-07T12:01:39Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-222-9b1798d (MC: 1.21.4)
Other
i genuinely dont know which plugin does it, ive checked config files of almost e...
unable to reproduce. can you try without plugins and default configs?
default without plugins and default configs seems fine, i cant ask myself to do the binary search so if thats the case then this issue is probably closed right?
For reference; https://docs.papermc.io/paper/basic-troubleshooting#binary-search
But, yes; This issue tracker is for software bugs, for support, please use the discord/forums
Is your feature request related to a problem?
Yes, as it currently stands Bukkit MemoryKey only provides a small handful of the current memory keys available from Minecraft.
It appears the Registry.MEMORY_MODULE_TYPE is hard coded to return MemoryKey.values() rather than actually grabbing from the Minecraft registry.
Describe the solution you'd like.
I would like to see the MemoryKey and registry re-written to actually return things from Minecraft rather than a small percentage of hard coded values.
Describe alternatives you've considered.
Other than grabbing from an NMS registry, nothing I can think of.
Other
No response
This PR aims to fix the Block#applyBoneMeal method always returning false.
I'm assuming the NMS method used here was probably changed at one point from CONSUME to SUCCESS
For context:
<img width="682" alt="Screenshot 2025-04-11 at 2 20 11โฏPM" src="https://github.com/user-attachments/assets/4f28c379-67d8-43df-b9fc-963897a81133" />
24w33a is the first snapshot for Java Edition 1.21.2 is probably when this got borked
24w33a is the first snapshot for Java Edition 1.21.2is probably when this got borked
Duly noted. Not too long so thats good!
0767902 CraftBlock - fix applyBoneMeal false result (#1... - ShaneBeee
While I am a fan of small PRs, introducing a config option to bypass a system that (presumably) is properly fixed later just for the config option to die then is not really something I am interested in.
This issue is not problematic enough to require a "hotfix" config option like this when simply using permissions plugins over operator levels has been common practice in the community for a near decade.
As cat stated, the "proper" solution for this would be a lot more work that we may or may not even be interested in maintaining (tho we do maintain CommandPermissions already so, it might be fine?) In general, fine grained permissions are a objectively better approach than vanillas operator system so I am not sure if a proper solution is worth maintaining.
I appreciate your work on this but I do not believe this approach is something I am willing to merge.
If you want to look into a proper mapping of permission levels to command permissions, feel free, tho that would b...
While I approve of the general concept of this, I'm not entirely fond about having highly specific stuff exposed if the context starts relating into stuff like security aspects, etc; i.e. what happens if we add a brand new forwarding mechanism that has its own option, does that get merged into the existing one or do we have an entire open hole? Do we really need this level of accessibility?
Some comments regarding the comments.
I feel like it would be worth to add a note that these also check if the proxy mode is enabled to begin with, given both return only true if their proxy mode is enabled and in online mode.
I feel like "selected critical settings." still makes it rather vague. Like why exactly are those critical? Are they critical for the server? The plugin dev? Both?
Maybe mentioning why they are considered critical would be beneficial here.
The paragraph and return statement contradict each other.
Like which is it? Is it returning true if server is in online mode or behind a online mode proxy, OR is it only returning true if behind a online mode proxy?
Hi @notTamion,
Thanks for the clarification. Iโll be taking another look at the code sometime soon. Appreciate you pointing it out.
can confirm this, is always false
Is your feature request related to a problem?
This issue contains both:
- a bug report (and a request for completing documentation about how to set the log level for plugin developers and server administrators)
- a feature request.
Feature request
Java.util.Logger logger = myPluginInstance.getLogger(); is a pain for plugin developers (or is it just me).
It does not support the basic logging features we find in every modern logging framework:
- simple parametrization using {} instead of %s
- setting log level statically from env/startup parameters/config files/... .
- setting log level dynamically from code (during execution): plugin.getLogger().setLevel() does not work (at least in 1.20.4 latest build). See bug report bellow.
- setting log level per plugin
- setting log level per package/class
- completing prefix with the class that produced a given log
- Mapped diagnostic context
- ... (see SLF4J/Logback/log4j2 documentation for a more complete feature l...
[PaperMC/Paper] Issue opened: #12409 Block.setType(Material.END_CRYSTAL) throws NullPointerException
Expected behavior
block.setType(Material.END_CRYSTAL)
works
Observed/Actual behavior
code throws an exception:
[14:47:44 ERROR]: Could not pass event EntityDamageByEntityEvent to RailNet v0.1.2
java.lang.NullPointerException: null
at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1693) ~[?:?]
at org.bukkit.craftbukkit.block.data.CraftBlockData.newData(CraftBlockData.java:576) ~[paper-1.21.3.jar:1.21.3-83-d6c81da]
at org.bukkit.craftbukkit.CraftServer.createBlockData(CraftServer.java:2842) ~[paper-1.21.3.jar:1.21.3-83-d6c81da]
at org.bukkit.craftbukkit.CraftServer.createBlockData(CraftServer.java:2817) ~[paper-1.21.3.jar:1.21.3-83-d6c81da]
at org.bukkit.Bukkit.createBlockData(Bukkit.java:2463) ~[paper-api-1.21.3-R0.1-SNAPSHOT.jar:?]
at org.bukkit.Material.createBlockData(Material.java:4984) ~[paper-api-1.21.3-R0.1-SNAPSHOT.jar:?]
at org.bukkit.craftbukkit.block.CraftBlock.setType(CraftBlock.java:182) ~[paper-1.21.3.ja...
End Crystals are entities, not blocks
The only thing we could do here is improve the error message but yea, Material#END_CRYSTAL refers to the item, it is not backed by a block.
I also tested plugin.getSLF4JLogger(). Same result: No way to set log level.
It seems people who tried to customize the log level like me wrote their own custom logger.
Their custom logger sometimes retrieve a log level (for the whole plugin or per package) from the plugin config or from another yml log configuration file.
Then, their custom logger will remap every log to INFO+ level (to be able to ignore spigot log level).
This is awful.
A primary issue is that mojangs default logging setup works by setting filters up on the appenders rather than setting up their config in a way that more accurately prevents fine logging from their own loggers internally, somebody would basically need to figure out a sane way to address this so that we could remove the filter applied to that, however, that would also impact other things that people pull in, so, I'm not 100% sure what the best mechanism here is
The only thing we could do here is improve the error message but yea, Material#END_CRYSTAL refers to the item, it is not backed by a block.
just for reference... NPE is only in that version since https://github.com/PaperMC/Paper/commit/0a04c3fe228cdb2ab6c4cac2586cb798fe218eff throws a better message for non-block Material
d55e548 use schema version in api - MiniDigger
298c733 snbt item stack serialisation (#12363) - electronicboy
[PaperMC/Paper] branch deleted: feat/snbt-stack-serialisation
6ed47cf Properly handle item flags with tooltip display - lynxplay
[PaperMC/Paper] New tag created: 1.21.4
[PaperMC/Paper] tag deleted: 1.21.4
[PaperMC/Paper] New tag created: 1.21.4
[PaperMC/Paper] tag deleted: 1.21.4
[PaperMC/Paper] New tag created: 1.21.4
ok shut up I got it
Found a way to set the log level that is working (but this is really a mess):
Reproduce
- Find the default log4j2.xml config file (for 1.20.4 in my case) here.
=> I could not find it in my paper.jar. Where can it be found easily (to avoid having to find the good commit in paper git repository) ?
-
Copy this file to my server folder.
-
Make paper use this custom log4j config by adding a parameter in the run command -Dlog4j.configurationFile=log4j2.xml
-
Update the run config AppenderRefs to allow traces to be logged (instead of only info):
<Async name="Async">
<AppenderRef ref="File" level="trace"/>
<AppenderRef ref="TerminalConsole" level="trace"/>
<AppenderRef ref="ServerGuiConsole" level="trace"/>
</Async>
- Add <Loggers> related to my plugin
<Loggers>
<Root level="...
c5b0a6a store the full tooltip display in CraftMetaItem - MiniDigger
Use cases related to this feature request
Context:
- (Using AOP or directly in my methods) I log (at trace/debug level) a lot of things (for example the calls to my controllers methods with theirs parameters, the state of some complex objects, etc). I usually don't want to see those logs during a normal execution.
Case 1:
- A server owner report a bug without enough information to reproduce. This bug is not an exception but so I don't have a stack trace.
- I ask the server owner to activate trace logs for my whole plugin (using a simple process like modifying a config file. The process described in the previous comment is too complex for a non developer).
- He activates it, reproduce the bug and send me the logs.
- I can then see what he did, reproduce and fix/help the server owner.
Case 2:
- As a developer, I quickly activate trace logs on a specific package of my plugin. This allows quicker diagnose without having the noises of every packages log traces. Thi...
I understand why it is not a priority and why this logging system is a mess inherited from mojang.
I think there are some quick actions that could help without having to refactor the whole logging system:
- Documentation: how to set log level for a plugin (almost a copy paste from my issue comment)
- Documentation: remove the wrong -Dpaper.log-level= parameter explanation at the start of System properties section.
- Code: Reroute the plugin.getLogger() to "PluginName" instead of log4j root "" logger to avoid confusing developers with different behaviors between provided loggers.
I ain't reading all that. I'm happy for u tho. Or sorry that happened.
[PaperMC/Paper] branch deleted: update/1.21.5
Oop, please reopen a PR targeting main again
Oop, please reopen a PR targeting main again
Previously the server attempted to compute the block placed by using the
BlockPlaceContext. This approach however fails on replacable blocks, as
the BlockPlaceContext computes this during its construction, which
happened after the actual world modification.
The commit reworks this approach and now stores metadata in the
InteractionResult which can later be read.
The diff is structured to allow for easy future expansion of the tracked
metadata.
Resolves: #12399
Redo of https://github.com/PaperMC/Paper/pull/12398
This PR originally aimed to add an option to place structures without doing block updates.
This was something Minecraft added in 1.21.5 to Structure Blocks as well as the /place template command.
After a great suggestion from Kashike, this PR changed to add a new PlacementOptions class.
This will allow for deciding which options you want to add, or fallback to defaults.
This will also be great in the future if Mojang adds more options for placement, won't need to create more methods in the structure class.
While I understand the team is not wanting PRs for 1.21.5 yet, I just wanted to get this done as early as possible.
I'm ok with the PR sitting here til the team accepts 1.21.5 PRs.
This feature (the earlier mentioned strict option) has been requested by users of my plugin for over a year now, so Im super excited to have this.
I did test with my plugin locally and it works like a charm :)
Side note (re: Stri...
Expected behavior
No exception and a horse to equip the saddle
Observed/Actual behavior
Throws exception
[12:11:24 ERROR]: #!#! Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
[12:11:24 ERROR]: #!#! at java.base/java.util.Arrays$ArrayList.set(Arrays.java:4271)
[12:11:24 ERROR]: #!#! at net.minecraft.core.NonNullList.set(NonNullList.java:50)
[12:11:24 ERROR]: #!#! at net.minecraft.world.SimpleContainer.setItem(SimpleContainer.java:213)
[12:11:24 ERROR]: #!#! at org.bukkit.craftbukkit.inventory.CraftInventoryAbstractHorse.setItem(CraftInventoryAbstractHorse.java:108)
[12:11:24 ERROR]: #!#! at org.bukkit.craftbukkit.inventory.CraftInventoryAbstractHorse.setSaddle(CraftInventoryAbstractHorse.java:25)
Steps/models to reproduce
((AbstractHorse) entity).setSaddle(new ItemStack(Material.SADDLE))
Plugin and Datapack List
Skript
Paper version
1.21.5
Other
No response
Note: The exception seems to be thrown when setting the saddle directly after the horse is spawned.
The same goes for setArmor however instead of throwing an exception, just seems to not get equipped.
If this new behavior is intended, then it's fine.
looks like an issue with the container... currently the API try to use BODDY and not SADDLE but not totally sure.
Rebased to 1.21.5 ๐ฅณ
Stack trace
[paste your stack trace or a mclo.gs link here!](https://mclo.gs/rOEwk2K)
Plugin and Datapack List
In crash report. Creative plugins.
Actions to reproduce (if known)
No response
Paper version
This server is running Paper version 1.21.4-222-main@9b1798d (2025-03-27T13:35:40Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are 3 version(s) behind
Download the new version at: https://papermc.io/downloads/paper
Other
No response
pallette is presized for the contents, this generally always means that you have a plugin screwing with the world async
f517267 Add passthrough for air serialization - electronicboy
Ports the follow commits from spigot to paper.
All credits to go the respective commit authors listed below.
Bukkit: 47480cd07c0957a94b220f3087b851594b063e54
CraftBukkit: c6c8165aa0d5679b9b015b209c1645a222f8c3a6
CraftBukkit: d275d3b96e041f6421f3bb7de1e6022ea8be5456
By: md_5 git@md-5.net
By: Doc nachito94@msn.com
I think it would be better if we moved the removal of the items past the dropAllDeathLoot call so we don't remove those items at all before we know the event was cancelled. this way. this would also restore parity with other entities which also have the event called with their equipment/items still on
that not require a littlle more refactor for another behaviours rather than just the armorstand?
This PR take the base of https://github.com/PaperMC/Paper/pull/11925 for expose the data in MusicInstrument for keep the old PR just for create new ones when support exists.
Thanks @Doc94 to still looking into this, still waiting for it to get into Paper so I can finally get those custom goat horn working like I want them ๐คฃ
Expected behavior
When scaling a player (e.g., via a mod or plugin like SnC that modifies entity/player scale), combat interactions such as hitting or being hit should still function normally. Specifically, entity detection for attacks should align with the visible hitbox and properly register hits regardless of the entity's Y position or scale.
Observed/Actual behavior
When a player is scaled up using the "scale" attribute, combat detection becomes inconsistent. Hits often fail to register unless the player aims near the "feet" of the scaled entity. This issue does not occur on Fabric/Forge with the same setup โ only on Spigot/Paper. It severely affects gameplay in scenarios involving large-scale entities (e.g., Titan shifters).
A side-by-side comparison video demonstrating the issue is available here
https://drive.google.com/file/d/1FGwJ0MITYNYZxQhFPLVzXYfP5tO1lWSb/view?usp=sharing
Steps/models to reproduce
I'm attaching a datapack where I trimmed the functions I...
Spark Profile
Description of issue
Why can't I log into Discord? I went in and it said I was banned.
Plugin and Datapack List
Server config files
Paste configs or mclo.gs link here!
Paper version
Other
I wanted to ask a core question, only to find out that I was banned
If you were banned from our Discord, you can use our unban request server to request an unban: https://discord.gg/cTKAXWy5eP
If you were banned from our Discord, you can use our unban request server to request an unban: https://discord.gg/cTKAXWy5eP
Why was I banned? I remember I didn't say much.
Ban appeals are handled on our appeal discord.
Ban appeals are handled on our appeal discord.
It was fixed. It turned out that someone had sent me a link with a problem on Steam without my knowledge.
I have tested and confirmed that the above video still holds for latest download (#225 for mc 1.21.4)
Expected behavior
This should be the view that players see.
Fullscreen: on
Observed/Actual behavior
However, when the game is not in full screen mode, the e (inventory) popup will overlap (shown in image below).
Fullscreen: off
Steps/models to reproduce
Turn off fullscreen
Plugin and Datapack List
Default PaperMC installation
Paper version
1.21.5 snapshot v4
Other
No response
That is 100% client side, and nothing to do with the server.
Replaces the example code in https://jd.papermc.io/paper/1.21.5/org/bukkit/event/entity/PlayerDeathEvent.html#getItemsToKeep() with a more up to date versions that doesn't depend on magic values in lore for important checks and doesn't promote legacy color codes over adventure components.
Introduced a new property to check if the respawn block is missing.
The ctors are internal so we can change them :sweat_smile:
No point in overloading more.
4511edb [ci skip] Don't promote checking enchantment by... - masmc05
I would like to add a setter for this as well but i am not sure what to do about PlayerList#respawn L929
That line clears the respawn location if the respawn block is missing fix for SPIGOT-5988 and calling the PlayerSetSpawnEvent
The ctors are internal so we can change them ๐ No point in overloading more.
Alright, did that just because the other constructors are internal as well but marked as removal since idk how long.
also is there a chance this could be backported to 1.21.4?
- Updated SignChangeEvent class
- Fix NPE on
getLine()/getLines()/ legacy String[] constructor - Updated the annotations to JSpecify, removed Paper comments and fully qualified imports as it's quite a small class & change
getLine()/line()/ constructor correctly show nullability again- Change lines handling to not allow external modifications (otherwise iffy things are possible like passing an immutable list, changing the amount of elements) and mandate 4 elements. Adds a method to set all the lines at once as an alternative.
- That's changing behavior, but I wasn't expecting the list mutability in the first place (it's not mentioned in javadoc, and differs from other similar places within API), and it's not a major break. The legacy getter didn't allow mutability already.
- Fix NPE on
- Javadoc corrections
Tool.Rule#speed()had a description forTool.Rule#correctForDrops()AbstractArrow#setItemnow points to#setItemStackinstead of#getItemStack
-...
Entity#getAsString allows dumping entity's snbt and can be used to create entity snapshots.
However, the method currently fails if used on unsaveable entity, e.g., non-persistent (entity.setPersistent(false)) ones.
While this API is not exactly supported, I don't see a reason to keep the restriction either.
I'd just call it getSound instead of SoundEvent
Yeah, you can make a follow-up PR after this is merged, or we'll backport it later
I clarified the docs for the isMissingRespawnBlock method lmk if it is fine like that
Hmm just the method not?
I set this name for avoid confusing for what this get and make consist with the create instrument PR.
Enhanced event to include associated block, entity, and data flag.
Expected behavior
The following code should spawn beehives with bees in them during block population
@Override
public void populate(WorldInfo worldInfo, Random random, int chunkX, int chunkZ, LimitedRegion lr) {
int targetX = chunkX*16 - 8;
int targetZ = chunkZ*16 - 8;
assert lr.isInRegion(targetX, 51, targetZ);
lr.setType(targetX,51,targetZ,Material.BEE_NEST);
Beehive bukkitBeehive = (Beehive) lr.getBlockState(targetX, 51, targetZ);
Bee bee = (Bee) lr.createEntity(new Location(bukkitBeehive.getWorld(),targetX, 55, targetZ), Bee.class);
bukkitBeehive.addEntity(bee);
}
Observed/Actual behavior
The code with a block populator will cause an IllegalStateException as Beehive.addEntity tries to call EntityRemoveEvent
Caused by: java.lang.IllegalStateException: EntityRemoveEvent may only be triggered synchronously.
at io.papermc.paper.plugin.manager.PaperEventManager.callEvent(PaperEventManager.java:42) ~[paper-1.21.5.jar:1.21.5-5-8f62e0...
Adds getters/setters in some classes, making BlockType and ItemType API even more useable without converting from/to material.
Hi, thank you for the PR and welcome to paper :partying_face: !
I am semi certain we are not planning on doing it this way as Item/BlockType will simply replace the existing Material parameters and return types when we retire Material.
I'll check in with the team on that tho.
I believe that this kinda thing was intended as a core team sorta task given that we also just wanted to start purging material at the same time and have bytecode translations for it
Expected behavior
When I click on ocelot with a fish to tame it, it should become a tamed cat with me as it's owner.
Observed/Actual behavior
I am unable to tame ocelot using fish. It spawns hearts like it "is" tamed but nothing happens. For example taming wolf works.
Steps/models to reproduce
- spawn / find ocelot
- have enough fish items in inventory
- sneak and wait for ocelot to close by itself
- feed fish to ocelot
- right click with fish on ocelot until you see heart particle effects
Plugin and Datapack List
No custom datapacks just: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
Plugins: CMI, CMIEInjector, CMILib, dynmap, FastAsyncWorldEdit, ItemsAdder, LuckPerms, Multiverse-Core, PAPIProxyBridge, PlaceholderAPI, ProtocolLib, Vault, VoidGen
Paper version
This server is running Paper version 1.21.4-225-main@0767902 (2025-04-11T21:49:39Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous ve...
When I click on ocelot with a fish to tame it, it should become a tamed cat with me as it's owner
I don't think this is how ocelots work?
Taming ocelots was removed in Java Edition 1.14
Oh, that was changed ages ago :D How did I miss that one? Thank you.
I did a search and it was a vanilla bug. I guess I'll just have to wait for vanilla to fix it.
that bug has a MOJIRA ticket for that?
Okay exists and in teory was resolved in 1.21.5
https://bugs.mojang.com/browse/MC/issues/MC-278552
MM did a pull request on this way back which was never merged (https://github.com/PaperMC/Paper/pull/9468). That PR used empty components instead of explicit nulls in the lists - would it be easier to work with the lines if those were used instead?
MM did a pull request on this way back which was never merged (#9468). That PR used empty components and a non-null transforming list instead of explicit nulls in the lists - would it be easier to work with the lines if those were used instead?
Oh, haven't seen that PR, thanks for the info! Missed (de)serializeOrNull being a thing, updated.
I do agree that getting rid of nulls would be better, but this will break backwards compatibility, and sadly the event existed in this state for years now.
-
By changing nulls, suddenly old "empty/untouched line" checks based on null will no longer pass.
-
Similarly, changing lines getter to immutable will break plugins relying on its mutability.
- There could be an API break for this one, since the mutability was never an API contract and likely wasn't intended, but suddenly breaking it isn't perfect either imo.
So I was playing around with game rules a bit and after running into an issue that GameRule#values() does contain even game rules that are disabled because the experimental data pack isn't enabled, I was wondering if there was a way to check if a game rule is enabled or not.
What I've found is that World#getGameRules() should contain only enabled game rules, however that wasn't applicable for my usecase since I didn't have a world available.
This PR adds an isEnabled() method to the GameRule class to make it possible to check if the game rule is enabled without needing access to a world.
We already have a system for that around FeatureDependant and FeatureFlagSetHolder.
GameRule should implement FeatureDependant
That doesn't seem to be the case.
Yea it doesn't rn xD SOrry I wasnt clear, the PR should do that instead of adding a new system.
Okay, I'll do that then ๐
Okay, yea that is indeed the plan.
Thank you for the PR but we have different plans for the integration of those type :)
Is your feature request related to a problem?
Not really. Just a nice addition which does not take much time ... so I think.
Describe the solution you'd like.
I think it would be a great addition to be able to change the server brand name displayed when pressing F3. It would be perfect in the paper-global.yml.
Describe alternatives you've considered.
There are workarounds via plugins, but like with Xray you could also integrate this directly into the paper config to save time, load fewer plugins, etc.
Other
Issue comes up every now and then, there are plugins that can change this but we generally like the one bit of attribution our work gets in the wild to not be changed :)
While I approve of the general concept of this, I'm not entirely fond about having highly specific stuff exposed if the context starts relating into stuff like security aspects, etc; i.e. what happens if we add a brand new forwarding mechanism that has its own option, does that get merged into the existing one or do we have an entire open hole? Do we really need this level of accessibility?
As written in the ServerConfiguration docs, it only aims to provide the most important settings
In my opinion there is nothing else that is really important to be exposed here as well
but I think this is better discussed internally
"This interface doesn't aim to cover every possible server configuration option but focuses on selected critical settings."
these settings are important why? What is the merit of exposing them individually rather than exposing the underlying concepts behind them?
I don't think I can follow. What do you mean by "the underlying concepts"?
The problem is that it isn't possible to check whether the server is configured for online mode and changing the Server#getOnlineMode impl seems iffy
So exposing them here/at all is kinda critical
Yes, so, isProxyOnline mode makes sense, individual bungee/velocity forwarding mode ones, I'm not sure about
You are right, thinking about it, I don't see a real upside in exposing them.
I think I am going to remove them
Generally LGTM!
I do wonder however if it would be smart to patch the GameRules internals to also maintain a Map<String, GameRule.Type<?>> for faster access.
The fact that this method is going to be pretty spam-heavy for checks would mean such optimisations would have a hopefully measurable effect.
Since the method is already here, maybe it would be better to just not include the optional Override annotation to reduce diff?
Yea, probably a good call.
Expected behavior
public abstract class LivingEntity extends Entity implements Attackable {
public boolean canUseSlot(EquipmentSlot slot) {
return false;
}
}
public abstract class Player extends LivingEntity {
@Override
public boolean canUseSlot(EquipmentSlot slot) {
return slot != EquipmentSlot.BODY;
}
}
Observed/Actual behavior
public abstract class LivingEntity extends Entity implements Attackable {
public boolean canUseSlot(EquipmentSlot slot) {
return true; // <- WTF
}
}
public abstract class Player extends LivingEntity {
// missing: boolean canUseSlot(EquipmentSlot slot) { slot != EquipmentSlot.BODY; }
}
Steps/models to reproduce
@EventHandler
public void on(@NotNull PlayerJoinEvent event) {
Player player = event.getPlayer();
for (EquipmentSlot slot : EquipmentSlot.values()) {
if (player.canUseEquipmentSlot(slot)) { // HAND, OFF_HAND,...
[PaperMC/Paper] New comment on issue: #12431 Paper 1.21.5 Erroneous canUseSlot(EquipmentSlot) handle
Known, tho I do not think we'll end up changing vanillas diff around there but rather fix this in the craft bukkit layer.
Is your feature request related to a problem?
The Persistent Data Container is a great part of the Paper API, and I often find myself wanting to save Data not to a specific World/Entity/... but rather the Server itself. The usual way to go about this would be using Plugin YAML configuration files, which get cluttered and take up quite a large amount of space when dealing with larger amounts of data.
Describe the solution you'd like.
Having a Persistent Data Container for the Server (or if feasible for the Plugin) would allow storing Data in a uniform way like the other PDC implementations.
Describe alternatives you've considered.
Plugin YAML configuration files, which can't use PersistentDataTypes, as an example of one limitation.
Other
No response
This try to close https://github.com/PaperMC/Paper/issues/12431 mostly adding a overriden method in CraftHuman for match the expected logic to setItem in CraftPlayerInventory... Vanilla allows make this things but API need avoid this things for avoid another issues.
The problem I see with this is that the server itself doesn't store anything using NBT data. Implementing this would require adding some sort of server data file. You could fairly easily do this with a plugin using the serialization methods of the PersistentDataContainer.
652cea5 Allow getAsString()-ing non-persistent entiti... - SoSeDiK
It will not. There will be no sound played nor will sculk sensors be alerted.
Rebased on master...
7903621 Remove json-simple imports from API, keep it as... - kennytv
Currently, if a plugin wants to set a Cooldown group on cooldown, they need either use NMS or they need to construct an ItemStack, which should not be necessary...
Copilot reviewed 45 out of 46 changed files in this pull request and generated 1 comment.
<details>
<summary>Files not reviewed (1)</summary>
- paper-api-generator.settings.gradle.kts: Language not supported
</details>
<details>
<summary>Comments suppressed due to low confidence (3)</summary>
paper-api/src/main/java/org/bukkit/event/player/PlayerLoginEvent.java:22
- The deprecation version 'idk' is unclear; please update it to a proper version string to improve clarity.
@Deprecated(since = "idk")
paper-api/src/main/java/io/papermc/paper/event/connection/configuration/PlayerConfigurationConnectionEvent.java:8
- [nitpick] The field 'loginConnection' should be renamed to 'configurationConnection' to better reflect its purpose in a configuration event.
private final PlayerConfigurationConnection loginConnection;
paper-api/src/main/java/io/papermc/paper/connection/PlayerCommonConnection.java:3
- [nitpick] Consider clarifying the name of this interfac...
There's a grammatical error; 'caused' should be changed to 'cause' to read correctly.
* Calling this on initial configuration will cause undefined behavior.
Maybe worth && this with the impl?
Just for sanity sake if mojang changes stuff there? Rn we just mirror.
@SoSeDiK Does your implementation suffer from the same bug as mine?
Using this event to set an arrow fails when the player looks at a block instead of air (it still gets called). I don't find an obvious reason for that.
(Setting an arrow when the player has none.)
Edit: And the bow does not animate the pulling back of the string when holding a shield in the offhand but the arrow still gets fired.
7d5695d Improve ItemMeta#hasCustomModelData compatibili... - lynxplay
We definitely cannot break the non null contract on the lines getters/setters.
We might be able to get away with null in the internal list but it would need to be transformed to empty().
If a legacy plugin calls setLine(0, null) and a follow up plugin calls line(0, line(0)), I think it is fine to remove the null value there. They boil down to the same thing once consumed by the server.
But yea, "breaking" (eventho yea, it has been technically broken) newer API in favour of older ones, *especially when this has been the case since 1.16.5 and hence been part of the API for more than 4 years now is not a change I'd be happy with.
Maybe worth && this with the impl? Just for sanity sake if mojang changes stuff there? Rn we just mirror.
true... i make now check the added logic and super with the check of implementation.
@SoSeDiK Does your implementation suffer from the same bug as mine?
Yea, sadly have to use interact event workarounds on plugin's side, basically same solution as yours
Can this be an adventure key instead? (the conversation is then in PaperAdventure instead of CraftNamespacedKey)
Good point, thank you, done!
Currently this workflow use an action with a deprecated node, this PR update that and make the necesary changes by the break things.
ref for the changed values: https://github.com/tibdex/github-app-token?tab=readme-ov-file#example-workflow
Could you give a specific example on what kind of data you would like to store associated with the server that is so big storing it in yaml would be too large in size? Besides if you have that much data why not use a database?
I thought that there was discussions over file PDCs, but, the thing is that for stuff simple enough, YamlConfiguration already exists, for anything more complex, a DB would generally be the better option
The recent commit 121a7bf4ebd42beb9285a694039c2868b4148b07 added
the interface FeatureElement to the GameRules.Type class to expose the
stored feature flags of gamerules.
This however messed with the reobf mappings spigot uses, as the now
overridden method requiredFeatures needs to be mapped to the same
obfuscated name as FeatureElement#requiredFeatures.
To avoid having this in the mappings patch, the commit removes the
inheritance again and instead exposes a wrapper method.
de410d1 Fix reobf mappings regression in GameRules.Type... - lynxplay
33e8928 Add support for bonus chest configuration in Wo... - NonSwag
723b511 Clone exit location passed to teleport event (#... - emilyy-dev
[PaperMC/Paper] Issue opened: #12438 Add methods to BlockItemDataProperties Builder - its empty ๐
Is your feature request related to a problem?
I want to add block data for items like note blocks. Using this I can create custom blocks (by using block states).
There isn't a way to add a block data for the BLOCK_DATA component with the BlockItemDataProperties builder.
itemStack.setData(DataComponentTypes.BLOCK_DATA, BlockItemDataProperties.blockItemStateProperties().build());
BlockItemDataProperties builder only has a build() method.
Describe the solution you'd like.
Add the necessary methods for users to be able to add block data using the new data component api.
Describe alternatives you've considered.
//
Other
No response
Fixed in 1.21.5 via mojangs InsideBlockEffectApplier
ed32204 Clone blockpos in InsideBlockEffectApplier record - lynxplay
6b4ad08 Add PlayerRespawnEvent#isMissingRespawnBlock (#... - NonSwag
Needs testing to confirm whether this is fixed now in .5
Plugin YAML configuration files, which can't use PersistentDataTypes, as an example of one limitation.
which of those can you not store with yml?
It's not necessarily about the already provided PersistentDataTypes, but rather when having custom PersistentDataTypes which would be better to reuse uniformly for all serialization instead of creating separate serialization methods based on whether you're saving to a YamlConfiguration, DB or a PDC.
Besides if you have that much data why not use a database?
for anything more complex, a DB would generally be the better option
Larger amounts of data aren't the only reason to prefer PDCs, another caveat with both YAML/DB options is that unlike with PDCs you need to handle saving/loading yourself, and especially with DBs this can be quite annoying, having to deal with asynchrony, race conditions and such; You also sometimes don't necessarily want the user messing around with stored data when it is saved as a plain YAML doc...
There is no global place to store NBT, and so, you'd need to manage it yourself anyways, unless you wanted to store it on the default world
One option would be in the config folder where the paper-global and paper-world-defaults configuration files reside. Another option would be implementing said Plugin PDCs instead which could easily be stored within the Plugin Data folder.
We generally would not be interested in attempting to introduce a new data system that we'd need to lifecycle for you, the only route I could see us supporting there is file based in which you'd need to deal with that yourself, the exact same as the configuration file, etc
I removed the forwarding mode related methods
I would suggest for the distant future, moving stuff like getPort and getIp and other methods from the Bukkit interface to this class to unclutter that mess of a class
Yes, so, isProxyOnline mode makes sense, individual bungee/velocity forwarding mode ones, I'm not sure about
It could be useful in case there would be Velocity-only features to use through Paper in the future.
Tho, that could also be checked via some message channel stuff I suppose.
If there are such features in the future, we can expand this type :wink:
I mean, the two major things I'd imagine plugins might want to see on this front are "Are we in online mode?" and "Are we behind a proxy?" disambiguation is complex, I generally wouldn't want us to be in a state where we add support for some new proxy mode and now every plugin relying on this API to check that is broken
Currently, when wanting to prevent or modify all or certain BlockData changes, you have to listen to numerous different BlockEvents to try and catch every one, and even then you don't catch cases like changes made by commands.
This PR adds a BlockDataChangeEvent which gets called whenever a BlockState gets changed in net.minecraft.world.level.Level#setBlock. To stay more consistent with Bukkit's Naming Scheme, BlockData has been chosen instead of BlockState for the Event Name.
Another benefit of this method is that commands like setblock return a sensible message that the block changes could not be made, instead of not notifying the user like with other workarounds.
I was thinking about something like this: https://pastes.dev/3ZkbtqLipa
This pull request includes significant changes to various files to enhance code maintainability, performance, and documentation. The changes include the addition of utility methods for bit manipulation, improvements to the rate limiter, and detailed JavaDoc comments for better code understanding.
Enhancements and Refactoring:
paper-server/src/main/java/io/papermc/paper/antixray/BitManipulationUtil.java: Introduced a new utility class for common bit manipulation operations to reduce code duplication and improve maintainability.paper-server/src/main/java/io/papermc/paper/antixray/BitStorageReader.javaandpaper-server/src/main/java/io/papermc/paper/antixray/BitStorageWriter.java: Refactored to use the newBitManipulationUtilmethods for reading and writing long values from/to byte arrays and creating bit masks. [[1]](diffhunk://#diff-ad396963ed5d4cfe441e513b9c4392f8217f02...
Expected behavior
When I was working on my Paper fork, I noticed that the logic for handling Bukkit's EntityExplodeEvent / BlockExplodeEvent has flaws.
This is the current code of the relevant part in net.minecraft.world.level.ServerExplosion:
public void explode() {
/* ... some code ... */
this.level.gameEvent(this.source, GameEvent.EXPLODE, this.center);
List<BlockPos> list = this.calculateExplodedPositions();
this.hurtEntities(); // problem 1: entities are hurt before the explosion event triggers
if (this.interactsWithBlocks()) { // problem 2: explosion events don't fire for explosions that don't modify blocks (Explosion.BlockInteraction.KEEP)
ProfilerFiller profilerFiller = Profiler.get();
profilerFiller.push("explosion_blocks");
this.interactWithBlocks(list); // explosion events are triggered inside this method
profilerFiller.pop();
}
if (this.fire) { // problem 3: explosions can create fire even if they...
Is your feature request related to a problem?
If my simulation-distance is much smaller than the view-distance, and I don't want the biological entities to randomly pathfind outside the simulation-distance range.
Describe the solution you'd like.
Add an option to prevent biological entities from randomly pathfinding into the area outside the simulation-distance range.
Describe alternatives you've considered.
null
Other
No response
Discussion Category: Ideas
Please do not open pull requests from the main branch, create a new branch instead.
_Originally posted by @github-actions[bot] in https://github.com/PaperMC/Paper/issues/12440#issuecomment-2804099050_
You should open a pull request from a different branch than main, as it says...
You should not PR from the same branch as you're targeting, it creates a whole host of issues which is best avoided on our side and yours
This pull request includes several changes focused on improving documentation, optimizing performance, and refactoring code for better maintainability. The most important changes include adding Javadoc comments to various classes and methods, optimizing string manipulation in camelCase names, and refactoring bit manipulation utilities.
Documentation Improvements:
- Added Javadoc comments to
AllocatingRateLimiterclass and its methods to describe their functionality and usage. [1] [2] [3] - Enhanced documentation for
ThreadUnsafeRandomclass, highlighting its non-thread-safe nature and usage recommendations. [[1]](diffhunk://#diff-b4f79bd02fec8bf95574648054eceba39cdca0f655f2014ac3030ecded9f1abbL10-R22...
This generally just looks like a shotgun PR... We do not accept changes to moonrise on this repo; replacing the string manipulation inside of the generator is really not a performance concern, some util functions are maybe nice but not really pressing
I was thinking about something like this: https://pastes.dev/3ZkbtqLipa
hmm yeah that works too.. i wanna add the check for valid slots BUT... API allow set saddle/body but item replace command not but that is another thing.
Welcome to paper :partying_face:
Thank you for this really well crafted PR!
The general "worry" with such events has always been
a) Yea, incredibly hot code path, but len checks like you added should balance that :tm:
b) more importantly, context. The event gets to carry effectively 0 context of why this change is happening and as such, it is useful for a rather niche use-case, specifically trying to protect a specific block state at all cost. For nearly all other use-cases, it is pretty nonsensical addition. The fact that plugins will still just ignore this when they skip straight to palette modifications because they are placing a crap ton of blocks does not help it either.
We'll definitely need some wider discussions on this.
b) more importantly, context. The event gets to carry effectively 0 context of why this change is happening and as such, it is useful for a rather niche use-case, specifically trying to protect a specific block state at all cost. For nearly all other use-cases, it is pretty nonsensical addition. The fact that plugins will still just ignore this when they skip straight to palette modifications because they are placing a crap ton of blocks does not help it either.
Having some state attached to a block somewhere in memory and wanting to clean that up when the block changes is the biggest usecase for me tbh. And I don't think this is that rare of a situation? The palette modification thing is something paper cannot do anything about, but it would be nice to have at least some API for when the world changes by different plugins, commands, vanilla features etc. that use the normal api. Listening to every possible event and still missing something is annoying.
More context is ...
Highly low-level events are a pain because they're completely out of the context of anything that traditionally interacts with this stuff and are in an area which can get hot stupidly fast; definitely not fond of an event with zero contexts fired after everything else is cancellable or even modifiable this far down the chain;
Yea, having data attached to blocks is a fine usecase, until the block is pushed by a piston and now the event did not carry enough context for you to properly move the data. Or the block was destroyed and you want to carry over data to the drops.
As to the "why not" part, the event chilling where it is has downsides (at least as long as the thing is cancelllable).
Plugin API for example is not supposed to be cancellable outside of specific calls that denote that.
This addition would retroactively make all block modification API calls cancellable with 0 proper way of the calling plugin to react to such a change.
Stuff also breaks around the concept of MONITOR priority in other existing events, specifically "At MONITOR priority, the EntityChangeBlockEvent is fine, lemme record that" being completely undone as the event now cancels, idk, an Enderman placing their block but without the entity maintaining it.
The missing context isn't just a plugin problem, it is also a ser...
As to the "why not" part, the event chilling where it is has downsides (at least as long as the thing is cancelllable). Plugin API for example is not supposed to be cancellable outside of specific calls that denote that.
This could be solved by setting a bitfield in flags for the API Level#setBlock calls and checking if it is present before calling the Event
Maybe instead we could say "hasOcccupants" whether or not this POI can hold occupants. Reuses terminology
This PR add methods for Block and BlockState for check if can Suffocate, this behaviour cannot be check using isSolid (ex: Leaves are consider solid but cannot suffocate)
Expected behavior
Server Should not Randomly Crash
Observed/Actual behavior
crash-2025-04-16_13.07.46-server.txt
Steps/models to reproduce
idk, i start the server and fly around
Plugin and Datapack List
its in the crash report
Paper version
its in the crash report, but here: This server is running Paper version 1.21.5-21-main@2948eb2 (2025-04-15T14:59:04Z) (Implementing API version 1.21.5-R0.1-SNAPSHOT)
Other
No response
Mojang no longer allows using non-colour chatformatting codes for player team colours.
E.g. a player team using ยงm or strikethrough is simply not valid anymore. This was changed in 25w05a.
You seem to be doing so through some mean.
I don't think there is much we want to do here, outside potentially gracefully loose data.
d929733 Document, add preliminary resource pack support. - Owen1212055
Adds Player#setEffectiveLocale(Locale) / Player#getEffectiveLocale() to set and get a player-specific locale, which is used for server-side translations.
Closes #10570
Expected behavior
The MapInitializeEvent should only fire when a map is initialized. So from my understanding, that's when
- a filled map is opened in a player's main hand or off hand
- a chunk containing an item frame containing a filled map is loaded
Observed/Actual behavior
If a player has a filled map in their inventory (locked or not locked), the MapInitializeEvent will fire every single tick.
Steps/models to reproduce
Load a plugin, TestPlugin-1.0.jar with an EventListener listening to this event.
@EventHandler(ignoreCancelled = true)
public void onMapInitialize(MapInitializeEvent event) {
getLogger().info("TEST");
}```
Observe as TEST is output every tick.
### Plugin and Datapack List
TestPlugin-1.0.jar
### Paper version
This server is running Paper version 1.21.5-21-main@2948eb2 (2025-04-15T14:59:04Z) (Implementing API version 1.21.5-R0.1-SNAPSHOT)
You are running the latest version
### Other
_No response_
Hey @brickmonster , could you post the world seed here if you still have it? Took a look at the code & stack trace, looks like this is something to do with structure generation close to the world spawn, if you give me the seed I'd be able to test it and see if I can come up with a fix.
Simplified stack trace for my own reference:
1. StructureTemplate.placeInWorld
2. SinglePoolElement.place
3. ServerLevel.onBlockStateChange
4. PoiManager.exists()
5. getOrLoad() -> ๐ฅ
Files:
main/java/ca.spottedleaf.moonrise.common/util/TickThread.java
minecraft/java/net/minecraft/world/entity/ai/village/poi/PoiManager.java
I am not sure if I do it right. waiting for review.
Expected behavior
It shouldn't make that noise
Observed/Actual behavior
It makes that noise
Steps/models to reproduce
Right click carrot on ground, other player will hear generic block place sound (stone)
Plugin and Datapack List
N/A
Paper version
This server is running Paper version 1.21.4-DEV-main@0767902 (1970-01-01T00:00:00Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are 24 version(s) behind
Download the new version at: https://papermc.io/downloads/paper
Previous version: 1.21.4-DEV-9b1798d (MC: 1.21.4)
Latest 1.21.4 stable, might be fixed in 1.21.5, i have no easy way to test
Other
No response
Close enough, it is directly related to the block place context not being evaluated for item interaction/position early enough.
I can reopen this if you care for it but it'll be fixed by the same PR I believe.
Added this issue to the PRs resolves list and created a build PR label. If you wanna go ahead and check if that fixes it.
It is 1.21.5 tho so you might have to find a 1.21.5 client and spin up a server locally given you for some reason cannot test on .5.
[PaperMC/Paper] New comment on issue: #12406 MemoryKey - expose all available keys from NMS registry
Registry#MEMORY_MODULE_TYPE is not a proper registry if you see in PaperRegistries it's not backed by a server registry. But that's the plan in the future. https://github.com/PaperMC/Paper/pull/5605 just need to be rebased, there should be more fields exposed tho now in 1.21.5 but the api is really limited at the moment.
Part 2 and 3 will be fixed in https://github.com/PaperMC/Paper/pull/11840 (which is blocked rn), part 1 was deemed as WAI in https://github.com/PaperMC/Paper/issues/8934
Duplicate of https://github.com/PaperMC/Paper/discussions/11050, and i generally agree with machine (can be seen easily with maxHealth where the number of hearts doesn't increase past the original limit
Expected behavior
No errors and a clean reload.
Observed/Actual behavior
A ConcurrentModificationException.
Steps/models to reproduce
Start server
Reload until you see the error. ( it's at the bottom kinda )
Plugin and Datapack List
Plugins (all Bukkit) : FacilisCommon, MultiWorld and SkinsRestorer
Datapacks: vanilla (built-in), file/bukkit (world), bundle (feature), paper (built-in)
Paper version
[19:56:32 INFO]: Checking version, please wait...
[19:56:32 INFO]: This server is running Paper version 1.21-83-master@967f98a (2024-07-17T14:55:35Z) (Implementing API version 1.21-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21-81-ceeb8c1 (MC: 1.21)
Other
Other
I noticed that every time I start my server, reload it a couple of times ( because I am developing my own plugin ) and look at the console ( to check for bugs ), I see a ConcurrentModificationException with a number that increments every time I see the error ( not every ti...
Expected behavior
Join the server and play the game.
Observed/Actual behavior
Trying to join server and getting kicked with this error: io.netty.handler.codec.DecoderException: java.io.IOException: Packet play/clientbound/minecraft:map_item_data (adx) was larger than I expected, found 110 bytes extra whilst reading packet clientbound/minecraft:map_item_data
Steps/models to reproduce
Setup Velocity Proxy and Paper 1.21.4 or 1.21.5 server. Try to join.
Plugin and Datapack List
16:35:40 INFO]: โน Server Plugins (47):
[16:35:40 INFO]: Paper Plugins (2):
[16:35:40 INFO]: - CrazyCrates, LogFilter
[16:35:40 INFO]: Bukkit Plugins (45):
[16:35:40 INFO]: - AdvancedBan, *AdvancedGUI, AdvancedPets, BedrockPlayerManager, ChatControl, ClientDetectorPlus, CMI, CMILib, CommandTimer, DeluxeMenus
[16:35:40 INFO]: *EasySetSpawn, FastAsyncWorldEdit, FileCleaner, floodgate, GadgetsMenu, InteractiveBoard, ItemJoin, JukeBox, JumpPads, LuckPerms
[16:35:40 INFO]: Matrix, MyCommand,...
This was fixed in a later version of paper
Can you reproduce without plugins, especially noting that you have a low level packet library plugin installed
i was told to reopen the issue by someone, go look at #11101
And the existing issue was reopened
You would need to provide information such as logs/version, the fix for this should be in 1.21.3+
I tried just with ViaVersion on the backend. Same issue
This PR doesn't make sense and assume that getChunk take a block pos instead of a chunk pos.
It would have been good to link the video too: https://www.youtube.com/watch?v=tCcBzxnl5Os
[PaperMC/Paper] New comment on issue: #12406 MemoryKey - expose all available keys from NMS registry
Registry#MEMORY_MODULE_TYPE is not a proper registry if you see in PaperRegistries it's not backed by a server registry. But that's the plan in the future. #5605 just need to be rebased, there should be more fields exposed tho now in 1.21.5 but the api is really limited at the moment.
Thats good to know, thank you!
Well, ViaVersion being a network hacking plugin would be the first offender for something like this.
Replicating without it is probably what cat was implying.
Hello @Lulu13022002, could you please care to explain why the PR does not make sense? I would love to understand what about the PR seems confusing to you, in hopes I can make everything clear.
Cheers,
Afonso Mendonรงa Jacinto
Expected behavior
BungeeChat components to support click/hover etc on 1.21.5
Observed/Actual behavior
BungeeChat components do not support click/hover on 1.21.5, but do on Spigot
Steps/models to reproduce
Run WorldEdit and do /schem list on Paper, it won't be clickable. On Spigot, it will. WorldEdit uses Text3 for API compatibility reasons, which serialises via Bungeechat components
Plugin and Datapack List
WorldEdit
Paper version
This server is running Paper version 1.21.5-22-main@6c2b037 (2025-04-16T18:32:47Z) (Implementing API version 1.21.5-R0.1-SNAPSHOT)
Other
It should be bumped to 1.21-R0.3-SNAPSHOT to get 1.21.5 support, Mini bumped it to 1.21-R0.2 a few weeks ago, which doesn't include the fixes.
bungeecord R0.3-snapshot contains no chat changes. this appears to be an issue with worldedit, its sending raw legacy messages, they of course dont retain hover and click info
Merger should look into whether we should instead call FishingRodItem#use as that also triggers sculk sensors and makes the sound. Not sure whats best here
Just an update, spigot just patched it like this
https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/3b4fd5b321f4440a2b3a67f3945739b45e6e687f#src%2Fmain%2Fjava%2Forg%2Fbukkit%2Fcraftbukkit%2Fevent%2FCraftEventFactory.java
This PR close https://github.com/PaperMC/Paper/issues/12372 by adding the support for server to consider the damage, this make the break change where the WorldBorder created by Server/Bukkit set the damage in zero.
I need a few feedback for the follow case:
If create a WorldBorder and set damage all fine, but if i change the World WorldBorder that change override in client the WorldBorder make you can not notice the virtual WorldBorder and get damage by the virtual... then not sure what is the best aproach for this:
- Notice this in JavaDoc for make users handle this in plugins
- Modify the BorderChangeListener in the Level class for add a filter and avoid send changes to players who has virtual worldborder and make Player#setWorldBorder refresh the data
3e8067f fix class predicate emitter - Lulu13022002
2 makes more sense to me, and makes the API easier to use
Esp if other parts of the server still think the virtual world border is still active / it mixes settings with the update packets
2 makes more sense to me, and makes the API easier to use
Esp if other parts of the server still think the virtual world border is still active / it mixes settings with the update packets
yeah i found two places where the listener are created with the send packets... for PlayerList and Level for that i wanna wait more feedback and then touch that
Thanks this was just an issue with an outdated packetevents on proxy.
Very nitpicky
But I don't believe "use first world border available" really describes the changes
Maybe smth like "use players worldborder, if present"
I personally would like an API to fully disable this. I use the virtual world boarder to simulate the world boarder not being there (as I don't like its visual presence), and I would personally like it to remain this way.
I'd like an API that makes the player receives damage if the player leaves the "real" world boarder, even if his personal world boarder is larger. (Basically make it fully the same as it is now) And I personally think my suggestion should be the default (as otherwise it is sort of a breaking change).
Setting the damage to 0 by default is a good start, but the real world boarder is still not active anymore
Ngl, itโs so easy to just check it yourself and damage the player urself. I also donโt really see why this is super useful especially as this is described as a sort of โvirtualโ border.
as I said, the only way I could support this would be if it was an optional override to the main scoreboard, changing behavior here is just bleh, people use the client one for visual stuff and expect the global border to still be active and do stuff, even if not visual to players
Scoreboard?
Then what about just improvement the docs for tell about the none damage is expected and can be handle by the user implementation?
I've added a new event that fires when a Ghast fires a fireball, I've implemented some basic setExplosionPower and getExplosionPower methods to mimic those provided by net.minecraft.world.entity.monster.Ghast in the future (such as a method to modify the speed, etc). I opted to set the values directly, because I didn't want to use any weird casts within the event listener's method to get a bukkit ghast.
I've added a new event that fires when a Ghast fires a fireball, I've implemented some basic setExplosionPower and getExplosionPower methods to mimic those provided by net.minecraft.world.entity.monster.Ghast in the future (such as a method to modify the speed, etc). I opted to set the values directly, because I didn't want to use any weird casts within the event listener's method to get a bukkit ghast.
Welcome to paper :partying_face:
Thank you for your first PR.
In what way does this event expose any benefits one could not already implement via the ProjectileLaunchEvent?
@EventHandler
public void on(final ProjectileLaunchEvent event) {
if (!(event.getEntity() instanceof final Fireball fireball && fireball.getShooter() instanceof final Ghast ghast)) return;
......
}
does (at least in my mind) the exact same already.
Ah... I forgot about the ProjectileLaunchEvent...
I think a potential concern with this... is that those limits aren't then synced to the client, so any client-side prediction that might use them would be incorrect leading to some desync.
there should be some attributes that don't desync with the client? like attack_knockback, I think the velocity is calculated by server and then send to player. Maybe they can get added
If I'm wrong, please correct me
Discussion Category: Ideas
Fix some either holder components: instrument, provides_trim_material and allow inlined sound definition for break_sound.
Expected behavior
MessageComponentSerializer should return the given tooltip for the argument suggestion when supplied asynchronously.
Observed/Actual behavior
When supplying command suggestions asynchronously using CompletableFuture#supplyAsync, the suggestion's tooltip is empty.
Steps/models to reproduce
Commands.literal("chat")
.then(Commands.literal("channel")
.then(Commands.argument("channel_name", StringArgumentType.word())
.suggests((ctx, builder) -> CompletableFuture.supplyAsync(() -> {
builder.suggest("test", MessageComponentSerializer.message().serialize(
// The tooltip will be empty
MiniMessage.miniMessage().deserialize("<blue>test tooltip")
));
return builder.build();
}))
.build())
...
no idea when these broke, but while testing / updating the paper-docs configuration stuff (incoming at somepoint :tm:),
I noticed that bukkit.yml, commands.yml and help.yml all had headers in their default files that werent being copied over.
Now, the behavior is that the headers are replaced on each start, matching paper-*.yml and spigot.yml
this replacement may cause data loss if people put custom information in the headers of these files.
if this is unacceptable, this can be changed to only affect new servers/servers where the header is blank,
by only setting the header if the current header is empty, but this means updating the header later becomes harder.
Also updated the headers to roughly match the format of paper-*.yml
Is your feature request related to a problem?
Because Material is an enumeration class, if I want to register blocks to the server in some special cases, I can't use Material to get the newly registered blocks. It is difficult to be compatible with plugins using Material. Due to the characteristics of Java, it is very dangerous to forcibly add enumerations to Material. So can I refer to the Blocks class of nms to modify Material to make it registrable?
Describe the solution you'd like.
Modify Material to make it registrable
Describe alternatives you've considered.
Use unsafe to force add enumeration to Material
Other
No response
Discussion Category: Ideas
Material is bad design and considered quasi deprecated, see the Block/ItemType APIs
Discussion Category: Ideas
However, there are already many plugins on the market that use Material. Although there is a new API, if this one is not considered to be removed, can it be refactored?
Discussion Category: Ideas
Material will have some form of compatability hack in the future to mitigate this, not sure what the entire plan is as this is a pretty invasive, we wanted to get out a better system for dealing with the ASM compatibility hacks first
Discussion Category: Ideas
Well, hopefully this can be improved sooner
Discussion Category: Ideas
This pull request enhances the Attributable interface in Attributable.java by introducing a set of useful new methods for managing and interacting with attributes more effectively. These additions make it easier to check if an attribute exists, access all registered attributes, and work with both their base and final values.
Here's what's new:
Check if an attribute exists:
The new hasAttribute(@NotNull Attribute attribute) method lets you verify whether a specific attribute is currently registered.
Access all registered attributes:
The getAttributes() method returns a collection of all attributes currently registered to the object.
Manage base values of attributes:
getBaseValue(@NotNull Attribute attribute) retrieves the base value of a given attribute. If the attribute isn't registered, it returns 0 by default.
setBaseValue(@NotNull Attribute attribute, double value) sets the base value of a given attribute, and throws an exception if the attribu...
I think you forgot to add the implementation of the added methods.
Also did you want to include the ParticleBuilder changes? You didn't include those in your pr description.
The PR seems to not add anything useful that isn't already present on the AttributeInstance.
Additionally you seem to have random changes to the particle builder.
We will not be pulling this, thank you for your PR!
I support this. I think that hiding player with hidePlayer should keep it's actual behavior while hideEntity should not remove the player from the list. But if we had a boolean to hidePlayer, that's good too ๐
Any update on this? Given that it bundles the isInRaitOrWater check, it is a bit too on my radar.
@cymbycode Hi, the crash is most likely caused by the EnderDragon plugin
04b9112 Update projects dependents GitHub Action (#12436) - Doc94
def0532 Fix writing headers and update to be more paper... - 456dev
You would need to provide information such as logs/version, the fix for this should be in 1.21.3+
This appears to still be an issue on 1.21.4, and presumably 1.21.5 too (although I have not tested it).
Can't really tell where the problem lies down exactly, but I was able to easily reproduce it with plugins such as PySpigot and LuaLink. Both are scripting engines and allow for runtime command registration via their "managers".
Here's the error itself: https://pastes.dev/VGlwabFbnW
(Possibly) Relevant code:
- PySpigot: https://github.com/magicmq/pyspigot/blob/master/bukkit/src/main/java/dev/magicmq/pyspigot/bukkit/manager/command/BukkitCommandManager.java
- LuaLink (Registration): https://github.com/LuaLink/LuaLinkV2/blob/master/src/main/kotlin/win/templeos/lualink/lua/LuaManager.kt#L87
- LuaLink (Unregistration): https://github.com/LuaLink/LuaLinkV2/blob/master/src/main/resources/lua/script.lua#L74-L104
This happens after unregistering, and a moment later - registering comma...
stacktraces from software which isn't paper is generally useless to us; All I can guess is that maybe the child nodes are being modified at runtime which is generally not standard behavior, we only defensively copy the root node as that's generally what we expect people to be messing with
- Javadoc corrections
Tool.Rule#speed()had a description forTool.Rule#correctForDrops()AbstractArrow#setItemnow points to#setItemStackinstead of#getItemStack
- Undeprecate
Entity#isInWaterOrRain- I've asked in Discord about this, there weren't any strong opinions for/against it.
- Deprecating
BubbleColumnoverload in 1.21.5 makes sense, but the rain one still exists internally and is a neat way to check "is this entity wet?". I don't mind leaving it deprecated, but also I've used this method 34 times in just one codebase and my lazy kicked in.-
<details>
<summary>Image</summary></details>
-
Any update on this? Given that it bundles the isInRaitOrWater check, it is a bit too on my radar.
I've moved the first two commits into a separate PR (https://github.com/PaperMC/Paper/pull/12462) given that the sign changes seem stuck.
We definitely cannot break the non null contract on the lines getters/setters.
To clarify, the changes in this PR do not break the null contract. getLine/ line were always nullable and getLines/lines were (and currently are) returning nulls as well, just that the javadoc didn't cover that.
We might be able to get away with null in the internal list
If we remove the null internally, there are two things to consider:
- Are we fine breaking existing
nullchecks in plugins? empty() will pass those linescurrently returns the internal (array) list directly. We either need to break mutability or return a list that would reject/convert nulls on changes to the list (event constructor also need to convert nulls then)
...
Ive moved the first two commits into a separate PR (https://github.com/PaperMC/Paper/pull/12462) given that the sign changes seem stuck.
thank you!
To clarify, the changes in this PR do not break the null contract. getLine/ line were always nullable and getLines/lines were (and currently are) returning nulls as well, just that the javadoc didn't cover that.
I do think MM's original PR is nicer in this regard yea, tho yea you are also right, I missed the fact that the component ones are nullable already. Presumably only due to the fact that legacy strings have that nasty habit.
Are we fine breaking existing null checks in plugins? empty() will pass those
I'd be at least. Something going from nullable to non null is generally fine as the non null version could have already been in there. Especially for components, for legacy strings yea, we might be able to find some hacky way to yield back null.
lines currently returns the internal (array) list directly. We ei...
I think we should additionally reset aboveGroundTickCount when the server attempts to disconnect a player to prevent the event from being spammed
Possibly, tho in a separate PR :+1:
df42993 Fix floating warning log when the kick event is... - pedroagrs
Add a second opening bracket to the method start instead.
I think the Either should allow for non-optional use too, e.g. isLeft/Right and left/right that throw on incorrect use. right now I assume the idea is to use instanceof checks given the two extra interfaces are exposes, but I'd prefer methods on Either for that
In that case I'd just make it a list to make it easier to get them individually
Unfortunately the oversized behavior is used enough that we can't break it without a longer discussion and warnings, so for now this is okay
I am a bit confused on these.
The entry yields this nullable, which mirrors internals, while this falls back to GENERIC.
What is the line of thought here?
I haven't tested it, but it looks like setting this before the isConnected call below means the actual disconnect logic is skipped?
Not tested, but generally looks good!
This should use the actual Block constants and/or reference the placeStructure method it's taken from
I did what vanilla does when calculating the fall message:
FallLocation fallLocation = Objects.requireNonNullElse(combatEntry.fallLocation(), FallLocation.GENERIC);
The reasoning is, since this calculates the fall location type, then if there's no special fall type, yield GENERIC (generic is only used internally as a fallback when the type is null iirc, so it was null vs GENERIC, and I liked the latter more)
But if I've missed something, nullable is also fine
Maybe also on the names, but I don't think we have proper guidelines for that, stuff like isIncludeEntities is a bit off, I think we usually do shouldIncludeEntities or includesEntities
Maybe this should just be separate events from an abstract class
Yea I know it is used internally for the death message computation, but that seems to be about it in terms of usage for that type?
The disconnect between "LivingEntity#calculateFallLocationType" and "create new combat entry from living entity -> ah it returns null here now eventho it just yielded GENERIC" is a bit unfortunate imo.
Tho I guess that is more on mojang than on this API given they do the "fallback" so late in their logic.
It is fine like this then, tho maybe a bit of javadocs if you have some time.
Kinda against this, what prevent you from having this method in your plugin if you have a lot of use for it, being lazy is not an argument for me. The method existing internally doesn't matter, api goal is not to map every methods found in the source but rather providing powerful tools.
General idea imo is the concept of "is the entity wet".
E.g. might distinguish fire.
Tho, urgh, yea technically that ought to be a separate method instead of this syntax sugar.
Given the change was on the "no one has strong opinions, we know it isn't great but sure" basis, and we have found an opinion on it, I dropped the deprecation removal :+1:
it returns null here now eventho it just yielded GENERIC"
It's quite ambiguous (javadoc suggestions?), but is expected from my point of view
Having GENERIC in the entry represents a fall (and this method is meant for that), while null means that the entry is not a fall damage one
Sure, that's fine by me. I've updated the deprecated javadocs then instead
Yea but calculateFallLocationType yielding GENERIC then, when the entity isn't falling rn is kind of a counterpoint.
Having a non null falltype in the entry (at least according to internals) does not define if that was a fall.
That is tracked (correctly so) via the DamageSource.
You can be in the air and killed by an arrow, that kill won't be a registered as a fall related death even though the last entry does hold a falllocation type.
Javadocs on CombatEntry#combatEntry also currently link to the calc method, which then would not be correct right?
Any thing need to be make in this PR?
My first review is still relevant iirc, generally it's a bit tricky but you need to play with lists a bit
Good points, definitely need to at least clarify this in javadocs
This pr break fire explosion done via world.createExplosion(location, 3, true, false) by filtering empty blocks i guess. Ideally should only affect the event but it's tricky cause block list is mutable
This one? If not wrong currently only affects the legacy ay not? Because the new way not filter any what ws the issue in first place when you let that comment.
Later im test that for see what can do with the list or just pass the empty blocks because i dont see a nice way to filter correctly and avoid mess that...
Initially I had the same idea, but I wasn't sure how backwards compat would work
Would PlayerPickItemEvent listeners still be called if the exact event isn't called anymore?
This should build/test successfully now. Internal mob variants should not have had SpawnPrioritySelectors.EMPTY
THIS IS PULL REQEUST #12345 AND I LOVE IT (soory this might be off topic but i had to say it)
What I find a bit unfortunate is that changing the bonus power in the event basically makes any changes in the offers redundant, as you reroll these anyways.
I don't know if there is a particularly clean way to fix this. I personally can also only think of one way to fix this, but I understand it is not very advantageous:
- The introduction of a new
RetrieveItemEnchantPowerEvent, which allows for setting the enchantment bonus before the offers are even put into consideration.
Therefore, the actual PrepareItemEnchantEvent could stay unmodified and enchantment offer modifications would still work as intended.
Of course, before you make this change, I'd like a Paper developer to confirm that this is an acceptable step to take, because I am not sure myself either.
Regression in 1.21.5 update.
Might ultimately make more sense to rename the AoE cloud instead of having two things named entity in "scope" but that's a separate issue.
55f2020 Fix CCE in LingeringPotionSplashEvent (#12463) - wizjany
Welcome to paper! Thanks!
I will fix the build error as soon as possible.
@Strokkur424 your idea is previous my idea.
when I discussed this feature at Paper discord's paper-dev channel, I suggest that structure but lynxplay adviced me making the event just set value is not good for his idea.
So I should change original PrepareItemEnchantEvent. Yeah. I feel it would be good if offers method have more role too. and I also think "why doesn't it process the vlaue od offers member field at constructor point with considering the bonus value? it would be easy way to handle the logic when making an event." but that is not really feasible. because paper-api package can not import the code from paper-src. (I don't know the principle why it should be like it.)
Finally my decision is making bonus member field non final instead of making new event to set the bonus value with other fields, checking the value and refreshing the enchantment hint after PrepareItemEnchantEvent calls. (it is now structure.)
the discord dialog link discussing this feature with lynxplay:...
Expected behavior
Smooth movement of minecarts
Observed/Actual behavior
Minecarts rubberband for the rider.
The rider's view also rubberbands.
Rubberbanding is not visible to external viewers or when spectating the rider or minecart.
The severity of the rubberbanding isn't consistent. Reconnecting doesn't change it but restarting the server does.
Steps/models to reproduce
Ride in a moving minecart. Going in a straight line makes it more obvious.
Vanilla and spigot are NOT affected.
Fresh server on localhost.
MSPT between 2 and 10.
Plugin and Datapack List
None
Paper version
This server is running Paper version 1.21.5-23-main@5f0b829 (2025-04-19T19:56:53Z) (Implementing API version 1.21.5-R0.1-SNAPSHOT)
Other
Spotted by another user on discord:
#paper-help message
Might have some weirdness with minecarts at the moment, need to take a closer look later (there seems to also be an inconsistency between when the VehicleEntityCollisionEvent is called between boats and minecarts).
Well, we still need some way to modify the new enchantment suggestions, because this is a valid thing a plugin would do:
- Add 5 to the bookshelf bonus.
- Replace smite and band of arthropods with sharpness.
Not entirely sure how this can be achieved cleanly though.
@Strokkur424 your idea is previous my idea.
when I discussed this feature at Paper discord's paper-dev channel, I suggest that structure but lynxplay adviced me making the event just set value is not good for his idea.
So I should change original PrepareItemEnchantEvent. Yeah. I feel it would be good if offers method have more role too. and I also think "why doesn't it process the vlaue od offers member field at constructor point with considering the bonus value? it would be easy way to handle the logic when making an event." but that is not really feasible. because paper-api package can not import the code from paper-src. (I don't know the principle why it should be like it.)
Finally my decision is making bonus member field non final instead of making new event to set the bonus value with other fields, checking the value and refreshing the enchantment hint after PrepareItemEnchantEvent calls. (it is now structure.)
the discord dialog link discussing this feature with lynxplay:...
@Strokkur424
You are right. refreshing enchantment is needed hint when replacing one of offers to other enchantment. Because paper-src codes can not be imported to paper-api, we should process the entire refreshing logic at paper-src/.../PrepareItemEnchantEvent.java (like logics of my PR)
I am sorry I haven't managed to read through this for so long.
The suggestion I made on discord was
Yea, I think there might be a point in adding API. Tho I don't think I'd like an API that says "just set that value" of bookshelves around.
The more powerful API on e.g. the EnchantmentView or whereever would be
Construct me an EnchantmentOFfer for this slot with this amount of bookshelves around
which I still believe to hold true.
Allowing a plugin to reroll specific offers and then setting them via Event#getOffers would enable doing all of this without the need for a second event.
@lynxplay Yeah. and I don't make another event.
it is a simple quality-of-life feature update for users who want an enchantment offers of specific level of bonus.
Expected behavior
When re-entering the paper server, the movement speed attribute is reset to the original value, while with the vanilla server core during testing there are no problems with resetting the movement speed attribute to the original. Please look into the cause and fix the bug.
Observed/Actual behavior
The speed attribute when entering a change in movement speed is reset on the paper server and does not save the current value of the movement speed on the ground
Steps/models to reproduce
didn't find
Plugin and Datapack List
Bukkit Plugins:
[13:31:01 INFO]: - AuthMe, Citizens, CMI, CMILib, DeluxeMenus, Interactions, PL-Hide, PlaceholderAPI, WorldEdit, WorldGuard
Paper version
This server is running Paper version 1.21.5-28-main@55f2020 (2025-04-22T20:12:27Z) (Implementing API version 1.21.5-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.5-26-d22644a (MC: 1.21.5)
Other
No response
I made MRE for this issue. Command registration/unregistration code copied from an actual plugin suffering from it.
https://github.com/PukPukov/paper-1-21-4-cme-mre
Taking a look at the logic for block breaking, it seems an unnecessary, duplicate distance/interaction check is being performed.
This distance check feels a bit redundant, as immediately after, a more comprehensive sanity check is performed in handleBlockBreakAction.
public void handleBlockBreakAction(BlockPos pos, ServerboundPlayerActionPacket.Action action, Direction face, int maxBuildHeight, int sequence) {
if (!this.player.canInteractWithBlock(pos, 1.0)) {
if (true) return; // Paper - Don't allow digging into unloaded chunks; Don't notify if unreasonably far away
this.debugLogging(pos, false, sequence, "too far");
} else if (pos.getY() > maxBuildHeight) {
this.player.connection.send(new ClientboundBlockUpdatePacket(pos, this.level.getBlockState(pos)));
this.debugLogging(pos, false, sequence, "too high");
} else {
...
}
}
Closing this as in general it's not really certain what you are trying to fix here. Feel free to respond with a more detailed description of your changes, but it's not really understood what kind of "unnecessary distance/interaction check" this is resolving here.
Closing this as in general it's not really certain what you are trying to fix here. Feel free to respond with a more detailed description of your changes, but it's not really understood what kind of "unnecessary distance/interaction check" this is resolving here.
It's not trying to "fix" anything, it's just observing that the same check is being performed here twice
There is a difference in the final outcome of those events, it's not exactly redundant
There is a difference in the final outcome of those events, it's not exactly redundant
is there? both branches end up with the attempt being acknowledged, sorry I can't tell if I'm missing something else here.
There's a bit of logic that will be run when removing this check. So no, not redundant.
You can use the @code tag instead, same for the other method
Don't mix nullable annotations, keep using javax if you don't want to clean things
Is your feature request related to a problem?
Hi! I've been developing some custom mobs for my server, like an ice Skeleton mounted on a Phantom, a Honey Zombie on a Bee, an armored Skeleton on a Ghast, etc...
I started my server on 1.19.2, and these mobs worked perfectly. However, when updating to 1.21 I encountered this weird bug that NO ONE is talking about nor trying to fix.
https://bugs.mojang.com/browse/MC/issues/MC-262182
Since 1.19.4, ANY mob with passengers on it doesn't do ANYTHING. Examples of this: A mob mounted on a Creeper, the Creeper loses ALL its AI, so it doesn't try to explode. A Skeleton mounted on a Phantom, the Skeleton works and shoots the player, but the Phantom doesn't fly. A Skeleton mounted on a Blaze, the Blaze doesn't fire fireballs. A Ghast with a passenger attacks, but it doesn't move at all.
The list goes on, explained more in detail in the bug report. The mounted mob loses all its AI and it's overriden by its passenger. I really need to find...
Ok i modify the filter based in the logic of fire method in NMS for pass in events the empty blocks used for that, the other option its just remove the filter and pass the whole blocks in the explosion and user can manage the whole explode expansion.
Expected behavior
Entity passengers riding a player should move with the player.
Observed behaviour on Spigot:
https://github.com/user-attachments/assets/cf5e013f-3314-4d98-a8af-1652a64bc2e0
Observed/Actual behavior
Entities are not attached to the player and do not ride them at all, if the player moves the entity is left behind
Observer behaviour on Paper:
https://github.com/user-attachments/assets/5f8d59a2-6d96-4f3c-b30c-97b7b7e7b84e
Steps/models to reproduce
Basic code to reproduce:
Bee bee = (Bee) player.getWorld().spawnEntity(player.getLocation(), EntityType.BEE);
bee.setAI(false);
player.addPassenger(bee);
Plugin and Datapack List
[22:26:59 INFO]: โน Server Plugins (2):
[22:26:59 INFO]: Bukkit Plugins:
[22:26:59 INFO]: - LuckPerms, TARDIS
[22:27:26 INFO]: There are 4 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [file/tardis (world)], [paper (built-in)]
Paper version
version
[22:20:54 INFO]: Checking versio...
It's more of a small jitter of the minecart than rubberbanding, but can confirm
Is your feature request related to a problem?
At the moment the WorldGameRuleChangeEvent provides the new game rule value as a string instead of the real object which requirtes you to parse the value yourself
Describe the solution you'd like.
Either pass the object itself or make the event generic so the GameRule type matches the value
Describe alternatives you've considered.
parsing the value myself
Other
the class as reference
Discussion Category: Ideas
Is your feature request related to a problem?
This patch is interesting, because it came in 1.21.4 right before mojang made remote matching a complete mess in 1.21.5, did you know it was about to happen? Also, would enabling this flag have any side effects like clients being able to merge an item with nbt with a non nbt item? or is it just for synchronization
Describe the solution you'd like.
a
Describe alternatives you've considered.
a
Other
No response
Discussion Category: Ideas
It's mainly for things like ViaVersion and Geyser that may not (easily) be able to calculate or translate item hashes between versions or platforms - I added it after seeing and having to work with the changes from 1.21.5-pre1... that said, the config option is sort of broken at the moment
Discussion Category: Ideas
Why is this a feature?
Merger can fix it hopefully :sweat_smile: or nonswag gets to it.
Why is this a feature?
I added a description
Merger can fix it hopefully ๐ or nonswag gets to it.
the var thing? i already "fixed" that
Your changes to mojang internals are in feature patches instead of the per-file patches.
Agree with lulu, the event is in a bit of a weird place there but yea, w/e, not part of this PR.
Fix some entity components: horse/variant and tropical_fish/pattern
Expected behavior
HIDE_ADDITIONAL_TOOLTIP should hide "Applies to: armor" etc on smithing templates like it did in 1.21.4
Observed/Actual behavior
in 1.21.5 it doesn't hide the tooltip
Steps/models to reproduce
create smithing template item and add flag HIDE_ADDITIONAL_TOOLTIP
Plugin and Datapack List
N/A
Paper version
9cddf136d78aa9293b3a7fbc426922785a42bfa8 1.21.5 (latest)
Other
No response
I feel this things can be moved to the CraftBukkit side
The hide_additional_tooltip component was removed in 1.21.5 in favour of the tooltip_display component.
As noted in the Javadoc for HIDE_ADDITIONAL_TOOLTIP, you should use the data component API instead.
This should works like the getter/setter in CraftWorld
The
hide_additional_tooltipcomponent was removed in 1.21.5 in favour of thetooltip_displaycomponent. As noted in the Javadoc for HIDE_ADDITIONAL_TOOLTIP, you should use the data component API instead.
What would the code be to hide smithing template then? Thank you
Would PlayerPickItemEvent listeners still be called if the exact event isn't called anymore?
To answer my own question, yes the event is still called
I made the PlayerPickItemEvent abstract, would that cause issues with plugins that listen to the event?
I am not sure if that would cause an IncompatibleClassChangeError
It appears that Mojang does not currently provide a way to hide the additional tooltip on smithing templates and disc fragments.
Yep there is currently no way to hide those lore.
It appears that Mojang does not currently provide a way to hide the additional tooltip on smithing templates and disc fragments without hiding the entire tooltip.
How can I hide the entire tooltip? I don't want to see the "applies to" stuff, its very ugly, also what did they change in 1.21.5 that breaks this?
It appears that Mojang does not currently provide a way to hide the additional tooltip on smithing templates and disc fragments without hiding the entire tooltip.
How can I hide the entire tooltip? I don't want to see the "applies to" stuff, its very ugly, also what did they change in 1.21.5 that breaks this?
Because I remember a similar thing happening to item flags in 1.20.5 where HIDE_ATTRIBUTES broke and I was told its impossible to hide attributes, even though it was, you just needed to explicitly set the default attributes.
How can I hide the entire tooltip? I don't want to see the "applies to" stuff, its very ugly
Hiding the entire tooltip means there will be no tooltip at all, including the item name, which is presumably not what you want.
If you want to try it, you can do it like this:
stack.setData(
DataComponentTypes.TOOLTIP_DISPLAY,
TooltipDisplay.tooltipDisplay()
.hideTooltip(true)
.build()
);
What did they change in 1.21.5 that breaks this?
They removed the hide_additional_tooltip component. It used to be checked before ItemStack#appendHoverText() was called.
That method is no longer used, except for in SmithingTemplateItem and DiscFragmentItem, so the additional tooltip will always show up for those two items.
How can I hide the entire tooltip? I don't want to see the "applies to" stuff, its very ugly
Hiding the entire tooltip means there will be no tooltip at all, including the item name, which is presumably not what you want. If you want to try it, you can do it like this:
stack.setData(
DataComponentTypes.TOOLTIP_DISPLAY,
TooltipDisplay.tooltipDisplay()
.hideTooltip(true)
.build()
);What did they change in 1.21.5 that breaks this?
They removed the
hide_additional_tooltipcomponent. It used to be checked beforeItemStack#appendHoverText()was called. That method is no longer used, except for inSmithingTemplateItemandDiscFragmentItem, so the additional tooltip will always show up for those two items.
Silly mojang ๐ญ
in which case would setNewState actually work? most changes there will just cause it to try and switch back to the previous state as not all the criteria are met