Drop fix for MC-125757 #12544
Drop fix for MC-125757 #12544
Conversation
MC-125757 has been marked as works-as-intended, meaning paper's changes to forcefully despawn arrows are breaking vanilla behaviour. Given paper also now implements entity-based time to live options, this kind of behaviour can be replicated by server admins anyway. See: PaperMC#3859
lynxplay
added
the
publish-pr
|
This opens up paper servers to entity overloading? i.e 1 million arrows on bubble columns, or more realistically this: https://www.youtube.com/watch?v=aItr0pRsBa8 |
|
You can already setup entity overloading with 1 million snowballs in a bubble column. As stated in the PR description, https://docs.papermc.io/paper/reference/world-configuration/#entities_spawning_despawn_time_%3Centity_type%3E exists and allows server admins to despawn entities like this. |
|
Maybe make this configurable instead of just removing it? I feel that there is a bit of a fun one here where mojang doesn't really care too much about server owners and what they have to deal with, and hard TTLs being a bit weird |
|
How is the any different from a hard TTL on arrows? It literally just sets a TTL for arrows on the vanilla in-ground despawn rate (1200 ticks) + 200 ticks of "flight" buffer. |
|
I thought that the maths might end up matching differently or something, kinda dubious on just removing something like this mid cycle |
|
Mid cycle? 1.21.5 is experimental. (and again, wanna restate this, the patch literally only works on arrows. The argument that this somehow opens a new vuln on servers when the exact same thing can be done via snowballs, which are a LOT easier to farm, feels weak) |
|
True, I guess; I guess it would maybe make sense to try to point to people about those recommendations somewhere, the entire reason we patched this was because it was a huge problem for servers, snowballs are more accidently so due to low sim distances rather than something people on the server do; 1.21.4 has 55k users, .5 has 27k users, I don't think that we're in the phase of experimental of just being able to gloss over stuff as easily as "we're still in experimental" now |
|
I mean, we could technically migrate older config files over and set this faulty TTL on arrows. |
|
I'm just thinking that if we're going to remove something that was intentionally added because we know it was being abused on servers, we should probably try to do something to let server owners know about this and "hey, there is a solution you can already adopt" sorta deal |
|
I thought this was merged because the linked issue for it was considered a confirmed but not fixed vanilla issue. We could very well include this in the stable 1.21.5 ping and note that, to re-create this, people ought to set the arrows TTLs. |
|
a bunch of things probably should have had config options when we added them, we have also generally been considering these builds "probably stable but we can't really go back to experimental mid run for some library and so we're keeping it as quasi experimental" for some time, I don't think that the "but we're still experimental" flag really has much of a bearing on anybody non-religous over that stuff |
|
Well, I guess I'll put down the rosary beads and semi accept that .5 is used as widely as it is. For all I care we migrate the default world config with a default TLL for arrows at this patches rate of 1400 ticks and in .6 we can switch the default back to 0/the vanilla behaviour. |
|
For something that was actively being exploited, and there being a test jar for it, I was just thinking to slap an announcement "hey, we're removing our fix for this, you might want to consider adjusting your server options to compensate, we'll be merging this in a day or two" or something to that effect |
|
Lynx is right IMO, this doesn't make server any more vulnerable, not worth announcing, any server worth their salt already is limiting large groups of entities, lagging using snowmen is way easier. |
|
most entity limiting stuff I see generally caters onto living entities, not targeting random entities which people might be upset if they lost; most of the servers I saw impacted by the snowball issue were generally servers using dangerously low simulation distance values, not your average normie servers which were getting hit with the arrow one intentionally This was patched more due to it being a support burden, rather than it being some super duper unmitigatable by servers issue |
Are you referring to snowballs entering unloaded chunks? Not the same snowball issue I was meaning, look at this video: https://www.youtube.com/watch?v=aItr0pRsBa8 plus snowballs into unloaded chunks can already be mitigated with configuration chunk save limits |
|
Hi guys, Docm's voodoo technology is broken by the current behaviour (arrows despawn in bubble columns), and after his latest HC episode I'm sure there's a bunch of people wanting to play with this. As mentioned above, perhaps a config to override this for admins could be a way to handle the case where people try to lag the server, but otherwise this change just diverges from vanilla without fixing any glitches or bugs, it would be cool to get it reverted via this PR. |
|
Yea I was hoping id get around to a proper migrating to the TTL config options fast enough but that doesn't look like it's happening so maybe a throwaway config option that we can just drop down the line is good enough for now. |
|
If I write a config line for this and push a PR will that increase the
chances of this getting into the next release?
…On Tue, Dec 9, 2025, 21:10 Bjarne Koll ***@***.***> wrote:
*lynxplay* left a comment (PaperMC/Paper#12544)
<#12544 (comment)>
Yea I was hoping id get around to a proper migrating to the TTL config
options fast enough but that doesn't look like it's happening so maybe a
throwaway config option that we can just drop down the line is good enough
for now.
—
Reply to this email directly, view it on GitHub
<#12544 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALJUP6VBXYMOXNB5G4BHOL4A4UFHAVCNFSM6AAAAAB434YH32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZUGA3DQMRRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hi, I bumped this last week, can I get an answer to my question? If the holdup is getting someone to write a change and test it locally, would it speed things up if I do this for you? Do we even need the TTL in the config or is just reverting the "fix" enough as per this PR? |
|
We're generally against just reverting this given that this was added to mitigate an issue that was heavily impacting people, adding a TTL would provide a migration path that people can disable if they so desire |
|
Thanks for the reply, I'll have a play and submit it as a separate PR. I guess you want the default TTL to be the 200 ticks as present but configurable? |
|
I would believe so |
|
I've pushed #13409, tested locally, arrow despawns as before with the default value in config, when value is set to -1 arrow doesn't despawn anymore |
3 participants
MC-125757 has been marked as works-as-intended, meaning paper's changes to
forcefully despawn arrows are breaking vanilla behaviour.
Given paper also now implements entity-based time to live options, this
kind of behaviour can be replicated by server admins anyway.
See: #3859
Download the paperclip jar for this pull request: paper-12544.zip