#paper

1 messages ยท Page 17 of 1

rustic folioBOT
#

You can reenable the blocking IO

How would this help here? Wouldn't it prevent any kind of backup at all then?

re-enabling blocking IO would tell the OS to write data NOW, rather than letting it sit around in memory, which might correct some issues caused by the writes being delayed, i.e. desynced region headers, etc

live backups are generally not something that is entirely supported, [...] while it does work with some degree of reliability with the correct setup/environment

Can you give me some pointers about what this would entail? I would imagine I'm not the only paper server owner on windows that wants to do backups while the server is running. There are also plugins that supposedly do this in a more involved manner like this - whould this work better/at all with paper?

I cannot provide support for Windows; I do not recommend using plugins for backups, but...

rustic folioBOT
#

Stack trace

[23:05:49 ERROR]: Error occurred while enabling MMOi18n v1.0.0 (Is it up to date?)
java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    top/mrxiaom/mmoi18n/placeholder/providers/ShieldPatternDataProvider.list(Lnet/Indyuce/mmoitems/stat/data/ShieldPatternData;)Ljava/lang/String; @47: invokestatic
  Reason:
    Type 'org/bukkit/block/banner/PatternType' (current frame, stack[2]) is not assignable to 'java/lang/Enum'
  Current Frame:
    bci: @47
    flags: { }
    locals: { 'top/mrxiaom/mmoi18n/placeholder/providers/ShieldPatternDataProvider', 'net/Indyuce/mmoitems/stat/data/ShieldPatternData', 'java/util/List', 'java/util/Iterator', 'org/bukkit/block/banner/Pattern' }
    stack: { 'java/util/List', 'org/bukkit/ChatColor', 'org/bukkit/block/banner/PatternType' }
  Bytecode:
    0000000: bb00 3659 b700 374d 2bb6 003d b900 4301
    0000010: 004e 2db9 0049 0100 9900 332d b900 4d01
    0000020: 00c0 004f 3a04 2cb2 0055 1904 b600 59b8
   ...
#

https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/commits/46b6d445c363be17953869fe9fada59655b778a4#src%2Fmain%2Fjava%2Forg%2Fbukkit%2Fblock%2Fbanner%2FPatternType.java

The enum > interface change was done by spigot in their 1.21 API builds as part of their experimental changes, in which they've been warning against treating this stuff as an Enum for the past few releases now, I'm not sure if there is any paper specific issues here, did we disable one of their stupidly expensive mitigations by default? I know that there was an enum rewrite which was so expensive that even spigot put that one behind a configuration option

rustic folioBOT
#

Expected behavior

Custom behaviour for the tablist order API.

Observed/Actual behavior

Sorted alphabetically by player name no matter what.

Steps/models to reproduce

Add LuckPerms and hook into it, make a weight-based tablist order:

Bukkit.getScheduler().runTaskTimer(() -> {
for (final Player player : Bukkit.getOnlinePlayers()) {
    player.setPlayerListOrder(getPlayerWeight(player));
}
}, 0, 20L);
private static int getPlayerWeight(Player player) {
    return RankUtils.getWeight(RankUtils.getLPRankName(player));
}
public static int getWeight(String rank) {
    Group group = TurtledDuels.getLuckPerms().getGroupManager().getGroup(rank);

    if (group != null) {
        Collection<WeightNode> Nodes = group.getNodes(NodeType.WEIGHT);
        for (WeightNode node : Nodes) {
            return node.getWeight();
        }
    }

    return 0;
}

public static String getLPRankName(Player player) {
    String rankName = null;
    try {
     ...
rustic folioBOT
rustic folioBOT
#

Expected behavior

Using a datapack that allows one tall versions of two tall plants to be planted (using the /setblock command), on vanilla Minecraft, the one tall plant is placed when crouching and right clicking the ground and item is consumed. if it's the first time planted then an achievement pops up to confirm the plant is planted. I used lilac and roses for testing but the behaviour is the same for all two high plants.

Observed/Actual behavior

When using paperMC doing the above crouch and right click, a bonemeal particle is seen and the item is consumed with the achievement registering if it's the first time, but the plant is not planted and the item vanishes.

Steps/models to reproduce

This was first detected on my server running paper 1.21.1. I then tested in a clean minecraft vanilla single player world and got the expected behaviour. I then ran a burner server and eliminated all plugins and tested again - still the same issue. Did the same and removed al...

rustic folioBOT
#

We also run into this issue (1.21.4).

Our case is reducing any incoming damage by some %, and this issue makes armor to break very very fast, and incoming damage is also very high

  @EventHandler
  public void onEntityDamage(EntityDamageEvent event) {
    if (event.getEntity() instanceof Player player) {
      event.setDamage(event.getDamage() * 0.85);
    }
  }

Result is:
Paper:
https://github.com/user-attachments/assets/fec98e08-d0c1-4a2d-b75d-6ddaa7c69b57

Expected (on vanilla):
https://github.com/user-attachments/assets/d4e1b53d-85e5-415e-95d2-ac06bebb5fa2

rustic folioBOT
rustic folioBOT
#

Is this correct, still? Maybe this was reworked again in 1.21.4, but how does one teleport a player to a position without updating their rotation using current API? As YAW and PITCH flags were dropped from API.

Previous working code:

player.teleport(newLocToTeleport, TeleportFlag.Relative.YAW, TeleportFlag.Relative.PITCH);

My new working code since it was removed from API? I've lost all the validation now that was inside the CB teleport method, though

               final Set<Relative> nms = Set.of(Relative.X_ROT, Relative.Y_ROT);
                ((CraftPlayer) player).getHandle().connection.internalTeleport(new net.minecraft.world.entity.PositionMoveRotation(
                        io.papermc.paper.util.MCUtil.toVec3(newLocToTeleport), net.minecraft.world.phys.Vec3.ZERO, 0, 0
                ), nms);

And the flag is still being applied in the teleport packet on the client, so they still use it? currentPos.yaw and currentPos.pitch is the lerped rotation...

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

For PotionMeta#hasCustomName to return whether the PotionMeta has a custom name.

Observed/Actual behavior

PotionMeta#hasCustomName seems to call ItemMeta#hasCustomName instead of the PotionMeta deprecated redirect, I assume because the override in CraftMetaItem takes priority?

Steps/models to reproduce

Wrote a test plugin:

ItemStack item = player.getEquipment().getItemInMainHand();
PotionMeta meta = (PotionMeta) item.getItemMeta();
player.sendMessage(meta.hasCustomName() + "|||||" + meta.getCustomName());
try {
    player.sendMessage(meta.getClass().getMethod("hasCustomName").toString());
}
catch (NoSuchMethodException e) {
    throw new RuntimeException(e);
}
return true;

On latest Spigot:
Image
On latest Paper:
Image
Item used: `/give @s minecraft:potion[min...

#

Is your feature request related to a problem?

not really a problem other than its missing

Describe the solution you'd like.

I would like to suggest the addition of an EntityType tag in the io/papermc/paper/registry/keys/tags/ package.
There are tags for other things such as BlockType, ItemType, Biome, but nothing for EntityType.

Describe alternatives you've considered.

Bukkit has the Tag class, but I see Paper wants to transition to its own tag system.

Other

No response

rustic folioBOT
#

Is your feature request related to a problem?

Currently you can't get cookies without a player instance, even tho you are able to get cookies during the login phase.

If you add a this.sendPacket(new ClientboundCookieRequestPacket(ResourceLocation.parse("..."))); to the callPlayerPreLoginEvents and check if the payload is present on the handleCookieResponse, you can see that the client does send the cookie response and it does send it with the payload.

Describe the solution you'd like.

Add retrieveCookie to the AsyncPlayerPreLoginEvent.

Describe alternatives you've considered.

Using a proxy /j

Other

No response

#

Events are just POJOs; to do this, you'd need to block the event, which would, in turn, stall up a thread. This needs new API to properly handle this phasing, and ideally a proper system for this akin to what mojang does with their tasks for configuration, rather than just making people block arbitrary events, if we wanted to support that, we'd need to support continuations or something

rustic folioBOT
#

We have to:

  • Apply all per-file patches (about 800)
  • Apply all feature-based patched (about 20, but REALLY large ones)
  • Do minor cleanup and fixes
  • Push to main and publish initial builds
  • Push paperweight-patcher and provide info for forks on how to update
  • Provide a script and info to contributors on how to update their pull requests
  • Do more fixing

Applying all patches will likely take a few weeks. See our forum post for more information: https://forums.papermc.io/threads/the-future-of-paper-hard-fork.1451/

#

Move back feature patches, apply and fix. You need to copy the patch from the old repo, the patches in feature-patches are missing lines and indexes and only there for tracking. For every applied feature patch, make sure to immediately delete the one in feature-patches/

- [ ] 1038 Optimize isInWorldBounds and getBlockState for inlin
- [ ] 1039 Improve Maps in item frames performance and bug fixe
- [ ] 1040 Optimize Network Manager and add advanced packet sup
- [ ] 1041 Allow Saving of Oversized Chunks
- [ ] 1042 Flat bedrock generator settings
- [ ] 1043 Entity Activation Range 2.0
- [ ] 1044 Anti Xray
- [ ] 1045 Use Velocity compression and cipher natives
- [ ] 1046 Optimize Collision to not load chunks
- [ ] 1047 Optimize GoalSelector Goal Flag Set operations
- [ ] 1048 Optimize Hoppers
- [ ] 1049 Optimize Voxel Shape Merging
- [ ] 1050 Optimize Bit Operations by inlining
- [ ] 1051 Remove streams from hot code
- [ ] 1052 Optimize Pathfinder Remove Streams Opt...
#
[PaperMC/Paper] New branch created: dev/hard-fork
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

If you place a book in a chiseled bookshelf with a hopper beneath it, the hopper, if it has free inv space, pulls the book out of the bookshelf and the book is visually removed from the bookshelf, the state (f3 slot_x_occupied) is set to false and the book is removed from its inv.

Observed/Actual behavior

If there already are books inside the hopper and after pulling out the book from the bookshelf the book stacks with the books inside the hopper the bookshelf is not updated correctly. But if there are for example 32 books in the last slot of the hopper and the other slots are free everything works normally because the book gets transfered into the first hopper slot and does not stack with 32 books in the last slot. The bug only occurs if the book stacks with books in the hopper. If the bug occurs the book gets pulled into the hopper but is still displayed in the bookshelf but you cannot take it out since it was already pulled out by the hopper and you a...

rustic folioBOT
rustic folioBOT
#

f60983a net.minecraft.world.entity.animal.allay - Machine-Maker
fe1744d net.minecraft.world.item.alchemy - Machine-Maker
f98d879 net.minecraft.world.level.block.state.properties - Machine-Maker
cb5fece net.minecraft.world.entity.monster.warden - Machine-Maker
9ef230a net.minecraft.world.entity.projectile - Machine-Maker
5b0289a net.minecraft.world.level.storage.loot.predicates - Machine-Maker
ce9d79a net.minecraft.world.entity.projectile.windcharge - Machine-Maker
64500a2 net.minecraft.server - Machine-Maker

rustic folioBOT
rustic folioBOT
#

Stack trace

https://gist.github.com/RealMangorage/7b446144a6440ec2d83518d7a03dc054

It should either be impossible to reload the Paper Plugins, or have it be updated to use the plugins Bootstrapper

Plugin and Datapack List

None, other then the development plugin

Actions to reproduce (if known)

No response

Paper version

This server is running Paper version 1.21.4-14-master@b746d9d (2024-12-11T21:22:39Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version

Other

No response

rustic folioBOT
rustic folioBOT
#

hey @ComputerNerd100, thanks for trying to help out. while we decided its kinda ok to accept contributions from regular contributors in this process, please make it somewhere known which folder you are working on so that we can properly check the progress and prevent duplicated work (i.e. the raid package was done by somebody else too)

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

You're absolutely right that the current configuration file structure (split across paper.yml, spigot.yml, and bukkit.yml) can be confusing and challenging to maintain. Consolidating these configurations into a cleaner, modular system would significantly improve the user experience. Breaking large monolithic files into purpose-specific, smaller configurations can aid readability and maintainability.

rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] New branch created: bugfix/entity-item-damage-event
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

Running echo eula=true > eula.txt and then (path_to_java)\bin\java -jar paper-1.21.4-14.jar nogui makes the server run properly.

Observed/Actual behavior

When attempting to do the two commands above as explained in the expected behavior section, This is what you actually see:

Image
(ALT. Text: Paper Server asks end-user to agree to EULA when they already have through the echo command)

Steps/models to reproduce

  1. Create a new Windows Server 2025 VM,
  2. Get a brand new copy of Paper 1.21.4,
  3. Get the latest temurin JDK 21 version,
  4. Attempt to run the two commands,
  5. Server should stop in the EULA text.

Plugin and Datapack List

(No plugins nor datapacks were used on this testing unit)

Paper version

Paper 1.21.4-14

Other

The terminal shown onscreen has cmd active by writing conhost to the powershell prompt first as powershell didn't...

rustic folioBOT
#

Expected behavior

/whitelist add PLAYERNAME
[INFO] Added PLAYERNAME to the whitelist

Observed/Actual behavior

[01:45:11 ERROR]: Got an error with a html body connecting to https://api.minecraftservices.com/minecraft/profile/lookup/bulk/byname: <html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>Microsoft-Azure-Application-Gateway/v2</center>
</body>
</html>
[01:45:11 INFO]: That player does not exist

Steps/models to reproduce

/whitelist add (a user who is not online/recent)

server tries: https://api.minecraftservices.com/minecraft/profile/lookup/bulk/byname

Plugin and Datapack List

[01:46:33 INFO]: Server Plugins (24):
[01:46:33 INFO]: Bukkit Plugins:
[01:46:33 INFO]: - ChatControlRed, CommandPanels, CoreProtect, floodgate, GSit, LiteBans, LuckPerms, NBTAPI, packetevents, Pl-Hide-Pro
[01:46:33 INFO]: PlaceholderAPI, PlasmoVoice, ProtocolLib, pv-addon-groups, ServerLinksZ, TAB-Bridge, Tebex, TradeManag...

rustic folioBOT
rustic folioBOT
#

Hey @Kishku7, I'm unable to reproduce this issue. Using Paper 1.21.4 build 14 without any plugins I was able to enable the whitelist and add myself without ever joining the server:

whitelist on
[13:27:45 INFO]: Whitelist is now turned on
whitelist add CAMM_
[13:27:48 INFO]: Added CAMM_ to the whitelist

Please try to reproduce this without any plugins, and if you're able to feel free to reopen this or join our Discord for support.

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] branch deleted: bugfix/entity-item-damage-event
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

When a raid in a village is triggered it should go over level 4 if the difficulty is on hard.

Observed/Actual behavior

When a raid is triggered it only goes to level 4 and then it declares victory when all the raiders a defeated.

Steps/models to reproduce

  1. Player is in survival mode
  2. Player drinks amnious 5 potion
  3. Player waits 30 seconds
  4. Player goes into a village
  5. Raid starts
  6. Complete the waves

Plugin and Datapack List

No datapacks are used.
The following plugins are used:
Simple Voice Chat
CustomDiscs
ImageFrame
PermissionsEx (not used, just install incase it is needed)
TabTPS
StatusPlugin

Paper version

1.21.4-14-master@b746d9d

Other

No response

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

Expected behavior

Players are placed on a team and visually stay on that team at all times they are assigned to do so.

Observed/Actual behavior

Some specific players are randomly removed from that team visually in tab and don't obey team modification rules, but they can still be teleported under such team.

Steps/models to reproduce

This is where it gets weird. This is only reproduced when I remove a bunch of people from a team after an extended period of time. This would only occur for a select few accounts after I left them on a team for an extended period of time.

Plugin and Datapack List

Plugins

  • Citizens
  • DecentHolograms
  • Essentials
  • ImageFrame
  • Multiverse-Core
  • ProtocolLib
  • SkBee
  • Skript
  • TridentCollision1 (this does nothing)
  • WorldEdit

Datapacks

  • vanilla
  • paper
  • bukkit

Paper version

This server is running Paper version 1.21.3-81-master@da71382 (2024-12-03T14:58:13Z) (Implementing API version 1.21.3-R0.1-SNAPSHOT)
You are running the...

rustic folioBOT
#

Paper 1.21 build 77 came out in mid-July, and was before we even removed the experimental label. Build 130, the last for 1.21, was weeks later. That makes you wildly outdated for 1.21. You shouldn't be on any of those, however, as 1.21.1 came out pretty fast to fix some critical bugs and exploits and had its last updates in November which is significantly later. But even that is outdated at this point. You should be on latest 1.21.3 or 1.21.4 by now.

First, upgrade the server and all your plugins and see if the issue persists. Maybe it was resolved in an update! If it's not, however, you will want to follow our guide on finding the culprit, in particular doing a binary search. Once you have identified the issue, your solution will vary:

  • If it's one plugin causing the issue, report it to them and remove the plugin for now.
  • If it's a result of multiple plugins conflicting, investigate if there's a ...
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

While migrating a plugin from a spigot plugin to a paper plugin, it should replace the previous jar in the /plugins folder when the new jar is placed in the /plugins/update folder.

Observed/Actual behavior

The update is not performed at all.

Steps/models to reproduce

Create a plugin with a plugin.yml and put it in the /plugins folder the create a second jar with a paper-plugin.yml and put it in the /plugins/update folder and restart the server.

Plugin and Datapack List

[14:05:47 INFO]: Server Plugins (13):
[14:05:47 INFO]: Paper Plugins:
[14:05:47 INFO]:  - BetonQuestPlus
[14:05:47 INFO]: Bukkit Plugins:
[14:05:47 INFO]:  - BetonQuest, Citizens, DecentHolograms, EffectLib, Essentials, EssentialsSpawn, packetevents, PlaceholderAPI, ProtocolLib, Vault
[14:05:47 INFO]:  WorldEdit, WorldGuard
[14:06:37 INFO]: There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
[14:06:37 INFO]: ...
rustic folioBOT
rustic folioBOT
#

Expected behavior

If an allay is left in an unloaded chunk, when you come back and put music in a jukebox nearby, it will dance, allowing it to be duplicated if its cooldown has passed.

Observed/Actual behavior

Once an allay has been unloaded, it will no longer be able to dance.

Steps/models to reproduce

  1. Place an allay in a cell outside of spawn chunks. Do not play music.
  2. Move far enough away to unload the chunk.
  3. Return to the allay.
  4. Place a jukebox right next to the allay and play a music disc in it. Note that the allay does not dance.

Plugin and Datapack List

I tested on two servers:

  1. No plugins. Datapacks: vanilla, bukkit, paper, vanilla tweaks - graves.
  2. Plugins: Skript. Datapacks: vanilla, bukkit, paper.

Paper version

Checking version, please wait...
This server is running Paper version 1.21.3-81-master@da71382 (2024-12-03T14:58:13Z) (Implement...
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Expected behavior

The unknown command message.

Observed/Actual behavior

[13:25:36 WARN]: Unexpected exception while parsing console command "abcd"
java.lang.NullPointerException: command
	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:922) ~[guava-33.3.1-jre.jar:?]
	at com.destroystokyo.paper.exception.ServerCommandException.<init>(ServerCommandException.java:28) ~[paper-api-1.21.4-R0.1-SNAPSHOT.jar:?]
	at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:1040) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at org.bukkit.craftbukkit.CraftServer.dispatchCommand(CraftServer.java:1019) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at org.bukkit.craftbukkit.CraftServer.dispatchServerCommand(CraftServer.java:1000) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at net.minecraft.server.dedicated.DedicatedServer.handleConsoleInputs(DedicatedServer.java:505) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at net.minecraft.server.dedicated.DedicatedServer.tickConnec...
rustic folioBOT
#

For some reason now I am getting this. Unfortunately I am not able to pinpoint the exact cause:

java.util.NoSuchElementException: No value present
	at java.base/java.util.Optional.orElseThrow(Optional.java:377) ~[?:?]
	at io.papermc.paper.command.brigadier.MessageComponentSerializer.message(MessageComponentSerializer.java:23) ~[paper-api-1.21.4-R0.1-SNAPSHOT.jar:1.21.4-15-bb76819]
	at io.papermc.paper.brigadier.PaperBrigadier.componentFromMessage(PaperBrigadier.java:45) ~[paper-api-1.21.4-R0.1-SNAPSHOT.jar:1.21.4-15-bb76819]
	at net.minecraft.commands.Commands.finishParsing(Commands.java:396) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at net.minecraft.commands.Commands.performCommand(Commands.java:351) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at net.minecraft.commands.Commands.performCommand(Commands.java:342) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at net.minecraft.commands.Commands.performCommand(Commands.java:337) ~[paper-1.21.4.jar:1.21.4-15-bb76819]
	at net.minecraft.server.netw...
rustic folioBOT
#

Expected behavior

When moving a custom item inside the inventory, the custom signature of the item should remain unchanged, ensuring the item can stack with other identical items without issue.

Observed/Actual behavior

When moving a custom item within the inventory, the custom signature is updated. While the item's visible properties (e.g., display name, lore) remain identical, the updated custom field prevents it from stacking with other items.

Steps/models to reproduce

  1. Create a custom item that has a custom signature.
  2. Place the item in your inventory.
  3. Move the item to a different inventory slot.
  4. Inspect the item's data.
  5. Compare the custom signature before and after moving the item.

Plugin and Datapack List

Image

Paper version

This server is running Paper version 1.21.3-81

Other

No response

rustic folioBOT
#

If any property of two items except the amount is different then the items cannot stack. Not much you can do with that, because by stacking the two stacks become one and the conflicting data would be lost...

The only way I can think of is to manually handle inventory operations and stack the items manually, while preserving how big part of the stack is marked which way... But I wouldn't go that rabbit hole....

#

The data is being automatically generated for the item when using custom attributes like a textured head.

This is the data of an example item, the only difference is a slight change in the custom data. To be specific:

Data 1:
H4sIAAAAAAAA/83Uz27T**MBw**HcA8VkZWXsMK1QqGlRavEAY2tc9SkrOu/BCHk...
Data 2:
H4sIAAAAAAAA/83Uz27T**MBg**AcA8VkZWXsMK1QqGlRavEAY2uc9SkrOu/BCHk...

These are nearly identical but differ at specific characters, such as "MBw" in Data 1 vs. "MBg" in Data 2.
This change only happens when moving the items around in your inventory making them unable to stack again.

rustic folioBOT
#

stack1

Gzip
Compound ""
        Compound "display"
                ...
                End
        Compound "SkullOwner"
                String "Name" ""
                IntArray "Id" 4
                        0
                        1231420745
                        -1
                        -1073674128
                Compound "Properties"
                        List "textures" Compound 1
                                        String "Value" "eyJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6Imh0dHA6Ly90ZXh0dXJlcy5taW5lY3JhZnQubmV0L3RleHR1cmUvZmU0NzNjNzdiZWJmMjExNjI3OGQxY2I4YjkyMWZjM2YzY2RjZGMzZTUxMTg5N2EzMjJlOWI3MGEyOGJiYmZlYiJ9fX0="
                                        End
                        End
                End
        End
End

stack2

Gzip
Compound ""
        Compound "display"
                ...
                End
        Compound "SkullOwner"
                Compound "Properties"
                        List "textures" Compound 1
                             ...
rustic folioBOT
#

Is your feature request related to a problem?

Currently, it is not possible to make entities look directly at other entities or locations without a bunch of math nobody really understands

Describe the solution you'd like.

Move the lookAt methods from the Player class to the Entity class

Describe alternatives you've considered.

Well... Math

Other

No response

rustic folioBOT
#

Expected behavior

I had a LibrariesLoader class in Kotlin implementing the PluginLoader Inverface to load all required libraries. I had registered the loader correctly in the paper-plugin.yml file and made sure everything else was correct. But it didnยดt work. It didnยดt even call the classloader function.

Observed/Actual behavior

the PluginLoader was not invoked

Steps/models to reproduce

Create a new paper plugin in kotlin and try to use a Loader

Plugin and Datapack List

just my own plugin with the loader registered

Paper version

This server is running Paper version 1.21.4-15-master@bb76819 (2024-12-15T09:48:21Z) (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
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Is your feature request related to a problem?

Yes, I cannot find a way in the API to get all tags from a specific registry.

Describe the solution you'd like.

I would like a simple method, such as Registry#getTags to get a list/collection of all available tags for a specific registry, that are currently registered to the server.

Describe alternatives you've considered.

At the moment I'm having to either use Bukkit's tag system, which leaves much to be desired.
I've also used NMS, which I'd rather stay away from.

Other

No response

rustic folioBOT
#

Expected behavior

Chest with an item inside crestes a redstone signal to camporator. Sitting cat on this chest blocks the chest and redstone signal from it to comporator

Observed/Actual behavior

Though sitting cat blocks the acces to chest, It does not block the redstone signal from this chest

Steps/models to reproduce

  1. Tame a cat
  2. Put an item to the chest
  3. Set a comporator applied to chest, chest gives redstone signal
  4. Put a cat on the chest
  5. Make cat sit/stand and cat despite it condition still gives redstone signal

Plugin and Datapack List

Anticreeper, AuthMe, BooksNews, CoreProtect, ImageFrame, LPC, LuckPerms, Playtime, SkinsRestorer. TAB Voicechat

Paper version

This server is running Paper version 1.21-130-master@b1b5d4c (2024-08-10T10:02:42Z) (Implementing API version 1.21-R0.1-SNAPSHOT)
You are running the latest version

Other

No response

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

Expected behavior

When a player blocks their shield and another player hits it, the blocking player should hear a block sound.

Observed/Actual behavior

The block sound does not play, instead only the "weak attack" sound plays.

Steps/models to reproduce

  1. Enable the skip-vanilla-damage-tick-when-shield-blocked option in paper-global.yml and start the server
  2. Join with 2 accounts and give one of them a shield and mute the audio on the other one
  3. Block your shield with said account (you can pause the game while blocking to continue blocking)
  4. Hit against the shield with the other account
  5. No block sound plays, only "weak attack"

Plugin and Datapack List

[18:13:53 INFO]: Server Plugins (0):

Paper version

[18:13:51 INFO]: Checking version, please wait...
[18:13:51 INFO]: This server is running Paper version 1.21.3-81-master@da71382 (2024-12-03T14:58:13Z) (Implementing API version 1.21.3-R0.1-SNAPSHOT)
You are running the latest version

Other

...

rustic folioBOT
#

This does not look like it'll be easily fixed given the bug that is skipping vanilla damage ticks that is re-enabled via this option means we just early opt out of any follow up logic.

That is why this option is in the unsupported block.
Obviously open to more input from the team, but to me the fix does not look simple enough to warrant its implementation for something as unsupported as adding back a spigot introduced bug that spigot itself already fixed

rustic folioBOT
rustic folioBOT
#

Expected behavior

Everything worked well on version 1.21.3.

Observed/Actual behavior

The method & class where the throw happens. Commit with the changes - https://github.com/PaperMC/paper/commit/71a367ec8489c8a61a4c009f6a3c536438707158

public class CraftArt implements Art, Handleable<PaintingVariant> {
      <...>
      @NotNull
      @Override
      public NamespacedKey getKey() {
          if (true) return java.util.Objects.requireNonNull(org.bukkit.Registry.ART.getKey(this), () -> this + " doesn't have a key"); // Paper
          return this.key;
      }
      <...>
}

Steps/models to reproduce

Register Arts via Bootstrap LifecycleManager. Call Art.getKey().

Plugin and Datapack List

They're not the problem.

Paper version

This server is running Paper version 1.21.4-15-master@bb76819 (2024-12-15T09:48:21Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.3-81-da71382 (MC: 1.21.3)
...

rustic folioBOT
rustic folioBOT
#

Expected behavior

The recipes in the recipe book should be sorted alphabetically as it does in vanilla minecraft from snapshot 24w40a and onward (1.21.2, 1.21.3, 1.21.4)
Image

Observed/Actual behavior

The recipe book is not sorted alphabetically like how it is now (1.21.2+) and is seemingly random
Image

Steps/models to reproduce

  1. Unlock recipes as one would do normally or via command /minecraft:recipe give @p *
  2. Open container/inventory that has the recipe book available (player inventory while in survival, crafting table, furnace, etc.)
  3. Click on the green book

Plugin and Datapack List

N/A
I am testing this with a fresh server with no installed plugins to make sure nothing is feeding into the problem.

Paper version

I tested with both:

This server is running Paper version 1.21.3-8...

rustic folioBOT
#

Expected behavior

The entire input is crafted and dropped on the ground.

Observed/Actual behavior

Acts as if q was pushed on its own and crafts a single result and drops it.

Steps/models to reproduce

  • Open a crafting table
  • Place 2 or more logs in the crafting table
  • Push Ctrl + Q while hovering over the planks

Plugin and Datapack List

/plugins
Server Plugins (0):

/datapack list
There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
There are no more data packs available

Paper version

This server is running Paper version 1.21.3-81-master@da71382 (2024-12-03T14:58:13Z) (Implementing API version 1.21.3-R0.1-SNAPSHOT)
You are running the latest version
This server is running Paper version 1.21.4-15-master@bb76819 (2024-12-15T09:48:21Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version

Other

No response

rustic folioBOT
#

Expected behavior

When creating a Brigadier command tree using Paper's Command API, when declaring a ArgumentTypes.resource(RegistryKey.STRUCTURE) argument, it should not kick a player on join because of a missing registry.

Observed/Actual behavior

The client gets kicked off the server. It seems to not be a server-sided kick, but instead a client-sided kick. The client gets a Connection Lost screen with a Network Protocol Error exception. The client's console also throws the following stacktrace:

[13:24:21] [Render thread/ERROR]: Failed to handle packet ace@9ecff4a, disconnecting
java.lang.IllegalStateException: Registry minecraft:worldgen/structure not found
	at jt$a.g(SourceFile:116) ~[minecraft-1.21.4-client.jar:?]
	at java.base/java.util.Optional.orElseThrow(Optional.java:403) ~[?:?]
	at jt$a.d(SourceFile:116) ~[minecraft-1.21.4-client.jar:?]
	at fw.<init>(SourceFile:49) ~[minecraft-1.21.4-client.jar:?]
	at fw$a$a.a(SourceFile:127) ~[minecraft-1.21.4-cli...
#

This does not happen with any other ArgumentTypes.resource(...) or ArgumentTypes.resourceKey(...) argument. I have them all tested. Only RegistryKey.STRUCTURE in combination withArgumentTypes.resource(...) has this issue.

Again, since the error is actually thrown on the client, I am not 100% certain this is a Paper issue, but it might still be worthwhile to look into it, mainly as the resourceKey(...) variant, which should visually have the same tab completion, does not behave this way.

rustic folioBOT
rustic folioBOT
#

Yeah, this is a vanilla issue. I think it's been reported before, maybe here or on discord. The cause is that the structure registry isn't synced with the client. The client then only has access to the static layer of registries (the builtins like Item, Block, etc) and the synced registries. So the resource argument type will only work with those registries. We can add a check on the server side that throws if you try to create one that will fail on the client.

rustic folioBOT
#

Expected behavior

Ability to convert from a TagSerializable DCV to Gson's DCV implementation. See KyoriPowered/adventure#1130

Observed/Actual behavior

missing adapter in the provider, there needs to be a conversion from TagSerializable to a GsonDataComponentValue

Steps/models to reproduce

See referenced adventure issue

Plugin and Datapack List

n/a

Paper version

From the user report:

This server is running Paper version 1.21.3-81-master@da71382 (2024-12-03T14:58:13Z) (Implementing API version 1.21.3-R0.1-SNAPSHOT)

Other

No response

rustic folioBOT
#
[PaperMC/Paper] branch deleted: dev/hard-fork-base
#
[PaperMC/Paper] New branch created: main
#
[PaperMC/Paper] branch deleted: dev/hard-fork
rustic folioBOT
#
[PaperMC/Paper] New branch created: remove-gibwork
#
[PaperMC/Paper] branch deleted: remove-gibwork
#
[PaperMC/Paper] tag deleted: downloads
#
[PaperMC/Paper] tag deleted: 1.18.2
#
[PaperMC/Paper] tag deleted: 1.19.3
#
[PaperMC/Paper] tag deleted: 1.19.2
#
[PaperMC/Paper] tag deleted: 1.19.1
#
[PaperMC/Paper] tag deleted: 1.19
#
[PaperMC/Paper] tag deleted: 1.19.4
#
[PaperMC/Paper] tag deleted: 1.20
#
[PaperMC/Paper] tag deleted: 1.20.1
#
[PaperMC/Paper] tag deleted: 1.20.2
#
[PaperMC/Paper] tag deleted: 1.20.4
#
[PaperMC/Paper] tag deleted: 1.20.6
#
[PaperMC/Paper] tag deleted: 1.21
#
[PaperMC/Paper] tag deleted: 1.21.1
#
[PaperMC/Paper] tag deleted: 1.21.3
rustic folioBOT
#

This pull request fixes #11693.

Reopen #11730.

Changes made

Fixes client-side visual issues when cancelling PlayerTradeEvent/PlayerPurchaseEvent by resending merchant offer packets.
The value 1 here is for WanderingTrader and CustomMerchantMenu.

To reproduce

Make a plugin that cancels PlayerTradeEvent like this code snippet:

@EventHandler
 public void onPlayerTrade(PlayerTradeEvent event) {
      event.setCancelled(true);
      event.setRewardExp(false);
      event.setIncreaseTradeUses(false);
 }
rustic folioBOT
rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper] New branch created: fix/totems
#

If you can find us a spark report where these kind of measures actually matter, feel free to open a performance issue regarding such "significant" downsides.
Location/vector/quaternion cloning is dirt cheap.
ItemStacks used to not be, hence we were hesitant, but since 1.20.5 cloning these has also become really cheap.

rustic folioBOT
rustic folioBOT
#

Expected behavior

I expected the player.removePotionEffect method to successfully remove the specified potion effect from the player, as it did in the previous version of Paper.

Observed/Actual behavior

Using the player.removePotionEffect API method no longer removes the player's potion effect in the latest Paper version 1.21.4-20-main@083c083. This functionality was working correctly in the previous version 1.21.4-15-bb76819 (MC: 1.21.4).

Steps/models to reproduce

Ensure the server is running Paper version 1.21.4-20-main@083c083.
Apply a potion effect to a player using the API.
Attempt to remove the potion effect using player.removePotionEffect.
Observe that the potion effect is not removed as expected.

Player player = Bukkit.getPlayer("PlayerName");
if (player != null) {
PotionEffectType effectType = PotionEffectType.SPEED;
player.removePotionEffect(effectType);
}

Plugin and Datapack List

[03:24:31 INFO]: Server Plugins (8):
[03:24:31 INFO]: Bukkit ...

rustic folioBOT
rustic folioBOT
#

Expected behavior

"The EntityResurrectEvent cancels the Totem of Undying's effect, causing the player to die and their inventory to drop."

Observed/Actual behavior

"The EntityResurrectEvent cancels the Totem of Undying's effect, causing the player to die but incorrectly results in their inventory being kept."

Steps/models to reproduce

  • Cancel the event: EntityResurrectEvent
  • Use a Totem in the off-hand or hold it in the main hand.
  • Let the player die.

Plugin and Datapack List

/plugins
Server Plugins (0):

/datapack list
There are 3 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)], [paper (built-in)]
There are no more data packs available

Paper version

/version
This server is running Paper version 1.21.4-22-main@188124b (2024-12-23T05:02:42Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)

Other

Discussed in the #hardfork-discussion channel on Discord, @lynxplay shared (https://pastes.dev/GwLU6zd...

rustic folioBOT
rustic folioBOT
#
[PaperMC/Paper-archive] New branch created: ver/1.21.4
rustic folioBOT
rustic folioBOT
#

Of cause. My Old plugin.yml looks like this

name: BetonQuestPlus
main: com.betonquest.betonquestplus.BetonQuestPlus
version: 1.0.0-DEV-UNOFFICIAL
api-version: 1.20.0
description: Additional Adventure Supplies
website: https://docs.betonquest.com/betonquestplus
author: BetonQuest Commercial
authors: [ Wolf2323 ]
depend:
  - BetonQuest

And my paper-pluigin.yml

name: BetonQuestPlus
main: com.betonquest.betonquestplus.BetonQuestPlus
version: 1.0.0-DEV-UNOFFICIAL
api-version: 1.20.0
description: Additional Adventure Supplies
website: https://docs.betonquest.com/betonquestplus
author: BetonQuest Commercial
authors: [ Wolf2323 ]
dependencies:
  server:
    BetonQuest:
      load: BEFORE
      required: true

I only changed the depend(encies)

rustic folioBOT
#

Add RegistryEvent for DamageType

Changes:

  • Add DamageTypeRegistryEntry
  • Add PaperDamageTypeRegistryEntry
  • Make DamageType PaperRegistry writeable
  • Add DamageType Event to RegistryEvents

But I ran into the problem, that DamageEffect uses Bukkit.getUnsafe() for initialization and that seems to be not available at bootstrap. I fixed that with the following changes, but I am not sure if that's the correct way to do is as it may break plugins:

  • Turn DamageType interface into an enum
  • Add CraftDamageType damageEffectToBukkit() and damageEffectToNMS() to CraftDamageType
  • Add getSoundForDamageEffect() to UnsafeValues (and CraftMagicNumbers)
  • Deprecated CraftDamageEffect, UnsafeValues#getDamageEffect() and DamageEffect#getDamageEffect()

The only breaking change I see is when someone tries to cast DamageType to CraftDamageType which is no longer possible with my approach.

rustic folioBOT
rustic folioBOT
#

Yeah, either other form of reference, or trying to resolve it not using CraftServer.

I think a pretty valid solution could be providing another access to unsafe values other than trough craft server. There was already a discussion of making some static access method in a pr, including to get the data and protocol versions in bootstrap, but that died down. Basically a provider class, implementation of that, retrieve it with https://www.baeldung.com/java-spi and hold it in a local class within the static getter method in UnsafeValues class

rustic folioBOT
#

Agree with that sentiment ^
Making this an enum is not something I'd like to see.
We'll end up with some version of unsafe values at bootstrap time down the line anyway so, yea.

Alternatively, we can attempt to predict that damage effects might be a registry value at some point?
Which would mean we could just move this to keys instead of the actual resolved value.
That would need a generated key class tho.
I'd personally be semi in favour of that approach as it means we won't have to break API there if that ever changes and it does get rid of the bootstrap issue. Will poke MM about it tho for his ideas.

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Reopens #11385.

Resolves #11378 by "restoring" the Spigot behavior where VanillaCommandNodes are only created once. Before this commit, BukkitBrigForwardingMap would create a new VanillaCommandWrapper each time a CommandNode was requested via the Bukkit CommandMap. This meant that calls to Command#setPermission would not persist between retrievals from the map.

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>".

As discussed on the original PR, it's probably a good idea to eventually migrate the behavior of Bukkit#dispatchCommand to use Brigadier directly rather than working via the Bukkit CommandMap, which causes issues like this. Now that the hardfork is real, Paper may eventually fully remove CommandMap in favor of direct Brigadier API, which would make ...

rustic folioBOT
#

After some more thinking on this, I'll close this.
Generally post hardfork we'll try to use the fact that the PR queue was soft reset to keep it as low as possible.
This change (while I agree that it would be a nice thing somewhere down the line) is so unlikely to happen and if the team ever decides on actually implementing this would require a lot of community communication / announcements / planning etc to make sure plugin developers have time to actually adapt to this as we cannot slowly phase this behaviour out.

It would be a hard break in a single version.

As such, I'll close this PR with the idea of "if we ever feel like it is the right time for this to happen, we'll go look for this PR / implement it ourselfs and smack you in as a co-author, but for now, this PR adds no value to the PR queue as no one can merge it / review to make it mergable".

Hope that makes sense for you, thank you anyway for the PR, if we ever manage to have the communications in place to pul...

#

See above, I'll also backport the PotionMeta changes without the ItemMeta break to 1.21.2 and 1.21.3 to make adoption easier, but the updated hasCustomName behavior in 1.21.4 will remain as is, since that's also what it will have to be later anyways. the names from upstream were just really poorly chosen. the other two method changes have no effect, since they're not overwritten anywhere

rustic folioBOT
rustic folioBOT
#

pre hard fork PR: https://github.com/PaperMC/Paper/pull/10478

relates to https://github.com/PaperMC/Paper/discussions/10584

Adds a simple disguise api that also makes sure that invalid entity data, not belonging to the type that is faked, is filtered.
It also adds a server generator module to reduce maintenance of the entity data filter.

tldr; The API provides a way to disguise any entity as another or a player with having the possibility to interact with the entity like with any others. The big advantage is that you've the whole vanilla logic and Mob Goal and Pathfinding included without hassle.

Testing the changes can be done using the following snippet:
https://gist.github.com/yannicklamprecht/639acba127a54f5617e1281f099b7aff

Effective loc:

600 loc in patches
3k+ loc generated filter classe
400 loc generator code copied from api-generator
100 loc for generating the filter class.
rustic folioBOT
#

When flattening any command or registering an alias to a node with no direct children (such as a redirect), the code now takes into account any potential redirect/fork/forward on the target node. This fixes the issue where, when registering a command that was simply a redirect, only the namespaced literal would work, and not any aliases of the command.

This fixes #10827 and has been reopened post hard-fork from #10952

rustic folioBOT
#

Sorry for turning this around now, but internal discussion has shown that doing the scanning in a "safe" way we want here and then also enforcing it properly for all future PRs is pretty involved and intrusive to some party in every reasonable way that was suggested.

For the relatively small benefit that it provides vs. just picking your min target version and us keeping track of it separately if needed, I don't feel comfortable adding a bunch of extra complexity/jankness onto either ourselves or our contributors in enforcing this later or regularly running scripts

We might revisit this a lot later when we're at a point with a cleaner code base and tools around it, with time for "extras", but for now I'll have to close it. Until then, thanks for the effort

rustic folioBOT
#
[PaperMC/Paper] branch deleted: feature/reg-mod-copy-from
#

Replaces https://github.com/PaperMC/Paper/pull/11724


This creates a copy of the power enchant and just changes some things about it. This is useful because you don't have to redefine everything about the other enchant, and it will stay updated to the other enchant's values.

@Override
public void bootstrap(@NotNull BootstrapContext context) {
    // io.papermc.testplugin.brigtests.Registration.registerViaBootstrap(context);

    final TypedKey<Enchantment> NEW = EnchantmentKeys.create(Key.key("mm:test"));
    context.getLifecycleManager().registerEventHandler(RegistryEvents.ENCHANTMENT.freeze(), event -> {
        event.registry().register(NEW, EnchantmentKeys.POWER, builder -> {
            builder.maxLevel(10);
            builder.description(text("MOARR POWER"));
        });
    });

    context.getLifecycleManager().registerEventHandler(LifecycleEvents.TAGS.preFlatten(RegistryKey.ENCHANTMENT), event -> {
        final PreFlattenTagRegistrar<Enc...
rustic folioBOT
#

Expected behavior

transformation.getScale().set() sets the scale of entities.

Observed/Actual behavior

Latest Paper build
Image

Paper build #15
Image

Steps/models to reproduce

Download the latest version of Paper.

Plugin and Datapack List

ProtocolLib

Paper version

The version that doesn't work
This server is running Paper version 1.21.4-30-main@aa2c52b (2024-12-23T19:28:24Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are running the latest version
Previous version: 1.21.4-23-a0b3326 (MC: 1.21.4)

The version that works
This server is running Paper version 1.21.4-15-master@bb76819 (2024-12-15T09:48:21Z) (Implementing API version 1.21.4-R0.1-SNAPSHOT)
You are 15 version(s) behind
Download the new version at: https://papermc.io/downloads/paper
Previous version: 1.21.4-30-aa...

rustic folioBOT
rustic folioBOT
#

Expected behavior

The applyMending method should not throw any exceptions when passing 0 as a value. At least that how it was in 1.20.4, since I just started running into that issue since updating to 1.21.4, and haven't changed anything to the plugin code.

I mean it would be a simple fix to not call the method when the value is 0, and I should implement that nonetheless, but throwing that exception seems wrong.

Observed/Actual behavior

Caused by: java.lang.ArithmeticException: / by zero
	at org.bukkit.craftbukkit.entity.CraftPlayer.applyMending(CraftPlayer.java:1899) ~[paper-1.21.4.jar:1.21.4-31-d0d0efe]
	at erenos-3.6.0-SNAPSHOT.jar/net.aerulion.erenos.command.commands.DebugSubCommand.execute(DebugSubCommand.java:37) ~[erenos-3.6.0-SNAPSHOT.jar:?]
	at erenos-3.6.0-SNAPSHOT.jar/net.aerulion.erenos.command.ErenosSubCommand.validateAndExecute(ErenosSubCommand.java:63) ~[erenos-3.6.0-SNAPSHOT.jar:?]
	at erenos-3.6.0-SNAPSHOT.jar/net.aerulion.erenos.command.CommandServic...
#
[PaperMC/Paper] New branch created: feat/component-obfuscation
#

Prevent division by zero in Player#applyMending by simply using zero
instead if the divider itself is zero.
This matches vanilla behaviour in the sense that
ExperienceOrb#repairPlayerItems, which this logic is lifted from, does
pass zero to the enchantment helper and runs its first iteration on
repairing. Vanilla is not affected as the computation failing with zero
is used to compute the leftover exp value, which is not needed if zero
itself is passed in.
As the paper impl however exposes said value to the initial event, our
code needs to account for the zero division.

Resolves: #11800

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

Expected behavior

Given container is a Container double-chest object, calling player.openInventory(container.getInventory()) should open the double-chest inventory (54 slots).

Observed/Actual behavior

A single chest inventory is opened (27 slots).

Steps/models to reproduce

Here's the full event handler; attach a sign to a double-chest, wax it, then right-click on the sign to open the chest.

From ClodMC:

  @EventHandler
  public void onPlayerInteract(@NotNull PlayerInteractEvent event) {
    if (event.getAction() != Action.RIGHT_CLICK_BLOCK) {
      return;
    }

    Block clickedBlock = event.getClickedBlock();
    if (clickedBlock == null) {
      return;
    }

    BlockState blockState = clickedBlock.getState();
    if (!(blockState instanceof Sign sign) || !sign.isWaxed()) {
      return;
    }

    BlockData blockData = clicke...
rustic folioBOT
#

Original: https://github.com/PaperMC/Paper/pull/8492.


Improves upon entity serialization API.

  • IllegalArgumentException will now be thrown if something goes wrong instead of silently failing and producing invalid data (documented in javadocs).
  • Allows optionally serializing passengers and spawning entities with passengers on them.
  • Adds a few flags to control behavior in places where serialization would normally fail.

<details>
<summary>Added serialization flags</summary>

  • FORCE - serializing entities that wouldn't normally be serialized.
    • This covers non-persistent (Entity#isPersistent) and invalid (Entity#isValid; i.e. dead, despawned) entities.
  • MISC - serializing misc non-saveable entities (lightning bolt, leash, fishing bobber).
  • PASSENGERS - if present, the serialized data will include serialized passengers as well.
    • All passed flags apply to passengers too, i.e. you'd also need to pass FORCE if some passenger is currently non-...
rustic folioBOT
#

Closes #11656
Post-softspoon version of https://github.com/PaperMC/Paper/pull/11689

Motive

Developers currently have to either use NMS or copy-paste the already existing NMS implementation. This PR aims to fix that by exposing ways to call that NMS implementation more easily by extending onto the (Human)Player#dropItem method to provide more extensive ways of making the player drop items.

What does it add?

The following overloads to the HumanPlayer#dropItem(...) method have been added:

  • Item dropItem(ItemStack itemStack)
  • Item dropItem(ItemStack itemStack, UUID thrower)
  • Item dropItem(ItemStack itemStack, UUID thrower), boolean throwRandomly)
  • Item dropItem(int slot)
  • Item dropItem(int slot, UUID thrower))
  • Item dropItem(int slot, UUID thrower), boolean throwRandomly)
  • Item dropItem(EquipmentSlot slot)
  • Item dropItem(EquipmentSlot slot, UUID thrower))
  • Item dropItem(EquipmentSlot slot, UUID thrower), boolean throwRandomly)

Im...

rustic folioBOT
#

Are this many overloads really needed?
Personally, I'd go only with just one Item dropItem(ItemStack itemStack) plus boolean throwRandomly and Consumer<? super Item> function to apply data before adding to the world, and would make that itemStack independent of anything, so that you could drop any item in any context you want. You can always easily manually remove/decrease item's amount in any equipment/inventory slot if needed.

rustic folioBOT
#

Personally, I'd go only with just one Item dropItem(ItemStack itemStack) plus boolean throwRandomly and Consumer<? super Item> function

I feel like that is too complicated and would kinda defeat its purpose.

  • The reason for the int slot overload is the fact that when having just an ItemStack itemStack overload, it always just chooses the first one that applies. With a slot you can choose the precise one to drop.
  • The reason for the EquipmentSlot one is due to the the standard int slot having no way to select those in armor or offhand slots.

[I] would make that itemStack independent of anything

That feels weird, as dropping an item sounds like you actually don't have it in your inventory anymore. Giving the developer the task of removing it themselves feels like a fair bit of unneeded code in this context.

#

I think removing the thrower parameter would already decrease the method amount by a fair bit If you want to set the thrower just do it but by default it should use the player as the thrower

I mean, it would not remove a single method, as there is also boolean throwRandomly, which definitely should be exposed as API, due to the complexity of that operation. Though we could get rid of the thrower parameter instead always have <itemselector>, boolean throwRandomly, which usually would just make the last param be set to false.

That sounds like a good middle-ground solution to me. If the developer wants to set the thrower they can do so.
I am not sure if it should flag the inventory owner of the Item as its thrower by default, but that can be put up to discussion.

rustic folioBOT
#

I feel like that is too complicated and would kinda defeat its purpose.

It's similar to already existing methods (e.g. World#dropItem), entity spawning methods have the save overloads.

The reason for the int slot overload is the fact that when having just an ItemStack itemStack overload, it always just chooses the first one that applies. With a slot you can choose the precise one to drop.

No, I mean to literally not link the dropped itemstack to anything, i.e. the drop would simply drop the cloned item no matter its source, not remove it from inventory or anything else. Then you just get the item in that slot and decrease its amount.

#

Your IDE should already be screaming at you that shadow color is never null...
There is no point in a comap flat map for something that is just an xmap.
You are also using the wrong codec, see what vanilla supports for defining shadow numbers in their own codecs (ExtraCodecs.ARGB_COLOR_CODEC.optionalFieldOf("shadow_color").forGetter(serializer -> Optional.ofNullable(serializer.shadowColor)),)

#

It's not entirely the same though. World#dropItem(Location, ItemStack, Consumer<? extends Item>) is defines as follows:

@Override
public org.bukkit.entity.Item dropItem(Location loc, ItemStack item, Consumer<? super org.bukkit.entity.Item> function) {
    Preconditions.checkArgument(loc != null, "Location cannot be null");
    Preconditions.checkArgument(item != null, "ItemStack cannot be null");

    ItemEntity entity = new ItemEntity(this.world, loc.getX(), loc.getY(), loc.getZ(), CraftItemStack.asNMSCopy(item));
    org.bukkit.entity.Item itemEntity = (org.bukkit.entity.Item) entity.getBukkitEntity();
    entity.pickupDelay = 10;
    if (function != null) {
        function.accept(itemEntity);
    }
    this.world.addFreshEntity(entity, SpawnReason.CUSTOM);
    return itemEntity;
}

Notice the new ItemEntity(...). This is what actually allows for the pre-spawn function to make sense, as it runs before it gets added to the world.

In my implemen...

rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
rustic folioBOT
#

Alright, I've done the following changes now:

  • Removed throwRandomly parameter in favor of new methods: dropItemRandomly(...)
  • Deprecated boolean dropItem(boolean) in favor of Item dropItem(EquipmentSlot.HAND, int)
  • Removed dropItem(ItemStack, ...) overloads. They just felt out-of-place and not really particularly. The operations done in that method can be easily simulated by a dev using that API.
  • The methods now look like this:
    • Item dropItem(int slot, int amount)
    • Item dropItem(@NotNull EquipmentSlot slot, int amount)
    • Item dropItemRandomly(int slot, int amount)
    • Item dropItemRandomly(@NotNull EquipmentSlot slot, int amount)
  • The amount can be any arbitrary number. If it is 0 or below, the method just returns null, if it is too big, it will only drop as much as there is amount in that ItemStack from the selected slot.
  • (Hopefully) improved the JavaDocs
rustic folioBOT
rustic folioBOT
#

replaces #11379, pre hard-fork pr

minimal changes from previous pr, mostly some variable renames + //paper comments, to be in-line with the new guidelines.

Additionally, I need to double check the implementation of PlayerLiddedOpenEvent for shulker boxes, particularly if players can leak.

previous description below:

Featuring

  • 5 LidModes, 3 of which were not possible before
  • The ability to get if the lid actually should be open, if a player is in the container
  • The ability to get if the lid is open, from api or the player itself

This also deprecates Bukkits api because of the confusing and outright incorrect javadocs (so those now accurately represent the behaviour)

Testable with the included testplugin commands.

I'm not 100% sure if the PaperLidded interface is the best way of doing this, but it is working
Also, let me know if the naming needs to change.

  • [ ] see if anything important is skipped in the check method scheduled every 5 ticks on chests
rustic folioBOT
#

You can pretty easily just map the Stream from Stream<Tag<T>> getTags right? That's one of the reasons a Stream here makes sense, lots of filtering or mapping or flatmapping people might want to do, so why turn it into a list just to go back into a stream again.

Sorry I may have miss worded that. Forget I said "list".
The point I was trying to make was something to return TagKeys instead of just Tags since Paper seems to be more keen to using TagKey and other things along those lines, felt like it fits more.

#

Expected behavior

Image

An error is not thrown when an array of EnchantmentOffers of size 3 is passed into setOffers.

https://jd.papermc.io/paper/1.21.4/org/bukkit/inventory/view/EnchantmentView.html#setOffers(org.bukkit.enchantments.EnchantmentOffer[])

Observed/Actual behavior

If a array of EnchantmentOffer of size 3 is passed into the setOffer function, the Precondition as written throws the exception. This needs to be the opposite way around as == 3 as the Precondition is thrown when the value is false.

Steps/models to reproduce

Pass in an EnchantmentOffer array of size 3 into the function.

Plugin and Datapack List

Image

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 ru...

rustic folioBOT
rustic folioBOT
rustic folioBOT
#
#

Due to the amount of changes to items in the past updates, the previous configuration for obfuscation does not really fit today's representation of items.
This reimplements ItemStack obfuscation in a way that is built in mind to support the new 1.21.4 ItemModel format.

The following data components are filtered by default when enabled:

DataComponents.MAX_STACK_SIZE,
DataComponents.MAX_DAMAGE,
DataComponents.DAMAGE,
DataComponents.CUSTOM_NAME,
DataComponents.ITEM_NAME,
DataComponents.LORE,
DataComponents.RARITY,
DataComponents.ENCHANTMENTS,
DataComponents.ATTRIBUTE_MODIFIERS,
DataComponents.CUSTOM_DATA,
DataComponents.WRITABLE_BOOK_CONTENT,
DataComponents.WRITTEN_BOOK_CONTENT,
DataComponents.MAP_ID,
DataComponents.POTION_CONTENTS // New!! Will try to hide if customColor is set

Unlike before, obfuscation for data components can now be configured on a per item model basis. So for example, items with the elytra item model will not obfuscate their damage co...

rustic folioBOT
rustic folioBOT
#

I genuinely do not see the benefit of doing this, as opposed to:

<details>
<summary>Code sample</summary>

// Get any item you want
ItemStack item = player.getInventory().getItem(EquipmentSlot.HAND);
ItemStack item = ItemStack.of(Material.GOWSTONE);
ItemStack item = // some other source

// Drop it, provide any amount with `item.asQuantity(amount)`
// Additionally with optional overload to apply data before drop event & item spawn occurred
player.dropItem(item, item -> {
    item.setGlowing(true);
});

// Subtract its amount if needed (this will decrease item's amount in inventory)
item.subtract(item.getAmount());

</details>

The difference would literally be a one-liner (subtract is done behind the scenes instead of manually at the cost of additional clutter), but with more control and wouldn't need deprecating dropItem.

rustic folioBOT
rustic folioBOT
#

I disagree with that approach. This is meant to serve as an API to simulate dropping items from the inventory in basically the same way as a normal player would.

I understand what you mean, and I see value in it, yes. But it doesn't fit what I have in mind for it. Dropping an arbituary amount of any arbituary item may be nice, but it is an entirely different scenario.

The deprecation of boolean dropItem(boolean) was done due to the fact that is has been superseded by a better api.

Your suggestion essentially is saying to abandon all of the useful implications of a one liner to drop 20 items in a player's inventory and never have to worry about reducing items again.
Your variant instead would nullify all of that, forcing the user to care about stuff that usually wouldn't be the case.

The consumer to modify the resulting Item entity is nice, but not really required due to the fact that it returns thay very same entity, meaning you are free to make it glow even now.

...

rustic folioBOT
#

I disagree with that approach. This is meant to serve as an API to simulate dropping items from the inventory in basically the same way as a normal player would.

I don't necessarily mind such API, I just don't see the benefit of having multiple methods like this for something that could be done with just one method and cover all proposed cases at once.

I understand what you mean, and I see value in it, yes. But it doesn't fit what I have in mind for it. Dropping an arbituary amount of any arbituary item may be nice, but it is an entirely different scenario.

Would be repeating of myself, but I don't see both cases as different scenarios to a degree of requiring separate methods. The only difference between dropping an arbitrary item and an inventory item is decreasing the inventory item's amount, which is very trivial to do.

My suggestion is meant to serve the same purpose (drop an item as if the player did that), except the item not being linked to the inventory. It ...

rustic folioBOT
#

Just saying, but that's actually incorrect. You'd have to call player.dropItem(false) to drop one of the item currently in-hand.

Updated to include false.

That method is also limited to just the main hand. You can't drop the off-hand, which you can do with my API.

Current method is supposed to drop the currently holding item, not imitate dropping any item from the inventory. The comparison was also about that, since it's the only use-case in which the deprecated method was being used.

These changes have been approved by the paper team and thus seem to be fine.

Still can discussed and re-reviewed.


I actually found an edge case in my proposed alternative. The drop event would have to be handled separately (one extra overload to NMS method) to not try re-adding the item back to the inventory since the item's source might be whatever and we're dropping a cloned item.

This edge case is also present in your methods. If you drop e.g. head item and can...

rustic folioBOT
rustic folioBOT
#

I was looking over this PR again and it seems like my approach here was a bit flawed, since it did not account for one framed map being viewed in multiple locations and being updated, only players viewing the item frame that's first in the entity iteration order would've seen the changes.

There are still some other gains that could be made, such as reducing the amount of map update packets being sent to players while no changes actually occurred, and the mess that is the tickCarriedBy (seriously, maps in item frames shouldn't have to check if the player is wearing a pumpkin).

rustic folioBOT
#

Expected behavior

When applying the enchantable component tag to an item that's normally not enchantable it should show some enchantment options when put in an enchanting table.

Observed/Actual behavior

The enchantment options are only shown in vanilla and not on a Paper server.

Steps/models to reproduce

  1. Execute this command as an operator. "/give @s dirt[enchantable={value:1000}]"
  2. Put the Dirt item into an enchanting table.
  3. Check if any enchantment options pop up while ignoring that there are no enchantment names shown when it works.

Do this on a paper server and vanilla world/server and compare the results.

Plugin and Datapack List

I've tested it on a completely clean setup of paper and survival server in 1.21.3 for both servers without any data packs, plugins, mods, resource packs, or shaders just plain vanilla.

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....

rustic folioBOT
rustic folioBOT
rustic folioBOT
#

I think going with the dropItem(ItemStack) method would require doing an extra copy of the itemstack. You make a copy with asQuantity(), but then we would have to copy the stack again to drop it. I don't think anywhere in the API (or very rarely) we just "unwrap" the itemstack passed in as a parameter to an API method. If the methods accept a slot, then we only need the single copy to get the stack with the specific amount to drop, and just directly mutate the stack in the inventory.

I think there is a usecase for dropping an arbitrary stack, but what about it just being an additional method that takes an arbitrary stack?

I also like the Consumer<Item>, but that can apply to all the methods.

rustic folioBOT
#

Yeah, any such API method would just be doing the getTags().map(Tag::key) internally anyways. There isn't a nice way to get all the tag keys without doing that map. So probably wont add that, and I'll just suggest doing getTags().map(Tag::key) to get a Stream<TagKey<T>>.

Ok yeah thats fair. Not terribly difficult on the users end.
Thanks :)

rustic folioBOT
#

It's also not as if I don't like the Consumer, but removing the existing methods feels limiting.
Perhaps, we add a new group of methods, dropAnyItem and dropAnyItemRandomly, which does no operations on the player's inventory. This group would not have that quantity param, as you can just set the amount on the ItemStack.

Also, I can add those Consumer params as nullable ones

#

Sorry to sound like a total pain in the rear end here...
Since you're now returning a Collection instead of a stream, getting keys would mean stream -> list -> stream again (and map) and then back to a list...
So with that said, maybe now is a good time to add a getTagKeys method?
(since internally you could do the map before toList return)

rustic folioBOT
#

For quite some time, Iโ€™ve noticed various plugins implementing strange calculations for converting real time into ticks, especially when scheduling tasks at real-world dates and times. These implementations often involve a lot of complexity around time zones.

In this PR, Iโ€™ve added several methods aimed at simplifying scheduler usage. I utilized Javaโ€™s modern time API, including Duration, LocalDateTime and LocalTime

Added API:

  • Standard: scheduling of tasks to run after a specific Duration
  • Standard: scheduling of repeating tasks at a specified Duration interval
  • New: scheduling single-run (non-repeated) tasks for a specific date and time, using LocalDateTime. Time zone handling and potential clock adjustments are managed automatically without user intervention
  • New: scheduling of repeated tasks, daily at the same time (hour, minute, second), using LocalTime. As with the above, time zone handling does not require user intervention. This required the c...
rustic folioBOT
#

Currently NullMarked inner classes a not detected right by the annotation test. Only when the outer class is annotated the test suceeds. Something like the following fails.

package com.destroystokyo.paper;

import org.jspecify.annotations.NullMarked;

public interface SkinParts {

    boolean hasCapeEnabled();

    boolean hasJacketEnabled();

    boolean hasLeftSleeveEnabled();

    boolean hasRightSleeveEnabled();

    boolean hasLeftPantsEnabled();

    boolean hasRightPantsEnabled();

    boolean hasHatsEnabled();

    int getRaw();

    @NullMarked
    interface Builder {
        Builder withCape(boolean cape);
        Builder withJacket(boolean jacket);
        Builder withLeftSleeve(boolean leftSleeve);
        Builder withRightSleeve(boolean rightSleeve);
        Builder withLeftPants(boolean leftPants);
        Builder withRightPants(boolean rightPants);
        Builder withHat(boolean hat);
        SkinParts build();
    }
}
rustic folioBOT
#

I think going with the dropItem(ItemStack) method would require doing an extra copy of the itemstack. You make a copy with asQuantity(), but then we would have to copy the stack again to drop it. I don't think anywhere in the API (or very rarely) we just "unwrap" the itemstack passed in as a parameter to an API method. If the methods accept a slot, then we only need the single copy to get the stack with the specific amount to drop, and just directly mutate the stack in the inventory.

Hmm, fair. In dropping an arbitrary stack there will be 2 or potentially 3 copies: asQuantity (could do int amount param to prevent it), our internal to detach from source itemstack, and one when creating the item entity.

Manually providing the amount and working with the source directly allows avoiding the first two copies. Looks like there's demand for this, so I'm fine with these and making a separate PR for arbitrary items ๐Ÿ‘๏ธ


Regarding the drop event, seems to be a known bug (ht...

rustic folioBOT
rustic folioBOT
#

Alright, here is my proposal for methods (all return Item):
dropItem(int slot, int amount, @Nullable Consumer<Item>)
dropItem(EquipmentSlot slot, int amount, @Nullable Consumer<Item>)
dropItemRandomly(int slot, int amount, @Nullable Consumer<Item>)
dropItemRandomly(EquipmentSlot slot, int amount, @Nullable Consumer<Item>)

dropItemAll(int slot, @Nullable Consumer<Item>)
dropItemAll(EquipmentSlot slot, @Nullable Consumer<Item>)
dropItemAllRandomly(int slot, @Nullable Consumer<Item>)
dropItemAllRandomly(EquipmentSlot slot, @Nullable Consumer<Item>)

dropAnyItem(ItemStack itemStack, @Nullable Consumer<Item>)
dropAnyItemRandomly(ItemStack itemStack, @Nullable Consumer<Item>)

This equals to a fair bit of methods, but each has a purpose. Any comments @SoSeDiK?

rustic folioBOT
#

Expected behavior

in the /sound command there is an error with the sound. instead of the normal id of the sound tags it says "/sound craftsound{holder=reference{resourcekey[minecraft:sound_event / minecraft:ambient.basalt_deltas.additions]=soundevent[location=minecraft:ambient.basalt_deltas.additions, fixedrange=optional.empty]}}"

Up to version 15 of the kernel 1.21.4 paper such an error did not occur.

Observed/Actual behavior

It should be like this: sound ambient_basalt_deltas_additions

and so on with all the sound tags.

Steps/models to reproduce

Plugin and Datapack List

AuthMe, Citizens, CMI, CMILib, DeluxeMenus, Interactions, PL-Hide, PlaceholderAPI, WorldEdit, WorldGuard

Paper version

This server is running Paper version 1.21.4-41-main@d85d318 (2024-12-26T08:45:00Z) (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

No response

rustic folioBOT
#

dropAnyItem(ItemStack itemStack, @Nullable Consumer<Item>)
dropAnyItemRandomly(ItemStack itemStack, @Nullable Consumer<Item>)

I would call those methods dropItem and dropItemRandomly

dropItemAll(int slot, @Nullable Consumer<Item>)
dropItemAll(EquipmentSlot slot, @Nullable Consumer<Item>)
dropItemAllRandomly(int slot, @Nullable Consumer<Item>)
dropItemAllRandomly(EquipmentSlot slot, @Nullable Consumer<Item>)

I would call those methods dropItems instead of dropItemAll

#

Just for testing, I setup the following command:

event.registrar().register(Commands.literal("drop")
        .then(Commands.literal("one")
            .executes(ctx -> {
                ((Player) ctx.getSource().getExecutor()).dropItemRandomly(EquipmentSlot.HAND, 1);
                return 1;
            }))

        .then(Commands.literal("all")
            .executes(ctx -> {
                ((Player) ctx.getSource().getExecutor()).dropItemAll(EquipmentSlot.HAND);
                return 1;
            }))

        .then(Commands.literal("any")
            .then(Commands.argument("item", ArgumentTypes.itemStack())
                .executes(ctx -> {
                    ((Player) ctx.getSource().getExecutor()).dropAnyItem(ctx.getArgument("item", ItemStack.class), item -> {
                        item.setGlowing(true);
                    });
                    return 1;
                })))

    .build());

You can see the result here:

http...

#

I would call those methods dropItem and dropItemRandomly

I feel like new API users could get confused on what those methods do, even when reading the JavaDoc (which I am yet to add).
I want to make it fairly clear which methods drop actual ItemStack from the player's inventory and which methods could cause a dupe glitch ๐Ÿ˜‚.

I would call those methods dropItems instead of dropItemAll

Yeah, sounds like a good idea.

#

Most of these are just default methods on the interface

@Nullable
public Item dropItemRandomly(@NotNull EquipmentSlot slot, int amount, @Nullable Consumer<Item> entityOperation);

@Nullable
public default Item dropItemRandomly(@NotNull EquipmentSlot slot, int amount) {
    return this.dropItemRandomly(slot, amount, null);
}


@Nullable
public default Item dropItemAll(int slot, @Nullable Consumer<Item> entityOperation) {
    return this.dropItem(slot, Integer.MAX_VALUE, entityOperation);
}

@Nullable
public default Item dropItemAll(int slot) {
    return this.dropItemAll(slot, null);
}

@Nullable
public default Item dropItemAll(@NotNull EquipmentSlot slot, @Nullable Consumer<Item> entityOperation) {
    return this.dropItem(slot, Integer.MAX_VALUE, entityOperation);
}

@Nullable
public default Item dropItemAll(@NotNull EquipmentSlot slot) {
    return this.dropItemAll(slot, null);
}
#

I would call those methods dropItem and dropItemRandomly

I feel like new API users could get confused on what those methods do, even when reading the JavaDoc (which I am yet to add). I want to make it fairly clear which methods drop actual ItemStack from the player's inventory and which methods could cause a dupe glitch ๐Ÿ˜‚.

dropAnyItem and dropAnyItemRandomly sounds even more confusing in my opinion
also the Any does not add any information to what the method does

#

I would call those methods dropItem and dropItemRandomly

but i think just mentioning in the docs that the item is not tied to the players inventory at all and will spawn a new item is better
in any case dropItem would be a better fit

Clashing with other methods isn't ideal either, since the behavior is different enough. Even with javadocs it'd be quite easy to miss.

I don't like Any too, but couldn't think of anything better yet.

rustic folioBOT
#

Given we already chatted about this on other channels, I'll be closing this PR as we do not believe such an API is the right fit for the main server API, especially when looking towards evolving this API continuously (outside of the version-specific values) and the general upkeep such an API includes.

We do however acknowledge that such functionality is essential for a lot of developers out there and that implementing such functionality purely via a plugin is cumbersome and limiting. To that degree, we'd offer you the following next steps if you are interested:

  1. Move this API to a separate plugin, for now under your own namespace.
  2. Getting the generator to work outside of the server environment is something we might be able to help with via discord. In this case, only the vanilla remapped jar + libs
    should be needed, which mache might help with?
  3. To skip potentially slow reflective calls, we'd accept "internal" API for your API as a feature patch along the li...
rustic folioBOT
rustic folioBOT
#

How does this interact with this command https://minecraft.wiki/w/Commands/tick? How does it deal with the low TPS drift?


Something along the lines of https://www.creativedeletion.com/2015/01/28/falsehoods-programmers-date-time-zones.html - the long standing problem is, as electronicboy said, the wall time scheduling that has plagued the game forever. If I want to schedule a restart at exactly 18:00 the next day - what do I do? It's obvious the server cannot be at exactly 20.00 TPS (or any 1.00x TPS speed) and will always undershoot the desired frequency. In a favourable scenario, the scheduled restart task will occur within 1 minute, but be greatly off with fluctuations in actual TPS.

Another example, suppose you have birthday today. Your next birthday isn't 365 days from now, it is exactly one calendar year from now. Otherwise you'd be surprised if your next birthday was offset by a day thanks to a February 29th.

Let's assume the function interfaces are fine: does ...

rustic folioBOT
#

No its an abstract class, Naming conventions for abstract classes should include that they are abstract. This creates more clarity that it is not a standalone and is dependent on some further implementation

There is no such convention. This creates a redundancy since you use the abstract keyword anyway and it's not even API so it's even less important to follow some convention you set for yourself.
Also you make the point of "This creates more clarity that it's not a standalone". This makes no sense as the presence of the abstract keyword already says as much. You can't instantiate an abstract class. Therefore you cannot really use an abstract class. An abstract class never is a standalone.

#

Whether or not you like the naming stripping the word Abstract from this class name furthers itself from a standard of other internal classes, feel free to look yourself to confirm, but also doesn't actually improve the content of the PR. Not worth continuing a debate over such a minutely unimportant detail that follows an arguably useful common distinction already made within the internals.

#

[20:23:50 WARN]: [PluginInitializerManager] ======== WARNING ========
[20:23:50 WARN]: [PluginInitializerManager] You are reloading while having Paper plugins installed on your server.
[20:23:50 WARN]: [PluginInitializerManager] Paper plugins do NOT support being reloaded. This will cause some unexpected issues.
[20:23:50 WARN]: [PluginInitializerManager] =========================

This is pretty intentional, we can't selectively not reload those plugins sadly. Most likely in the future this will be made stricter, but until then.

rustic folioBOT
#

Yea, Phantoms and Ghasts don't use it either.
This seems like a bit of an impossible task to properly do.
This is at best gonna be an EntityTag once we have the ability to properly define custom paper tags, but for now I don't think a new API method like this makes sense given the server has many definitions for flying entities (e.g. FlyingMob vs FlyingPathNavigation vs whatever they may come up next).

Thank you anyway for the PR, does highlight that we should work towards custom tags maybe somewhat soon :)

rustic folioBOT
#

Two points:

  • While maybe not the most correct - preserving event order for open event / lid event means we need to split the openMenu calls out of initMenu() and have them be called right before the 5 places inventory open events are fired / initMenu methods are called.

  • While there is 100% not a default title that randomly appears, the nature of the menu provider specific builder implementations (BE, LocationAccess etc) does allow us to technically construct the MenuProvider for each and fetch the title from there.
    This way, LocationAccess Builder impl should get a reference to the nms.Block the menu will be sourced from so it can call the BlockBehaviour#getMenuProvider and source a default title from there.