/tg/Station 13

Bottom post of the previous page:

so, basically, why does oranges keep merging heavily disliked stuff? shouldnt there be something that prevents him from merging (policy wise) without considering what the community wants?
Examples:
https://github.com/tgstation/tgstation/pull/44324
https://github.com/tgstation/tgstation/pull/44530
https://github.com/tgstation/tgstation/pull/42386
all of these were heavily disliked, yet oranges still merged them.

dont get me wrong here, this isnt just oranges, but hes doing most of it.


also a gem i found in my pics, god bless his soul

If you want some examples. When I look at the recent PRs. I get really annoyed at the disregard of simple mob functions and their antagonists. You nerfed dragging but gave people a feasible alternative. (Almost didn't exist until PKpenguin came up with the idea. But the execution ended up just being another roundabout minor movement speed nerf.) The problem with this was, is that simple mobs were not addressed and ultimately ignored. Because "They're not important enough for me to care" as oranges put it so eloquently.

On another example, stasis. It left some gaps to fill in medbay as it made doctors even more useless and forced people to rely on an unreliable role. It wasn't a 1:1 replacement as the maintainer who merged it put it, and hoped that it would inspire people either out of anger or frustration to fix medbay themselves.

It didn't, and the maintainer themselves had to add in a bit more to keep medical doctors busy.

These issues would both be addressed by some quality control that I'm looking for. A simple, "Your PR has issues like ___ and until they get fixed. This is simply not compatible with our code-base."

You cannot rely on people to care about things that do not affect them. You have to give them a reason to care. Maybe a coder would fix the botched PRs after a month passes and they realize "Hey. Why does this role suck so much? How come no one fixed this?" But I feel like this could ultimately be more easily addressed by just having the original person. Either fix it or not merge their half-baked idea at all.

To simply put it. I want it to be the original coder's problem. They only care whether their nerf PR gets merged or not. Why shouldn't the maintainers make them care about the issues their nerf PR brings up?

This is what confuses me.

I am happy that the maintainers are willing to go against popular opinion, because while i don't agree all changes, i think most controversial changes have turned to be very good. In my opinion stasis has been a great improvement to medical gameplay and there is now way the playerbase would voluntarily leave their sleeper hugbox.

The big problem in my opinion, is that oranges seems to relish in being opaque and not explaining reasons for liking or disliking a proposed change. "x is lame" or "thog say no" tells you nothing about why the change was rejected, this is a shame because knowing how our benevolent dictators thinks would be very valuable for the contributors.

I do agree that some PR, while fundamentally good, such as the drag nerf and null crate caused issues that were very foreseeable and probably should not have been merged until those issues were dressed.

I mean the only reasons nulls were removed are "tee hee this one item that I can easily edit out is ruining stocks and griffers reeee" and "buying nulls is self antag" (which is bullshit and yall know it. Does keeping traitor items make you self antag too?)

Mentioning the issue tracker number is either disingenuous or shows a lack of understanding. The vast majority of old issues are either not bugs now or never were.

Timonk wrote:I mean the only reasons nulls were removed are "tee hee this one item that I can easily edit out is ruining stocks and griffers reeee" and "buying nulls is self antag" (which is bullshit and yall know it. Does keeping traitor items make you self antag too?)

The reason why i think nulls were problematic is that they kind of hampers secs ability to sniff out who is an antagonist, having several pieces of antag gear without any good reason should be surefire proof someone is bad. The problem with removing them is that cargo doesnt have a lot going on for them, they need new exciting crates to buy, preferably lootbox style with randomised content.

Kryson wrote:

Timonk wrote:I mean the only reasons nulls were removed are "tee hee this one item that I can easily edit out is ruining stocks and griffers reeee" and "buying nulls is self antag" (which is bullshit and yall know it. Does keeping traitor items make you self antag too?)

The reason why i think nulls were problematic is that they kind of hampers secs ability to sniff out who is an antagonist, having several pieces of antag gear without any good reason should be surefire proof someone is bad. The problem with removing them is that cargo doesnt have a lot going on for them, they need new exciting crates to buy, preferably lootbox style with randomised content.

having a shitton of antag gear is acting like an antag, into the prisoner transfer room you go

Screemonster wrote:

Kryson wrote:

Timonk wrote:I mean the only reasons nulls were removed are "tee hee this one item that I can easily edit out is ruining stocks and griffers reeee" and "buying nulls is self antag" (which is bullshit and yall know it. Does keeping traitor items make you self antag too?)

The reason why i think nulls were problematic is that they kind of hampers secs ability to sniff out who is an antagonist, having several pieces of antag gear without any good reason should be surefire proof someone is bad. The problem with removing them is that cargo doesnt have a lot going on for them, they need new exciting crates to buy, preferably lootbox style with randomised content.

having a shitton of antag gear is acting like an antag, into the prisoner transfer room you go

you, me and everyone else knows that's not how it plays out

A lot of this thread just sounds like people ranting with increasing hyperbole about how "those damn coders never listen to anyone!" and then expecting to be taken on faith that joe-player-average would know the difference between functional code and not by looking at it.

Not all opinions are created equal

For instance some of the people in this thread are so reliably wrong that if one of them tried to tell me that killing babies is wrong it could cause me to re-evaluate the pros and cons of cold-blooded toddler murder

You just assume the worst out of people Mickyan.

I think the ultimate problem here is one about accountability and quality control. As a game designer myself, I absolutely understand and agree with having next to no democracy for many design decisions because game design, however complex or simple people think it is, ultimately has wiggle room. There are a few no nos that are universally agreed on, and there are many identifiable objective bad design choices, but these often are mired by people arguing with fallacies or require a bit of study and dissection.

This is where I feel the point of quality control/accountability comes in. A problem I've seen excessively of late is many merges are introduced that are either hilariously buggy, simply do not work, or quite frankly giant pieces of shit. Pubby and Donut SM merges were tire fires visible from space. The Russian Surplus PR was a complete shitshow of balance that not a single maintainer cared about. Fireman carry flat out doesn't work on the ones you'd expect it to. Even the stamina crit debacle was insane. All of these are actually recent and just off the top of my head.

Meanwhile, we see PRs being closed for either completely arbitrary reasons or because the maintainers usually want those coders to go above and beyond what the scope of the PR was. There was a PR to move mech rockets into security lathe and the response was effectively "come up with a completely new system just because;" Specifically, a way to have different access to different lathes. At this point, any new coder is immediately shut down because this may be so far out of scope for their skill that it doesn't have any chance to get done. Meanwhile, maintainers can push whatever they want fundamentally ignoring the restrictions they impose on others.

This brings up an additional problem in that maintainers can arbitrarily decide if or when something is good. Nominally, in any game design or large term project, you establish a design document or overreaching policy to help guide people to the goal they want to receive. These could be somewhere between simple to extensive, but gives contributors factors they can understand and limits they can experiment with to really enhance the open source portion of the platform. Saying something as simple as "Security should control production of all weapons on the station" is a very simple design goal with a stated goal. Now you can make pulls that police cargo null crates requiring (say) a security card to open. Mech weapons are pushed to security or robotics is made a sec department. This is a very simple design document, and is just an example, but it creates an understanding that others can follow.

Our current maintainers do not seem to be interested in doing anything even remotely like that.

This just goes back to the above problems of accountability and quality control. There are no maintainer elections or coder elections. This means unless they screw up so bad you can see from the moon, they will likely receive no need for accountability. If they do not change, however, this does mean that a global design document can exist (and should exist) because it allows open source contributors to push forward to it.

I think the policy going forward should be one of bringing coderbus back down into the realm of accountability or at least making them require certain goals or thought processes beyond "I feel like it." This can be done with some measure of elections or just by forcing them to do documents with certain restrictions then punishing them when they feel otherwise. It's getting scarily close to some things getting merged for no reason whatsoever while the person atop the INTERNAL DISCUSSIONS tower mocks the flunkies below.

As for democracy, an important part of game design is also responding to community wants and needs. Fighting game combos are probably the universal example of this as they were never intended, but once they came out the game designers realized its popularity and started making them baseline. For a most esoteric example, Wavedashing is another great one as the designers acknowledged that it allowed for higher level play. They disagreed with making it baseline, and would eventually evolve it into Perfect Pivot.

Players may be terrible judges of making good design decisions, but many can and readily will tell you when something feels fair, interesting, or engaging. This is also why metabreakers tend to come either with small choices that expand out dramatically (Brigitte from Overwatch) to complete reworks (pick a jungle rework from League of Legends). The difference is, most of those changes tend to be a little more accepted because you take the time to explain your thought process and you engage in the community. Alternatively, you could just do the Blizzard WoW aspect of "We know better than you." Hint: That almost never works because statistically, there are more people willing to show you why it doesn't. Related Link (Massive Irony Expected): https://1d4chan.org/wiki//tg/_gets_shit_done

I agree.

Maintainers need accountability.

Otherwise, they don't care about what the community thinks.

Pretty much why the current coders just "lol" at any suggestions that anyone who isn't a maintainer suggests.

So...Maintainer elections when.

fellow players, I urge you to stop this pointless crusade
know your place, players, we are here to play the game, not to make it
everyone says "coders/admins don't play", I say that's good
society works best when everyone has a role in it and fulfills it
coders should code, administrators should administrate, players should play
this way everything will be the best it can, even if you're not aware of it

As to the topic this thread is supposed to be about, there doesn't seem to be a lot of appetite for an enforced "top down" change of power (ie MSO/headmins threaten to fork unless changes are made). Not that it's impossible or anything. For all I know someone will run as headmin with a platform of forking.

Kryson wrote: The big problem in my opinion, is that oranges seems to relish in being opaque and not explaining reasons for liking or disliking a proposed change. "x is lame" or "thog say no" tells you nothing about why the change was rejected, this is a shame because knowing how our benevolent dictators thinks would be very valuable for the contributors.

Try talking with oranges and everyone else on Discord. If you're not plugged into the actual place of discussion, you're missing out.

Kenteko wrote:-snip-

Writing design documents is more work than most people think, hence why we have pretty much none. They're also a lot of fun to write, at least for me. I'll tell everyone, if you write a good design document, you're going to change minds and fire people up to do things your way. There's a stickied thread in Ideas with a mining redesign for example. As to forcing a design onto the maintainers and other contributors, that's up to oranges. I'll just say that there's advantages to a super decentralized design, but there's disadvantages too. Just like with potential game designs, both directions are valid.

MisterPerson wrote: I'll just say that there's advantages to a super decentralized design, but there's disadvantages too. Just like with potential game designs, both directions are valid.

Just don't lose the core theme of what this game is about in a decentralized design.

I've seen it countless times, games, tv shows, Ideas. They get hijacked and completely lose their initial goal.

I don't think /tg/ has a pre-determined "finish line" for features. So it'll go on as long as it can.

I'm not sure a game without an ending should be de-centralized.

MisterPerson wrote: Writing design documents is more work than most people think, hence why we have pretty much none. They're also a lot of fun to write, at least for me. I'll tell everyone, if you write a good design document, you're going to change minds and fire people up to do things your way. There's a stickied thread in Ideas with a mining redesign for example. As to forcing a design onto the maintainers and other contributors, that's up to oranges. I'll just say that there's advantages to a super decentralized design, but there's disadvantages too. Just like with potential game designs, both directions are valid.

Writing design documents absolutely take time and effort, but they're also incredibly useful and serve as goals whether it be decentralized or focused design. Even having goals for different departments or overall flow is important and something that needs some level of scrutiny. We mandate administrators follow a set of rules and even occasionally write policy, why is this not the same for coders?

Hell, we don't even need a full fledged design document. Having design choices or overall situations laid down in some level of stone akin to policy will help raise accountability and communication almost exponentially. If we were to understand what, say, should be expected code wise of any changes for security, that may in and of itself spur different pulls and codes to bring security in line with the new design choice or put it under scrutiny. Saying "All good" or "I want to change it" does a disservice to the very idea for open source, especially when the coder in question is infamous for not giving a damn about explaining anything.

So yes, a lack of a design document can absolutely be good in a true open source project where maintainers exist to just check if things work or not and push it through. This may create a bit of a mess of a project, but that's part of open source/decentralization. Our maintainers have shown clear and evident design decisions and goals, but their failure to communicate makes it appear as if they only care about their own personal agendas, moods, or otherwise and will merge things regardless of what other people think. Saying "it's open source" does a disservice and is a double standard because, when presented with clear evidence of bias and or biased decisions, it is a heavily controlled and focused product versus being completely open source. Pick one and stick to it, imho.

Yeah shadow, that's why we shouldn't have any stupid-ass votes, because the "initial goal" of ss13 is being forgotten by people who joined in 2018 and thought that good players were the bad players of 2017 who thought good players were the bad players of 2016 who thought the good players were the bad players of 2015...

oranges is an actual oldfag, and thus has a fairly not-shit idea of the "core theme" of the game. that's why I like him.

I think the main theme here isn't "over-throwing the maintainers" it's

"Make the Maintainers actually care about what the players think"

And

"Maintainers should make the coders not be so damn lazy with their nerf prs."

I like krysons idea, but my point is, maybe you should hold out on merging something with 53 downvotes and almost no upvotes

Shadowflame909 wrote:I think the main theme here isn't "over-throwing the maintainers" it's

"Make the Maintainers actually care about what the players think"

And

"Maintainers should make the coders not be so damn lazy with their nerf prs."

>make them

How do you propose you're going to do that? This is policy discussion, not Merlin's lab. You can't fiat what you haven't defined. You've just repeatedly asserted "the maintainers don't care xd"

You've been posting mindlessly like this and it doesn't do anything to advance whatever your supposed goal is.

Someone should draw up a list of all the gameplay changes over the years that were colossally unpopular but pushed through the github permanently anyway.

cedarbridge wrote:

Shadowflame909 wrote:I think the main theme here isn't "over-throwing the maintainers" it's

"Make the Maintainers actually care about what the players think"

And

"Maintainers should make the coders not be so damn lazy with their nerf prs."

>make them

How do you propose you're going to do that? This is policy discussion, not Merlin's lab. You can't fiat what you haven't defined. You've just repeatedly asserted "the maintainers don't care xd"

You've been posting mindlessly like this and it doesn't do anything to advance whatever your supposed goal is.

You're intentionally looking for flaws in the wording instead of listening to the argument. Not very productive.

How is it difficult at all to not accept an obviously flawed code-change instead of merging it with its errors no ones going to fix.

I have no clue how to make it any simpler to you.

What I want is. A simple "Hey. Do you see how this PR change hasn't taken notice of its effect on this feature? Please deal with that or else it cannot be merged."

Coders that actually care about their product rather than people who just want to see how many nerf PRs they can get away with is what I want in this community.

The second does exist by the way.

We've seen time and time again that the main-stay coders literally don't care about what their code breaks as long as the maintainers aren't giving them crap for it.

The coders will just "lol" at any valid player complaints.

Give me some more quality control dammit.

Edit: This is also a valid forum for this complaint.

Because we've seen that headmins are the only ones willing to listen to player feedback.

Considering that they themselves are able to be held accountable.

it is an impossible task to adequately cover every surface of the game to ensure that a change doesn't break other components of the game, so there is a tradeoff to be made and we generally choose feature velocity over ensuring consistency and avoiding all bugs.

This has been true since the beginning, complaining about it now is simply muck raking.

I understand what you are saying. You would rather have more interesting mechanics. That's fair and I can't blame you for that.

But, the downside of this is that and stay with me on this one. It's lead to a sort of quality of life entropy. Unintentionally features have become less fluid and mechanics are essentially becoming machines that are running unoiled. It's harder to do things, and you get a sort of resistance from older mechanics being botched by newer designs.

I strongly feel that a little bit more care being put forth to maintain the functionality of more "minor" mechanics would do well in keeping the game fully functional like a well-oiled machine.

In earnest, I think that when we look towards the more controversial changes. A bit more prodding and poking at the coder who codes these things, so they don't laze off and chip away at the game. Would do well for the enjoyment of the players who play it.

It's all I'm suggesting.

Examples of the scenarios I think a bit more prodding would have led to a more functional game: 4dplanners Dragging change. It was very obvious to all parties that simple mobs would be influenced by the nerf, but not the handy change to allow them the same freedom non-simple mobs have. This lead to a decrease of functionality to the many simple mobs hit and run gimmicks like xenomorphs, the demons, holoparasites, spiders, and the many other mobs that require dragging humans to complete their goals.

This may be beneficial to other views of the game. But it not being an intentional focus is an issue of itself. As it can damage mechanics, like said previously.

Another example that wasn't stated previously would be Economy. It does the goal the maintainers gave it. To give even less reason for them to be assistants. But ultimately it leads to being just a cargo buff. Allowing them to buy guns and the like at roundstart by taking the budgets, and it was a botanical nerf. Making all plants cost money that the botanists cannot afford so easily. I feel with this as well, a little more prodding and more care about what this new feature affected outside the initial goal. Would be wonderous in keeping mechanics intact.

So ultimately, as a TLDR if you will. I thank you for commenting and expanding upon the reasons for why you do things this way. But I still feel like change is necessary. I do not think this change would be aggressive or massive. Just a simple PR "Oil Check" if we're going back to that metaphor. If an obvious issue is brought up. I beg of you. Please do not let it slide and make it the coder of the PR's issue. And not the issue of another code months down the line, when they finally feel like increasing the number of Fix PRs under their belt.

It'd make the game a whole lot nicer to play.

Shadowflame909 wrote:

cedarbridge wrote:

Shadowflame909 wrote:I think the main theme here isn't "over-throwing the maintainers" it's

"Make the Maintainers actually care about what the players think"

And

"Maintainers should make the coders not be so damn lazy with their nerf prs."

>make them

How do you propose you're going to do that? This is policy discussion, not Merlin's lab. You can't fiat what you haven't defined. You've just repeatedly asserted "the maintainers don't care xd"

You've been posting mindlessly like this and it doesn't do anything to advance whatever your supposed goal is.

You're intentionally looking for flaws in the wording instead of listening to the argument. Not very productive.

How is it difficult at all to not accept an obviously flawed code-change instead of merging it with its errors no ones going to fix.

I have no clue how to make it any simpler to you.

Yes, I know you don't. You're trying to play the victim when I asked you how you plan to implement a solution to your complaint. "Not helpful."

Literally, everything you're asking for already exists except for the coders giving you some sort of authority or stake over them and their work. If all you want is to be able to contact a coder about something you don't like or to comment on those things, then do it. There's literally no way you're going to obligate or make those people do anything apart from actually convincing them.

(Writing a thousand words to explain something simply is not how you accomplish that either)

"coder do this"
"no"
oops the entire system failed

the "us and them" mentality that the majority seems to have about noncoders vs coders is the biggest issue. sure server and codebase are separate entities, but all in all it's the same playerbase. Anyone can be a coder, if you think something is a dumb mechanic or unbalanced feature learn how to code and make a pull request.

Chances are people that already contribute to the codebase will have conflicting pinions with your change or be unwilling/not knowledgeable about fixing a bug. You'd do exactly the same if you were a contributor.

Unless you're physically or mentally incapable of being able to code(very unlikely), you can be a coder. The only thing stopping you is yourself.

Shadowflame909 wrote:4dplanners Dragging change.

I actually can't tell if it's deliberate by this point

imsxz wrote:the "us and them" mentality that the majority seems to have about noncoders vs coders is the biggest issue. sure server and codebase are separate entities, but all in all it's the same playerbase. Anyone can be a coder, if you think something is a dumb mechanic or unbalanced feature learn how to code and make a pull request.

Chances are people that already contribute to the codebase will have conflicting pinions with your change or be unwilling/not knowledgeable about fixing a bug. You'd do exactly the same if you were a contributor.

Unless you're physically or mentally incapable of being able to code(very unlikely), you can be a coder. The only thing stopping you is yourself.

Do you not see the flaw in this WYCI mentality? Why merge half-baked changes and then hope someone else will fix it down the line?

We've tried that, and it just makes everything feel worse to play. Because unless someone has an incentive to do things. They aren't going to go out of their way to fix a job role they don't even play.

There is that running gag of "coders don't play" as well. So how could they know how unfun they've made the game by breaking another feature with their nerf PR.

Lastly, Oranges is going for quantity of features and gameplay changes over the quality of said gameplay changes and their effect on the entire game. I'm still saying the same things. It'd just be simpler to shortly deny PRs and make coders fix their own spaghetti code.

If they don't want to. Did we really need a half-baked idea that the coder themselves didn't have the drive to see through?

Edit: And Cedarbridge. Convincing a coder? Bah. Unless you bribe them. I've sincerely doubted that anyone's gotten anything outside of a "lol" from a coder when you say you don't like the way their PR interacts with the game and you wish they would fix the issues their code brought up.

If the only care is getting a PR merged or not. Then I think it'd be easier for the maintainer to pull an "Or Else." I care about the quality of the game. And as seen here, I feel like the lack of quality from these recent PRs have been eroding older features that aren't being properly looked over.

Is it really that difficult to understand that I think a coder should fix whatever they've obviously broken or else they don't get their PR merged?

Shadowflame909 wrote:Just a simple PR "Oil Check" if we're going back to that metaphor. If an obvious issue is brought up.

The only things you consider an "issue" are changes you don't like.

oranges wrote:itt people with no understanding of how to run a codebase

\thread

"Changes I don't like" is a very valid description. But I think going more depth into that would be "Changes I don't like because they're unintentionally tampering with older mechanics and making the game not go as smooth."

Thanks for the open viewpoint as always Muncher.

That's still changes you don't like, but with a slight modifier indicating why you don't like them, it still doesn't make it any more valid than last time.

Shadowflame909 wrote:"Changes I don't like because they're unintentionally tampering with older mechanics and making the game not go as smooth."

Yes, so literally "changes I don't like". Adding more opinions doesn't change that. You're using language like "broken" and "issue" to try and paint the code as non-functional, but what you really mean "I just don't like it".

Look. We can play this wording game all we want. It's not accomplishing anything other than annoying me because I'm trying to communicate with someone who doesn't want to listen.

The problem is these changes are affecting things outside of their design. And Maintainers aren't pressing the coders to fix this before merging their PRs.

So yes. I don't like them. Why would I? It's messing with something unintentionally and making it worse off for it.

Why are you defending this?

Shadowflame909 wrote: So yes. I don't like them. Why would I? It's messing with something unintentionally and making it worse off for it.

Why are you defending this?

What did removing Null crates, separated chems and binary gender unintentionally effect?

Have I mentioned them at all?

You're arguing for the sake of arguing. But you're literally hitting the wrong person here.

Shadowflame909 wrote:Have I mentioned them at all?

I mean they are in the OP.
Do you really believe pull nerf effect simple mobs is unintentional?

Yeah. What reason would you have to intentionally damage mechanics in a large group like that? Instead of doing a one by one mechanical change to the simple mobs. So their gimmick/new gimmick thanks to the change can flow better and they can still accomplish their goals.

Shadowflame909 wrote:What reason would you have to intentionally damage mechanics in a large group like that?

oranges wrote: I want to kill the meta that I have seen of rushing in, stunning someone in a group and then dragging them into maint at high speed (sometimes with stims, sometimes without and just relying on superior map knowledge) to be killed at your leisure.

I still want to allow dragging people, but you suffer a slowdown and you can negate that (for rescue and antagonist needs) by using the fireman carry, which takes a little while to do.

The outcome is hopefully that it will be much harder to ambush groups of people, requiring more thought as a solo antagonist about how you want to eliminate a target and how to get them alone.

We may need to look at moveable chairs/rollerbeds at a slightly later date, if they prove to become the new meta, but I suspect their bulky/obvious nature will render that unnecessary.

That applies to human antagonists. That argument literally doesn't work for simple mobs.

Because they can't use stun batons, and they cannot use stims.

Also... THEY CAN'T FUCKING FIREMAN CARRY.

Edit: But yeah. Going back on the topic since any further continuation of that is futile. Oranges, Cobblestone, Shiz, Cyberboss, Ninjanomnom, and the other maintainers who I cannot think of right now.

Please focus more on increasing the quality of a PR instead of trying more for feature variation. Damaging other mechanics like stated earlier is pretty lame.

Shadowflame909 wrote: Because they can't use stun batons

Humans aren't the only antagonists who can stun.

Shadowflame909 wrote: xenomorphs, the demons, holoparasites, spiders

None of these rely on dragging, or have "gimmicks" that rely on it. The line about "requiring more thought as a solo antagonist about how you want to eliminate a target and how to get them alone." however does apply to all of them.

It's completely obvious how all of those require dragging to get their objectives completed.

I don't know why the fuck you want to win this "argument" so badly that you'll literally say whatever you can to win.

But sure ok. I'll give you the benefit of the doubt one more time and explain how these all rely on dragging people to complete their jobs.

Xenomorphs: Have to drag people to the nest and buckle them on resin so they can grow their Army.

Spiders: Drag people to the Green Spiders, so they can concoon them and make more spiders.

Slaughter Demons: They drag people to spread blood, so they can continue jaunting and don't suffer from speed slow-downs by running too far.

Holoparasites: This one probably wanted to be nerfed. But the holoparasites usually futilely drag their masters away when they reach crit. Looking for a medibot to prevent total death.

Now Please. For the love of communication. Do not just look for another reason to make an argument out of this. It's really starting to grind my gears. This is common sense to me, and you're looking really bad faith right now.

Muncher21 wrote:

Shadowflame909 wrote: xenomorphs, the demons, holoparasites, spiders

None of these rely on dragging, or have "gimmicks" that rely on it

What Are you on about? Xenomorphs and slaughter demons heavily rely upon dragging, the former for dragging to nests and the latter for spreading blood.

I acknowledge, in the abstract, validity of concerns about "side-effects". (I have been relatively inactive and do not want to indict my fellows without evidence.) However, the game is very complicated, and the code is tangled in difficult-to-predict ways, or in other words:

oranges wrote:it is an impossible task to adequately cover every surface of the game to ensure that a change doesn't break other components of the game, so there is a tradeoff to be made and we generally choose feature velocity over ensuring consistency and avoiding all bugs.

It's better to try to spot obvious bugs in code review and singleplayer testing, testmerge or merge the PR, and fix the bug reports as they arise than it is to grind the patience of PR authors by demanding that every possible side-effect has been exhaustively planned for.

Simple mobs are explicitly second-class citizens in this respect, so that we don't have to slow down iteration on core gameplay to cater to this non-core segment. Admittedly, a big part of the appeal of this game is its sheer depth and breadth, and "you can play as the spider" is part of that. Unfortunately, the devs can't think of everything when they don't have enough manpower to do so.

The reason "when you code it" stays strong is that how else is something going to get coded? Every coder and maintainer is a volunteer. Either you code it, or you find someone who is willing to code it, or you become someone who can code it. There's no way to compel our limited pool of coders to fix bugs that are both difficult and unimportant, unless they decide they want to. I got into this project by fixing bugs I encountered personally during play, and then tackling easy bugs that had simply been overlooked.

You're welcome to ask oranges if he would accept a PR unnerfing certain simple mobs then code it.

Also if this thread is a genuine policy thread can we talk about the process instead of specific feedback on features?

Also the lack of fireman carry on simplemobs was literally intentional, or at least oranges acknowledged the interaction changes. I don't know how you're coming to the conclusion you're coming to unless you yourself are choosing to selectively read.

https://github.com/tgstation/tgstation/ ... -496099513

Well. I guess it was just denial again on my part.

I don't understand it.

Right, and if you just want to quibble with oranges/maintainers about merge policy, this isn't the right forum for this discussion anymore.

Please recall that this thread is left open with the intent of allowing discussion about a system that would put coding decisions under server policy, not about specific pull requests or changes you like/dislike.

Quick attempt at stating a potential policy:

If a certain level of dislikes is reached, as determined by the headmins, the pull request is blocked A poll must then be established wherein a certain percentage must be met in order for the PR to be merged.

The reason I say a certain % is so we do not have obstructive or obtuse polls that can be mired in double talk to help pass. The established numbers above would be prone to being changed by headmins.

why should the headmins give a shit if a pr gets brigaded with downvotes by hippie and digg