Skyrat-tg icon indicating copy to clipboard operation
Skyrat-tg copied to clipboard

[MODULAR] Engineering staff have increased access on orange alert

Open lessthnthree opened this issue 2 years ago • 16 comments

About The Pull Request

Airlocks on receiving the signal of an orange alert level will give staff with an engineering access card expanded access. Of course the sensitive things like command offices, security, vault and such are excluded. It will allow them to get into lobbies and such of the more common areas. When the alert is changed off orange, the access is revoked. It functions similar to the emergency access feature, except it only applies to engineering.

How This Contributes To The Skyrat Roleplay Experience

A common pain for engineering staff is that in the event of meteors, explosions, and other disasters they're stuck at an airlock with no access. They can use their multitool to break in to any airlock they want, but when the station is depressurizing, on fire, or otherwise falling apart seconds matter and this makes it a more formal process.

"A major engineering emergency has developed. Non-engineering personnel are required to evacuate any affected areas and obey relevant instructions from engineering staff."

With this change the engineering staff will now have some power to access areas in said major engineering emergencies.

Changelog

:cl: LT3 add: Engineers now have expanded airlock access during orange alert for responding to emergencies. add: New lights added to airlocks indicating engineers have expanded access during orange alert. /:cl:

lessthnthree avatar Oct 12 '22 00:10 lessthnthree

Pink lights are now orange. orange_airlocks

lessthnthree avatar Oct 14 '22 21:10 lessthnthree

Pink lights are now orange. orange_airlocks orange_airlocks

This looks red at a glance. Can we see the colors side-by-side? Orange and red? (I think pink was better!)

Acer202 avatar Oct 14 '22 22:10 Acer202

Can we get a vote to use pink instead? I think it's way more clear to me as an engi main, personally.

Acer202 avatar Oct 14 '22 22:10 Acer202

Pink lights are now orange. orange_airlocks orange_airlocks

Perhaps you could use a different animation to make these stand out? Engineering stuff usually uses diagonal stripes for their stuff, having diagonal stripes go along the bottom of the door could work but would definitely need testing. I can toss a sprite your way if you wanna test it

Also, does this mean the green has been changed back to yellow too?

OrionTheFox avatar Oct 14 '22 22:10 OrionTheFox

airlock_pink image

I personally like the pink, but can we settle on something? I don't want to resprite all the airlocks a fourth time. I'm fine with the hazard stripes and faster flashing like on firelocks, my concern is that it would be annoying to the other players in the departments for however long the orange alert is. But we need to agree on a colour.

lessthnthree avatar Oct 14 '22 22:10 lessthnthree

My vote's on pink! I have a feeling people will pick up on it rather fast.

Acer202 avatar Oct 14 '22 22:10 Acer202

So here's 4 alternate sprite options: Diagonal Pink, Diagonal Orange, Blue/Pink Alternating, Off/Pink Alternating airlocks

lessthnthree avatar Oct 15 '22 00:10 lessthnthree

After discussions, the orange hazard lights seem most appropriate. The sprite has been also adjusted to look better. orangelights2

lessthnthree avatar Oct 15 '22 01:10 lessthnthree

What? Where did this discussion take place? I thought we were supposed to discuss these things here.

The flashing lights will probably get really annoying, and they look very similar to firelocks which give off more of a "Don't go here, there's danger" or a "This door is closed" kind of feeling, as opposed to "Engineers can enter here right now, but it's still operating like normal."

I'd like to see what others said to dissuade the decision to go with a more neutral pink, rather than a flashing warning light that will be all over the station!

Acer202 avatar Oct 15 '22 15:10 Acer202

Emergency access does not need to change colour, and should not to avoid confusion. The pink hazards are fine. Straight pink lines look too much like bolt lights. The orange hazards are fine. Straight orange will look too much like emergency access.

Yeah the flashing hazard patten means we can leave EA yellow. I would like the colour differentiation of pink if we're keeping yellow EA, it's so close to orange as well.

lessthnthree avatar Oct 15 '22 19:10 lessthnthree

Emergency access does not need to change colour, and should not to avoid confusion. The pink hazards are fine. Straight pink lines look too much like bolt lights. The orange hazards are fine. Straight orange will look too much like emergency access.

Emergency Access is yellow again and Engineering Override is the hazard stripes.

Please don't make me have to resprite all the airlocks a 5th time.

lessthnthree avatar Oct 16 '22 09:10 lessthnthree

I think the stripes are distinct enough that it doesn't matter too much what the colour is. So I'm happy with that. Just make sure you get all of them. image

tf-4 avatar Oct 16 '22 11:10 tf-4

I think the stripes are distinct enough that it doesn't matter too much what the colour is. So I'm happy with that. Just make sure you get all of them. image

Whoops yeah, missed a sprite. Fixed.

lessthnthree avatar Oct 16 '22 19:10 lessthnthree

it is immensely easy for this to be done via the signal system and if you need help doing so, i'd be happy to walk you through how to implement this using signals for a far more performant and significantly less laggy implementation of this

Iamgoofball avatar Oct 19 '22 22:10 Iamgoofball

alright so here's the writeup on what you gotta do to move the engineering access to signals

  1. in the Initialize for airlocks, if they meet the criteria you set for "should this door qualify for the engineering access", register the signal against the security level subsystem like so:
/obj/machinery/the_door_path_goes_here/Initialize()
  ..()
  if(whatever_checks_for_engineering_emergency_access_qualification_goes_here)
    RegisterSignal(SSsecurity_level, COMSIG_SECURITY_LEVEL_CHANGED, .proc/handle_engineering_access)

/obj/machinery/the_door_path_goes_here/Destroy()
    if(whatever_checks_for_engineering_emergency_access_qualification_goes_here)
      UnregisterSignal(SSsecurity_level, COMSIG_SECURITY_LEVEL_CHANGED)
    ..()
  1. make a new proc on your doors, it's gonna listen for the security level change and take in the new security level
/obj/machinery/the_door_path_goes_here/proc/handle_engineering_access(datum/source, new_level)
  SIGNAL_HANDLER
  if(new_level <= ACCESS_LEVEL_FOR_ENGINEERING_ACCESS_YOU_WANT) // see security_alerts.dm
    disable_engineering_access_here()
  else
    enable_engineering_access_here()

bam, you're done, it's now signal based

Iamgoofball avatar Oct 19 '22 22:10 Iamgoofball

plus, to make it even easier, /obj/machinery/door is already hooked into security alert level changes for some fuckin' reason you can just override /obj/machinery/door/proc/check_security_level(datum/source, new_level) on airlock and do all your stuff in there

Iamgoofball avatar Oct 19 '22 22:10 Iamgoofball

This PR has been inactive for long enough to be automatically marked as stale. This means it is at risk of being auto closed in ~ 7 days, please address any outstanding review items and ensure your PR is finished, if these are all true and you are auto-staled anyway, you need to actively ask maintainers if your PR will be merged. Once you have done any of the previous actions then you should request a maintainer remove the stale label on your PR, to reset the stale timer. If you feel no maintainer will respond in that time, you may wish to close this PR youself, while you seek maintainer comment, as you will then be able to reopen the PR yourself.

github-actions[bot] avatar Nov 07 '22 00:11 github-actions[bot]