Skip to content

Conversation

MidZik
Copy link
Contributor

@MidZik MidZik commented Oct 20, 2025

About the PR

Currently, a containment field will die if either side loses power. This PR changes this behavior to keep a containment field alive as long as at least one side has enough power.

Why / Balance

This is unexpected behavior, because if you only power one side, the field will be created and be perfectly happy. You can safely create a tesla or singularity containment field with only two emitters, one for each corner. As long as those corners stay powered the containment field will last the whole shift.

However, if you try to power all four of the corners and then remove the emitter for just one of the corners, the field for that corner will die. Indeed, you can actually loose by adding an emitter to an unpowered corner, and then removing that added emitter. Two powered corners is safe. Going from three to two will loose.

This behavior has caused an unintentional loose at least in round 94809 (Lizard), which is what caused me to look into this. It's not unlikely that at least a few other looses occurred due to this behavior, since an engi might reasonably assume that some emitters are safe to turn off due to the two-emitter setups that exist.

Technical details

RemoveConnections now accepts an optional predicate that determines if a connection should be removed or not.
LosePower now passes in a predicate to RemoveConnections in order to only remove connections if both sides don't have power.

Media

Old behavior:

ContainmentFieldBroken.mp4

New behavior:

ContainmentFieldFixed.mp4

Requirements

Breaking changes

Changelog
🆑

  • fix: Fixed containment fields dying even when one side still had power.

Currently, if either side of a containment field loses power,
the field dies, even if the other side is still powered. This commit
changes the behavior to only destroy the field if neither side
of the field has enough power.
@PJBot PJBot added S: Untriaged Status: Indicates an item has not been triaged and doesn't have appropriate labels. S: Needs Review Status: Requires additional reviews before being fully accepted. Not to be replaced by S: Approved. size/S Denotes a PR that changes 10-99 lines. labels Oct 20, 2025
@iaada iaada requested a review from a team October 20, 2025 19:51
@iaada iaada added T: Bugfix Type: Bugs and/or bugfixes P3: Standard Priority: Default priority for repository items. A: Engineering Area: Engineering department, including Atmospherics. and removed S: Untriaged Status: Indicates an item has not been triaged and doesn't have appropriate labels. labels Oct 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A: Engineering Area: Engineering department, including Atmospherics. P3: Standard Priority: Default priority for repository items. S: Needs Review Status: Requires additional reviews before being fully accepted. Not to be replaced by S: Approved. size/S Denotes a PR that changes 10-99 lines. T: Bugfix Type: Bugs and/or bugfixes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants