Shielded cables : Add Shielded LV cables and Shielded APC that only powers objects on top of them #2025
Conversation
Shielded cables create a fourth type of cable network. Shielded lv cables will not connect to normal lv cables, and will furthermore require a shielded APC. Otherwise shielded cables work on anything with an extensioncablereceivercomponent on the same tile.
Make it so that if both an lv and shielded cable are underneath the receiver, the shielded cable is always selected as the provider. This also breaks the entity check loop early.
(TODO: Make APCShieldedFrame inherit from APCFrame instead of copying the parameters)
…apping action, rcd, cargo
spacedwarf14
changed the title
|
RSI Diff Bot; head commit 45d8c52 merging into 28c27e2 Resources/Textures/Objects/Tools/cable-coils.rsi
Resources/Textures/_NF/Structures/Power/Cables/sh_cable.rsi
|
|
Not really a fan of making changes like this to power systems, especially since I feel power is already needlessly over-complicated. On an ideal world, we would drop lv cables altogether and just have apc's have a larger power broadcast. The 3 existing cable types and power conversion is already too complicated of a system for our use case on frontier. The real solution to your specific use case you outlined would be to implement power switch verbs onto machines that don't have them to turn them off individually |
|
yeah that makes a lot of sense. Would a PR with those changes be considered? |
|
Before my opinion this PR has issue with yml that 100% could have been under _NF folders, and missing comments to mention Not a fan of this change tbh, this feels like it over complicated a system, why not just add a toggle on APC that turn the APC into this range mod? |
I actually started with this. I decided against the dynamic behavior since was not immediately intuitive which provider an entity would attach to once it is anchored. Receivers cannot have more than one provider so it would attach to neighboring networks if the APC's range is turned off. This means there's both the anchor state and the APC's range/nearfield state to keep track of when determining which network the entity attaches to. It was also cleaner to implement as a separate network, otherwise I would have had to introduce more event passing and complications to the code. More rules to tweak that maps might unintentionally rely on. |
|
Please see #2027! |
About the PR
(90% finished, so this is the bulk of the PR and I think ready for feedback. See TODO)
This PR introduces shielded LV cables and a shielded APC. Normal LV cables power objects up to 3 tiles away from the cable. shielded LV cables only power the objects on top of them. The Shielded APCs will not power any neighboring entities, either.
To make this work flexibly, I decided to introduce the Shielded LV cables as a separate network from the normal LV cables. This way, they don't connect to each other, and they can both be laid on the same tile. As a result, I made modification to the power monitor and some components (electrified, powerprovider) to accommodate using the new cable network.
Since LV and Shielded LV cables can be placed on the same tile, I added a rule to the provider selection mechanism to prioritize selecting the shielded cable if it is underneath, regardless of any other LV cables in the vicinity. This lets the player de-select objects from normal LV networks by placing the shielded lv cable underneath it. A separate circuit can then be made that only powers airlocks, for instance, without the airlock being affected by LV cables that are routed underneath them for other reasons. Turning off science should no longer affect your ability to move around!
This PR introduces the following specific changes:
I tried to make the code changes as minimal as necessary. I also avoided, to my knowledge so far, changing the default rules for provider and receiver selection; I did append one rule that I mentioned above that should only affect networks where shielded LV cables are explicitly laid down.
In order to treat the Shielded LV networks as a separate power network, it had to be mapped as its own "voltage" which in-turn has a matching nodeGroupID. This enables setting up a shielded APC prototype to provide power to a shielded cable and prevents the shielded cables from connecting to any other network. These are mostly field / enum additions and adding cases to handle the new cables (identically to LV cables, basically).
The ExtensionCableSystem is modified slightly so that receivers prioritize shielded cables placed underneath, regardless of the presence of normal LV cables.
The power monitor allocates another line array for selecting and drawing the shielded APC network, sizes and enums adjusted accordingly.
Cases to handle Shielded APC have been added to ElectrocutionSystem, and PowerSwitchable systems.
I still need to tweak a few things, TODO:
Why / Balance
There's are at least two distinct ways to look at an APC:
Extended range for power systems made sense in vanilla SS14, where gameplay takes place in large space. Corridors >= 3 tiles wide, big rooms that corresponded to their functions (science, engineering, bar, etc). This means that it was easy to have the function of the power systems that the APC affect map to the space in-which they occupied. That is, because rooms were separated enough from each-other, it wasn't really much of a thought about whether APCs were functionally oriented or spatially oriented -- the space was the function, allowed for the functions to coexist with the ranges that are expected by power receivers and providers.
FS14 typically takes place in smaller spaces, which means it is more difficult to make the APCs functional. There are tradeoffs between the ship layout and the functions an APC affects. In an example situation, that means that if you want to turn off science, you end up turning off airlocks and occasionally some thrusters. Almost every ship I've played on has an issue like this -- and if you /try/ to make the APCs functional, you end up with ridiculous wiring schemes and room extensions just to prevent entities from connecting to things 2 tiles away. I've spend many hours on a ship to try to make this possible.
FS14 also introduces fuel requirements on tighter supply cycles, so there's more of an incentive to shut down an unused part of the ship in order to reduce fuel consumption.
There was some brief discussion on discord about whether cable selectivity was a problem, but no discussion about whether this is an entity worth introducing. This shouldn't affect the gameplay if a player wants to stick to the default behavior. I started doing this to learn how my favorite game works, and to recover from some programming burnout. If this PR is merged, I will make a map that takes advantage of shielded cables.
How to test
Spawn a map; manufacture some shielded cable, place a shielded APC construction ghost, build; connect shielded cable to it, make network, place power consumer (power monitor).
When there are neighboring LV providers, a power receiver entity anchored on top of an existing Shielded LV cable will always select it as the provider. If a cable is placed under a receiver which already has a provider, the receiver will remain connected to that provider until it is re-anchored on top of the shielded LV cable. This is actually default behavior that you can observe with LV cables as well.
Media
Shielded LV Cable on tile (I will fix the gap soon)
etc:
description (TODO change color of "Shielded LV Cable")`
Requirements
Breaking changes
The changes are mostly additive, to support the shielded lv network, and should not change how existing cases are handled. The most significant change I would say is the addition to the TryFindAvailableProvider, which is optional but makes the shielded cables more useful.
Changelog
🆑