Need to be able to split stabilization beam node paths

[Edymnion]

The beam paths for stabilizers don't fork correctly when trying to make separate paths to reactor groups.

Interior of a ship I'm routing beams through:


As you can see by the circled blocks, I have two stabilizer node paths going down the length of my ship, but only one is being used. If I try to start with a single point, I can only chain one other block as the next step in the path, I can't split it.

Here's that same ship from the outside:


Red circles are roughly where the relay nodes are located.
The green path is what I would want/expect the stabilizer beams to do.
The purple path is what the stabilizer beam is actually doing.

So yeah, would really like to either see the ability to split the beam the same way logic pipes on activators can be split, or greater control over designating multiple starting points. Currently once you've got relay nodes in there, you're stuck to a single path.

I even tried routing a single line from left to right, it still split the beam from the last point and jumped outside the ship.

Of course, I could move the center of mass of those stabilizers forwards some now so that the beam would fork more where I wanted, but if we're going to have these beams (and I do like them), we need to treat them more like logic pipes that can be split up.

 

[YamiHikari]

I could be wrong, but to my knowledge, stabilizers are only supposed to connect to a single reactor group, and therefore should not fork at all.

 

[Edymnion]

I could be wrong, but to my knowledge, stabilizers are only supposed to connect to a single reactor group, and therefore should not fork at all.

The demo image in the loader shows one reactor with two separate beams going to two stabilizer groups.


If you have no route nodes, this is what it does. One beam to each group. As soon as you put a stabilizer path down, it routes from the reactor through the path in a single line, and then forks when it gets to the last node.

Hence asking for a little more control over when and how the beam forks so that we can route it properly.
[doublepost=1514050095,1514048063][/doublepost]Better illustration of whats going on currently:

 

[YamiHikari]

I see. After testing it out for myself what you say is true, and I completely agree that this should be changed due to the fact that players don't want all of their stabilizer groups to be in a single area.

 

[Edymnion]

I see. After testing it out for myself what you say is true, and I completely agree that this should be changed due to the fact that players don't want all of their stabilizer groups to be in a single area.

Yup, the intent was to give us options, but with how the routing works now we only really get one option, a single block of stabilizers.

I'm guessing its just an oversight, since this is a pre-release on an alpha build.

 

[YamiHikari]

Are you sure it isn't just a bug?

 

[Edymnion]

Are you sure it isn't just a bug?

Well, yes and no.

I'm a professional programmer by trade, so when I hear/say "bug", it means something else than it likely does to you.

To me, a "bug" is simply when the output isn't what you expected. It can be either by accident (which is what most people think of when they hear the term bug), or it can be due to an intentional piece of code you did that doesn't play out like you expected (a logic bug).

I think the fork thing and the node thing were done separately and put together at the end. I think it was probably a case of they tested multiple beams, and they tested that the nodes worked, and put it out there without realizing that there was a third potential interaction between the two.

So its a bug in the form of "Oops, I don't think this is what was intended", but I don't think its a bug in the "Well we meant to make it work like this and it just isn't because we forgot to carry a 1".