
Kaed
Members-
Posts
1,698 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Everything posted by Kaed
-
Personally, I think it's much more reasonable for the head of security to have some sort of unique gun than the detective or warden, simply by dint of being one of the most important job short of captain (maybe even more than captain in certain cases) during a high stakes antagonist round. You tell me that the HoS is a desk job, but that's not how people treat them. I've seen many security teams that would fall to fucking pieces if their Daddy Hoss went away because they're a bunch of brainless morons with no tactical initiative other than flock towards valids in strong need of leadership and guidance during a crisis, along with someone to unlock maint for them. I often try to play my HoS characters as back row commanders but often find myself required to move to the front line just so I can babysit the latest gaggle of spineless ninnies surviving officers. Now, I would also say that the epistol fails to fulfill that role, because it is garbage. Even before brainmed, it was actually impossible to kill someone with the epistol, even if you hit them with all 5 shots and they were a catbeast. You wouldn't even put them in critical. They need a gun that doesn't require them to take weapons intended for the officers just for self defense. Carbines are battle weapons, not a self defense sidearm.
-
I've never understood this fixation people have with giving the detective a revolver or otherwise unique fancy gun. It's like people are incapable of separating outdated film noir concepts from the term 'detective'. There are plenty of modern day detectives existing right now, that walk around with normal, modern style firearms and no brown (or bright yellow) trenchcoats or silly fedoras. And we're supposed to be in a futuristic setting. It irritates me, and if I had my way, they wouldn't have a gun at all, or at the very most, a standard issue rubbers one like sec officers get. But hey, just my two cents.
-
You're right, I'm a novice developer, and have very little idea on what was involved in the fix. But I find it hard to believe that there is absolutely nothing that can be done to mitigate this problem, and that it was 'intended' for rocks to suck out all air in the station when they are revealed by the floor being destroyed. It feels to me more like a compromise being passed off as intended, because it's utterly nonsensical for asteroid rocks to behave this way. The last person who did any serious work on fixing ZAS (that I'm aware of, which isn't the same as factually correct) was Lohikar, and he left the team over a year ago. So maybe the current devs don't want to or don't have the experience to fix ZAS, or maybe it's not even fixable. But the fact remains is that this map you (the collective you, as in the server staff, not you specifically) have all created had a serious flaw in design that you fixed by basically writing out atmospheric simulation entirely on the majority of it, and as a result, incidents like the one that spawned this thread occur now. You not knowing a better solution to the problem does not mean it's 'working as intended', there is a serious flaw in the current setup. If you don't know how to correct it, or it's even impossible to correct as you say, perhaps an alternative angle should be looked into to correct the asteroid problem. Perhaps a map redeisgn like alb mentioned earlier.
-
Edit: For people who aren't aware of the situation, like burger seems to be somewhat --v This is not a bug or mis-implemented venting mechanic, it's an oversight in the slapdash approach the dev team took months ago to fixing problems with the asteroid. You see, the asteroid, or "Mine" area is the largest uninterrupted 'one' in the current server map, spanning multiple levels and significantly outweighing the actual space of the station itself. Due to our atmospheric engine (which is the one most people call ZAS), this caused a lot of lag and memory issues because the moment someone caused an atmospheric change between the inside of the station and the outside, by opening an airlock or breaking a window, the entire asteroid began trying to process the difference in pressure. This caused problems such as areas taking 10 seconds or more to notice that they should be venting (sometimes allowing people to close a breach before ZAS could make it happen) and a strange glitch where the entire Mine area was caught in an endless loop of simulating a large pressure change, making it so miners and people on the asteroid were constantly being blown off their feet (people called this phenomenon 'space wind' and it was extremely annoying). The 'fix' for this problem was switching all rock tiles on the server from 'simulated' to 'unsimulated', which meant that the Mine just doesn't process ZAS at all. This helped a lot with smoothing out the problems with the server's chugging atmos, but left us with a new problem - because of how unsimulated tiles interact with simulated ones, rock tiles basically act like space tiles (which are also unsimulated), and suck all air out of the area as if it was a breach. I (and probably others) told the devs at the time that they were implementing this that they would need to come up with a solution for it, such as making the tiles under the station itself an alternate, simulated version of rock tiles, but as with many things on this server at the time and apparently still now, they deemed quickly finished halfway measures sufficient. Now we suffer for this oversight every time someone breaks the flooring on the station and causes a magical unsimulated vacuum rock to appear.
-
It's not supposed to be in character. It's an adaptation on the ghosting concept fit with the new mechanics - previously you are free to leave your body when you died without writing yourself out of the round. This was very easy to happen, because the moment you reached a certain threshold you would start dying of suffocation and then perish at total 200 damage. It did not take 2 hours to happen. It is simplicity itself to establish the same restrictions on role-playing out what you learned while you were a ghost after you're cloned, and therefore create the same functional scenario as people who died and wandered around waiting to be cloned, only here they're waiting for someone to rescue their not dead body.
-
Overly harsh and not a solution, especially when they're taking cloning out. A game is supposed to be fun and it should be more important than enforcing gritty realism of making people state black screen for a half hour or more or choose to just die and give up thier character development that round.
-
In my tenuous understanding of Brainmed, you can sit unconscious for hours without dying. So, to help people not be bored out of their skulls without having to ghost, it would be nice if after a certain amount of time in 'near-death unconciousness', you can 'fake ghost' for a sort of limited ability to see their surroundings. Perhaps locked to their location, or only able to go a certain distance, or something. Or just let them ghost without losing their mob? Up to you guys on how it would work in specifics, discuss. It's very boring to stare at a black screen for ages!
-
Praise brainmed for bringing us this miracle
-
Personally, I think it's kind of dumb that we stopped short in our simulation of life process simply due to squeamishness. There have been a couple attempts to introduce bodily waste processes the game but every time people just go "ew gross" or "this isn't necessary" and shut it down. I see the same mentality being presented here. I think it would be nice for vomit to be more than an object on the floor it has no connection to anything around it, and serves no other purpose than to be cleaned up. You should be able to step in it and make a mess, to examine it to determine loosely what someone was eating, take samples of it for forensic purposes, perhaps you determine what poison or virus was involved in making a person puke. We can put a lot more depth to vomit then we do.
-
Look, I think if you put the work in for a significant content update like this, with new sprites and mechanics, it's worth at least a test merge to see if anyone likes it. But I just don't think this mechanic sounds very fun. While technically it is an improvement over current cult mechanics (click until horizontal join or die mechanics are horrid, in general), much in the way that I'd rather be punched in the face than stabbed in the gut, both options are distinctly unappealing in nature. Your idea involves almost entirely passive attacks upon other players, and while I can see that you have stars in your eyes about how much roleplay it will generate, as someone who added an update to changelings to help them not have to murder so much just to play the game, here's the facts: People are in the game to get all the cool stuff and win. They will find a path of least resistance and then relentlessly cheese whatever exploit (or god forbid, actual bug) they find in your new mechanic to gain the most entertainment and benefit for themselves, at the least risk to themselves. For instance, I guarantee you will find cultists who stand around brooding in crowded rooms, trying not to draw attention to themselves so they can spread as much corruption as possible before being caught. No matter how much you think players will use the new tools you give them to facilitate better gameplay, they will always disappoint you and find the path of least resistance to get what they want. I think you would therefore be better served creating a mechanic that encourages interaction between players actively, if you want more roleplay. If you want conversion over time that is less forced instantly on players, you will have to find a way to do that that engages both parties, rather than this, which just slowly fucking everyone up over time in the hopes that becoming insane will generate loads of the delicious roleplays out of their reactions to becoming insane.
-
I agree with all of Aticius's points here, and also want to add my dislike for 0 conversion mechanics. This defies the basic principle of cults, to be unable to induct new members, never mind all the other issues.
-
Same. I often get rolled into malf when I'm trying to play something else, and that's exciting. I would not like to be forced to play an AI if I don't want to just to be in the malf pool.
-
I was planning to rewrite doggo code too once the PR finishes so that everyone uses the same namechange helper support proc which includes stuff like admin notices of name changes.
-
Please hold off on this. I'm already implementing a name change helper in my https://github.com/Aurorastation/Aurora.3/pull/7382 PR, and redundant code is not a great idea. I'd be happy to adapt the name change helper to station pets after the PR is merged.
-
In all fairness, I have noticed that people tend to ignore the existence of vomit puddles. It's might be an incentive not to do that.
-
The bubbling sound was removed from all food/drink related reagents specifically because it was so out of place and jarring. Why would pouring two non-reactive reagents together make a loud bubbling sound? It's dumb. However, I can see why an audio cue is helpful - it's just that no one bothered to port in a newer, more subtle sound to replace the bubbling noise, so it's just silent now.
-
After some thought I would like to withdraw this application. However, I will still listen to feedback if anyone has it.
-
I can't exactly argue with first half of point 1, think your arguments start to fall apart after that. Literally in the application I posted two PRs which were extensive, complicated feature reworks or new content that were not in response to a 'disagreement' with anyone. Certainly, I have room to improve, but 'your code is not good and you only code reactively' is overly harsh and feels a little out of touch. Have you actually taken a look at any of those those recent PRs I have up yet? I haven't seen any feedback from you on how to 'improve my code', so I'm not sure how you expect me to improve when you just huff and call my code bad without giving any specific feedback on how.
-
https://github.com/Aurorastation/Aurora.3/pull/7531 Allows picking colors for your xenowear footwraps. Just like this: What an exciting new world we live in, to allow hot pink foot wraps on your burly lizardman.
-
Ckey/BYOND Username: Kaedwuff Discord Name: Menthe Position Being Applied For: Coder Past Experiences/Knowledge: I've been putting out PRs in the github for over a year, and gradually gaining experience in DM. Examples of Past Work: https://github.com/Aurorastation/Aurora.3/pull/7428 https://github.com/Aurorastation/Aurora.3/pull/7413 https://github.com/Aurorastation/Aurora.3/pull/7382 https://github.com/Aurorastation/Aurora.3/pulls?q=is%3Apr+author%3AKaedwuff+is%3Aclosed (my list of older stuff, much of which was merged) Additional Comments: It sounded like you guys could use some help.
-
Yes, we must undermine people's ability to capture individuals silently by allowing medical and savvy AIs to immediately see what is happening to them via suit sensors. Except no, that's the kind of regressive anti-antag mentality that insists antagonists must be punished for daring to be a bad guy in our utopian roleplay focused society. Before the liver update the crossbow was largely a pretty gimmicky item but at least it worked, albeit by telegraphing it strongly via toxins damage. (Though, admittedly, the last time I used it, we hadn't updated to vague terminology on the monitor and used to have numerical values shown.) Now, you hypothetically can kill someone through liver damage trying to crossbow them down repeatedly, which somewhat defeats the purpose of taking a hostage, if you kill slowly them in the capture attempt. However, it's also ranged and has multiple rechargable shots, so it having a downside like this is probably okay. As far as I'm concerned, spotting a parapen kidnapping happening on camera or in person should be enough for anyone, or we're undermining the very concept of 'stealth' by forcing kidnappings to show up on the health monitor.
-
What if I implemented a cooldown timer between escaping cuffs? Something not huge, like 30-60 seconds, but large enough that you can't just spam escape attempts for all eternity instead of trying to roleplay. It would also probably deal a small amount of damage to them with each attempt, and when you get to a certain level of damage you have to wait for it to heal before continuing. And while I'm not as confident of this part, I think it would be a little more immersive if instead of moving the player or batonning them to interrupt their mechanical do_after() action (this is the term in code for effects that only happen after an interruptable timer completes its course), there could be an action taken on handcuffed people like 'check cuffs' that interrupts the handcuff breaking. I would also probably change the George Melons is attempting to break out of his handcuffs! message to only display for people 1-2 spaces away and to be something that's not in huge bold italic red text that catches the attention of everyone in the area, like "George melons begins shifting his arms around." Ideally, this would shift the culture away from clicking resist over and over and into officers just occasionally coming back to Check Cuffs if they haven't been keeping watch over the cuffed antagonist. If you left them alone too long or weren't watching close enough? That's YOUR fault. The antagonists will have to be more judicious with attempting to escape, because if they just use it every time it comes up, eventually they're going to fuck up their wrists enough that the pain will stop them from continuing for longer. We should never have to deal with situations where the officers are just so exhausted with the constant resist spam that they start disregarding it and then the perp escapes because they missed one message in the slurry of resist spams that all blended together into a haze of red text. My primary goals here are to reduce immersion shattering game-y behavior that exists with current cuffcode, such as: -It's weird to have to push someone around or beat them to the floor to stop them breaking handcuffs. I've literally seem officers who just walk in a circle dragging someone as if this is normal behavior, when we all know it's to cancel resist spam, a mechanical issue, not a roleplay one. -It's weird that there's no penalty to constantly resisting, both because breaking out of handcuffs is not a simple act, and because it leads to this culture of pressing resist instead of roleplaying, because you can. -I don't like that that breaking out of cuffs is so highly telegraphed, because it causes situations where people can actually interrupt interactions by filling up the text box with bold red letters even though they are 6 tiles away and no one is looking at them because they are discussing lunch. If you want to guard someone, actually stand guard over them during processing, don't rely on bold redtext to alert you from across the room.
-
They are talking about that taking away options to silently capture someone will lead to more cases of people walking up and shooting people/holding people at gunpoint with no preamble. I can't say I entirely agree with that pessimistic view point of people's behavior, but I can understand their train of logic there.
-
Reasonable. It has been renamed to 'dextrotoxin'. Because it is a poison that removes your ability to use your arms and legs.
-
The issue with ganks is not an issue that should be solved in code by removing content. Like many people said, we have staff members that will deal with that.