C# Suggestions

[Droll]

Right now when terraforming bodies and removing gasses, when that gas is completely removed the game automatically sets the active gas to "none" to prevent issues. This is the desired outcome for every gas, except one:

Water vapor.

The problem I have happens with a lot of terraformers and/or small bodies where the terraform speed is too damn high. What this means that in every 5 day increment, all the water vapour gets sucked out of the atmosphere, which sets the active gas to "none", but I still want to drain the swamp which means that advancing the game becomes quite excruciating given how long draining a swamp usually takes.

My suggestion is to make water vapor an exception to the auto-stop terraforming rule so that terraformers can automatically remove the new vapor that is forming after the previous got sucked out.

[nuclearslurpee]

Right now when terraforming bodies and removing gasses, when that gas is completely removed the game automatically sets the active gas to "none" to prevent issues. This is the desired outcome for every gas, except one:

Water vapor.

The problem I have happens with a lot of terraformers and/or small bodies where the terraform speed is too damn high. What this means that in every 5 day increment, all the water vapour gets sucked out of the atmosphere, which sets the active gas to "none", but I still want to drain the swamp which means that advancing the game becomes quite excruciating given how long draining a swamp usually takes.

My suggestion is to make water vapor an exception to the auto-stop terraforming rule so that terraformers can automatically remove the new vapor that is forming after the previous got sucked out.

If an exception is not desirable, it should be sufficient to have the vapor/liquid/solid conversion step happen after the gas is added/removed, but before the terraformers check if the gas is removed. This should mean that additional water vapor is added to the atmosphere before the 'formers check if they should shut off, rather than after.

[Garfunkel]

That is a much better solution as otherwise there's a risk of killing colonists by causing a drought. Not enough water, CC cost goes up, people die.

[QuakeIV]

It may or may not be practical to re-order the calculations like that, if its easily possible thats definitely the right way to go however.

Would be kindof nice to be able to set a target surface water percentage though.  This would also be an exception but in my opinion a logical one.

[Garfunkel]

It may or may not be practical to re-order the calculations like that, if its easily possible thats definitely the right way to go however.

Would be kindof nice to be able to set a target surface water percentage though.  This would also be an exception but in my opinion a logical one.

Once Steve has the time to redo the terraforming interface, we'll hopefully get a "target atmosphere and water level" window and then just leave the TF stations to do their business.

[Froggiest1982]

The Create Project under the Research Lab should be changed as the Create Project window is actually different. Furthermore, the Create Project window should also be accessible via the research screen.

I suggest the current Create Research button to be changed into Start Research (or project) and to add a new button called Create Project linked to the correct window.



CURRENT





SUGGESTED




Eventually, I would still at least change the Create Research button into Start Research (or project) for clarity.

[Elminster]

Make the "Matching Scientists Only" checkbox checked as default.


In fact you always do this click, and then again when you don't have a matching scientist.

[serger]

Off-topic:

Current Russian naming scheme (that's on screenshot) looks rather funny for native Russian:

1) A lot of first names in diminutive forms (Pasha, Fedya, Jasha), some of them double diminutive (Boryenka, Stepka), and that's for the culture, that is nearly never using diminutives in official context, even to convey a pejorative sense - and that's the only sense in which diminutive forms are applicable in Russian aside of friendly/family context; it was really a norm up to XVIII century to use diminutives as a rank denotation (that is: a monarch using diminutives when referring to any of their subject; a nobleman - to a serf, etc.), yet it's a completely dead ancient norm.

2) Some surnames among/instead of given names (Petrov, Dmitreeva).

3) Strictly-feminitive surnames paired with strictly-male given names (the only way to approximate a Russian norms in Aurora naming scheme is to use male surname form only).

4) Non-Russian given names that are not and was not in use as popular foreign names in Russia (Marko, Derzhena).

5) Some orthographic mistakes (Shashenka instead of Sashenka, though it's intimate double diminutive inacceptible in official context too).

I'll edit and upload smth like "Russian, modern edition" naming scheme if you need it.

[Platys51]

Suggestion:
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.

[Kiero]

I would like to see another option (the those that are in Naval organization->Ship Overview->Ship Design Display tab) for "tankers":
"Refuel own Refueling Hub".

[Blogaugis]

Suggestion:
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.

Add up to that, how about making engineering spaces, maintenance storage, fuel storage, cargo space, cryogenic and ground troop transport components design-able? I much prefer them to be able to design them (from the get-go, Conventional start) rather than research them. Making them design-able during conventional start could also allow us to play some interesting scenarios, set in home system as well.
Also... I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport? We already have drop bays and boarding bays...

[MasonMac]

Instead of completely disabling shipping lines, would it be possible to just impose a cap on them? I would like to have the shipping lines upgrade their ships to be honest.

[Elminster]

Also. . .  I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport?

I always think that the troop transport component also includes training facilities, briefing rooms, small maintenance equipment, even shooting ranges and gyms.  So the troops can perform some training and preparations during the voyages.

[Blogaugis]

I always think that the troop transport component also includes training facilities, briefing rooms, small maintenance equipment, even shooting ranges and gyms.  So the troops can perform some training and preparations during the voyages.

And it is made, so that the troops being transported actually retain their capability to be combat-effective...
Alright, I guess I can understand that.

Although... would cryogenic transport be able to... be a makeshift troop transport component, at least, in some instances?

I mean, do we really need so many different types of transport components? Can we simplify it from:
3+ (cryogenic, cargo, troop with boarding and drop) to 2+ (cargo not requiring a life support, cargo requiring life support with boarding and drop)?

[Density]

Also... I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport? We already have drop bays and boarding bays...

The troop transport bay is cheaper and uses less displacement than the drop and boarding bays of the same size. Even if the player has all the varieties researched, they have the option to make cheap ship classes for moving garrisons and defensive troops. That is, ships that aren't overdesigned for their role in terms of speed, defenses, and the bay itself.

You may prefer less options in this regard, others prefer more.