#paper

1 messages ยท Page 18 of 1

rustic folioBOT
rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] New branch created: fix/air-item-drop
#

This allows command frameworks that insert CommandNodes directly into the Brigadier dispatcher to change the permission String of the VanillaCommandNodes created for their commands, rather than it always being the default "minecraft.commands.<name>".

The issue that if at any point Bukkit#dispatchCommand is reimplemented, wouldnt the above change kinda be invalidated? I find it very likely that bukkit dispatcher will be ripped out at one point or another, so I don't think this will have any effect command execution wise?

rustic folioBOT
#

d0d0efe Partially revert 083c083188 for Transformation ... - Machine-Maker
b8a0541 Fix 0 parameter in Player#applyMending (#11802) - lynxplay
9e2d39c Fix double chest identification (#11812) - Lulu13022002
321d17c [ci skip] Only build PRs on correct label (#11811) - lynxplay
d568e17 Port basic lookAt methods from Player to Entity... - Doc94
25cc3d8 Fix EnchantmentView#setOffers length preconditi... - Warriorrrr
763b32d Fix framed maps looping through all players in ... - Warriorrrr
946314f Remove disableTeleportationSuffocationCheck con... - Lulu13022002
140577b Fix broken field rename compat for instrument "... - Lulu13022002

#

What was the original issue with a randomly boolean parameter instead?

Too many overloads for a single method, I guess.
But yeah, here is my plan to reduce methods (once again):

  • Remove the non-entityOperation overloads (api users can just pass null)
  • Instead of the ...Randomly methods, let's just add a boolean dropRandomly parameter back in and explain in the JD what it does (again)

That should cut it down to like a quarter of the methods. And that's gonna be it.

rustic folioBOT
#

Expected behavior

Recipes should make what they are coded for on Bedrock (iOS in this case). The bundle recipe is simply string and leather. Having those ingredients normally unlocks the recipe and then allows you to make it.

Observed/Actual behavior

In the Java client (MacOS desktop) everything appears to be working as expected. Sting and Leather make a brown bundle and then adding die to the brown bundle or for that matter and other color bundle will change the color as expected. Using a Bedrock client, all bundle recipes show changing its color from another single other color. There is no recipe to create a simple brown bundle to start. Interestingly the Shulker Shell recipe is a String and a piece of Leather. There is no Shulker Shell in the Java version; only a Shulker Box. I don't believe there is a recipe for the shell; it's only a dropped mob item from a Shulker. I can't remove the Shulker Shell recipe as an op, so something is mixed up. Of course a Shu...

rustic folioBOT
#

Indeed, if CommandMap is ever removed, then BukkitBrigForwardingMap would not need to exist, and nothing would use the new CommandNode.wrappedBukkitCommandCached field added by this PR.

This PR only fixes CommandMap behavior, which is currently used by Bukkit#dispatchCommand. The current API is a bit broken in this edge case, and this PR fixes that bug. I don't expect CommandMap is going to be removed immediately, so I think it is a good idea to merge this PR. Since the change is so small, it will be obvious how to undo the changes from here when the time comes, so I don't think there is any downside to merging this PR.

But yeah, again, if we just want to fix #11378 by changing the implementation of Bukkit#dispatchCommand and don't care about the map identity thing, feel free to close this PR.

#
[PaperMC/Paper] New branch created: feat/PlayerMoveEvent-Vehicle-Improvement
#

Reworked Vehicle PlayerMoveEvent Handling

The PlayerMoveEvent is triggered whenever a player controls a vehicle.
This event is generally broken, and does not represent what is actually happen. For example, the event used the player's location as the "from" position and the vehicle's location as the "to" position. This caused significant issues and confusion:

  • Teleporting the player from within this event was undone later by a positionPassengers call, rendering setTo calls effectively useless.
  • Cancelling the event led to desyncs and odd behavior, such as the player being rapidly teleported between two locations.
  • The event was not giving a straightforward way to control the actual movement of the player on a vehicle.

Fixes:
PaperMC/Paper#8214
PaperMC/Paper#7021

In order to best clean up the event logic, the solution is to center the event around the vehicle rather than the player.


Key Changes

  1. Player Remains Untouched
    ...
rustic folioBOT
#
[PaperMC/Paper] branch deleted: feature/RegistryValue
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

I think a PlayerSteerMountEvent would cover more cases
the event could be called for any entity the player is riding steerable or not
it could provide the exact inputs (jump left right forward backward and maybe dismount?)
and also provide the from and to location and even the applied vector
this wouldn't restrict the even to only movements but every steering input
in case the ridden entity is not steerable by the player the even could just be cancelled by default and/or not provide from and to

One case I didn't think about in advance that came to mind while writing this are pigs and striders
they are controlled by the players held item and therefore this event would not represent the movement properly

rustic folioBOT
#

The problem with vehicle movement is that there are a lot of overarching concepts which look similar but are entirely different, there were discussions over input events in the past, and there was no viable workable solution that I could see for providing events which are actually useful to devs within the context of the discussions they had (i.e. overriding the entities move controller)

rustic folioBOT
#

Expected behavior

In vanilla a rolled up (scared due to a zombie being nearby) Armadillo would be shown taking damage while standing on a campfire, though it physically takes 0 damage.

Observed/Actual behavior

The rolled up armadillo isn't shown to take any damage from the campfire.

Likely due to it technically taking 0 damage, therefore the animation or whatever is being skipped.

Steps/models to reproduce

Armadillo on a regular campfire, in a 1x1, a zombie within a couple of blocks for the armadillo to roll up.

Image

Plugin and Datapack List

Image

Image

Paper version

This server is running Paper version 1.21.4-12-master@c17ef64 (2024-12-08T22:42:46Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)...

#

Adds the EntityPotionTickEvent.

This event is triggered on each tick of the potion effect (e.g. every 25 ticks for Poison level 1), and if the event is cancelled, the potion effect will not be applied to the entity.

I have been using it in my personal fork for the past year, mainly to add additional effects on each tick of a potion effect.

rustic folioBOT
#

Expected behavior

Launching a projectile on snow should trigger the event ProjectileHitEvent with hitblock = the snow block

Observed/Actual behavior

Currently when you launch a projectile on a snow block (stage 1, the lowest quantity of snow) the PorjectileHitEvent is trigerred but with the hit block that is bellow the snow.

Steps/models to reproduce

create a small plugin and listen to ProjectileHitEvent and launch a projectile on a snow block (stage 1)

Plugin and Datapack List

[16:37:46 INFO]: Server Plugins (7):
[16:37:46 INFO]: Bukkit Plugins:
[16:37:46 INFO]: - ExecutableBlocks, ExecutableEvents, ExecutableItems, MyFurniture, PlaceholderAPI, SCore, Vault

Paper version

[16:38:00 INFO]: This server is running Paper version 1.21.4-53-main@326c687 (2024-12-27T12:59:10Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-15-bb76819 (MC: 1.21.4)

Other

https://github.com/user-attachments/assets...

rustic folioBOT
rustic folioBOT
#

To clarify, we would accept a base level of (internal) API to allow for easier custom entity or NPC creation, but properly representing all of what the "target" of this PR implies is a lot of maintenance and sort of magic, unstable API, for a use case that's pretty brittle too. Hence it doesn't really fit into our API module in its entirety. If the goal is just to spawn player entities, then the scope of the API itself should reflect that and ideally avoid the full-blown entity data generation

rustic folioBOT
#

This PR is a "copy" from a 2 years old PR in Spigot related to explosion, when this start the issue is how the gamerule for avoid mob griefing make the explosion event not being called, with recent changes now CraftBukkit pass the explosion behavior for make the user know what is the behaviour of this explosion.. with this in mind this PR takes that for well.. call the event for that also handle a issue where "explosions" created by Wind Burst call the block explosion with not data.

rustic folioBOT
rustic folioBOT
#

Being able to create basic fake entities/players without relying on a plugin would be very nice. Sometimes many features certain plugins provide are just too much for a simple use case and thus a potential waste of resources.

I don't really understand why this PR was suddenly (given the fact that most of the talking happened internally it seems to have happened out of nowhere) closed with lynxplay's comment that said "it would add a bunch of maintenance work (which is understandable) and doesn't really fit into the API" and later clarifying that a more trivial and internal api is more fitting and thus more likely to be accepted.

Especially powerful apis like this is what many people like about paper. Simple ways to create powerful plugins.

That being said I hope someone tries to add something like this in a more trivial way.

rustic folioBOT
#

We can expose powerful APIs that wrap/enable modification of the server for things like data components / registry modification without much hesitation because they are entirely new systems.

Disguising an entity as another is a terribly complex API if implemented fully. The issue of such an API in the paper repository is that, if you glanced at the required API of existing alternatives (e.g. citizens or lib disguise or whatever) people tend to do more with their disguised/npc entities than just spawning them in.
The existing types surrounding entities (org.bukkit.entity.Entity) were never designed for wrapping anything that isn't an actual entity in the world, making them a poor way to allow consumers to do such down the line changes (think, I want my phantom disguised as a shulkerbox to open up mid flight by calling Shulker#setPeek).

My only hope for something like this would be mojang moving entities into a data component setup similar to ItemStacks, which would mean ...

rustic folioBOT
#

Reopening this one, was a bit discussed internally. Relevant item in the shulker:
<details>
<summary>1.20.4 item</summary>
minecraft:written_book{pages: ['{"extra":[{"color":"gold","text":"Daily Quest Book #188:"},"\n","\n",{"extra":[{"underlined":true,"color":"#67CCE0","text":"23h, 55m"}],"text":"This book expires in: "},"\n",{"color":"gold","text":"Weekly Challenge:"},"\n","Gain 120 quest points before the end of the week to get: ",{"italic":true,"color":"aqua","hoverEvent":{"action":"show_item","contents":{"id":"minecraft:emerald","tag":"{CustomModelData:1029506977,Enchantments:[{id:\"minecraft:lure\",lvl:1s}],HideFlags:1,display:{Lore:['{\"extra\":[{\"text\":\"Swaps your hotbar\"}],\"text\":\"\"}','{\"extra\":[{\"text\":\"with the slots above.\"}],\"text\":\"\"}'],Name:'{\"extra\":[{\"bold\":false,\"italic\":false,\"underlined\":false,\"strikethrough\":false,\"obfuscated\":false,\"color\":\"#26A485\",\"text\":\"Swap Stone\"}],\...

rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] branch deleted: fix/disabling-vanilla-registry-values
#

So we decided that there should be 10 methods added here

  • dropItem(int slot, int amount)

  • dropItem(int slot, int amount, bool, consumer)

  • dropItem(EquipmentSlot slot, int amount)

  • dropItem(EquipmentSlot slot, int amount, bool, consumer)

  • dropItem(int slot)

  • dropitem(int slot, bool, consumer)

  • dropItem(EquipmentSlot slot, bool, consumer)

  • dropItem(EquipmentSlot, slot)

  • dropItem(ItemStack)

  • dropItem(ItemStack, bool, consumer)

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

The lightning is just a visual effect and doesn't interact with the world.

Observed/Actual behavior

https://www.youtube.com/watch?v=JTZpJiI-3Kc

victim.getWorld().strikeLightningEffect(victim.getLocation());

Steps/models to reproduce

Just use the method.

Plugin and Datapack List

ProtocolLib

Paper version

This server is running Paper version 1.21.4-60-main@0629524 (2024-12-28T00:13:57Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-50-a5b8df6 (MC: 1.21.4)

Other

No response

rustic folioBOT
#

Expected behavior

Image
Versions below 1.20.1 don't have this issue, but now there is a problem in versions 1.21 and above. The author said it cannot be fixed. It is suggested to turn off Paper redirection, which will likely solve the issue.

Observed/Actual behavior

no

Steps/models to reproduce

no

Plugin and Datapack List

Image

Paper version

Image

Other

No response

rustic folioBOT
#

Expected behavior

I expect calling
player.getLocation().getWorld().spawnParticle(Particle.FIREWORK, null, null, player.getX(), player.getY() + 50, player.getZ(), 1, 0,0,0, 0, null, true);
to have the same result as running
/minecraft:particle minecraft:firework ~ ~50 ~ 0 0 0 0 1 force

Observed/Actual behavior

When using the spawnParticle method the particle cannot be seen when too far away, even when setting force to true

Steps/models to reproduce

  1. Call: player.getLocation().getWorld().spawnParticle(Particle.FIREWORK, null, null, player.getX(), player.getY() + 50, player.getZ(), 1, 0,0,0, 0, null, true);
  2. See no particle.

Plugin and Datapack List

Just a test plugin.

Paper version

[15:47:51 INFO]: This server is running Paper version 1.21.4-61-main@e0abc5f (2024-12-28T14:03:42Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-15-bb76819 (MC: 1.21.4)

Other

I noticed this issue ...

#

Replaces #11690. Copied description:

This change replaces the previous approach using ASM with a simpler one only depending on MethodHandles and hidden classes.

The concept is pretty straightforward: We have a template class that contains all the logic. This class is never loaded directly, but its bytecode is used to define hidden classes. Each hidden class gets its own MethodHandle (and the other attributes needed). This way, the attributes can be static, allowing full optimization by the JVM. This is the main difference compared to the previous MethodHandle-based implementations.

The generated classes previously had the additional problem of book-keeping: The classes needed to be loaded by a class loader, and - as plugins can be unloaded - the classes also shouldn't outlive their plugin.
Hidden classes can be unloaded even if their defining class loader is still reachable, so the JVM takes care of that this way.

One difference is that previously one class was loaded p...

rustic folioBOT
#

Expected behavior

Mob#clearLootTable (or setLootTable(null)) should prevent the mob from generating and dropping loot on death

Observed/Actual behavior

The mob still generates and drops its default loot

Steps/models to reproduce

  1. spawn a mob (pig for example)
  2. invoke the Mob#clearLootTable method (or set it to null)
  3. kill the entity

Plugin and Datapack List

irrelevant

Paper version

This server is running Paper version 1.21.4-61-main@e0abc5f (2024-12-28T14:03:42Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-34-d568e17 (MC: 1.21.4)

Other

No response

rustic folioBOT
#

This is due to the way Mob#getLootTable works in internals, it defaults to the entity type's default loot table if the Mob#lootTable field is an empty optional, which is what is set by the API.

Though what you're trying to do is already possible in the API using the EntityDeathEvent, just clear the getDrops there and the entity won't drop anything

#

Yeah, I just came to the same conclusion while reading through the code.
for now, I just pass an empty loot table instance because an event isn't a solution in my case (the loot table might get overridden later in the entity's lifecycle).

Judging from the docs, it sounds like setting the loot table to null will not generate loot on death of a mob.

Image

I feel like adding a resetLootTable method would be clearer for that, while also making it possible to have no loot table at all.
Also, getting the loot table after setting it to null, on an entity that has a loot table by default, will not return null which seems wrong.

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

This is pretty much the joys of making loose promises in the API over existing implementations of behavior, if we want to enforce this API promise, most solutions here just introduce their own behavioral breakages, I think that the answer here is to just update the JDs to reflect the recentish changes and ensure that API exists for plugins to deal with whatever case they want

rustic folioBOT
#
[PaperMC/Paper] branch deleted: feature/datapack-lifecycle-event
#

Alright, thank you for the PR!
We have reviewed it but are a bit (a bit too) hesitant to call these events when their javadocs do define them to not be called in these exact spots.

We could fire them pre-cancelled, but block break related events are obviously rather important for plugin data, and I'd rather avoid plugins dying/duping because they did not correctly check cancelled here.

Instead, Machine and I think it'd be best to use this API downside to finally create a better version of the "SomethingExplodeEvent" (better name pending) that covers both entities, blocks and nothing (like in the mace's case). Such an event can be called for these cases, specifying that no blocks will be broken etc.
The current events types could then be marked as Obsolete and the new event would be called after to allow people to take priority with the new API.

If you are up for implementing such a change yourself, feel free to just use this API, otherwise we can close it and open a...

#

Stack trace

[16:31:41] [Async Tab Complete Thread - #0/ERROR]: Caught previously unhandled exception :
[16:31:41] [Async Tab Complete Thread - #0/ERROR]: Async Tab Complete Thread - #0
java.lang.IllegalArgumentException: Comparison method violates its general contract!
	at java.base/java.util.TimSort.mergeHi(TimSort.java:903) ~[?:?]
	at java.base/java.util.TimSort.mergeAt(TimSort.java:520) ~[?:?]
	at java.base/java.util.TimSort.mergeCollapse(TimSort.java:448) ~[?:?]
	at java.base/java.util.TimSort.sort(TimSort.java:245) ~[?:?]
	at java.base/java.util.Arrays.sort(Arrays.java:1308) ~[?:?]
	at java.base/java.util.ArrayList.sort(ArrayList.java:1804) ~[?:?]
	at com.mojang.brigadier.suggestion.Suggestions.create(Suggestions.java:99) ~[brigadier-1.3.10.jar:?]
	at com.mojang.brigadier.suggestion.SuggestionsBuilder.build(SuggestionsBuilder.java:51) ~[brigadier-1.3.10.jar:?]
	at com.mojang.brigadier.suggestion.SuggestionsBuilder.buildFuture(SuggestionsBuilder.java:55) ~[brigadier-1.3...
#

Adds LivingEntity#getCombatTracker to get entity's combat tracker that allows getting/setting combat history (list of damage entries during a combat session), recording new combat entries without causing actual damage, getting/resetting current combat state/session and getting a death message based on the present combat history.

FallLocation represents a location from which the entity fell, and is used by vanilla to generate fall death messages.


API implementation is basically done, but definitely open to feedback. Javadocs & namings could use some love.

rustic folioBOT
#

Expected behavior

It should return the good number of theses stats

Observed/Actual behavior

``Theses stats return 0 when I'm logging then into messages:
Image

The code :
@EventHandler public void join(PlayerJoinEvent e) { Player p = e.getPlayer(); p.sendMessage(Component.text("Test kills:" +p.getStatistic(Statistic.PLAYER_KILLS))); p.sendMessage(Component.text("Test deaths:" +p.getStatistic(Statistic.DEATHS))); }

Steps/models to reproduce

Just copy and paste my code, and you will get 0

Plugin and Datapack List

Plugin: PvPBox (my custom plugin which contains the problem, I only have this into my PlayerJoin)
Datapack : N/A, I just generated a simple Paper Server into 1.21.4 with build 63

Paper version

This server is running Paper version 1.21.4-63-main@feb8756 (2024-12-28T21:39:34Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT...

#

The join event might be too early for that data to be loaded properly. Did you try it in another event too?

I tried on AsyncChatEvent (into renderer), I have the same result :
Image

My code:

 @EventHandler
    public void onChatAsync(AsyncChatEvent e) {

        e.renderer((player, sourceDisplayName, message, viewer) -> {

            Bukkit.broadcast(text("Test kills:" +player.getStatistic(Statistic.PLAYER_KILLS)));
            Bukkit.broadcast(text("Test deaths:" +player.getStatistic(Statistic.DEATHS)));
 
            return text(player.getName()+":   ").append(message.color(WHITE));
        });
    }
rustic folioBOT
rustic folioBOT
#

Expected behavior

Maps should not be ignored from updates after the initial call to render().

Observed/Actual behavior

Maps do not render unless you rejoin

Steps/models to reproduce

This GitHub issue is the whole conversation between me and the developer of ImageMaps. He even provides a way to reproduce the issue: https://github.com/SydMontague/ImageMaps/issues/70

Plugin and Datapack List

Not really relevant, all you technically need is the ImageMaps plugin or the code they provided in the issue I linked above.

Paper version

[Sun 01:47:38 INFO ] Checking version, please wait...
[Sun 01:47:38 INFO ] This server is running Paper version 1.21.4-65-main@287eb52 (2024-12-28T23:19:11Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-53-326c687 (MC: 1.21.4)

Other

No response

#

Back in https://github.com/PaperMC/Paper/pull/8812 I added support for detecting if the end user is using Velocity over Bungeecord for the offline mode warning.

This expands upon that and will swap up the message whenever they're using Velocity in online mode. It's still enough of a message to let people know but without being a complete nag.

It'll also make it, so people are less confused when they see the message in server logs in the paper-help channel.

Definitely open to different wording on the message. I'm not really good at Englishing properly some days.

#
[PaperMC/Paper] New branch created: chore/checkstyle
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

The description says ingition but it should be ignition
https://jd.papermc.io/paper/1.21.4/org/bukkit/attribute/Attribute.html#BURNING_TIME
Image

Observed/Actual behavior

Spelling mistake. It says ingition

Steps/models to reproduce

Open javadocs or sourcecode or whatever and look at the description of org.bukkit.attribute.Attributr.GENERIC_BURNING_TIME

Plugin and Datapack List

N/A

Paper version

paper-api:1.21.4-R0.1-SNAPSHOT

Other

No response

rustic folioBOT
rustic folioBOT
#

The updates are ignored after the first call to render().

A simple MapRenderer with this code was able to reproduce the problem for me:

    @Override
    public void render(MapView view, MapCanvas canvas, Player player) {
        BufferedImage image = new BufferedImage(128, 128, BufferedImage.TYPE_INT_RGB);
        Graphics g = image.getGraphics();
        g.setColor(new Color((int) (Math.random() * 255)));
        g.fillRect(0, 0, 128, 128);
        canvas.drawImage(0, 0, image);
    }```

The maps should cycle between colors constantly, but they remain static. This does work as expected on Spigot.
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

I did a PR once on CraftBukkit that did a big overhaul to the teleport methods, using Minecraft's logic.
I did this because Minecraft now supports TP with passengers via the TP command.
Unfortunately a few people over there felt that my PR took away the "old behaviours" of the Bukkit that people were used to.
OH NO... how dare I ๐Ÿ˜†

So my goal for this PR was just to fix the bug.
I'm no pro when it comes to the NMS stuff like some of you guys are, so I didnt want to take on such a huge task, I just wanted to do a simple fix.

If another PR has a greater chance of making this so much better, I'm ok with this being closed and let someone else handle it.

That said I would be nice to fix the bug for the time being.

#

I did a PR once on CraftBukkit that did a big overhaul to the teleport methods, using Minecraft's logic.
I did this because Minecraft now supports TP with passengers via the TP command.
Unfortunately a few people over there felt that my PR took away the "old behaviours" of the Bukkit that people were used to.
OH NO... how dare I ๐Ÿ˜†

So my goal for this PR was just to fix the bug.
I'm no pro when it comes to the NMS stuff like some of you guys are, so I didnt want to take on such a huge task, I just wanted to do a simple fix.

If another PR has a greater chance of making this so much better, I'm ok with this being closed and let someone else handle it.

That said I would be nice to fix the bug for the time being.

rustic folioBOT
#

Is your feature request related to a problem?

While brigadier is capable of redirecting or forking a node modifying the command source via (Single)RedirectModifier, it is impossible to make use of this feature using the current command API

Describe the solution you'd like.

Expand the CommandSourceStack interface by adding wither methods:

  • CommandSourceStack withExecutor(Entity executingEntity)
  • CommandSourceStack withLocation(Location location) (atLocation?)
  • For the sake of completion and because Minecraft's CSS also has this method, CommandSourceStack withSender(CommandSender sender), but I'm not really sure how to feel about this, it's one to discuss: do we want to retain the original sender or be able to change it? We can also do both by exposing an additional originalSender method as well, or simply not add such method today but can be revisited in the future

This would allow for plugins to use the forwarding mechanisms of brigadier and better integrate...

#

Maybe it would also be possible for plugins to store their own data in CSS? Same way vanilla stores there the executor and location, which it can change. CSS is a short living object that dies anyway when command finished executing, so don't think it'll be a big issue if plugin objects would be stored in that nms class

There are already numerous utilities for storing data and for a short lived object like this it probably isn't necessary at all anyways.

#

Expected behavior

The expected behavior is that player skulls load correctly, even when the player is offline, displaying the correct texture or appearance as they do in Spigot.

Observed/Actual behavior

The player skulls do not load when the player is offline, showing either a blank texture or failing to appear altogether.

Steps/models to reproduce

  1. Set up a PaperMC server with the latest version.
  2. Ensure a player has placed a skull (player head) of another player on the server.
  3. Make sure the player whose skull is being used is offline.
  4. Attempt to display the skull.
  5. Observe that the skull either appears blank or does not load at all.
  6. Repeat the test on a Spigot server, where the skull loads correctly.

Plugin and Datapack List

none

Paper version

This server is running Paper version 1.21.4-66-main@d00344a (2024-12-29T14:59:35Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)\nYou are running the latest version\nPrevious version: 1.21.4-60-0...

#

There are already numerous utilities for storing data and for a short lived object like this it probably isn't necessary at all anyways.

There is no reliable way. Ofc we can use something like WeakHashMap but then if something uses the new with* methods and creates a new one and propagate further that one, your data is lost. A lot easier it would be to store the data in the object itself which would be propagated to the execution and then would die easily

#

This is probably related to the issue with MTVehicles here https://github.com/MTVehicles/MinetopiaVehicles

The plugin was working fine in 1.21.1 and now in 1.21.3 or 1.21.4 the movement of the armorstand and tool is not tracking correctly .I can not see what was changed, maybe undocumented .

The vehicle textures are layed on top of the armorstand holding a damaged pickaxe . The location and axis are read and moved around the map with key presses or just W key and look steering (mouse polling). The vehicle can still move by the keys and mouse, but only when hitting other keys (spamming the keys) .Paper is slowing input to the Keys and mouse . The source for the plugin is above . You will see it works well in 1.21.1 and not in versions above . Viaversion is affected in the same way when on 1.21.1 and clients for 1.21.3 or 1.21.4 try to use the plugin. Maybe you still have not applied some patch yet, which is why i can not find documentation yet

rustic folioBOT
#

@Tsoccerguy3 This patch was not merged to Paper yet, and the bug that causes this issue is in vanilla Minecraft for years already, so it is probably something else.


About the patch itself: I haven't edited it yet to add the Mojira link because I forgot, and because I was still trying to figure out if there's any issues with this solution because it wasn't battle tested.

(I'm not running this patch in production because my issues were solved by using packets for anything that required teleport interpolation, and using the display entity transformation matrix for any display entities that do not actually need to be teleported on the server itself)

rustic folioBOT
#

The coder already recognized the problem, the new method when a button is pressed is only saved as a boolean, which only goes to true when the button is pressed again. Before, we used to get a float which showed us how far the key was pressed, so we could ensure continuous movement.
Dont know if this is even fixable going forward.

rustic folioBOT
rustic folioBOT
#

I noticed that on my servers too
I think that happened from 1.20.4 to .6
Personally I fixed that by completing the profile and then applying the player profile to the skull
I believed that was just the new profile component requiring the entire data to properly display the head
That also happened to placed heads in the world but you guys fixed that (don't exactly remember how tho)

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

fixes #11866

The following methods have been added:

  • CommandSourceStack#withExecutor(@Nullable Entity)
  • CommandSourceStack#withLocation(Location location)

JavaDocs hasn't been added yet, but that is something I will be doing very soon.

Testing the code can be done via the following:

this.getLifecycleManager().registerEventHandler(LifecycleEvents.COMMANDS, event -> {
    final LiteralCommandNode<CommandSourceStack> node = Commands.literal("test")
        .then(Commands.literal("run")
            .executes(ctx -> {
                Bukkit.broadcast(MiniMessage.miniMessage().deserialize("<name>: I am at <x> <y> <z>",
                    Placeholder.component("name", ctx.getSource().getExecutor().name()),
                    Placeholder.unparsed("x", String.valueOf(ctx.getSource().getLocation().x())),
                    Placeholder.unparsed("y", String.valueOf(ctx.getSource().getLocation().y())),
                    Placeholder.unparsed("z", String.va...
rustic folioBOT
#

Is your feature request related to a problem?

It's more for PvP servers where picking up items / EXP is more crucial and should be able to be a random system instead of based on who joined first

Describe the solution you'd like.

Minecraft has a "player priority" system when choosing who picks up items / EXP if there's multiple players around. And the priority is based on who logged in first. I think a config option in paper to set the priority system to either "DEFAULT" (no change) or "RANDOM" would be coo. Where "RANDOM" chooses a random player to pick up the items / EXP if both are around the items instead of who logged in first

Describe alternatives you've considered.

I've tried plugins that cancel the pick up completely and delegate the items, but it comes with further glitches doing that that is not ideal. Would be better if paper could do it on their end

Other

No response

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

Expected behavior

When running new ItemStack(Material.BARRIER) in code in a JUnit test it will not throw an error: java.lang.IllegalArgumentException: BARRIER isn't an item

Observed/Actual behavior

Hi - I'm in the process of shifting BentoBox to PaperAPI fully and trying to get all the JUnit tests to run.

One of the issues I'm hitting is with this code: new ItemStack(Material.BARRIER) where, when run, will throw an error in the JUnit test: java.lang.IllegalArgumentException: BARRIER isn't an item. Barrier is just an example - it happens when trying to create any ItemStack with any Material.

This is thrown by a check that is done in ItemStack.java:
Preconditions.checkArgument(type.asItemType() != null, type + " isn't an item");

Indeed, if I put debug code before the new ItemStack is created:
System.out.println(Material.BARRIER.isItem()); it returns false, so I'm not surprised that this is being thrown.

Stack trace of error:

java.lang.IllegalArgume...
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

I have an oldest plugin who's really big (+130 classes) since 2016. I'm working on an update to Paper 1.21.4.

I started to update my plugin to latest Paper features (paper-plugin.yml, Brigadier commands, etc.)

On typping /version PvPBox, it should return the version with the ${git.commit.id.describe-short}. Since I migrated to paper-plugin.yml, it don't work.

Observed/Actual behavior

It shows the name of the variable instead of my version.
Image

Steps/models to reproduce

  1. Create a paper-plugin.yml (very basic : package.Main class, Name, author, version, api-version)
  2. On your pom.xml, add into <builds> the plugin git-commit-id-maven-plugin (version 9.0.1).
  3. Into <version> set it to <version>3.0.0 (${git.commit.id.describe-short})</version>
  4. Set this into your paper-plugin.yml : version: ${project.version}

Plugin and Datapack List

No datapa...

rustic folioBOT
rustic folioBOT
#

Expected behavior

it has to return damager's holding

Observed/Actual behavior

When an EntityDamageByEntityEvent occurs, getActiveItem always returns AIR (empty-handed)

Steps/models to reproduce

this is my plugin source
@EventHandler
public void onEntityDamage(EntityDamageByEntityEvent event) {
if (event.getDamager() instanceof Player) {
Player player = (Player) event.getDamager();
ItemStack activeItem = player.getActiveItem();

        if (activeItem.getType() == Material.AIR) {
            player.sendMessage("You are attacking with an empty hand!");
        } else {
            player.sendMessage("You are attacking with a " + activeItem.getType().name());
        }
    }
}

Plugin and Datapack List

just my plugin only(that has no function)

Paper version

This server is running Paper version 1.21.4-69-main@bdfad1c (2025-01-01T00:57:45Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are r...

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

That there are no errors when we whitelist a player.

Observed/Actual behavior

I've just created my server with the latest version of Paper at 1.21.4, and when I tried to whitelist to the server, I noticed that I had some big errors in the console.
Logs: https://mclo.gs/6b4Og6k

Steps/models to reproduce

  1. Use the latest devbuilds of Paper 1.21.4.
  2. Whitelist a players
  3. See the errors

Plugin and Datapack List

Paper version

This server is running Paper version 1.21.4-69-main@bdfad1c (2025-01-01T00:57:45Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)

Other

No response

#

Expected behavior

The whitelist state should be updated in server.properties.

Observed/Actual behavior

The whitelist state is not updated in server.properties.

Steps/models to reproduce

  • Toggle whitelist by either using the in-game vanilla command (or using the Server::setWhitelist method)
  • Close the server
  • Start the server
  • Observe that the whitelist state has been reset by using the same command. The command would fail if the provided state is the one that is already set.

Plugin and Datapack List

I made a simple plugin to print the status of the whitelist, though the bug is present without plugins and datapacks.

Paper version

This server is running Paper version 1.21.4-69-main@bdfad1c (2025-01-01T00:57:45Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-66-d00344a (MC: 1.21.4)

Other

In addition to not storing the value in server.properties, the Server::hasWhitelist continues to yie...

rustic folioBOT
rustic folioBOT
#

Stack trace

A problem occurred configuring root project 'paper'.
> Could not resolve all artifacts for configuration ':classpath'.
   > Could not resolve io.papermc.paperweight:paperweight-core:2.0.0-beta.10.
     Required by:
         root project : > io.papermc.paperweight.core:io.papermc.paperweight.core.gradle.plugin:2.0.0-beta.10
      > No matching variant of io.papermc.paperweight:paperweight-core:2.0.0-beta.10 was found. The consumer was configured to find a library for use during runtime, compatible with Java 21, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.10' but:
          - Variant 'javadocElements' declares a component for use during runtime, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything abo...
#

Expected behavior

When rendering a small image using the MapCanvas#drawImage, it correctly draws the image, like shown in the image (all textures are drawn as seperate small images) (Paper 1.21.1):
Image

Observed/Actual behavior

The images do not render correctly, instead they render the top row multiple times, and fail to render transparancy correctly (Paper 1.21.4 latest):
Image

Steps/models to reproduce

Try to render a small (< 128px) image on a map canvas(renders weirdly), or render any image with an x offset to repeat the top pixel row.

Plugin and Datapack List

Tested on a clean installed paper server with only my plugin.

Paper version

This server is running Paper version 1.21.4-69-main@bdfad1c (2025-01-01T00:57:45Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are 1 version(...

rustic folioBOT
#
[PaperMC/Paper] New branch created: conf/shared-random
rustic folioBOT
rustic folioBOT
#

It actually is safe to pass null, since executors are actually nullable (mainly when executed as the console). It seems that internally, the method is not annotated as such, but judging from the implementation, it is only setting the executor field of CommandSourceStack, which may be null

passing null will cause a NPE, n.m.c.CSS#withEntity calls getName and getDisplayName on the passed entity

rustic folioBOT
rustic folioBOT
#

Because it isn't required to construct a CSS initially, think console
commands

On Wed, 1 Jan 2025, 22:19 Strokkur24, @.***> wrote:

@.**** commented on this pull request.

In
paper-server/src/main/java/io/papermc/paper/command/brigadier/PaperCommandSourceStack.java
https://github.com/PaperMC/Paper/pull/11868#discussion_r1900491346:

@@ -40,6 +42,12 @@ default Entity getExecutor() {
return nmsEntity.getBukkitEntity();
}

  • @Override
  • @NonNull
  • default CommandSourceStack @.*** Entity executor) {

In that case, how is it possible that the Bukkit CSS has their withEntity
nullable?

โ€”
Reply to this email directly, view it on GitHub
https://github.com/PaperMC/Paper/pull/11868#discussion_r1900491346, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIPXWBBRC6XMPIP6OQEQY5L2ISH3NAVCNFSM6AAAAABUMCAM3OVHI2DSMVQWIX3LMV43YUDVNRWFEZL...

rustic folioBOT
rustic folioBOT
#

Expected behavior

When an entity is ~50 blocks away, they should immediately drop when the floor is moved under them via a piston.

Observed/Actual behavior

When an entity is ~50 blocks away, there is a significant delay (several seconds) before they fall from gravity via a piston.

Steps/models to reproduce

https://github.com/user-attachments/assets/d0bc15b7-2657-4952-b193-7ad4489e3b2b

Plugin and Datapack List

Plugins:
-RHLeafDecay
-TabTPS

Datapacks:
-Vanilla
-file/bukkit
-paper

Paper version

This server is running Paper version 1.21.4-71-main@83995d7e (2025-01-01T21:03:20Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version

Other

-Sim Distance: 10
-Render Distance: 20

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

i have no plugins but same type of error

---- Minecraft Crash Report ----
// Surprise! Haha. Well, this is awkward.

Time: 2025-01-02 09:24:39
Description: Exception in server tick loop

java.lang.IllegalStateException: Failed to bind to port
	at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:271)
	at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1163)
	at net.minecraft.server.MinecraftServer.lambda$spin$2(MinecraftServer.java:310)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.net.BindException: Cannot assign requested address: bind
	at java.base/sun.nio.ch.Net.bind0(Native Method)
	at java.base/sun.nio.ch.Net.bind(Net.java:565)
	at java.base/sun.nio.ch.ServerSocketChannelImpl.netBind(ServerSocketChannelImpl.java:344)
	at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:301)
	at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:141)
	at i...
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

https://github.com/PaperMC/Paper/blob/daddcf67420e92ce1eba27949f3c847a92ffab14/paper-server/patches/sources/net/minecraft/server/network/ServerGamePacketListenerImpl.java.patch#L179

this kinda confused me until i realized its paper logic bug.

 } else if (!this.updateAwaitingTeleport() && this.player.hasClientLoaded()) {
            Entity rootVehicle = this.player.getRootVehicle();
            // Paper start - Don't allow vehicle movement from players while teleporting
            if (this.awaitingPositionFromClient != null || this.player.isImmobile() || rootVehicle.isRemoved()) { // ensuring awaitingPositionFromClient is null
                return;
            }
            // Paper end - Don't allow vehicle movement from players while teleporting

as you can see we are ensuring awaitingPositionFromClient is null, but it was already just checked inside this.updateAwaitingTeleport(), which will only return False if awaitingPositionFromClient is...

rustic folioBOT
rustic folioBOT
#

This change has the unfortunate side effect of potentially breaking existing cooldown state on the client.
We do not have the ability to tell a client to start a cooldown in the past, so the only thing we can really do here is resend the current cooldown as a new cooldown, which will be visually different but better than completely dropping an existing cooldown and not noticable if all cooldowns are cancelled.

rustic folioBOT
rustic folioBOT
#

This pull request addresses #11821

Previously after the enchantment event took place bukkit would clear out all empty enchantments and send a completely empty offer list to the client. Minecraft handles this differently by default by still sending a cost to the client so the slots illuminate as seen in the attached issue.

This pull request attempts to address this issue by not setting back enchantment offer cost to 0 after PrepareItemEnchantEvent. This keeps the original price that was generated through the loop earlier within the slotsChanged method.

As far as drawbacks go for this fix after looking into this it would largely be thinking about how things are handled event side, because something would need to be done. If a developer wants to null out a spot how do we address this while maintaining vanilla behavior when an item may have no offers available? Or should vanilla behavior be kept to start with?

For reference when blanking out all 3 offers an enchanment table ...

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

In versions prior to 1.21.2, you could set the loot table to LootTables.EMPTY to create a mob that drops nothing. This loot table has been removed from Minecraft and Bukkit/Paper in 1.21.2.
You can still summon a mob that doesn't drop loot by specifying an invalid loot table like /summon sheep ~ ~ ~ {DeathLootTable:""}. You can't do this with Paper because, as far as I know, Paper only allows you to select from existing loot tables. So you would have to create a datapack containing an empty loot table, which could then be selected by your plugin to create such a mob.

It would be best if Paper could restore the lost LootTables.EMPTY functionality with a built-in datapack which provides an empty loot table. This way, you could also access it with commands like /summon sheep ~ ~ ~ {DeathLootTable:"paper:empty"} or something like that.

rustic folioBOT
#

Just to make sure I recall the previous design correctly, the idea was that the builder itself contained executing methods and allowed configuration of starting position and direction vector right?

I still do not believe it is a good design choice to have execution methods on the builder/executor type itself, specifically when it itself just calls back to the world. We could however move starting position and direction vector onto the builder too (e.g. in the factory method) and then also expose a wither method on the configuration itself so people can easily update it?

E.g.

final var config = RayTraceConfiguration.builder()
  .direction(dir).origin(pos)
  .target(BLOCKS);
world.rayTrace(config);
world.rayTrace(config.relocate(pos, dir));

Just an idea tho, would love your input on that.

#

We could however move starting position and direction vector onto the builder too (e.g. in the factory method) and then also expose a wither method on the configuration itself so people can easily update it?

Doesn't that just defeat the purpose of having an immutable configuration?

Unrelated I just think that having a configuration for this just doesn't really work out. The adventure JoinConfiguration (which was used as an example in previous discussions) only defines a format. though here we would basically be defining the values in the configuration. (can't really find a better analogy)

Might be worth having some more people in the community give feedback on what they prefer as i am sure that personal preference is playing a big part here.

rustic folioBOT
#

Well that was your issue in the last comment on the pre-hardfork PR tho right?
The fact that consumers need to pass location and direction on each invocation.

The configuration would still be immutable, consumers that ray trace the exact same configuration would be fine and consumers that ray trace the exact "configuration" but from a different location/direction would only have the performance downsides of a single record copy.

This problem however isn't even solved with the previous approach discussed.
The only difference being that the previous approach was completely mutable and took over the responsibility of casting a ray. But yea I agree, more input is definitely needed.

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

When looking at an entity and writing the /data command, the UUID of the entity is available as a command suggestion

Observed/Actual behavior

No entity UUID appears in the command suggestions

Steps/models to reproduce

Look at an entity and type /data get entity. There should be a UUID in the command suggestions

Plugin and Datapack List

No plugins or data packs

Paper version

This server is running Paper version 1.21.4-72-main@daddcf6 (2025-01-02T08:17:56Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version

Other

No response

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

It's not so much "typos" as it's just hunks that applied successfully but the names of local variables changed which changed some functionality. The diff between this and pre-hard fork is way too littered with all the other renaming/decompiler changes. Our tooling also changes the local variable names to much nicer names (in some cases) which renames all the other local variables as well. So it's just a matter of identifying those cases. We did several pass throughs of the whole diff right after, and found a bunch.

rustic folioBOT
#

How about just add this to the LootTable interface?

public static LootTable EMPTY = new LootTable() {

        @Override
        public @NotNull NamespacedKey getKey() {
            return new NamespacedKey("paper", "empty_loot_table");
        }

        @Override
        public @NotNull Collection<ItemStack> populateLoot(@Nullable final Random random, @NotNull final LootContext context) {
            return List.of();
        }

        @Override
        public void fillInventory(@NotNull final Inventory inventory, @Nullable final Random random, @NotNull final LootContext context) {

        }
    };

not fully like but not sure if just try to add in registry and empty work... NMS have a empty but its not registered then cannot be called in API unless mess with server side for make a thing like getEmptyLootTable for call this but the Craft implementation expect a loottable with key...

rustic folioBOT
#

This PR is refer a issue mentioned in Discord where a item with a sound event in the instrument component throw a convert issue when call getItemMeta.
in a few tests i come to the CraftMusicInstrument and notice the use of a deprecate registry thing i change this and works but not really sure if this is the correct fix.. mostly the issue is ItemMeta and the expected things...

#

Expected behavior

Up to release 1.21.3, we were able to retrieve the PDC data of a custom goat horn which doesn't use a standard instrument (see below to reproduce).

Trying to retrieve the value using that code :
event.getItem().getItemMeta().getPersistentDataContainer().has(new NamespacedKey(myplugin, "customhorn")

should get me "filename.mp3" (where "event" is "PlayerInteractEvent")

Observed/Actual behavior

Now, doing the same code with 1.21.4 end with an error :
java.lang.IllegalArgumentException: Cannot convert direct holder to bukkit representation

Steps/models to reproduce

Give yourself a modified goat horn with a custom instrument (using a vanilla sound_event) + some custom_data (which will reflect the PDC creation) :

/give @a goat_horn[instrument={use_duration:10,range:100,sound_event:"minecraft:intentionally_empty"},custom_data={PublicBukkitValues:{"myplugin:customhorn":"filename.mp3"}]

If you try to retrieve the custom_data "myplugin:customhorn",...

#

well actually, minecraftToBukkit and minecraftHolderToBukkit should just have the bukkit Registry parameter replaced with RegistryKey. And then all the usages should be updated. Shouldn't be passing a Registry instance anywhere, just the key, and then get the registry instance in CraftRegistry minecraftToBukkit and minecraftHolderToBukkit

hmm im lost in there xd
if you wanna handle because (maybe the time) dont fully understand the changes in the implementation

rustic folioBOT
#

Is your feature request related to a problem?

Around a decade ago the Bukkit API swapped to creating snapshots when creating BlockState objects with a raw getState() method, which was magnitudes slower than beforehand. Paper created a getState(boolean) method as a workaround, to allow plugins to opt-out of the snapshot behaviour. This is good, but many plugins don't realise and instead opt for the significantly slower snapshot variant.

Describe the solution you'd like.

Paper should change the default behaviour to not create snapshots, and instead have usecases that require snapshots go through getState(true) instead. This would make code performant by default, which fits Paper's general goals.

This change should be made across all method calls that create a BlockState instance, not just Block#getState().

Describe alternatives you've considered.

An alternative would be to deprecate the raw method entirely, so that developers are forced to confront the choice...

rustic folioBOT
rustic folioBOT
#

Generally I believe this is a really good idea, but I'm a bit worried about this being somewhat of a hidden behaviour change for the few percent of plugins that actually rely on it being a snapshot.

I do think this is fine and worth it due to the performance benefits, but the change should happen in a major release or with the first stable post-hardfork build, so that plugin developers get the chance to adapt to it and there is a clear cut between builds with and without this change.

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Every other day someone in #paper-dev tries to declare commands in paper-plugin.yml, which is not supported, but simply returns null instead of a clear error message.
This commit hopes to clarify that calling getCommand on self is not supported for paper plugins.

Note: check only applies during onEnable because we do not want to break the ability for other plugins to check if a plugin defines a command by calling JavaPlugin#getCommand on it

#

so all it seems to do is send the breaking packet to the client and removing modifiers from the itemstack (which i am not sure is necessary? considering its breaking anyways). using setDamage(reallyhighnumber) when throwing the trident without riptide it just gets stuck in the ground and can't be picked up anymore which i guess is to be expected, when using with riptide it just breaks but still gives you the boost. not sure whether disallowing breaking the trident, changing the onBreak Consumer or just leaving it as is is the best option
not allowing it to break would be kind of an inconsistency tho (copy pasted from [discord](#paper-contrib message) incase you missed it)

rustic folioBOT
#

Is your feature request related to a problem?

Currently, there is no official online hosted Brigadier Javadocs, meaning you cannot look up the Brigadier jd online.
You also do not have any Javadocs in your IDE with Paper-API, even though Brigadier is exposed and Paper-API Javadocs are downloaded.

Describe the solution you'd like.

I would love to have the Brigadier Javadocs included in Paper-API in order to have an easier time reading up on what the individual classes actually do.

Describe alternatives you've considered.

The "best" way to read Brigadier Javadocs currently seems to be the Javadocs of CommandAPI: https://commandapi.jorel.dev/javadocs/html/annotated.html.

To have something similar in Paper would be great.

Other

It seems that Brigadier themselves do not actually define any Javadocs, meaning one would have to map Javadocs to the classes themselves, or we could copy them from CommandAPI

rustic folioBOT
#

No, you donโ€™t just hide errors when something goes sideways, that would
just mask the issue and cause other side effects people would expect us to
fix.

As I said earlier, we need a way to reproduce this in some form of manner
so that we can look into it.

On Sun, 5 Jan 2025 at 15:22, Matej @.***> wrote:

Unfortunately it is still happening; I am very confident we do not mess
with META-INF. Can you simply add an if-condition to prevent that error?

โ€”
Reply to this email directly, view it on GitHub
https://github.com/PaperMC/Paper/issues/11752#issuecomment-2571661396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJMAZF6G2DJPPJH74W6GJL2JFE4FAVCNFSM6AAAAABT44BKSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRGY3DCMZZGY
.
You are receiving this because you commented.Message ID:
@.***>

#

Issue is that brigadier doesnโ€™t have Java docs, there is a pr to change
that, but, nothing has been said from mojang regarding this

On Sun, 5 Jan 2025 at 15:08, masmc05 @.***> wrote:

Maybe an alternative would be hosting brigadier compiled with sources and
javadocs on paper's official repo. Brigadier is MIT so the license permits
redistributing brigadier

โ€”
Reply to this email directly, view it on GitHub
https://github.com/PaperMC/Paper/issues/11915#issuecomment-2571657063,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJMAZAIYUL6NJV63HZFRHT2JFDE7AVCNFSM6AAAAABUUFX5MCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRGY2TOMBWGM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

#

I did bring merging and pushing that pr ourselves internally a short while
back I think, so weโ€™d have JDs for that; it is a pain that there is
currently stuff which people canโ€™t see and miss out on due to this

On Sun, 5 Jan 2025 at 15:32, Strokkur24 @.***> wrote:

Indeed. That's why my suggestion would be to write some ourselves. I can
understand this being a lot of time spend for minimal gains though

โ€”
Reply to this email directly, view it on GitHub
https://github.com/PaperMC/Paper/issues/11915#issuecomment-2571664246,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJMAZF3BCFT6YN64N5W4A32JFGBVAVCNFSM6AAAAABUUFX5MCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRGY3DIMRUGY
.
You are receiving this because you commented.Message ID:
@.***>

rustic folioBOT
#

Expected behavior

No error message should pop in the console.

Observed/Actual behavior

After updating from 1.21.3 to 1.21.4, I got spammed by a lot of messages in the console :

[17:33:09 ERROR]: Failed to parse vibration listener for Sculk Sensor: 'No key selector in MapLike[{event_delay:0,event_distance:0.0f,range:8,source:{pos:[I;1167,-38,-4707],type:"minecraft:block"}}]'
[17:33:09 ERROR]: Failed to parse vibration listener for Sculk Sensor: 'No key selector in MapLike[{event_delay:0,event_distance:0.0f,range:8,source:{pos:[I;1167,-37,-4708],type:"minecraft:block"}}]'
[17:33:10 ERROR]: Failed to parse vibration listener for Sculk Sensor: 'No key selector in MapLike[{event_delay:0,event_distance:0.0f,range:8,source:{pos:[I;1189,-34,-4699],type:"minecraft:block"}}]'
[17:33:10 ERROR]: Failed to parse vibration listener for Sculk Sensor: 'No key selector in MapLike[{event_delay:0,event_distance:0.0f,range:8,source:{pos:[I;1167,-42,-4703],type:"minecraft:block"}}]'
[17...
rustic folioBOT
#

Expected behavior

Zombie piglins forgive the player.

Observed/Actual behavior

A zombie piglin doesn't stop attack the player even after death and the creative/spectator's mode.
https://github.com/user-attachments/assets/7457b4f5-191b-4a75-b938-771c11bea961

Steps/models to reproduce

  1. Go to the nether
  2. Hit the zombified piglin in survival mode
  3. Set creative or spectator mode and see

Plugin and Datapack List

Plugins: Airdrop, ChatEx, ChristmasFireworks, Chunky, craftableinvframes, FreedomChat, Gsit, LuckPerms, PlaceholderAPI, SkinRestorer, Tab.
Datapacks: DeepOceans, PlayerHeadDrops

Paper version

1.21.4-75-main@9f90b4c

Other

No response

rustic folioBOT
#

Expected behavior

Redstone Comparator should be reading SS2 and not SS1 when reading a dropper with an unstackable item (ie a iron shovel or netherite hoe) is inside it.

Observed/Actual behavior

See discussion in Reddit's r/redstone by MazeyMoos0022 (submitter)

Redstone Comparator reading from a dropper (or hopper) is worth SS1 per non-stackable item (ie a iron shovel or netherite hoe) and not worth SS2

Steps/models to reproduce

Literally just shove a comparator reading a hopper/dropper/dispenser/crafter and put a non-stackable item in, and read the output (a vanilla tweaks resource pack is useful here)

Plugin and Datapack List

DiscordSRV (v1.29.0), LuckPerms (v5.4.150), OpenInv (v5.1.4), ProtocolLib (v5.3.0), SuperVanish (6.2.20), CutiecordPlugin (v1.2.1 CUSTOM PRIVATE PLUGIN!), JailPlugin (v1.3 CUSTOM PUBLIC PLUGIN).

Issue also occurs with no plugins also present o...

rustic folioBOT
#

Expected behavior

Hello.

The following method when there is a space to add the item should add the item in the inventory:

PlayerInventory inv = p.getInventory();
inv.addItem(new ItemStack(Material.DIAMOND));

Image

I have place in my offhand, so it should increase to 37, 38, 39 up to 64.

Observed/Actual behavior

But currently, it doesnt work when the space is in the off hand.
The additem method return a non empty Map.

Steps/models to reproduce

Create a small plugin with

PlayerInventory inv = p.getInventory();
inv.addItem(new ItemStack(Material.DIAMOND));

when you do a specific action

put at least one of the item you add in your offhand and fullfill your inventory with another item

Plugin and Datapack List

[21:25:21 INFO]: - AceStore, CustomPiglinsTrades, ExecutableBlocks, ExecutableEvents, ExecutableItems, LuckPerms, MyFurniture, NBTAPI, packetevents, PlaceholderAPI
[...

rustic folioBOT
#

Expected behavior

A mob with equipment, say a skeleton should always drop its bow when killed with a looting 255 sword, whether spawned by commands, spawners or egg.

Observed/Actual behavior

Only natural and egg-spawned mobs drops its equipment, /summon and from mob spawner (natural generated spawner) don't

Steps/models to reproduce

Get a Diamond Sword with max Looting and Sharpness

Hunt natural skeletons - they always drop bow
Spawn skeletons with eggs - they always drop bow
Find a skeleton spawner - spawned skeletons never drop bow
Use /summon minecraft:skeleton - these never drop bow either

Plugin and Datapack List

Tested in a fresh server folder.

Paper version

This server is running Paper version 1.21.4-75-main@9f90b4c (2025-01-04T21:02:23Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)

Other

No response

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Can we aim to have as few feature patches as possible? their existence kind of defeats the purpose of per-file patches, as what you see in the patch files isn't what you get, since it will be overwritten by the feature patches, also they cause errors with fixuppatches if you dare to modify a file that feature patches also touch

This is probably better to discuss on the discord, but generally itโ€™s very dependent on the feature itself for whether or not it becomes a feature patchโ€ฆ especially when itโ€™s very diff noisy, so allowing it to be dropped on updates easily is just undeniably useful. They donโ€™t defeat the purpose at all, they are there for a separate purpose roughly.

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

I dislike the notation of such an event, especially given the lack of a context API. If handled improperly, it would only break other plugins, which could be dangerously destructive to servers. Plugins do not have mechanisms for seeing the context of what is going on to surmise how they'd be able to handle anything properly.

I have a plugin that takes over some operations to put items into a player's inventory and uses the returned map to implement fallback behaviour, which is relevant to what is going on because I have the context of that.

rustic folioBOT
rustic folioBOT
#

player.setPlayerTime(time, false) allows freezing time on the client, as per javadoc:

When using non relative time the player's time will stay fixed at the
specified time parameter.

Doing so makes the client move the skybox forward, and then jump back due to the server resyncing the time, causing a constant skybox stutter.
This can be prevented by accounting for a non-relative (fixed/frozen) player time alongside the real world's day cycle gamerule.


tldr; avoid skybox stutter by accounting for frozen player time / tell the client to not move skybox when using frozen player time

rustic folioBOT
rustic folioBOT
#

We could I guess also only send an update if there is no cool down right now? Implying that the client doesn't have a cool down? A server initialized cool down would not require a resync.

you check if exists in cooldown? not sure... i make a test like

if (this.isOnCooldown(item)) {
                System.out.println("addCooldown::isOnCooldown true");
                this.onCooldownStarted(cooldownGroup, this.getCurrentCooldown(cooldownGroup));
            } else {
                System.out.println("addCooldown::isOnCooldown false");
            }

and with the same code items like goat horn not has the cooldown but throw the visual desync because not use the cooldown component use the intrument duration for handle this and sure client know this too then need resend unless wanna make a case per case for this edge cases... but i prefer send the packet in all cases becauses is like... in the end vanilla send the packet all the time for any cooldown call

rustic folioBOT
#

when make this i have the "question" about if is good make the changes in MusicInstrument or move to the paper components for make a builder... but sure the best thing.. i mean for less breaking things i prefer keep working in MusicInstrument (not sure in that case how handle a builder or leave this to future PR)

another thing.. currently this PR still fails if the item created has a sound_event invalid
ex: /give @a minecraft:goat_horn[minecraft:instrument={sound_event:"intentionally_empty",use_duration:140,range:256,description:"asd"}]
make the getData for instrument throw this.

[09:48:09 ERROR]: Command exception: /test
java.lang.IllegalArgumentException: Cannot convert direct holder to bukkit representation
	at org.bukkit.craftbukkit.CraftRegistry.minecraftHolderToBukkit(CraftRegistry.java:83) ~[main/:?]
	at org.bukkit.craftbukkit.CraftMusicInstrument.minecraftHolderToBukkit(CraftMusicInstrument.java:23) ~[main/:?]
	at io.papermc.paper.datacomponent.DataComponent...
rustic folioBOT
rustic folioBOT
#

It isn't needed in this case as the block entity Is only used for faking it's open. See Anvil impl for example where it's used. In the case of opening a real shulker box the block entity is obtained from the world. And to be completely honest I don't care about InventoryType. This may be controversial but I personally have no plans to build around API this is meant to replace. I'll look into it, but no promises and almost certainly not my priority.

rustic folioBOT
#

I think there are some fundamental issues with this concept. I do not like introducing any way to thwart/bypass the priority system while we still have modifiable events. In your example, you are re-querying the player from the event. Imagine an event with a mutable field with a getter/setter. This would enable you to modify the event from that callback. That shouldn't be allowed. I much prefer you just have 2 listeners on different priorities.

rustic folioBOT
#

Is your feature request related to a problem?

When using Entity#addPassenger, the event that is thrown - VehicleEnterEvent should it be a vehicle. The same is done when a player manually enters a vehicle. If you want to cancel the event, there is no straightforward way to distinguish between these two causes.

Describe the solution you'd like.

Add getVehicleEnterCause to VehicleEnterEvent, similar to TeleportCause

Describe alternatives you've considered.

Listening to cancel instead, though it's a bit less clean of a workaround. A way to properly distinguish player vs plugin passenger adding would be ideal

Other

No response

rustic folioBOT
#

While doing a hard fork, do you think it would be viable option to switch to GraalVM native image? This would drastically improve performance while sacrificing the garbage collector which means that plugin developers would have to be more careful. I think the advantages outweigh the disadvantages

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

While doing a hard fork, do you think it would be viable option to switch to GraalVM native image? This would drastically improve performance while sacrificing the garbage collector which means that plugin developers would have to be more careful. I think the advantages outweigh the disadvantages

has native image been tested for a minecraft server? I wouldn't a expect performance more than 15% max, and for this you'd be paying a huge cost, breaking most plugins, folia also breaks plugins but is a more scalable approach

rustic folioBOT
rustic folioBOT
#

But the 2 lines basically say the same.
Maybe something like this?

Paper plugins do not support YAML-based command declarations!
You are probably trying to get a command via JavaPlugin#getCommand that you defined in paper-plugin.yml.
This method of command declaration is not supported when using Paper plugins.
Please check the documentation for more information on how to define commands in Paper plugins: https://docs.papermc.io/paper/dev/getting-started/paper-plugins#commands

Also do you guys rename Paper plugins to Lifecycle plugins? Maybe reflect that already?

RE:

That being said, the stacktrace will also show the right location, so maybe it's indeed too verbose?

Without wanting to make assumptions i think that "new to plugin development (or development in general)" wont know how to read a stacktrace. So we should not consider that as a factor here. As you said you want to be extra clear and I think being a bit more verboste makes sense.

rustic folioBOT
#

Please don't reply to a 2 year old closed issue, open a new issue following the issue template.

<img alt="" width="16" height="16" src="https://avatars.githubusercontent.com/u/332527?s=64&u=9a4ea3a56d212d307ed052382f9dba29e7464ea5&v=4">@BillyGalbreath I seem to be having this exact same problem lately on Paper 1.21.4-76-main@486e521; has this problem resurfaced for you as well?

rustic folioBOT
#

Expected behavior

I expect wolves to not get damaged when players hit them and EntityDamageByEntityEvent is cancelled.

Observed/Actual behavior

The Wolf entity gets damaged by the player

Steps/models to reproduce

  • Cancel the EntityDamageByEntityEvent completely
  • Load into a world and summon a wolf
  • Try to hit it and observe the outcome

Plugin and Datapack List

A custom plugin with just the cancellation of the EntityDamageByEntityEvent

Paper version

This server is running Paper version 1.21.4-78-main@49d15f6 (2025-01-07T18:45:42Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-68-9298f59 (MC: 1.21.4)

Other

No response

rustic folioBOT
#

Expected behavior

flush-regions-on-save: true to write to region files when chunks unloaded/etc via Windows.

Observed/Actual behavior

flush-regions-on-save: true do not write to region files when chunks unloaded/etc via Windows.
/save-all flush works however.

Steps/models to reproduce

Environment: Windows Version 24H2 & Java 23.0.1+11-39

Settings:
server.properties.sync-chunk-writes=true
bukkit.ticks-per.autosave: 6000
paper-world-defaults.chunks.auto-save-interval: default
paper-world-defaults.chunks.flush-regions-on-save: true

Start Paper server, break a few blocks, teleport away, notice region files are not be written to.
Using /save-all flush - Does however write to the files.

The option to fix this was added here: https://github.com/PaperMC/Paper/issues/9142
Looks like this option is no longer wired up / functional.

Plugin and Datapack List

On Request via Discord.

Paper version

Paper 1.21.4-76-main@486e521

Other

No response

rustic folioBOT
#

@Machine-Maker Yes, I agree with your concerns because we can only request that cannot do so, but the request is clearly not as restrictive as the limit.

Therefore, I also agree that this change should not be implemented, at least not in the Paper API. But I also want to know if using it while adhering to immutable requirements would result in performance issues?

Sorry for the late reply, there was an issue with Github when I was replying this morning.

rustic folioBOT
#

Expected behavior

fixing the GhostTotem error

Observed/Actual behavior

as I understand it, this happens to some extent because of the ping, and to some extent because the players take them at the last moment.

Steps/models to reproduce

fixing the GhostTotem error

Plugin and Datapack List

AntiPopup, BetterRTP, Chunky, ClearLag, EasyPayments, FastAsyncWorldEdit, FasterCrystals, KnockbackSync, LiteBans, LPC, LuckPerms, MyCommand, packetevents, Pl-Hide-Pro, PlaceholderAPI, PlugManX, PremiumVanish, ProtocolLib, RtpQueue, sCheckPlayer, SetSpawn, SimpleTpa, SkinsRestorer, Skript, TAB, ViaBackwards, ViaVersion, Welcome, WorldGuard

Paper version

1.21.4 (79)

Other

Hello, I'm using the latest version of Paper (namely 1.21.4 #79) and there is a bug or bug called GhostTotem, I don't know for sure if it depends on your kernel, but try to do something about it.
So, this is a fairly common problem for players who play CrystalPvP in MineCraft, there is no fix for th...

rustic folioBOT
#
[PaperMC/Paper] branch deleted: feat/component-obfuscation
rustic folioBOT
rustic folioBOT
#

Expected behavior

Looking at an entity/hitbox should add the UUID from this entity to the brigadier entity selector argument.

Example:
Image

Observed/Actual behavior

Looking at an entity/hitbox does not add the UUID to the entity argument.

Example:
Image

Steps/models to reproduce

  1. Look at an entity
  2. Enter any command including an entity selector argument (e.g. /kill ...)
  3. Check if entity UUID is inside the suggestion

Plugin and Datapack List

None

Paper version

This server is running Paper version 1.21.3-82-ver/1.21.3@5a60ffb (2024-12-23T19:10:30Z) (Implementing API version 1.21.3-R0.1-SNAPSHOT)
You are running the latest version

Other

No response

#

Hi @kompot7, I don't believe this is actually an issue related to Paper nor can Paper do anything about it. An issue was created on Mojira for a similar reason and was closed as invalid because:

If you didn't switch early enough, then you didn't actually switch to the totem in time.

I also tested Totems of Undying 20 or so times with ~500ms ping and they all worked fine every time, even though there was a delay. Granted, I wasn't trying to switch my active item to a Totem at the last second, but again, that isn't something Paper should try to account for.

Also, for the record, I see you're using SkinRestorer. Just so you're aware, support isn't provided to those using offline mode.

#

Sniffers use Mojangs new Brain AI system, as they are very smart mobs. The behaviours defined in that will override whatever you do with the Pathfinder. You would need to disable/remove those to make it respond to the pathfinder properly, similar to how you need to remove mob goals from other mobs. This is nothing that can really be fixed on its own, there just needs to be a Brain API.

As a workaround until the Brain API arrives, you can use NMS/Internals to remove the Behaviours from the Brain.

#
[PaperMC/Paper] New branch created: fix/map-biome-check
#

Is your feature request related to a problem?

There seems to be no alternative to entitytype.isenabledbyfeature

    /**
     * Gets if this EntityType is enabled by feature in a world.
     *
     * @param world the world to check
     * @return true if this EntityType can be used to spawn an Entity for this World.
     */
    @Deprecated(forRemoval = true, since = "1.20") // Paper
    public boolean isEnabledByFeature(@NotNull World world) {
        return Bukkit.getDataPackManager().isEnabledByFeature(this, world);
    }```

I need to use this in order to generate a list of spawn eggs (excluding spawn eggs for experimental mobs)

### Describe the solution you'd like.

Why is it marked for removal? It works fine, no reason is given in bukkit datapack manager either, it just suggests using paper data pack manager which has no feature flag related methods

```java
/**
 * Manager of data packs.
 * @deprecated use {@link io.papermc.paper.datapack.DatapackManager}
 */
@Dep...
rustic folioBOT
#

Stack trace

[22:51:05 ERROR]: Failed to handle packet ServerboundSelectKnownPacks[knownPacks=[minecraft:core:1.21.4]], suppressing error
java.lang.IllegalArgumentException: Hash is too long (max 40, was 44)
        at net.minecraft.network.protocol.common.ClientboundResourcePackPushPacket.<init>(ClientboundResourcePackPushPacket.java:33) ~[paper-1.21.4.jar:1.21.4-82-08fc33c]
        at net.minecraft.server.network.config.ServerResourcePackConfigurationTask.start(ServerResourcePackConfigurationTask.java:22) ~[paper-1.21.4.jar:1.21.4-82-08fc33c]
        at net.minecraft.server.network.ServerConfigurationPacketListenerImpl.startNextTask(ServerConfigurationPacketListenerImpl.java:188) ~[paper-1.21.4.jar:1.21.4-82-08fc33c]
        at net.minecraft.server.network.ServerConfigurationPacketListenerImpl.finishCurrentTask(ServerConfigurationPacketListenerImpl.java:199) ~[paper-1.21.4.jar:1.21.4-82-08fc33c]
        at net.minecraft.server.network.ServerConfigurationPacketListenerImpl....
rustic folioBOT
#

Generally a bit unsure on both the naming of the event and the exposed caused.
PlayerLoadedEvent can mean a lot, the packet name is fine-ish given it is a packet.
But in the context of the API, it could easily be confused for player data being loaded. As for alternative suggestions, uh nothing immediately comes to mind?
PlayerClientLoadedEvent?

In regards to the cause, I'd rather not introduce the concept of "packet" triggered.
Tho I am having a bit of a hard time to think of a usecase for the cause, so if you can elaborate on that, maybe that'll help my understanding :+1:

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

#paper-help message
old
Image
new
Image

maybe there is something broken? :)

Observed/Actual behavior

shulker tooltip is empty

Steps/models to reproduce

put stuff in shulker and this shulker into a chest, to view the lore - hover over it ;)

Plugin and Datapack List

  • mods deactivated
  • no plugins changed between paper versions

Paper version

This server is running Paper version 1.21.4-82-main@08fc33c (2025-01-09T18:13:41Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-79-b34ae4f (MC: 1.21.4)

Other

No response

rustic folioBOT
#
[PaperMC/Paper] New branch created: bugfix/oversized-obfuscation
#
[PaperMC/Paper] branch deleted: bugfix/oversized-obfuscation
#

Generally, I like the idea.

I do wonder if we could improve this even further, especially around the bit set usage.
Having one bit set per tempt predicate is a bit annoying as it has to be resized when new players join. Instead, what prevents us from keeping the bitset on the player and using the predicate as key? We'd currently even get away with using a single long on there, saving us a long[] allocation from BitSet. Would require a Object2IntMap for the predicate, or we could even go further and make the extracted predicates an enum/custom type that also carries the int id.

#

I don't think that storing data on the player directly would be nearly as effective.

The resizing of the BitSet is effectively a non-issue - we can represent the state for 64 players in a single long.

With this change, an entity running TemptGoal.canUse can check all players with just that one BitSet. This is very effective, because no player objects are actually looked up; the data required is in a single cache line.

If extra data was stored on the player, it would be a new cache line for every player, and rather inefficient.

rustic folioBOT
#

Opinion in using an int index for access to the cached values?
Means we can skip the temp goal lookup and bit set lookup for unoptimized goals implemented by e.g. plugins + we do not rely on hashmap and the predicate object hashcode being nice.

Also, rangeTargetConditions can/should probably not check the already checked item again.
Would need a // dif on change on both the ctor tho

#

I opted for a HashMap here as it keeps the constructor and function signatures the same and reduces the maintenance burden.

I think it's fine to rely on the Predicate hashCode because we are only adding the Predicates defined in the TemptGoalLookup class and nothing user-provided, so the implementation will always be the default Object.hashCode implementation, and we are effectively getting reference equality, which is all we need. If that's really a concern then we could use IdentityHashMap which calls System.identityHashCode instead. I don't think it would be worthwhile to try and use an integer.

While we are checking the item twice with rangeTargetConditions, it's not a massive issue as it's only for players who are (probably) already holding the item, which is not going to be very many. Fixing this would require inlining quite a lot of code and is probably also not worth it.

#

One downside of the current approach here is that the calculation is eager. I think it would make sense to make it lazy by inversing the meaning of the bitset and marking players that shouldn't be followed. This can then be computed the first time it is actually needed. With the selector separated, you can also directly use the shouldFollow method directly, requiring less copied logic.

#

You are not skipping the bitset lookup, you'll be running into a HashMap#get miss on every tick in a hashmap that is nearly completely saturated (e.g. we will be doing 1 or more object comparisons, depending on the uncertain hashmap bucket layout, which may or may not be on the "cache line")

I am not particularly concerned over what hashcode is used, given the predicates do not overwrite this, it is indeed whatever. I am more concerned about the fact that the hashmap is going to end up with buckets/nodes with size > 1 given the unpredicable nature of the object hashes so our #get calls also need to dabble through the hashmap node table, so even a downside on the vanilla case where an optimized predicate is used.

Overloading a constructor really isn't that big of a deal, especially with a constructor that has not changed since 1.17.

Regarding your change, selector nulling can just be done in the ctor, also easier if we just overload the ctor if we end up passing an int in...

rustic folioBOT
#

I've changed the code to use an integer index similar to your pastebin suggestion and I've also made the calculation lazy for each entity.

Thank you for the quick changes! I'll get to testing it tonight so we can get this merged. Especially with this now being lazy, it should be a performance improvement in any usecase, not just the ones where entities of this type exist.

rustic folioBOT
#

For reference, SirYwell suggestion would have probably looked like this:

I personally do not have much of a preference between the two implementations, nextClearBit has to invert the words vs the one bitset lookup your implementation has to do on a single long for the predicate index.
But yea, just for you to look at, maybe you find it prettier.

diff --git a/paper-server/patches/sources/io/papermc/paper/entity/goal/TemptGoalLookup.java.patch b/paper-server/patches/sources/io/papermc/paper/entity/goal/TemptGoalLookup.java.patch
index 95a44e4a15..bd9f5d9464 100644
--- a/paper-server/patches/sources/io/papermc/paper/entity/goal/TemptGoalLookup.java.patch
+++ b/paper-server/patches/sources/io/papermc/paper/entity/goal/TemptGoalLookup.java.patch
@@ -1,6 +1,6 @@
 --- /dev/null
 +++ b/io/papermc/paper/entity/goal/TemptGoalLookup.java
-@@ -1,0 +_,64 @@
+@@ -1,0 +_,54 @@
 +package io.papermc.paper.entity.goal;
 +
 +import java.util.ArrayList;
@@ -38,7 +38,6 @@
 ...
rustic folioBOT
#

PlayerLoadedWorldEvent to me sounds too much still like WorldLoadEvent and doesn't strongly enough indicate this is a client-state/behavior event. Might I propose PlayerFinishJoinEvent or something of that ilk?

I just feel it's important not to name it something that sounds like Bukkit-level actions, but rather is a later phase of joining a server.

rustic folioBOT
rustic folioBOT
#

Expected behavior

EXP is added when retrieving items from a furnace/smoker

Observed/Actual behavior

No EXP is added

Steps/models to reproduce

  1. Craft items that total to >= 1 exp, but do not retrieve them
  2. Restart the server
  3. Retrieve the items

Plugin and Datapack List

Fresh server folder

Paper version

This server is running Paper version 1.21.4-83-main@4007171 (2025-01-10T13:45:03Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)

Other

  • Tested with fresh server folder and world.
  • Last working build is 1.21.4-15
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] branch deleted: fix/map-biome-check
rustic folioBOT
#

I don't like to change it only when no sign is actually there, because when using UnsafeValues#nextEntityId(), you are guaranteed that your fake entity id is unique and therefore interacting with your fake entity will always call that event.

Contrary to that there might be a sign already placed somewhere, and searching for a free spot to "place" the sign seems kinda whack for something that is not persistent.

As for the name of the event, I am open for suggestions, because that is best name that I could come up taking my reasoning into account

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

Customized vaults (with a custom loot table) from generated structures or placed jigsaws should be lootable (first time).

Observed/Actual behavior

When generating a structure or placing a jigsaw with a customized vaults players will be unable to loot them.
This seems to be related to the NBT server_data.state_updating_resumes_at as mentioned in the MC-268618 report.

Steps/models to reproduce

Create a structure with a vault that has a custom loot table.
Generate the structure or place it as a jigsaw in an existing world.
Attempt to loot the vault (for a first time)... this shouldn't work.

To fix the vault use the fill command to replace the vault with one that has server_data.state_updating_resumes_at set to 0.
After this looting the vault should work.

Plugin and Datapack List

Custom datapack with a structure that has vault with custom loot tables.
No plugins available.

Paper version

Any versi...

rustic folioBOT
#

Going to close this as we cannot merge this PR as of right now.
I do 100% think the issue is worth addressing with a PR along these lines, but we'll need to first start sending out notices to developers e.g. via nags or whatever that this behaviour is expected to change in ~1-3 releases down the line before we can pull this.

As such, in the name of keeping the PR queue to a minimum, I'll send it to the graveyard to be revived once we finished all preparations :)

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

Yeah that's not a bad way to do it, but you are calling shouldFollow potentially multiple times for the same player if they are not discarded.

Yes, I expect that to be a rather uncommon case, but that claim might be hard to validate :)

Tho I am considering moving all of these changes into a feature patch instead as it is semi-involved and we could live without it during an update / apply in experimental.

One way to reduce the surface of the patch would be to get rid of the TemptGoalPredicate again and use the fact that all the current lambdas are non-capturing:

Index: paper-server/src/minecraft/java/net/minecraft/world/entity/ai/goal/TemptGoal.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/paper-server/src/minecraft/java/net/minecraft/world/entity/ai/goal/TemptGoal.java b/paper-server/src/minecraft/java/net/minecraft/world/...
rustic folioBOT
rustic folioBOT
#

Expected behavior

When I run the command:
/minecraft:give Zenologia minecraft:paper[custom_model_data={strings:["bandana1"]}], i expect to see a piece of paper with a custom texture called on from a resource pack.

The attached screenshot is in a 1.21.4 SINGLE PLAYER world with the resource pack in place

Image

Observed/Actual behavior

I get a piece of paper with one more entry for component data, but not the correct texture, and not marked as an "ingredient" with advanced tooltips on.

The following image is from a paper 1.21.4-97 server

Image

Steps/models to reproduce

  1. Enter world with resource pack loaded (either in local files in single player, or through server.properties for the server
  2. Run the command /minecraft:give Zenologia minecraft:paper[custom_model_data={strings:["bandana1"]}] on...
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

This fix has created an issue. It breaks the compactness serialized size of the commands. For any plugin that uses "flat" aliases (aliases that just shallow copy the root literal), it now doubles the serialized size of the command tree instead of re-using the references to the children command nodes. This is because the hashmap that tracks a serialization id for each CommandNode no longer finds existing nodes because the Command instances are not equal.

rustic folioBOT
#

Going to close this after some further discussion.
Most plugins provide a configuration option to enable their proxy features, or check for the presence of such a setup themselves. Its not Papers responsibility to prevent wrongly configurated plugins, or to fix badly implemented plugins.

However, adding API that makes checking for a proxy setup easier is something that could be PR'ed to Paper.

rustic folioBOT
#

After even more discussion on this, apparently the intention of our RemoveFromWorldEvent is not the same as EntityRemoveEvent, specifically around the time they are called.

The bukkit remove event has a cause but may be called at times (especially around chunk unloads) where edits to the entity are not longer respected.

I'll open a follow up PR undeprecating the bukkit event with your as co-author given all the work you did here (and it was a lot of work) so all credits to you and sorry for the confusion on this change.

#

Expected behavior

No errors and no vanishing piggy would be nice ๐Ÿ˜Š

Observed/Actual behavior

I recently had an issue where stopping a goal of an entity, cause a stack trace in the console (and then the entity vanished).
The goal specifically was the FollowParentGoal.

The error states that this.parent is null.
After doing some digging I came to the realization that the PaperVanillaGoal had wrapped the goal itself, and not the (NMS)WrappedGoal.
Issue here is WrappedGoal#stop stops the goal from running and also stops the goal itself.
But Paper isn't returning the WrappedGoal therefor the WrappedGoal still thinks its running.
As seen here (in PaperMobGoals):
<img width="737" alt="Image" src="https://github.com/user-attachments/assets/942c4583-14da-46a4-b767-07b83ea8f847" />

Inside FollowParentGoal:
<img width="268" alt="Image" src="https://github.com/user-attachments/assets/97592a3a-e86b-4156-8746-47c5021bd902" />

Inside WrappedGoal:
(This is what we're missing acces...