Mechanically prevent AME sabotage

[Titian3]

About the PR

Mechanically prevent the AME from exploding to assist in removing the rule on station sabotage.

• When the AME is put in to a state in which it would overload prior to 30min the injection status will display a safety alert and revert back to the safe level of operation for the amount of cores.
• Post 30min the AME will behave as normal and explode on overloads. Will also show an overload message on the injection status.
• Fixed initial status not showing not in 'Not Injecting'
• Colorized injection status so my smooth brain knows green good, red bad. Will help with new players mistakenly turning too high too.
• Added audio alarm to overloading state that is on the AME controller
• Added engineering radio alert to warn of the overload.

Why / Balance

From the chats and movement for less rules and more mechanical solutions: #20064

Technical details

When AME calculations are done for power/ overload, it will reset the injection level for next cycle and flag the UI update message to know to give overload or warning message if below defined sabotage timeout.

Media

Prevention:

AME-Overload-Prevention.mp4

Alerting:

AME-Overload-Alert.mp4

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

Breaking changes

No breaking changes.

Changelog
Add lockout for AME so can't be detonated prior to 30min, also has some new injection statuses.

🆑Repo

• tweak: AME now has safety features to prevent its overload prior to 30min.

[LankLTE]

The time should be a cvar rather than being hardcoded.

[lzk228]

maybe made alert sound quieter and send message about overloading in emgi channel like in admin

[Titian3]

The time should be a cvar rather than being hardcoded.

Thanks, I didn't know what they were called in here, added it in now.

[Titian3]

maybe made alert sound quieter and send message about overloading in emgi channel like in admin

Dropped the sound a bit and put some contextual messages based on how unstable it is.

Depending on how it is detonated it could show many messages if it was just over the safe injection or maybe just one or none if someone dumps 50-100 injection on to it.

[Myakot]

Won't it be much better if you removed all hardcode of "nuh-uh can't explode till 30 minutes for reasons" and just left AME with an in-built alarm for Engi channel?

Either for overloading and risk detonations or just in general:
[Engineering] AME controller says, "AME injection levels have been modified"

[deltanedas]

that wouldnt account for welding a part but leaving injection alone

[Ilya246]

that wouldnt account for welding a part but leaving injection alone

then make it always scream over radio once it detects injection as dangerous

[Titian3]

Won't it be much better if you removed all hardcode of "nuh-uh can't explode till 30 minutes for reasons" and just left AME with an in-built alarm for Engi channel?

Either for overloading and risk detonations or just in general: [Engineering] AME controller says, "AME injection levels have been modified"

The main issue is not that it needed more alerting but to try and mechanically prevent the overload in the first 30min, Either a troll/shitter/Newbie will overload the AME in the first 30min effectively ruining the round. There is already a rule here to try and prevent this and an admin notification but it still happens...often.

[Titian3]

that wouldnt account for welding a part but leaving injection alone

So i had a quick test on it and if you un-weld and knock a 3 core down to a 1 core and the injection stays the same. Results:

• The first safety one will reduce injection back to safe level 2x core injection rate, so no risk at all of overload.
• The post 30min overload time will trigger the overload/stability system but with how it works depending on the cores and injection it will have plenty of warning 2min+.

Here are some nerd graphs because I was interested. These didn't include random instability factors, but generally it will give a good idea.
I have different engi radio warnings at the warning lines:

TLDR: Fastest you can overload is 50seconds, roughly. There are 3 rates to get it to explode, slow, medium and fast. There is a random chance to have 1 extra instability removed per injection attempt.

[BolloTea]

How will this work on nuclear operatives, where detonating AME is common practice? Especially during a hidden game.
Don't you think 30 minutes is too much?

[BolloTea]

In addition, we have mentor roles - who must monitor and train newcomers, explaining how AME works and what happens when it is rebooted.

[Titian3]

How will this work on nuclear operatives, where detonating AME is common practice? Especially during a hidden game. Don't you think 30 minutes is too much?

Most likely outcome is the current Nukie gameplay is unchanged maybe with a slight delay for the ones that really want to destroy AME for some reason.
Anecdotally, most Nukie games I've seen never make it to the station prior to 30min.

• Stealth-ops, a later time might even have a better effect as people are more unaware.
• War-ops, up to 5min to decide 15min timeout, 5-10min get all the cats on to the shuttle and FTL to station. You're pretty much at 30min give or take a little.
• Normal-ops, generally i would say AME is low priority, Order of priory in this style for me would be: Armory, Grav, Cargo, Telecoms. Beside the actual objective nuke disk and nuke. Even when the AME goes the SMEs are going to keep it going for a while so low benefit to active targeting.
  A exception for Nukie would not work either as soon as someone sees AME blow prior to 30min everyone would scream nukie.
  Benefit of not having the round ruined often because some shitter blew the AME vs nukies having to wait 5-10min extra to blow the AME seems like a good trade off.

In addition, we have mentor roles - who must monitor and train newcomers, explaining how AME works and what happens when it is rebooted.

This sounds like a non-issue, why cant the Senior just tell them, this change doesn't prevent them from talking about it? Example: Senior Engineer: "This is the AME Controller, Set it to inject at 2x the amount of cores. If you set it higher it will overload and explode once it has warmed up."
Technical assistant: "How long does it take to warm up?"
Senior engineer: "30 minutes."

[daerSeebaer]

I'm against artificially limiting the amount to safe levels for the simple reason of retaining player agency.

A lightly overloaded AME (like 1-core 6-fuel) can be a conscious choice of the engineering department to boost power production with the drawback of higher fuel consumption and really having to pay attention to prevent explosions. Taking this choice from the available options will further degrade the possibilities of what one can do with an AME - and most discussions on the topic that I've heard are about how to make the AME MORE interesting, not even less interesting.

A compromise from my perspective would be a setting where the AME can't be overloaded beyond the "semi-stable" levels (max. of core-count + 5). At those levels, it will take a long time to degrade (16+ minutes, more likely 20+) which in turn already is more or less in line with the rules since the AME will likely not get overloaded at round start.

I would also scale down on the chat-warnings. One or two are a nice addition, but just putting everything that happens into a chat message would shift the focus from a world-based RPG to a text-based RPG. Engineering should have some clue on what is happening at their department without getting everything presented in the chat.

[Titian3]

I'll bring it back in to draft for now as it seems like there is still some decent discussion to be had.

I'm against artificially limiting the amount to safe levels for the simple reason of retaining player agency.
...how to make the AME MORE interesting, not even less interesting.

I'm also aligned to this and you made some good points.

A compromise from my perspective would be a setting where the AME can't be overloaded beyond the "semi-stable" levels (max. of core-count + 5). At those levels, it will take a long time to degrade (16+ minutes, more likely 20+) which in turn already is more or less in line with the rules since the AME will likely not get overloaded at round start.

I'll put the conditions here because this is what is going to determine it the alerts, overload and safety switch.

        // The AME is being overloaded.
        // Note about these maths: I would assume the general idea here is to make larger engines less safe to overload.
        // In other words, yes, those are supposed to be CoreCount, not safeFuelLimit.
        var instability = 0;
        var overloadVsSizeResult = fuel - CoreCount;

        // fuel > safeFuelLimit: Slow damage. Can safely run at this level for burst periods if the engine is small and someone is keeping an eye on it.
        if (_random.Prob(0.5f))
            instability = 1;
        // overloadVsSizeResult > 5:
        if (overloadVsSizeResult > 5)
            instability = 5;
        // overloadVsSizeResult > 10: This will explode in at most 5 injections.
        if (overloadVsSizeResult > 10)
            instability = 20;

With this are we talking about still having the safety switch go on in these situations, for reference instability is removed per injection from 100 for simplicity:

• 1 instability-16min(Fails every coinflip on every injection) to Never overload) = Alert to engi radio/ No audio warning/ No safety override.
• 5 instability(3min overload) = Alert to engi radio/ No audio warning/ Safety override before 30min.
• 20 instability(50s overload) = Alert to engi radio/ Audio warning/ Safety override before 30min.

The 16min and 3min overloads, im pretty sure an engi would see and be able to travel respond to the overload within the time frame. The 50s there is little chance to get there in time unless you were already in engineering and you immediately saw the warning.

I would also scale down on the chat-warnings. One or two are a nice addition, but just putting everything that happens into a chat message would shift the focus from a world-based RPG to a text-based RPG. Engineering should have some clue on what is happening at their department without getting everything presented in the chat.

Yeah I'd agree with you here too, the alerts are going out every injection. Probably reducing them down to one alert when it has passed the threshold would be better so with the current instability levels of 10,30,60,90 triggering alert levels it would only have one alert per passing threshold. So on the 3 trajectory's of overloads, 4 alerts per overload cycle:

• 16min overload - about every 4min
• 3min overload - about every 45sec
• 50s overload - about every 13sec

[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.

[Titian3]

I'm going to close this for now, It feels like its moved in another direction with just preventing by making the overload take longer rather than alerting engi.