feat(radio): add AN/PRC-117G comms system#1306
Conversation
Add the AN/PRC-117G manpack radio for RTO-qualified operators, including programmable nets, relay support, COMSEC fills, intercept behavior, and jamming-aware transmission modes. The AN/PRC-117G supports up to four labeled preset nets, faction-net selection, raw frequency tuning, and `:r` transmission on the active net. When worn by an eligible operator, it can relay loaded faction nets for nearby headset traffic without requiring a comms tower. Add radio operating modes with different security and jamming behavior: FH, SC, CT, and PT. Add monitor mode, scan mode, squelch control, callsign prefixes, and a local net log. Add physical COMSEC fill cards with a dedicated slot and zeroize support. Valid fill secures faction nets outside PT mode, while captured enemy fill cards allow operators to decode secured enemy traffic. Add tiered radio jamming. Standard radios are blocked when transmitting inside jam fields, while AN/PRC-117G traffic degrades based on operating mode. Receiver proximity to jammers now applies additional garbling, and degraded messages always corrupt at least one word. Add one tunable direct frequency to standard ship headsets. Direct headset traffic uses `:x`, operates peer-to-peer over short range, can be bridged by an AN/PRC-117G on the same frequency, and remains vulnerable to jamming. Add GOVFOR, OPFOR, and CLF radio variants with matching fill cards. Issue the new equipment to RTOs, squad sergeants, and commanders. Add guidebook documentation and relay exemptions for tower and telephone gating. # Conflicts: # Resources/Prototypes/_AU14/Roles/Jobs/Military/Base/commanderBase.yml
github-actions
Bot
added
Changes: UI
| - AU14TabletGovfor | ||
| - AU14TabletGovfor | ||
| - ANPRCFillCardGOVFOR | ||
| - ANPRCFillCardGOVFOR |
There was a problem hiding this comment.
The rank chevron is spawned and equipped into a free hand. Current implementation causes the Captain's chevron to be yoinked by anyone that spawns next to them.
Move this to pocket2 or the back storage (marines spawn with a satchel which isn't listed here)
| - type: ClothingSpeedModifier | ||
| walkModifier: 0.95 | ||
| sprintModifier: 0.95 | ||
|
|
There was a problem hiding this comment.
What's with all the newlines here in this prototype?
|
Media is gonna be required for this one when you get the chance. Otherwise this looks really cool, RTO can probably make a comeback as a dedicated role once more. |
TheHellFireo
left a comment
TheHellFireo
left a comment
There was a problem hiding this comment.
Other then stuff i found, i really don't know how this would be good for gameplay
This could have just been a fun little minigame for RTO, where they exist as a limited ranged radio tower ie
,
if the radio tower is down on the map, the RTO has to adjust signals and manage channels every few odd minutes to be able to have players in like a 15 tile radius be able to hear and transmit radio messages like normally
| if (radio.FrequencyOverrides.TryGetValue(radio.ActiveSlot, out var dynFreq)) | ||
| { | ||
| args.Channel = null; | ||
| _tunable.BroadcastOnFrequency(args.Source, dynFreq, outMessage); |
There was a problem hiding this comment.
This in not good. you are just making a new chat system which has none of the systems the current one has like admin logging, metadata, observer checks etc etc.
| return null; | ||
| } | ||
|
|
||
| private void SendToEntity(EntityUid sender, EntityUid receiver, string message, int frequency) |
|
|
||
| // :x intercept | ||
|
|
||
| private void OnSpoke(Entity<TunedFrequencyComponent> ent, ref EntitySpokeEvent args) |
There was a problem hiding this comment.
This only checks for the radio component and doesn't checkj if the headset is broken or disabled etc
| private void UpdateBuiState(Entity<ANPRCRadioComponent> ent) | ||
| { | ||
| _ui.SetUiState(ent.Owner, ANPRCRadioUI.Key, new ANPRCRadioState( | ||
| new Dictionary<int, ProtoId<RadioChannelPrototype>>(ent.Comp.Presets), |
There was a problem hiding this comment.
You rebuild the UI even when its not open
| var channelId = args.Channel.ID; | ||
|
|
||
| // Same map-local rule as OnSendAttempt. | ||
| if (!AnyAnchorCoversChannel(channelId, Transform(args.RadioReceiver).MapID)) |
There was a problem hiding this comment.
You already scan for anchors in line 127, this just doubles the work
|
Dropped a banger and then went completely dark |
4 participants
About the PR
This PR adds the AN/PRC-117G manpack radio for Radio Telephone Operators, a tunable direct-frequency layer for all headsets, and tiered radio jamming.
The goal is to make ground comms more interesting than a simple "tower works / tower does not work" check. RTOs now have a real field role: keeping squads connected, managing secure nets, handling intercepts, and reacting to jamming.
The AN/PRC-117G is worn on the back and can only be operated by RTO-qualified personnel. It supports up to four programmable preset nets, either selected from the faction net list or entered manually as raw frequencies. The active AN/PRC net is transmitted on with
:r.While worn and powered, the radio acts as a relay anchor. Friendly headset traffic on nets loaded into the AN/PRC works without a communications tower within 30 tiles at full signal, and out to 45 tiles with degraded signal.
The radio has four operating modes:
It also has monitor mode, scan mode, a
0–5squelch noise gate, an operator callsign, and a 50-entry net log.COMSEC is handled through physical fill cards. Faction fill cards are inserted into the radio and secure faction-net traffic in every mode except PT. Secured transmissions are pure static to any AN/PRC without the matching fill. The fill slot also accepts captured enemy cards, which is how hostile secured traffic can be decoded.
Tuning an enemy net's frequency shows their traffic as red intercept text. A ZEROIZE button ejects the inserted fill card.
All headsets also get one tunable direct frequency, from
30.000to87.999 MHz, transmitted with:x. Direct frequencies work peer-to-peer without towers, keys, or relays, and can be bridged over distance by an AN/PRC carrying the same frequency.Radio jammers now interact with these systems. Standard radios are still hard-blocked when transmitting from inside a jam field, but AN/PRC transmissions degrade instead with mode-dependent garble. FH is more resistant, PT is more vulnerable, and direct frequencies can be jammed too.
GOVFOR, OPFOR, and CLF all get their own AN/PRC variants and fill cards. RTOs, squad sergeants, and commanders receive the new equipment through faction loadouts
Two new guidebook pages cover the AN/PRC-117G and field headset systems.
Why / Balance
This gives the RTO role something important to actively manage during a round. Squads benefit from staying near their RTO, losing the RTO can hurt a whole element's communications, and capturing a radio or fill card can provide real intelligence value. (This could also be used as an intel objective)
The COMSEC loop (fill, intercept, zeroize, capture) gives faction RTOs something to play around without changing how regular soldiers use their normal headset encryption keys.
The scope is intentionally contained. The relay only ever carries the operator faction's own nets. Colony and third-party channels still route the way they did before: tower-dependent and unaffected by an RTO simply tuning to them.
Colonist and third-party gameplay should remain unchanged unless someone brings a jammer into play, which affects everyone equally.
Please test this yourself
Please do not just review the code and assume this is fine. This touches a lot of radio behavior, and I would really appreciate people testing it ingame with weird setups.
Good things to try:
If you can think of an edge case that is not listed here, please reply with it. I would rather have too many strange test cases than miss one obvious exploit.
Ingame testing performed
The following has already been tested ingame:
:rtransmits on the selected active AN/PRC net.30.000–87.999 MHzrange.:xtransmits on the headset's tuned direct frequency.Outstanding before merge
Merge warning
Warning
Do not merge this PR until it has been tested heavily
This touches radio routing, tower gating, jamming, faction encryption, item slots, headset behavior, and intercept logic. There are probably edge cases I have not thought of yet.
Edge cases reviewers should think about
Please reply to this PR with any abuse cases, edge cases, or strange interaction ideas you can think of, especially around:
ANPRCRangeSystemrelies onafter:constraints againstRMCTelephoneSystem/JammerSystem. If upstream ever renames those systems, this fails loudly at server startup rather than silently.(component, event)pair. If upstream ever subscribes<HeadsetComponent, MapInitEvent>itself, the server should fail loudly at startup with aDuplicate Subscriptionsexception instead of silently changing behavior.Technical details
ANPRCRangeSystemsubscribes toRadioSendAttemptEvent/RadioReceiveAttemptEventafterRMCTelephoneSystemandJammerSystem, then overrides their verdict for relay-covered traffic and AN/PRC:rtransmissions. Conditions that must stay cancelled, such as muted channels viaRMCRadioFilterand jammed non-ANPRC senders, are checked again before anything is un-cancelledANPRCGarbleSystemsubscribes toRadioReceiveEventonTunableHeadsetComponentbeforeHeadsetSystem. The by-ref event carries the garbled message into the normal relay-to-chat pathTunableFrequencySysteminjectsTunableHeadsetComponentand registers its BUI on every headset at map-init throughSharedUserInterfaceSystem.SetUi(), instead of editing the upstreamCMHeadsetprototypeEngine constraint: only one system may subscribe a given
(component, event)pair. Our_AU14systems therefore hookTunableHeadsetComponentfor receive-garbling and<HeadsetComponent, MapInitEvent>for component injection. If upstream ever subscribes<HeadsetComponent, MapInitEvent>itself, the server will probably fail at startup with aDuplicate Subscriptionsexception. The fix would be retargeting our subscription:ANPRCRadioSystem: presets, transmit, receive/intercept, and net logANPRCCryptoSystem: fill card item slotANPRCGarbleSystem: jam, range, COMSEC garble tiers, and squelchANPRCRangeSystem: per-map relay range gatingTunableFrequencySystem: direct-frequency routing and relay bridgingThe radio item carries its own
ActiveRadioComponent, like a headset, instead of granting channels to the wearer. This avoids collisions with accessory earpieces or radio implants that putIntrinsicRadioReceiverComponenton the playerAdded a new BUI and XAML window for the radio panel
Added a small frequency-tuning window for headsets
Added prototypes for:
:rand:xrouting.Added guidebook XML and guide entries.
Added FTL locale files.
Media
TODO, will update once I have more time.
Requirements
Changelog
🆑
:rtransmission.30.000to87.999 MHz, to all headsets. It transmits with:x, requires no tower or encryption key, and can be bridged by an AN/PRC.