Amunak

B-but unironically I think borer is great ? Though I guess it doesn't work too well as a voted-in gamemode, and it isn't in secret either q.q

Interesting, looking at the code both hypospray and syringes can be used on people in suits. Syringes have a specific check for this, whereas hyposprays simply don't bother to call `can_inject` and thus can be used on any mob at any time (which is probably a bug). Unfortunately borg hypos are a different thing as well, and they do check `can_inject`, which is why borgs can't inject suited people. IMO can_inject should be added to regular hypos but allowed to inject people with suits on. (And the code should be probably moved to reagent_containers so that we don't have 3 different copies).

Oh! Maybe just fixing that instead would help? I don't see a reason why the hypo (including non-borg) should be incompatible with this. Like, you'd expect them to be made specifically compatible for exactly this reason.

Maybe this already existed at some point and was removed, but what about just giving voidsuits and hardsuits (maybe just some types?) an injector port to quickly help (or not) people inside? I'm pretty sure I've seen at least some semi-realistic Sci-Fi have that, and it makes perfect sense (to me anyway). Not sure if it would somehow upset the antag balance or whatever.

Ckey/BYOND Username: Amunak Discord Name: amunak#4953 Position Being Applied For: Coder Past Experiences/Knowledge: I've been programming for over a decade now (both for fun and as a profession), as well as running various servers (with boring infrastructure). I have a BS in applied informatics and in my career I've done most of my work in PHP (and Symfony), although I don't shy away from C, C++, C#, Java or Python (or really anything else if I'm motivated enough). Examples of Past Work: Played and coded since 2014, though with a biig gap in between. Even ran my own (Baycode) server with a few friends for a while. Previous Baystation12 contributor (PRs) Most notably I have pioneered "chat tags" / images for the various (OOC) chat "channels" and I normalized channel and radio colors at the time. I also did some major refactors for what it's worth. Doesn't look as cool now as it did back then, lol. Current Aurora contributor, and - at times - a player: PRs are mostly smaller, QoL stuff. Some of these have even been accepted Closest to DM experience I have made some Minecraft plugins and mods in Java and have been a mod of the biggest server in Czechia for like 5+ years. I like lists and being verbose. Sorry. Additional Comments: I'm very new to Aurora and as I had an almost-uninterrupted pause from SS13 for like 5 years I'm somewhat re-discovering the game and the code. I was looking for a HRP place to play a bit and hopefully introduce some friends to the game, but I couldn't help myself and had to contribute because apparently I have too much free time. I very much like it here however; the community is nice and the developers are very helpful and encouraging. My motivation is mainly to have access to the staff meme development channel to get a better idea of what's going on on the inside and perhaps being able to communicate and coordinate better. I don't have any "big project" in mind, though with my luck almost every simple fix somehow becomes a bigger project. I however do have a list with some thing I'd like to do, and every time I do something it only seems to grow. I actually tend to shy away from bigger things since I sometimes have trouble seeing them to completion, but I've been quite motivated to work on things lately, so who knows. I also have to admit that my biggest concern is that my motivation and/or free time will wear off, which is why I was hesitant to make this post. No matter how this goes I'll gladly be a part of this community, with or without a green name. It's gratifying and fun.

They should, as he cuts off all interaction. If not we'll fix it

Then perhaps make it so that they know about its existence, and that if something happens that they need it they must ask the captain, AI or perhaps seek out the slip on the briefcase (which would be a great addition in any case I think).

From the few games I played I have to say I don't like the vision cones much either. It's cool and seems to add realism at first, but even if you don't fight (which I never did during my play here yet) it tends to get in the way. As others said, even when just RPing you now have to turn around much more, you have to check all the time if the person you were talking or walking with is still there, etc. I know there are the "step marks" or whatever, but I'm not sure that's enough. As an example, I may be talking with fellow engineers in engineering break room, but I also want to look at the console up top checking on whatever. And the vision cones make me turn around all the time just so I can see if they're still there. It's also not really how people work, as usually you'd just be able to turn your head and body a bit when you want to look. Given how hard and slow it's to turn in this game I don't think it's really a surprise that it gets annoying. Overall I'd prefer if it was not a thing, though I wouldn't say it makes me not want to play. Oh and I think that at least some of the issues people have with it could be fixed if you could see even behind you for like 2 tiles. At least melee should be better, while you'd still more or less have that "stealth" effect.

Makes sense, I'm happy for the feedback even if it's negative. Shows me a different perspective! I'll be closing the PR as this is clearly not the way to go. However I'll be considering adding a simpler check that makes it so that when you are on help intent (and with a regular mob, too) you wouldn't damage others with items, essentially preventing accidental attacks. Please tell me (feel free to @ me on Discord) if you see any caveats with that (and keep in mind that's a completely different kind of change).

Just adding a freeform law wouldn't work regardless as in case of conflict of laws inaction is the default action. This is flavored as a chassis programming thing - the borg is physically incapable of doing that action (kind of like, say, climbing a ladder), so law changes would have no effect. You would also have to hack the borg, though there were some talks about adding metadata to laws that would allow them to change stuff like this. But I expect that would be a pretty big undertaking and is definitely out of scope for this.

This is an idea I implemented* in #10360, though the idea really belongs to @Chada1. As the title says, the idea is to prevent regular borgs from attacking living beings. This includes most mobs (except simple ones; rats, carp, ... they can also still attack vines and similar things). The logic is that they are already not supposed to fight - their laws dictate self-preservation whenever possible. The change makes it so that when they try to attack they only get a message similar to the one when they try to electrify a door: "Your programming does not allow you to harm <thing>". It's a mechanical way to better enforce our rules for borgs, both IC (laws) and OOC. It also nicely solves the issue of borgs accidentally hitting/damaging people with tools. Even a cornered borg still has defensive capabilities (flash), and I believe there were some PRs with additional things on the way (though I can't find any ATM). Emagged, traitor, syndicate, combat, ERT, ... borgs are not limited by this. It was suggested that they should have a toggle as to not accidentally reveal themselves. *It still needs some changes and perhaps more testing. It's more like a proof of concept.

Not sure what you mean? The number of ghosts is independent. I often just ghost because I don't have time or will to commit to a round, and if I didn't dislike the idea of NT-ERT I could join as an ERT without participating in the round before. There are plenty of people who do this, but who do join the ERT when it gets called. It was a borg antag and a human (former sec I think?), the ERT just ION'd the borg who was closer and then obliterated the human with ballistics. All in a timeframe of about 10 seconds (after talking with them for a minute or two trying to get them to surrender, which they didn't seem to do, they just stood there and talked. It's not my place to judge whether it was justified, I didn't participate in it and I didn't even see what the antags did previously, so maybe it was justified. But what I don't like about it is the whole situation: lore-wise ERTs (and NT-ERTs especially) are there to end the threat, which makes sense. But ending the threat also means ending whatever was going on before, and with decent antags that's often more fun for everyone.

There seems to be quite a lot of people saying that something needs to be done about NT-ERT. Unless we want to make another thread I'd like to keep talking about it. As was suggested even by you, the way to go is probably making NT-ERT spawn dependent on things like: How much (alive, non-antag) security is there? Someone came up with a nice formula that would essentially allow to spawn as many NT-ERTs as there are antags minus active security (so none if you have two antags and two security - some other ERT would get called instead). How much havoc they've done. This could be hard to calculate because of indirect deaths through explosions and whatnot, but at least direct kills (or damage) by them could probably be counted. How late it is in the round, or even what kind of traitor it is. The overall other composition of the station staff. If it's a lowpop round maybe heavier ERT is justified. And the why? Because right now I watched another NT-ERT - just a single guy - obliterate two antags 10 seconds after they didn't drop their guns as he asked. That's definitely not helpful to the round's roleplay.

The whole areas there are mapped ... well not ideally. But changing that would be a bigger change. Didn't find the switch you mean. Perhaps it's already fixed? ---------- The following changes have been made in https://github.com/Aurorastation/Aurora.3/pull/10332: Replaced regular bed with a roller bed. Added the bucket. There is no "toilet door type", departments just use their own doors. I added the bolt, as well as to all the other bathrooms where it was missing (command and patient). Done, that very much makes sense. It even goes nicely that the AI can still see inside - at least until the window tint is turned on. (Also done for the Rep. office)

Love it, especially the fact that the only colored parts are those that actually make sense colored. Now if we also had colored PDAs... Also, ideally you could make a palette with master colors and shades to pick from so that other sprites know what to use and don't need to use caps and whatnot as reference.

There has been an update! As per feedback from Arrow768 traitor/malf AIs and admins can now choose to use the regular (un)bolting and fake being a proper AI. The UI has been updated to add separate "Force (un)bolt" buttons and I also added area and airlock name into the UI. For details and screenshot see the PR please. --- As an aside I'm grateful people like the direction! Thank you all.

I created a PR that concerns some issues brought up in this topic. Feedback thread PR#10310

I created a PR#10310 as an attempt to kind of bring back bolting for AIs and stationbounds without making it overpowered and unfriendly to roleplay and antag players. The main points are: AIs and stationbounds can bolt some airlocks, but it is only a handful of types (external airlocks, high security ones [think Engineering Secure Storage, Vault entrance, almost everything near AI core/upload and Bunker] and Hatches [tcommsat and a few other places] plus more or less anything that's bolted at start of round). There is a lenghty timer before either bolting or unbolting happens. It adds new mechanics and meaning to AI control wire (hacking), so there's more stuff to do for not just the AI but players as well. It is highly configurable and versatile, so if the current configuration doesn't work it can be just tweaked and doesn't need to be completely removed. I also wanted it to work as at least a small incentive for antags to subvert the AI. At least a little bit. Additionally the PR adds a notice for AI players to keep in mind their influence on the round and not to ruin peoples' fun. For more details read the PR description carefully please. It's long, but it's hard to describe the changes otherwise even if in gameplay they feel natural. There's also a bunch of related and miscellaneous changes and a few bugfixes. There are also some examples of which airlocks this concerns and a ton of screenshots documenting the changes. It was created with several other threads in mind; from what I've read and seen a lot of people think the AI is kind of useless and boring now, but we also don't want it to allow shutting down the round due to mechanics. The fact that as an AI bound by laws they must obey command doesn't help. I'm mainly seeking feedback on the points outlined in the PR (or any general feedback if you have some): Do you think this is too much of a buff and a return to the previous state? If so, how would you change the defaults for which airlocks can be bolted? (Personally I'm not so sure about the high security doors, but I also think it makes sense if AI has control over them.) Waiting 8 seconds for bolts to raise/drop might be too much. But it definitely allows reaction from people; if the AI was trying to lock you in you could just open the doors and they'd bolt open. Is it too much / not enough? Keep in mind in emergencies you want to be able to unbolt fast-ish. We could also just separate the timers (or even override them for specific door types) so the options are endless. The "AI Help" text, especially the OOC part might be too wordy. I'm open to suggestions.

Yeah, that does sound undesirable. I would expect the whitelisted command roles to know better (was the bolting removal before or after whitelisting command roles?) but I guess when you have a legit ICly tool to simply handle a situation there is no good ICly reason not to use it. In that sense I agree with the removal, as it's no longer even really a player problem. Thank you for the explanation. With that in mind I'll explore options to add gameplay elements for AIs that hopefully don't have this issue.

Ah right, I didn't know that was possible before / on other servers. TBF it would be possible to allow AIs bolt open doors only, but at that point we should probably allow both. Alternatively (or in addition) there is something I wanted to do for a long time regardless; adding an option to timings in doors that's "timers off" which would make the doors not close automatically at all so they'd have to be clicked (and possibly same with opening? idk). But I do miss that. I'll look into adding the message.

True, that was a bad example. But bolting doors because there's, say, a spider in the room would be a legit use case. Also the heads might want to give the AI an order to block access to some place for whatever reason, and we can't do that now. Oh, and bolting doors *open*. Like, I just think it's a nice, fun mechanic for the AI that shouldn't have been removed from the game. What do you think about adding something like a override permission on higher IDs so that they could then unbolt (or even bolt) doors with an alt-click or something? Do they? You could easily play a chef for a week, never even leaving kitchen, and then go on to play AI and play it like shit against antags. I actually considered playing AI and I didn't know; I probably wouldn't have ruined peoples' fun but you never know. I would definitely take more care after reading this topic. Having a message there wouldn't hurt anything. Obviously there is always the nuclear option of just putting it behind the same whitelist as department heads are. Oh, then I guess it doesn't matter much? It would still help antags some, but it could potentially make the AI's job even harder. And regular crew could be shits about it as well. What specifically do you mean by "while visible"? I thought you always had to be visible (except, I guess, in the areas without camera coverage).

I'd actually love if AI still had an option to bolt doors; there are absolutely valid reasons to do so even outside ruining fun for people. Door leads to unpressurized area or something? Bolt it so that crew doesn't accidentally wander in. Doing stuff like that is quite fun as an AI player, IMO. To help the issue with AIs fighting antags too much we could (and IMO absolutely should) add OOC notes to their role for start-up where it tells them what to do and what to avoid. Even just saying something like "Please remember that as an AI player you are extremely effective against non-crew and thus also potentially effective at ruining everyone's fun. Don't forget to give all players some leeway; you don't have to report every petty crime, call out every suspect or provide unfallible evidence without asking. Your role is supposed to be supportive and assistive, not assertive." could probably help, especially for newer players. Maybe then we could even bring back bolting... And if not, perhaps some other mechanics could be added to facilitate AI blocking access (for at least willing people), while not blocking access for antagonists. Perhaps an opposite to "IDscan" - a toggle where yellow lights light up on an airlock, and some special permission (which, say, engineers, EMTs and command would have) or intent (maybe a confirmation "Are you sure to enter?") is required to override it? One huge problem with AIs being able to bolt only when antag is IMO the fact that OOCly when people see more than handful of bolted doors that otherwise wouldn't be they can guess it's malf AI. To prevent AIs ruinging antags we could also base the camera follow feature on suit sensors; if they were turned off completely the tracking could be made impossible. But I'm not sure what other repercussions that'd have.