#paper
1 messages ยท Page 18 of 1
This issue is due to Moonrise calling the tracking behavior of an entity multiple times when chunk statuses upgrade. This causes the Allay game event listener to not reregister their listeners, causing it to not respond to the jukebox (as long as the allay has not moved)
af2812f For new registry values, allow copying from exi... - Machine-Maker
Maybe
dropItemFrom(int/slot)and dropItemStack()?
Yeah I like that one.
[PaperMC/Paper] New branch created: fix/air-item-drop
6cc87f8 Remove itemstack mutation on player drop method - Owen1212055
This appears to cause alot of issues, as the general assumption when calling this method is that the itemstack would not be mutated.
Common issues that this seems to cause is item related actions that later increment a statistic, which is no longer true because the item type changes since its now considered empty.
The dupe that this was meant to resolve was patched.
Fixes #11520 / #11765
59f43ad Remove/Adjust diff that was changed based on th... - Owen1212055
What exactly was broken with the stream/map/toArray?
0efd301 Fix suggestions for ResourceLocation (#11830) - YoungSoulluoS
Ok, now its just soo many methods. What was the original issue with a randomly boolean parameter instead? I kinda think just adding that to the methods and reducing the number of methods by half is better.
Might make sense to apply it before PlayerDropItemEvent?
drop should have a separate handling for cancelled PlayerDropItemEvent in case of arbitrary items. This is a special case, the item's source might not be player's inventory, so the item should not be neccesarily added to the player's inventory, but rather let the dev handle it.
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?
Tested locally, looks good to me!
953f6f9 Banner pattern registry modification (#11803) - kokiriglade
Looks good to me, the intention of that code is to essentially make that new node act identical to redirectTo, rather than redirecting to redirectTo. This avoids some vanilla bugs.
This was missed, it seems.
PlayerRespawnEvent supports mutability, this change removes that behavior as AbstractRespawnEvent clones it.
This was discussed, there is a setter for the respawn location, so this is intential bulletproofing.
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
3b48eaa removed unneeded import - Machine-Maker
That error doesn't seem possible. It can't find the service via java's service loader API. Is something messing with the META-INF in the server or something removing it?
I guess, just not sure about doing changes like these silently.
a5b8df6 add tagkey file for entity type (#11832) - Machine-Maker
What was the original issue with a
randomlyboolean 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
...Randomlymethods, let's just add aboolean dropRandomlyparameter 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.
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...
Paper doesn't support bedrock clients. You should try reporting this to the bridging system you are using (probably Geyser)
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
4456237 Reworked Vehicle PlayerMoveEvent Handling - Owen1212055
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
setTocalls 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
- Player Remains Untouched
...
No longer needed because we need the Either pattern anyways.
[PaperMC/Paper] branch deleted: feature/RegistryValue
I think non-entityOperation ones could stay (@Machine-Maker?), given that's the only overload left; while this would be 3 methods * 2 for item consumption overloads, it would be on pair with other such APIs, and requiring users to pass null each time is annoying
Semantics but, I think cachedWrappedBukkitCommand would read better than what's currently there
This Potentially resolves #11633
I would suggest improving the vehicle move event and/or adding a "mount steer event" and completely stop calling the player move event for passengers
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
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)
[PaperMC/Paper] Pull request review comment: #11836 fix more incorrect array nullability annotations
Wrong way around.
The arrays are not null, its elements may be.
Same for below.
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.
Plugin and Datapack List
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)...
Unable to reproduce now in 1.21.4 with the given reproduction code + video, I'm able to repeatedly use /me test and still chat/run commands fine after
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.
It seems like this behaviour was changed in 2018 by spigot when they made the block fade event also be called for path blocks turning to dirt. Instead of adding an event call to the path block class, they instead moved the call to the turnToDirt method, (unintentionally?) making the event also be called for trampling
Issue was diagnosed in discord, turned out to be caused by another plugin
Yeah, makes sense to me. I think I originally went with wrappedBukkitCommand + Cached to match the naming of unwrapped + Cached and wrapped + Cache directly above.
Maybe Owen had a reason to go with the original naming, but in isolation I prefer cached + WrappedBukkitCommand.
This definitely seems like it was unintentional
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
Vanilla logic dictates that a snow block with only 1 layer has no collision shape
That's not gonna happen. With the planned setup we can just go back to using citizens.
Also fair if that is not something you are interested in.
Thank you anyway for the work you put into the PR :+1:
Closing this after long long discussions and the nice POC work of yannik, which ultimately did show that maintaining something like this will be too much in upkeep / api development when existing third party projects are already more powerful and have more fleshed out API.
Discussion Category: Ideas
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
[PaperMC/Paper] New comment on pull request: #11836 fix more incorrect array nullability annotations
Is that even relevant to do before the jspecify migration for not null types that are not wrong? there's also some formatting issues for World#getLoadedChunks, SimplexNoiseGenerator#dot
[PaperMC/Paper] New comment on pull request: #11836 fix more incorrect array nullability annotations
Yeah, should do it. The jspecify migration is just gonna happen in chunks when you modify a file, I donโt think thereโs gonna be one โhugeโ PR to do it all at once. Reviewing it would be a nightmare
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.
PS: Very new with the new contribution system.. currently the ExplosionServer has unused CB imports but if remove that the fixupSourcePatches just fails
Pastes have expired and the creator's account has been deleted, closing this as incomplete
Closes #9854
Switches two maps in CraftMapView that use a player as the key to be a weak map. I confirmed with a debugger & a heap dump that this properly cleans up the entry in the renderCache and canvases maps after a player logs out & a gc happens.
Okay so, from my understanding, there is no need to adopt virtual components because we expect them to die on any interaction with the API and the server can/should just treat them as text component impl.
Thank you zml for the insights on that <3
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.
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 ...
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\"}],\...
The goal of the build workflow is split into multiple requirements.
- Run on pushes to same repo.
- Run on PR open/reopen/syncs from repos that are not the same
(PRs from the same repo are covered by 1) - Run on labeled PRs that have the build-pr-jar flag.
ca8709b Fix more incorrect array nullability annotation... - Machine-Maker
e10dcbf [ci skip] Improve build workflow conditions (#1... - lynxplay
Should be resolved now that we bumped to adventure 4.18 ๐
57fce6f update comment - Machine-Maker
b4051db Handle disabled vanilla registry values correct... - Machine-Maker
[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)
4b89390 Fix contextual map renderer memory leak (#11841) - Warriorrrr
I generally also do not seem much use for this?
The only place where this might be useful would be the folia async scheduler, which already has methods dealing in TimeUnit and longs.
But yea, don't think this PR in this form is something Id wanna pull
Totally missed it on my first review, but welcome to paper :partying_face:
Great first PR and thank you for your work!
Totally missed it on my first review, but welcome to paper ๐ฅณ Great first PR and thank you for your work!
Tyvm.
Although you might missed this one.
Well get congratulated twice then xD
c702417 Add support for component dropping + simplify - Owen1212055
This implementation has been dramatically simplified, and now supports dropping components. So for example, unbreaking is now hidden.
So we decided that there should be 10 methods added here
The methods make sense. Did you decide to go with the same naming for every method instead of separating inventory & arbitrary as proposed earlier?
Yeah, I think the parameters and the javadocs will make it clear what happens. I think also, the ItemStack methods will make defensive copies, so dropping a stack from the inv wonโt actually drop it, just copy it.
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
Diff dropped during hardfork.
Resolves: #11844
Expected behavior
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
Paper version
Other
No response
Pretty sure this is not a paper issue. Tell the author of that plugin to update their dependency to 1.21.3.
If they need help figuring it out, they are welcome to ask in the #paper-dev channel in the PaperMC Discord server
- You are using Purpur, but this is the paper GitHub
- The author of UltraBind just has to compile the plugin for 1.21.3
e0abc5f Do not spawn fire for visual lightning (#11845) - lynxplay
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
- Call:
player.getLocation().getWorld().spawnParticle(Particle.FIREWORK, null, null, player.getX(), player.getY() + 50, player.getZ(), 1, 0,0,0, 0, null, true); - 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...
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
- spawn a mob (pig for example)
- invoke the
Mob#clearLootTablemethod (or set it to null) - 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
Incorrectly updated by spigot in 1.21.4 as the new flag 'alwaysShow'
does not force the particle to bypass all limits, but instead only
controls if it bypasses the particle amount setting on the client like
'decreased'.
Resolves: #11847
Superseded by the mentioned PR above
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.
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.
This PR adds resetLootTable and getDefaultLootTable methods while also prioritizing the defined loot table when one gets generated
Resolves #11849
int max value feels a bit weird
this can probably just be moved to the impl and use the size of the stack
@Machine-Maker alright, I have changed the methods to reflect the ones you have listed above.
Also, just to confirm, the dropItem(ItemStack) one does indeed make a copy. So running that logic on an ItemStack currently in the inventory (I tested it on the currently held one) drops it without reducing it
Changing the entire behavior of mob loot tables is pretty much a non-starter here
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
Alright, I didn't really expect anything else
gonna change the docs like you said in the issue
0336f2a Add plugin source to API - lynxplay
Using this event to set an arrow fails when the player looks at a block instead of air (it still gets called).
I don't see an obvious reason for that.
feb8756 Add datapack registration lifecycle event (#11804) - Machine-Maker
[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.
18da1ae [ci skip] update DiscoveredDatapack javadoc - Machine-Maker
[PaperMC/Paper] branch deleted: generators
[PaperMC/Paper] New branch created: generators
Yeah, the event shouldn't be even called in this case, as the event is for when dropping from the inventory. That will solve this issue.
Yeah. @lynxplay is making that change now.
This PR aims to fix a bug in Minecraft in which a custom biome which is cold enough but does NOT have precipitation will accumulate snow on the ground during rain.
The biome will not visually snow, but the snow will still form on the ground.
This has been reported on MoJira MC-248212 and is marked as a bug.
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:
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?
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 :
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));
});
}
@Malfrador I tried on another ways (like a custom command with CommandExecutor), I have the same problem. It looks like that it don't come from a specific event or whatever what.
Maybe a patch from Paper who have override the Player class ?
287eb52 Use hidden classes for event executors (#11848) - SirYwell
Then you mean a new event "ExplodeEvent" for handle all the explosions, like a merge of the current entity and block not?
This require send a canceled state of this new event?
PD in teory just need call this new event in the sane place but later of the bukkit?
I have opened an issue https://github.com/Tuinity/Moonrise/issues/87 to hopefully get the issue better tracked.
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.
This PR aims to fix the RETAIN_PASSENGERS teleport flag not actually teleporting passengers.
I'm not positive if this is 100% the way to do it, but it's working.
Open to suggestions.
(ignore all my commits, had a lil branch issue)
Fixes #11003
Do we even need a message like that. Like if they are using velocity online mode, can't we just say "Using Velocity for Authentication"?
[PaperMC/Paper] New branch created: chore/checkstyle
1ffbfe6 beginning of checkstyle configuration for API - Machine-Maker
Do we even need a message like that. Like if they are using velocity online mode, can't we just say "Using Velocity for Authentication"?
Technically this server is still not authenticating usernames. It's just trust Velocity's checks.
The checkstyle configuration for the API. The server's will come later and be mostly similar with some key differences (like javadocs and excluding decompiled sources).
8076728 remove redundant bit from include filter - Machine-Maker
If someone will be interested out of curiosity in the future, I have set up https://paper-jd.masmc05.dev/ and https://github.com/masmc05/Paper/tree/auto-sinces which I will maintain some time with up to date with a CI, so everyone could look when certain api was added
The fix in principal looks good here, however, I am more curious why we are not using the vanilla teleportion logic in all cases.
Looking at the logic in teleportSameDimension, it seems pretty extensive behavior that we are not doing here. (Teleport transitions being sent to players, etc)
Not a blocking comment, but curious what others think here.
I have an open PR (old paper) that changes the logic to use vanilla's
Removes experimental from @Contract(mutates=) which we use a bunch
You can take a look at what I was planning here https://github.com/PaperMC/Paper/pull/10734
Updated documentation to specify that setting a null loot table resets it to its default behavior.
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
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
I have no idea about velocity, but is there a risk here? you can't bypass velocity like you can with bungee, right?
so the only risk is that you configured velocity incorrectly (i.e. not authenticating there) or you configured a velocity instance that you don't control, I don't think we need to tell the user to "beware" for that (especially without suggesting concrete actions)
One or two years ago we had a discussion about a different message and the outcome was how it is now (just the firewall link)
I dont think there is any change necessary
The logic here is flawed and a bungee mode server in which a user has said velocity online to true would trip this message improperly; This is also generally not stuff that I see the need to throw time on
[PaperMC/Paper] New comment on issue: #11856 Map updates are ignored on the initial call to render()
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.
cough This is why I shouldn't open tickets from things I understand nothing about ๐
Thanks for the help though! :)
From a 2 second glance, looks like mojang changed some of the logic here and that collides with an optimisation we have to not waste time doing stuff that won't be sent to the client?
hm, no, nvm, it's not what I was looking at, that logic is still fine
What's the use of this?
FallLocationType maybe? Rn it sounds like this is actually holding a location
It should just be immutable/say it's a copy
Thanks for taking a look, really curious as to why this started happening ๐ค
Pretty mysterious bug we seem to be looking at here.
Updated the wording to state it's a copy.
Haven't made this immutable because it's returning a copy internally each time, so modifications are safe. Otherwise, users would need to make a copy of a copy.
"Sneakily" setting prior combat history without overriding/resetting active combat state.
It's a neat shortcut for providing fake pre-made combat history scenarios and producing specific death messages.
Yes, the Type makes more sense
This pull request fix just a word into javadoc of Attribute class which is caused by Spigot.
Just a small fix into javadoc of Attribute's class for spelling the ignition's word caused by Spigot.
The Paper comments are not needed with hardfork ๐
The Paper comments are not needed with hardfork ๐
Oh ok, I fixed it.
Those spaces are kinda out of place, either the whole file needs to receive them (most probably bad without a maintainer's approval), or remove here the diff that adds them
These spaces was due to my old Paper comments (which was uselesss), I fixed the spaces. Thanks.
Those spaces are kinda out of place, either the whole file needs to receive them (most probably bad without a maintainer's approval), or remove here the diff that adds them
These spaces was due to my old Paper comments (which was uselesss), I fixed the spaces. Thanks.
The issue was within the drawImage method, there's an optimization in there to copy the image to the map in a more efficient manner, but doing so it was failing to mark the altered pixels as changed, causing them to not be sent to the client. I've created a PR that fixes this, and the reproduction code works fine with it.
Wohooo, that sounds amazing. I'll also verify if it's working as the new build of paper comes out and if all is good I'll close this issue as well as the other one on the ImageMaps repo :)
not sure about this, did this logic allow using negative values to support offsetting an oversized values?
3115a49 Ignore if obfuscated - Owen1212055
b99c3fb Ignore if obfuscated - Owen1212055
2754c27 Remove comments, pass registry access, remove e... - Owen1212055
I didn't think about that, I added that because the current impl will throw if a negative value is supplied. does seem like the old impl works with negative values, so I'll try seeing if I can fix that too
Yeah after some thinking there's no real good way to convey all the decent information. I'll just close this up lol
similarly, but maybe more useful, I created https://minidigger.github.io/api-diff/ which automatically diffs the different paper api versions (plus can also generate a report of sinces)
https://github.com/MiniDigger/api-diff
https://minidigger.github.io/api-diff/since.html
https://minidigger.github.io/api-diff/diff-1.21.3-1.21.4.html
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.
There is a general concern over changing what plugins end up seeing, but, some level of "kicking the can for 10 years" doesn't help either; Moving back to vanilla handling of stuff is pretty much always better when viable (assuming we don't 'lose' out on something)
Understandable, in which case this is fine for now.
General cleanup can be done in another PR, but would rather have this fixed sooner than later.
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...
I am not really familiar with the internals here, but maybe it would be possible to add a builder method or something to be able to create a copy while keeping the original object unmodified
They would return a new CSS instance
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
For the sake of completion and because Minecraft's CSS also has this method, CommandSourceStack withSender(CommandSender sender
This one sounds like it'll end up misused a lot, and without many real usages other than a plugin (either the same one or other plugins) not working great with withExecutor
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
- Set up a PaperMC server with the latest version.
- Ensure a player has placed a skull (player head) of another player on the server.
- Make sure the player whose skull is being used is offline.
- Attempt to display the skull.
- Observe that the skull either appears blank or does not load at all.
- 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...
nms's CommandSourceStack#withSource isn't used except for debugging, so no, I would 100% be against adding that.
nms's CommandSourceStack#withSource isn't used except for debugging, so no, I would 100% be against adding that.
fair enough, didn't know that, so that one's out of the table then
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
Hey!
I made a test on my side, I don't have any problem with the skull of offline players :
How did you generated the skull ? From /give ?
There is the command that I've done to get it :
/give x9nico minecraft:player_head[minecraft:profile={name:"JumperBoost"}]
94ce9b1 only run on changed files for specific users - Machine-Maker
User not found.
I made another test (user Likaos), the skull is not the good :
It looks like that sometimes, the texture is not the good one.
My command again :
/give x9nico minecraft:player_head[minecraft:profile="Likaos"]
Are you sure you have online mode enabled?
Are you sure you have online mode enabled?
Oh yes it's enabled, maybe it's for that, my bad sorry.
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
Online mode is enabled yes, me and my friends we all tried it in localhost, there it doesnt work but on our public server it does work
Tested this with a bunch of offsets & image sizes and it works the same as it did in CB now
60edd61 [ci skip] Fix spelling of ignition's word into ... - x9nico
@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)
Ok, this is ready to be reviewed. I'm sure there will be things we notice when we start updating all the files it tells us to that we don't want, but we can make those changes as we go along.
This also isn't validated against any formatter yet, so there could be conflicts. We will find those out though as we go.
d1327d6 output command line errors - Machine-Maker
12effdc properly log command line errors - Machine-Maker
1f48f90 include regular output in error - Machine-Maker
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.
How are you creating the skulls? The only behavioral change vs spigot that I'm aware of is that we use mojangs ItemStacks for everything, which makes a spigot change more likely to result in profiles on skulls not applying properly due to a race condition they induced
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)
Looking forward to this being accepted :D
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...
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
Ok based in the comments here and in discord i rework this PR for keep the changes but also the new calls just being called in the new event called...
i dont like "duplicate" the CB code for the paper event but dont wanna mess with strange behaviours for use the same method for call the paper event and make changes...
Spigot already randomizes the player list
the player-shuffle options controls the behavior for that
https://docs.papermc.io/paper/reference/spigot-configuration#settings_player_shuffle
that's shuffling the connection list, this is controlled by the entity tick list; I'm not sure that shuffling that list is really viable
Would it be an option to have the entity tick list cloned on player pick up and thatโs the list that is used for pickup orioroty. So could shuffle prior maybe? Or a similar system to spigot where it shuffles on a timer but it shuffles a cloned list only used for this?
It turns out that the method for this is called from the player tick logic from the network list, which already has a config option to shuffle it inside of spigot.yml, so, this is likely already solved?
Oh right so it is from the connection list linked above? Will test it
a37eba9 refactor a bunch to use task caching - Machine-Maker
No Block. It's always air, location is enough.
Then remove the getBlock methods?
Just BlockState and Entity?
adfe848 actually use file contents provider - Machine-Maker
So there's a ton of new logic now in the api's build.gradle. This should probably be moved somewhere, idk if we wanna do the buildSrc thing, or make it part of pw, or what
If we are going to stick with the "mutability" of this list, lets make that clear in the javadocs that the expected behavior is to mutate this list.
I was debugging villagers and I noticed that the reduce on the stream has massive overhead so I decided to unroll it.
Here are sparks for before and after:
Before
After
Those numbers are with 229 active villagers on R7 5700X with 64GB of RAM.
Here is the test world:
world.tar.gz
I was debugging villagers and I noticed that the reduce on the stream has massive overhead so I decided to unroll it.
Here are sparks for before and after:
Before
After
Those numbers are with 229 active villagers on R7 5700X with 64GB of RAM.
Here is the test world:
world.tar.gz
This can use a pattern instanceof, plus the entity != villager can be taken out of the negated part to be easier to read as was shortly talked about in discord
Since it's changing minecraft code, this can still use some paper comments
You are right, I forgot about that, will do.
The profiling results look very impressive. You may have forgotten to return the winner to ifPresent? .reduce
The profiling results look very impressive. You may have forgotten to return the winner to ifPresent? .reduce
The result wasn't used at all before so there is no need to return anything because the only thing it does is the sideffect.
As per https://github.com/PaperMC/Paper/blob/main/CONTRIBUTING.md#imports, FQN are for patched vanilla files, you can use imports
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...
I think this would be better asked in discord, but can you test that your mocked item registry indeed has a value for barrier?
And maybe check out https://github.com/MockBukkit/MockBukkit, they have a lot better mocking of libraries
They're still working on 1.21.4 support, but, this API just quite simply cannot work inside of an API only environment, it relies upon implementation-specific data
NonNull annotation is redundant in a NullMarked class
This doesn't seems to be safe to pass null here?
Don't mix nullability annotations either convert the class to jspecify or keep using jetbrains one for now
Yaw and pitch looks inverted here?
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.
Steps/models to reproduce
- Create a paper-plugin.yml (very basic : package.Main class, Name, author, version, api-version)
- On your pom.xml, add into
<builds>the plugingit-commit-id-maven-plugin(version 9.0.1). - Into
<version>set it to<version>3.0.0 (${git.commit.id.describe-short})</version> - Set this into your paper-plugin.yml : version: ${project.version}
Plugin and Datapack List
No datapa...
This has nothing to do with Paper as you were already told on Discord.
b6e5ec7 move to convention plugin - Machine-Maker
When make https://github.com/PaperMC/Paper/pull/11840 i notice a few missing annotation in DamageSource where custom fields has the Nullable annotation but the get methods added or a few parameter not.. this PR just add things missing things for make more clear in IDE the nullable thing...
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...
'using' is a specific game concept, i.e. consuming food, using a shield, drawing a bow, etc; it does not cover general interactions/attacks
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
In the Bukkit location, the yaw comes before pitch. That's what I used as a reference here. I am not sure whether this is the same in NMS terms
Strange i test that in a fresh server and just get the value for deaths. (need people for test the other stat)
you sure the plugin its not mess with the behaviour for kills?
Strange i test that in a fresh server and just get the value for deaths. (need people for test the other stat) you sure the plugin its not mess with the behaviour for kills?
Yes, I'm sure. I only have this in my plugin.
I am also not able to reproduce this.
Do you by any chance have statistic saving disabled? You can disable that in spigot.yml, stats.disable-saving
I am also not able to reproduce this.
Do you by any chance have statistic saving disabled? You can disable that in spigot.yml,
stats.disable-saving
No, I didn't disabled the saves :
stats:
disable-saving: false
forced-stats: {}
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
- Use the latest devbuilds of Paper 1.21.4.
- Whitelist a players
- 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
The request was blocked by mojangs WAF, we have 0 control over this
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...
can you update it to 1.21.4
Just tried the newest version. The whitelist state still seems to be reset after server restart
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...
Right sorry, this only took care of part of it
Updating gradle from 8.10 to 8.12 fixed the issue
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):
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):
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(...
Can reproduce. There is already a recent PR that should also fix this issue by the looks of it: https://github.com/PaperMC/Paper/pull/11865
I added the build-pr label to it, there should be a paperclip .jar that you can run on appearing on the PR soon. Could you test it with that?
ffa4118 [feat] add config option to configure shared en... - electronicboy
[PaperMC/Paper] New branch created: conf/shared-random
I added the build-pr label to it, there should be a paperclip .jar that you can run appearing on the PR soon. Could you test it with that?
This pr does indeed fix most of the issues. The only difference from before is that transparent pixels from the drawn image are actually drawn as "transparent" instead of ignored, but an argument could be made that this should be the intended behaviour.
Build using the gradle wrapper in the repo, not your system gradle install
Closes #11878.
I accidentally broke this during the hard fork, since properties is the name of the existing map this compiled fine.
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
Still strange if you test in a fresh server with new map and well adding to the stats (like using kill) that output not change... i still cannot replicate that.
In that case, how is it possible that the Bukkit CSS has their withEntity nullable?
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...
[PaperMC/Paper] Issue opened: #11882 Entity Has Delayed Falling when Piston is moved from under them
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
When an entity is ~50 blocks away, there is a significant delay (several seconds) before they fall from gravity via a piston.
sounds like entity activation range, this would be expected if the entity is outside of that range, they won't realise that they're falling until they next tick
The JOML javadocs currently aren't linked properly in the paper javadocs as the base url is wrong.
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...
Cannot assign requested address: bind
invalid IP address (also, please don't bump 6 year old issues)
The some events is inconsistent with the vanilla and the description in javadoc.
This commit may have fixed these issues.
[PaperMC/Paper] Issue opened: #11895 Redundant awaitingPositionFromClient check in handleMoveVehicle
Expected behavior
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...
Given no one else picked up on this, I'll be closing this as I do not think we'll be merging it.
You can try bothering leaf with it on e.g. the AsyncScheduler as mentioned, but yea.
edde726 [ci skip] Add missing Nullable annotations for ... - Doc94
Agreed with @emilyy-dev . The underlying issue should be fixed so the exception is not thrown at all. It can be avoided in this case. First to fix the swallowed exception and to fix the issue with moving piston.
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.
i make the changes with the same code or the original (where i call the cooldown later) works like the same by the moment.
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 ...
Can reuse the now pre-fetched holder in here
Reported in discord TargetHitEvent#getSignalStrength() return just 20 or 8 based in the projectile this behaviour is a side-effect caused by hard-fork where pre-hard-fork the value used is called "i" (ref: https://github.com/PaperMC/Paper/blob/master/patches/server/0441-Add-TargetHitEvent.patch) but now is called redstoneStrength and i is just used for another thing.
Yeah, this is just a fundamental problem with how EnchantmentOffer is structured. It should've never been nullable in the array and instead had a nullable enchantment so the cost could still be set. I think it's fine to just revert to handle it like vanilla.
You also need to update the usage of i inside the last hunk in that file, the call to awardTargetHitCriteria.
I was pretty apprehensive around sending stuff to the client as now you introduce latency into the mix
fixes #11545
pre hardfork #11556
fixes #11655
pre hardfork #11716
#11511
pre hardfork #11555
I was pretty apprehensive around sending stuff to the client as now you introduce latency into the mix
latency?
well for me is like the same than just set another cooldown, this is an alternative for avoid make a thing like change cooldown based in when need more or less time in the item for avoid the visual desync.
Allows the editing of signs that are not placed on the server as text-input without meddling with packets.
Expected behavior
Observed/Actual behavior
Steps/models to reproduce
Plugin and Datapack List
Plugins: AuthMe, BlueMap, BreweryX, CoreProtect, FlectonePulse, ForcePack, GSit, LiteBans, NoChatReports, ProtocolLib
ServerLinksZ, SkinsRestorer, voicechat
Datapack -
Paper version
1.21.4 build 72
Other
No response
fixes #10869
pre hardfork #11569
You are running an unsupported environment (offline mode) which we do not support, you have also provided no context to the issue or means of reproduction
resolves #8729
pre hardfork #9998
new pr #11906
Discussion Category: Ideas
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.
closes #9942
pre hardfork #10237
Make sure to look at my last comment on the old pr hardfork PR (i still think this is the case)
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.
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.
Resolve https://github.com/PaperMC/Paper/issues/11893 by adding pattern methods like location but for orientation, also based in another PR make a clear for the pre-fork comments in the class based in the new style for api.
I am semi convinced, set/add/substractRotation might be nicer to not confuse peeps too much.
I am semi convinced,
set/add/substractRotationmight be nicer to not confuse peeps too much.
hmmm yeah add "rotation" like suffix in the methods can make more obvious the behaviour of that methods
Idk if I like the prefix "unchecked". I get what this is meant to do, but couldn't we just call it UnknownSignChangeEvent similar to PlayerUseUnknownEntityEvent and only call this in the path of no sign actually being there?
Idk if raw is the right thing to use here when usually the filteredOrEmpty output is passed through StringUtil.filterText.
is local the right name here? do we use that naming elsewhere? maybe virtual?
and I think the event that is used for the change should be mentioned here
why is this event always called, shouldn't it be only called if the if below is false, as in, the server doesnt know a sign there? the method and the event are connected and should only work together the way I understand it, plus the the naming can reflect that
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
You can probably fix it by disabling commands.fix-target-selector-tag-completion in the paper-global.yml.
eccf1aa abuse less static state - Machine-Maker
16dbb25 early out in getAssetObfuscation - Machine-Maker
6ab1352 Improve performance of PoiCompetitorScan by unr... - ChromMob
33a590b Fix TargetHitEvent#getSignalStrength() post-har... - Doc94
9f90b4c Fix ItemDamageEvents called for 0 damage (#11900) - notTamion
I am unsure if breaking actually works here given that LivingEntity#onEquippedItemBroken isn't called if the item breaks.
Might be better to just not allow breaking. Needs investigation.
Is there any difference in ONE vs ALL/SOME?
ALL means the entire stack is gone, SOME means some is left.
What is the benefit of ONE here? Unless I am missing a mechanic of only inserting ONE item.
the hard fork being so peppered with typos seems like cause for concern, is there no way we can scan the post patched source in comparison to pre hard fork source to find these typos?
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.
yeah i think i for some reason thought that such a mechanic existed. my mistake
No need for paper comments, all of this is file patches xD
oh right, forgot that method was basically turned into pure cb code
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...
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...
Lets instead add overloads to CraftRegistry.minecraftToBukkit and CraftRegistry.minecraftHolderToBukkit that take RegistryKey so others can use this and we don't have to do the full RegistryAccess.registryAccess()
Lets instead add overloads to CraftRegistry.minecraftToBukkit and CraftRegistry.minecraftHolderToBukkit that take RegistryKey so others can use this and we don't have to do the full RegistryAccess.registryAccess()
you mean move the RegistryAccess.registryAccess() to CraftRegistry or the new method using the RegistryKey and handle in a own way?
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
well actually,
minecraftToBukkitandminecraftHolderToBukkitshould 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 CraftRegistryminecraftToBukkitandminecraftHolderToBukkit
hmm im lost in there xd
if you wanna handle because (maybe the time) dont fully understand the changes in the implementation
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...
[PaperMC/Paper] New comment on issue: #11912 Default to not creating snapshots in BlockState getters
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.
[PaperMC/Paper] New comment on issue: #11912 Default to not creating snapshots in BlockState getters
Yeah I'd definitely expect a degree of change management to be required. This did suddenly switch to snapshots in the past too, so this method changing is not unprecedented. It does definitely make sense to go alongside some other cut-off point. Either while 1.21.4 is experimental, or alongside 1.21.5/1.22.0
[PaperMC/Paper] New comment on issue: #11912 Default to not creating snapshots in BlockState getters
I know more than one plugin that relies on storing snapshots (and restoring them later by calling update) that this would break. I feel like deprecating to show people the new method is better
I tested the above and it worked fine @Toseflo. Can you please confirm if it sorts it for you too? I don't believe it will fix it for existing entities though.
Hey @JHarris12345, did you get around to testing this? If so, how did it go?
Hey @AkotoWeed, are you still experiencing this issue? If so could you please provide how you're creating the skulls as electronicboy asked? When I give myself the skull of an offline player with the Vanilla give command, I have no issue.
1c35f64 use checkstyle to create a much nicer nullabili... - Machine-Maker
just going to bump this and ask people if this is still something you want? there are some fair points against having this in paper (e.g. plugins not working correctly even though they are enabled and that giving a sense of false security)
links to the discord convos about it:
#hardfork-discussion message
#paper-contrib message
#paper-contrib message
Discussion Category: Ideas
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)
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
Setting it to false indeed fixes the issue
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
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?
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: @.***>
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
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:
@.***>
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...
After NullMarked, only need to use the jspecify Nullable annotation.
Lets put this in a separate enum inside the package. If we ever add the buildable/reusable builder that doesn't have location/direction, we will regret having this enum inside this type. Make it just like RayTraceTarget with ENTITY and BLOCK or something.
Use @NullMarked either on the interface or a package-info in the new package.
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
- Go to the nether
- Hit the zombified piglin in survival mode
- 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
[PaperMC/Paper] Issue opened: #11920 PaperMC 1.21.4 - V75 Bug. Redstone issues - EXPERIEMENTAL BUILD
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...
I can confirm that keeping aggravation is intended behavior.
That happens in Vanilla as well.
It is documented on Minecraft wiki and also happens on my test as well.
I do not believe that this is a bug.
I can confirm that keeping aggravation is intended behavior.
That happens in Vanilla as well.
It is documented on Minecraft wiki and also happens on my test as well.
I do not believe that this is a bug.
Not piglins. Zombified piglins.
My mistake. I mean zombified puglins on my reply and it mirrors Vanilla behavior on the switching gamemode part.
"A player's death causes zombified piglins to become neutral toward the player if the gamerule forgiveDeadPlayers is true.โ" - also doesnยดt work
My mistake. I mean zombified puglins on my reply and it mirrors Vanilla behavior on the switching gamemode part.
Yeah, really. But also them doesn't stop attack the player after death
I've tested both the claim of them never forgetting and the forgiveDeadPlayers gamerule. Both are working properly on my case.
You're right in that errors shouldn't be hidden. I'll get back on this once I steps to reproduce. Thanks.
Yes I definitely think this would be useful. Jes this gives no 100% security (nothing can give that), but it can avoid accidential starting the server when there definitely is a problematic misconfiguration
Discussion Category: Ideas
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));
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
[...
Hmm... I'll have to check again.
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
Are these first lines really needed? I feel like the last two are enough or am I wrong?
I cannot replicate this.
A dropped with a single unstackable item (in my case an iron shovel) has the comp read a signal strength of 2.
Is there anything you changed in configs? Is this replicable on a completely fresh server?
No point telling them to switch to timings.of since timings will be removed soon
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
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.
This is still happening to me ;-;
This is a vanilla issue that's been marked as fixed in the next update: https://bugs.mojang.com/browse/MC-278683
Also unable to replicate, the signal strength for an unstackable item is 1 while in a chest/crafter, and 2 while in a hopper/dropper/dispenser. Repeated the test in vanilla and got the same result
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.
No config was changed, tried also in a fresh server of the same seed and also a fresh server of a random seed. Also tried in different coords of the server where the issues originated from and was still having the issue. With a vanilla 1.21.4 (from mojang official), the Redstone issues didnโt arise.
Maybe can be good mention spark here and maybe an alternative for what this class is used (?
This bug disappeared after restarting the server and updating paper to 1.21.4-76-main@486e521.
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
I restart the server and update paper to 1.21.4-76-main@486e521. Mainly zombified piglins stop aggro, but some bugged zombified piglins still killing me after death again and again.
Video:
https://drive.google.com/file/d/1xnIUziLagPDoTWMolX0wLzONxmiec2gx/view?usp=sharing
If we can't replicate the issue, there isn't much we can do. How are you testing this? What's your build setup?
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.
Is there maybe a point in only yanking the cost if the cost wasn't present pre-event call? To allow the native vanilla layout for enchantable items without breaking plugins that actively want the offer to not be sent?
Given this API will just need to be deprecated anyway, a bit of salvaging might be worth minimal breakage
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
This PR aims to provide more fields to the MusicInstrument currently this class with many deprecated methods for the instrument but not provide any method for the fields in instrument https://minecraft.wiki/w/Data_component_format#instrument like the description or duration.
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...
Looking at the git history this is broken since 1.14. This fixes the CB loot table API to properly support the luck and random setters / to actually do something with them.
Any reason to not have an underlying Shulkerbox block entity? this means getType on the view doesn't return the right type and putting a shulkerbox inside the container has a weird behavior.
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.
Adventure related methods shouldn't have a get/set prefix and getSoundEvent feels a bit weird i don't think the api has any of that actually except registry keys fields. It's okay to have them in the instrument itself in the future the value could be created via an inlined builder like Art#create in the component.
We should 100% fix the fact that a shulker menu from an API that is 100% focused around menu types is opened as a generic 9x3 because of CB code relying on the inventory type to figure out the MenuType.
Is it opened as a 9x3? I was under the impression only the InventoryType was incorrect. I'll take a look when I get a chance.
Yea, CraftHumanEnt#openInventory(View) has the fun bit of logic that is
// Now open the window
MenuType<?> windowType = CraftContainer.getNotchInventoryType(inventory.getTopInventory());
so the type relies on the inventory type
That method is a real sore spot. In this case I must pass the entity until we go back and replace that internally. Easy fix I guess when I implemented it I ignored it because I didn't care about the distinction with the fake menus. Either way yeah sloppy as hell impl and easy solution.
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.
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
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
No, there is no interest in burning the entire ecosystem to adopt an alternative JVM platform which comes with its own pros and cons. native images do not support loading jar files and would require a whole bunch of work to adopt a mechanism to support this for very limited gain.
So what could be done to improve performance without going the Folia route?
So what could be done to improve performance without going the Folia route?
This isn't the best place to discuss this, @SolsticeSpectrum. You can join us on Discord and provide a spark report in #paper-help along with the issues you're facing and someone may be able to help you with your performance!
I wanted to be extra clear, since the majority of people asking about this in paper-dev seem to be new to plugin development (or development in general), so I wanted to make sure they go to exactly the right place.
That being said, the stacktrace will also show the right location, so maybe it's indeed too verbose?
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
Also cannot replicate this, are you sure nothing in your plugin might mess with stats?
It might make sense if this method followed the same logic as item pickups in vanilla, which is first putting items into the offhand if it contains an item of the same type
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.
@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?
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?
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
Can reproduce, this seems to be caused by a missing return statement..
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
b34ae4f Fix wolves ignoring result of damage event (#11... - Warriorrrr
@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.
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...
efdcaa2 Fix removing the "LootTable" nbt tag from Block... - 456dev
What is the point in also checking the negated doDaylight here?
Just a performance improvement to potentially reuse the world packet?
[PaperMC/Paper] branch deleted: feat/component-obfuscation
https://github.com/PaperMC/Paper/pull/11817 was merged, the config looks different so you will need to adopt the changes.
08fc33c Update CustomTimingsHandler Nag Message (#11923) - spring-dependency-management
Expected behavior
Looking at an entity/hitbox should add the UUID from this entity to the brigadier entity selector argument.
Example:
Observed/Actual behavior
Looking at an entity/hitbox does not add the UUID to the entity argument.
Example:
Steps/models to reproduce
- Look at an entity
- Enter any command including an entity selector argument (e.g.
/kill ...) - 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.
There is no /tick skip command, but when I tried this with /tick step 1000 instead nothing weird happened, since the game just runs at 20 tps for 1000 ticks. Could you try this again in 1.21.4?
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
18eab3c Fix MapItem incorectly fetching water biomes on... - Owen1212055
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...
if you need a temp workaround in the meantime you can use stackwalker to figure out where the event was called from :P
The alternative is this new api: https://jd.papermc.io/paper/1.21.4/io/papermc/paper/world/flag/FeatureFlagSetHolder.html#isEnabled(io.papermc.paper.world.flag.FeatureDependant), the javadoc should be updated to point to this as the replacement.
fromBlock(0) could just be left as 0
Did that for just logic consistency-- it shouldn't really matter.
The skip was of course a typo. Will try to reproduce in 1.21.4
Yea, if the world time is frozen already there's no need to spoof it, so we can reuse the packet
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....
The hash needs to be a sha-1 hash, which is always exactly 40 characters long
Oh that's true, i was using SHA-256.
Thanks
Unnecesary NotNull if the class has the NullMarked annotation
This is used in another places.. this change not break any?
No, the boolean is set to true. Take a look at the changes below.
Yeah, the NotNull annotation was created by Intellij. Will remove
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:
Hm yeah I can try to find a better name for the class (my personal favourite would be PlayerLoadedPacketEvent or the name you provided).
I added the Cause so that people can make a difference between the client actually setting it's local state to loaded or the server doing it, I personally don't need it.
Since lynxplay mentioned bad naming, I have some suggestions
What do you think about renaming this to PlayerWorldLoadEvent? It's main cause is the client side world finishing being loaded, and the name would be consistent with https://jd.papermc.io/paper/1.21.4/io/papermc/paper/event/packet/PlayerChunkLoadEvent.html
What do you think about renaming this to PLAYER? Since it's the player that triggers this, the api doesn't need to have details on how the player triggered this
Also I think maybe just a boolean #timeout could work better than a full cause class, don't think it's gonna evolve into something more than either player triggers this, or server is tired of waiting and force mark as loaded
Thanks, that's actually a quite good name. I will rename the event!
Yeah, makes sense. Fixed
I think you accidentally removed unused imports in the newest commits
Why not PlayerReadyEvent? Because World already loaded at the time of event call, so current event name looks a little unclear IMO.
I don't like the term Ready honestly, renamed it to PlayerLoadedWorldEvent which should be clear enough now.
Generally looks good to me. My only concern is the hardcoded lookup which would need to be updated whenever Mojang does change something there. That isn't really avoidable though.
Missed a // Paper comment here
This seems to be a Paper bug? (Or vanilla dedicated server bug)
Can reproduce on Paper 1.21.4 build 82 (post hard-fork).
Cannot reproduce on vanilla 1.21.4, the bookshelf got updated corretly.
Expected behavior
#paper-help message
old
new
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
weird nitpick but why is it so complex? item obfuscation session, switching contexts, item obfuscation bindings, just seems like it might cause issues with maintenance in future (kind of like how anti-xray is complex, to a lesser extent though)
Indeed a weird nitpick.
We need a session as obfuscation is not enabled on every code path.
We need a context to pass context.
[PaperMC/Paper] New branch created: bugfix/oversized-obfuscation
3d2202c Correct obfuscation of oversized items - lynxplay
4007171 Correct obfuscation of oversized items (#11944) - lynxplay
[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.
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...
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.
Think you may have pressed optimize imports here xD
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.
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 @@
...
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.
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.
Cannot reproduce on Paper 1.21.4 build 82.
Maybe PlayerLoadedInWorldEvent?
PlayerReadyEvent - player ready for what tho xD
`PlayerFinishJoinEvent' and the other one don't work because this is also called when the player respawns.
Realistically, it is an event that is called when the client finished loading into the world.
But yea, I'll throw some names around the PR parties if we can't find a good one xD
PlayerClientLoadedWorldEvent? That would make it explicitly clear that it has nothing to do with Bukkit world loading. And the naming would align with another client-triggered event, the PlayerClientOptionsChangeEvent
Expected behavior
EXP is added when retrieving items from a furnace/smoker
Observed/Actual behavior
No EXP is added
Steps/models to reproduce
- Craft items that total to >= 1 exp, but do not retrieve them
- Restart the server
- 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
I am also good with PlayerClientLoadedWorldEvent but will discuss that with machine tomorrow prior to merge so that rename can be done by us if we do feel like it. Beyond that, needs testing but LGTM.
ea7b961 Fix MapItem incorectly fetching water biomes on... - Owen1212055
[PaperMC/Paper] branch deleted: fix/map-biome-check
b242f1e Prevent day cycle on the client when using fixe... - SoSeDiK
Can you explain each of the changes and why they're needed?
3e42518 Fix snow accumulating in custom biomes without ... - ShaneBeee
Should be named EntityEffectTick or EntityPotionEffect tick, I think I'd prefer the first (since it's technically not always associated with potions or potion specific effects)
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
When I opened the original PR I was honestly stumped how FilteredText is used on the server, so I guessed I'll use the raw text the player entered. Does anyone have proper insight how this system is actually used?
Please provide how you're creating the skull then
3d9ecc4 Log thread check parameters when the thread che... - Spottedleaf
Beta 8 required gradle 8.11.1, your intellij is using 8.10 here. You can configure intellij to use the gradle wrapper to avoid issues like these in the future
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...
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 :)
I'd leave out final local variables for now to still be able to instantly find "not clean" code, and this one is easy to do automatically in a single commit through IJ later on as well. Otherwise should be good, anything that looks off we can change when we run into it
a0bec23 move logic out of paper-api build.gradle.kts - Machine-Maker
Also set the initial array list capacity
19ddbef Fix InventoryAction wrong for Bundles (#11902) - notTamion
ac3aaa2 Don't use delayed registries in impl anywhere (... - Machine-Maker
775002a [ci skip] Remove nullable from SyncedEntityData... - NonSwag
c2f24e1 Feat: Add 'with' methods to CommandSourceStack ... - Strokkur424
ed75b0e Disallow calling JavaPlugin#getCommand during o... - NoahvdAa
Did the TemptGoalLookup class accidentally slip into the wrong source tree (src/minecraft/java instead of src/main/java)? Pretty sure it shouldn't be a .patch since it's in Paper's package and not a feature patch
There are class files in Paper's package in both src/minecraft/java and src/main/java, but I believe that src/minecraft/java is for non-API classes, and TemptGoalLookup is not API.
no, src/main/java is for everything not mojang :+1:
It should indeed live in src/main/java.
src/mojang/java only includes mojang types.
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.
ah ok, I'll move it
default it in the API type. No point in keeping it around in internals too.
The behaviour you are seeing is normal, setting the tick rate to 2 will cause it to ignore every other tick, but the spawn delay will also be decremented by two when it does tick. That way the spawner still spawns at roughly the same rate, without ticking as often
Yea ignore whatever I said. Makes no sense. I'll talk it over with some others but I think resending current cool down is still better than not doing anything.
The output seems to match what is expected when I try it in 1.21.4 now, closing as resolved
Yeah that's not a bad way to do it, but you are calling
shouldFollowpotentially 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/...
Looking at this today, this issue seems to be resolved. The part in worldcreator that creates the key now replaces spaces with underscores, and attempting to change my level-name to something with a space also works fine.
I performed a test where I put two fish in the same block of water, one from a bucket and one from /summon, and moved to a point where they were in the soft despawn range. The summoned fish repeatedly despawned, while the fish from the bucket stayed, meaning that everything seems to be in working order
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
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
Steps/models to reproduce
- Enter world with resource pack loaded (either in local files in single player, or through server.properties for the server
- Run the command /minecraft:give Zenologia minecraft:paper[custom_model_data={strings:["bandana1"]}] on...
Close this issue as there is no need to implement it.
Can you please share your paper-global.yml configuration?
While this does work I think it's important to note that Collectors#toList doesn't guarantee that it's mutable, but since that's unlikely to change it's probably fine.
Should be HANDLER_LIST
New events should go into the paper package
I think this line here and in the new event's javadoc could be a bit better, since there's an import it's also not necessary to use the fully qualified name.
* For cases involving entities, please use {@link EntityHarvestBlockEvent}.
The "modifies temperature" part confused me a bit until I looked at the actual implementation, so I feel it's worth clarifying.
* Calculates the temperature based on climate and height.
* @see <a href="https://minecraft.wiki/w/Mob_spawning#Spawn_costs">Mob spawning#Spawn costs</a>
Is there any reason the return type is the implementation while the other two are the interfaces?
Do all these inheritDocs in the impl classes matter?
Was an oversight, was added when hard fork was just added to see how they look like, removed those
The patch that adds the fix target selector tag completion option had some other inherent issues, so it's going to end up being dropped later, once that's done this issue will also be fixed.
Attempting to teleport the vehicle with the retain passengers should work better now thanks to #11858, but the retain vehicle one is likely still scuffed.
Also cannot replicate this, are you sure nothing in your plugin might mess with stats?
Sorry for the wait.
Yeah I have only this.
Also cannot replicate this, are you sure nothing in your plugin might mess with stats?
Sorry for the wait.
Yeah I have only this.
you test in the new latest? also can provide the plugin because for all the cases i cannot make this replicable for any chance...
This is not completely resolved for getHandlers and can you move the handler related methods at the end of the class for consistency with other events. Javadocs could be spread on more lines.
eb4db79 Make CommandSourceStack respect hidden players ... - notTamion
86c6308 Fix locate command dist overflow/underflow (#11... - HaHaWTH
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.
If immutable then why not cached?
Block datas needs to be cloned on every get, since the internal block state is mutable
Right, I forget the API is dumb.
@Lulu13022002 Thanks, pushed a fix
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.
Going to close this, given that Waterfall is EOL, Mojang has changed how server resourcepacks work and the issue happened with a paid plugin so we can't easily reproduce it. Sorry that it took so long.
I am wondering, what really is the rule for interfaces and explicit public modifiers? I have seen files/PRs with and I have seen files/PRs without.
The Javadocs have been removed on this method. Is this intentional, or are you going to be adding different Javadocs soon?
[PaperMC/Paper] New comment on pull request: #11779 Add removal reason to EntityRemoveFromWorldEvent
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...
FilteredText isn't really used on paper at all, it's realms tech.
Raw imo is fine tho, this is "unchecked" afterall xD