Skip to content

Add unsupported-settings section to config (piston tnt dupe config option)#3565

Merged
aikar merged 1 commit into
PaperMC:masterfrom
schlatt-co:master
Jun 15, 2020
Merged

Add unsupported-settings section to config (piston tnt dupe config option)#3565
aikar merged 1 commit into
PaperMC:masterfrom
schlatt-co:master

Conversation

@JRoy
Copy link
Copy Markdown
Member

@JRoy JRoy commented Jun 15, 2020

This adds a configuration option to allow tnt duplication which was recently fixed. While I wouldn't personally use it, the config option should be here for users who want to use it.

The config option adds a new unsupported-settings which can be used for future controversial patches like the last one. By changing anything in this section, users should expect to not receive support unless they reproduce their issues by setting options in the unsupported-settings section to their default values.

With that being said, there's no reason this shouldn't be added. Having multiple different forks/local forks of Paper will just cause further fragmentation and hurt Paper's market share. If you don't like this, don't use the option.

To all those that I've been disrespectful to in the issue tracker, I'm sorry as I was under the impression that Mojang had fixed this in 1.16 and that you could suck it up for the remaining 1.15 lifecycle.

@JRoy
Copy link
Copy Markdown
Member Author

JRoy commented Jun 15, 2020

att #3561 #3544

@Cryptite
Copy link
Copy Markdown
Contributor

Pretty sure this is the reason this won't be added: #3561 (comment)

@JRoy
Copy link
Copy Markdown
Member Author

JRoy commented Jun 15, 2020

Was going off convo which was had here

That being said, support tickets which deal with pistons can require a timings report which has the paper config included in it, if any unsupported options are set, reject the issue.

@JRoy JRoy closed this Jun 15, 2020
@JRoy JRoy reopened this Jun 15, 2020
@aikar
Copy link
Copy Markdown
Member

aikar commented Jun 15, 2020

After talking w/ slicedlime about this, I will relent and allow a config for just this tnt duping concept (not dupes in general)

Notably as lime said "You're talking about the one automated form of mining in a game about... mining."

@aikar aikar merged commit f860969 into PaperMC:master Jun 15, 2020
@BillyGalbreath
Copy link
Copy Markdown
Contributor

This is why we can't have nice things. Next in line was pushable tile entities, but that's not a possibility with piston dupe bugs laying around. Oh well

@zachbr
Copy link
Copy Markdown
Contributor

zachbr commented Jun 15, 2020

That one was never coming to Paper.

@BillyGalbreath
Copy link
Copy Markdown
Contributor

BillyGalbreath commented Jun 15, 2020

That one was never coming to Paper.

Oh, I know. I just meant in general.

Imagine what new things we could have from mojang by now if they didn't leave these types of bugs alone. I just used pushable TEs as an example. Imagine where redstone could be if mojang wasn't afraid to fix it, for another example ;)

@wilderop
Copy link
Copy Markdown

Thank you for this, I've been running a paper server since October and this just shows how much you guys listen. I'll be donating to support all you're great work!

@Darth-Sicaedus
Copy link
Copy Markdown

Darth-Sicaedus commented Jun 16, 2020

I know this absolutely off topic and I frankly don't care. To start off, I couldn't possibly care less about TNT duping. I don't use it personally, but I also don't mind if my players do. Minecraft is a sandbox game, do as you please to your heart's content within the limits of the game engine(exploits included) and plugins. However, I am a bit floored at how the development team treats the users of it's software. I get that you folks probably get some of the dumbest support requests for all sorts of things no longer supported or that you don't want to support for the reasons stated in the mission goal of Paper or for personal reasons. I am sure this happens multiple times per day. However, there was some blatant contempt and straight up disrespect leveled at people simply trying to make their point. There is a better way to deal with that. Like simply having a cookie cutter, blanket statement prepared for just these such situations. Something saying that, "X request goes against the goals of Paper's development and it's developer's goals and that the requested "feature" or "fix" will not be developed, implemented or supported and that if they so wish, they may fork it on their own or find someone else to do so on their behalf. Leave it at that and close the issue off. No need to let those things to go on for that long and get that toxic. I love what you folks are doing. Paper is fantastic with it's speed and granular config. I want to continue using it, but I really don't want to have to ask you folks for support on an issue if that is par for the course for dealing with you.

@aikar
Copy link
Copy Markdown
Member

aikar commented Jun 16, 2020

Would like to note a lot of the comments you are referencing are not Paper team members.
Yes some people in the community made some harsh and disrespectful comments and usages of hurtful words, but we do not condone that (such as that fork name, which we asked them to rename before we added this config).

I reviewed my own comments (And I believe I was the only one really commenting from the Paper team, outside of Z also asking people to be nice) and don't see anything I said targeting anyone, just reinforcing my opinions and trying to explain them.
If any part of my statements was taken as disrespect towards you or another individual, it was not my intent and I apologize.

@MiniDigger
Copy link
Copy Markdown
Member

might me worth pointing out the difference between the member and contributor tag here on github. a contributor (like me), is somebody who send a PR to suggest changes and they got pulled into the project. that can be anything from a typo, to big features, bug fixes and everything in between. contributors are not associated in the project in any way, other than that they did contribute something in the past.
actual team members are part of the papermc organization here on github and as such are marked as member on github. these are the only ppl that can speak as the project. everybody else (contributor or not) is "just" part the community and you shouldn't really hold the paper project or its team member accountable for something they said.
that said, as aikar pointed out, the paper team tries to influence the community to not be total dicks. but with how big the community has grown, thats no easy task and the topic was fairly controversial, so the discussion got heated and ppl said and did stuff they (hopefully) normally wouldnt have done.

I myself suggested that the paper team documents their stance on things like this, so that in the future, issues can just be closed and locked with a reference to use a document, before a discussion starts.

LeonTG pushed a commit to LeonTG/Paper that referenced this pull request May 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants