## About The Pull Request
Oh man, so this entire pr started because of two things:
1. A kinda hacky fix to #92123 that got closed a good while ago.
2. A borg I know mentioning you can't do custom say verbs over robotic
talk.
Which subsequently led me down this rabbit hole of say modes and custom
say verbs.
So! The most wide-reaching thing this does is merge the custom say
verb/radio emote logic that used to be specialcased in
`compose_message(...)` into `say_quote(...)`, renaming this to
`generate_messagepart(...)` with its new functionality. This means
things that don't use the exact same chain as living things talking
normally can still generate custom say verbs if given that message
modifier.
Then, we split up say modes into a "can we do this" and "try to do this"
check to reduce conflicts (like #92123), and forward more of our data to
the latter. This allows us to then edit the say modes to actually make
use of that data, and with the previous addition of
`generate_messagepart(...)` allow for custom say verbs to be used.
In doing this I realized the logging was kind of awkward and all over
the place, so we create the new logging helper `log_sayverb_talk(...)`
which handles selecting how we should log things based on the given
message modifiers.
For better or worse I forgot about this pr for a few weeks, so I don't
perfectly remember all the details, but those are the big key parts.
## Why It's Good For The Game
Fixes#92123.
I think custom say verbs are some of the best flavour we have for
talking over radio, and any situation benefits from that being possible.
It's great to be able to tap your microphone, and it's hilarious for an
AI to be able to emote beaming an image directly into the heads of their
borgs over robotic talk.
The rest is mostly cleanup.
## About The Pull Request
While working on another PR, I noticed that there wasn't any real
distinction between subsystems that function as a network for various
logical components/systems in the code, and subsystems that are meant to
represent what is actually an in-game network. As such, I moved what
seemed to be clear representations of the functions of in-game networks
under their own subfolder.
This should have no effects otherwise.
## Why It's Good For The Game
Per an .md I added in the folder, it helps to clearly demarcate what are
backend programmatic networked systems, and what are meant to actually
be a network in the game itself; the radio jammer disrupts your suit
sensors and headset, not your signal relationships with DCS, and I
believe having that distinction be clear at a glance of the file
structure is valuable.
## Changelog
🆑 Bisar
code: Subsystems that are meant to represent a network in-game have been
moved into their own category inside the codebase.
/🆑
