How to Fix Starmade

[God mode]

Hello schema. Here's an easy 3-step process to fix your game.

1. Stabilizers

Problem: Stabilizers encourage building a ship in a single direction, with reactors and stabilizers at extreme ends of the ship. The side bonus mechanic fails to fix these problems, and in fact worsens them due to an inherent and easily exploitable flaw.

Solution: Base the stabilizer efficiency on the distance to the nearest stabilizer group rather than on the distance to the reactor, with a required minimum of 2 stabilizer groups. To encourage multiple stabilizer groups, make each additional block added to a group contribute less stabilization.

This approach gives no benefit to expanding a ship in any particular direction and allows the reactor to be placed anywhere within the ship without loss in efficiency. The stabilizer group count vs group size interaction provides advanced players an opportunity to further engineer and optimize their power systems.​

2. Power Stream

Problem: The current power stream does not fit the game at all, is inherently ugly, and is a huge annoyance when constructing ships.

Solution: Convert to a block-based connection using conduits, with an invisible rectangular power stream slightly thicker than the conduit blocks to efficiently check for weapon impacts.

Players would first build a contiguous connection path using conduit blocks, at which point the invisible power stream would be created following the connection path. Until the conduit path is built and the stream created, the stabilizer group would have no contribution to reactor stability.​

3. System Integrity

Problems:

A. System integrity is completely ineffective in preventing most spaghetti systems.

For systems other than reactors, chambers, and stabilizers, small groups of blocks can be built in a line and chained together to form spaghetti systems. Applying system integrity to these systems does nothing to combat spaghetti ships.
Thrusters can be built on multiple docked entities and thrust inherited to completely bypass thruster integrity limits.​

B. System integrity encourages multiple small groups of blocks for most system types to prevent system explosions when damaged.

For systems other than reactors, chambers, and stabilizers, using the integrity buffer to create many small groups is ideal. With these systems, integrity only increases as blocks are destroyed. If the groups were merged, integrity would decrease as blocks are destroyed, eventually going negative and causing explosions.​

C. System integrity greatly restricts the possible shapes of systems in legitimate ships.

This applies mostly to smaller ships, but is a problem in principle. Players should be able to build systems however they want, and not be encouraged to build systems as perfect cubes.​

D. System integrity is a general nuisance when building normally.

There are currently 4 separate integrity values to keep track of, each in a different location, in addition to the integrity values for every single primary and secondary weapon group.​

E. System integrity makes decoration using system blocks difficult if not impossible.

This applies mostly to thrusters, as they can't be split up to make use of the integrity buffer without using docked entities, but other systems have this problem to a lesser degree.
​

Solution: Only apply system integrity to reactors and chambers.

Reactors and chambers are the only systems responsible for ship HP, so restricting system integrity to only those systems is entirely adequate to combat spaghetti ships. Applying integrity to other systems provides no benefit and only causes major problems.​

Implement these changes and the vast majority of issues with the power update will be solved.

 

[Valiant70]

1. Stabilizers
Problem: Stabilizers encourage building a ship in a single direction, with reactors and stabilizers at extreme ends of the ship. The side bonus mechanic fails to fix these problems, and in fact worsens them due to an inherent and easily exploitable flaw.

Solution: Base the stabilizer efficiency on the distance to the nearest stabilizer group rather than on the distance to the reactor, with a required minimum of 2 stabilizer groups. To encourage multiple stabilizer groups, make each additional block added to a group contribute less stabilization.

This approach gives no benefit to expanding a ship in any particular direction and allows the reactor to be placed anywhere within the ship without loss in efficiency. The stabilizer group count vs group size interaction provides advanced players an opportunity to further engineer and optimize their power systems.

This just got fixed, which is awesome.

2. Power Stream
Problem: The current power stream does not fit the game at all, is inherently ugly, and is a huge annoyance when constructing ships.

Solution: Convert to a block-based connection using conduits, with an invisible rectangular power stream slightly thicker than the conduit blocks to efficiently check for weapon impacts.

Players would first build a contiguous connection path using conduit blocks, at which point the invisible power stream would be created following the connection path. Until the conduit path is built and the stream created, the stabilizer group would have no contribution to reactor stability.

In a conversation with Lancake, I learned that the block-based conduits had performance issues. Something about checking what group they belong to when they get destroyed. I'm still hoping Schema can find a workaround that doesn't involve these obnoxious beams.

A. System integrity is completely ineffective in preventing most spaghetti systems.
For systems other than reactors, chambers, and stabilizers, small groups of blocks can be built in a line and chained together to form spaghetti systems. Applying system integrity to these systems does nothing to combat spaghetti ships.
Thrusters can be built on multiple docked entities and thrust inherited to completely bypass thruster integrity limits.

The exception, oddly enough, is thrusters. This makes them less exploitable, but at the same time horribly irritating to build normally with.

B. System integrity encourages multiple small groups of blocks for most system types to prevent system explosions when damaged.
For systems other than reactors, chambers, and stabilizers, using the integrity buffer to create many small groups is ideal. With these systems, integrity only increases as blocks are destroyed. If the groups were merged, integrity would decrease as blocks are destroyed, eventually going negative and causing explosions.

I hadn't actually thought about this, but you're right.

C. System integrity greatly restricts the possible shapes of systems in legitimate ships.
This applies mostly to smaller ships, but is a problem in principle. Players should be able to build systems however they want, and not be encouraged to build systems as perfect cubes.D. System integrity is a general nuisance when building normally.
There are currently 4 separate integrity values to keep track of, each in a different location, in addition to the integrity values for every single primary and secondary weapon group.E. System integrity makes decoration using system blocks difficult if not impossible.
This applies mostly to thrusters, as they can't be split up to make use of the integrity buffer without using docked entities, but other systems have this problem to a lesser degree.

Yep.

 

[God mode]

This just got fixed, which is awesome.

It's still a problem as indicated in the original post.
Proof
I've gone into more detail on this elsewhere, but it still very much exists.

In a conversation with Lancake, I learned that the block-based conduits had performance issues. Something about checking what group they belong to when they get destroyed. I'm still hoping Schema can find a workaround that doesn't involve these obnoxious beams.

My suggestion would avoid these performance issues. In terms of the current system, it would be like building a continuous linked line of stream nodes, but automatically and obviously more efficiently, with the stream being invisible.

The exception, oddly enough, is thrusters. This makes them less exploitable, but at the same time horribly irritating to build normally with.

It makes them less easily exploitable, but still exploitable. Encouraging multiple docked thrusters through a restrictive mechanic is probably a bad a idea.

 

[YamiHikari]

My suggestion would avoid these performance issues. In terms of the current system, it would be like building a continuous linked line of stream nodes, but automatically and obviously more efficiently, with the stream being invisible.

You're not the first one to come up with this idea. I've heard it from other people, too. But think about it. Which would you rather have: a redirectable stream (let's ignore the aesthetics because those can be fixed) or a good few thousand conduit blocks snaking throughout your ship? Performance issues would be the least of your problems because you'd have to go through the hassle of placing conduit after conduit after conduit each time you place a new stabilizer group. Then, when you have to move the stabilizer group you then have to remove and replace conduit after conduit after conduit. In a lot of builds, there is often something like 200, 300, 400, even 1000 blocks between each stabilizer and the reactor, and now that might even be with 2, 3, 4, maybe even 6 stabilizer groups. Think about how many conduits you would have to place one by one by one. With stabilizer streams, all you need to do is drop a cube of stabilizers and redirect the stream with a couple nodes if you have to. I'd personally prefer that, even if they do look like the contents of an alien barf bag.

You probably want to argue that we have conduits for chambers, so why not stabilizers, but the difference is that you don't need a ton of distance between reactors and chambers. I don't know about you, but I rarely use more than one conduit to connect the reactor to each chamber group. That's a lot less than 1000 conduits.

 

[NTIMESc]

2. Power Stream
Problem: The current power stream does not fit the game at all, is inherently ugly, and is a huge annoyance when constructing ships.

Solution: Convert to a block-based connection using conduits, with an invisible rectangular power stream slightly thicker than the conduit blocks to efficiently check for weapon impacts.

Players would first build a contiguous connection path using conduit blocks, at which point the invisible power stream would be created following the connection path. Until the conduit path is built and the stream created, the stabilizer group would have no contribution to reactor stability.

I would also prefer to not manually build conduits all through the ship.
Assuming the stabilizer stream is here to stay, I would just like the node blocks to be made indestructible and non-solid like the streams.
Having the stream suddenly change its path, cutting through the interior or popping out of the ship is not only ugly, but nonsensical. I am assuming that the stream actually represents a power conduit of some sort, and not just some free-flowing energy beam arcing through the ship. I would also like to see a few options for the texture of the stream.

 

[God mode]

Which would you rather have: a redirectable stream (let's ignore the aesthetics because those can be fixed) or a good few thousand conduit blocks snaking throughout your ship?

I would also prefer to not manually build conduits all through the ship.

I would rather have to put in some extra effort building than have a strange purple glowing tube through the middle of my ship, but this is a valid point. Using build tools makes building conduits much easier.

If it's really a problem, perhaps conduit lines could automatically be generated between node blocks (like the current line tool) which could then be modified, or the stream could be change graphically so that it resembles a line of conduit blocks. The important thing is that the ugly power stream has to go.

 

[YamiHikari]

I would rather have to put in some extra effort building than have a strange purple glowing tube through the middle of my ship, but this is a valid point. Using build tools makes building conduits much easier.

If it's really a problem, perhaps conduit lines could automatically be generated between node blocks (like the current line tool) which could then be modified, or the stream could be change graphically so that it resembles a line of conduit blocks. The important thing is that the ugly power stream has to go.

It doesn't necessarily need to go. It just needs to look good. From the private conversations I've had, the devs are very open to suggestions on how to improve the aesthetics of the streams. In fact, instead of demanding they be removed, why not just make a post about ways they could be improved aesthetically (just be sure you're still keeping it as a beam)?

 

[God mode]

It doesn't necessarily need to go. It just needs to look good. From the private conversations I've had, the devs are very open to suggestions on how to improve the aesthetics of the streams. In fact, instead of demanding they be removed, why not just make a post about ways they could be improved aesthetically (just be sure you're still keeping it as a beam)?

That's exactly what I did. I suggested keeping the beams for performance reasons, but making them invisible. They would still exist. Simply changing the texture is not enough.

 

[Lone_Puppy]

I don't mind the beam, but a conduit to protect it makes sense.
Using the build tool to auto generate the necessary blocks also make sense for build ease and speed.
The conduit could add to stability, either as a component of the stabilizers or something less like 1% of a stabilizer.

To reduce the checking lag, simply make them armor with a stabilizer bonus. Which is how I would see protecting a beam of importance like this.

If you liken the stabilizer mechanic to combustion engine fuel supply, the current beam is like having a stream of gasoline squirting over to the carburetor or jet assembly directly from the fuel tank.

 

[Space Shaman]

Why not base it on the old power system?
So the distance component of stabilizers would be based on the sum of the distance to the farthest stabilizer on each side.

This allows for borg cubs, death noodles, and everything in-between.
(On second thought, this might incentivize borg cubes, so in that case, count the farthest stabilizer distance twice.)

And about the power stream, the way it works mechanically definitely shouldn't change for visual's sake. However, the way the nodes work is a mess. Reactors automatically try to connect to any nodes. I propose:
The power stream should ignore all nodes by default. Reactors can be set up to use nodes. This is done by placing a node touching the reactor(there's no reason one node can't touch more than one reactor). Then you must link the nodes you wish to go between the reactor and the chosen stabilizer, which must also be touching a node.
In addition, the power stream routing should ignore changes made through damage. As it makes no sense for it to suddenly poke out the side.

 

[YamiHikari]

So the distance component of stabilizers would be based on the sum of the distance to the farthest stabilizer on each side.

Place one stabilizer 1000 blocks away. Now you have instant stability. That's why we can't have that.

Reactors automatically try to connect to any nodes. I propose:
The power stream should ignore all nodes by default. Reactors can be set up to use nodes. This is done by placing a node touching the reactor(there's no reason one node can't touch more than one reactor). Then you must link the nodes you wish to go between the reactor and the chosen stabilizer, which must also be touching a node.

The automatic node connection actually didn't happen originally. I don't know why it is all automatic now, but when the nodes were first added you had to link at least two together for the stream to redirect through it. While your method is a bit out there (I can't really back it), I think going back to a manual connection initiation would be a good idea, especially considering the aesthetic potential of the nodes.

In addition, the power stream routing should ignore changes made through damage. As it makes no sense for it to suddenly poke out the side.

+1 Like
Not so much "damage" as block destruction. I think adapting the planned docked entity fix to streams would be a good idea for the future. For now, though, let's just finish fixing all the bugs.