Denied Add SCP hacking alerts to GSD SGT+ and SA+

[Zen]

What does this suggestion change/add/remove:
Adds SCP hacking alerts to the following:

• GSD SGT
• GST CPT
• GSD MAJ
• GSD Chief
• Site Advisor
• Site Manager
• Site Director
• O5-X

It makes no sense that only GSD SCU specifically would get these alerts, but not their superiors. What if nobody is on SCU? Especially if there's no E-11 on.

Has something similar been suggested before? If so, why is your suggestion different?:
Not to my knowledge.

Possible Positives of the suggestion (At least 2):

• During low-medium pop, there are still hacking alerts even if there's no SCUs or E-11 on, which there often aren't below like 60 players
• It simply makes more sense - why would an SCU get an alert, but not even their Chief?

Possible Negatives of the suggestion:

• None. Balancing isn't actually a concern here, because either:
  • There are E-11 or SCUs on, and so the hacking alert would be received and spread via comms anyway.
  • There aren't any active E-11 or SCUs, and so the site absolutely needs those hacking alerts or it's completely fucked.

Based on the Positives & Negatives, why should this suggestion be accepted:
This just makes sense. It's QoL for GSD, not having to have someone on SCU to get the alerts, and it makes downtime not quite as fucked because someone can no longer hack an SCP without anybody even getting an alert.

 

[Zen]

To add to my point (Don't call me a chud istg).
I used to put almost ten hours sessions into this server ranging from playing from 8pm to 4am, to playing 6pm-6am EST. I regularly played both when the server was bustling, To when there were 10 people on the server.


I could see it being a good idea if Gensec leadership could keep a hold on their lower ranks, But that just isn't gonna be the case. Most likely some GSD leadership is going to call out a breach, and most if not all of Gensec will abandon D-Block to combat hackers E-11 will have handled by the time we send someone up to open the bulk.

On UK, the moment a hacking alert happens, E-11 call it out 100 times in /c, and this isn't an issue. GSD already know at high pop. It's just low pop that nobody knows.

 

[FrostByte]

+/- Support

I dunno about GSD Sergeants and stuff but I can definitely see it for Major or atleast Chief and Site Administration.

 

[vvvvvv4203]

On UK, the moment a hacking alert happens, E-11 call it out 100 times in /c, and this isn't an issue. GSD already know at high pop. It's just low pop that nobody knows.

The issue isn't the fact that it's being called out, The issue is who's calling it out. If an E-11 calls out "Hacking 049" on high pop and it's a singular CI DC, we can tell Gensec not to horde down because the DC will be demolished. If Gensec leadership calls it out, lower Gensec will have a harder time listening to E-11 if we don't want them all rushing down for a single CI DC or techie hacking. Maybe if they get it on a delay so E-11 can call it out first and assess the situation.

We are suppose to work with general security, I know that, But a lot of the times the people we get responding to heavy calls are either

A.) Morons who have no idea how to navigate HCZ, Get lost, Then yell at us when we don't hold their hand the whole way through

B.) Are unimaginably rude when we ask them to not be dickheads about us not opening bulks for them the nanosecond hacking is called out.


I do definitely agree with uou that there should be something set so they get notifications when no E-11 or SCUs are online though. That's a no brainer.

 

[Cloudblade]

Suggestion Denied​

---

Hi @Zen ,

Thanks for taking the time to make a server suggestion.

The Content Team has chosen to deny your suggestion due to the following reason(s):

We don't think the addition of SCP hacking alerts to the jobs mentioned would provide enough of a benefit to prove useful in the situation that somebody starts hacking an SCP out, as E-11 already communicates alerts over comms pretty quickly when they get one.

Your suggestion will now be locked and marked as denied.​