Love-To-Hug

I agree with Shadeykins That said, I think it would be nice if it received some minor QoL improvements, because it really is a bit of a clusterfuck of buttons that have no organization to them at all aside from alphabetizing. Departmental separators would be nice.

A lot don't because the baton can stunlock. Just spamming it on the person while you drag them out of the restricted area is enough.

Is that what this is about? Sorry for saying I hated it. I can be rather blunt. I meant no offense to you and yours.

If there were a nerf I would propose that harmbatonning with a telebaton gives you a short cooldown on when you can next stun someone, to break up the stun harm harm stun cycle.

I think implementing Neca's suggestion is just going to make all Command start carrying cable cuffs, which will only worsen the problem.

This would be amazing with a hotkey toggle. Sounds like it'd be hard as hell to implement though - especially when you consider almost all of us play on 2x sprite size mode. It's easy to forget just how small the rendering area actually is.

Responding to my criticism by telling me to take a programming course is what I'd consider to be condescending, yes. I think there is a major disconnect here. At no point was it my intention to imply that your suggestion would be difficult to implement. It's just the way in which you wanted to do it is not generally considered acceptable practice by the Paradise codebase. The idea behind it - making autopsy less tedious - is not anything I was ever against. Removing it as a surgical procedure is something neither of us thought of, and it's a very elegant solution. This is not saying anything about you as a person or your programming skill. I don't really understand why this has to be so personal.

Creating an exception for autopsy as a surgery operation is snowflaking the code by the maintainers' own definition, which is why the solution to this problem was removing it as a surgery operation. I'm honestly not sure why this is such a big deal. A solution was found, so we should probably just move on.

I think people are reading way too much into the whole 'snowflake' thing. The initial suggestion involved creating an autopsy table and a bunch of special rules that are inconsistent with the way surgery normally works. That is something the codebase heavily frowns upon unless absolutely necessary (such as IPCs). Taking surgery out of the equation entirely was a clever solution to the problem that satisfies all parties. Pretty cut and dry, everyone's happy now.

Was a failed attempt at being cheeky. I just thought it was funny that people unanimously didn't like this so I thought it was funny to toss a 'no' on the pile. I apologize.

.

That is remarkably condescending, especially when you take into consideration that the maintainer said he wasn't changing the surgery specifically for the reasons I stated: That said, this was a clever solution that I don't think any of us thought of. But my point about why your initial suggestion could not be implemented still stands.

Shadeykins you just literally decribed snowflaked code, something the maintainers hate.

I really hate this suggestion, I'll be honest with you. This is major code snowflaking (and with that comes bugs) just to save two clicks. The real problem with autopsy is it usually doesn't reveal much that the detective's scanner doesn't already tell you. Only when the patient has died mysteriously is it ever useful (such as figuring out what chemicals were in the patient's body). If you want autopsies to be more useful, expand the amount of information autopsies can tell you - stuff the detective's scanner can't tell you. What weapons were used to kill the patient, for instance. Saving clicks isn't going to do anything on its own, but if you were going to do this, I'd make it so starting surgery with an autopsy scanner makes it 'autoselect' autopsy surgery and you can jump straight to making the incision.

While TG has faster atmos I do notice that their server stalls a lot compared to ours. Our code seems to handle 2-3 dozen more people before it starts to stall. We have the best performing server out there as far as I can tell.

Allfd, this is all assuming current code, right? Would optimizations allow us to support a higher player count? I mean, I'm sure the answer is 'yes', but, to what extent of an improvement could we expect?

I don't really agree with the philosophy that the delister is 'sticking our heads in the sand'. Most multiplayer game servers (and I'm talking in all sorts of games) have a player cap for good reason, there comes a point in which gameplay starts to degrade if you have too many people. Instead of having a hard cap, this is more like a soft cap. That said, I completely agree with the codebase changes that need to take place so we can give support to these higher populations. I would also look into some of the jobs being 'high peak exclusive' so that we don't get a bunch of filler jobs at low peak when essential jobs are vacant. The delister can continually get re-evaluated as our circumstances change - I'm a believer in adapting to the current situation rather than endlessly planning for the future.

I think the threshold needs to be lowered to 100, and I also think it needs to be less buggy.

I would like very much to be able to do a 'stick-up' where I have time to type and if they dare move or try to draw a weapon (could use the same identification beepsky uses as to what's a weapon) you'll automatically fire.

Anyone else feel like the setup-and-forget engines need to go away? A lot of servers are ditching the singularity and tesla because they don't really provide any interactivity beyond roundstart and potentially releasing it... and personally, I've never considered a round where either was released to be fun.

So an Orderly.

This is a symptom of a larger problem. You can make all the rules you like, but those that are bored will find some way to make themselves a nuisance for giggles. There's simply not enough for them to do. In other words, this is putting a bandaid on a huge gash. Kyep's job slot PRs are just on the horizon and we're getting closer to implementing Lavaland. Those things will help significantly.

Why is the feature freeze so strict as to deny even desperately needed improvements like cleaning up the admin logs, or even minor things like letting the cluwne mask work with internals? It doesn't seem like the feature freeze really increased the frequency of fixes, either. Is it really going to last until the end of the year? As an aside, it was also pretty unfair for Kyep that he got hit with the feature freeze when he was forced to split Terror Spiders into multiple PRs.

Boobtime Anomalies

Bluespess