C# Suggestions

[Zincat]

Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

[SpikeTheHobbitMage]

Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

I've been saying that for years. 

[Shadow]

Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.

[SpikeTheHobbitMage]

Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.

It is actually trivial to track and shouldn't noticeably affect performance.  Give each shipping line a counter for each category of ships it operates (F, C, L).  Every time a civilian ship can't find* a job, bump the appropriate counter.  Every time a shipping line builds new ships, only consider categories that have low** counters and then reset the counters for that line.  If all categories are too high then don't build anything and put the money into dividends instead.

*They check every time they finish a job or once every five days while idle.
**One more than the number of production cycles since the last build cycle is probably a good upper limit.

[Zincat]

Something similar to what SpiketheHobbitMage said, and check every production cycle (5 days). If the ship did nothing, then increase the counter. You just need one counter for the entire shipping line, if multiple ships did nothing the counter gets increased mutliple times. Should have negligible performance impact.

We also have the history of what the civilian ships did, if we want to use that, but the various tasks do not have the same lenght of course, so it could be tricky. One trip to the moon is different than one trip to a 60 billion km colony in another system. So I'd just use a counter based on how many production cycles the ships of the company had nothing to do.

[SpikeTheHobbitMage]

Some QoL ideas regarding fleet management:

Current Location:
If a fleet is in orbit around a body, at a jump point, etc, then that body/JP should be listed first in the locations list.
If the fleet is in space then an entry called 'Current location' should be listed first with commands like a way-point.

Sub-fleets:
Allow sub-fleets to have standing orders.  Such orders shouldn't do anything as-is, but:
-When a fleet is given the order 'Join as Sub-Fleet' it should remember its standing orders.
-When a sub-fleet is detached its standing orders should become active again.

An order to detach all sub-fleets.

Remember the parent fleet when detaching a sub-fleet, or parent sub-fleet if detaching a sub-sub-fleet.  This should survive the parent fleet joining another fleet as a sub-fleet and/or detaching from a grandparent fleet.
-A standing order to re-join the parent fleet as a sub-fleet.
-If a fleet has a parent fleet then it should be listed second in the locations list, even if the 'Fleets' option isn't checked.

An order to wait for all detached sub-fleets to rejoin.

Fleet list:
Dropping a fleet onto another should join as a sub-fleet instead of merging.
Right-clicking on a fleet should give options to merge into the parent and/or absorb sub-fleets.
If a fleet is dropped on another fleet that is at a different location, ask the player if they want to issue move and join orders.

[Jorgen_CAB]

Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.

It is actually trivial to track and shouldn't noticeably affect performance.  Give each shipping line a counter for each category of ships it operates (F, C, L).  Every time a civilian ship can't find* a job, bump the appropriate counter.  Every time a shipping line builds new ships, only consider categories that have low** counters and then reset the counters for that line.  If all categories are too high then don't build anything and put the money into dividends instead.

*They check every time they finish a job or once every five days while idle.
**One more than the number of production cycles since the last build cycle is probably a good upper limit.

I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.

This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.

There is no need to use artificial and arbitrary rules for this, the economy can govern itself.

I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...

[SpikeTheHobbitMage]

I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.

This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.

There is no need to use artificial and arbitrary rules for this, the economy can govern itself.

I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...

Such a system would make the shipping lines overbuild until they bankrupted themselves and collapsed.  Not only does it do nothing to address the problem at hand (overbuilding ships) it actually manages to be worse than the existing system (introduces catastrophic collapse cycles).  The demand limiting mechanisms under discussion aren't arbitrary, but a simplified model of how actual shipping lines manage production.

Civilians using TN materials, especially fuel, would not only eliminate the sole advantage to having them but it would make them an active threat.  There would be no reason to ever enable them.

[QuakeIV]

The proposed system of running costs, plus selling ships the line cant afford, would work perfeclty fine if there was dampening on both ends of the behavior.

That is to say: if current rate of income isnt meeting current costs (sum of income vs sum of costs for past year for instance), start scrapping ships (less effecient ships first, so for instance older engine tech perhaps), rather than waiting to run out of money first (waiting to run out would cause a catastrophic collapse).  Additionally, only purchase new ships if surplus income is sustained for a while (maybe a year? i dunno).

The running cost could be changed to calibrate roughly how many ships they keep on hand.

[Jorgen_CAB]

I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.

This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.

There is no need to use artificial and arbitrary rules for this, the economy can govern itself.

I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...

Such a system would make the shipping lines overbuild until they bankrupted themselves and collapsed.  Not only does it do nothing to address the problem at hand (overbuilding ships) it actually manages to be worse than the existing system (introduces catastrophic collapse cycles).  The demand limiting mechanisms under discussion aren't arbitrary, but a simplified model of how actual shipping lines manage production.

Civilians using TN materials, especially fuel, would not only eliminate the sole advantage to having them but it would make them an active threat.  There would be no reason to ever enable them.

No... they would not..

1. They first would try to sell it... if that don't work they scrap it and get some wealth back.

2. When a ship is sold/scraped their running cost is lowered and they get some fresh new cash.

This would act to balance their economy and not make it crash, not very hard to make right at all... They would only crash if there is NO jobs at all. In that case there can be some safeguard in place where they are guarantied to keep a few ship that they don't have to pay maintenance for.

[SpikeTheHobbitMage]

The proposed system of running costs, plus selling ships the line cant afford, would work perfeclty fine if there was dampening on both ends of the behavior.

That is to say: if current rate of income isnt meeting current costs (sum of income vs sum of costs for past year for instance), start scrapping ships (less effecient ships first, so for instance older engine tech perhaps), rather than waiting to run out of money first (waiting to run out would cause a catastrophic collapse).  Additionally, only purchase new ships if surplus income is sustained for a while (maybe a year? i dunno).

The running cost could be changed to calibrate roughly how many ships they keep on hand.

Building surplus ships due to surplus income is the problem behaviour that we need to fix.  Adding a delay would cause unnecessary production lag during growth periods, especially in the critical early game, while doing nothing to actually limit overbuilding.  The only 'dampening factor' that will effectively curb idle civilian ships is to track their idle time.  No measurement of supply (income) can ever accomplish that goal because it is measuring the wrong thing, and any valid proxy will always be inferior to direct measurement.

No... they would not..

1. They first would try to sell it... if that don't work they scrap it and get some wealth back.

2. When a ship is sold/scraped their running cost is lowered and they get some fresh new cash.

This would act to balance their economy and not make it crash, not very hard to make right at all... They would only crash if there is NO jobs at all. In that case there can be some safeguard in place where they are guarantied to keep a few ship that they don't have to pay maintenance for.

Even granting that, your proposed system still requires a large idle fleet to create the increased costs needed to curb growth.  It will always produce a fixed ratio of working to idle ships, which is what the current system already gives us and is exactly the problem that we need to fix.  Simply changing the ratio does not address the problem.  Reducing the ratio too far will also cripple small lines in the early game.

If there aren't enough jobs to support them then the civilian lines should fold.  That is the only way to automatically limit the number of civilian lines.

[Coleslaw]

I feel like this one has been suggested already but I can't seem to find it, so maybe it hasn't.

Being able to queue the research project that follows after the project you assigned a scientist and labs for would be super handy. I.e., I'm researching active sensor strength 16, it would be nice if I could also then queue active sensor strength 21 (the next tier after 16), and then also queue active sensor strength 28 (the next tier after 21.)

[QuakeIV]

It should control their population somewhat if there is a substantial running cost for the ships.

[xenoscepter]

I would like some form of orbital ground command, if I haven't asked for it already.

Here's a link to the bigger, nicer looking request:
http://aurora2.pentarch.org/index.php?topic=11671.0

[SpikeTheHobbitMage]

It should control their population somewhat if there is a substantial running cost for the ships.

That would cause idle colonizers to limit needed freighter production without actually preventing construction of unnecessary ships in the first place.

Seriously, what is wrong with my proposal?  It is well defined, directly addresses the problem, shouldn't have any negative side-effects, and should be trivial to implement.