A way to make multi-reactor setups possible

[Skwidz]

Ships with one reactor can be destroyed quickly if the enemy knows where to attack. A reactor failsafe chamber can fix this by switching to another reactor but it's still a single reactor and a single location to attack which could also have been destroyed earlier while the enemy was trying to get to the main reactor. Multiple reactors are common in many sci-fi ships and all of the reactors are on at once (except for backup reactors). Having multiple reactors online in one ship can yield plenty of power and help prevent giant bulges and allow even more ship designs but that can also allow for jack ships as each reactor has its own reactor capacity. A parent/child reactor system can solve that and add more ways of building a reactor. The parent reactor would have a "cluster reactor chamber" connected and set to "cluster reactor parent" under the reactor chamber configuration menu. Level one could support up to two child reactors and higher levels could support even more. The highest level of the "cluster chamber" would consume all of the parent reactor's rc to help prevent jack ships. Each child reactor would have to have a "cluster chamber" attached and configured to "cluster reactor child". To prevent jack ships there can be only one of each special per ship (ie one child reactor has the stealth drive addon but the others can't have it too) and each level up to the parent chamber consumes a bit of rc for each child reactor as well.

Any extra reactor without the link to the parent reactor is a backup reactor and can be switched to with the current reactor failsafe chamber function. I was considering backup cluster reactors but those don't seem like a good idea because such a design in a ship can allow all of the reactor chambers to be added, not that that would matter much due to reactor boot delays.

Stabilization for a cluster reactor could work like this: a stabilization beam from the child reactor furthest out from the main reactor in the group can be rerouted to the next nearest reactor which repeats the chain until all the child reactors are connected to the main reactor which sends its stab beams off to the stabilizers.

Idea improvements for this if agreed on will be added to this post.

 

[M.Waites]

Hm, a suggestion could be to have a main reactor, so that's where the chambers have to be connected to and it determines the chamber size to to it's size and different sub reactors who could be linked to systems directly.

So you'd have an overall reactor for the ship functions (like oxygen if that becomes a feature, lights, doors, flight controls (the directions not the thrust per se) and the overall functions, like to be able to command the ship via the flight mode. and hence having access to all primary weapons etc.

So for the main reactor to be x% destroyed you'd lose x% of direct command there, like a worse reload, slower controls (basically worse turns rates etc)

But if the ship has the reactors linked to a certain system, let's say a weapon system somebody who'd sit directly at the weapons comp would still have 100% functionality if that sub reactor is still at 100%.

That way one could have a multi crew ship with an actual reason to have several crew members.

The other reactors would make sense to have a the individual parts powered, if they'd add a shield control computer too, that would be able to have shield system up, like one could change the recharge rate vs capacity rates so it wouldn't be too boring to sit at one of those.

Heck they could do the same for every major station/function of the ship too and really have a multiplayer ship there, which could be flown alone still but there'd be less backup if things get taken out.

So there could be an actual flight control station which would overrule the flight mode controls and basically turn that into mode more into an overview mode (only if the flight control is manned, otherwise it works just as it does right now) so a captain would be like a tank commander by selecting targets and destinations I guess, much like a Star Trek Captain would do I guess.

Could even work for some unique ship design if there's no central bridge but several sections with control abilities.

Might mak the whole thing too complex though but I assume it wouldn't be a too big technical challenge to implement them after all weapon computers are already working that way right?

And the reactors might work like docked entities which either get energy from their own reactors or the main ship. So in this case either the linked reactor or the main one.

If one could have certain order shortcuts that couldwork with AI too, like for weapon computers the target selection, for shields maybe a + cap - recharge and - cap + recharge command. Flight control might be a bit harder though but I guess it could be sufficient if there's an AI crewmate at the position it would work normally but still having a flight mode like normal?

So the only difference in regards to AI manned ships vs ships right now would be the need to have AI crew there. And for multiplayer ships it would open up a whole new array of options, and one can alternate between both too.


Like if a captain would still want to fly the ship themselves instead of commanding others, he could have an AI sit on the flight control while other players take care of shields, weapons etc. It would all be up to individual choices.





Hm the idea up there wont be bad either, to be able to link up different reactors without the need to physically touch. I guess the sytem integrity could work like they do for thrusters as in each group counts towards the total? And one could have to link them via the stream connector thingies. So it would indeed be a chain of streams which make a whole reactor, so it could be split up physically.

Which in turns could allow for a whole new approach on reactor designs and allow for a wide variety of shapes overall and enable one to be less boxy in certain parts of the ship. Pretty sure people from prior power 2.0 and their ship designs would appreciate those ideas.

Also it would make the reactor less of a big fat target and more a cluster of several, depending on personal choices. And the chamber size could in turn depend on total reactor size which are linked just like they do already.

And stabilization would still depend on reactor distance and possibly total size of it for balancing reasons? Or individual sizes of the smaller clusters? Hm, I guess one way to offset an overdo of individual clusters would be if a cluster would increase the need for stabilization, like the weapons get an increase in energy requirement for individual groups.

So the more reactor clusters you have the more overall stabilization you'd need. So everything has their pro's and con's attached to it.

Like many clusters and hence more safety to total reactor health but one needs more stabilization for it, vs less clusters and hence lower chance to be fully functional still after a decent hit but one lees less volume and mass for stabilization, or something in between.

Hm, I like choices so would definitely be in favor of such a system :3

 

[MacThule]

Meanwhile, some people are saying that it's already waaay too hard to destroy reactors and are demanding a return of SHP so they can kill ships more easily. Are we sure reactors need help?

 

[Nosajimiki]

Meanwhile, some people are saying that it's already waaay too hard to destroy reactors and are demanding a return of SHP so they can kill ships more easily. Are we sure reactors need help?

This is true. You can drill right through a reactor destroying 90% of it and still keep going off of the rHP in your remaining chambers which may be distributed for the kind of redundancy you are talking about (at least vs overheat.) Also, distributive reactors are exploitable by making a bunch of small spaced out reactors that are too small to effectively target allowing a spaghetti-like meta to come back into play. While less realistic, a single reactor model is less exploitable

 

[Skwidz]

Also, distributive reactors are exploitable by making a bunch of small spaced out reactors that are too small to effectively target allowing a spaghetti-like meta to come back into play.

Hmm reactors like that could be an issue. It looks like I forgot to mention reactor count limitations besides leveling up the parent chamber which would only half solve the issue. I'm not sure what else to do for that, any ideas?

As for making it less difficult to destroy a reactor maybe the reactor has to be at least 25% intact for it to be functional. The planned repair mechanics keep the last ship configuration before damage occurs. That could be used to determine reactor completeness and a reboot can update that (and maybe the full ship design? It may be based off of blueprints actually iirc) so when a reactor is reduced to small parts (or a chunk) which is less than 25% of the total reactor size, the reactor shuts down and the others take over (or the ship overheats).

I also forgot to mention how a cluster reactor could be destroyed. Once the main reactor is taken out, the child reactors are left useless unless one of them is equipped with a parent chamber, then that one would take over. If the parent reactor had a failsafe chamber, then maybe it would switch to the backup power supply instead. This could be used to create a reactor which switches to each child reactor in a chain until no more of the cluster reactor can function, then the backup system would take over.

 

[JNC]

I like the idea of allowing multiple active reactors. The current system is too limiting... the fewer mandatory requirements the better.

Perhaps allow slaved reactors to use host stabilization OR their own, this way parent reactor status doesnt affect the clusters so much.

 

[Skwidz]

After some thinking I couldn't come up with a solution for destroying reactors easily besides that completeness idea and building a reactor similar to how weapons are built. A reactor could be made up of a reactor core which has reactor blocks linked to it. The rotation of the core won't matter and counting the core towards the reactor's total integrity could allow the core to sit anywhere in the reactor.

Another version of this counts the core/reactor block integrity total as well, but any reactor blocks within range (3 blocks?) of the core or the reactor structure (core with reactor block(s) in range) will be part of that reactor and count towards the integrity. Any reactor cores within the range of the reactor won't function. This can make reactors less annoying to destroy but easier too, so that's where a cluster reactor comes in.

(misc. thingy: stab beams originate from the core so that could speed up stab beam placement processing and reduce bugs kind of. The core would take the place of some of the stab beam end placement but integrity and range would need to be calculated which already happens with stab and shield groups)

 

[MacThule]

It really does make very little sense to allow a machine to produce power when half demolished...

 

[NaStral]

It really does make very little sense to allow a machine to produce power when half demolished...

Even if overheat were kept at 25%, there should be complete systems failure at below 50% along with a “disabled” marker.