Method for debugging the laying of utility lines

Kriomant shared this feedback 20 days ago
Not Enough Votes

I've read many proposals for laying communications. Electricity, fuel, and oxygen aren't magically transmitted through blocks, and a conveyor belt is too versatile. We'll handle the installation of wires and pipes on a small grid. However, opponents of this approach say it will be too complicated and will likely discourage newcomers, and ship construction will become tedious.

I fundamentally disagree with this. I believe communications are necessary, even vital, for this game. They solve the problem of ship survivability in space battles, and they force more thoughtful engineering planning of construction.

But it's possible to reduce routine operations. I propose that wires and pipes be automatically routed from functional blocks to the nearest distribution block, along the nearest surface. First, in project mode, so that placement can be adjusted, and then, to complete the line, you need to build one switch block, rather than the entire line. The communication line will be a physical object, but repairs or construction will require interaction only with the outermost connection blocks. This should simplify operation without simplifying the mechanics themselves.

Replies (2)

photo
1

I hope this topic will be discussed.

photo
1

Conveyor components can serve as “transport elements” for power distribution and data distribution systems.


Functional blocks with high energy consumption or high energy output (reactors, batteries) should always be connected to the conveyor system.

At the same time, however, I believe that “small appliances”—such as interior lights and the like—should draw power directly from the block on which they are located, without the need to connect to additional distribution systems.

“Data elements” should function similarly—control consoles with chairs, program blocks, and similar “large” elements should be connected to the conveyor, while small elements, such as buttons, small wall panels, cameras, and detectors, should suffice with a connection to the structural block.

Weapon systems should function similarly—internal defense turrets should be capable of operating autonomously, so they only need power and data connections “via the structural block.” Larger weapons should be connected to the conveyor.


Unfortunately, the current condition and design of the functional components—particularly their connection points to the conveyor—are such that this solution is not only impossible but is directly ruled out.


I don't think creating separate models for electrical and data distribution systems will be beneficial. One of the problems is the number of structural elements that can be attached to a single wall of a structural component, such as an armor block.

Another source of problems with electrical and data distribution systems is issues related to the splitting and reconnection of grids.

photo
1

I understand, but it doesn't solve the problem. I love space battles, but the current crafting system makes ships incredibly durable. In the first game, you had to gnaw through structures like beavers because even 15% of the craft remained combat-ready. More complex communications and the creation of structures (turret-sensor network-targeting computer) for fire control would solve this problem.

At least, divide the conveyors into several types, removing their versatility, and add a distinction between units that transfer energy and those that don't.

photo
1

It would be nice if there were several types of conveyors, pipes, and “cables.” However, the game's current state does not allow for this. The “design” of blocks and conveyors, as well as the rules for connecting blocks and attaching additional devices to them, do not allow for this.

Try building a ship where the “normal” conveyor system connecting storage facilities and production equipment is isolated from the hydrogen conveyor system between the generators, tanks, and engines.

Three-point challenge: Make sure the conveyor systems are also separated at the hydrogen and oxygen generators.


As for controlling the turrets—connecting the autonomous control units and autonomous power sources directly to the turret is the least of the engineering challenges. Yes, this will cause some problems for engineers who use turrets from the in-game selection, but it won’t cause any problems for builders who construct turrets from components.

So the idea that an interruption in data communication between the central computer and the turrets could significantly weaken the ships’ combat effectiveness is mistaken.

Yes, it could have some effect if multiplayer battles involved fleet engagements where groups of several ships with “different values” were fighting each other. But that doesn’t happen and won’t happen—it’s always one ship against one ship, so the default setting for autonomous control—“fire at all enemy ships within effective range”—possibly with a priority for which systems to destroy first—is fully sufficient to ensure the autonomous control system operates effectively.


Translated with DeepL.com (free version)

photo
1

At a minimum, this should reduce firing range due to the loss of targeting and sensors. A turret might not have an effective range without a radar.


I agree that the current block architecture is poorly suited for line-of-sight separation, but we have a small 1/5 grid, and the game is still in Early Access.


Maybe I'm expecting too much, but I love this game too much and want it to develop.

photo
1

It appears that a centralized fire control system with specialized fire control radars, rangefinders, and other equipment does not yet exist at all.

I am not aware of one, or at least I have not seen such a solution yet.

So, as things stand, there should be no difference between centralized and autonomous fire control.


Furthermore, the fire control system should not affect the weapon’s performance (maximum range, etc.), but only its aiming accuracy.


I don’t think the game’s development will bring about significant changes to the ship and base construction systems or to the game mechanics. Simply because a significant change would likely render existing solutions and designs unusable, thereby causing considerable dissatisfaction and a negative reaction from players. Unfortunately...

So KSH will continue to try to patch new content onto flawed and ill-conceived initial solutions.


Translated with DeepL.com (free version)

photo
Leave a Comment
 
Attach a file