Suggestions Thread for v2.0

[kilo]

[...]

 --- Regarding beam ships:

 --- It struck me that a form of "Capacitor Bank" might be a helpful thing for diversify beam ship designs. Basically, this component would derive it's efficiency from the Capacitor tech. It would then incur a power requirement, like a beam weapon would, and would charge like a beam weapon too. The capacitor would discharge as part of the beam weapon firing phase, just like a beam weapon would, however, it would distribute it's available energy evenly across all beam weapons that are firing. This would work more or less identically to how power plants distribute their power, following the same priorities. The caveat is that these aren't power plants, but capacitors, and so count as extra capacitors for the purposes of weapon RoF.

 --- So for example, a weapon has 25 capacitors, and a RoF of 10s. A single capacitor bank of 25 would give it a 5s RoF instead. Another example, Three weapons with 10 capacitor and a 20s RoF with a single 15 capacitor bank would instead have a 15s RoF each. I'll do an effort post later, in it's own thread. Questions or thoughts are welcome in the meanwhile.

I do not understand it completely. Are we talking of some sort of ready rack for munitions/energy, that allows for a limited rate of fire increase to levels otherwise unobtainable by current technology levels?

[xenoscepter]

[...]

 --- Regarding beam ships:

 --- It struck me that a form of "Capacitor Bank" might be a helpful thing for diversify beam ship designs. Basically, this component would derive it's efficiency from the Capacitor tech. It would then incur a power requirement, like a beam weapon would, and would charge like a beam weapon too. The capacitor would discharge as part of the beam weapon firing phase, just like a beam weapon would, however, it would distribute it's available energy evenly across all beam weapons that are firing. This would work more or less identically to how power plants distribute their power, following the same priorities. The caveat is that these aren't power plants, but capacitors, and so count as extra capacitors for the purposes of weapon RoF.

 --- So for example, a weapon has 25 capacitors, and a RoF of 10s. A single capacitor bank of 25 would give it a 5s RoF instead. Another example, Three weapons with 10 capacitor and a 20s RoF with a single 15 capacitor bank would instead have a 15s RoF each. I'll do an effort post later, in it's own thread. Questions or thoughts are welcome in the meanwhile.

I do not understand it completely. Are we talking of some sort of ready rack for munitions/energy, that allows for a limited rate of fire increase to levels otherwise unobtainable by current technology levels?

Kind of. I did a far more full write up of both of these suggestions here: http://aurora2.pentarch.org/index.php?topic=13233.0

[superstrijder15]

Allow STO ground units to use components, decreasing their build cost if you have the right weapon systems already available

[Velociranga]

I imagine it might be finnicky but I would love the option to refit a ground formation to an updated version like we can do with ships.  The ability to drag and drop formation elements is good but I think it would make updating large amount of ground formations way easier.

Especially if you make a change to your formation sizes.

[Panopticon]

Something that would help a bit form a micro perspective might be combining multiple sensors and/or fire controls into one installation. So when creating a ship rather than adding in an EM, Thermal, and one or more active sensors, you can can have the choice to just create a single installation with them in it and add one of those, perhaps it could save a little space and weight, perhaps not.

I feel like, especially if you are building a navy(or multiple navies) from scratch this would help prevent forgetting sensors, and minimize the clicks you need to create ships.

[dpickle]

In the Mining tab there is currently no clue or helpful warning if you set a bunch of orbital mining modules to an asteroid too big to mine orbitally.  This can be obvious if you only have OMs there, but if you also have Automines, it may not be super obvious that your OMs aren't contributing, since they are shown as being present and are added to the total automines listed in brackets in the left pane and shown in the bottom pane where it shows the calcs for how much they will produce.  Maybe either don't count them as being added in the left pane, or add a column titled "OM eligible" in the bottom pane with a 0 multiplier the asteroid is too big or you're at a moon/planet that's ineligible.

[GrandNord]

Would a rework of the armor and damage localisation systems be in the cards in the future? or even possible/desirable? Right now it's serviceable but having components localised relative to the armor scheme and each other and the ability to put different amounts of armor layers on different parts of the ships might be interresting?

It would allow for more armor optimisation and interresting designs, maybe spaced armor to defeat certain types of damage like missiles (for one shot at least), all or nothing schemes, components blowing up damaging the components and armor around them and not at random, so proper placement of dangerous components would be advantageaous. Maybe internal armoring and compartimentalization would be possible?

Maybe also with a structural integrity system? For example it wouldn't matter if the front and back components and armor are fine, if everything in the middle has been reduced to scrap them you've got two halves of a ship. This might be a way to buff big missiles, if only one shot landing can be a killing blow if it destroys everything in a chunk of the ship and cuts it in half.
Might be a way to simulate fires too, or other hazards around the ship that could reduce efficiency in certain components.

It could also be an opportunity to separate the overall ship's armor with the weapon's and other system's armor, with some systems that could be internal, external and armored or external and unarmored. Sensors, for example, should not be something that could be put below a few meters of Duranium and still be expected to work fine after all. Hangars also should be weaknesses in the armor, that should be at the surface of the ship and where you shouldn't be able to put any armor layers (though maybe their HTK could be raised to account for an armored blast door for example?).

Sorry if this is a bit disjointed, just throwing some ideas I just had. I don't know if any of this is even possible to do or if it would make for interresting gameplay or just boring minutia.

[GodEmperor]

One small thing - i would love for the old "transport bay isnt drop pod bay" distinction to return...

I miss making dedicated drop ships for Marine/Assault forces and big transports that just serve purely as transports.

[nuclearslurpee]

One small thing - i would love for the old "transport bay isnt drop pod bay" distinction to return...

I miss making dedicated drop ships for Marine/Assault forces and big transports that just serve purely as transports.

Not sure what you mean? We have distinctive troop transport bays for normal, drop, and boarding types. Normal bays can still unload the troops on a planet, it just takes many hours to do whereas drop bays are instant and thus usable against a position defended by STOs.

[Golem666]

Could we get "Stealth" modules that would increase the tonnage instead of decrease? I don't know how much the current decided based in this, but it could be useful for PvP or MP games.

[Oafsalot]

Yes, the bays have sort of all blurred into one situation going on.  The only advantage to drop bays is instant drop, which is only really necessary when a planet is defended.  Which usually isn't the case, because you won't invade until you have control of space.

As there is a delay to combat, it doesn't matter that it takes hours to ship troops down by shuttle.  Perhaps it should be that transport to the surface by shuttle causes a Ground Combat Event where they can attack for free, either while in the shuttle, against the shuttle causing a complete loss, or while rallying at the drop point, or all three.  That way drop bays would be useful more than in a rare situation.  You'd be required to use them or take heavy losses.

At the same time, I think the mass of the drop pods ought to be much greater and drop bays need to be one shot and the component is replaced by a used one which can be refitted at a Shipyard.  Maybe even bring back the VB6 situation where drop bays were moral problems.  This brings back the need for staging somewhere and keeps all the bays useful in narrower situations.

[nuclearslurpee]

Yes, the bays have sort of all blurred into one situation going on.  The only advantage to drop bays is instant drop, which is only really necessary when a planet is defended.  Which usually isn't the case, because you won't invade until you have control of space.

This is not universally the case. If a planet has a large concentration of STOs it may not be desirable or feasible to bombard the planet first to eliminate the STOs before landing troops (this might be due to not outranging the STOs and being unable to win in a shootout, or just not wanting to incur collateral damage effects). In this case, heavily-armored dropships are the main way to land troops against STO fire and pull back before getting completely wrecked.

The drop bays are really intended to be quite specialized modules, not only are they 20% larger than the normal ones for the same capacity but are 2.5x more expensive, so I think it should be clear that the normal transport bays should be preferred for general use and the drop bays used in the face of withering STO fire and other similar situations.

I would not want to see the VB6 style drop pods make a comeback, at least not as a required mechanic... ground combat in C# is so much bigger in scope, with homeworld invasions requiring multiple million tons of troops, so I would not want to deal with the micro headache of loading millions of tons of troops into hundreds or thousands of drop pods, one by one... 

[StarshipCactus]

I agree with Nuclearslurpee, I was not a fan of the gameplay for troop transports in VB6. I much prefer the current system.

[kilo]

Another point that is very important when it comes to bombardment vs invasion is the terrain. It is incredibly costly to bomb a planet with mountain or rift valley + forest or jungle. You may end up with hit chances around 1% against the STO installations, especially when they are firmly dug in. When the enemy has fortified such a planet consider landing or bring a lot of maintenance parts. You will need them.

[Whitecold]

It would be interesting to have a game option to completely disable Jump Point Stabilization, to really force the usage of jump stations, tenders and jump freighters.

I guess the option itself is trivial to implement, what would be more tricky is getting civilians and NPRs to work properly with the lack of stable jump points:

• It would be easiest for connectivity to assume every jump tender remains stationary if they are at a jump point. Since jumps can be individually forbidden, ships can still be kept on the desired lanes. Moving a jump tender will disrupt movements, but that feels more like something for the player to take care of rather than a bug, if you remove the last jump tender on your largest trade route, well, what did you expect to happen?
• For ship construction the existing jump drive designs should already give an indication of what kind of ship sizes might make sense, what tenders may be available. From this it should be possible to infer the possible accessible populations for different ship sizes, with and without their own jump drive, and then choose an appropriate size

The nice thing about these features is that they would also help anyone not playing with stable jump points disabled.