Make airlocks on station enter emergency access mode when nuke is close to detonation

[Sparlight]

About the PR

I have changed the endgame for nukie rounds such that, as soon as the nuke music begins playing, all doors on the station enter emergency access. This attempts to encourage a bit more action or force players together at the endgame of a round.
If the nuke is disarmed, all doors will return to their normal state (or whatever emergency access state was already set) after ten seconds.

Why / Balance

This change was made in response to something I find is a common issue in nukie rounds.
If the nuke is set in a secure zone, it is often going to be able to detonate without any issue. Oftentimes, the nukies get ahold of AA or something close to it and move the nuke very far into a secured zone to minimize the degree to which they have to defend the nuke.
In these situations, there can often be a couple dozen people or so alive, but none of them have adequate access to reach the nuke, and if they do, the process of actually getting to the nuke in time for any reasonable combat to change the pace of the round to occur makes it happen late enough for the effort not to matter.

The change here would hook into a familiar audio cue - when the nuke music plays - and unlock all station doors to emergency access. Usually by this point the round is either decided, or there is just enough time for a final push. This allows for more dramatic gameplay moments at the critical climax of the round.
I understand not all nuke music is the same, some lasting between 1m50s to 3 minutes. I'd still argue that timing it to the randomly-selected music helps push players into one last push, if at all. This time between nuke arming and the granting of emergency access also allows players to prepare for what may inevitably become a planned counter-attack, rather than running around in circles trying to find the nuke and despairing that nobody left alive can access wherever the nuke is.

In the event the nuke is disarmed, the emergency access restrictions on the doors will be reverted after ten seconds, giving players some time to reposition themselves. This also maintains the status of emergency access on doors that already had it set.

Technical details

This modifies the shared classes AirlockComponent and SharedAirlockSystem, as well as modification to the server-side NukeSystem class.
The changes therein are minimal, but this being my first PR, there's bound to be something wrong with my approach.
I tried using event calls, but I couldn't manage to get them to receive. My next best bet was to use the EntityManager to find all airlocks belonging to the nuked station's grid and toggle their Emergency Access state. I had to add a variable to store their emergency access state prior to all doors being EA so that I could revert the permissions if the nuke was disarmed. Additionally, I took notes from the Nuke's timer use and learned that each component has an update function called each tick. I leveraged that to make all airlocks revert their emergency access state after a certain amount of time has elapsed since the nuke disarmed. I have set this to ten seconds by default.

Media

Ss14.Airlockeapreview.mp4

• I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

🆑

• tweak: All airlocks enter emergency access mode when an armed nuke gets close to detonation.
• add: All airlocks revert to previous emergency access mode settings on nuke disarm.

[Sparlight]

Yes. This does produce some swing in variance to when this happens, but generally speaking, it averages around two minutes or so. I personally don't mind the random element that the music length produces in determining how the end of round goes, but I can understand it might cause friction.

[metalgearsloth]

AudioSystem lets you get audio length and fixes this problem entirely just nuke code needs rewriting to take advantage of it.

[Sparlight]

AudioSystem lets you get audio length and fixes this problem entirely just nuke code needs rewriting to take advantage of it.

I might be mistaken - it seems like the nuke code already accounts for the length of the music track, and it has a part that times the nuke track to play and finish before round-end. That's where I hooked into to time the door emergency access toggle. Is there some part of the nuke code that isn't already accounting for audio length that I'm missing?

[IProduceWidgets]

Tying it to the musical que seems odd and like a weird thing to ballance around going forward.
My suggestion would be to do so upon Delta Alert being set instead. With a delay if that's desirable.

[Sparlight]

Tying it to the musical que seems odd and like a weird thing to ballance around going forward. My suggestion would be to do so upon Delta Alert being set instead.

Yeah, that's fair. Not having a consistent time for the airlocks being EA can be a problem. Would it work better, do you think, if I set it to a static time (i.e. two minutes) beyond the nuke's activation? Part of what I'm trying to avoid is having the nuke grant temporary stationwide AA at the get-go, and to focus it more on the end part of the round. For my brain, that's when the music is playing. But nothing wrong with going with a static timer if that's what people are gravitating toward.

[IProduceWidgets]

I think a delay could be fine, especially if you keep the second announcement of the EA change.

Tying it to delta alert also gives the nice benefit of being able to make it generic and usable for... other future imminent destructions...

[Sparlight]

As a note of progress - I've got on my local version of the branch a version that decouples this from nukes and listens to OnAlertLevelChanged, such that a change to alert level delta will set a two-minute timer on doors before they go into emergency access. It works perfectly, but I'd like to tidy up the localization strings and some of the logic in general. If that's the route we want to go, I've got something in the wings for it, at least.

[Brandon-Huu]

IC, why wouldn't it be immediately after the nuke is armed or alert level changed to delta?

[Sparlight]

IC, why wouldn't it be immediately after the nuke is armed or alert level changed to delta?

IC? I suppose I'm not the best at IC reasoning - but there's verbiage in the nuke warning indicating that there's a potential for the nuke to have been armed in error.

For a company like Nanotrasen with seemingly lax workplace safety adherence, it makes sense for them to wait until it's more obvious that the station would be destroyed for workers to have the kind of freedom of movement that unlocking all doors would provide.

The delta-level alert also suggests crewmembers listen to their heads of staff for further instruction. Allowing the staff time to convene before a blanket evacuation protocol makes sense.

[a-person5660]

How will this work with the nuke getting disarmed and re-armed?

[Sparlight]

How will this work with the nuke getting disarmed and re-armed?

In the current state of this PR, it would re-enable emergency access on re-arm as long as the timer is short enough for the music to trigger.
In a WIP on my local branch of this PR, I've migrated this logic to be based off of alert level being changed to delta. In this case, doors have a (180 second) timer before their emergency access begins when the alert level changes to delta. Because the new logic would decouple from the nuke logic, the doors would have no information on how close the nuke is to detonating, and as such will always wait three minutes from the time delta alert is enabled, meaning if it's disarmed close enough to detonation and rearmed, emergency access would not apply.

Now that you bring it up, I really don't like how the proposed changes would affect this; but I might be able to add a flag to force emergency access on subsequent occurrences of alert level delta.

[thebadman4662]

For a company like Nanotrasen with seemingly lax workplace safety adherence, it makes sense for them to wait until it's more obvious that the station would be destroyed for workers to have the kind of freedom of movement that unlocking all doors would provide.

NT is not lax with nukes though, you need to get the code specifically from them(admemes) when needed to destroy station in extreme ergency so random bullshit does not happen. Only other way is bruteforcing whole lto of combinations... or nukies but thats just a myth and they are certainly not real so not need to act upon them.

[Sparlight]

Alright, I've changed this away from being tied to the nuke music, and it now listens to the station's alert level. If it changes to Delta, the doors begin a timer that counts down. Once the countdown is finished, the airlocks enter emergency access mode and a station-wide announcement plays indicating as much.

Compared to before, the announcement that plays is a bit more genericized; it is not targeted at the nuke, and as such won't tell players the remaining time before detonation of the nuke. It simply indicates that a station-destroying threat is ongoing.

This loss of functionality is due to us not having access to NukeComponent anymore and as such there's no information on how long until the station goes kaboom.
I've also created a flag that is set the first time emergency access due to delta alert is enabled. If this happens, then every time the station enters delta alert from thereon the doors enter emergency access immediately. In the current state of the game, this means that if the nuke is disarmed then later rearmed, the doors won't waste time on their timer and they'll immediately be set to countdown 0 and open to emergency access straightaway.

Other than that? Functionally pretty much the same.

SS14.AirlockEAPreview2.mp4

[Plykiya]

Update the defusal announcement to indicate that the doors will re-lock after a short period of time...? although this might naively assume that the bomb got far enough that the doors even went into emergency mode in the first place. Hmmm.

[Sparlight]

Update the defusal announcement to indicate that the doors will re-lock after a short period of time...? although this might naively assume that the bomb got far enough that the doors even went into emergency mode in the first place. Hmmm.

I could add on an announcement when delta alert reverts if the door locks engaged - though we already have two pretty large announcements coinciding with the bomb defusal. I worry about announcement bloat.

[SlamBamActionman]

I could add on an announcement when delta alert reverts if the door locks engaged - though we already have two pretty large announcements coinciding with the bomb defusal. I worry about announcement bloat.

I don't think this will be necessary. It is a pretty logical progression that "emergency ongoing -> doors unlock ; emergency over -> doors return to normal". Additionally it will also be very easily felt through gameplay, since doors will lose the emergency access lights in close proximity to the alert change.

[Killerqu00]

IC, why wouldn't it be immediately after the nuke is armed or alert level changed to delta?

IC? I suppose I'm not the best at IC reasoning - but there's verbiage in the nuke warning indicating that there's a potential for the nuke to have been armed in error.

IRL, secure locks are tied to the fire system. If a fire occurs, all locks release, letting people evacuate.
Also, the error mention in the announcement is probably an inaccuracy - the detonation is timegated as an additional security measure from bad actors, not from a human error.
Also, how are players supposed to know that doors unlock specifically after 2 minutes? I would just tie it to the Delta code for readability and simplicity.

[Sparlight]

IC, why wouldn't it be immediately after the nuke is armed or alert level changed to delta?

IC? I suppose I'm not the best at IC reasoning - but there's verbiage in the nuke warning indicating that there's a potential for the nuke to have been armed in error.

IRL, secure locks are tied to the fire system. If a fire occurs, all locks release, letting people evacuate. Also, the error mention in the announcement is probably an inaccuracy - the detonation is timegated as an additional security measure from bad actors, not from a human error. Also, how are players supposed to know that doors unlock specifically after 2 minutes? I would just tie it to the Delta code for readability and simplicity.

As implemented, it is tied to the Delta code. Would you rather I made an announcement upon the commencement of delta alert to indicate when airlocks unlock, or simply unlock as soon as delta begins? I worry about triggering a delta event just for what is essentially AA for all on demand.

[slarticodefast]

I apologize for the delay on reviewing this, we are currently are quite backlogged with that.

Conceptually I like the idea. I had a look at the code and this will need a few changes:

• Currently you made this part of the airlock system, which is bad for several reason. Since the countdown is the same for all airlocks you don't have to update it for every airlock seperately, but only once for each station.
• I would suggest instead making this a part of AlertLevelSystem and AlertLevelComponent.
• Add DataFields to AlertLevelPrototype for whether or not an alert level should change door access and the timer settings (similar to selectForceEnableEmergencyLights). That way it could also be easily used for other alerts, not only delta.
• Use TimeSpans and compare to CurTime instead of accumulating frametime.
• remove SetDeltaEmergencyAccessOn and AttemptRemoveDeltaEmergencyAccess. Instead you can just check the current access status in the component and call ToggleEmergencyAccess from another system when needed. The airlock system itself should not be tied to alert levels in any way.

[slarticodefast]

Hey are you still intending to work on this? If yes, I can ask the other maintainers for conceptual approval before you have to address the review.

[Sparlight]

Yeah. I can work on this. I'm still new to the codebase and I've come to realize I'm probably biting off more than I can chew, but I'll bite. Before I tear this down and rebuild it again according to the review, though, I would like to see if this is functionality that the maintainer team desires. If not, it's not worth me continuing.

…

On Fri, Aug 30, 2024, 5:27 AM slarticodefast ***@***.***> wrote: Hey are you still intending to work on this? If yes, I can ask the other maintainers for conceptual approval before you have to address the review. — Reply to this email directly, view it on GitHub <#30143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVS6FUCAQEJ5XSZ6IUPXPTZUBJITAVCNFSM6AAAAABLB6X4KOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRQHEYTSNBQGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[slarticodefast]

Before
I tear this down and rebuild it again according to the review, though, I
would like to see if this is functionality that the maintainer team
desires. If not, it's not worth me continuing.

No problem, I'll open a maintainer discussion thread for it to get conceptual approval. Minimum discussion time according to policy is three days, but I'll get back to you once a decision is made.

[slarticodefast]

Hey, sorry for the wait, we are quite backlogged at the moment. I brought this up for maintainer discussion and it got conceptual approval. We consider this a good improvement for the nukeops gamemode as it gives the crew a fighting edge at the climax of the battle, making things more interesting. The reason it took so long for discussion was that we had to reconsider it with the addition of the AI which can open doors as well, but it should not be purely an AI task in our opinion. So when you address the code review, this should be good to merge. Let me know if you need help with any of that.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[slarticodefast]

Are you coming back to this?

[Pumkin69]

sparlightttttt come on sparlighttttt im gonna harass you in DMs if you dont work on this sparlightttttt