mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-01-28 10:01:58 +00:00
## 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. /🆑
Networks: Subsystems that are conceptually networked IN-GAME
Specifically, these subsystems are for in-game mechanics that are intended to rely on a digital/radio/physical network, such as telecomms servers or the powernet
The intent of this folder categorization is to be able to quickly reference what are intended to be in-game networks, vs what is logically networked inside the code.
Knowing what is meant to be conceptually working off of an in-game network serves as guidance for adding or modifying features or fixing oversights and/or bugs.
For instance, the radio jammer only affecting headsets and suit sensors could benefit from a shorthand awareness of other systems that are represented as a network, such as research. Using the radio jammer near a server or fabricator could cause it to sever its link to the supply silo or the research web. This example is presented only as such, and not a recommendation on any new features or balance changes.