-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds new Criminal Status designations (SecHUD) #11909
Conversation
While I'm not really sure to what extend "Armed and Dangerous" will be useful as most culprits are usually expected to be hostile in some way when wanted and approached by Security, I can see "Search" becoming a really useful addition. I have a tendency as AI to tag people for Arrest with the reason of just performing a search, and most officers - due to their inability to read charges properly on the HUD - arrest them instead of just searching, so this might come in handy. Monitor I only see useful for AI and cyborgs to use. Most of Security won't be really stalking people just to make sure they don't commit any crimes, so the Monitor tag would only be an addition for the AI to sort of "occasionally check in on them" of sorts, and not a lot more. Over all, I'd appreciate to see this in game, though I'm not 100% certain whether or not you might also want to include a "Searched" icon for when the search is actually conducted on them. I tend to just slap Released on people I frisked. |
Thoughts:
|
For the armed and dangerous, in short, I thought this as a try to limit the "stun-cuff in sight" -way to arrest to be primarily used only against people designated as such. Presently, on code green and bule, the Sec SOP states not to incapaciate and handcuff any arrested person prior to trying perform the arrest without. Code red however states, that "Security Officers may arrest crewmembers with no stated reason if there is evidence they are involved in criminal activities", which is kind of loose and allows stun-cuff then brig -type of action on any person arrested. While it's usual to spend a big part of the shift in code red, not every arrest warrant needs to be executed the stun-cuff way. Namely, if the crimes in question are not of major/capital type, or the proof is not certain. With the distinction of A&D and regular arrest I'm thinking of the antags too, as of while in code red just a suspicion with the arrest tag could lead them to lose it all that quickly, which seems to be one factor to encourage being (overly) stealthy. Then those antags, who are going out loud, could be treated with stuncuff-in-sight as designated to A&D. I think of that Kluys' opinions on antagging -forum thread with this. This one is close to the execution order, indeed. Though, we don't want issue execute on, for example, known and armed criminals of the mindwashed type without them having done capitals and without the proper procedure. Same for vamps in case we're not certain whether they are powered or not. So all in all, by this proposion it would be like this: regular arrest on code red - depending on the situation, prefer arrest by stating it first on, if they flee, then proceed with a stuncuff. A&D warrant, the perp is confirmed to be dangerous if apprehended, stuncuff-in-sight. It is a question, indeed, too, whether that status, if applicable, should be possible to be set via the HUD. On the Monitor status, it's there because of my own experience, had it here for thoughts on it. I thought that it could be useful for the cluster fun cases, in which there is something serious out there but we don't have the exact lead. Reported changeling identies, partial evidence on somebody being into crimes, and such. For example, if sec happens to be quickly at a murder or break-in scene, a suspect is there, but search and forensic can't link the crime to them. Using the monitor status could be an alternative to stuff a suspect into processing for a long time while the needed investigations are on their way, while still tagging the primary suspect to be linked in the issue. That way preventing the latter a bit, maybe, and at least provide memory aid for security on the cases that are not that straight-forward. Search icon, indeed - what could be an alternative? I tried a yellow background, but that felt like too bright, the S was difficult to read. Could try it again with outlining the S symbol while the background is yellow. Or having the S with other color than white. Posting alternatives here soon. On further hud tweaking, I'll have a try with these. Thanks! |
I'm not sure it is a good idea to limit stuncuffing more than we already do. We already prohibit it (via SOP) on green. Pushing people not to stuncuff, even on red, is just making sec's lives more difficult for questionable benefit. I'm not sure it is an improvement. I'm also not sure that 'A&D' status will work in practice like you think it will. Lethal force is authorized against armed targets. 'Armed and Dangerous' I think is going to get interpreted as 'kill on sight' by officers. I still think adding 'search' and 'demote' sec statuses would be good ideas. But they need distinct icons. I also think that the earlier idea I posted (of putting the most recent sec note in someone's file into their examine text if you examine them with a SecHUD on) is a fairly big deal for security, seeing as it would eliminate a lot of 'why is this person set to arrest' and enable sec to tell the difference between different types of arrest warrant even without dedicated statuses. |
On stuncuff, I see the point. My intent on that was having a manageable aid for officers on which kind of arrest is in question, A&D for like confirmed EoC, so, that it will be a dangerous job to apprehend, then arrest warrant on minor crimes or in cases, which are arrests as code red permits, "with evidence on being involved in criminal activities", while not being certain they are actual criminals. As we spend long time in red typically, the arrests of latter type, executed with the stuncuff-in-sight, seem to be one factor detoriating sec-crew relations, when IMO number of those could be handled, if the situation permits it, the code green/blue way (stun-cuff if they resist it anyhow) with better results. On second thought, yeah, SOP-wise limiting the stuncuff on red might not, either, serve this. You could do an arrest with less force anyway, if the situation permits that. And the separate A&D warrant might just lead to misuse of force. Space law knows A&D already, too. My question was to aid the memory and judgement of the officers with each arrest situation, presently tagged with the same W, whether it's a dangerous case and got to do it quick and cautious, or whether I could have better results with less force in first hand. But the about-same mechanical aid could be indeed provided with having the most recent comment instantly visible on examining a person while wearing the HUD, without the risk of misuse that having the A&D warrant and symbol there carries. That would be a great little tweak, didn't come to think about it at first hand. Got to admit, I did read the notes from sec computer for a long long time. Conclusion: I'll proceed with removing the A&D status and icon, having the thought behind that in adding the examination while wearing the HUD -feature, and having icons and status designations for "search" and "demote.". ETA few days, got some work ahead. Thanks! |
I liked the armed and dangerous idea, shame you decided against it. The difference between it and execute would be that you are supposed to revive someone armed and dangerous if you take them down with lethals, while an execute person gets cremated or borged after death. It would also mean the difference between lethalling them until they drop and then arresting them, and harmbattoning them to death once they're down. But eh, let's see how things work out. |
In your CL, you dont need to mention the files you changed with each change, just a summary. Youre fine to mention these parts outside the CL blocks though, just inside the blocks keep it to format, otherwise it will break the webhook processor Compacted CL is below
Also I recommend downloading git and using it locally, instead of using the god awful web based file uploader and editor |
I'd say it depends on whether tweaking the security/legal SOP to know different arrest warrants is seen an idea to work on. I thought the A&D tag to work the way you said it to, but if implemented to the present it might just turn out bad, as shortly discussed above. In my opinion, it would be good if there was separate section in SOP to rule warranting and conducting arrests and search. Presently the how-to is under job specific titles at Sec SOP. Which makes it to be not that easy to refer to. As well as I think this new "arresting" -section could know three kinds of warrants: A&D, arrest, search. I've set up a forum thread for it. If that is seen good to go, A&D arrest including, then maybe. With this PR I will update it so, that it could be implemented to the present situation. Updating this, and having the sketch of the SOP proposal to the forum thread, got delayed by work, I'll return into these soon.
Thanks alot! I'll update it, and yeah, indeed it seems so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xXx-RegularJoe-xXx
Conflicts. Inform when deconflicted. Ping me on discord or DM me on discord preferably - I check my e-mails all the time but may not catch it.
PR is already accepted. Inform maintainer when reopened and deconflicted. |
When you do open it, you should probably update the changelog, as this isn't accurate anymore. |
What does this PR do:
This PR adds new Criminal Status designations:
Aim of the change
Twofold idea behind this:
In short, the ideal of this as a feature (with a related SOP change) is to have there three types of warrants that could be issued on perps in need of different treatment: armed and dangerous, aka the "stun cuff" warrant, then the arrest warrant as-is, to be issued known or probable criminals, then, at last, the search warrant to be issued on suspected crew, marking them to be either searched or interrogated, but not as criminals (yet). These could have their own tabs at the sec SOP, for ease of referencing and ease of new sec officers to get the grasp on how to do the interaction with the crew. Above all this is about reducing the "stun cuff" taking place: this kind of interaction should only take place when the perp is known to be dangerous, such as certain vampires, the loud way agents, so on. While the present SOP does have this spirit already, the intent is to make it more clear.
The "Monitor" status is just of my personal experience that it would be neat to have a neutral HUD symbol on somebody, that is known to be linked in criminal activity, while there is no condemning evidence on it. So we could have a BOLO list.
To be considered
This PR is conjucted with a SOP expanding proposal, so I'd like it to be considered along the feature itself.
Then, in second, if a SOP change is out of question, is this found beneficial as a simple memory aid, without any SOP add-ons? And in third, if otherwise liked, are the icons fine as-is?
At last: this also served as a learning experience for me, so I did not ask anybody beforehand if this kind of feature is wished at all. Saying simply "no thanks" is a fine option as well, it did serve me the learning already!
Also, if I've done something wrong with this, correcting notes are thanked in advance.
Images of sprite changes:
馃啈
add: *New Criminal Status designations: Armed and dangerous, Search, Monitor
add: Designations to be available to modify with secHUD
add: Threat levels to Beepsky for the new status designations, A&D = 6; M, S = 2
add: Designations to be available to modify with sec records computer, incl. record line colouring
fix: Existing "execute" criminal status had no threat level for Beepsky = presently beepsky ignores executed
imageadd: Hud sprites for the designations; A&D has a mildly flashing animation
imagetweak: Mildly flashing animation for the execution hudsprite
/馃啈
UPDATE 31.7.2019 - Work in progress, going to update this accordingly to the discussion below.